Ontology Evolution Management for Semantic ... - Semantic Scholar

Download PDF
2 downloads 19697 Views 455KB Size Report
Comment
International Journal of Electronic Business Management, Vol. 9, No. 4, pp. 310-321 ... processing of ontology and related mapping evolution management. A case study in ...... Application Platform Suite (APS), or aggregated services evolving ...
310

International Journal of Electronic Business Management, Vol. 9, No. 4, pp. 310-321 (2011)

ONTOLOGY EVOLUTION MANAGEMENT FOR SEMANTIC WEB SERVICES COOPERATION Soumaya Slimani1*, Djamal Benslimane2, Salah Baïna1 and Karim Baïna1 1 Ecole Nationale Supérieur d’Informatique et d’Analyse des Système Mohammed V-Souissi University Rabat (10000), Morocco 2 Laboratoire d'InfoRmatique en Image et Systèmes d'information Lyon1 University Lyon (69100), France

ABSTRACT Interconnecting services is a complex task. A part of the complexity comes from the need to have a common, shared view of the information, ontology. Thus, there is a need for approaches that help to overcome the differences between service ontologies, and to manage the possible future evolution of the ontologies. The approach proposed in this paper provides a support for cooperation between services. Our proposition is useful for service architectures that evolve and grow in size constantly. The number of services increases and even services are changing to offer new alternatives. The aim is to provide a flexible way to partially automate the processing of ontology and related mapping evolution management. A case study in Telecom service cooperation illustrates the benefits of our approach. We apply our algorithm and implementation prototype p2OEManager to Message Billing Service ontology and Internet Billing Service ontology and particularly, we use our ontology agent model and prototype to manage some significant changes in these ontologies. Keywords: Ontology Evolution, Semantic Service, Multi-agent System

1. INTRODUCTION *

In recent years Enterprise Application Integration (EAI) systems have evolved towards service-oriented architectures (SOA) [6]. However, today’s SOA technologies only provide a partial solution to interoperability. Moreover, in accordance to [13], current SOA standards do not provide any semantic composing functionality. In order to address these drawbacks, a major effort has been invested in semantic extensions of SOA known as Semantic SOA which offers a scalable integration, more adaptive to changes in business requirements. Web services are the most used technology to develop the SOA. Two elements are essential to move from basic SOA to SSOA (Semantic SOA): 1. Ontology: Ontology is, in accordance with the definitions of [5], a formal specification of a shared conceptualization. An Ontology consists of concepts that are organized taxonomically using subsumption relationships (is-a), property or relationship that represents interactions types between concepts and individuals that are used to represent concrete entities in a domain. We can *

Corresponding author:[email protected]

distinguish several types of ontologies: (1) General ontologies: are related to general concepts that are independent of a field or a particular problem, such as concepts of time, space, concept of mathematics. (2) The domain ontologies: such ontologies express specific conceptualizations of ontology in particular fields but still generic for these fields. Many domain ontologies have been developed (Enterprise Ontology, UMLS). (3) Ontologies of applications: these ontologies are the most specific. Concepts correspond to the role played by domain entities while performing a certain activity. These ontologies may contain specific extensions such methods and tasks. They may also contain all definitions to describe the knowledge required for a particular application. From this categorization, we can conclude that service ontology is very specific because it describes the functional properties of a service. On the other hand, we believe that the frequency of change increases when the ontology is more specific and the ontology is more stable when it is more generic (Figure 1). Service ontology evolves continuously, i.e., it is frequently changing to incorporate new domain knowledge. Then, a mechanism for ontology evolution management is essential.

S. Slimani et al.: Ontology Evolution Management for Semantic Web Services Cooperation 2. Semantic Web services: are the result of the evolution of both Web services syntactic definition and the Semantic Web. So, to bring semantics to traditional Web services description several standards exist: OWL-S [11], WSMO [4] and WSDL-S [1].

these ontologies because services are not aware of these changes. Hence, ontology mappings (which allow services to interpret correctly exchanged data) should be updated. Furthermore, new concepts and relationships which are added should be used in the communication between services as quickly as possible. Research in ontology evolution and change management deals particularly with the versioning and evolution of the same ontology, but does not deal with the evolution of heterogeneous ontologies, interrelated by mappings and describing different services. So, existing approaches are not applicable to the SSOA context.

Mono ontology

Figure 1: Ontology specificity vs ontology change rate Using these two elements (Semantic Web service and ontologies), three integration approaches can be used to develop SSOA (Figure 2): 1. Mono-ontology integration approach: a single ontology provides a shared vocabulary to all services. This does not support the semantic heterogeneity and requires an adaptation of the global ontology when adding or updating applications. 2. Multiple ontologies integration approach: each service is described by its own ontology. This approach supports semantic heterogeneity, but the management of connections and comparisons between local ontologies is difficult. 3. Hybrid integration approach: takes advantage of the two previous approaches, each service is described by its own ontology, and ontologies of all services (local ontologies) are connected to a global ontology to share a common vocabulary. This approach is the appropriate approach that meets requirements like semantic heterogeneity, scalability of the system and comparing ontologies. We can deduce that the hybrid approach is the appropriate approach to the agile context of SSOA but it demands the development and the management of a greater number of ontologies. Scaling this approach requires other techniques and algorithms to perform the management of all ontologies and their related mappings. The ontology evolution management in SSOA architecture is still an open question. As the semantic service oriented architecture (SSOA) grows in size, the complexity of ontology change management increases. However, these changes, may impact the correctness of future services communication using

311

approach

Multiple ontology approach

Hybrid approach

Figure 2: Semantic service integration approaches In this paper, we propose a new architectural approach for managing distributed services ontologies and the ontology-related mappings using an agent-based algorithm. A framework is proposed for developing an ontology agent model that manages changes in different services ontologies. This model consists of two levels or dimensions. The first dimension describes how agent can detect, transform and propagate changes. The second dimension of the model describes how receiver agent processes changes and the mappings update. This architecture was implemented on a prototype system developed for managing distributed OWL ontologies. The remainder of this paper is as follows: Section 2 presents a case study demonstrating cooperation between multiple services from the Telecom Billing domain, the functional requirements for this cooperation and different scenarios for Ontology evolution of cooperating services, while Section 3 discusses the state-of-the-art in semantic service-oriented architecture and ontology evolution. Section 4 presents the proposed ontology evolution approach. Section 5 presents the implementation architecture and details. In section 6, we use our ontology agent model and p2OEManager prototype to manage some significant changes in the Telecom Billing case, and finally conclusions are drawn in Section 7.

2. ONTOLOGY-EVOLUTION SCENARIOS AND TASKS We will now discuss different scenarios for ontology evolution, their attributes, and functional requirements for service collaboration.

312

International Journal of Electronic Business Management, Vol. 9, No. 4 (2011)

2.1 Case Study We now describe briefly some specific scenarios of ontology evolution in a collaborative service-based environment. We limit ourselves to an example of four services. But this example can be generalized to a more complex architecture. The running example ontologies come from the domain of Telecom and concern particularly four telecom billing services. 1. Service cooperation scenario: We use a notion of Cooperation environment to denote a network of interconnected services that work and evolve under a set of guidelines. In our example, the client application Duo-billing (DB) uses services provided by Internet billing (IB) and Mobile billing (MbB), (MbB) uses itself services provided by Message billing (MB) (Figure 3). To calculate an Internet bill, DB specifies information about the customer or the customer account and requests from both IB and MbB the set of transaction made by the customer and the associated price. To fulfill the request, IB and MbB use MB services. As broker, IB and MbB should be able to interpret the information on SMS that cover the specified bill supplied by DB. As shown in Figure 3. , in order to manage this cooperation, the four participants export schemas and exchange data based on mappings.

Figure 3: Actors and resource exchanges in the telecom duo billing case 2. Semantic description of services: For this example, we focus on the interconnection of both Internet billing and Message billing services. Services descriptions in the case are developed using WSDL-S standard. So, we have annotated the capabilities and requirements of Web services with semantic concepts referenced from ontologies. Figure 4 shows the Message ontology part of the telecommunications services ontology developed for SIMS1. This ontology is used in our 1

http://meag.tele.pw.edu.pl/sims/ontology.html

example by the Message billing service. Figure 5 shows the Message part of the Internet ontology used by the Internet billing service. MESSAGE Is a

Is a

MULTIMEDIAMESSAGE

TEXTUALMESSAG E CONTAINS_SMS*

HAS_CHARGE*SMSEXCHANG

CHARGE

INTERNET_SMS

HAS_PARTICIPANT

PARTICIPANT

Is a

HAS_SENDER* HAS_RECEIVER* Is a

Is a

CUSTOMER_SERVIC

CUSTORMER

Figure 4: Part of message billing ontology (MBO) MESSAGE Is a

HAS_SENDER*

INTERNET_SMS

CUSTOMER_SERVICE

HAS_RECEIVERS*

CUSTOMER

Figure 5: Message part of internet billing ontology (IBO) 2.2 Functional Requirement for Semantic Service Cooperation We start by discussing the exchange between the Internet Billing service and the Message Billing service then some functional requirements that are relevant for ontology evolution in any collaborative service architecture. 1. From internet billing to message billing: The ID_account is sent from the DB to the IB. the IB uses this information to access the customer internet account. Internet access is billed per minute. Among Internet Billing services, a customer can receive message containing information about his Internet account balance, this service is called INTERNET_SMS. Internet service needs to know the INTERNET_SMS bill to calculate the bill (how many INTERNET_SMS has asked the customer during the billing period? and how much it costs?). Services that require the message bill must specify the ID_account and the message type: The mapping presented in Table 1 shows the correspondences between the two ontologies and we can identify also that some concepts don’t have any correspondences: 2. Functional requirements for service collaboration: For the sake of describing our approach we provide the following scenario of

S. Slimani et al.: Ontology Evolution Management for Semantic Web Services Cooperation IBO and MBO ontology evolution, their semantic description and their implications on the mapping and then on the services communication: Table 1: Mapping between MBO and IBO Concepts

Is equivalent to

MBO.MESSAGE

IBO.MESSAGE

MBO.INTERNET_SMS

IBO.INTERNET_SMS

MBO.HAS_SENDER only CUSTOMER_SERVICE MBO.HAS_RECEIVER only CUSTOMER

IBO.HAS_SENDER

IBO.HAS_RECEIVER

When updating ontologies on either side there is a need for synchronization. Thus changes in either the Internet Billing ontology (IBO) or the Message Billing ontology (MBO) need to be reflected on both sides and on the mapping. Some factors should be considered: 1. Not all changes should be propagated: there are some changes which are not interesting to manage because they do not affect the relation between the IBO and all MBO. 2. Not all dependent ontologies must receive all changes: For example changes in IBO that are only related to the mapping between IBO and MBO will be sent only to the ontology MBO. 3. Changes should be understandable: to have well understanding of changes, a translation phase is necessary. Changes will be translated according to the mapping between the IBO and MBO. 4. The mapping update should be managed: Mapping is a charred resource between IBO and MBO. So, access to this resource can generate conflicts. 5. Study of change operation impact on service communication: On one hand, delete operation is considered as an operation which not has an impact on semantic conflict during service communication. But this manipulation will stop the communication between services. Because service does not have the necessary concepts to answer the query (Example 1, Table 1). On the other hand, the add operation may modify the semantics of concepts; subsequently the service answer will be erroneous (Example 2, Table 1). The update operation is a combination of the delete and the add operations. In this paper we focus on the add operation as it is the most important operation that affects the service communication correctness.

313

3. RELATED WORKS In this section we give an overview of the research works related to our approach. We divide this overview into two parts regarding two research communities: the semantic service oriented architecture (SSOA), and the ontology evolution. 3.1. Related Works in SSOA As mentioned in the introduction, modeling the semantics of business services and their corresponding messages using ontologies enables flexible integration that is more adaptive to business-driven change. Several works have developed tools and adopted approaches to develop semantic service architectures: - Haller [6] applies the WSMO (Web Service Modeling Ontology) principle to present a new type of SOA architecture called SSOA. This solution is based on a multi-ontology approach, in this model semantics is distributed in services that are highly isolated. The management of connections and comparison between the local service ontologies is difficult. From the interoperability perspective, the use of WSML to represent services semantics (WSMO ontologies) may be the weak point of this solution. - Izza [8] extends the SOA architecture by adding a semantic layer. This paper proposes a hybrid approach to semantic integration. In the proposed architecture, each service has an OWL-S description and services ontologies are in an urbanized area. Although this model has the advantages of being a hybrid integration approach, the complexity of the semantic model in terms of number of ontologies is a major drawback especially when no automation or management mechanism is provided. - Châtel [2] proposes a Framework called SETH (Semantic Thales) for the interoperability of heterogeneous SOAs. In this architecture single domain ontology allows semantic annotation of services that are described by a SAWSDL description. This architecture is centralized and mono-ontology which makes the implementation simple, but this requires an adaptation of the global ontology when adding or updating applications. The part of the problem lies in the management of ontology evolution in these architectures. As the semantic service oriented architecture (SSOA) grows in size, the complexity of ontology change management increases. However, these changes, may impact the correctness of future communication using these ontologies because services are not aware of these changes. Hence, ontology mappings, which allow services to interpret correctly exchanged data, should be managed too.

314

International Journal of Electronic Business Management, Vol. 9, No. 4 (2011)

3.2 Related Works in Ontology Evolution The ontology evolution and change management has been addressed by many researchers. For instance, Klein [9] [10] investigates the versioning of ontologies, Plessers [12] defines Change Definition Language (CDL) to specify changes, Djedidi [3] presents a patterns-based ontology evolution approach called “Onto-Evoal” and Zablith [14] proposes a solution is called “Evolva”; a Framework for ontology evolution which explores different sources of information to evolve ontology. These previous works are complementary to ours and they neither consider service ontologies nor the evolution of related mappings. Furthermore, the evolution of ontology-related mappings in life science domain has been analyzed in [7]. The existing algorithms are not applicable to our context (SSOA), because they deal with ontology versions and distributed copies of the same ontology. So, the ontology evolution will require applying the same changes on the distributed ontologies. But, in the SSOA, service ontologies are heterogeneous, and are interconnected by different mappings. In our work, we propose a semi-automated evolution model for multi-ontology system where ontologies are different and mappings between ontologies are managed in parallel.

detailed overview of the ontology evolution process in the Initiator Ontology and in the Dependent Ontology. 4.2 Initiator Ontology Evolution Management As shown in Figure 7, the ontology evolution management process can be presented in 4 steps:

Figure 6: Ontology evolution scenario

4. GENERIC ONTOLOGY EVOLUTION MANAGEMENT MODEL In this section, we present the ontology evolution model, its concepts and algorithms. 4.1 Ontology Evolution Management Model Overview Since ontology evolution is considered in a service cooperation context, the ontology evolution management process is distributed on two sides: change initiator service ontology and change dependent service ontology. IO will denote the initiator service ontology, and DO the dependent service ontology. Figure 6 present the system related to our case study (ontologies and their related mappings). Changes are applied to the ontology IBO. So IBO is initiator ontology (IO) and all ontologies which are related to IBO by a mapping are dependent ontologies (DO). When the ontology IBO changes, all changes should be detected, stored in an appropriate format, and propagated to all dependent ontologies. After the propagation phase, received changes should be handled on the DO side (How changes performed on the IO will affect the dependent ontology and the related mapping?).Below, we explain and illustrate a

Figure7: Initiator ontology evolution management process 4.2.1 Phase 1: Change Detection In this phase a list of changes is automatically generated. To calculate this list a difference between two versions of the initiator ontology (IO) is made, the first one is a version which has been stored after each change, and the second one is the new version of the ontology (i.e. the changed version). The difference between two versions of ontology is calculated by comparing two source files of the ontology. The output of this comparison is a source file (an ontology) containing the added and the deleted objects from the original file. Ci =

( Operation, Object, Subject, Predicate ) (2)

Operation specifies the change operation (Add, Delete, etc). The Object specifies the type of component that has changed (Class, Property, and Individual). The Subject represents the name of the component that has changed. The Predicate

S. Slimani et al.: Ontology Evolution Management for Semantic Web Services Cooperation represents a set of information about the change. If a class was changed, this field contains the position of the class in the hierarchy of the ontology (its super-classes and sub-classes). But, if a property was changed, it contains the Range, Domain, superproperties and sub-properties. It is defined as follows: Predicate =

< superclass, subclasso

Predicate =

< Range, Do

e1  en c1  0  0    MMRC =       ck  1  0 

(8)

(3) (4)

We also define a message or changeSet by a list of changes: changeSet =< C1 , C 2 , …, C n >

315

(5)

Illustration1: Consider changes on IBO in Table 2. Changes are presented as follows:

Illustration 3: For the Mapping M IBO-MBO : - The change C1 is related to the Mapping M IBO-MBO because INTERNET_SMS is an element of the mapping. - The change C2 is related to the Mapping M because IBO-MBO INTERNET_INFO_SMS is subclass of MESSAGE which is an element of the mapping. - The change C6 is not related to any elements of the Mapping. Bellow the related matrix for all changeSet elements: E1 E2 E3 E4

4.2.2 Phase 2: Change and Receivers Selection We define a list of mappings and related ontologies:

C1  0  C2  1 C3  1  MM IBO-MBO RC = C4  0 C5  0  C6  0 C7  0

1 0 0 1 1 0 1

0 0 0 0 0 0 0

0  0 0  0 0  0 0 

… , M in } (6)

If a change, in the changeSet, is related, at least, to one entity in the mapping, we decide that this change is related to this Mapping.

M ij : The mappings between the ontology Oi and the ontology Oj.

IsRelated�ChangeSetMappingSet → { 0, 1 } (9)

MappingSet = ( Oi )

{ Mi1 , Mi2 ,

Illustration2: Consider the schema in Figure 6, for IBO the Mapping Set is: MappingSet(IBO) ={M IBO-MBO , M IBO-DBO } Select mapping-related changes: In this phase ontology will be able to decide whether changes will be ignored or propagated. Two-level decision is made. A first level is to calculate whether changes are related to a specific mapping: IsMpqRelated�ChangeSet × Mpq → { 0, 1 } (7) sMpqRelated (ci, ej) = {1,0, if ∃ r ∈ Rtqr[ci, ej] = 1 else

Using this function we can calculate the matrix MMpqRC (Matrix of Changes Related to the mapping Mpq) whose rows represent the changeSet elements and the columns represent the entities of the specific mapping.

IsRelated(cj, Mpq) = {1,0, if

∃ i / MMpqRC[cj, ei] = 1 else

So, this operation will initiate the second level decision. After calculating all related changes of all mappings in the MappingSet. The results are stored in a matrix MMRC (Matrix of Mapping-Related Changes) whose rows represent the changeSet elements (i.e. all Changes) and the columns represent the MappingSet elements (i.e. all DO Mappings). Mp1  Mpn c1  0  0  (10)   MMRC =       ck  1  0  Receivers Selection: If a change, in the changeSet, is related at least to one mapping in the MappingSet, we decide that this change will not be ignored and we

316

International Journal of Electronic Business Management, Vol. 9, No. 4 (2011)

decide to propagate this changes to the corresponding DO. Table 2: IBO and MBO evolution scenarios Change Ontology Semantic description Implications - On service communication For Message Billing service there is no INTERNET_INFO_SMS concept, so INTERNET_INFO_SMS is communication with Internet Billing service Update an SMS that fail. ‘INTERNET_SMS’ to IBO CUSTOMER_SERVICE - On Mapping ‘INTERNET_INFO_SMS’ sends to the CUSTOMER. The correspondence “MBO. INTERNET_SMS IBO.INTERNET_SMS” must be updated to “MBO. INTERNET_INFO_SMS IBO.INTERNET_SMS”

-

ADD

-

‘INTERNET_SMS’ ADD new property

-

ADD

A new type of message, which a client can send to another via Internet. ‘INTERNET_SMS’ has a property which describe that the sender of an ‘INTERNET_SMS’ is a

new class

‘HAS_SENDER’

new property

IBO

CUSTOMER.

has a property which describe that the receiver of an ‘INTERNET_SMS’ is a CUSTOMER. For each INTERNET_SMS, a FEE is associated. Add new type of MESSAGE. ‘INTERNET_SMS’

‘HAS_RECEIVER’

-

ADD

new property

‘HAS_FEE’

-

new class ‘MMS’.

ADD

IsPropagaed (cj)

MBO

=1 = {1,0, ∃ i / MMpqRC[cj, Mpi] else

(11)

The propagation matrix is represented as follows: DO1  DOn c1  0  0    MPg =       ck  1  0 

(12)

Illustration 5: The propagation matrix of our example is: MBO

DBO

C1 1 1   C2 1 0 C3 1 0   MPg = C4 1 0 C5 1 0   C6 1 0 C711 0  The changes C1 and C4 are propagated to MBO

-

On Mapping MBO. INTERNET_SMS ≠ IBO.INTERNET_SMS

- On service communication Services have two different interpretations of the concept INTERNET_SMS. Communication cannot be done properly. So Message billing response by sending the FEE of SMS that sends CUSTOMER_SERVICE to the CUSTOMER.

No implication on the service communication.

and DBO. The changes C2, C3, C5 and C7 are only propagated to MBO. The change C6 is not propagated. For changes to be propagated, translation phase is necessary. In this phase, a new list of changes is generated by replacing the objects of the field Predicate in the original list by their match in the related mapping. Note that only changes that are related to the mapping are translated so all elements in the predicate part can be mapped. The operation of change translation is a transformation of a change based on a specific mapping. TMRC: ChangeSet x MappingSet  Change (13) Ci = (OP, O, S, ) TMRC(Ci, M pq ) = (OP, O, S, -

4.3.1 Step 1: Syntactic and Semantic Search Process a syntactic and semantic search for each change in the received change set. The semantic search looks for a semantic corresponding object of change. Specifically, it looks for an equivalent concept. A search algorithm in ontology and a dictionary is used. SemSearch�ChangeSet × O → { 0, 1 }

(14)

SemSearch (ci, Oj) = =1 {10,if ∃ cj ∈ Oj / equivalent (ci, cj) else

The syntactic search finds if there is a concept in the ontology which has the same syntax as the changed object. The EqualDistance algorithm is used in this phase. It returns true if the two strings are identical and it returns false if they are different. SyntacticSearch�ChangeSet × O → { 0, 1 } (15)

SyntacticSearch�(ci, Oj) = =0 {10,if ∃ cj ∈ Oj EqualDistance (ci, cj) else

4.3.2 Step 2: Selection of Action to Perform TMRC: ChangeSet x MappingSet  Change Ci = (OP, O, S, )

Calculate object definition: object definition id presented by a triplet :

Negotiation of object definition: Negotiation, in our case, is an automated process corresponding to the reformulation of the Object definitions, and then to exchange these definitions. The DO calculates a definition of an object, and then sends it to the IO. Which, in turn, interprets this definition and compares it with its definition. If it finds that the two definitions are equivalent, it sends its agreement; otherwise it recalculates the definition, and sends the new definition to the DA, and so on. The negotiation ends when both DO and IO have a common definition of the object or they find a conflict.

Action 3: Annotation of change The added object matches with an object in the dependent ontology, but they have different syntaxes. Then, the mapping is updated and annotation is added to the corresponding object. Annotation allows adding new object as annotation of existing object. An annotation is a comment, a note or any other external remarks that can be attached to an entity of the ontology. In OWL DL, it is possible to annotate classes, properties and individuals. There are five predefined annotation properties in OWL: Owl:versionInfo, Rdfs:label, Rdfs:comment, Rdfs:seeAlso, Rdfs: isDefinedBy. Table 3: Dependent ontology actions Syntactic Search

According to the results in step 1, one of the actions summarized in Table 3 is applied: Action 1: Update related mapping Dependent ontology contains syntactically and semantically the added object. In this case, the mapping between initiator ontology and dependent ontology is updated. Mapping of ontologies is based on the definition of the corresponding relationships between entities of two ontologies. The update mapping method allows adding new correspondence between two concepts in the mapping.

True

True

Semantic Search False

Action 2: Negotiation of change definition The added object exists in the dependent ontology but does not have the same semantics as the initiator ontology object. So, a phase of collaborate is necessary to define a common definition of the change (what we call negotiation). If negotiations

Action 1 -Updates the related mapping (action 1) Action 2 -Reformulate s the change definition. -Negotiates the change definition.

Action 4: Add new object

False Action 3 -Action 1. -Annotates the corresponding object by the added object. Action 4 -Adds the new object to the ontology. - Action 1.

318

International Journal of Electronic Business Management, Vol. 9, No. 4 (2011)

The added object is a new object for the DO. Thus, the new object is added to the dependent ontology and mapping is updated.

Illustration7: Below are the results of semantic and the syntactic searches in MBO for all received changes: - C2: The class INTERNET_INFO_SMS matches with the class INTERNET_SMS in MBO, so we perform the action 3. - C3: INTERNET_SMS in MBO has not the same semantics of INTERNET_SMS in IBO. In this case we choose the action 2 in the algorithm. - C4: HAS_SENDER exists in both IBO and MBO and it has not the same semantic, so we perform the action 2. - C5: HAS_RECEIVER exists in both IBO and MBO and it has the same semantics, so we perform the action 1 and we update the mapping by adding new correspondence between IBO.HAS_SENDER and MBO.HAS_SENDER. - C7: The class FEE and the property HAS_FEE in IBO match with the class CHARGE and the property HAS_CHARGE, so we perform the action 3.

Syntactic search Semantic search Action

C2 0

C3 1

C4 1

C5 1

C7 0

1

0

0

1

1

Action

Action

Action

Action

Action

Performed

3

2

2

1

3

5. DESIGN AND IMPLEMENTATION 5.1 p2OEManager Design Overview The typical characteristics of ontology and service ontology-based applications can be identified as: distributed, heterogeneous, and highly dynamic. Agent technology is thus ideally suited to this context. The overall architecture of our proposal is shown in Figure 7. p2OEManager (which stands for peer to peer Ontology Event Manager) consists of 3 main components: Ontology Manager, Ontology Mapping Manager, and Ontology Agent Manager built on an open Service Layer. Interactions between instances p2OEManager peers (i.e. ontology change event messages) are handled through an ontology change communication channel. In fact, p2OEManager is neutral regarding the service infrastructures. Thus, services can be either composite services handled within a usual Application Platform Suite (APS), or aggregated services evolving within an Enterprise Service Bus (ESB), or even atomic services listening behind a basic Application Server (AS) Container. Also, business messages between those services are supported outside the scope of p2OEManager within service marshalling/unmarshalling and security, addressing, reliable messaging, routing, and transport standard protocols.

Figure 7: p2OEManager architecture p2OEManager architecture is based on agent based approach. As shown in Figure 7, service layer, which is outside p2OEManager, represents services that are described by ontologies. Service ontologies are defined by human designers using ontology editors, and these service ontologies are then monitored synchronously by p2OEManager. Service dependencies are represented by service ontology mappings defined by human designers too using ontology mapping tools. Services communicate and collaborate with each other within the service infrastructure based on ontology mappings evolving in p2OEManager.

Our proposal is based on a combination of ontologies and agents. We associate an agent to each ontology. This agent is responsible of change management and propagation of these changes to other dependent ontologies. 5.1.1 Ontology Manager Ontology Manager is a component that handles, and monitors service ontologies. Service ontology must evolve to adapt to business evolution, and ontology changes can also concern its entities (i.e. ontology components). Each ontology describes one service evolving in the service layer. A user can

S. Slimani et al.: Ontology Evolution Management for Semantic Web Services Cooperation

319

process changes on service ontology via an ontology editor and Ontology Manager will be responsible for monitoring ontology changes.

based on the existing correspondences in the mapping. The Ontology Mapping Manager uses Wordnet too to extract those relations.

5.1.2 Ontology Mapping Manager The Ontology Mapping Manager is a component that handles the description of correspondent relationships between entities of two ontologies. The mapping in our context is used to make exchanges between services more understandable. So, based on mapping, services can build a more reliable interpretation of all concepts used in exchanges with other services. If ontologies evolve, the mapping must evolve too. Ontology Mapping Manager is responsible of managing ontology mapping evolution by adding new correspondences between existing and changed concepts. As the first version of the mapping exists, the Ontology Mapping Manager updates this version and creates new relations between concepts

5.1.3 Ontology Agent Manager Ontology Agent Manager is a component that manages ontology agents monitoring both service ontologies, and ontology mappings. Each agent acts on a service ontology and on a corresponding mapping in the mapping layer. The goal of an ontology agent is to implement the ontology evolution life cycle basically through detecting and propagating changes to other agents and to update the mapping. Within Ontology Agent Manager instances, agents interact, in a peer to peer manner, with each other to reach their goal. There are two participants in agent interaction a sender and a receiver. Therefore, in our proposal agent will take one of two roles:

Table 4: IBO and MBO evolution scenarios Change

Implications - On Mapping The correspondence “MBO. INTERNET_SMS IBO.INTERNET_SMS”

Solution performed by the agent - On Mapping Add to M IBO-MBO : must

be updated to “MBO. Update ‘INTERNET_SMS’ to

INTERNET_INFO_SMS IBO.INTERNET_SMS”

‘INTERNET_INFO_SMS’

- On service communication For Mobile Billing service there is no INTERNET_INFO_SMS concept, so communication with Internet Billing service fail. - On Mapping MBO.INTERNET_SMS≠ IBO.INTERNET_SMS MBO. HAS_SENDER ≠ HAS_SENDER

IBO.INTERNET_SMS_INFO = MBO.INTERNET_SMS.

- On service communication Now IBO can use INTERNET_INFO_SMS to request for a bill. - On Mapping Add to M IBO-MBO : Agent update the mapping by adding new correspondence between FEE and CHARGE, and between HAS_ FEE and HA S_CHARGE.

The agent adds also a property “same as: FEE”. On service communication

CHARGE

-

new class ‘INTERNET_SMS’ - ADD new property ADD

‘HAS_SENDER’

-

ADD

new property

‘HAS_RECEIVER’

-

ADD

new property

‘HAS_FEE’

- On service communication Services have two different interpretations of the concept INTERNET_SMS. Communication cannot be done properly. So Message billing response by sending the FEE of SMS that sends CUSTOMER_SERVICE to the CUSTOMER.

-

Agents exchange INTERNET_SMS definition to negotiate. To have the same definition agent must add a mapping between IBO.CUSTOMER and MBO.CUSTOMER_SERVICE, but this operation can generate an error, because we have already in the mapping a correspondence between IBO.CUSTOMER and MBO.CUSTOMER. In this case, the agent sends an alert message to the user. The user can modify the mapping and the ontology IBO or validate any of the definitions contained in the negotiations exchange.

320

International Journal of Electronic Business Management, Vol. 9, No. 4 (2011) -

new class No implication on the service This change is not propagated, so ‘MMS’. communication agent ignores it. - Initiator Ontology Agent (we will name IOA), 6. EVALUATION SCENARIO: when its ontology changed TELECOM DUO-BILLING CASE - Dependent Ontology Agent (we will name DOA), when an ontology of a service collaborating with For this case study, we have chosen to use the its ontology service changed. complete model of the Ontology Agent. Because, we have developed our ontologies and their related 5.2 p2OEManager Implementation mapping using tools generating an OWL format. As We have developed an agent-based ontology input, we have the Internet Billing service ontology evolution prototype using the JADE platform (IBO), the Message Billing service ontology (MBO), http://jade.tilab.com/). So, we have implemented the and the mapping between IBO and MBO (M IBO-MBO ). IOA and DOA behaviors in Java using Jena API. Our The process of using the complete Ontology Agent proposal presents a solution that can be easily used Model can be presented in 3 steps: by service designers and developers within their SOA Step 1: We have parameterized the Ontology Agent technical infrastructures. Designers have to Model by integrating IBO, MBO, and parameterize our Ontology Agent Model to create M URIs. We have obtained two IBO-MBO their ontology agent. Ontology Agents: one for the Internet Billing Following the analysis of the proposed service ontology and another for the architecture, we worked out the details of the Message Billing service ontology. prototype. It consists of one Generic ontology agent interface which will be implemented to create Step 2: Run the IBO agent and the MBO agent. specific ontology agent corresponding to their Step 3: Process change ontology and Mapping format. Bellow, we gives the change implications on the - An OWL Ontology Agent model (OWL-OAM), service communication and the solution performed by when using: (1) OWL format for ontologies, (2) our ontology agents (IBO agent and MBO agent): and OWL format for the Mapping. This is an Our algorithm provides a support for implementation of our ontologyAgent Interface. In cooperation between services. In this example, it this case, users of our model have to parameterize allows services (Internet Billing and Message Billing) the model by integrating only the ontologies and the to be aware of evolution in other services. Agents mapping URI. And then run their Ontology Agent take the necessary decisions to maintain this communication by applying the necessary changes to the mapping and to the ontologies. But if the agent detects a conflict it only informs the user of the problem. The agent-based approach proposed in this paper is suitable for ontology evolution management in dynamic, distributed and heterogeneous environments. We adopt a multi-agent system (MAS) perspective to model ontologies in ontology-based Figure 8: p2OEManager implementation applications. An agent-based approach aims to provide a flexible way to partially automate the We have added a user Agent (UA). This agent process of ontology evolution management as much interacts with a particular GUI. It includes getting the as possible. The approach consists of software agents business scenario from GUI, passing it on to the which are autonomous and engaged in flexible ontology agent instances and presenting expected interactions, these agents can perceive changes in the results. The prototype runs as follows: ontologies and adopt corresponding actions to - User can publish ontology (he gives OWL maintain the mapping between ontologies. ontology URI and creates an account). To illustrate our approach we applied it to a Telecom - User can select dependent ontologies and gives cooperation case. The case study highlighted some of Mappings URIs). the main benefits of the approach. Firstly, it was - The System Develops corresponding OA of the shown that initial differences in the services ontology; ontologies could be overcomed by defining mappings - User can run or stop the ontology agent. between the ontologies. Secondly, and more - User can visualize Agent messages and actions. important, we showed how the approach could be - User can modify ontology and mapping URI. used to propagate change to other dependent ontologies and how to process changes on the ADD

S. Slimani et al.: Ontology Evolution Management for Semantic Web Services Cooperation receiver side. Thus, even though changes were made to the ontologies, interoperability between the services could still be upheld. The approach could be extended and improved in several ways. First, there is a question of the general applicability of the approach. As shown in the case, even quite complex changes in the ontologies can be handled by the approach. However, there is a need to further analyze the implications that these changes have on the logic of the running software services.

REFERENCES 1.

2.

3.

4.

5.

6.

7.

8.

9.

Akkiraju, R., Farrell, J., Miller, J., Nagarajan, M., Schmidt, M. T., Sheth, A. and Verma, K., 2005, Web Service Semantics-WSDL-S, Technical Note, Version 1.0. Châtel, P., 2007, “Toward a semantic Web service discovery and dynamic orchestration based on the formal specification of functional domain knowledge,” International Conference on Software & Systems Engineering and their Applications (ICSSEA). Djedidi, R. and Aufaure, M. A., 2010, “ONTO-EVOAL an ontology evolution approach guided by pattern modeling and quality evaluation,” Lecture Notes in Computer Science, Vol. 5956, pp. 286-305. Domingue, J., Dumitru, R. and Stollberg, M., 2005, “Web service modeling ontology (WSMO) - An ontology for semantic web services,” Position Paper at the W3C Workshop on Frameworks for Semantics in Web Services, June 9-10, 2005, Innsbruck, Austria. Gruber, T., 1995, “Toward principles for the design of ontologies used for knowledge haring,” International Journal of Human-Computer Studies, Vol. 43, No. 5-6, pp. 907-928. Haller, A., Gomez, J. M. and Bussler, C., 2005, “Exposing semantic Web service principles in SOA to solve EAI scenarios”, International Conference on the World Wide Web (WWW2005), pp. 12-17. Hartung, M. K., 2008, “Analyzing the evolution of life science ontologies and mappings,” In: Proc. of Data Integration in the Life Sciences (DILS), pp. 11-27. Izza, S., Vincent, L. and Burlat, P., 2005, “A unified framework for application integration: An ontology-driven service-oriented approach,” ICEIS 2005, Proceedings of the Seventh International Conference on Enterprise Information Systems, pp. 165-170. Klein, M. and Fensel, D., 2001, “Ontology versioning on the semantic Web,” Int. Semantic

321

Web Working Symposium (SWWS), pp. 75-91. 10. Lein, M., 2004, “Change management for distributed ontologies,” Vrije University Amsterdam, PhD Thesis. 11. Martin, D., 2004, OWL-S, Semantic Markup for Web Services, Technical Note. 12. Plessers, P. T., 2007, “Understanding ontology evolution: A change detection approach,” Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 5 pp. 39-49. 13. Singh, M. P. and Huhns, M. N., 2005, Service Oriented Computing: Semantics, Processes, Agents, Chichester, West Sussex, UK: Wiley. 14. Zablith, F., 2009, “Evolva: A comprehensive approach to ontology evolution,” In Proceedings of the 6th European Semantic Web ESWC, pp. 944-948.

ABOUT THE AUTHORS Karim Baïna is a Professor in ENSIAS (Ecole Nationale Supérieur d’Informatique et d’Analyse des Système) at Mohammed V-Souissi University, Rabat, Morocco. He is also Cooperation Service Responsible at ENSIAS, and Alqualsadi (Enterprise Architecture) research team leader, after being Professor Assistant from 2003 to 2007 at ENSIAS, postdoctoral research Fellow at School of Computer Science and Engineering (CSE), UNSW, Sydney in 2003, and Research Fellow at LORIAINRIA, Nancy, France from 1999 to 2003. His own research interest is in enterprise architecture integration, quality, and governance Salah Baïna is a Professor in ENSIAS (Ecole Nationale Supérieur d’Informatique et d’Analyse des Système) at Mohammed V-Souissi University, Rabat, Morocco. He has obtained his PHD at Nancy University Djamal Benslimane is a Professor at Université Claude Bernard Lyon, France. Head of the Service Oriented Computing Research Team (SOC). Head of the Computer Science department @ IUT, Lyon 1 University.his principal research interests are : we services, databases, interoperability, ontology, context. Soumaya Slimani is a Ph.D graduate student at Mohammed V-Souissi University at ENSIAS (Ecole Nationale Supérieur d’Informatique et d’Analyse des Système), Rabat, Morocco. His research interests are semantic SOA and ontotlogy management. (Received September 2010, revised January 2011, accepted April 2011)