Finding and specifying relations between ontology versions Michel Klein1 and Atanas Kiryakov2 and Damyan Ognyanoff3 and Dieter Fensel4 Abstract. Interoperability between different existing ontologies is These links can be used to re-interpret data and knowledge under import to leverage the use of ontologies. However, the interoperabil- different versions. The ontologies and their relations together form a ity between different versions of ontologies is at least as important. web of ontologies. The specification of these links is thus very im- Especially when ontologies are used in a distributed and dynamic portant. context as the Web, we can expect that ontologies will rapidly evolve In this paper, we present a web-based system that supports the and thus may cause incompatibilities. This paper describes a system user in specifying the conceptual relation between version of con- that helps to keep different versions of web-based ontologies inter- cepts. The system, called OntoView, also maintains those links, to- operable. To achieve this, the system allows ontology engineers to gether with the transformations between them. It use them to provide compare versions of ontology and to specify the conceptual relations a transparent interface to different versions of ontologies, both at a between the different versions of concepts. Internally, the system specification level as at a conceptual level. It can also export the dif- maintains the transformations between ontologies, some meta-data ferences between versions as separate “mapping ontologies”, which about the version, as well as the conceptual relation between con- can be used as adapters for the re-interpretation of data and other cepts in different versions. This paper briefly describes the system, ontologies. The goal of this system is not to provide a central reg- presents the mechanism that we used to find and classify changes in istry for ontologies, but to allow ontology engineers to store their RDF-based ontologies, and discusses how this may be used to spec- versions and variants of ontologies and relate them to other (pos- ify relations between ontologies that improve their interoperability. sibly remote) ontologies. The resulting mapping relations between versions can also be exported and used outside the system. Most of the ideas underlying the versioning system are not de- 1 ONTOLOGY EVOLUTION THREATENS pending on a specific ontology language. However, the implemen- INTEROPERABILITY tation of specific parts of the system will be dependent on the used ontology language, for example the mechanism to detect changes. Ontologies have become popular because of their promise of knowl- Throughout this article, we will use DAML+OIL5 [8, 9] and RDF edge sharing and reuse [10]. Interoperability between ontologies is Schema (RDFS) [7] as ontology languages. These two languages are an important issue, because the reuse of knowledge often implies that widely considered as basis for future ontology languages for the Web. different existing ontologies are used together. This requires that the The rest of the paper is organized as follows. In the next section, knowledge represented in the ontologies is not conflicting. However, we discuss some issues about update relations between ontologies. In ontology interoperability is not only important between different ex- section 3, we give an overview of the versioning system and describe isting ontologies, it is also an issue between different versions of an its the main functions. Section 4 describes the main feature of the ontology. This is especially relevant when ontologies are used in the system: comparing ontologies. In that section, we explain the mech- context of the Semantic Web [5]. anism we used to find changes in RDF-based ontologies and present In this vision, ontologies have a role in defining and relating con- some of the rules that we used to encode change types. Finally, we cepts that are used to describe data on the web. The distributed and conclude the paper in section 6. dynamic character of the web will cause that many versions and vari- ants of ontologies will arise. Ontologies are often developed by sev- eral persons and continue to evolve over time. Moreover, domain 2 THE UPDATE RELATION BETWEEN changes, adaptations to different tasks, or changes in the conceptu- ONTOLOGIES alization might cause modifications of the ontology. This will likely cause incompatibilities in the applications and ontologies that refer There are three important aspects to discuss when considering an to them, and will give wrong interpretations to data or make data update relation between ontologies. First, this is the difference be- inaccessible [11]. tween update relations and conceptual relations inside an ontol- To handle ontology changes, a change management system is ogy. needed that keeps track of changes and versions of ontologies. More- Ontologies usually consist of a set of class (or concept) definitions, over, it is necessary to maintain the links between the versions and property definitions and axioms about them. The classes, properties variants that specify the relations and updates between the versions. and axioms are related to each other and together form a model of 1 Vrije Universiteit Amsterdam, michel.klein@cs.vu.nl a part of the world. A change constitutes a new version of the on- 2 OntoText, Sofia, Atanas.Kiryakov@sirma.bg tology. This new version defines an orthogonal relation between the 3 OntoText, Sofia, damyan@sirma.bg 4 Vrije Universiteit Amsterdam, dieter@cs.vu.nl 5 Available from http://www.daml.org/language/ definitions of concepts and properties in the original version of the hand, a natural language definition of a concept might change, e.g. ontology and those in the new version. This is depicted in Figure 1. the new definition of “chair” might exclude reclining-chairs” without a logical change of the concept. The intention of a change is made explicit by categorizing them into the following categories [16]: • conceptual change: a change in the way a domain is interpreted (conceptualized), which results in different ontological concepts or different relations between those concepts; • explication change: a change in the way the conceptualization is specified, without changing the conceptualization itself. A change cannot be automatically classified as belonging to one of these categories, because it is basically a decision of the modeler. However, heuristics can be applied to suggest the effects of changes. Figure 1. Orthogonal relations between classes in two version of an ontol- We will discuss that later on. ogy (dashed arrows) A third, somewhat different, aspect of an update is the packaging of changes, i.e., the way in which updates are applied to an ontol- The relations between concepts inside an ontology, e.g. between ogy. This is an important practical issue for the development of an class A and class B, is thus a fundamentally different relation from ontology change management system. the update relation between two versions of a concept, e.g. between We can distinguish two different dimensions with respect to the class A1.0 and class A2.0 . In the first case, the relation is a purely packaging of the change specification. One dimension is the gran- conceptual relation in the domain; in the second case, however, the ularity of the specification: this can be either the level of a single relation describes meta-information about the change of the concept. “definition” or the level of a “file” as a whole. Nevertheless, two version of a concept still have some conceptual The second dimension is the method of specification. There are relation. This relation, however, is not determined by the update it- several methods thinkable: self, but accompanying information of an update relation. There are • a “transformation specification”: an update specified by a list of other characteristics of an update relation, too. We distinguish the change operations (e.g., add A, change B, delete C); following properties that can be associated with an update relation: • a “replacement”: an update specified by replacing the old version of a concept or an ontology with a new version; this is an implicit • transformation or actual change: a specification of what has ac- change specification; tually changed in an ontological definition, specified by a set of • a “mapping”: an update specified as a mapping between the orig- change operations (cf. [1]), e.g., change of a restriction on a prop- inal ontology and another one. Although this is not a update in erty, addition of a class, removal of a property, etc.; the regular sense, an explicit mapping to another ontology can be • conceptual relation: the logical relation between constructs in the considered as an update to the viewpoint of that ontology. two versions of the ontology, e.g., specified by equivalence rela- tions, subsumption relations, or logical rules; This gives several possible change specifications. For example, a • descriptive meta-data like date, author, and intention of the up- change can be specified individually, as a mapping between one spe- date: this describes the when, who and why of the change; cific definition in one ontology and another definition in another on- • valid context: a description of the context in which the update is tology, but it can also be done at a file level, by defining the transfor- valid. In its simplest form, this might consist of the date when the mation of the ontology. change is valid in the real world, conform to valid date in temporal Notice that the packaging methods are not equivalent, i.e., they do databases [15] (in this terminology, the “date” in the descriptive not give the same information about the update relation. It is clear meta-data is called transaction date). More extensive descriptions that the mapping provides a conceptual relation between versions of of the context, in various degrees of formality, are also possible. concepts that is not specified in a transformation. A well-designed ontology change specification mechanism should take all these characteristics into account. 3 GENERAL DESCRIPTION OF ONTOVIEW Another issue to discuss about ontology updates is the possible OntoView is a web-based system under development that provides discrepancy between changes in the specification and changes support for the versioning of online ontologies, which might help the conceptualization. We have seen that a ontology is a specifi- to solve some of the problems of evolving ontologies on the web. cation of a conceptualization. The actual specification of concepts Its main function is to help the a user to manage changes in ontolo- and properties is thus a specific representation of the conceptualiza- gies and keep ontology versions as much interoperable as possible. tion: the same concepts could also have been specified differently. It does that by comparing versions of ontologies and highlighting the Hence, a change in the specification does not necessarily coincide differences. It then allows the users to specify the conceptual relation with a change in the conceptualization [11], and changes in the spec- between the different versions of concepts. This function is described ification of an ontology are not per definition ontological changes. more extensively in the next section. For example, there are changes in the definition of a concept which It also provides a transparent interface to arbitrary versions of on- are not meant to change the concept, and, the other way around, a tologies. To achieve this, the system maintains an internal specifica- concept can change without a change in its logical definition. An ex- tion of the relation between the different variants of ontologies, with ample of the first case is attaching a slot “fuel-type” to a class “Car”. the aspects that were defined in section 2: it keeps track of the meta- Both class-definitions still refer to the same ontological concept, but data, the conceptual relations between constructs in the ontologies in the second version it is described more extensively. On the other and the transformations between them. 2 OntoView is inspired by the Concurrent Versioning System have unintended, unexpected and unforeseeable consequences in CVS [4], which is used in software development to allow collabo- the ontology itself [13]. rative development of source code. The first implementation is also OntoView provides some basic support for the analysis of these ef- based on CVS and its web-interface CVSWeb6 . However, during the fects. First, on request it can also highlight the places in the ontol- ongoing development of the system, we are gradually shifting to a ogy where conceptually changed concepts or properties are used. complete new implementation that will be build on a solid storage For example, if a property “hasChild” is changed, it will high- system for ontologies, e.g., Sesame7 . light the definition of the class “Mother”, which uses the property Besides the ontology comparison feature, the system has the fol- “hasChild”. In the future, this function should also exploit the tran- lowing functions: sitivity of properties to show the propagation of possible changes through the ontology. • Reading changes and ontologies. OntoView will accept changes Further, we expect to extend the system with a reasoner to au- and ontologies via several methods. Currently, ontologies can be tomatically verify the changes and the specified conceptual rela- read in as a whole, either by providing a URL or by uploading tions between versions. For example, we could couple the sys- them to the system. The user has to specify whether the provided tem with FaCT [3] and exploit the Description Logic semantics of ontology is new or that it should be considered as an update to DAML+OIL to check the consistency of the ontology and look for an already known ontology. In the first case, the user also has to unexpected implied relations. provide a “location” for the ontology in the hierarchical structure • Exporting changes. The main advantage of storing the concep- of the OntoView system. tual relations between versions of concepts and properties is the Then, the user is guided through a short process in which he is ability to use these relations for the re-interpretation of data and asked to supply the meta-data of the version (as far as this can not other ontologies that use the changed ontology. To facilitate this, be derived automatically, such as the date and user), to character- OntoView can export differences between ontologies as sepa- ize the types of the changes (see below in section 4), and to decide rate mapping ontologies, which can be used as adapters for data about the identifier of the ontology. sources or other ontologies. They only provide a partial mapping, In the future, OntoView will also accept changes by reading in because not all changes can be specified conceptually. transformations, mapping ontologies, and updates to individual The exported mapping ontologies are represented with the stan- definitions. These update methods provides the system with dif- dard constructs of the ontology langauge. Because in OntoView ferent information than the method described above. For that rea- the conceptual relation and the actual transformation are stored son, this also requires an adaptation of the process in which the separately, it is not necessary to extend the ontology language with user gives additional information. more advanced mapping- or transformation primitives than those • Identification. Identification of versions of ontologies is very im- already available. portant. Ontologies describe a consensual view on a part of the The meta-data about the ontology update is specified as a set of world and function as reference for that specific conceptualiza- properties of the conceptual relations themselves. In DAML+OIL, tion. Therefore, they should have a unique and stable identifica- this meant that we had to re-ify the mapping statements.8 This tion. A human, agent or system that conforms to a specific ontol- method has two advantages. First, when specified over re-ified ogy, should be able to refer to it unambiguously. statements, the meta-data does not interfere with the actual onto- Usually, the XML Namespace mechanism [6] is used for the iden- logical knowledge, as would be the case when meta-data is spec- tification of web-based ontologies. This means that an ontology ified as characteristics of classes and properties. Second, because is identified by a URI, i.e. a unique pointer on the web. In prac- the meta-data is data about the mappings themselves, agents or tice, people tend to use the location (the URL) of the ontology systems that understand the meta-data can use this to decide which file on the web as identifier. OntoView also uses the namespace mappings are applicable in a specific context and which are not. mechanism for identification, but does not necessarily use the lo- In the future, it should also be possible to export transforma- cation of the ontology file. If a change does not constitute a con- tions between two versions of an ontology. A transformation is ceptual change, the new version gets a new location, but does not a complete specification of all the change operations. This can get a new identifier. For example, the location of an ontology can be used to re-execute changes and to update ontologies that have change from “../example/1.0/rev0” to “../example/1.0/rev1”, while some overlap with the versioned ontology in exactly the same way the identifier is still “../example/1.0”. as the original one. However, transformations facilitates data re- OntoView supports two ways of persistent and unique identi- interpretations only to a very small extent. A mapping ontology fication of web-based ontologies. First, it can in itself guaran- provides better re-interpretation, because it also captures human tee the uniqueness and persistency of namespaces that start with knowledge about the relations. “http://ontoview.org/”, because the system is located at the domain ontoview.org. Second, because the location and identification of ontologies are only loosely coupled, it can also store ontologies 4 COMPARING ONTOLOGIES with arbitrary namespaces. In this case, the ontology engineer is One of the central features of OntoView is the ability to compare responsible for guaranteeing the uniqueness. The ontologies with ontologies at a structural level. The comparison function is inspired arbitrary namespaces are not directly retrievable by their names- by UNIX diff, but the implementation is quite different. Standard pace, but can be accessed via a search function. diff compares file version at line-level, highlighting the lines that • Analyzing effects of changes. Changes in ontologies do not only affect the data and applications that use them, but they can also 8 The DAML+OIL semantics do not currently cover reification because of the undecidability of second-order logic. However, there is an awareness 6 Available from http://stud.fh-heilbronn.de/˜zeller/ that use reification for “tagging” purposes — as we do — is different from cgi/cvsweb.cgi/ full second-order logic. See http://www.daml.org/language/ 7 A demo is available at http://sesame.aidministrator.nl features.html. 3 textually differ in two versions. OntoView, in contrast, compares ver- ontology definitely is. Finding the right level of abstraction is thus sion of ontologies at a structural level, showing which definitions of important. ontological concepts or properties are changed. An example of such Second, even when we found the correct level of abstraction for a graphical comparison of two versions of a DAML+OIL ontology is change detection, the conceptual implication of such a change is not depicted in Figure 2.9 yet clear. Because of the difference between conceptual changes and explication changes (as described in section 2), it is not possible to derive the conceptual consequence of a change completely on basis 4.1 Types of change of the visible change only (i.e., the changes in the definitions of con- The comparison function distinguishes between the following types cepts and properties). Heuristics can be used to suggest conceptual of change: consequences, but the intention of the engineer determines the actual conceptual relation between versions of concepts. • Non-logical change, e.g. in a natural language description. In In the next two sections, we explain the algorithm that we used DAML+OIL, this are changes in the rdfs:label of an concept or to compare ontologies at the correct abstraction level, and how users property, or in a comment inside a definition. An example is the can specify the conceptual implication of changes. first highlighted change in Figure 2 (class “Animal’). • Logical definition change. This is a change in the definition of a concept that affects its formal semantics. Examples of such 4.3 Rules for changes changes are alterations of subClassOf, domain, or range state- The algorithm uses the fact that the RDF data model [12] underlies a ments. Additions or deletions of local property restrictions in a number of popular ontology languages, including RDF Schema and class are also logical changes. The second and third change in the DAML+OIL. The RDF data model basically consists of triples of the figure is (class “Male” and property “hasParent”) are examples of form , which can be linked such changes. by using the object of one triple as the subject of another. There are • Identifier change. This is the case when a concept or property is several syntaxes available for RDF statement, but they all boil down given a new identifier, i.e. a renaming. to the same data model. An set of related RDF statements can be • Addition of definitions. represented as a graph with nodes and edges. For example, consider • Deletion of definitions. the following DAML+OIL definition of a class “Person”. Most of these changes can be detected completely automatically, ex- cept for the identifier change. Each type of change is highlighted in a different color, and the actually changed lines are printed in bold- face. We describe the mechanism that we use to detect and classify changes in the next paragraphs. 4.2 Detecting changes There are two main problems with the detection of changes in on- tologies. The first problem is the abstraction level at which changes should be detected. Abstraction is necessary to distinguish between When interpreted as a DAML+OIL definition, it states that a “Per- changes in the representation that affect the meaning, and those that son” is a kind of ”Animal” and that the instances of its hasParent don’t influence the meaning. It is often possible to represent the relation should be of type “Person”. However, for our algorithm, we same ontological definition in different ways. For example, in RDF are first of all interested in the RDF interpretation of it. That is, we Schema, there are several ways to define a class: only look at the triples that are specified, ignoring the DAML+OIL meaning of the statements. Interpreted as RDF, the above definition results in the following set of triples: subject predicate object or: Person rdf:type daml:Class Person rdfs:subClassOf Animal Person rdfs:subClassOf anon-resource anon-resource rdf:type daml:Restriction anon-resource daml:onProperty hasParent Both are valid ways to define a class and have exactly the same mean- anon-resource daml:toClass Person ing. Such a change in the representation would not change the ontol- This triple set is depicted as a graph in Figure 3. In this figure, the ogy. Thus, detecting changes in the representation alone is not suffi- nodes are resources that function as subject or object of statements, cient. whereas the arrows represent properties. However abstracting too far can also be a problem: considering The algorithm that we developed to detect changes is the follow- the logical meaning only is not enough. In [2] is shown that different ing. We first split the document at the first level of the XML docu- sets of ontological definitions can yield the same set of logical ax- ment. This groups the statements by their intended “definition”. The ioms. Although the logical meaning is not changed in such cases, the definitions are then parsed into RDF triples, which results in a set of 9 This example is based on fictive changes to the DAML example on- small graphs. Each of these graphs represent a specific definition of tology, available from http://www.daml.org/2001/03/daml+ a concept or a property, and each graph can be identified with the oil-ex.daml. identifier of the concept or the property that it represents. 4 Figure 2. Comparing two ontologies Figure 3. An RDF graph of a DAML class definition. Then, we locate for each graph in the new version the correspond- around) to signal a specific type of change. With this rule mecha- ing graph in the previous version of the ontology. Those sets of nism, we were able to specify almost all types of change, except the graphs are then checked according to a number of rules. Those rules identifier change. Here we also used some heuristics, based on the specify the “required” changes in the triples set (i.e., the graph) for a location of the definition in the file. We list two example rules below. specific type of change, as described in section 4.1. A change in the value of a local property: Rules have the following format: IF exist:old IF exist:old * not-exist:new THEN change-type A not-exist:new They specify a set of triples that should exists in one specific version, and a set that should not exists in another version (or the other way THEN logicalChange.localPropertyValue X 5 A change in the property type: We did not yet specify the way in which a “valid context” is described. Such a context will have several dimensions, of which IF exist:old “time” is only one. This is something what still has to be done. With- out such a specification, it is difficult to assess the validness of a conceptual relation between concepts in different versions. We can not-exist:new assume that such a relation is at least valid between two successive versions, but we do not know whether such mapping is allowed to THEN logicalChange.propertytype X “propagate” via other mappings to other ontologies. Research on this is necessary. The rules are specific for a particular RDF-based ontology lan- A situation in which versioning support is also necessary is the guage (in this case DAML+OIL), because they encode the interpre- collaborative development of an ontology [14]. We think that On- tation of the semantics of the language for which they are intended. toView is also useful in this situation, especially because all the con- For another language other rules would have been necessary to spec- ceptual implications of versions have to be characterized individually ify other differences in interpretation. The semantics of the language by users. This integrates the conflict resolution in the update proce- are thus encoded in the rules. For example, the last example not looks dure. at changes in values of predicates (as the first does), but at a change A side remark about the use of a versioning system for collabora- in the type of property. This is a change that is related to the specific tive ontology development is that this gives an evolutionary way of semantics of DAML+OIL. ontology building. Each person can have its own conceptualization, Also, notice that the mechanism relies on the “materialization” of which is conceptually linked to the conceptualizations of others. In all rdf:type statements that are encoded in the ontology (some- this sense, the combination of versions and adaptations in itself forms times called “knowledge compilation”). The last example depend on a shared conceptualization of a domain. the existence of a statement . Finally, we want to mention that the system is still under construc- However, this statement can only be derived using the semantics of tion. In section 3 we extensively depicted the foreseen functional- the rdfs:subPropertyOf statement, which — informally spo- ity of OntoView. However, as became clear of some of the descrip- ken10 — says that if a property is an instance of type X, then it is tions, not everything is already realized. The basis functions are im- also an instance of the supertypes of X. The application of the rules plemented, but a number of more advanced functions are still being thus has to be preceded by the materialization of the superclass- and developed. superproperty hierarchies in the ontology. For this materialization, the entailment rules in the RDF Model Theory11 can be used. 4.4 Specifying the conceptual implication of 6 CONCLUSION changes The comparison function also allows the user to characterize the conceptual implication of the changes. For the first three types of When ontologies are used in a distributed and dynamic context, ver- changes that were listed in section 4.1, the user is given the option sioning support is essential ingredient to maintain interoperability. In to label them either as “identical” (i.e., the change is an explica- this paper we have analyzed the versioning relation, described its as- tion change), or as “conceptual change”, using the drop-down list pects, and depicted a system that provides support for the versioning next to the definition (Figure 2). In the latter case, the user can spec- of online ontologies. ify the conceptual relation between the two version of the concept. We described how this systems supports helps users to compare For example, the change in the definition of “hasParent” could by ontologies, and what the problems and challenges are. We presented characterized with the relation hasParent1.1 subPropertyOf a algorithm to perform a comparison for RDF-based ontologies. This hasParent1.3 . algorithm doesn’t operate on the representation of the ontology, but on the data model that is underlying the representation. By grouping the RDF-triples per definition, we still retained the necessary repre- 5 DISCUSSION sentational knowledge. We also explained how users can specify the conceptual implication of changes to help interoperability. This hon- There are a few other issues and choices about the design of the sys- ors the fact that it is not possible to derive all conceptual implications tem that we want to discuss. First, we purposely do not provide sup- of changes automatically. port for finding mappings between arbitrary ontologies. The intention The analysis of a versioning relation between ontologies revealed of our system is to provide users with a system to manage versions several dimensions of it. In the system that we described, all these of ontologies and maintain their relations. Finding the relations is a dimensions are maintained separately: the descriptive meta-data, different task. However, it might be possible to incorporate this func- the conceptual relations between constructs in the ontologies, and tion in a future version of the system, e.g. by interfacing it with a the transformations between the ontologies themselves. This multi- ontology mapping tool. dimensional specification allows both complete transformations of Another issue is the visualization of the changes. The current ver- ontology representations and partial data re-interpretations, which sions shows the changes by highlighting the textual definitions that help interoperability. The conceptual differences can be exported and are changed. More advanced visualization techniques are possible. used stand alone, for example to adapt data sources and ontologies. For example, one could think of techniques that render ontologies in The described system is not yet finished and should be developed a graphical representation and highlight the changes in the picture. further. We believe that it will significantly simplify the change man- 10 The precise semantics of RDF Schema are still under discussion. agement of ontologies and thus help the interoperability of evolving 11 http://www.w3.org/TR/rdf-mt/ ontologies on the web. 6 REFERENCES [1] Jay Banerjee, Won Kim, Hyoung-Joo Kim, and Henry F. Korth, ‘Se- mantics and Implementation of Schema Evolution in Object-Oriented Databases’, SIGMOD Record (Proc. Conf. on Management of Data), 16(3), 311–322, (May 1987). [2] Sean Bechhofer, Carole Goble, and Ian Horrocks, ‘DAML+OIL is not enough’, in Proceedings of the International Semantic Web Working Symposium (SWWS), Stanford University, California, USA, (July 30 – August 1, 2001). [3] S. Bechhofer, I. Horrocks, P. F. Patel-Schneider, and S. Tessaris, ‘A proposal for a description logic interface’, in Proceedings of the In- ternational Workshop on Description Logics (DL’99), eds., P. Lambrix, A. Borgida, M. Lenzerini, R. Möller, and P. Patel-Schneider, pp. 33–36, Linköping, Sweden, (July 30 – August 1 1999). [4] Brian Berliner, ‘CVS II: Parallelizing software development’, in Pro- ceedings of the Winter 1990 USENIX Conference, ed., USENIX Asso- ciation, pp. 341–352, Washington, DC, USA, (January 22–26, 1990). USENIX. [5] Tim Berners-Lee, Jim Hendler, and Ora Lassila, ‘The semantic web’, Scientific American, 284(5), 34–43, (May 2001). [6] Tim Bray, Dave Hollander, and Andrew Layman. Namespaces in XML. http://www.w3.org/TR/REC-xml-names/, January 1999. [7] D. Brickley and R. V. Guha, ‘Resource Description Framework (RDF) Schema Specification 1.0’, Candidate recommendation, World Wide Web Consortium, (March 2000). [8] Dieter Fensel, Ian Horrocks, Frank van Harmelen, Stefan Decker, Michael Erdmann, and Michel Klein, ‘OIL in a nutshell’, in Knowl- edge Engineering and Knowledge Management; Methods, Models and Tools, Proceedings of the 12th International Conference EKAW 2000, eds., Rose Dieng and Olivier Corby, number LNCS 1937 in Lecture Notes in Artificial Intelligence, pp. 1–16, Juan-les-Pins, France, (Octo- ber 2–6, 2000). Springer-Verlag. [9] Dieter Fensel and Mark A. Musen, ‘The semantic web: A new brain for humanity’, IEEE Intelligent Systems, 16(2), (2001). [10] T. R. Gruber, ‘A translation approach to portable ontology specifica- tions’, Knowledge Acquisition, 5(2), (1993). [11] Michel Klein and Dieter Fensel, ‘Ontology versioning for the Seman- tic Web’, in Proceedings of the International Semantic Web Working Symposium (SWWS), Stanford University, California, USA, (July 30 – August 1, 2001). [12] O. Lassila and R. R. Swick, ‘Resource Description Framework (RDF): Model and Syntax Specification’, Recommendation, World Wide Web Consortium, (February 1999). See http://www.w3.org/TR/REC-rdf- syntax/. [13] Deborah L. McGuinness, Richard Fikes, James Rice, and Steve Wilder, ‘An environment for merging and testing large ontologies’, in KR2000: Principles of Knowledge Representation and Reasoning, eds., An- thony G. Cohn, Fausto Giunchiglia, and Bart Selman, pp. 483–493, San Francisco, (2000). Morgan Kaufmann. [14] Helena Sofia Pinto and Jo ao Pavão Martins, ‘Evolving ontologies in distributed and dynamic settings’, in Proceedings of the Eighth Inter- national Conference on Principles of Knowledge Representation and Reasoning (KR2002), Toulouse, France, (April 22–25, 2002). [15] John F. Roddick, ‘A survey of schema versioning issues for database systems’, Information and Software Technology, 37(7), 383–393, (1995). [16] Pepijn R. S. Visser, Dean M. Jones, T. J. M. Bench-Capon, and M. J. R. Shave, ‘An analysis of ontological mismatches: Heterogeneity versus interoperability’, in AAAI 1997 Spring Symposium on Ontological En- gineering, Stanford, USA, (1997). 7