Of great importance to the efficient use of an ontology is the ability to easily effect change [9]. This paper presents an approach toward automating a method for instance data to be kept up to date as an ontology evolves.
As computers become more ubiquitous and the information they attain and
store becomes vast, the benefit gained from formally representing that
information grows. Ontologies are one of the key technologies which strive to give
information well-defined meaning. This, in turn, allows computers and people
to work more cooperatively [
While there are many applications which help develop and create ontologies,
there are still very few which aid or facilitate the evolution of an ontology [
A change in an ontology requiring dependent ontologies to be updated is a common problem. IBM’s Design Manager is a collaborative design management software. It works with domains which are specified using ontologies to store, share, search and manage designs and models. The work presented in this paper was inspired, in part, by work IBM has done and problems IBM has encountered while developing Design Manager. Figure 1 helps describe the problem being addressed.
In Figure 1, there exists an original ontology (O), an evolved or updated ontology (O0) and a set of dependent ontologies (I1; I2; :::; In). For all j; Ij imports O and contains only individuals and facts asserted about those individuals.
Notice that classes and properties are kept separate from individuals. In an
ontology, an individual is a resource which is an instance of a class and cannot
contain any other resource (individuals may be related to one another through
properties). Through this seperation, classes and properties are analogous to
metamodels or schema while individuals are analogous to objects or data.
Separating class definitions and property definitions from individuals is common
practice when designing and building ontologies [
For any change that is made to O, there may exist an arbitrary number of j such that Ij is inconsistent. Furthermore, it is possible that there exist an a and a b such that a change in O will make Ia and Ib inconsistent for unrelated reasons (the axioms in O0 that make Ia inconsistent are distinct from the axioms in O0 that make Ib inconsistent). It is the hope that for all j, a transformation can coevolve or migrate Ij into a new ontology, Ij0 , such that Ij0 imports O0 and remains consistent. In Figure 1, the arrow labeled ‘transformation’ represents the portion of this problem for which we propose a unique solution which automates the transformation process.
Currently, this work is often done manually, or put off entirely because of the
effort required to devise and implement these sorts of migrations. Due to the
complexity possible in an ontology and the semantic ambiguity behind changes
being made, it is not possible to automatically generate the transformation that
performs the migration for individuals in dependent ontologies. Since
ontologies may be too complex for a user to fully comprehend and changes may be
ambiguous and therefore difficult for a computer or algorithm to deal with [
To help automate the migration process, we aid the user creation of a transformation which unambiguously defines how to perform a migration for any possible dependent ontology. We also develop a set of tools and techniques aimed at making it increasingly easier for users to create these transformations. 2
The approach discussed here breaks the process into three phases which are incorporated into a single tool called Oital-T.
The first phase deals with comparing the two ontologies (O and O0). While not strictly necessary for the development of the transformation, an understanding of the difference between O and O0 allows Oital-T to make suggestions and help the user to make choices regarding the transformation.
The second phase is the creation of the transformation itself. The transformation is authored in a language called Oital. Oital-T acts as an integrated development environment for Oital, allowing the syntax to be easier to learn and manipulate. The end goal of this entire process is to create a transformation written in Oital. This is the transformation that can then be run any number of times to migrate instances from O to O0.
Finally, the last phase involves analyzing the transformation. This phase of the process can be used to indicate which parts of the transformation may require correction or further development.
In OWL, the separation of class and properties from individuals is expressed using axioms and facts. In relation to Figure 1, I1 through In are all a series of facts with an inclusion reference to O while O and O0 both consist of a series of axioms (possibly with inclusion references to other ontologies).
Axioms may either restrict or add to an ontology. Restrictive axioms add further clarification to the information encoded in an ontology (such as holdsVolume exactly 1 in Figure 2) while additive axioms broaden the scope of the information (such as the creation of a new class).
Figure 3 depicts three regions in which an axiom may exist. Region 1 describes axioms which can be found in O and not in O0 (deleted axioms), region 2 describes those axioms which can be found in both O and O0 (unchanged axioms), and region 3 describes axioms which can not be found in O but can be found in O0 (new or added axioms).
Axioms may influence one another. In Figure 2, the kitchen ontology has an axiom (A) stating that cutlery is the domain of the property holdsVolume. It also has the axiom (B) that there is a specific anonymous restriction class which contains only individuals that hold exactly one amount of volume. Axiom B is influenced by axiom A because a change in A is axiomatically a change in B as well. For any axiom, C, the axiom and all other axioms it is influenced by is denoted as C and called that axiom’s context.
Table 1 gives an overview of how axioms are labeled while analyzing O and O0. If there exists axiom A such that its context, A , is entirely in Region 3, then A cannot be the cause of any inconsistencies. Specifically, if Ij is consistent with respect to O, then any inconsistencies Ij has with respect to O0 cannot be due to axiom A. This means that aspects of the updated or evolved ontology which are entirely unique to the updated ontology are not of concern for the creation of a transformation. Similarly, for any A such that A is entirely in region 2, A cannot cause inconsistencies. This means that those parts of the original and updated ontologies which remain unchanged are not of concern either.
Axioms found in Region 1 may not, by default, be ignored. If the axiom is restrictive, such as the restriction class in Figure 2, then its removal cannot create an inconsistency and is considered OK. If, however, the axiom is additive, then its removal may create inconsistencies. For example, removing the fork is a subclass of cutlery axiom from the kitchen ontology in Figure 2 would result in
Region 2
Region 3 Region 1 & 2 Region 2 & 3
OK Should Investigate Must Investigate
OK
OK Must Investigate Should Investigate any facts which state that an individual fork holds a specific volume becoming inconsistent.
If, for a given axiom, A, the context, A , straddles two regions, then A is very likely to be semantically important. This means that even if the axiom may not cause inconsistencies, it may still be of interest to a user creating the transformation. Generally A having elements in region 1 and 2 suggests that a part of the ontology was removed but in such a way that the updated ontology had to be restructured to accommodate the removal (such as the removal of a class from a hierarchy). Similarly, A having elements in both region 2 and 3 suggests that a part of the ontology that has been added affects parts of the already existent ontology (Such as the creation of a new restriction class in a class hierarchy). Some of these changes may cause inconsistencies and are treated as more important, but all instances of these are shown to the user.
The following example illustrates how this analysis in performed. Consider the kitchen ontologies from Figure 2. The following is information that can be gathered from an analysis of these two ontologies. The spork class is new and therefore part of Region 3 from Figure 3. Its context includes the fork and spoon classes because of the subclass property. Because of the spoon, its context also involves the anonymous restriction class as well as the property holdsVolume. Because of holdsVolume, its context involves the cutlery class. Since spork is from Region 3, and it has a context which encompasses Region 2, this change straddles Region 2 & 3. The creation of a named class is additive, so (as shown in Table 1) this is unlikely to create an inconsistency during migration, but should still be brought to the user’s attention as it may be important semantically. 2.2
A transformation that facilitates a migration of individuals from one ontology to another must, in some way, encode all the information that is still lacking after the two ontologies have been fully analyzed. While an analysis of the original and evolved ontology can reveal how the original ontology has been changed, it cannot uncover the reasoning behind any given change.
A comparison of O and O0 may uncover a difference for which there are many possible reasons. Consider the analysis of the evolution depicted in Figure 2, to know how to proceed, it is import to know why the spork class was created. If, for example, the class was added because of the discovery of a spork, then the migration can simply ignore this difference. If, on the other hand, the spork class was created because there were individuals within the class fork which held a volume, then a migration should take those forks which have the holdsVolume property and migrate them to the new spork class.
This very simple example illustrates why user interaction is required for the creation of the migration transformation. To express this transformation, we developed a domain specific transformation language called Oital. 2.2.1
Ontology Individual Transformation Authoring Language Oital is a transformation language designed specifically for specifying the migration of individuals who are conformant to O such that they become conformant to O0. Currently, SPARQL update is used to perform tasks which alter an ontology. SPARQL update, however is an update language for RDF graphs. To use SPARQL update to effect change on an ontology requires an understanding of how ontologies are stored as RDF triples. Ontologies which are not stored in an RDF triple store must first be converted to one before SPARQL update can be used.
Oital alleviates these issues by using ontology concepts directly in the language (thus abstracting away from RDF). Instead of querying triples in a triple store the way SPARQL update does, Oital queries classes and properties in the ontology.
The current Oital compiler compiles Oital code into SPARQL update code. This means that ontologies queried using Oital must still be stored in RDF. It is, however, possible for Oital to be compiled in such a way that it can efficiently query and alter other formats as well. Details concerning the syntax and structure of Oital have been omitted due to space requirements.
To help make Oital easier to adopt, the syntax was heavily influenced by
the Manchester OWL syntax. Oital transformation classes are defined using
a syntax similar to the way OWL classes are defined. As the Manchester Owl
Syntax has been adopted by World Wide Web Consortium [
So far, no extensive evaluation of Oital has been conducted. However, preliminary results suggest that it is a convenient means of expression for the kind of ontology migration transformations we target. 2.3
Analyzing the created transformation is a helpful step toward inspecting if the
transformation that has been created is correct. Currently, the only forms of
analysis supported by Oital’s IDE (Oital-T) are traditional testing and a form
of abstract interpretation which executes the transformation in some abstract
fashion while collecting specific information [
We have developed and implements an abstract interpretation of Oital to track class membership. For instance, if after running an abstract interpretation of the transformation, the result shows that a specific class – such as spoon – is empty, then there exists no possible input such that any individuals from that input will have rdf:type spoon. Depending on the intent of the transformation, this may or may not be a desired result.
Traditional testing, abstract interpretation, and – in future – other forms of analysis may be used throughout the transformation authoring process in order to ease the development of complex transformations with fewer errors. 3
The migration problem, as presented here, closely resembles the data migration
problem found in database work [
Using a transformation language is an approach currently being used to solve
the co-evolution problem. Languages such as ATL [
Not much work has been done on the migration problem for ontologies as
has presented here, but similar work can be found concerning ontology evolution
management. Much of the work done in this field, such as [
In this paper, we have described an approach to facilitate the development of transformations that migrate individuals from the original ontology to an updated one. The approach is based on 1) differencing the ontologies, 2) transformation development using a novel, domain-specific language, and 3) analysis.
There is, however, still much outstanding work to be done. Along with continued development on Oital’s IDE (Oital-T), we will attempt to identify transformation patterns and additional analysis that are scalable, yet still provide developers with useful information.
Aiding the development process will be sufficiently complex case-studies which shall help show the usability and capability of the approach presented in this paper. IBM has given us multiple versions of an ontology encoding of the UML specification along with a series of UML models stored as ontologies. IBM has also offered access to a domain with IBM’s Design Manager which may benefit from this approach.