Achieving Semantic Interoperability & Integration[MFU1] Using RDF and OWL

W3C Editor's Draft– 01/23/2006

This version:

Latest version:

http://www.w3.org/TR/whatever

Previous versions

This is the first public Working Draft

Editors:

Mike Ushold, The Boeing Company

Christopher Menzel, The Boeing Company

Abstract

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 import, share and reuse public ontologies (in whole or part) [MFU2] and 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.

Status of this Document

This is a nearly complete first draft of this note.
The outline and structure of the document is stable.
The major change form the last version is that there is a narratave for the different OWL mapping constructs. The major content remaining to be added are the code examples.

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

Complete the examples, adding code and sufficient supplementary text.
Tidy up a bit the comments about interoperability vs. integration. The fact is, the same mapping constructs can be used for both. The distinction is an architectural one.
Use cases should probably tie in better with the text.
Say something about why Namespaces and Imports are out of scope, but that they are broadly relevant.

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.

Introduction

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.

Use Cases

Extending a single ontology: A knowledge engineer would like to start with one ontology and extend it so that it meets the needs of a particular application. This can be viewed as a “base case” of integration as the engineer is integrating the conceptual specification of her requirements with the existing ontology.

Integrate existing OWL ontologies: A knowledge engineer has distinct OWL ontologies to integrate resulting in one larger ontology[dlm3] . She largely understands the intuitive meanings of the vocabulary of the existing ontologies, either because the existing ontologies are well documented and 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 existing ontologies explicit and to generate one integrated ontology. We will refer to this as semantic integration.

Application interoperability requiring data translation: A software developer needs to have a data sent from a source application (that is expressed using the vocabulary from one ontology), to a target application that requires the data to be expressed using another ontology. The data needs to be converted to use the vocabulary of the target application. This is similar to the previous use case, in that we assume that there is a good understanding of the meaning of both ontologies, and that the main task is to specify the mappings. The primary differences from the previous use case are that there is one target ontology receiving data and there is no requirement to create one new integrated ontology.

1. Share existing ontologies[dlm4] : A knowledge engineer has a stock of legacy ontologies written in different representation languages such as Classic, Ontolingua, KIF, FLogic or other KR languages. She wants to be able to share ontologies on the web. This knowledge engineer may find that sharing ontologies is facilitated if mappings to terms in the ontologies written in the other ontologies are made explicit. Best approach is to consult [OWL Semantics] for precise account of the semantics of OWL; also CL-based axiomatic semantics [Hayes], [Menzel] [dlm5]

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.

What do we mean by Semantic Interoperability & Integration?

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?

DLM: why don’t we just say that this document focuses on a first step toward semantic interoperability as facilitated by semantic integration that is accomplished using a set of formal statements of logical relationships between terms. Some have referred to this as articulation, or bridging, axioms.

MFU: the data translation use case is very definitely semantic interoperability, not integration, so I think we are doing both. Hence, I added ‘integration’to the title of the note.

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. Semantic interoperability usually means that the original systems and ontologies remain intact. Semantic integration usually means that there is some merging of the ontologies or applications. For this note, we will use the term ‘semantic I&I’ to refer to both semantic interoperability and semantic integration. 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 [MFU6] 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. [dlm7] 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). 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.

Semantic I&I and the Semantic Web: Some Basic Guidelines

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.
To the extent that recommended standard ontology languages come into broader usage for building ontologies on the WWW, the problems of syntactically different or semantically ill-defined representation languages is minimized. Therefore, whenever possible, use OWL when building new ontologies. This will help ensure semantic I&I, at least at 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 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[dlm8] .

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

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 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 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 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. 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.
[MFU10]
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 – comment – we should be careful not to encourage people to model a lot information that is not expected to be useful. For example, many people do not like using CYC’s upper level because it is viewed as having too many upper level concepts that “clutter” an application when they are all inherited. We probably want to draw a fine line here.]

MFU: True, and here ‘useful’ means more than just what a given ontology is intended for. When building an ontology for a specific purpose, you definitely would not want to add lots of axioms that would likely never get used in any application. However, it is also true that to facilitate semantic I&I, one can argue that to a large extent, the more meaning the better – the more meaning, the easier it will be for humans, or automated mapping assistants to understand the meaning of the terms, which is needed to map them. It is a tradeoff, to be sure. There is an analogy with db schema development. Often, DB constraints that are true, and could be expressed, and which would help on understand the meaning of the data, are SPECIFICALLY NOT put in, due to possible performance impact. The tradeoff is understandabilty vs. performance. The same might apply in ontology development.

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 [MFU11] 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. [MFU12] This mechanism enables a single core term to be used in both ontologies, each having a different meaning (this mechanism also preserves provenance information). [MFU13] In the event that the meanings are the same, or closely related, it is important [MFU14] to specify the semantic connection between them. This is done by using various mapping constructs in OWL.

MFU: expand this section to include various use cases for when an ontology to ontology mapping might be needed or useful. Distinguish interoperability from integration use cases, perhaps. Then, we might want to shorten what is below, and just a breif section about the kinds of mappings. This would be elaborated on in much more detail in the main ‘narrative’ below. Here, you woud probably skip OWL syntax. I grayed out the text below, and used it as a starting point for the narrative. We need to come back to here and replace the gray text with a suitable summary of the key points. It might juust be a few sentences, or somethigne a bit more elaborate. Given this is the main meat of the note, it bears repeating for emphasis.

The simplest mapping constructs declare exact logical equivalence; these 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, an ontology designer might say that OntA:lifeform and [OntB:plant Union OntB:animal Union OntB:fungus] are equivalentClass(es). [NOTE: put the right OWL syntax here. Mike: actually, you should have English as well as the OWL code.]

Additionally, logical connections may be specified that go beyond simple equivalence statements. If an ontology designer was not interested in fungus, s/he might say that [OntB:plant Union OntB:animal] isSubClassOf [OntA:lifeform]. As a more complex example, an ontology designer may find that they want to state that their car class is defined as a subclass of the ontB:auto class along with being a subclass of a new restriction class (that may restrict the range of a particular property). [MFU15] In this way, OWL constructs may be used to express formal logical relationships between either existing terms across multiple ontologies or formal relationships between existing ontology terms and a new ontology term.

In summary[MFU16] , 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 vocabulary.[dlm17]

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.

OWL-Based Mappings: Overview

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[MFU18] :morning_star. 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 t~~The core OWL mapping constructs [MFU19] ~~to be~~are: owl:equivalentClass, owl:equivalentProperty, owl:sameAs, owl:subClass and owl: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. For Iin 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~~y designer~~ 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. In the same way, Oone can also use OWL restrictions to define classes that enable one to express even more subtle in ~~class~~ 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; more exactly:

<owl:Class rdf:resource=”&OntA;bicycle”>

<rdfs:subClassOf>

<owl:restriction>

<owl:onProperty rdf:resource=”&OntB;hasWheels”>

<owl:cardinality rdf:datatype=”&xsd;nonNegationInteger”

>2</owl:cardinality>

</owl:Restriction>

</rdfs:subClassOf>

</owl:Class>

[CPM�Ⰶ⤀뿿�20]

~~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.[1] 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. [MFU21] 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. [MFU22]

The core mapping constructs are distinguished in that they play a primary role in mapping; you cannot create mappings without them[MFU23] . 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[MFU24] .

In the next section, we look at more examples of mappings using OWL, in the context of a realistic example.

OWL-Based Mappings: Detailed Example

In this section, we give more elaborate examples illustrating the above scenarios and others in the context of mapping between two independently created airplane ontologies. The need to create such mappings could arise if two travel companies merged, and each used different ontologies. We first present the ontologies, and then we illustrate how OWL can be used to map between them.

Two Ontologies

We begin by laying out two ontologies with a good deal of related and overlapping content from which examples of semantic mapping will be drawn. We use a tabular format to present the content; the full OWL [dlm25] versions can be found HERE [TO BE ADDED]. Indentation and the ⊇[MFU26] symbol are used to indicate that a class is a superclass of the immediately 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 [dlm27] FOR PURPOSES OF ILLUSTRATING THE MAPPING EXAMPLES TO COME...

Ontology 1

Classes			Properties	Restrictions	Individuals
Commercial_Jet			seatingCapacityOf (posint) - F
⊇	Airbus_Jet
	⊇	A300		(≥ 220 seatingCapacity) (≤ 336 seatingCapacity)
	⊇	A380		(= 555 seatingCapacity)
⊇	Boeing_Jet
	⊇	737		(≥ 100 seatingCapacity) (≤ 162 seatingCapacity)
	⊇	747		(≥ 397 seatingCapacity) (≤ 544 seatingCapacity)
	⊇	767		(≥ 216 seatingCapacity) (≤ 290 seatingCapacity)
⊇	McD_Douglas_Jet
	⊇	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] Chicago New_York
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 ERJ_145
⊇	MidSizeAircraft				Airbus_A300 Boeing_737 Boeing_767 MD_80 ERJ_190
⊇	JumboJet				Airbus_A380 Boeing_747 MD_DC10
Aircraft_Company					Boeing Airbus Embraer
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)
City
⊇		Euro_City			London Paris
⊇		US_City			Seattle San_Francisco Chicago New_York
Flight			hasFlightCode (string) – F arrivalAirport (Airport) – F departureAirport (Airport) – F

Mapping Examples

Class Mappings

A good place to start when mapping two ontologies, is to identify classes that are logically equivalent. Here is a simple example:

Note that if the names of the classes in both ontologies are already the same, you still have to explicitly state their equivalence. This is because even though the base names are the same, the actual name includes the namespace, and this makes the two names different. OWL does not make a unique names assumption.

In searching for simple cases of identical classes from both ontologies, you will likely find cases where there is no exact match in the other ontology. However, there may be a subclass relationship between two different classes.

Or you may find that there are classes from both ontologies that are known to be disjoint, or non-empty.

Or you may find that there is a set of classes from both ontologies that forms a partition.

You may also discover that a class in one ontology is equivalent to, or a subclass of some combination of classes in the other ontology using the set operators, union, interesection and complement. Here are some simple examples:

What you do next may depend on your preference, and your knowledge of the two ontologies. If you are already familiar with the properties in the two ontologies, you might notice that you can use restrictions to state a subclass or equivalence relationship between two classes. For example:

<code example: Restriction: O1: AircraftCompany is a Company sellsProduct someValuesFrom Aircraft

Anotehr Restreiction: using complemen>

Property Mappings

At some point, you will need to do a thorough examination of all the properties in each ontology to identify any equivalent properties.

As for classes, you may find properties that are not equivalent, but where one is a subproperty of the other.

Note that as for classes, if the property names are the same in the two ontologies, their namespaces are not, therefore if you have determined that they are identical, you have to declare them to be equivalent. Two classes or two properties can have the same name in the two ontologies, and not have the same intended meaning. If the meaning of the two is unrelated, then you don’t have to specify anything – the uniquie namespaces distinguish them. Of course, this can be confusing, because the names being the same will suggest that they have the same meaning. If the two are identical in meaning, or one is a subclass or sub-property of the other, that has to be specified using the appropriate core OWL mapping construct. This can also be confusing, to specify that OntA: plane is a subclass of ontB:plane will seem jarring at first. Determining the relative meaning of different terms can be difficult – two important sources of information are the documentation and the axioms.

While equivalence, subclass and subproperty are the main ways to specify the relationship between the meaning of terms in different ontologies, there are other useful mapping relationships. For example, you could can specify that the union or intersection of classes from different ontologies are non-empty. You can state that two classes from different ontologies are disjoint. Partitions are also useful for creating mapping axioms.

Also examples for coverings and disjoint coverings.

[MFU28]

Nb That unlike for classes, you can’t have property expressions. Ther eare no analogous property-forming operators.

Instances / Individuals

Some sameAs and differentFrom examples.

Maybe also give some examples of class expressions with individuals in them using oneOf, for example.

Note that unlike for calsses, where you can have expressions, yo ucant for individuals. Technically this would be a ‘definite description’ except in OWL_Full.

Give an example in OWL-Full

Some More Complex Examples

A couple harder examples with more complex expressions, possibly some nuances… mayber 2-3 steps to build up the example, where the result is: hey, this is neat, but it is also a bit of work to get it right.

Use datatypes somewhere in the examples, either here or above.

Notes on a New Strategy / Narrative

Ontology example:

Don’t do datatypes first, use simple object properties instead.

Make sure to include subclass mappings, as well as equivalent.

Can say that Unions and Intersections are non-empty.

Complement, Disjointness, Partitions also are useful mapping axioms.

If have 3 subclasses of A, it is disjoint from other disjoint coverings… (see prior Deb message)

Covering: full containment (really subclass relationship) contextual notion of subclass. MOre than subclass.

COvering implies a partitioning?

Disjoint covering is a partition.

Enogh examples to clue folk in that there are interesting logical relationships using set constructors.

Strategy:

1. simple equivalence

2. branch out

a. add restriction on one class

b. do some union/intersetcion, complement examples

Equivalence: Start with two classes that have same name and relate them, also different names, and relate those too. Message: just because name is same, not mean don’t have to say equivalent, really difference, because of namespace.

Subclass Relation: Aircraft, commercial jet

Intersection: Aircraft is subclass of Union..

Restriction: O1: AircraftCompany is a Company sellsProduct someValuesFrom Aircraft

Anotehr Restreiction: using complement

Properties: same script

two same name properties

two different-name properitese

one sub-property

Instances: sameAs and differentFrom

NOte: unlike for classes, where you can have class expressions, you cannot have individual expressions. [definite descriptions, in technical terms] Except in OWL-Full

Then some simple things that just cannot do:

· rules with variables

· procedures.

· string matching

Complexities for later:

· While in OWL, there are no definite descriptions, (expressions that evaluate to an instance), but there are in RDF. Can do in OWL-Full

· acomments about allDifferentFrom

Limitations on OWL for Achieving Semantic I&I

Then some simple things that just cannot do:

· rules with variables

· procedures.

· string matching

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.

Straight forward intersections can introduce inconsistencies: if two terms are intersected, restrictions may intersect in ways that have unintended consequences. For example, if one class has a property, such as the class car having a property hasManufacturer and the same class name in another ontology has the same property but if the two ontologies have disjoint restrictions on the property, then a maximum cardinality restriction of 0 will be inferred on the conjoined class. Addtitional tool support can help identify such issues, but humans are likely to be needed to resolve many of the issues.

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

OWL-inexpressible Connections

The concatenation of the initial two of characters of an O2:hasFlightCode are in the range of O1:airlineCodeOf.
The result of removing the initial two of characters of an O2:hasFlightCode is a string of digits whose value is an xsd:PositiveInteger.

Note these expressive limitations are explicitly noted in "OWL Web Ontology Language Use Cases and Requirements" (http://www.w3.org/TR/webont-req/#section-objectives):

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

Issues

Some ontologies will use names to indicate instances. Other ontologies will mention names and have an explicit Name property.
Property value vs class
Many more issues...

References

[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

When connectivity is restored, add references to ontolingua and chimaera.

Ontology example:

Don’t do datatypes first, use simple object properties instead.

Make sure to include subclass mappings, as well as equivalent.

Can say that Unions and Intersections are non-empty.

Complement, Disjointness, Partitions also are useful mapping axioms.

If have 3 subcvlasses of A, is is disjoint from other disjoint coverings… (see prior Deb message)

Covering: full containment (really subclass relationship) contextual notion of subclass. MOre than subclass.

COvering implies a partitioning?

Disjoint covering is a partition.

Enogh examples to clue folk in that there are interesting logical relationships using set constructors.

Strategy:

3. simple equivalence

4. branch out

a. add restriction on one class

b. do some union/intersetcion, complement examples

Subclass Relation: Aircraft, commercial jet

Intersection: Aircraft is subclass of Union..

Restriction: O1: AircraftCompany is a Company sellsProduct someValuesFrom Aircraft

Anotehr Restreiction: using complement

Properties: same script

two same name properties

two different-name properitese

one sub-property

Instances: sameAs and differentFrom

NOte: unlike for classes, where you can have class expressions, you cannot have individual expressions. [definite descriptions, in technical terms] Except in OWL-Full

Then some simple things that just cannot do:

· rules with variables

· procedures.

· string matching

Complexities for later:

· While in OWL, there are no definite descriptions, (expressions that evaluate to an instance), but there are in RDF. Can do in OWL-Full

· acomments about allDifferentFrom

Old Stuff, may be Obsolete?

In this section, we introduce a variety of constructs that

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.

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.

DLM: I think the first thing to present is class equivalence and then show an example of adding a restrition to the class using a local range restriction (using all Values From)

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, some options arise:

Leave the two classes distinct, but declare them equivalent; disambiguate them via distinct namespace prefixes [dlm29] .
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.
Creat subclasses of one or both of the classes adding selected restrictions as chosen from the other class.

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

Intersection

Situation: A class in O1 is the intersection of two classes in O2.

Illustration:[dlm30] 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>

Union

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[dlm31] 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>

Complement

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

</rdf:Description>

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, plausibly, 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

Mixed Mappings (crossing object types)

Class/Instance Mapping

Situation

A very common 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>

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

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

Property Value – Class Equivalence

Property-Class Mappings

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

LOTS MORE CASES OF MAPPINGS... [dlm32]

Notes> One can do arbitrary combinations of class formation and logical

> operators for stating class equivalence.

> What, if any interesting expressions of a similar ilk can be made for

> stating property equivalence or that two individuals are the same?

> In other words, are there any 'property-forming' or 'individual-forming'

> operators in OWL?

There's owl:equivalentProperty for stating eqivalence, but there are no analogues of the boolean operators, or of restrictions, for properties.

> How would I say that the sibling is in some sense the union of brother

> and sister (thinking of the sets of tuples)?

Alas, you can't! I suspect the addition of a union operator on properties would lead to computational intractability.

> How would I say that one of the editors of this note also authored the

> paper: "Where are the semantics in the semantic web?" using the sameAs

> construct?

In this case you could use class constructs; I don't have the time to construct proper OWL at the moment, but logically the pieces would be something like:

#WATSISW rdf:typeOf owl:Article

#WATSISW owl:hasTitle xsd:string^^"Where are the Semantics in the Semantic Web"

#SI rdf:typeOf W3C_Note

#SI owl:hasTitle xsd:string^^"Semantic Interoperatbility"

<owl:Class rdf:ID="SI_Authors">

<owl:subclassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#authorOf" />

<owl:hasValue rdf:resource="#SI" />

</owl:Restriction>

</owl:subClassOf>

</owl:Class>

<owl:Class rdf:ID="WATSISW_Authors">

<owl:subclassOf>

<owl:Restriction>

<owl:onProperty rdf:resource="#authorOf" />

<owl:hasValue rdf:resource="#WATSISW" />

</owl:Restriction>

</owl:subClassOf>

</owl:Class>

One can then say that the owl:intersectionOf these two classes is nonempty. A little more work would be needed to say that *exactly* one of the authors of SI is also an author of WATSISW.

There might be an easier way to do it. It's pretty horrible though, no? :-)

> Can you think of anything interesting to say in an expression using

> sameAs or equivalentProperty?

owl:sameAs statements are interesting only because they identify individuals referenced in different ontologies that might not have been known to be identical. Similarly for owl:equivalentProperty.

But the statements themselves are not going to be very interesting from a logical point of view.

-chris

[1] The authors of this note can’t think of one J.