Achieving Semantic Interoperability Using RDF and OWL – v4

by Mike Uschold

Submitted to:

SWBPD Working Group

Contact Information:

Boeing, Phantom Works

P.O. Box 3707,m/s 7L-40

Seattle, WA USA

98124-2207

Tel: +1 425 865-3605

Fax: +1 425 865-2965

Email: michael.f.uschold@boeing.com

STATE OF THIS DRAFT :

This is an outline of a draft with some sketchy notes.

Abstract

RDF and OWL have been designed, in part, to overcome the challenges of pervasive semantic heterogeneity. This note provides guidance on how RDF and OWL may be exploited to help achieve semantic interoperability. 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 between their different vocabularies.

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

1 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 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 equivalences between different ontologies.

2 What do we mean by Semantic Interoperability?

Semantic interoperability is about enabling different agents, services, and applications to exchange information, data, and knowledge in a meaningful way (one 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 just to transmit data between systems: does 32 mean your age, or the temperature? To a supplier, the delivery date is the date the product is shipped. To the buyer delivery date is the date received.

Semantic interoperability means avoiding the potential pitfalls that commonly arise when exchanging information. It is about ensuring that the meaning is preserved from one system or agent to another.

2.1 Use Cases

Ontology engineering – syntactic interoperability of semantic artifacts
Application interoperability - hub spokes

3 Semantic Interoperability and the Semantic Web

Semantic Web and the Semantic Web languages provide both the social structure and the technical means to facilitate semantic interoperability. At the same time, simply expressing ontologies in RDF or OWL does not solve the interoperability problem: agents must either share and reuse ontologies to describe the meaning of their data and processes, or, if they use different ontologies or schemas, to establish correspondences between classes, properties, and individuals in their respective ontologies, thus creating a mapping between ontologies.

3.1 What Semantic Web gives interoperability

Semantic Web provides the infrastructure, standard languages, and the technical means to support semantic agreement between different agents. Say something about why ontologies in general help semantic interoperability – explicit assumptions that one can examine, etc.

The Semantic Web infrastructure encourages and supports publication of ontologies. This infrastructure will hopefully encourage agents to reuse existing ontologies rather than create new ones. When two agents use the same ontology, semantic interoperability between then is greatly facilitated: They share the same vocabulary and the understanding of what classes, properties, and individuals in that vocabulary mean, and how they relate to one another. Easy access to and availability of ontologies in standard formats that the Semantic Web infrastructure provides, should enable and facilitate such reuse.

W3C recommendations for RDF, RDF Schema, and OWL, establish a set of standard XML-based ontology languages for the first time. While formal ontologies have existed before, they all used different languages, underlying knowledge models, and formats. Having a set of standard languages for ontology interchange and reuse should also facilitate and encourage reuse of ontologies.

Semantic Web languages, such as RDF and OWL, provide the technical means to facilitate interoperability:

namespace and URIs in RDF and OWL, and imports in OWL, enable specific references from concepts in one ontology to concepts in another ontology, thus providing technical means for the ontology reuse. For instance, a user developing an application that deals with wines can declare his specific wine individuals to be instances of the Wine class defined in a shared ontology elsewhere.
languages constructs in OWL to relate meaning of concepts from different ontologies (owl:sameAs, owl:equivalentClass, owl:equivalentProperty)

We describe these concepts and provide examples of their usage to facilitate semantic interoperability below.

3.2 What Semantic Web does not provide for interoperability

Semantic Web and RDF and OWL are not 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
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

4 Explicit support provided by OWL

There are two main ways in which RDF and OWL support interoperability.

by making it easy to import and reference other ontologies or individual terms from one or more different ontologies. This is done by incorporating namespaces and URIs into OWL.
by providing ways to relate the meaning of terms from different ontologies (i.e. mapping)

@@It is critical that in this section, there are some good examples with code. Perhaps we can have a simple usage scenario where we reuse one ontology and create a mapping to another. Ideally, the latter will also involve things that OWL cannot do, such as numeric calculations, concatenations, etc.. Any ideas?

4.1 Namespaces, Import and URIs

Give a few paragraphs explaining this, and some examples of how you can get reuse of existing concepts from ontologies, or whole ontologies. Give some specific code examples.

The first supports plug and play among different ontologies, and can be seen as the foundation for making the Semantic Web possible. It supports reuse and sharing of ontologies.

4.2 Mapping

Introduce and explain the following. What are they good for, what are their limitations.

same_as
equivalent_class
equivalent_property

NB when using OWL-DL, you have a rich language for specifying necessary conditions, or necessary and sufficient conditions.

Need some good examples.

Jim Hendler referred to Network Inference doing this. Are there any examples?

Deborah talked about this: are there any examples?

5 Examples

2 simple ontologies w/ some overlap
import one into the other

little overlap
lots of overlap

Enrichment / Bridge axioms

outer level: sameAs, equivalentClass<Property>, differentFrom
plus other language constructs as needed for inner details

6 Considerations

beware of over-enrichment w/ bridge axioms, run risk of inconsistency
use reasoner to check consistency

7 Conclusions and Recommendations

OWL and RDF provide the infrastructure and technical means to achieve semantic interoperability in a range of situations. Users and application developers are cautioned not to regard OWL and RDF as a silver bullet for semantic interoperability. Rather, it provides some very important first steps.

If we can, it might be nice to say something along these lines.

If you want to do X, then you can go ahead with OWL as it is, and get along fine.

If you want to do Y, then you can proceed, but do so with caution. Realize the pitfalls.

If you want to do Z, then there is little or no support provided by OWL at this time.

8 Appendix

8.1 owl:sameAs

The built-in OWL property owl:sameAs links an individual to an individual. Such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity".

For individuals such as "people" this notion is relatively easy to understand. For example, we could state that the following two URI references actually refer to the same person:

<owl:sameAs rdf:resource="#BillClinton"/>

</rdf:Description>

The owl:sameAs statements are often used in defining mappings between ontologies. It is unrealistic to assume everybody will use the same name to refer to individuals. That would require some grand design, which is contrary to the spirit of the web.

In OWL Full, where a class can be treated as instances of (meta)classes, we can use the owl:sameAs construct to define class equality, thus indicating that two concepts have the same intensional meaning. An example:

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

<owl:sameAs rdf:resource="http://sports.org/US#SoccerTeam"/>

</owl:Class>

One could imagine this axiom to be part of a European sports ontology. The two classes are treated here as individuals, in this case as instances of the class owl:Class. This allows us to state that the class FootballTeam in some European sports ontology denotes the same concept as the class SoccerTeam in some American sports ontology. Note the difference with the statement:

which states that the two classes have the same class extension, but are not (necessarily) the same concepts.

NOTE: For details of comparison of URI references, see the section on RDF URI references in the RDF Concepts document [RDF Concepts].

8.2 owl:equivalentProperty

The owl:equivalentProperty construct can be used to state that two properties have the same property extension. Syntactically, owl:equivalentProperty is a built-in OWL property with rdf:Property as both its domain and range.

NOTE: Property equivalence is not the same as property equality. Equivalent properties have the same "values" (i.e., the same property extension), but may have different intensional meaning (i.e., denote different concepts). Property equality should be expressed with the owl:sameAs construct. As this requires that properties are treated as individuals, such axioms are only allowed in OWL Full.

8.3 owl:equivalentClass

AXIOM SCHEMA: class description owl:equivalentClass class description

A class axiom may contain (multiple) owl:equivalentClass statements. owl:equivalentClass is a built-in property that links a class description to another class description. The meaning of such a class axiom is that the two class descriptions involved have the same class extension (i.e., both class extensions contain exactly the same set of individuals).

In its simplest form, an equivalentClass axiom states the equivalence (in terms of their class extension) of two named classes. An example:

<owl:Class rdf:about="#US_President">

</owl:Class>

NOTE: The use of owl:equivalentClass does not imply class equality. Class equality means that the classes have the same intensional meaning (denote the same concept). In the example above, the concept of "President of the US" is related to, but not equal to the concept of the principal resident of a certain estate. Real class equality can only be expressed with the owl:sameAs construct. As this requires treating classes as individuals, class equality can only be expressed in OWL Full.

Axioms with owl:equivalentClass can also be used to define an enumerated class by linking a type 1 class description (a class identifier) to a type 2 class description (an enumeration). An example:

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

<owl:equivalentClass>

<owl:Class>

<owl:oneOf rdf:parseType="Collection">

</owl:oneOf>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

This class axiom defines the class of operas that together represent the "Da Ponte operas of Mozart" (a popular subject in musicology). By using the equivalentClass construct we can state necessary and sufficient conditions for class membership, in this case consisting of an enumeration of three individuals, no less, no more.

NOTE: OWL DL does not put any constraints on the types of class descriptions that can be used as subject and object of an owl:equivalentClass statement. In OWL Lite the subject must be a class name and the object must be either a class name or a property restriction.

NOTE: Although in principle different types of class descriptions are allowed as the subject of an equivalentClass statement, in practice it usually is some class identifier. This is also true for the examples in this section.

It is possible to have multiple equivalentClass axioms about the same class. However, this requires care. Both axioms must lead to the same outcome, i.e. exactly the same class extension. For example, an alternate equivalentClass axiom for Mozart's "Da Ponte operas" could be the following one:

<owl:Class rdf:about="#DaPonteOperaOfMozart">

<owl:equivalentClass>

<owl:Class>

<owl:intersectionOf rdf:parseType="Collection">

<owl:Restriction>

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

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

</owl:Restriction>

<owl:Restriction>

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

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

</owl:Restriction>

</owl:intersectionOf>

</owl:Class>

</owl:equivalentClass>

</owl:Class>

This states that the class extension of the Da Ponte operas of Mozart corresponds exactly to those operas which are composed by Mozart and for which the libretto is written by Da Ponte (note: intersection = "and"). This axiom indeed defines a class with exactly the same instances as the previous axiom.

NOTE: If we wanted to "upgrade" an axiom of the form "A subClassOf B" to "A equivalentClass B" (meaning that the class extension of A is not just any subset, but in fact the same set as the class extension of B), we could add a second subClassOf axiom of the form (B subClassOf A), which by definition makes the two class extensions equivalent (and thus has the same meaning as "A equivalentClass B"). Such subClassOf "cycles" are explicitly allowed. As OWL is usable in a distributed environment, this can be a useful feature.

[*] Invited Talk, ISWC, October 2003, Sanibel, Florida