A Component-Based Framework For Ontology Evolution

TLDR: It is shown how different representations in the framework are related by describing some techniques and heuristics that supplement information in one representation with information from other representations, which is the kernel of the framework.

Abstract: Support for ontology evolution becomes extremely important in distributed development and use of ontologies. Information about change can be represented in many different ways. We describe these different representations and propose a framework that integrates them. We show how different representations in the framework are related by describing some techniques and heuristics that supplement information in one representation with information from other representations. We present an ontology of change operations, which is the kernel of our framework. 1 Support for Ontology Evolution Ontologies are increasing in popularity, and researchers and developers use them in more and more application areas. Ontologies are used as shared vocabularies, to improve information retrieval, or to help data integration. Neither the ontology development itself nor its product—the ontology— is a single-person enterprise. Large standardized ontologies are often developed by several researchers in parallel (e.g. SUO1 [9]); a number of ontologies grow in the context of peer-to-peer applications (e.g. Edutella [5]); other ontologies are constructed dynamically [2]. Successful applications of ontologies in such uncontrolled, de-centralized and distributed environments require substantial support for change management in ontologies and ontology evolution [7]. Given an ontology O and its two versions, Vold and Vnew, a complete support for change management in an ontology environment includes support for the following tasks.2 Data Transformation: When an ontology version Vold is changed to Vnew, data described by Vold might need to translated to bring it in line with Vnew. For example, if we merge two concepts A and B from Vold into C in Vnew, we must combine instances of A and B as well. http://suo.ieee.org/ Note that Vnew is not necessarily a unique replacement for Vold. There might be several new versions based on the old version, and all of them could exist in parallel. The labels are just used to refer to two versions of an ontology where Vnew has evolved from Vold. Data Access: Even if data is not being transformed, if there exists data conforming to Vold, we often want to access this data and interpret it correctly via Vnew. That is, we should be able to retrieve all data that was accessible via queries in terms of Vold with queries in terms of Vnew. Furthermore, instances of concepts in Vold should be instances of equivalent concepts in Vnew. This task is a very common one in the context of the Semantic Web, where ontologies describe pieces of data on the web. Ontology Update: When we adapt a remote ontology to specific local needs, and the remote ontology changes, we must propagate the changes in the remote ontology to the adapted local ontology [8]. Consistent Reasoning: Ontologies, being formal descriptions, are often used as logical theories. When ontology changes occur, we must analyze the changes to determine whether specific axioms that were valid in Vold are still valid in Vnew. For example, it might be useful to know that a change does not affect the subsumption relationship between two concepts: if A v B is valid in Vold it is also valid in Vnew. While a change in the logical theory will always affects reasoning in general, answers to specific queries may remain unchanged. Verification and Approval: Sometimes developers need to verify and approve ontology changes. This situation often happens when several people are developing a centralized ontology, or when developers want to apply changes selectively. There must be a user interface that simplifies such verification and allows developers to accept or reject specific changes, enabling execution of some changes and rolling back of others. This list of tasks is not exhaustive. The tools that exist today support these tasks in isolation. For example, the KAON framework [10] supports evolution strategies, allowing developers to specify strategies for updating data when changes in an ontology occur. The SHOE versioning system specifies which versions of the ontology the current version is backward compatible with [3]. Many ontology-editing environments (e.g., Protege [1]) provide logs of changes between versions. While these tools support some of the ontologyevolution tasks, there is no interaction or sharing of information among the tools. However, many of these tasks require the same elements in the representation of change. Imple-