Semantic Integration & Interoperability Using RDF and OWL

W3C Editor's Draft 3 November 2005

This version:
Latest version:
Previous versions
This is the first public Draft
Mike Ushold, The Boeing Company
Christopher Menzel, The Boeing Company
Natasha Noy, Stanford University
Deborah McGuinness, Stanford University
Patrick J. Hayes, IHMC


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.

Status of this Document

This is a very preliminary and incomplete draft of this note for review withing the OEP group:

At this point editorial feedback from outside OEP probably would not be useful, as the draft is expected to change.

[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.

Use Cases 

What do we mean by Semantic Interoperability?

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.

Semantic Interoperability and the Semantic Web: Some Basic Guidelines

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 1: To facilitate interoperability, create new ontologies in OWL.
To the extent that these languages come into standard usage for building ontologies on the WWW, the problem of differing, often syntactically or semantically ill-defined representation languages simply goes away.   Therefore, whenever possible, use OWL  when building new ontologies. This will help ensure interoperability, at least a the language level. Unfortunately, of course, many existing ontologies are not written in OWL, this gives rise to the second principle.

Principle 2: To facilitate interoperability, translate existing ontologies into OWL.
If you have ontologies already, written in a language other than Owl, interoperability will be served if you translate them into OWL. Unfortunately,  and there is no general, foolproof, automated method for translating an ontology written in some other KR language into OWL. The difficulty of the task, however, varies significantly from language to language. Notably, an ontology written in a frame-style language like Ontolingua, LOOM, or CLASSIC will translate much easier into OWL than will an ontology written in a full, unrestricted first-order language like KIF, as OWL is itself a descendent of frame-style languages — classes and binary relations — a.k.a. properties, or “slots” — are part of its basic representational apparatus. Hopefully, however, the problem of translation that will diminish over time as OWL is more widely adopted for the creation of new ontologies. 

The first two principles are about having all ontologies represented 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, is says exactly what is meant by saying that a relationship is transitive, or that in individual is a member of a class.  Second, OWL specifies how the meanings of complex syntactic constructs generated by the grammar of the language depend systematically on the meanings of their simpler parts.  For example, if you know the precise meaning of the Animal and Plant classes, and [from the OWL language spec] you know the meaning of the reserved word 'Union' [NOTE: put the right OWL construct here] you can know exactly what 'Animal Union Plant' means [NOTE: put the right OWL expression here].

The semantics of OWL, however, are silent on our knowledge engineer's domain specific vocabulary. Hence, if this ontology is to be shared with or reused by someone who does not share the ontology creator's understanding of the domain specific vocabulary, the meanings of terms in that vocabulary must be captured somehow. And this is really where the semantics gets into the Semantic Web.  This gives rise to our next principle:

Principle 3: To facilitate interoperability, reduce ambiguity by expressing more meaning.

In the context of the Semantic Web, ontology creation takes on an entirely new and exciting guise. First, under the current paradigm, web page content is expressed largely in terms of unstructured text and graphics. OWL's constructs open up the possibility of much richer content — essentially, it is what puts 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 all you say about your class is that it has the name "Animal", then for a start, only English speaking people will have any idea what it might mean. All we know from the semantics of OWL is that 'Animal" denotes a set of individuals.   If you in addition, say that the class Animal is a subclass of PhysicalObject, then this is expresses more meaning, and further reduces ambiguity.   If you specify 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, you can also indicate what relations have the class Animal in their Domain or Range, you can specify whether those relations are transitive, or not etc.

Expressing more meaning in your 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. 

Each thing you say about the terms in your 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 invididuals named in one's 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 full use of OWL's reserved vocabulary to axiomatize the classes, properties, and individuals in an ontology.

Principle 4: To facilitate interoperability, 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 constucts 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 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.

Two Ontologies

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.


Ontology 1

Classes Properties Restrictions Individuals
Commercial_Jet seatingCapacityOf (posint) - F    


A300   (≥ 220 seatingCapacity)
(≤ 336 seatingCapacity)

A380   (= 555 seatingCapacity)  

737   (≥ 100 seatingCapacity)
(≤ 162 seatingCapacity)

747   (≥ 397 seatingCapacity)
(≤ 544 seatingCapacity)

767   (≥ 216 seatingCapacity)
(≤ 290 seatingCapacity)

MD80   (≥ 142 seatingCapacity)
(≤ 172 seatingCapacity)

DC10   (≥ 270 seatingCapacity)
(≤ 380 seatingCapacity)
Airline hasAirlineCode (string) – F   Continental ("CO")
United ("UA")
British_Airways ("BA")
American ("AA")
Airport hasAirportCode (string) – F
locatedIn (City) – F
  OHare_Intl ("ORD", Chicago)
SeaTac_Intl ("SEA", Seattle)
Kennedy ("JFK", New York)
San_Francisco_Intl ("SFO", SF)
La_Guardia ("LGA", New York)
City     Seattle
San_Francisco [SF]
Flight flightNumberOf (integer) – F
airlineOf (Airline) – F
hasLayover1 (Airport) – F
hasLayover2 (Airport) – F
arrivalAirportOf (Airport) – F
departureAirportOf (Airport) – F

Ontology 2

Classes Properties Restrictions Individuals
Aircraft hasMaker (Aircraft_Company) – F
hasMinCapacity (posint) – F
hasMaxCapacity (posint) – F
SmallAircraft     ERJ_135
MidSizeAircraft     Airbus_A300

Aircraft_Company     Boeing
Airline hasAirlineCode (string) – F   Continental ("CO")
United ("UA")
British_Airways ("BA")
American ("AA")
Airport hasLocation (City) – F   ORD (Chicago)
LHR ( London)
SEA (Seattle)
JFK (New York)
SFO (San_Francisco)
LGA" ( New York)
Euro_City     London
US_City     Seattle
Flight hasFlightCode (string) – F
arrivalAirport (Airport) – F
departureAirport (Airport) – F

OWL-based Mappings

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.


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.

OWL Restrictions

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.

Class Mappings

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:

  1. Leave the two classes distinct, but declare them equivalent;  disambiguate them via distinct namespace prefixes.
  2. Define a new "merged" class that is declared to be equivalent to both of the original classes whose properties comprise the union of the properties associated with the original classes.
und so weiter...

Equivalent Classes

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]

Class to Class Mappings


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:onProperty "&O2;seatingCapacity" />
<owl:minCardinality rdf:Resource="&xsd;PositiveInteger"

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:unionOf rdf:parseType="Collection" />
<owl:Class rdf:Resource="&O2;MidSizeAircraft" />
<owl:Class rdf:Resource="&O2;JumboJet" />

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

Enumerated Classes


Property Mappings

Property to Property Mappings

Equivalent properties

Negated properties

Inverse property mapping


Individual Mappings

Individual to Individual Mapping

Identical individuals

In this mapping, an individual in O2 is identified with an individual in O1.

<rdf:Description rdf:about="&O1:Twain">
<owl:sameAs rdf:resource="&O2:Clemens">
Composite Objects

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">

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

Mixed Mappings

Class/Instance Mapping


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.


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" />

Property Value to a Class Instance Mappings

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" />

Now we can formulate the bridging axiom in question:

<owl:Class rdf:Resource="&O2;AirportCode">
<rdfs:subClassOf rdf:Resource="&xsd:String">
<owl:onProperty rdf:Resource="#isAirportCodeOf" />
<owl:someValueFrom rdf:Resource="&O1:Airport" />

Property Value – Class Equivalence

Property-Class Mappings

The seatingCapacity restrictions in O1 can be mapped to O2:hasMinCapacity and O2:hasMaxCapacity.


Interoperability not provided by the Semantic Web

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:

OWL-inexpressible Connections



[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