Copyright ©2005 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 in a meaningful way, 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 this can be done.
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 import, share and reuse public ontologies (in whole or part) and the ability to express logical equivalence and other relationships between concepts, properties and individuals in different ontologies. The 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 very preliminary and incomplete draft of this note for review withing the OEP group:
[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:"
Open issues, todo items: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 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.
Integrate Existing OWL Ontologies: A knowledge engineer has two distinct OWL ontologies to integrate. She largely understands the intuitive meanings of the vocabulary of the two ontologies, either because the two ontologies are well axiomatized, or simply because she is familiar with the domain specific vocabulary of each. Her main task is to be able to make the mappings between the two ontologies explicit.
Application Interoperability:
Translating Data Expressed
using Two or More Different Ontologies: An software developer
needs to have data sent from one application (that is expressed using
the vocabulary from one ontology), to another application. The data
needs to be converted to use the vocabulary from the receiving
application. This is similar to the first use case, in that we assume
that there is a good undersatnding of the meaning of both ontologies,
and that the main task is to specify the mappings.
Build new OWL ontology reusing existing ontologies: A knowledge engineer wants to build a new ontology to serve as a backdrop for managing some aspect of corporate knowledge (e.g. her company's manufacturing process). There are various existing ontology resources to draw from, and she would like to reuse them as much as possible.
NOTE this document currently focuses on
semantic integration as opposed to the broader notion
of semantic interoperability. Here, semantic
integration is taken to consist chiefly in the identification and
explication of logical connections between classes, properties, and
individuals across ontologies. Semantic interoperability (we (or I –
CM) suggest) encompasses semantic integration proper as well as, e.g., interoperability of services and tools made possible
and driven by semantic integration.
MFU: you don't say here what interoperability
is that integration is not. Do we need to say something in the document?
Semantic interoperability is about enabling different agents, services, and applications to exchange information, data, and knowledge in a meaningful way, on or off the Web. (In this note, 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, "It's the semantics, not the plumbing", says Michael Brodie, chief technical officer at Verizon. 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), "32" can mean an age, the average temperature, or the number of employees. To a supplier, "delivery date" typically means the date the product is shipped; to the buyer, the date received. Without a way of indicating its intended meaning, the raw data received by a target system is 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 on the Web. The
Semantic Web and the Semantic Web languages provide both the
social
structure and the technical means to facilitate semantic
interoperability. The most fundamental element that Semantic Web brings
to interoperability is a set of standardized languages. One
of the most daunting impediments to interoperability 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.
Such specifications are perhaps, in some cases, unnecessary within a
single organization, as new users can pick up the structure of the
syntax and its intended interpretation from experienced users. However,
in the context of the SW, this model is utterly inadequate; 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 huge advance on the
language heterogeneity problem through the
introduction of formal recommendations for several standard
XML-based
ontology languages, notably, RDF, RDF Schema (RDFS), OWL.
The syntax and semantics of these languages are open,
well-defined
standards. This gives rise to our first principle:
Principle 5: To facilitate
interoperability,
use OWL mapping constructs to relate the terms in different ontologies.
When a term
from another ontology is reused, it comes "tagged" with its original
namespace. In addition to preserving provenance, this mechanism
prevents the creation of ambiguity that might otherwise is the same
term is already being used with a different meaning in the target
ontology. Consequently, however, the semantic connections between the
reused term and the existing terms in one's ontology are not created
automatically; they must be added explicitly. OWL contains a variety of
constructs for representing such explicit semantic connections.The main
ones are: owl:sameAs, owl:equivalentClass, and
owl:equivalentProperty.
For example, we might specify that ontA:car is an equivalentClass to ontB:auto; or that ontA:canRunSlowly is equivalentProperty to OntB:canJog, or that OntA:venus is the sameAs OntA:morning_star. These three core mapping constructs can also be used in conjunction with arbitrary combinations of a variety of other OWL constructs (such as class forming operators) to create complex logical mappings between terms from different ontologies. For example, you might say that OntA:lifeform is the equivalentClass to [OntB:plant Union OntB:animal Union OntB:fungus] [NOTE: put the right OWL syntax here]
In summary, OWL mapping constructs can be used to specify the
logical connections between reused classes, properties, and individuals
and
those in one's ontology by means of the OWL "ontology mapping"
vocabulary.
In the next section of this document, we illustrate the use of the ontology mapping constructs for facilitating semantic interoperability by means of a series of examples.
We begin by laying out two fairly elaborate ontologies with a good deal of related and overlapping content from which examples of semantic integration will be drawn. We use a tabular format to present the content; the full OWL versions can be found HERE [TO BE ADDED]. Indentation and the ⊇ symbol are used to indicate that a class is a superclass of the immedidately subsequent classes with greater indentation. Properties are listed next to their domain classes; their ranges are indicated in parentheses. Property values for individuals are listed in parentheses. An "F" indicates that a property is functional.
NEITHER OF THESE ONTOLOGIES IS AT ALL COMPLETE FOR PURPOSES OF ILLUSTRATING THE MAPPING EXAMPLES TO COME...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CM: The mappings below are categorized as Class, Property, Individual, and "Mixed" (e.g., when an instance maps to a class). They are obviously not exhaustive, and at the moment are still rather top-of-the-head. Any and all suggestions for further, reasonably common, cogent, tricky, etc mappings appreciated.
[USUAL DESULTORY INTRO STUFF :-]
The integration of two ontologies written in OWL is in every respect no different than the construction of a single ontology containing logically related concepts. In both cases, we have classes, properties, and individuals whose logical relations require — and are amenable to — clarification.
Much of the power of OWL, especially for purposes of semantic integration, arises from the power it provides for defining "anonymous" classes by means of the two related constructs "owl:Restriction" and "owl:onProperty". For the specification of a logical relation between things in different ontologies often requires the construction of just such classes. A helpful discussion of these constructs can be found in Section 3.4 of [OWL Guide]. ...
0ne often needs to introduce an auxlilary class or property to express a bridging axiom....
CM: Seems to me [CM]
that a facility with restrictions is absolutely key to the creation of
effective mappings, and hence that it might be well to expand this
section with a number of examples, tips 'n' tricks, etc.
MFU:
maybe so, but in any event, this is more advanced stuff that should
come after the basic stuff.
In the simplest case, a class in one ontology is simply identified with a class in another — or, more generally, one class is declared to have exactly the same instances as another. Much more typically, however, the logical connections between two classes in different ontologies will be more subtle, and their expression will require the use of more complex OWL constructs.
Very often, what is intuitively the same class might be referenced two different ontologies. For example, it is reasonable to assume that O1:Airline and O2:Airline both represent the same concept. However, due to the vagaries of the different contexts in which the ontologies were created, and of the modeling styles and preferences of the ontology builders they are represented somewhat differently in the two ontologies. In this case, they associate slightly different sets of properties. A merging of the two classes may or may not be desirable. Consequently, there are two options here:
In this mapping, classes in two ontologies are declared to be identical.
[SOME SIMPLE EXAMPLES -- e.g., O1:Airport and O2:Airport; O1:City to O2:US_City]
Situation: A class in O1 is the intersection of two classes in O2.
Illustration: The class O2:JumboJet can be defined as the intersection of the class O1:Aircraft and the class of things that have an O1:seatingCapacity of at least 300.
<owl:Class rdf:Resource="O2:JumboJet">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:Resource="&O2;Aircraft">
<owl:Restriction>
<owl:onProperty "&O2;seatingCapacity" />
<owl:minCardinality rdf:Resource="&xsd;PositiveInteger"
>300</owl:minCardinality>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
Situation: A class in one ontology is the union of two classes in another.
Approach: Use "owl:unionOf" to express a bridging axiom linking the classes in question.
Illustration: O1:Commercial_Jet is a subclass of the union of O2:MidSizeAircract and O2:JumboJet
O2:Aircraft is a subclass of the union of O1:Boeing_Jet and O1:McD_Douglas:Jet
<owl:Class rdf:Resource="&O1;Aircraft">
<owl:subclassOf>
<owl:unionOf rdf:parseType="Collection" />
<owl:Class rdf:Resource="&O2;MidSizeAircraft" />
<owl:Class rdf:Resource="&O2;JumboJet" />
</owl:unionOf>
<owl:equivalentClass>
</owl:Class>
Situation: A class in one ontology can be characterized in terms of the complement of a class in another.
Discussion: Complement is naturally used to characterize classes in one ontology when they bear certain "positive" relations to some classes in another ontology, but also fail to bear certain relations to others.
Approach: owl:complementOf
Illustration: O2:Aircraft are the codes of cities that are not in Europe
Equivalent properties
Negated properties
Inverse property mapping
In this mapping, an individual in O2 is identified with an individual in O1.
<rdf:Description rdf:about="&O1:Twain">Composite Objects
<owl:sameAs rdf:resource="&O2:Clemens">
</rdf:Description>
Situation: A simple object in one ontology might be a complex object in another.
Example: A Flight in O1 might be modeled as a single object with properties departureCity, departureFlightNumber, arrivalCity, and arrivalFlightNumber. In O2, there might only be the class FlightLeg, with properties departureCity, flightNumberOf, and arrivalCity. A nonstop Flightleg — SEA2CHI, say — on this scenario might well correspond to a Flight; indeed, they are, plasuibly, one and the same entity.
<rdf:Description rdf:about="&O1:SEA2CHI">
<owl:sameAs rdf:resource="&O2:SeattleToChicago">
</rdf:Description>
But, arguably, a complex flight just is a composite of flight legs.
Flight and FlightLeg Itinerary can have several Flights Flight F can have several legs: F1 F2
Situation
A very common of choice that has to be made in the construction of an ontology is whether to model a given entity as a class or an instance. For example, it might be useful in one ontology to represent aircraft models as classes that can have specific aircraft as instances. Thus, in O1 we find that each Boeing_JetModel is a class that contains particular instances of that model. The designers of O2, by contrast, were only interested in structural issues and had no interest in recording information about specific aircraft instances, or even indicate that there are such things. Thus, in O2, the various aircraft models themselves are simply taken to be instances of the Aircraft class. Thus, what is a class from O1's perspective —737, for instance — is an individual — Boeing_737 — from the perspective of O2. Intuitively, however, these are exactly the same entity — at the least, it might be desirable for a knowledge engineer to model them as such.
Approach
To capture the appropriate mapping in such a case, the flexibility of OWL Full is required. For in OWL Full, classes can also be considered instances. Thus, in our integrated ontology, the mapping in question could be captured straightaway with "owl:sameAs":
<rdf:Description rdf:about="&O1;737">
<owl:sameAs rdf:resource="&O2;Boeing_737" />
<rdf:Description>
Illustration: Every O2:AirportCode is the value of O1:hasAirportCode on some O1:Airport. An easy way to express this in terms of OWL classes is to say that O2:AirportCode is a subclass of the class of those strings that are the value of O1:hasAirportCode for some O1:Airport. This suggests the use of owl:Restriction together with owl:onProperty. But the property that we need in order to use these constructs must be a property of strings, and O1:hasAirportCode is a property of O1:Airports. We need the property that associates a string with an airport; that is, we need the inverse of O1:hasAirportCode:
<rdf:Property rdf:ID="isAirportCodeOf">
<owl:inverseOf rdf:Resource="&O1;hasAirportCode" />
</rdf:Property>
Now we can formulate the bridging axiom in question:
<owl:Class rdf:Resource="&O2;AirportCode">
<rdfs:subClassOf rdf:Resource="&xsd:String">
<owl:Restriction>
<owl:onProperty rdf:Resource="#isAirportCodeOf" />
<owl:someValueFrom rdf:Resource="&O1:Airport" />
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
The seatingCapacity restrictions in O1 can be mapped to O2:hasMinCapacity and O2:hasMaxCapacity.
Semantic Web and RDF and OWL do not constitute a silver bullet for semantic interoperability. Agents need to share and reuse ontologies published in RDFS and OWL, reuse them correctly and consistently, or create correspondences between terms in different ontologies, if they choose to reuse different ones. More specifically, there are several requirements for semantic interoperability that must be addressed by other tools or by the social structure:
Incorrect or inconsistent reuse of ontologies: Reusing ontologies is hard, just like reusing software code. The Semantic Web makes it likely that people will reuse (portions of) ontologies incorrectly or inconsistently. However, semantic interoperability will be facilitated only to the extent that people reference and reuse public ontologies in ways that are consistent with their original intended use. For instance, if an agent uses the property DC:author to represent anything other than the author of the document, interoperating with others that use the property correctly will be a problem.
Need to find mappings between ontologies If two agents operating in the same domain choose to use different ontologies, the interoperability problem will still exist even if their ontologies and data are in OWL and RDF. The agents will then need to create mappings between terms in their respective ontologies, either manually or with the help of tools. While OWL provides some constructs to express the mappings, it does not free users from the necessity to find and declare these mappings.
String functions: Can illustrate with O1 and O2: flightNumber is an integer in O1 that is combined with airlineCode; flightNumber in O2 is the combination a string consisting of the concatenation of an airline code and (the string for) an integer.
More expressive rules and constructs for mappings: some of the mappings between ontologies required for interoperability between them may require constructs that go beyond the expressiveness of RDF and OWL, such as operations on numbers and strings, @@ another example here
"The language should support string concatenation and simple pattern matching. These features can be used to establish interoperability between ontologies that treat complex information as a formatted string and those that have separate properties for each component. For example, one ontology may represent an e-mail address as a single string, while another may divide it into a string for user name and a string for server name. To integrate the two ontologies, one would need to specify that the concatenation of the user name, the '@' character, and the server name is equivalent to the single value used in the first ontology."
[1] http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0091.html
[2] http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0016.html
[3] http://lists.w3.org/Archives/Public/public-swbp-wg/2004Jul/0009.html
[4] http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#reification
[5] http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue
[6] de Bruijn, J., Foxvog, D., Zimmerman K., Ontology Mediation Patterns Library V1