Home

An Ontology Versioning Tool

Source:

WP2: Ontology Management, Deliverable nr. D2.4 (2006)

URL:

http://www.omwg.org/tools/versioning/v1.0/FactSheet.html

Keywords:

web service ontology versioning

Abstract:

The Semantic Web [Berners-Lee, 1999] aims to make data accessible and understandable to intelligent machine processing. Semantic Web (SW) services additionally aim to do the same for services available on the SW, targeting automation of service discovery, composition and invocation. For describing SW services, we need to elicit the so-called “domain ontologies” (usually in a distributed manner) which formalise the knowledge necessary for capturing the meaning of the services and the exchanged data. In other words, ontologies are supposed to make access to information more effective by not just providing a set of linked documents, as on the web, but by providing a collection of knowledge repositories with meaningful content and additional logic structure. Particularly, in the SW setting, evolution is a persistent problem through the whole ontology life-cycle, i.e. ontology elicitation and ontology application. The elicitation of these ontologies is conducted massively in a distributed fashion, and is governed by a combination of ontology engineering processes such as: (i) lexical disambiguation of terms into concepts [De Leenheer and de Moor, 2005], (ii) “contextualisation” of existing definitions for particular purposes by refinement, restriction, projection, etc. Commonly agreed concepts and processes might be slightly nuanced according to the pragmatical relevance of the respective parties. This leads to a diverging range of (subjective) views (versions). Finally, (iii) ontology integration is indispensable when converging or combining subontologies [Euzenat et al., 2001; Kalfoglou and Schorlemmer, 2005]. This results in a sequence of transformations and versions that expand, contract and revise the ontology; even after deployment. Ontology Engineering Methodology All these processes characterising ontology engineering on the level of the Semantic Web show that ontology reuse is not a trivial copy-paste. Moreover, a tool set supporting these processes is not sufficient. Albeit autonomy is an important caveat for the success of the Semantic Web, humans still play an important role in the interpretation and negotiation of meaning during the elicitation and application of ontologies [de Moor and De Leenheer, 2006]. A viable ontology engineering methodology requires supporting domain experts in gradually analysing, building and managing increasingly complex versions of ontological elements and their converging and diverging interrelationships. Hence, such a methodology orchestrates the above mentioned processes. Ontology Management This imposes strong requirements on an ontology (versions) management infrastructure, which should not be limited to the persistent identification, storage, and versioning of versions, such as required for a classical library system [Ding and Fensel, 2001]. On the contrary, we pose the additional requirement of a sound and complete set of operators to alter, access, and select from the ontologies. Different resolution strategies are presented to the knowledge engineer when during evolution the ontology is brought into a presumed inconsistent state. Furthermore, there should be a way to describe ontologies with meta-information, and express dependencies (in terms of e.g., change logs or mappings) between ontologies that result from particular OE processes such that alternative definitions can possibly be disambiguated properly [De Leenheer et al., 2006 ; de Moor and De Leenheer, 2006]. Such an infrastructure increases the power of the ontology engineering processes on top of it. E.g., three-way merging of two ontologies is much straightforward: if there is a common origin and this origin is known, or can be read in terms of the correlations. Furthermore, a management framework is indispensable during the application of ontologies, where (autonomous) agents representing multiple stakeholders, have multiple views on multiple ontologies. The availability of this contextualised knowledge is critical, as these agents are expected to collect the right bits and pieces of meaning for correctly interpreting web services. Web Service Ontology Versioning The knowledge representation model on which we will define an evolution framework is the Web Services Modelling Language (WSML) [de Bruijn et al., 2005]. A WSML ontology consists of the conceptual part (subset from WSMO conceptual model) modelling the ontology; and a logical expression part (in some logical language); the latter used to refine/constrain the conceptual part. One of WSMO's central conceptual elements to change, viz. a concept, is presented as a frame defined by its superconcepts and attribute declarations. As already mentioned, to translate evolution to an interpretable formal specification, a designated sound and complete toolbox of consistency-preserving change operators needs to be designed. This is straightforward on the conceptual part as much related work in data schema evolution can be adopted; however evolving the logical part boils down to replacing the whole definition, and checking the consistency of the new one. The most trivial evolution process might be problematic: a change at the upper level facet of the ontology may have cascading effects in the bottom-level facets (that include the former) and committing applications [Stojanovic, 2004]; the deprecation of a concept raises alternative strategies what to do with its orphaned subconcepts and instances, etc. Summarising, in order to get a clear overview, a set of semantics must be specified for each of our change operators. Furthermore, as none of the known techniques we consider to reuse is model-independent, we must adapt them to the specific inherent properties of WSML. The ontology management (OM) we envision in the perspective of the SW is not limited to revising and managing ontology versions. The compatibility between different versions is as important, hence we also focus our attention on alignment, losing as little information as possible. Especially in the SW setting, not all resource providers will commit to the most recent ontology version. Goals of this Deliverable Our work has four aspects. First, we do an analysis of versioning requirements; second, we need to adapt the existing state-of-the-art data schema and ontology evolution and versioning research for the particular case of the Web Services Modelling Language (WSML) ontologies. Third, due to their relatedness, we extend these adapted existing versioning techniques to support at least partial automatic generation of transformation between ontology versions. Such transformations are necessary for interoperability between deployments of the different versions, a scenario that the Semantic Web practically guarantees [Klein, 2004]. From the change log, WSML ontology mappings [Scharffe, 2005] between the old and new version can be generated. Finally four, we test whether the implemented requirements are sufficient to support versioning-intensive tasks such as collaborative elicitation. To investigate the latter we have to define precisely what we mean by collaboration [Curtis, 1992; Domingue, 1998; Sure et al., 2002], as it is oftenly confused with other concepts such as concurrent access, and multi-user support [Martín-Recuerda, 2004]. The latter two are necessary, but should be complemented with tools that provide collaborative facilities that contribute to generating a virtual environment where people can analyse and share their ideas, manifested by ontologies; and where norms and responsibilities govern the dynamics. The basic infrastructure therefore is a repository of multiple concurrent ontologies and transformations (i.e. change log and mapping for each) as first-class citizens, each tagged with appropriate meta-information that creates a contextualisation in order to optimise querying. Purpose of this Document This document elaborates on the requirements and theory notes of the versioning tool being developed as part of the ontology management framework of WP2. Finally, presents the implementation plan to be followed, presenting which of the requirements are to be developed until December 2004 (M12), June 2005 (M18), June 2006 (M30) and until the end of the project, i.e. December 2006 (M36). This document is accompanied by the implementation fact sheet, and a user manual. For some theory notes we refer to the following (published) articles, declared as DIP disseminations: -A survey of database schema evolution and transformations [De Leenheer, 2004b] -Managing and Revising Multiple Ontology Versions in a Possible Worlds Settting [De Leenheer, 2004] -Context-driven Disambiguation in Ontology Elicitation [De Leenheer and de Moor, 2005] -Context Dependency Management in Ontology Engineering [De Leenheer et al., 2006 -DOGMA-MESS: A Meaning Evolution Support System for Interorganizational Ontology Engineering [de Moor and De Leenheer, 2006] The list of requirements we specify reflects a weighted intersection of use case partner tool demands and absolute research aims. For the design of these requirements we basically chose from a palette of existing approaches from the related fields, and combined them for devising new methods. The functionality provided will be integrated as part of the ontology management suite developed in D2.6. It heavily depends on D2.3 which facilities the access to the storage layer and the reasoning support required.