W3C

OWL Guide

This version:
4 September 2002
Previous version:
29 Aug 2002
Authors:
Michael K. Smith, Electronic Data Systems, michael.smith@eds.com
Raphael Volz, Forschungszentrum Informatik (FZI), volz@fzi.de
Deborah McGuinness, Stanford University, dlm@ksl.stanford.edu
Acknowledgement:
This document represents the work of many people, in particular the members of the W3C Web Ontology Working Group and the original authors of the DAML+OIL Walkthru. Appendix B was contributed by Guus Schreiber, University of Amsterdam, schreiber@swi.psy.uva.nl.

Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

The World Wide Web as it is currently constituted resembles a poorly mapped geography. Our insight into the documents and capabilities available are based on keyword searches, abetted by clever use of document connectivity and usage patterns. The sheer mass of this data is unmanageable without powerful tool support. In order to map this terrain more precisely, computational agents require machine-readable descriptions of the content and capabilities of web accessible resources. These descriptions must be in addition to the human-readable versions of that information.

The OWL Web Ontology Language is intended to provide a language that can be used to describe the classes and relations between them that are inherent in Web documents and applications.

This document demonstrates the use of the OWL language to

  1. formalize a domain by defining classes and properties of those classes,
  2. define individuals and assert properties about them, and
  3. reason about these concepts to the degree permitted by the formal semantics of the OWL language.
The sections are organized to present an incremental definition of a set of classes beginning with the fundamentals and proceeding to more complex language components.

NOTE: Notes to be expanded or or fixed are highlighted in yellow.

Contents Update when sections complete

Introduction

"Tell me what wines I should buy to serve with the following menu. And, by the way, limit them to the following price range."

It would be difficult today to construct a Web agent that would be capable of performing a search for wines on the web that satisfied this query. Similarly, consider actually assigning a software agent the task of making a coherent set of travel arrangements. (For more use cases see the OWL requirements document.)

To support this sort of computation, it is necessary to go beyond keywords and specify the meaning of the resources described on the web. This additional layer of interpretation captures the semantics of the data.

OWL provides a language to define Web ontologies. An ontology describes the concepts in a specific domain of discourse. In the case of OWL, an ontology may include

Datatype properties and object properties are collectively the properties of a class.

Defined classes and properties can then be used to describe specific Web resources. A great deal of information may be available about an objects based on a simple categorization. Due to the properties of the class and its various parent classses, many additional derived characteristics of the instance may be entailed by the semantics of OWL.

One question that comes up when describing yet another XML/Web standard is "What does this buy me that XML and XML Schema don't?" An operational consensus can always be developed over the meaning of a set of XML tags and their contents. There is furious ongoing standards activity doing exactly this. There are two answers to this question.

History

RDF and RDF Schema (RDFS) were the first markup languages specified by the W3C for defining Web ontologies. RDFS is purposefully lightweight and very general. Like OWL, it includes classes and properties, as well as range and domain constraints on properties. It provides inheritance hierarchies for both classes and properties. Upon its release users began requesting additional features, including data types, enumerations and the ability to define properties more rigorously.

Accordingly, several research efforts were initiated to extend RDFS with more expressive constructs.

A group of European researchers, funded through the On-To-Knowledge project by the E.U., defined a language called OIL (Ontology Inference Layer). A few months later a group of U.S. researchers, funded through the DAML (DARPA Agent Markup Language) program initiated by the U.S. Defense Advanced Research Projects Agency, defined a language called DAML-ONT. As the objectives of the two groups were similar, separate efforts were deemed redundant. The languages were merged into DAML+OIL.

The outcome of the merged work of these groups, the DAML+OIL language, was submitted to W3C as a proposed basis for OWL and was subsequently selected as the starting point for OWL.

In addition to ontology languages, various taxonomies and existing ontologies are already in use commercially. In e-Commerce sites they facilitate machine-based communication between buyer and seller, enable vertical integration of markets and allow descriptions to be reused in different marketplaces. [@@ ref to Deborah VerticalNet] [@@ ref to one of the medical or drug-related ontologies?]

There exist large taxonomies in use today that would be ripe for extension into the OWL space. For example, the North American Industry Classification System (NAICS) defines a hierarchy of over 1900 elements that identify industry types. A short sample includes: 

 
11 Agriculture, Forestry, Fishing and Hunting 
111 Crop Production
...
1113 Fruit and Tree Nut Farming 
11131 Orange Groves 
11132 Citrus (except Orange) Groves 
11133 Noncitrus Fruit and Tree Nut Farming
111331 Apple Orchards 
111332 Grape Vineyards
...  
42 Wholesale Trade
421 Wholesale Trade, Durable Goods
...  
4228 Beer, Wine, and Distilled Alcoholic Beverage Wholesalers 
42281 Beer and Ale Wholesalers 
42282 Wine and Distilled Alcoholic Beverage Wholesalers
NAICS is also tied to the International Standard Industrial Classification System (ISIC, Revision 3), developed and maintained by the United Nations. A new North American Product Classification System (NAPCS) is under development, with initial focus on products of service industries.

Analogies

There are several ways to think of OWL, depending on your background.

  1. Object oriented programming: Consider classes to be object definitions, with functional properties as fields and relational properties as boolean methods.
  2. Set theory: This maps very naturally onto the semantics. Classes define sets of individuals and a property can be taken to be the set of pairs for which it is true.
  3. Logical predicates: Think of classes as one-place predicates defining types, where C(x) means that x is an element of class C. And let properties be two-place predicates.

These are approximations. To understand OWL, read on.

Structure of Document

In order to provide a consistent set of examples throughout the guide, we have adapted a wine ontology previously developed as a description logic example and tutorial.

In this document we present examples using the OWL XML syntax, assuming XML will be familiar to the largest audience. The standard for interchange of OWL assertions between tools depends on RDF triples. These XML and RDF formats are part of the standard. Other notations have been formulated, in particular a UML version. Appendix A provides links to various primers on related standards.

We expect that in the normal course of events, users will depend on tool support to develop ontologies. Thus, you may see something like 


  Class POTABLE-LIQUID : CONSUMABLE-THING
        disjointWith(EDIBLE-THING)
rather than 

  <owl:Class rdf:ID="POTABLE-LIQUID">
    <rdfs:subClassOf rdf:resource="#CONSUMABLE-THING"/>
    <owl:disjointWith rdf:resource="#EDIBLE-THING"/>
  </owl:Class>
Even more likely, you will be working with a GUI, since ontology development and maintenance tools will be graphically based.

The Structure of Ontologies

We consider an ontology to be a specification or model for a particular domain or set of domains. Given a domain, an ontology defines its basic and derived concepts and their interrelationships. As we use the term, an ontology will often include assertions about individuals in addition to classes. That is, the ontology might include a class, DOG, as well as an instance, DOG-45, the particular dog M. Smith owned from 1986 through 2000. The property NAME may be defined as a relation between DOGs and strings, while an instance of the NAME property would exist that connects DOG-45 with the specific value, "Tuxedo".

In order to write down an ontology that can be interpreted unambiguously and used by software agents we require a formal syntax and semantics. OWL provides these necessary underpinnings for ontology construction. See the formal semantics and XML syntax.

A set of OWL assertions loaded into a reasoning system is called a knowledge base (KB). These assertions may be based on a single ontology or multiple distributed ontologies that have been combined using defined OWL mechanisms. The assertions may include various derived facts, facts not literally present in the original textual representation of the ontology, but entailed by the semantics of OWL.

Namespaces

Before we can use a set of terms, we need a precise indication of what specific vocabularies are being used. Where do the terms come from? A standard initial component of an ontology includes a set of namespace declarations. These provide a means to unambiguously interpret identifiers and make the rest of the ontology presentation much more readable. A typical OWL ontology begins with a namespace declaration similar to the following. 


<rdf:rdf 
    xmlns     ="#" 
    xmlns:vin ="#"      
    xmlns:owl ="http://www.w3.org/??/owl#"
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"
    xmlns:dte ="http://www.w3.org/2003/??/owl-guide-dt#" >

The first two declarations identify the namespace associated with this document. The first makes it the default namespace, stating that unprefixed elements and empty URI references refer to the current document. The second identifies the namespace of the current document with the prefix vin:.

The third namespace declaration says that in this document, elements prefixed with owl: should be understood as referring to things drawn from the namespace called http://www.w3.org/2003/??/owl#. This is a conventional OWL declaration, required to introduce the OWL vocabulary.

OWL depends on constructs defined by RDF and RDFS. In this document, the rdf: prefix is understood to refer to things drawn from the namespace called http://www.w3.org/1999/02/22-rdf-syntax-ns#. The next two namespace declarations make similar statements about the RDF Schema (rdfs:) and XML Schema datatype (xsd:) namespaces.

This OWL document is related to a separate document containing XML Schema datatype definitions. The final declaration says that elements prefixed with dte: should be understood as referring to things drawn from the namespace called http://www.w3.org/2003/??/owl-guide-dt#, which contains the datatype definitions for this Guide document.

Ontology Headers

Once namespaces are established we begin with an assertion that what follows is an ontology.

<owl:Ontology rdf:about="">

This assertion is formulaic. The about attribute will typically be empty, indicating that the subject of this assertion is this document. Otherwise the subject of this assertion is the value specified by the current embedding base (see XML Base).

Having established the fact that we are defining an ontology and provided the necessary namespace mapping, a set of additional tags are provided to handle such critical housekeeping tasks as comments, version control and inclusion of other ontologies. 


<owl:Ontology rdf:about=""> 
  <rdfs:comment>An example OWL ontology</rdfs:comment>
  <owl:versionInfo>$Id: OwlGuide.html,v 1.0 2002/07/17 16:12:00 mksmith $</owl:versionInfo>
  <owl:imports rdf:resource="http://www.w3.org/2003/??/owl"/>
Does the '/owl; in the last line above need to end in a '#'? What about the scope of imports? This example doesn't really make sense. We need to know how to interpret owl:imports before we can import its definition. ???

<rdfs:comment> provides the obvious needed capability to annotate an ontology.

<owl:versionInfo> is a standard tag intended to provide a consistent hook for version control systems working with ontologies.

<owl:imports> provides an include-style mechanism. Importing another ontology brings in the entire set of definitions provided by that ontology into the knowledge base. In order to make best use of this imported ontology it would normally be coordinated with a namespace declaration. Notice the distinction between these two mechanisms. The owl namespace declaration provides a convenient meand to reference names from the owl definitions. Conceptually, the owl:imports is needed to bring in the knowledge base that defines the underlying ontology mechanism and thus any of the entailments that might arise due to the use of OWL.

OWL provides several other mechanisms to tie the current ontology and imported ontologies together (see ontology mapping).

This prelude is followed by the actual conceptual definitions that make up the ontology. At the end of the ontology definition will be a closing tag. 


</owl:ontology>

The Basics

Simple Classes and Individuals

Most uses of an ontology depend ultimately upon the ability to reason about individuals. In order to do this in a useful fashion we need to have a mechanism to describe the classes that individuals belong to and the properties that they inherit by virtue of class membership. We can always assert specific properties about individuals, but much of the power of ontologies comes from class-based reasoning.

Sometimes we want to emphasize the distinction between a class as an object and the set of elements of the class. We call the set of individuals that are members of a class the extension of the class.

Defining Simple Hierarchical Named Classes (class, subClassOf)

The most basic concepts in an ontology are the roots of various taxonomic trees. Every instance in the OWL world is a member of owl:Thing. Thus each of these user-defined primitive classes is implicitly a subclass of owl:Thing. Root classes are defined by simply declaring a named class.

We first create the classes of WINERY, WINE-REGION, and CONSUMABLE-THING. 


<owl:Class ID="WINERY"/> 
<owl:Class ID="WINE-REGION"/> 
<owl:Class ID="CONSUMABLE-THING"/>

Note that we have only said that there exist classes that have been given these names, indicated by the ID= syntax. Formally, we know almost nothing about these classes other than their existence, despite the use of familiar English terms as labels. And while the classes exist, they may have no members. For all we know at the moment, these classes might as well have been called XXX, YYY, and ZZZ.

It is important to realize that definitions may be incremental and distributed. We will have more to say about WINERY later.

The syntax ID="WINE-REGION" is used to first introduce a name, as part of its definition. This is the familiar ID attribute defined by XML. The concept of a wine region can now be referred to by the rdf:resource="#WINE-REGION" usage. Another form of reference uses the syntax rdf:about="#US-REGION" to extend the definition of a resource.

This use of the rdf:about="#x" syntax is a critical element in the creation of a distributed ontology. It permits the extension of the imported definition of x without modifying the original resource and supports the incremental construction of a larger ontology.

It is now possible to refer to these defined concepts in other OWL constructs by their given identifier. For the first class, within this document, we can use the relative identifier, #WINERY. Other documents may need to reference this class as well. The most reasonable way to do so is to provide a namespace definition that includes this document as a source: 


<rdf:RDF xmlns:vin="http://www.w3.org/2003/??/owl-guide#"  ... / >
Given this namespace definition, VIN:WINERY can be used to refer to the winery concept defined above. (Remember that namespaces are not really intended to identify actual documents. In the case of an imported ontology, they just need to line up with the namespace definition in that document. We often succumb to the natural inclination to make the namespace and document identical.) More literally, it is always possible to reference the full URI, http://www.w3.org/2003/??/owl-guide#winery.

Next we define US-REGION to be a subclass of WINE-REGION and CALIFORNIA-REGION to be a subclass of US-REGION. SubclassOf is the fundamental taxonomic constructor for classes. It is transitive. If X is a subclass of Y and Y a subclassOf Z then X is a subclassOf Z.

The issues surrounding a rigorous definition of geographic part/whole inclusion are many, and are not solved in this example. (An alternate region ontology can be found in Appendix B..) We treat geographic regions as elements of a simple class hierarchy, with the most specific regions as instances. These individual regions will ultimately be used to fill the slots in the wine instance REGION properties. 


<owl:Class ID="US-REGION"> 
  <rdfs:subClassOf rdf:resource="#WINE-REGION"/> 
</owl:Class> 

<owl:Class ID="CALIFORNIA-REGION"> 
  <rdfs:subClassOf rdf:resource="#US-REGION"/>
</owl:Class>

An class definition has two parts: a name introduction or reference and a list of restrictions. Each of the immediate contained expresssions in the class definitiion further restricts the members of the defined class. Class members are members of the intersection of the restrictions. The examples above only include one restriction, forcing the new class to be a subClass of some other class.

Now, it is possible to do some simple reasoning. For example, any member of the class CALIFORNIA-REGION is also a member of WINE-REGION, due to the transitive nature of the subclass relation.

We define POTABLE-LIQUID (liquids suitable for drinking) to be a subclass of CONSUMABLE-THING . 


<owl:Class ID="POTABLE-LIQUID"> 
  <rdfs:subClassOf rdf:resource="#CONSUMABLE-THING"/> 
</Class>

At this point it is possible to create a simple (and incomplete) definition for the class WINE. WINE is a POTABLE-LIQUID. 


<owl:Class ID="WINE"> 
  <rdfs:subClassOf rdf:resource="#POTABLE-LIQUID"/> 
  <rdfs:label xml:lang="en"> wine </rdfs:label> 
  <rdfs:label xml:lang="fr"> vin </rdfs:label> 
  ...  
</owl:Class>

The rdfs:label [?? owl:label ???] entry provides an optional human readable textual name for this concept. Presentation tools can make use of it. The "lang" attribute provides support for multiple languages. Neither a label nor a comment contributes to the logical interpretation of the language.

Our wine definition is still very incomplete. We know nothing about wines except that they are things and potable-liquids, but we have sufficient information to create and reason about instances.

Design for Use

Is this appropriate here?

We don't want to get deeply philosophical here, but there are obvious issues regarding when a concept is an instance and when it is a class. The fundamental driver is how the ontology is going to be used.

The original ontology had elected to make instances be particular types of wine produced by a particular winery. This does not capture the distinction between wines made in different years.

We added a subclass of WINE, VINTAGE, which has a VINTAGE-YEAR property.

In addition, wineries produce different versions of a single variety of wine. For example, Page Mill Vineyard, in 2000, sold two chardonnay's, Chardonnay Bien Nacido Vineyard and Chardonnay Arey Listwin Vineyard. Of course we can always create PAGE-MILL-WINERY-CHARDONNAY-1 and PAGE-MILL-WINERY-CHARDONNAY-2. But we have no NAME, PRICE, PRIZES, or DESCRIPTION slots for wines. These are the sort of concepts that might distinguish these two concepts. Under our current ontology they are indistinguishable.

The point of this digression is to note that the development of an ontology should be firmly driven by use cases.

Defining Individuals (Individual)

In addition to classes, we want to be able to describe their members. We normally think of these as individuals in our universe of things. owl:Individual is typically used to introduce a new individual. 


<owl:Individual ID="CENTRAL-COAST"> 
   <type rdf:resource="#CALIFORNIA-REGION"/> 
</owl:Individual>

The definition of an individual does not need to contain any further qualification. The following is identical in meaning to the definition above. 


<owl:Individual ID="CENTRAL-COAST" /> 

<owl:Individual rdf:about="CENTRAL-COAST"> 
   <type rdf:resource="#CALIFORNIA-REGION"/> 
</owl:Individual>

There are a couple of points to be made here. First, we have decided that CENTRAL-COAST is as specific as we need to get in our regional breakdown for this area. Second, there is no requirement that these two statements need to be adjacent to one another, or even in the same file. Web ontologies are designed to be distributed. They can be imported and augmented, creating derived ontologies.

Simple Properties

Defining properties (ObjectProperty, DatatypeProperty, subPropertyOf, domain, range)

This world of classes and individuals would be pretty uninteresting if we could only define taxonomies. Properties let us assert general facts about the members of classes and specific facts about individuals.

A property is a binary relation. Two types of properties are distinguished:

When we define a property there are a number of ways to restrict the elements of the relation. The domain and range can be specified. The property can be defined to be a specialization (subproperty) of an existing property. More elaborate restrictions are possible and are described later. 

<owl:ObjectProperty id="GRAPE-SLOT"> 
  <rdfs:domain rdf:resource="#WINE"/>
  <rdfs:range rdf:resource="#WINE-GRAPE"/> 
</owl:ObjectProperty>
In OWL, a sequence of statements without an explicit operator represents an implicit conjunction. They apply to their containing element. The property GRAPE-SLOT has a domain of WINE and a range of WINE-GRAPE.

Properties, like classes, can be arranged in a hierarchy. 


  <owl:ObjectProperty rdf:ID="TASTE-SLOT">
    <rdfs:domain rdf:resource="#WINE"/>
    <rdfs:range  rdf:resource="#WINE-TASTE"/>
  </owl:ObjectProperty>

  <owl:ObjectProperty rdf:ID="SUGAR">
    <rdfs:subPropertyOf rdf:resource="#TASTE-SLOT"/>
    <rdfs:range rdf:resource="#WINE-SUGAR"/>
  </owl:ObjectProperty>
TASTE-SLOT properties relate wines to the components of their taste, including sweetness, body, and flavor. SUGAR is a subproperty of the TASTE-SLOT properties, with its range further restricted to WINE-SUGAR.

It is now possible to expand the definition of WINE to include the notion that it is an element of things that stand in a GRAPE-SLOT relation to at least one WINE-GRAPE. As with property definitions, class definitions have multiple subparts that are implicitly conjoined. 


<owl:Class ID="WINE"> 
  <rdfs:subClassOf rdf:resource="#POTABLE-LIQUID"/> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#GRAPE-SLOT"/>
      <minCardinality> 1 </minCardinality>
    </owl:Restriction> 
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#REGION"/> 
      <owl:minCardinality> 1 </owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
  ...  
</Class>
The highlighed text defines an un-named class that represents the set of things with at least one grape-slot. We call these anonymous classes. Inserting this subclass restriction in the wine class definition body states that the things that are wines are also members of this anonymous class. That is, every wine must participate in at least one grape-slot relation. Additionally, every wine must come from at least one region. This cliche is presented in more detail in the section on restrictions.

Properties and Datatypes

We distinguish properties according to whether they relate resources to resources (object properties) or resources to datatypes (datatype properties). Datatype properties may range over strings or they may make use of simpleTypes defined in accordance with XML Schema datatypes.

Suppose we wanted to restrict vintages (wine-years) to years after 1700. We would create several XML Schema datatype definitions in a separate file, such as http://www.w3.org/2002/??/owl-ex-dt.xsd , which contains: 


<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 
       xmlns="http://www.w3.org/2002/??/owl-ex-dt.xsd">

  <xsd:simpleType name="year"> 
    <!-- year is an XMLS datatype based on integer --> 
    <xsd:restriction base="xsd:decimal"/> 
  </xsd:simpleType>
  
  <xsd:simpleType name="wineYear"> 
    <!-- wineYear is an XMLS datatype based on year --> 
    <!-- with the added restriction that values must be GEQ 1700 --> 
    <xsd:restriction base="year"> 
    <xsd:minInclusive value="1700"/>
  </xsd:restriction> 
  </xsd:simpleType>
</xsd:schema>

We can reference elements of this file in OWL property definitions and class restrictions. [@@ Check syntax.
Functional, transitive, symmetric, etc. properties.


I am assuming we do not have to put the full URL in for wineYear. E.g. that can we use a prefix (as for owl:collection), which normally would not have any meaning in the value of an attribute. ??] 

<owl:ObjectProperty ID="VINTAGE-YEAR"> 
  <owl:FunctionalProperty />
  <rdfs:domain rdf:resource="#WINE"/> 
  <rdfs:range  rdf:resource="dte:wineYear"/> 
</owl:ObjectProperty> 

VS

<owl:ObjectProperty ID="VINTAGE-YEAR"> 
  <owl:FunctionalProperty />
  <rdfs:domain rdf:resource="#WINE"/> 
  <rdfs:range  rdf:resource="http://www.w3.org/2003/??/owl-guide-dt#wineYear"/> 
</owl:ObjectProperty>

Properties of Individuals

First we create an instance in our REGION hierarchy, and then we define our first wine instance. 


<owl:Individual ID="SANTA-CRUZ-MOUNTAINS"> 
  <rdf:type rdf:resource="#CALIFORNIA-REGION"/> 
</owl:Individual>

<owl:Individual ID="SANTA-CRUZ-MOUNTAIN-VINEYARD-CABERNET-SAUVIGNON">
  <rdf:type rdf:resource="#CABERNET-SAUVIGNON"/> 
  <REGION   rdf:resource="#SANTA-CRUZ-MOUNTAINS"/> 
  <MAKER    rdf:resource="#SANTA-CRUZ-MOUNTAIN-VINEYARD"/> 
  <SUGAR    rdf:resource="#DRY"/> 
  <FLAVOR   rdf:resource="#STRONG"/> 
  <BODY     rdf:resource="#FULL"/> 
</owl:Individual>

Property Characteristics and Restrictions

The next few sections describe the predefined property restrictions. Tagging a property with these characteristics provides a powerful mechanism for enhancing the mechanization of reasoning with particular properties.

TransitiveProperty

A property, P, tagged as transitive satisfies the following axiom: 


P(x,y) and P(y,z) iff P(x,z)
The concept 'AncestorOf' is transitive, while 'ParentOf' is not. My mother's ancestor is my ancestor, but not my parent.

SymmetricProperty

A property, P, tagged as symmetric satisfies the following axiom: 


P(x,y) iff P(y,x)
The concept 'SiblingOf' is symmetric, while 'BrotherOf' is not. Bob is Jane's sibling and vice-versa. Bob is Jane's brother, but not vice-versa.

FunctionalProperty

A property, P, tagged as functional satisfies the following axiom: 


P(x,y) and P(x,z) -> y = z
Thus, if x is a person, then SocialSecurityNumber might be functional (ideally), while PhoneNumber would not (home, work, cell, ...).

InverseOf

A property, P1, tagged as the InverseOf P2 satisfies the following axiom: 


P1(x,y) iff P2(y,x)
Note that the syntax for InverseOf includes a property name as an argument. 

<owl:ObjectProperty rdf:ID="MAKER">
  <owl:FunctionalProperty />
</owl:ObjectProperty>
  
<owl:ObjectProperty rdf:ID="MADE-BY">
  <owl:InverseOf rdf:resource="#MAKER" />
</owl:ObjectProperty>

InverseFunctionalProperty

A property, P, tagged as InverseFunctional satisfies the following axiom: 


P(y,x) and P(z,x) -> y = z
Think of x in the above axiom as defining a unique key, in the database sense, or a distinguishing name. If property P2 is the inverse of P1, and P1 is functional, then P2 is inverseFunctional.

Property Restrictions: allValuesFrom, someValueFrom

We have already seen one way to restrict the types of the elements that make a relation. The mechanisms to date have been global. These next two, allValuesFrom and someValueFrom, are local to their containing class defintion. 


  <owl:Class rdf:ID="MEDOC">
    <owl:subClassOf rdf:about="#BORDEAUX"/>
    <owl:subClassOf 
      <owl:Restriction>
        <owl:onProperty rdf:resource="#REGION"/>
        <owl:allValuesFrom rdf:resource="#MEDOC-REGION"/>
      </owl:Restriction>
    </owl:subClassOf>
    ....
  </owl:Class>

A MEDOC is a BORDEAUX from the MEDOC-REGION. Which means that any instance of a MEDOC must come from one of the region instances PAUILLAC-INDIVIDUAL or MARGAUX-INDIVIDUAL. The allValuesFrom restriction is on the REGION instances of this Medoc class only.

In fact this definition can be strengthened, since Medoc wines are exactly the set of Bordeaux wines from Medoc. And we will see an example of how to do this later.

Simple Cardinality

We have already seen examples of cardinality constraints. To date, they have been assertions about minimum cardinality. Even more straight-forward is owl:cardinality, which permits the specification of exactly the number of elements in a relation. For example, we define VINTAGE to be a subclass of WINE with exactly one VINTAGE-YEAR. 


<owl:Class rdf:ID="VINTAGE">
  <rdfs:subClassOf rdf:resource="#WINE"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#VINTAGE-YEAR"/> 
      <owl:Cardinality> 1 </owl:Cardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

owl:maxCardinality can be used to specify an upper bound. In combination with owl:minCardinality it is possible to specify a range.

MinCardnality defaults to 0. There is no default value for cardinality or maxCardinality.

Ontology Mapping

In order for onologies to have the maximum impact, they need to be widely shared. In order to minimize the intellectual effort involved in developing an ontology they need to be re-used. In the best of all possible worlds they need to be composed. For example you might adopt a date ontology from one source and a physical location ontology from another.

It is important to realize that much of the effort of developing an ontology is devoted to hooking together classes and properties in ways that maximize implications. We want simple assertions about class membership to have broad and useful implications. This is the hardest part of ontology development. If you can find an existing ontology that has already undergone extensive use and refinement, it makes sense to adopt it.

... [@@ Challenge is when we pull in an assortment. Need facilities to ensure that the union is consistent. ]

sameClassAs, samePropertyAs

In order to tie together a set of component ontologies as part of a third it is frequently useful to be able to indicate that a particular concept in one ontology is equivalent to some concept in a second ontology. This capability must be used with care. It is fairly easy to create necessarily empty sets when combining a set of distributed definitions. If the combined ontologies disagree anywhere (all A's are B's vs. all A's are not B's), including up their class hierarchy, their extensions will be empty.

[@@ Example: waiting see where we end up with these.]

sameIndividualAs, differentIndividualFrom

This mechanism is similar to that for classes, but declares two individuals to be identical. A classic example would be: 

<owl:Individual ID="EVENING-STAR" /> 

<owl:Individual ID="MORNING-STAR"
  <owl:sameIndividualAs about="#EVENING-STAR" /> 
</owl:Individual>

Complex Classes (Axioms and Constructive Classes)

OWL provides additional constructors with which to form classes. These constructors can be used to create so-called class expressions. OWL supports the basic set operations, namely intersection, union and complement. These are denoted unionOf, intersectionOf, and complementOf, respectively. Additionally classes can be enumerated. Class extensions can be stated explicitly by means of the oneOf constructor.

Two constructors exist to ensure that class extensions must be disjoint. The DisjointWith constructor states that two class extensions must be disjoint. DisjointUnionOf is a convenience constructor that operates like the UnionOf constructor and ensures that the extensions of all involved classes are pair-wise disjoint. Is disjointUnionOf still with us? And is this a correct description? I thought it only included in the resulting set those elements that were pair-wise disjoint. Not that it imposed a restriction on its involved classes. [MKS]

Set Operators

From a semantic point of view classes are interpreted as subsets of a domain. The interpretation of a class maps every defined (was atomic) class to a set of individuals in the domain. This set of individuals is called the extension of the class. Since class extensions are sets, OWL provides the means to manipulate class extensions using basic set operators.

Intersection

The following example demonstrates the use of the intersectionOf construct. 


<owl:Class rdf:ID="WHITE-WINE">
  <owl:intersectionOf rdf:parsetype="owl:collection">
    <owl:Class rdf:about="#WINE"/>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#COLOR"/>
      <owl:hasValue rdf:resource="#WHITE"/>
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

...

<owl:Class rdf:ID="BURGUNDY">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#SUGAR"/>
      <owl:hasValue rdf:resource="#DRY"/>
    </owl:Restriction>
  </rdfs:subClassOf>
  <owl:intersectionOf rdf:parsetype="owl:collection">
    <owl:Class rdf:about="#WINE"/>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#REGION"/>
      <owl:allValuesFrom rdf:resource="#BOURGOGNE-REGION"/>
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

...

<owl:Class rdf:ID="WHITE-BURGUNDY">
  <owl:intersectionOf rdf:parsetype="owl:collection">
        <owl:Class rdf:about="#BURGUNDY"/>
        <owl:Class rdf:about="#WHITE-WINE"/>
  </owl:intersectionOf>
  ...
</owl:Class>
We first define WHITE-WINE to be the intersection of the the class WINE and the set of things that are white in color.

Classes can be identified as closed by using the attribute/value, rdf:parsetype="owl:collection" This is an important capability. It permits us to state that WHITE-WINE is exactly the intersection of the the class WINE and the set of things that are white in color. In an enumeration using oneOf it means that nothing has been left out of the set and thus nothing can be added to it.

Finally the class WHITE-BURGUNDY is the intersection of white wines and burgundies. Burgundies in turn are grown in the French region of Bourgogne and are dry wines. Accordingly all individual wines that meet these criteria are part of the class extension of WHITE-BURGUNDY.

Complement

The complementOf construct selects all individuals from the domain of discourse that do not belong to a certain class. Usually this refers to a large number of individuals: 


<owl:Class rdf:ID="NON-ADULTS">
  <complementOf rdf:resource="#ADULT"/>
<owl:Class>

This defines the class of NON-ADULTS, whose members are all individuals that do not belong to the extension of ADULT. Note that this set also includes all WINES, REGIONS, etc. It is literally the set difference between owl:Thing and ADULT. Therefore, a typical usage pattern for complementOf is in combination with other set operators: 


<owl:Class rdf:ID="MINOR">
  <intersectionOf rdf:parsetype="owl:collection">
    <owl:Class rdf:about="#PERSON"/>
    <owl:Class>
      <complementOf rdf:resource="#ADULT"/>
    <owl:Class>
  </intersectionOf>
</Class>

This defines the class MINOR as being the intersection of PERSON with the set of all individuals that do not belong to the extension of ADULT.

Union

The following example demonstrates the use of the unionOf construct. It is used exactly like the intersectionOf construct: 


<owl:Class rdf:ID="FRUIT">
  <unionOf rdf:parsetype="owl:collection">
    <owl:Class about="#SWEET-FRUIT" />
    <owl:Class about="#NON-SWEET-FRUIT" />
  </unionOf>
</Class>

This defines the class FRUIT whose extension includes both the extension of SWEET-FRUIT and the extension of NON-SWEET-FRUIT. An individual belonging both to SWEET-FRUIT and NON-SWEET-FRUIT would only appear once in the extension of FRUIT, since class extensions are sets.

Enumerated Classes

OWL provides means to define the classes via a direct enumeration its members. This is done using the oneOf constructor. Notably this defintion may closes the class extension, so that no other individuals (that were not explicitly enumerated) can be declared to belong to the class.

The following statement defines a class WINE-COLOR whose members are the individuals WHITE, ROSE, RED and GREEN: 


<owl:Class rdf:ID="WINE-COLOR">
  <rdfs:subClassOf rdf:resource="#WINE-PROPERTY"/>
  <owl:oneOf> rdf:parsetype="owl:collection">
    <owl:Thing rdf:about="#WHITE"/>
    <owl:Thing rdf:about="#ROSE"/>
    <owl:Thing rdf:about="#RED"/>
    <owl:Thing rdf:about="#GREEN"/>
  </owl:oneOf>
</owl:Class>

The first thing to understand here is that no other individuals can be a valid WINE-COLOR since the class has been defined by enumeration and closed using the parseType attribute. [@@ Have we stated this correctly?] Each element of the oneOf construct must be a validly declared individual. A individual has to belong to some class. In the above example, each individual was referenced by name. We used owl:Thing as a simple cliche to introduce the reference. Alternatively, we could have referenced the elements of the set according to their specific type, WINE-COLOR, by: 

<vin:WINE-COLOR rdf:about="#WHITE" />

Any other definitions of individuals could also be a valid element of the oneOf construct, for example: 

<owl:Individual rdf:about="#WHITE">
  <rdf:label> White </rdf:label>
</owl:Indivitual>

Disjoint Classes

OWL provides several constructs to state that the extensions of classes are disjoint.

owl:disjointWith

The pair-wise disjointness of a set of classes can be expressed using the owl:disjointWith constructor. It guarantees that an individual can only belong to one of the listed classes. 


<owl:Class rdf:ID="NON-SWEET-FRUIT">
  <disjointWith rdf:resource="#SWEET-FRUIT"/>
</Class>

<owl:Class rdf:ID="PASTA">
  <rdfs:subClassOf rdf:resource="#EDIBLE-THING"/>
  <owl:disjointWith rdf:resource="#MEAT"/>
  <owl:disjointWith rdf:resource="#FOWL"/>
  <owl:disjointWith rdf:resource="#SEAFOOD"/>
  <owl:disjointWith rdf:resource="#DESSERT"/>
  <owl:disjointWith rdf:resource="#FRUIT"/>
</owl:Class>

The first statement ensures that any fruit is either a NON-SWEET-FRUIT or a SWEET-FRUIT. An inconsistency would arise if it were both. (We later define fruit to be the union of these two classes.)

The PASTA example shows the extension to multiple classes. How do we get mutual disjointness? Do we have something like: 

<owl:disjointWith>
  <owl:class rdf:about="#PASTAMEAT"/>
  <owl:class rdf:about="#MEAT"/>
  <owl:class rdf:about="#FOWL"/>
  <owl:class rdf:about="#SEAFOOD"/>
  <owl:class rdf:about="#DESSERT"/>
  <owl:class rdf:about="#FRUIT"/>
</owl:Class>

owl:disjointUnionOf

The owl:disjointUnionOf constructor is a convenience constructor that combines the owl:unionOf constructor while making all involved classes pair-wise disjoint. The following example defines the class PRODUCT as being the union of AVAILABLE-PRODUCT and OUT-OF-STOCK-PRODUCT: 

<owl:Class rdf:ID="PRODUCT">
  <disjointUnionOf rdf:parsetype="collection">
    <owl:Class rdf:ID="AVAILABLE-PRODUCT" />
    <owl:Class rdf:ID="OUT-OF-STOCK-PRODUCT" />
  </disjointUnionOf>
<owl:Class>

This statement is equivalent to the following statements: 

<owl:Class rdf:ID="AVAILABLE-PRODUCT">
  <disjointWith rdf:resource="OUT-OF-STOCK-PRODUCT" />
</Class>

<owl:Class rdf:ID="PRODUCT">
  <unionOf>
    <owl:Class rdf:ID="AVAILABLE-PRODUCT" />
    <owl:Class rdf:ID="OUT-OF-STOCK-PRODUCT" />
  </unionOf>
</Class>

Is it? Does the first require that Available-Product and Out-Of-Stock-Product be disjoint? [MKS] Thus, the same logical information can be expressed using a variety of syntactic constructs.

Combination of Class Expressions

Class expressions can be nested without requiring the creation of names for every intermediate class. This allows the use of set operations to build up complex classes from anonymous classes or classes with value restrictions: 

<owl:Class ID="BURGUNDY">
  <owl:intersectionOf rdf:parsetype="owl:collection">
      <owl:Class about="#WINE"/>
      <owl:Restriction>
        <owl:onProperty rdf:resource="#REGION"/>
        <allValuesFrom rdf:resource="#BOURGOGNE-REGION"/>
      </owl:Restriction>
  </owl:intersectionOf>
  ...
</Class>

Here the class of BURGUNDY wines is defined as those members of WINE that come from the BOURGONE-REGION. We could have declared a new class THINGS-FROM-BOURGONE-REGION and used it as a class in the owl:intersectionOf construct. Since we do not have any other use for THINGS-FROM-BOURGONE-REGION, the declaration above is shorter, clearer and doesn't require the creation of a contrived name.

Class Expressions using sameClassAs and subClassOf

Class expressions can also be the target of sameClassAs and subClassOf constructors. Again, this avoids the need to contrive names to every class expression.

For example, we could say, that all BURGUNDY wines are dry wines. This can be expressed by saying that their property SUGAR must take the value DRY: 


<owl:Class ID="BURGUNDY">
<rdfs:subClassOf>
  <owl:Restriction>
    <owl:onProperty rdf:resource="#SUGAR"/>
    <owl:hasValue rdf:resource="#DRY"/>
  </owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

Complex Property Axioms

Raphael Volz is currently working on this.

Full Cardinality

hasValue

Usage : Wine Portal / Agent

Deb McGuinness is currently working on this.

Status

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document is a working document for the use by W3C Members and other interested parties. It may be updated, replaced or made obsolete by other documents at any time.

This document has been produced as part of the W3C Semantic Web Activity, following the procedures set out for the W3C Process. The document has been compiled by the Web Ontology Working Group. The goals of the Web Ontology working group are discussed in the Web Ontology Working Group charter.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.


Notes

Note 1
Text.
Note N
Text.

References

Related OWL

Requirements
Requirements for a Web Ontology Language . W3C Working Draft, 08 July 2002.

Feature List
Feature Synopsis for OWL Lite and OWL. Deborah L. McGuinness and Frank van Harmelen. W3C Working Draft, 29 Jul 2002.

Reference
OWL Web Ontology Language 1.0 Reference . Mike Dean, Dan Connolly, Frank van Harmelen, James Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Working Draft, 29 July 2002.

XML Syntax
[@@ ref]

Abstract Syntax
OWL Web Ontology Language 1.0 Abstract Syntax. Peter F. Patel-Schneider, Ian Horrocks, and Frank van Harmelen. W3C Working Draft 29 July 2002.

Formal Model
Model-Theoretic Semantics for OWL, Peter F. Patel-Schneider, 15 August 2002

Sample Ontologies

Daml.org Wine Ontology
http://www.daml.org/ontologies/76

Wine Ontology Tutorial
Ontology Development 101: A Guide to Creating Your First Ontology Natalya Fridman Noy and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001.

Wine Ontology in CLASSIC
Living with CLASSIC: When and How to Use a KL-ONE-Like Language , Ronald J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin Resnick , and Alex Borgida. in John Sowa, ed., Principles of Semantic Networks: Explorations in the representation of knowledge, Morgan-Kaufmann: San Mateo, California, 1991, pages 401--456.

Related Ontology Standards

DAML+OIL
DAML+OIL W3C Submission, includes reference description, both model theoretic and axiomatic semantics, annotated walkthrough and examples.

Annotated DAML+OIL Ontology Markup, Frank van Harmelen, Peter F. Patel-Schneider and Ian Horrocks (eds), March 2001.

Related W3C Standards

RDF
Resource Description Framework (RDF) Model and Syntax Specification , World Wide Web Consortium Recommendation, 1999 Lassila, Swick [eds].

RDF: Resource Description Framework at W3C. Background.

RDFS
Resource Description Framework (RDF) Schema Specification 1.0 , W3C Candidate Recommendation 27 March 2000.

XML
Extensible Markup Language (XML) 1.0

XML Tutorial 1: Well-Formed XML Documents , Bonnie SooHoo Aug 4, 2000 in webreview.com.

Extensible Markup Language (XML) at W3C More background

XML Schema
W3C XML Schema

URI
Uniform Resource Identifiers (URI): Generic Syntax , IETF Draft Standard August 1998 (RFC 2396) T. Berners-Lee, R. Fielding, L. Masinter

A Beginner's Guide to URLs . The classic intro to URLs, by the NCSA Mosaic team.

Web Naming and Addressing Overview (URIs, URLs, ...). More background at W3C.

XML Namespaces
Namespaces in XML , W3C Recommendation Jan 1999.

XML Namespaces by Example, Tim Bray Jan. 19, 1999 in XML.com.

Namespace Myths Exploded, by Ronald Bourret Mar. 8, 2000 in XML.com.

XML Base
XML Base, W3C Recommendation

General

Description Logics
Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, editors, The Description Logic Handbook: Theory, Implementation and Application , Cambridge University Press, 2002.

Description Logic Web Page

Knowledge Representation and Ontology
KR Home Page

OIL
OIL Home Page

DAML
Daml Home Page

DAML-ONT
DAML-ONT initial release

Controlled Vocabularies
Mind your phraseology! Using controlled vocabularies to improve findability , DigitalWeb Magazine, Christina Wodtke

Appendix A: XML + RDF Basics

This appendix provides links to introductions to the standards that OWL depends on.

To fully understand the OWL syntax and semantics you should be familiar with the basics of the related W3C and IETF standards listed below. A minimal guide to XML and RDF can be found as an appendix to the DAML+OIL Walkthru. Any other recommendations for primers for these standards?

Appendix B: An Alternate Region Ontology

This example was developed by Guus Schrieber [ W3C WG Archive] and presents a more elaborate wine region ontology.

For wine the "production area" is an important feature. There is enormous variation between wine types w.r.t. the grain size of the production area, ranging from a complete country to a particular vineyard. One could distinguish four types of production area's:

  1. country: e.g., France, Italy
  2. region: e.g., Bordeaux, Medoc, Tuscany,
  3. town: e.g., Margaux, Montalcino, Montepulciano
  4. vineyard, e.g., Chateau Margaux, Avignonesi
    5. ?=

In addition, we need to model part-of relationships between the various sorts of production areas:

We would like to be able to derive from our wine KB that a wine from Chateau Margaux is a French wine and that Avignonesi is a Tuscan wine.

MODELLING DECISION: at this point we decided to drop the "town" subclass and treat towns as regions. This simplifies the model and is consistent with the fact that a "town" as a wine production area typically stands for an area surrounding the town, which can be larger or smaller that the actual town area. For example, the production area "Montalcino" is in fact a subregion of Tuscany surrounding the village of Montalcino.

This leads to the following model:

Classes:


<owl:Class ID="vin:ProductionArea"/ >
<owl:Class ID="vin:Country:">
    <rdfs:SubClassOf rdf:resource="vin:ProductionArea"/>
</owl:Class> 
<owl:Class ID="vin:Region:"> 
    <rdfs:SubClassOf rdf:resource="vin:ProductionArea"/> 
</owl:Class> 
<owl:Class ID="vin:Vineyard:"> 
    <rdfs:SubClassOf rdf:resource="vin:ProductionArea"/> 
</owl:Class>
Triples
vin:ProductionArea rdf:type rdfs:Class.
vin:Country rdfs:SubClassOf vin:ProductionArea.
vin:Region rdfs:SubClassOf vin:ProductionArea.
vin:Vineyard rdfs:SubClassOf vin:ProductionArea.

Properties:


<owl:ObjectProperty ID="vin:hasSubArea">   
    <owl:TransitiveProperty/>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:subAreaOf">   
    <owl:inverseOf rdf:resource="vin:hasSubArea"/> 
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:hasRegion">   
    <rdfs:SubPropertyOf rdf:resource="vin:hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="vin:Region"/>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:regionOf">   
    <rdfs:inverseOf rdf:resource="vin:hasRegion"/> 
    <owl:allValuesFrom rdf:resource="vin:Country"/>
    <owl:cardinality> 1 </owl:cardinality>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:hasSubRegion">   
    <rdfs:SubPropertyOf rdf:resource="vin:hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="vin:Region"/>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:subRegionOf">   
    <rdfs:inverseOf rdf:resource="vin:hasSubRegion"/> 
    <owl:allValuesFrom rdf:resource="vin:Region"/>
    <owl:cardinality> 1 </owl:cardinality>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:hasVineyard">   
    <rdfs:SubPropertyOf rdf:resource="vin:hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="vin:Vinyard"/>
</owl:ObjectProperty>  

<owl:ObjectProperty ID="vin:vineyardRegion">   
    <rdfs:inverseOf rdf:resource="vin:hasVineyard"/> 
    <owl:allValuesFrom rdf:resource="vin:Region"/>
    <owl:cardinality> 1 </owl:cardinality>
</owl:ObjectProperty>
Triples
  
vin:hasSubArea rdf:type rdfs:Property.  
vin:hasSubArea rdf:type owl:TransitiveProperty. 
vin:subAreaOf owl:inverseOf vin:hasSubArea. 

vin:hasRegion rdfs:SubPropertyOf vin:hasSubArea.
vin:hasRegion owl:allValuesFrom vin:Region.
vin:regionOf owl:inverseOf vin:hasRegion.
vin:regionOf owl:allValuesFrom vin:Country.
vin:regionOf owl:cardinality 1.

vin:hasSubRegion rdfs:SubPropertyOf vin:hasSubArea.
vin:hasSubRegion owl:allValuesFrom vin:Region.
vin:subRegionOf owl:inverseOf vin:hasSubRegion.
vin:subRegionOf owl:allValuesFrom vin:Region.
vin:subRegionOf owl:cardinality 1.

vin:hasVineyard rdfs:SubPropertyOf vin:hasSubArea.
vin:hasVineyard owl:allValuesFrom vin:Vineyard.
vin:vineyardRegion owl:inverseOf vin:hasVineyard..
vin:vineyardRegion owl:allValuesFrom vin:Region.
vin:vineyardRegion owl:cardinality 1.

ONTOLOGICAL NOTE: the part-whole relationship described here is well-known in the formal-ontology literature. The typology of part-whole relations by Winston et al. [1] characterize this as a "place-area" relation. Various authors have critised and amended this typology. If the formal-ontology community would, at some point, be able to make a part-whole typology available in OWL, the properties in this wine ontology could be linked to it.

UML NOTE: Below is a UML class diagram for this example. The modelling decisions for this diagram will be discussed in the forthcoming document on the UML presentation syntax. For the moment, note the use of the UML "composition" construct (the darkened diamond), which caries some of the semantics of the place-area relation.

[1]
Winston, Chaffin & Herrmann. A Taxonomy of Part-Whole Relations. Cognitive Science, 11:417-444, 1987.