An ontology change management system: an experiment on a health care case study

Transcription

1 An ontology change management system: an experiment on a health care case study Soumaya Slimani 1, Karim Baïna 1, Salah Baïna 1, Martin Henkel 2, Erik Perjons 2 1 ENSIAS, Mohammed V-Souissi University, Morocco slimani.soumaya@gmail.com, {baina, sbaina}@ensias.ma 2 Department of Computer and Systems Sciences, Stockholm University, Sweden, {martinh, perjons}@dsv.su.se Abstract: Numerous ontologies have been developed for life science domains. These ontologies are continuously changing. Thus, it is becoming important to study and to manage these changes in order to keep all dependent ontologies and their related mappings consistent. The aim of this paper is to propose an agent based approach enabling not only ontology and ontology mapping evolution analysis but also to manage their changes. An experiment in health care illustrates the benefits of our approach. We apply our algorithm and implementation prototype p 2 OEManager to eye specialist ontology (ESO) and primary health care ontology (PCO), and particularly, we use the prototype and our ontology agent model to manage some significant changes in the ESO ontology. Keywords: eye specialist ontology, primary health care ontology, ontology evolution, semantic service, multi-agent system. 1 Introduction Ontologies are becoming increasingly important in life sciences. In electronic health care, a major problem is the heterogenity of information systems, which obstructs the exchange of data between them. So, the use of ontologies to describe those systems is essential to obtain interoperability between the systems. Semantic interoperability of these heterogeneous systems can be achieved through an agreement between the underlying ontologies (e.g. by applying RDF, OWL, etc.). In the context of web services, several standards were developed to describe web services semantics, and aid the development of semantic web services (e.g. WSDL-S, WSMO, OWL-S, etc.). We can distinguish two scenarios for web ontology-based applications: (1) distributed systems based on Single Ontology and Multiple Instances of this ontology (we will name this a SOMI approach), and (2) distributed systems based on Multiple Ontologies, and Single or Multiple, Instances of these ontologies (we will name these MOSI and MOMI approaches). Even thought the basic technology for manaing ontologies exists, the management of the ontologies can be complex and time consuming. Due to the rapid development of life science research, ontologies evolve continuously, i.e., they are frequently changing to incorporate new domain knowledge. However, these changes may impact the correctness of future communication using these ontologies because other services are not aware of these changes. Hence, ontology mappings, which allow services to correctly interpret exchanged data, should be

2 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 deal particularly with the versioning and evolution of the same ontology (SOMI), and do not process the evolution of different ontologies, interrelated by mappings and describing different services. In this paper we propose an agent-based algorithm and prototype managing the life cycle of ontologies, as well as the evolution of ontology-related mappings. We apply our algorithm to an eye specialist ontology (ESO) and a primary health care ontology (PCO), and, particularly, we use our ontology agent model and p 2 OEManager prototype to manage some significant changes in the ESO ontology. 2 p 2 OEManager Design and Implementation Overview Fig. 1. shows the general architecture of p 2 OEManager (which stands for peer to peer Ontology Event Manager) consisting of 3 main components: Ontology Manager, Ontology Mapping Manager, and Ontology Agent Manager, which are built on an open Service Layer. Interactions between instances p 2 OEManager peers (i.e. ontology change event messages) are handled through an ontology change communication channel. In fact, p 2 OEManager is neutral regarding the service infrastructures. Thus, services can be either composite services handled within a usual Application Plateform 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 p 2 OEManager within service marshalling/unmarshalling, security, addressing, reliable messaging, routing, and transport standard protocols. Ontology Agent Manager Ontology Manager Ontology Mapping Manager Ontology change communication channel Ontology Agent Manager Ontology Mapping Manager Ontology Manager Service Layer Business communication channel Service Layer Fig. 1. p 2 OEManager Architecture p 2 OEManager components are built on top of technologies from ontology management, agent based approaches, service oriented computing, and change management. As shown in Fig.1., Service layer, which is outside p 2 OEManager, represents services that are described by service ontologies. Those service ontologies are defined by human designers 1 using ontology editors, and those service ontologies are then 1 The terms human designer and user will be interchangeable in the remainder of the paper.

3 monitored by p 2 OEManager. Service dependencies are represented by service ontology mappings defined by human designers by using ontology mapping generators. 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. 2.1 Ontology Manager Ontology Manager is a component that handles, and monitors service ontologies. Each ontology describes one service evolving in the service layer. We consider ontology as a formal specification of a shared conceptualization (with regards to Gruber definition of ontology) [1]. In our context, an ontology consists of: (i) concepts that are organised taxonomically using subsumption relationships (aka. is-a), (ii) properties or relationships that represent interactions types between concepts, and (iii) individuals that are used to represent concrete entities in a domain. A user can process changes on a service ontology via an ontology editor. A service ontology must evolve to adapt to business evolution, and ontology changes can also concern its entities (i.e. ontology components). Ontology Manager will be responsible for monitoring all types of ontology changes through an ontology evolution life cycle. Ontology Manager distinguishes between three types of ontology changes: (1) atomic change (e.g. add a concept, delete a concept), (2) composite change (i.e. a group of atomic changes - rename a concept (i.e. composition of deletion of a concept and adding of a new concept), and (3) complex change (i.e. a sequence of composite change) [8]. Ontology Manager also distinguishes between three levels of changes: (1) structural level change (i.e. a change in the specification), (2) and syntactic level change (i.e. change in the representation), and (3) semantic level change (i.e. a change in the conceptualization) [2]. Ontology Manager monitors and handle ontology evolution through a 6-step life cycle: (1) detection of ontology changes, by a simple version comparison, (2) representation of changes, if it is necessary to store them in an appropriate format, (3) analysis of changes, by checking their direct and indirect effects on the ontology, (4) implementation of changes, there are two methods of change propagation: change is propagated immediately after its implementation or on request (5) propagation of changes to keep dependent objects consistent, (6) validation of changes, user can reject or accept this changes [3] Ontology Mapping Manager Ontology Manager is a component that handles ontologies mappings which are basically descriptions of correspondence relationships between entities of two 2 However, the 6-step ontology evolution life cycle, described above, is not always followed in this order. There are two approaches to verify the consistency of ontology: (1) change is applied first, then we check whether the updated ontology satisfies the consistency constraints or not. (2) For each change, a set of conditions is defined. Consistency is maintained, if the ontology is consistent before the implementation of change (i.e. if the conditions are met). And there are two methods of change propagation: change is propagated immediately after its implementation or on request.

4 ontologies 3. Mappings in our context are used to make exchanges between services syntactically and semantically relevant and understandable. Thus, based on ontology mappings, services can build a more reliable interpretation of all concepts used when exchanging messages with other services. If ontologies evolve, their mappings must evolve too. Ontology Mapping Manager is responsible of managing ontology mapping evolution by adding new correspondences between ontologies existing and changing concepts. 2.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: (i) Initiator Ontology Agent (we will name IOA), when his ontology changed, and (ii) Dependant Ontology Agent (we will name DOA), when an ontology of a service collaborating with his ontology service changed. The IOA/DOA agent model contains three behaviours: (1) a behaviour of a listener to detect change IOA side Algorithm), (2) a behaviour for changes formulation and propagation (IOA side Algorithm), and (3) a behaviour for receiving and processing changes (DOA side algorithm). Below, we explain and illustrate a detailed overview of the interaction between IOA and DOA agents within p 2 OEManager peers instances. Interaction between agents begins when an ontology change. As shown in Fig. 2., the initiator agent (IOA) generates automatically a list of changes. After this, for all dependant agents (DOA) that are observing IOA ontology, the IOA get the mapping between its ontology and the ontology of each DOA, then for all changes two alternatives are possible: Either, (i) the change is related to the mapping between initiator agent and dependent agent ontologies (i.e. IOA and DOA ontologies) : the change is concerning objects that are contained in the ontology mapping, or that are connected to this mapping elements (e.g. sub-class, property, etc.). In this case, the change is translated and encapsulated into a message and sent to all DOA, or (ii) the change is not related to the mapping between initiator agent and dependent agent ontologies: the change is concerning objects that are not contained in the mapping, or that are not connected to some of this mapping elements (e.g. sub-class, property, etc.). In this case, the change is simply ignored because it is considered as not interesting for the DOA receiver and it will not involve communication between the two ontology described services after worth. The interaction between IOA and DOA may concern either an atomic change, or composite/complex change (i.e. a set of changes). When the DOA receives a set of changes, for each change, it has four alternatives as shown in Fig. 3. : either (i) DOA ontology contains syntactically and semantically the added object. In this case, the agent updates the mapping between initiator agent 3 See [4] for a wide overview on ontology mapping techniques state of the art.

5 ontology and dependent agent ontology, or (ii) the added object exists in the dependent agent ontology but does not have the same semantics as the initiator agent ontology object. So, the two agents collaborate to define a common definition of the change (what we call agent negotiation [5]). If negotiations succeed, the DOA agent updates the mapping. If negotiations fail, an alert is sent to the user, or (iii) the added object matches with an object in the dependent agent ontology, but they have different syntax. Then, the DOA updates the mapping and annotates the corresponding object by the added object, or finally, (iv) the added object is a new object for the DOA. Thus, the DOA adds it to his ontology and adds a new correspondence to the ontology mapping. Fig. 2. Detection and propagation of change For more formalisation details of our ontology model, and IOA/DOA algorithms and interaction protocol implemented within our p 2 OEManager Architecture, please refer to our paper [5].

6 2.4 p 2 OEManager Implementation Fig. 3. Change processing p 2 OEManager components are built on a panel of libraries and packages which we have either developed or integrated into p 2 OEManager. We have implemented the IOA and DOA side algorithms. Our proposal presents a solution that can be easily used by service designers and developers within their SOA technical infrastructures and SOBA business solutions. We have studied many alternatives for storing ontologies to be monitored by the Ontology Manager: DAML+OIL, OWL, RDF, RDF (S). We have finally chosen OWL, but other alternatives can be easily integrated to p 2 OEManager. Also, There exist many Ontology editors: OILEd, OntoEdit, Protégé, WebODE, etc. We have chosen to work with Protégé 3.4 ( but other editors may be used since the Ontology Manager is listening to ontology basic file change events before their processing. Concerning the ontology format we have chosen OWL format ( Also, we have studied many alternatives for mapping ontologies to be monitored by the Ontology Mapping Manager: LOM, IF- Map, OMEN, GLUE, FCA-merge, Chimaera, Prompt (Protégé plugin). Our final choice was for Prompt ( that enables ontology versions to be compared, ontologies to be merged, and parts of ontology to be extracted. Concerning the Ontology mapping format, we had the choice between OWL, and OBO, and we have chosen again OWL. Finally, we have studied many alternatives for implementing the Ontology Agent Manager: AgentBuilder, ASL, Bee-gent, FIPA-OS, MOLE, Open Agent Architecture, RETSINA, Zeus, JADE. And, we have finally chosen JADE ( to develop our Ontology Agent Manager.

7 3 Illustration Scenario : The S:tEriks Health Care We illustrate our approach by using a case study from the health care sector. To reduce the complexity we focus on two ontologies in the case study. Both ontologies are used to describe concepts of health care domain. To interrelate the two ontologies, we determine ontology mapping using Prompt plugin in Protégé. Before going into details on the applying the approach, we will introduce the case below. 3.1 The S:tEriks Health Care Case In order to illustrate the approach presented in this paper, we use a health-care case from the REMS project. The main objective of the REMS project was to develop a set of e-services that could be used to create, manage and transfer health care referrals between S:t Erik s eye hospital specialist clinic and primary care units in the county of Stockholm. As referrals are used as a mean to route a patient from a local physician to the correct level of specialist care, the problem domain is a complex mixture of actors, patient information and health care systems. One of the ideas behind the REMS project is that the created e-services will be part of a larger set of e-services supporting all health care units in the county of Stockholm. Having a set of e-services available from different health care providers would enable healthcare systems to be interconnected in order to share information. To achieve this integration, it is crucial for that the services share the same set of concepts. Fig. 4. gives an overview of the handling of referrals in the county of Stockholm using a simplified value model [6]. The value model depicts the main flow of resources between the patient, the primary health care and the eye specialist clinic. The figure is explained below, first, the collaboration between the primary health care and patient are described, then the collaboration between patient and primary health care, and so on. Primary health care unit Initial opinion / diagnosis Referral to specialist Patient Patient fee Information on symtoms Patient fee Information on symtoms Referral, describing the health problems Referral answer with information on symptoms and diagnoses Information on specialist competencies Eye specialist clinic Performed eye-treatment Diagnosis Information on ongoing treatment Fig. 4. Actors and resource exchanges in the S:tEriks health care case.

8 From Patient to Primary Health Care. When a patient experiences an eye health problem, she/he will visit a primary health care provider. The primary health care physician gives an initial opinion about the problems, and if possible decides on a diagnosis. If the patient needs further treatment, the provider refers the patient to an eye care specialist at a specialist clinic who is able to provide advanced treatments. To do this, the primary health care unit creates a referral to an eye specialist, the patient can utilize this referral to get access to advanced treatment. As an input for creating the referral the primary health care unit physician use the patients symptoms, and any output from performed examination at the primary care. The patient also pays a fee to the primary care. If desired, the patient gets a paper copy of the referral. From Primary Health Care to Eye Specialist Clinic The referral is sent from the primary health care to the eye specialist clinic. For the eye specialist clinic, the referral contains important information, such as symptoms, that the eye specialist clinic uses to assess how urgent the patient s treatment is, as well as to plan and allocate resources at the clinic. In order to send the referral to the right clinic the primary care unit needs information on the specialists competencies at each clinic. When the eye specialist clinic has treated the patient, the clinic sends a referral answer back to the primary care unit which is information on symptoms, diagnoses and carried out treatments. From Eye Specialist Clinic to Patient When the patient visits the specialist clinic, she/he will typically receive eye treatments from the clinic. Furthermore the specialists clinic is obliged to inform the patient about the overall progress of the ongoing treatments, and on the reached diagnose. For the remainder of this paper we will focus on information exchange between the primary health care units and the eye specialist clinics. 3.2 Information exchange in the S:t Eriks Case There are important aspects that need to be considered when designing e-services for the information exchange between the primary care and the specialist clinics. In the case of Swedish health services these should follow standards on the international and national levels. One standard that is of particular interest is the Health-Level Seven Reference Model (HL7/RIM) [7]. Moreover, the Swedish National Board of Health and Welfare ( Socialstyrelsen in Swedish) has published a list of standardized health care concepts [8]. However, even given these standards it is still plenty of room for interpretation of the concepts. Furthermore, there is also a need to specialize the concepts/models in order to cover specific details of the eye health care. Thus it is likely that two organizations that follow the standardized concepts/models will end up with two different models that need to be kept synchronized if they are to be able to exchange information. In order to illustrate our approach we will use the S:tEriks health care case as a base for creating a sample that show the applicability of the approach. For this example, we focus on the interconnection of the systems at the primary care units and the systems at the eye specialist clinics. Fig. 5. show the basic ontology that in our

9 example is used on the primary health care units systems. Fig. 6. shows the ontology that in our example is used at the eye specialist side. These ontologies will be the basis for the services that need to interconnect when exchanging referral information. Fig. 5. Primary health care ontology (PCO)

10 Fig. 6. Eye specialist ontology (ESO) Common to both ontologies are the concepts of PATIENT, ROLE, HEALTH PROBLEMS and SYMPTOMS. They also share the concept of REFERAL, which is important for our case. The concepts taken from HL7/RIM is marked with. However, the ontologies also differ in many respects. The mapping presented in the Fig. 7. shows the correspondences between the two ontologies and we can identify that some concepts don t have any correspondences. Fig. 7. Mapping between PCO and ESO When updating ontologies on either side there is a need for synchronization. Thus changes in either the eye specialist ontology (ESO) or the primary care ontology (PCO) need to be reflected on both sides. For the sake of describing our approach we provide four examples of changes, Fig. 8. shows the ESO after processing the following changes: C1 Adding the concepts of EYE_REFERRAL to the ESO. This is needed to handle information specifically related to eye problems. This concept is not present in the PCO. C2 Adding the concept of HEALTH_CARE_ACTIVITY (subclass of ACT) to the ESO. This concept is added to document patients visits at the specialist clinic. The concept of HEALTH_CARE_ACTIVITY can be mapped to the existing concept of HEALTH_CARE_EVENTS in the PCO. C3 Adding the concept of PARTICIPATION to the ESO. This concept exists in the PSO.

11 C4 Adding ORGANIZATIONAL_UNIT to the ESO with an association to CARE_GIVERS in the ESO. ORGANIZATIONAL_UNIT matches syntactically to ORGANIZATIONAL_UNIT in the PCO, but this match is semantically incorrect since only PUBLIC_O can have ORGANIZATIONAL_UNIT in the PCO. Fig. 8. ESO after change 4 Algorithm Application : Process of changes 4.1 Addition of the concept EYE_REFERRAL to the ESO The application of the algorithm in this scenario begins on the Initiator side (ESO agent). First, changes are listed as follow: changeset = < C1=<ADD :Class :EYE_REFERAL: subclassof REFERAL>, C2=<ADD:ObjectProperty:EYE_SYMPTOMS:<Domain :EYE_REFERAL, Rang:SYMPTOMS >> >

12 Then changes are classified according to their relationship with the mapping. All changes are sent to PCO agent. The syntactic and semantic search will return false. Because all added objects are new objects for the PCO. Thus the agent chose the fourth case. So, C 1, and C 2 are added to PCO and the Mapping is updated. ( ESO. C 1 PCO.C 1 and ESO. C 2 PCO. C 2 ). Thus, the Eye Specialist Clinic service can communicate with the Primary Health Care service using the concept "EYE_REFERAL". 4.2 Addition of the concept HEALTH_CARE_ACTIVITY in ESO After adding HEALTH_CARE_ACTIVITY concept as subclass of ACT in the ESO. ESO agent represents this change as follow: changeset = < C1=<ADD:Class:HEALTH_CARE_ACTIVITY:subclassOf ACT> > This change is sent to PCO agent. PCO agent starts processing this change and the syntactic search will return false, but the semantic search will return true. Because HEALTH_CARE_ACTIVITY can be mapped to the existing concept of HEALTH_CARE_EVENTS in the PCO. Thus the PCO agent chose the third case and: 1. Annotate the concept HEALTH_CARE_EVENTS concept by adding Rdfs:seeAlso HEALTH_CARE_ACTIVITY annotation. 2. Update mapping by adding HEALTH_CARE_EVENTS HEALTH_CARE_ACTIVITY correspondence. 4.3 Addition of the concept PARTICIPATION to the ESO After adding the concept PARTICIPATION in the ESO. ESO agent represents this change as follow: changeset = <C1=<ADD:Class:PARTICIPATION:subclassOf Thing> > This change is sent to PCO agent. PCO agent starts processing this change and the syntactic and the semantic search will return true. Because this concept exist in the PCO. Thus the PCO agent chose the first case and update the mapping by adding ESO.PARTICIPATION PCO.PARTICIPATION correspondence. 4.4 Addition of the concept ORGANIZATIONAL_UNIT to the ESO The concept ORGANIZATIONAL_UNIT is added with an association to CARE_GIVERS in the ESO. ORGANIZATIONAL_UNIT matches syntactically to

13 ORGANIZATIONAL_UNIT in the PCO, but this match is semantically incorrect since only PUBLIC_O can have ORGANIZATIONAL_UNIT in the PCO. ESO agent represents this change as follow: changeset = < C1=<ADD:Class:ORGANIZATIONAL_UNIT:subclassOf Thing> C2=<ADD:ObjectProperty:ORG_CG:<Domain:ORANIZATIONAL_UNIT, Rang:CARE_GIVERS>> > These changes are sent to PCO agent. The concept ORGANIZATIONAL_UNIT in PCO has not the same semantic as ORGANIZATIONAL_UNIT in ESO. In this case the PCO agent chose the second case in the algorithm. PCO agent calculates a definition for ORGANIZATIONAL_UNIT as follow: <<Class:PCO. ORGANIZATIONAL_UNIT: subclass of Thing> <ObjectProperty: PCO.OU_HAS :Domain : PCO.RGANIZATIONAL_UNIT, Rang :PCO.PUBLIC_O > > PCO Agent sends this definition to ESO agent, which calculates a new definition: <<Class:PCO. ORGANIZATIONAL_UNIT: subclass of Thing> <ObjectProperty: PCO.OU_HAS :Domain : PCO.RGANIZATIONAL_UNIT, Rang :PCO.PUBLIC_O > <Class:ESO. ORGANIZATIONAL_UNIT:subclass of Thing> <ObjectProperty: ESO.OU_HAS :Domain : ESO.ORGANIZATIONAL_UNIT, Rang :ESO.CARE_GIVERS > > The last matching ESO.CARE_GIVERS PCO.PUBLIC_O introduces a conflict in the definition of CARE_GIVERS. Indeed, as we have already in the mapping that ESO.PUBLIC_O PCO.PUBLIC_O and ESO.PUBLIC_O is a subclass of CARE_GIVERS, this can be a source of errors. Then, the agent sends an alert message to the user. User can modify the mapping and the ontology or validate any of the definitions contained in the negotiations exchange. In this example, our algorithm allows services in the eye specialist clinic and in the primary care provider to be aware of evolution in other services. Agents take the necessary decisions to maintain a reliable exchange of data between those entities by applying the necessary changes to both mapping and ontologies. But if the agent detects a conflict it only informs the user of the problem.

14 5 Related works The ontology evolution and change management has been addressed by many research. Klein [9,10] investigated the versioning of ontologies, [11] define Change Definition Language (CDL) to specify changes. In [12], a patterns-based ontology evolution approach called Onto-Evoal is presented. In [13], the proposed solution is called Evolva, a Framework for ontology evolution which explores different sources of information to evolve ontology. This previous work is complementary to ours and does neither consider service ontology nor related mapping evolution. Furthermore, the evolution of ontology-related mappings has been analyzed in [14]. But we propose an evolution model for multi-ontology system when ontologies are different and not only for instance. When ontologies are considered as an ontology instances, the source ontology has the semantics of the dependent ontologies (because they are instances of the source ontology). So, ontology evolution will require applying the same changes on the dependent ontologies. Note also that in the case of different ontologies, mapping between ontologies must be managed in parallel. 6 Conclusion and Discussion Interconnecting services is a complex task. A part of the complexity comes from the need to have a common, shared view of the information, an ontology. Even thought there are domain specific reference models to follow when constructing these ontologies, these reference models do not cover all the details that are needed in individual cases. Thus, as argued in this paper, there is a need for approaches that helps to overcome the differences that exist between service ontologies, and to manage the possible future evolution of the ontologies. The approach proposed in this paper is suitable for ontology evolution management in distributed and heterogeneous environments. The aim is to provide a flexible way to partially automate the process of ontology evolution management. The approach consists of software agents that manage the changes in ontologies by utilizing an algorithm based on syntactic and semantic searches. The software agents represent each of the services involved, and their respective ontologies. Syntactic and semantic searches are used to finds mappings between newly introduced changes in the ontologies. While syntax searches covers basic changes in the ontologies, the semantic searches utilizes semantic databases to find more complex mappings. The algorithm covers the basic changes in the initiator side and treats the Add operation at the receiver side. We have implemented and tested the initiator side algorithm and part of the receiver side algorithm. To illustrate our approach we applied it to a health care case from the County of Stockholm in Sweden. The case study highlighted some of the main benefits of the approach. Firstly, it was shown that initial differences in the services ontologies of the primary care and the eye specialist care could be overcomed by defining mappings between the ontologies. Secondly, and more important, we showed how the approach could be used to propagate changes to the eye specialist ontology into the primary

15 care ontology. Thus, even thought 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 to the logic of the running software services. Changes in the ontologies might simply require an update of the logic in the services. Furthermore, there is a need to extend the algorithms to include different types of changes in our algorithms (removal, update, etc...). This paper is thus a first step to lay the groundwork for future research. Acknowledgements. This work is partially funded by the Swedish Research Council as a part of the collaboration between DSV (Stockholm University, Sweden) and ENSIAS (Mohammed V Souissi University, Morocco) within the MENA program. References [1] Gruber, T., Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal of Human-Computer Studies, 43(5-6), , [2] LUONG, P.H., Gestion de l'évolution d'un web sémantique d'entreprise, PhD thesis, l'ecole des Mines de Paris, [3] Stojanovic, L., Maedche, A., Motik, B., and Stojanovic, N., User-driven ontology evolution management, In European Conference on Knowledge Engineering and Management, p , [4] Jiayi, P., Utilizing Statistical Semantic Similarity Techniques for Ontology Mapping with Applications to AEC Standard Models, Tsinghua Science and Technology, October [5] Slimani, S., Baïna, S., Baïna, K., Agent-based Architecture for Service Ontology evolution Management, the 22 nd Inernational Conference on Software Engineering and Knowledge Engineering (SEKE 10), The 22dInternational Conference on Software Engineering and Knowledge Engineering, San Francisco Bay, USA [6] Henkel, M., Johannesson, P., Perjons, E., Zdravkovi, J., "Value and Goal Driven Design of E-Services", The IEEE International Conference on e-business Engineering (ICEBE'07), Hong Kong, China, October [7] Health Level Seven International, ISO/HL :2006 Health informatics Reference information model (HL7/RIM), available at [8] The Swedish National Board of Health and Welfare, Health Care Dictionary, available at [9] Klein, M., Fensel, D.: Ontology versioning on the Semantic Web. In: Proc. Int. Semantic Web Working Symposium (SWWS) (2001) [10] Klein, M.: Change Management for Distributed Ontologies. PhD thesis, Vrije Universiteit Amsterdam (2004). [11] Plessers, P., Troyer, O., and Casteleyn, S., Understanding ontology evolution : A change detection approach, Web Semantics : Science, Services and Agents, on the World Wide Web , 2007 [12] Djedidi, R., and Aufaure, M.A., Patrons de gestion de changements OWL, IC [13] Zablith, F., Evolva : A Comprehensive Approach to Ontology Evolution. In Proceedings of the 6th European Semantic Web Conference (ESWC) PhD Symposium LNCS eds. L. Aroyo et al., Springer-Verlag, Berlin, Heidelberg, pages , [14] Hartung, M., Kirsten, T., Rahm, E.: Analyzing the evolution of life science ontologies and mappings. In: Proc. of DILS. (2008) 11 27