W3C [Not Quite] Working Draft – 01/23/2006
This version:
http://www.w3.org/TR/2006/whatever
Latest version:
http://www.w3.org/TR/whatever
Previous versions
There are no previous versions worth noting.
Editors:
Authors:
Contributors:
Am unclear on who goes where...
Copyright ©2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Semantic interoperability means enabling different agents, services, and applications to exchange information, data and knowledge, on and off the Web. To enable semantic interoperability agents, services, and applications need to share the same mutually understood vocabulary or to create correspondences or mappings between their different vocabularies. One of the design goals of RDF and OWL is to provide the means to specify such mappings. This note provides guidance on how OWL and RDF can be used to enable semantic interoperability.
We briefly characterize what we mean by semantic interoperability, and what the challenges are. We describe some RDF and OWL constructs that are designed to support semantic interoperability and illustrate them with examples. We highlight their strengths and limitations. The main strengths are the ability to express logical equivalence and other relationships between concepts, properties and individuals in different ontologies. One main weakness is the lack of support for procedural functions (e.g. arithmetic, string manipulation) that are needed for mapping between many real-world ontologies.
This is a nearly complete first draft of this note.
The outline and structure of the document is stable.
The major change from the last version is that there is a narrative for the different OWL mapping constructs.
Open issues, todo items:
Requested Feedback from reviewers of this incomplete draft:
[ANTICIPATED:] This document is the First Public Working Draft. We encourage public comments. Please send comments to public-swbp-wg@w3.org [archive] and start the subject line of the message with "comment:"
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Semantic Web languages, such as RDF and OWL facilitate interoperability in significant ways. They provide the social structure and technical framework to reuse existing ontologies; they provide formal mechanisms to express logical equivalences and other formal relationships between classes and properties in different ontologies. The goal of this note is to give users and application developers tools and guidelines to exploit OWL to achieve semantic interoperability. Ultimately, it is up to the users to reuse ontologies correctly and to identify and specify the logical relationships between terms in different ontologies.
Note that for use cases 2 and 3, there is a need to map terminology from one ontology to another. A major focus of this note will be how to specify these mappings in OWL. The mechanics of creating the mappings is independent from what use case the mappings are needed for.
The terms ‘semantic interoperability’ and ‘semantic integration’ are often used loosely and somewhat interchangeably. The core idea for both is the existence of and desire to bridge a semantic gap between different systems or applications that use different vocabularies. The different vocabularies reflect different underlying conceptual models or ontologies that the systems are based on. Thus, semantic interoperability and semantic integration both entail the use of semantic mappings between terms in one ontology to terms in another ontology. The main difference is an architectural one. In the case of semantic interoperability, the original systems and ontologies remain intact. For example, ... [MIKE, can you add a simple example of this here? ...] By contrast, semantic integration usually involves some merging of ontologies or applications. [Mike, do we really want to say "or applications" here? What would be an example of merged applications??] For this note, we will use the term ‘semantic I&I’ to refer to both semantic interoperability and semantic integration, as most of the issues dealt with in this document are common to both. We will use either term on its own when we specifically wish to refer to just one.
We view semantic I&I as an effort that focuses on enabling different agents, services, and applications to exchange information, data, and knowledge such that the intended meaning of the information/data/knowledge is preserved. For simplicity, we will refer to agents, services, and applications collectively as agents. Great strides have been made in recent decades to improve interoperability at physical and syntactic levels. Streams of data were successfully transmitted between systems, however there was no meaning associated with the data. This situation is analogous to successful delivery of an encrypted message, appearing to the recipient in an unfamiliar script -- mere scratchings on the page. However, as Verizon CTO Michael Brodie notes, "it's the semantics, not the plumbing", [that is required for interoperability]. It is insufficient, that is, just to have a robust physical infrastructure for transmitting data between systems, as the very same data can mean very different things in different systems: depending on the system (as well as the context). To a supplier, "delivery date" typically means the date the product is shipped; and to the buyer, the same phrase typically means the date the product is received. Similarly, data values such as “32” may be an integer age (measured in years), a temperature (measured in degrees fahrenheit or celsius), or a number of employees (measured in FTE – Full Time Equivalents). [DLM3] Without a way of indicating its intended meaning, the raw data received by a target system is potentially so misleading and open to misinterpretation, that is can be viewed as essentially useless. Systems are semantically interoperable when agents within them are able to exchange information, rather than mere data.
In this section, we give some general guidelines and principles for achieving semantic interoperability & integration among Web applications. The Semantic Web and the Semantic Web languages provide both the social structure and the technical means to facilitate semantic I&I. The most fundamental contribution that the Semantic Web brings to semantic I&I is a set of recommended standardized languages with well defined syntax and semantics . One impediment to semantic I&I has been the use of a wide variety of knowledge representation frameworks to represent information. Exacerbating the problem is the fact that many of these languages lacked any explicit specification of their syntax — their basic vocabularies and their grammars — and their intended semantics. In limited circumstances, the need for such specifications may not arise. For example, within a small organization new users can pick up the structure of the syntax and its intended interpretation from experienced users in the organization. However, in the context of the SW, this model is inadequate since agents wishing to share information must first share a common understanding of the content of the representations in terms of which that information is expressed.
The Semantic Web activity in the W3C made a significant advance on the language heterogeneity problem through the introduction of formal recommendations for several standard XML-based ontology languages, notably, RDF, RDF Schema (RDFS) and OWL. The syntax and semantics of these languages are open, well-defined standards. This gives rise to our first principle:
Principle 1: To facilitate semantic I&I, create new ontologies in OWL.Principle 2: To facilitate semantic I&I, translate existing ontologies into OWL.
If existing ontologies are intended to be shared, translate them into OWL and make the OWL version available in addition to the original version. Unfortunately, there is no general, automated method for translating an ontology written in another KR language into OWL. The difficulty of the task, varies significantly from language to language.
First, some ontologies are written in languages that are more expressive than OWL (such as full first order logic) and thus it is possible that some details in the original ontology will not be translatable into OWL. Some systems such as Ontolingua and Chimaera that use KIF – a first order logic language – as their internal representation language handle this issue in their export capabilities by translating as much as possible into OWL and noting what they could not translate. One emerging option is to produce ontologies completely in OWL if expressively possible with additional information in a more expressive language, such as KIF, if required.[DLM4]
Second, some ontologies may be written in languages that embody paradigms more or less similar to those embodied in OWL. For example ontologies written in a frame-style language like OKBC, LOOM, or CLASSIC may translate more easily and naturally into OWL than ontologies written in a full, unrestricted first-order language like KIF. Protege, for example, extended its frame-based core to represent ontologies in OWL. OWL can be viewed as a descendant of frame-style and description logic systems and provide natural support for modeling things such as classes and binary relations. If ontologies are best conceptually modeled with things such as ternary (or higher arity) relations, translations may be less natural.[MFU1]]The first two principles focus on representing ontologies using the same language, OWL. This is a great help, but there are many issues of semantic heterogeneity that arise even when the same language is universally used.
The semantics for OWL does two very important things for us. First, it fixes the meanings of the reserved vocabulary. For example, it says exactly what is meant by declaring a relationship to be transitive, or that an individual is a member of a class. Second, OWL specifies how the meanings of complex expressions using various syntactic constructs as specified by the grammar of the language depend systematically on the meanings of their simpler parts. For example, if you know the precise meaning of theAnimal and Plant classes, and you know the meaning of the OWL construct owl:unionOf you can know exactly what the following expression means: owl:unionOf(Animal Plant). This expression is an anonymous class for which the
class extension contains those individuals that occur in the class extensions
of either Animal or Plant.Principle 3: To facilitate semantic I&I, reduce ambiguity by expressing more meaning.
In the context of the Semantic Web, ontology creation takes on an entirely new and exciting guise. Currently, web page content is expressed largely in terms of unstructured text and graphics where most or all of the meaning is implicit. Acquiring the intended meaning[MFU2] of the content relies on the human’s understanding of the words and context. OWL's constructs open up the possibility of explicitly declaring the meaning of the content. OWL is used to put the semantics in the Semantic Web.
An ontology builder must take care to specify the meaning of the terms in the ontology. This ensures that others who may wish to reuse your ontology can glean the intended meaning of the vocabulary in your ontology. If an ontology only contains a name for a class and nothing more, such as the class named “Animal”, then for a start, only English speaking people will have an idea what the class might mean.[NN2] All we know from the semantics of OWL is that 'Animal" denotes a set of individuals. If the ontology also includes, say that the class Animal is a subclass of PhysicalObject, then this expresses more meaning, and further reduces ambiguity. If the ontology further specifies that Animal is a subclass of other classes (e.g. the class of all moving things), that adds yet more meaning, further reducing ambiguity. In addition to specifying superclasses, the ontology builder can also indicate what relations have the class Animal in their Domain or Range. Further, the ontology builder can specify properties of those relations, such as if the relations are transitive. Expressing more meaning in an OWL ontology amounts to 1) using a variety of
OWL constructs to capture different aspects of the meaning of a given term
and 2) using a given OWL construct as often as necessary to say as much as
possible about that aspect of the term's meaning.[DLM-MFU-NN-1]
Each thing stated about the terms in an ontology is represented as a formal statement using the grammar of RDF along with the OWL reserved vocabulary. Each statement serves to characterize the logical characteristics of, and logical connections among, the classes, properties, and individuals named in a domain specific vocabulary. Although a typical user of an ontology building environment may not be aware of it, these formal statements are all axioms in a formal logic.
In summary, one increases sharing and reuse by reducing ambiguity, which in turn, is achieved by adding more meaning to one's ontology. One adds more meaning by making use of OWL's reserved vocabulary to axiomatize the classes, properties, and individuals in an ontology.
Principle 4: To facilitate semantic I&I, reuse terms from existing ontologies.
The richer content and standardized representations afforded by OWL, together with the connectivity provided by the web's basic infrastructure, opens up the second exciting aspect of ontology creation on the Semantic Web, namely, the possibility of genuine, robust reuse. Prior to the semantic web, reuse consisted of little more than incorporating a term from someone else's ontology into one's own ontology, with the intention that it means the same thing across ontologies. But if the term is not defined or axiomatized by means of the sort of rich representational constructs that OWL provides, there is no way to be certain, or even mildly confident, of its meaning and hence no way to ensure commonality of meaning when the term is reused. OWL makes such representations possible. Moreover, the infrastructure of the web — notably, the mechanism of Uniform Resource Locators — together with XML namespaces facilitate reuse by making it possible to import content directly from remote ontologies, thereby reducing work and eliminating the possibility of transcription errors.
Reusing existing terms, that have a well-defined meaning, is an important step, but not nearly enough. Sometimes, there are good reasons to represent the same concepts using different terms, or different representational constructs. This gives rise to our next principle.
Principle 5: To facilitate semantic I&I, use OWL mapping constructs to relate terms from different ontologies.
When a term from one ontology is reused in the context of building a new ontology or extending an existing ontology, it comes "tagged" with its original namespace.[MFU4] This mechanism enables a single core term to be used in both ontologies, each having a different meaning (this mechanism also preserves provenance information.[MFU5] In the event that the meanings are the same, or closely related, it is important [MFU6] to specify the semantic connection between them. This is done by using various mapping constructs in OWL.[MFU7]
In the next section of this document, we illustrate the use of the ontology mapping constructs for facilitating semantic interoperability & integration by means of a series of examples.[MFU8][MFU9][DLM5]
There are three constructs in OWL to express logical equivalence: owl:equivalentClass, owl:equivalentProperty,
and owl:sameAs. We use owl:equivalentClass to express logical equivalence of two class definitions (that is, the two classes have the same extensions, but they are not necessarily the same concepts. We use owl:equivalentProperty to express logical equivalence of two property definitions. The property owl:sameAs indicates that two URI references actually refer to the same thing: the individuals have the same "identity".
For example, we might specify that the class ontA:car is equivalent to the class ontB:auto :
ontA:car
owl:equivalentClass ontB:auto .
We can state that the property ontA:canRunSlowly is equivalent to the property ontB:canJog :
ontA:canRunSlowly
owl:equivalentProperty ontB:canJog .
We can also specify that the individual ontA:venus is the same individual as ontB:morning_star
ontA:venus
owl:sameAs ontB:morning_star .
Often, there is no exact equivalence between two classes or two properties, but there may still be an important subclass or subproperty relationship between them that is useful to capture. For example, one might wish to create a mapping stating that the class ontA:Primate is a subclass of the class ontB: Mammal, or that the property ontA:brotherOf is a subProperty of ontB:siblingOf:
ontA:Primate
rdfs:subClassOf ontB:Mammal .
ontA:brotherOf
rdfs:subPropertyOf ontB:siblingOf .
The equivalence and subclass relationships state fundamenatal similarities between classes. One can also make statements that clarify some of their differences, using properties owl:disjointWith and owl:differentFrom.
For example, one might declare that ontA:Plant is disjoint with the class ontB:Fungus :
ontA:Plant
owl:disjointWith ontB:Fungus .
You can also say that ontA:JohnASmith is different from ontB:JohnASmith:
ontA:JohnASmith
owl:differentFrom ontB:JohnASmith .
These kinds of statements are not as obviously useful as a basis for translating data from one ontology to another, however they specify mapping information in the sense that they relate the meaning of classes and individuals in two different ontologies.
In addition to being used on their own simply to express relations between given classes, as in the above examples, the core class mapping constructs may also be used in conjunction with other OWL constructs to create more complex logical mappings between class terms from different ontologies. For example, an ontological engineer might say that the class ontA:Lifeform in Ontology A is equivalent to the union of the three classes ontB:Plant, ontB:Animal and ontB:Fungus in Ontology B :
ontA:Lifeform
owl:equivalentClass
[ a owl:Class ;
owl:unionOf ( ontB:Plant ontB:Animal ontB:Fungus
] .
In the same way, one can also use OWL restrictions to define classes that enable one to express even more subtle mappings. For example, we can state that the class ontA:Bicycle is a subclass of the class of all ontB:landVehicle(s) which exactly two wheels:
ontA:Bicycle
owl:equivalentClass
[ a owl:Class ;
owl:intersectionOf (ontB:LandVehicle
[ a owl:Restriction ;
owl:cardinality 2 ;
owl:onProperty ontB:hasWheels
])
] .
In general, any legal combination of OWL class formation operators can be used to form arbitrarily complex class expressions to state class equivalence, disjointness or subclass relationships. More typically, one of the class expressions will be just a class name, like ‘lifeform’ in the above example. However, it is also allowed to have arbitrarily complex expressions for both classes that are declared to be equivalent, disjoint or subclasses. For example, one could state that the class formed by the intersection of the class C1 with the union of classes C2 and class C3 is a subclass or (or equivalent to, or disjoint with) the class formed by taking the complement of the intersection of classes C2 and C4. We leave it as an exercise for the reader to come up with real-world examples where such expressions might be useful. You can also state that any class expression is empty or non-empty. You can state that a set of classes forms a partition. Mapping statements are only limted by your imagination and the set of legal OWL constructs for specifying classes.
In summary, we have introduced
five core OWL mapping constructs that explictly relate classes to classes,
properties to properties or individuals to individuals: owl:equivalentClass, owl:disjointWith, owl:equivalentProperty, owl:sameAs, owl:differentFrom. They are used, in conjunction with other
OWL constructs to express formal logical relationships between terms in different
ontologies for the purpose of mapping. Depending on the use case, mappings can be used to specify
the logical connections either between existing terms across multiple ontologies
or between existing ontology terms and a new ontology term. Mappings can be
used to state clear similarities, or clear differences. Mappings can involve
any combination of classes, properties and individuals from two or more ontologies.
[THE ABOVE MARKS THE END OF NATASHA'S EDITS AND CONTRIBUTIONS. THE FOLLOWING IS OLD STUFF, SOME OF WHICH REITERATES THINGS SAID ABOVE, BUT IT ALSO SEEMS TO ME TO CONTAIN SOME GOOD IDEAS WE MIGHT WANT TO PRESERVE.]
The simplest and most explicit mapping constructs in OWL declare exact logical equivalence. For example, we might specify that the class ontA:car is quivalent to the class ontB:auto, or that the property OntA:canRunSlowly is equivalent to the property OntB:canJog. We can also specify that the individual OntA:venus is the same individual as OntA:morning_star.[MFU10] These are examples of three core mapping constructs in OWL that allow us to state that 1) two classes are equivalent, 2) two properties are equivalent, and 3) that two individuals are identical. The OWL constructs for this are equivalentClass, equivalentProperty and sameAs, respectively.
Often, there is no exact equivalence between two classes or two properties, but there may still be an important subClass or subProperty relationship between them that is useful to capture. For example, one might wish to create a mapping stating that the class OntA:Primate is a subClass of the class OntB: Mammal, or that the property OntA:brotherOf is a subProperty of OntB:siblingOf.
The equivalence and subclass relationships state fundamenatal similarities between classes. One can also make statements that clarify some of their differences. For example, one might declare that OntA:plant is disjoint with the class OntB:fungus. You can also say that ontA:JohnASmith is different from ontB:JohnASmith. These kinds of statements are not as obviously useful as a basis for translating data from one ontology to another, however they specify mapping information in the sense that they relate the meaning of classes and individuals in two different ontologies.
We consider the core OWL mapping constructs[MFU11] to be: equivalentClass, equivalentProperty, sameAs, subClass and subProperty because they explictly relate classes to classes, properties to properties or individuals to individuals.
In the case of properties and individuals: equivalentProperty, subProperty, sameAs, and differentFrom pretty much exhaust what can be specified in a mapping between two different ontologies. In the case of classes, there is much much more.
In addition to being used on their own, as in the above examples, the core class mapping constructs may also be used in conjunction with other OWL constructs to create more complex logical mappings between terms from different ontologies. For example, an ontology designer might say that the class OntA:lifeform is equivalent to the union of the three classes: OntB:plant, OntB:animal and OntB:fungus. One can also use restrictions in class mappings. For example, we can state that the class OntA:bicycle is equivlaent to or subclass of the class of all OntB:landVehicle(s) such that the cardinality of the numberOfWheels property is equal to exactly 2.
In general, any legal combination of OWL class formation operators can be used to form arbitrarily complex class expressions to state class equivalence, disjointness or subclass relationships. More typically, one of the class expressions will be just a class name, like ‘lifeform’ in the above example. However, it is also allowed to have arbitrarily complex expressions for both classes that are declared to be equivalent, disjoint or subclasses. For example, one could state that the class formed by the intersection of the class C1 with the union of classes C2 and class C3 is a subclass or (or equivalent to, or disjoint with) the class formed by taking the complement of the intersection of classes C2 and C4. We leave it as an exercise for the reader to come up with real-world examples where such expressions might be useful. You can also state that any class expression is empty or non-empty. You can state that a set of classes forms a partition. Mapping statements are only limted by your imagination and the set of legal OWL constructs for specifying classes.
Note that although in principle, any OWL constructs that can be used to describe or refer to properties can be used in conjunction with equivalentProperty and subProperty to create mappings between properties in different ontologies, in practice there aren’t an OWL construcsts for this. Similarly, while in principle, any OWL constructs that can be used to refer to individuals may be used with sameAs or differentFrom to create mappings between individuals in two different ontologies OWL does not have any additional constructs.[MFU12] [TBD: some examples on complex expressions using property-forming and indiv-forming operators, analogous to the class-forming operators. How would you say that the sibling property is in some sense the union of brother and sister (thinking of the sets of tuples)? How would you say that one of the editors is the same individual as the one who authored the paper: "Where are the semantics in the semantic web?" using the sameAs construct? Maybe I use individuals with oneOf in conjunction with class formation operators?]
In summary, we have introduced five core OWL mapping constructs that explictly relate classes to classes, properties to properties or individuals to individuals: equivalentClass, disjointClass, equivalentProperty, subProperty, sameAs, differentFrom. They are used, in conjunction with other OWL constructs to express formal logical relationships between terms in different ontologies for the purpose of mapping. Depending on the use case, mappings can be used to specify the logical connections either between existing terms across multiple ontologies or between existing ontology terms and a new ontology term. Mappings can be used to state clear similarities, or clear differences. Mappings can involve any combination of classes, properties and individuals from two or more ontologies.
We can also say how they are different. For example we might say that OntA:bicycle is disjoint from OntB:motorcycle. Or we mignt want to say that a given individual in OntA is differentFrom a given individual in OntB. Broadly speaking, a mapping axiom can be any statement that related the meaning of any two or more terms from two different ontologies. It might be useful to say that the intersection of classes from both ontology are disjoint. You might wish to create a partition using classes from the different ontologies. All of these are examples or relating the meaning from terms, or combinations of terms from two ontologies.[MFU13]
The core mapping constructs are distinguished in that they play a primary role in mapping; you cannot create mappings without them.[MFU14] However, they are not used exclusively for mapping; they also are important for building individual ontologies, when mapping is not a concern. For example, equivalentClass is very commonly used when defining restriction classes. As we have seen, other OWL constructs can also play a role in mapping. Thus, there is no subset of OWL that is exclusively used for mapping. Most or all OWL constructs can be used for mapping or for other things, depending on the context.[MFU15]
In the next section, we look at more examples of mappings using OWL, in the context of a realistic example.
[Question is what more is needed now? Do we want a longer, more detailed narrative? More subtle examples? Ideas welcome. I don't think my original airline example does the job; too complex.]