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 Web Ontology Language (OWL) 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

formalize a domain by defining classes and properties of those classes,

define individuals and assert properties about them, and

reason about these classes and individuals 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, properties and individuals, beginning with the
fundamentals and proceeding to more complex language components.

This section describes the status of this document as of its 4 Nov 2002
publication. Other documents may supersede this document. This is a W3C Working
Draft for review by W3C members and other interested parties. It is a draft
document and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use W3C Working Drafts as reference materials or to
cite them as other than "work in progress." A list of current W3C
Recommendations and other technical documents can be found at http://www.w3.org/TR/.

This draft represents the working group's efforts to date, starting in
roughly the direction of the DAML+OIL
walkthru, but with more realistic and elaborate examples. It has undergone
considerable review in the working group, but further work is anticipated,
espcially with respect to remaining open issues.

"Tell me what wines I should buy to serve with each course of the
following menu. And, by the way, I don't like Sauterne."

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 is a language for defining Web ontologies and their
associated knowledge bases.
Ontology is a term borrowed from philosophy that refers
to the science of describing the kinds of entities in the world and
how they are related. In OWL, an ontology is
a set of definitions of classes and properties, and constraints
on the way those classes and properties can be employed.
An OWL ontology may include the following elements.

taxonomic relations between classes

datatype properties, descriptions of attributes of elements of classes,

object properties, descriptions of relations between elements of classes,

and, to a lesser degree,

instances of classes and

instances of properties.

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

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

While ontologies for the most part do not include individuals (as
distinct from knowledge bases), it is often the case that some
individuals are needed in an ontology to define certain classes. For
example, if we consider Wine and Color to be classes,
and red to be an element of Color, then the class
Red Wine would require the individual red as part of its
definition and thus as an element of the ontology. As a result, no
precise line can be drawn to distinguish when a collection of OWL
assertions should be labeled an ontology and when it should be called
a knowledge base.

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.

An ontology differs from an XML schema in that it is a knowledge
representation, not a message format. Most industry based web
standards consist of a combination of message formats and protocol
specifications. These formats have been given an operational
semantics. "Upon receipt of this PurchaseOrder message,
transfer Amount dollars from AccountFrom to
AccountTo and ship Product." But the specification
is not designed to support reasoning outside the transaction context.
For example, we won't in general have a mechanism to conclude that
because the Product is a type of Chardonnay it must also be a
white wine.

One advantage of OWL ontologies will be the availability of tools that
can reason about them. Tools will provide generic support
that is not specific to the particular subject domain, which would be
the case if one were to build a system to reason about a specific
industry-standard XML schema. Building a sound and useful reasoning
system is not a simple effort. Constructing an ontology is much more
tractable. It is our expectation that many groups will embark on
ontology construction. They will benefit from third party tools based
on the formal properties of the OWL language, tools that will deliver
an assortment of capabilities that most organizations would be hard
pressed to duplicate.

The OWL language provides three increasingly expressive sublanguages
designed for use by specific communities of implementors and users.

Owl Lite has been defined with the intention of
satisfying users primarily needing a classification
hierarchy and simple constraint features. For example, while it
supports cardinality constraints, it only permits cardinality values
of 0 or 1. For these reasons, it should be simpler to provide tool support for
Owl Lite than its more expressive relatives.

OWL DL includes the complete OWL vocabulary, interpreted
under a number of simple constraints. Primary among these is type
separation. Class identifiers cannot simultaneously be properties
or individuals. Similarly, properties cannot be individuals.
OWL DL is so named due to its correspondence with
description logics.
It was designed to support the existing Description Logic
business segment and has desirable computational properties
for reasoning systems.

OWL Full includes the complete OWL vocabulary, interpreted
more broadly than in OWL DL, with the freedom provided by
RDF. For example, in OWL Full a class
can be treated simultaneously as a collection of individuals
and as an individual in its own right. Another significant difference from
OWL DL is that a DatatypeProperty can be marked as
an InverseFunctionalProperty.
These powerful features are common in many database and knowledge
representation systems but increase the complexity of reasoning systems
that support them, as compared to OWL DL.

Each of these sublanguages is an extension of its simpler predecessor, both
in what can be legally expressed and in what can be validly concluded.
The following set of relations hold. Their inverses do not.

Every legal OWL Lite ontology is a legal OWL DL ontology.

Every legal OWL DL ontology is a legal OWL Full ontology.

Every valid OWL Lite conclusion is a valid OWL DL conclusion.

Every valid OWL DL conclusion is a valid OWL Full conclusion.

Ontology developers adopting OWL should consider which dialect best
suits their needs. The choice between OWL Lite and OWL DL
depends on the extent to which users require the more expressive
restriction constructs provided by the full language.
The choice between OWL DL and OWL Full mainly
depends on the extent to which users require the
metamodelling facilities of RDF Schema (i.e. defining classes of
classes).
The price paid for OWL FULL when compared to OWL
DL is that reasoning support is less predicatable.
For more information about this issue see the
semantics document.

When we introduce constructs that are only permitted in OWL DL or
OWL Full, they are marked by "[OWL DL]".

In order to provide a consistent set of examples throughout the
guide, we have created a wine ontology. This
ontology satisfies the requirements of OWL DL. Some examples will
focus on OWL Full capabilities and will be marked by "[OWL Full]".
The wine ontology is a significant modification of a DAML version that was
developed as a description logic example and
tutorial and
submitted
to the DAML ontology library.

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. Note that OWL has been designed for maximal compatibility
with RDF and RDF Schema. 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.

Notes indicating expected changes pending clarification are marked
with '@@', e.g. [@@ Note].
All of the examples presented in this document are taken from the
ontologies contained in wine.owl and food.owl, except those marked with ¬ in the bottom right corner.

OWL is a component of the Semantic Web
activity. This effort aims to make Web resources more readily
accessible to automated processes by adding information about the resources
that describe or provide Web content. Because the Semantic Web
deals with web content, it is inherently distributed. We expect OWL
ontologies to also be distributed. One consequence of this is that
OWL generally makes an open world assumption. That is,
descriptions of resources are not confined to a single file or scope.
While class C1 may be defined originally in ontology O1, it
can be extended in other ontologies. The consequences of these
additional propositions about C1 are monotonic. New
information cannot negate previous information. Facts
and entailments can only be added, never deleted.

OWL does allow negative information to be explicitly stated.
As a result, it is fairly simple to explicitly state contradictions.
In addition, contradictions may be implicit. These properties of a
knowledge base are something the designer of an ontology needs to be
careful about. It is expected that tool support will help detect such
cases.

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.

Before we can use a set of terms, we need a precise indication of what
specific vocabularies are being used.
A standard initial component of an ontology includes a set of
namespace declarations enclosed in an opening rdf:RDF tag.
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.

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

The fourth 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/2002/07/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.example.org/wine-dt#, which contains
the datatype definitions for this Guide document.

As an aid to writing down references to lengthy URLs it can often be
useful to provide a set of entity definitions in a document type
declaration (DOCTYPE) that precedes the ontology definitions. The names defined by the namespace
declarations only have significance as parts of XML tags. Attribute
values are not namespace sensitive. But in OWL we frequently
reference ontology identifiers using attribute values. They can be
written down in their fully expanded form, for
example "http://www.example.org/owl/wine#merlot". Alternatively,
abbreviations can be defined using an ENTITY definition, for example:

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

<owl:Ontology rdf:about="http://www.example.org/wine">

This assertion is formulaic. The about attribute will
normally be the URL of the current file, indicating that the subject
of this assertion is this document. If
desired, the ontology may be given a name that is a URN and
independent of a particular physical location.

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.

<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 does
not specify the structure of the content.

<owl:imports>
provides an include-style mechanism.
<owl:imports>
takes a single argument, identified by the rdf:resource attribute.

Importing another ontology brings the entire set of definitions
provided by that ontology into the current ontology or 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 means to reference names defined in other OWL
ontologies.
Conceptually, owl:imports is provided to indicate your
intention to include the assertions of the target ontology.
These assertions define the meaning of the terms defined in that
ontology, meanings that support reasoning about the terms.

Note that owl:imports may not always succeed. As you would
expect when dealing with the Semantic Web, access to resources
distributed across the Web may not always be possible. Tools will
respond to this situation in an implementation defined manner.

[@@ The final details of imports are still under consideration by the working group.]

One common set of additional tags that could reasonably be included here are
the standard Dublin
Core metadata tags. Examples include
Title, Creator, Description, Publisher, and Date. The URI defining
the Dublin Core namespace is 'http://purl.org/dc/elements/1.1/'.)

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

The ontology header definition is closed with
the following tag.

</owl:Ontology>

This prelude is followed by the actual definitions that
make up the ontology and is ultimately closed by

Many uses of an ontology will depend on 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 a class as a set containing elements.
We call the set of individuals that are members of a class
the extension of the class.

The most basic concepts in a domain should correspond
to classes that are the roots of various
taxonomic trees. Every individual in the OWL world is a member of
owl:Thing. Thus each user-defined class
is implicitly a subclass of owl:Thing. Domain specific root classes are
defined by simply declaring a named class.

Note that we have only said that there exist classes that have been
given these names, indicated by the 'rdf: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 Thing1,
Thing2, and Thing3.

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

The attribute/value syntax rdf:ID="Region" is used to first introduce a
name, as part of its definition. This is the
rdf:ID
attribute that is like the familiar ID attribute defined by XML.
Within this document, the Region class can now be referred to using
rdf:resource="#Region". Other ontologies may reference this
name using its complete form, "documentURI#Region" (see below).

Another form of reference
uses the syntax rdf:about="#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 document and supports the incremental construction of a larger ontology.

It is now possible to refer to the classes we defined in other OWL
constructs using 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 namespace and entity definitions
that include the defining document as a source:

Note that we use '...' to indicate that there is additional text that
has been elided for purposes of the example.

Given these definitions we can refer to the winery class either
using the XML tag vin:Winery or the attribute value &vin;Winery.
More literally, it is always possible to reference a resource using its full URI,
http://www.example.org/wine#Winery.

The fundamental taxonomic constructor for
classes is subClassOf.
It is transitive. If X is a subclass of Y
and Y a subclass of Z then X is a subclass of Z.

We define PotableLiquid (liquids suitable for drinking) to
be a subclass of ConsumableThing.

In the world of web-based ontologies, both of these classes
should be defined in a separate ontology that would provide the basic
building blocks for a wide variety of food and drink ontologies. And
in fact this is what we have done. These elements are defined in the
food ontology, which is imported into the wine ontology.
The food ontology includes a number of classes, for example
Food, EdibleThing, MealCourse, and
Shellfish, that do not belong in a collection of wine facts,
but must be connected to the wine vocabulary if we are going to
perform useful reasoning. Food and wine are mutually
dependent, in order to satisfy our need to identify wine/food matches.

A class definition has two parts: a name introduction or reference
and a list of restrictions. Each of the immediate contained
expressions in the class definition further restricts the members of
the defined class. Class elements are members of the intersection of
the restrictions. So far we have only seen examples that include a single restriction,
forcing the new class to be a subclass of some other named class.

At this point it is possible to create a simple (and incomplete)
definition for the class Wine. Wine is a
PotableLiquid.

The rdfs:label entry provides an optional human readable
name for this class. Presentation tools can make use of it.
The "lang" attribute provides support for multiple languages. A label
is like a comment and contributes nothing to the logical
interpretation of an ontology.

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

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.
An individual is minimally introduced by declaring it to be a member
of a class.

<Region rdf:ID="CentralCoastRegion" />

Note that the following is identical in meaning to the
definition above.

rdf:type is an RDF property that ties an individual to a class
of which it is a member.

There are a couple of points to be made here. First,
we have decided that CentralCoastRegion (a specific area) is
member of Region, the class containing all geographical regions.

Second, there is no requirement in the two-part example that the two
statements need to be adjacent to one another, or even in the same
file (though the names would need to be extended with a URI in such a
case). We design Web ontologies to be distributed. They can be
imported and augmented, creating derived ontologies.

In order to have available a few more basic definitions for the
properties introduced in the next sections, we define a branch
of the Grape taxonomy, with an individual denoting the
Cabernet Sauvignon grape varietal.

There are important issues regarding the distinction between a class and
an individual in OWL. A class is simply a name and collection of properties
that describe a set of individuals, and individuals are the members of those sets.
Thus classes should correspond to naturally occurring sets of things in a domain
of discourse, and individuals should correspond to actual entities that can be grouped
into these classes.

In building ontologies, this distinction is frequently blurred in two ways:

Levels of representation: It is well known that in certain contexts something
that is obviously a class can itself be considered an instance of something else. For
example, in the wine ontology we have the notion of a Grape, which is
intended to denote the set of all grape varietals.CabernetSauvingonGrape is
an example instance of this class, as it denotes the actual grape varietal
called Cabernet Sauvignon.
However, CabernetSauvignonGrape could itself be considered a class, the set of all
actual Cabernet Sauvignon grapes.

Subclass vs. instance: It is very easy to confuse the
instance-of relationship with the subclass relationship.
For example, it may seem arbitrary to choose to make CabernetSauvignonGrape
an individual that is an instance of Grape, as opposed to a subclass of Grape.
This is not an arbitrary
decision. The Grape class denotes the set of all
grape varietals, and therefore any subclass of Grape should denote a subset of these
varietals. Thus, CabernetSauvignonGrape should be considered an
instance of Grape, and not a subclass. It does not
describe a subset of Grape varietals, it is a grape varietal.

Note that the same distinction arises with the treatment of the
Wine class. The Wine class actually denotes the set
of all varieties of wine, not the set of actual bottles that
someone may purchase.
Each instance of Wine could be considered the class
consisting of all the bottles of wine of that type. It is easy to
imagine an information system, such as an inventory system for a wine
merchant, that needs to consider individual bottles of wine.
The wine ontology as it currently exists would require the ability to
treat classes as instances in order to support such an interpretation.
Note that OWL Full permits such expressivity,
allowing us to treat an instance of a wine variety simultaneously
as a class whose instances are bottles of wine.

In a similar vein, the wines produced by wineries in specific years
are considered vintages. In order to represent the notion of a
vintage, we must determine where it fits in the current ontology. An
instance of the Wine class, as discussed above, represents a
single variety of wine produced by a single winery, for example
FormanChardonnay.

Adding that the wine produced in the year 2000 is considered a
vintage
poses a challenge, because we don't have the ability to represent a
subset of a given wine individual. This vintage is not a new
variety of wine, it is a special subset of the wine - that produced in
the year 2000.
An option would be to use use OWL Full and treat the wine instances as
classes with subclasses (subsets) denoting vintages. Another option is
to use a workaround and to consider Vintage as a separate class whose
instances have a relationship to the Wine they are a vintage of.
For example, FormanChardonnay2000 is an
individual Vintage with a vintageOf property whose value is
the Wine, FormanChardonnay. We define the
Vintage class below.

The point of this
discussion is to note that the development of an ontology should be
firmly driven by the intended usage. These issues also underlie
one major difference between OWL Full and OWL DL. OWL Full
allows the use of classes as instances and OWL DL does not.
The wine ontology is designed to work in OWL DL, and
as a result individuals like FormanChardonnay cannot
simultaneously be treated as classes.

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:

datatype properties, relations between elements of
classes and XML datatypes,

object properties, relations between elements of two classes,

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.

In OWL, a sequence of statements without an explicit operator
represents an implicit conjunction. They
apply to their containing element.
The property madeFromGrape has a domain of Wineand a range of WineGrape. That is, it relates
elements of the class Wine to elements of the class
WineGrape.

WineDescriptor properties relate wines to their color and components of their
taste, including sweetness, body, and flavor. hasColor is a
subproperty of the hasWineDescriptor property, with its range
further restricted to WineColor.

Next we introduce the locatedIn property, which relates things to
the regions they are located in.

Notice how the domain and range of locatedIn are defined.
The domain permits anything to be located in a region, including
regions themselves. And the transitive composition of this relation
essentially creates a network of geographically included subregions
and things. Those elements that do not have other elements located in
them can be of any class, while those that contain others must be
regions.

It is now possible to expand the definition of Wine to
include the notion of regions, and that a wine is
made from at least one WineGrape.
As with property definitions, class definitions have multiple subparts that are
implicitly conjoined.

The highlighted subclass restriction
defines an unnamed class that represents the set of things
with at least one madeFromGrape property. We call these anonymous
classes [OWL DL]. Inserting this subclass restriction in the Wine
class definition body states that things that are wines are also
members of this anonymous class. That is, every individual wine must participate
in at least one madeFromGrape relation. Additionally, every
wine must come from at least one region. This cliché is
presented in more detail in the section on restrictions.

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
simple types defined in accordance with
XML Schema datatypes.

Suppose we wanted to restrict vintage years to years after
1700. We would create several XML Schema datatype definitions in a
separate file, such as
http://www.example.org/wine-dt.xsd
, which contains:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org/wine-dt.xsd">
<xsd:simpleType name="year">
<!-- year is an XMLS datatype based on integer -->
<xsd:restriction base="xsd:integer"/>
</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>

The type 'year' is defined to be a subtype of the XML Schema simple
type 'integer. The type 'wineYear' is a subtype of 'year' that is
restricted to integer values greater than or equal to 1700. We can
reference elements of this file in OWL property definitions and class
restrictions.

The yearValue property relates WineYears to integer values
greater than or equal to 1700.
It would have been possible to tie Vintages directly to the
XML Schema datatype dte:wineYear, but this layer of
indirection permits us to extend the ontology with the notion of
'good years' for wine.
We define the hasVintageYear property, which relates a Vintage to a
WineYearbelow.

[@@ The final syntax of datatype references is awaiting input from RDF Core.]

This is still incomplete. There are other aspects of the wine flavor
that are defined in the full ontology. But the pieces are falling
together. We could begin reasoning about what menu items this wine might
accompany. We know from the definition above that the Santa Cruz
Mountain Vineyard makes it.
Because it is a Cabernet Sauvignon (see wine.owl),
we know it is a dry, red wine.

Datatype properties can be added to individuals in a similar
fashion. Below we create an instance of WineYear and tie it to a
specific value of type dte:wineYear, an integer > 1700.

The next few sections describe the mechanisms used to further define
properties. It is possible to specify property
characteristics, which provides a powerful mechanism for enhanced
reasoning about a property.

The property adjacentRegion is symmetric, while locatedIn is not.
(To be more precise, locatedIn is not intended to be
symmetric. Nothing in the wine ontology at presetn prevents it from being symmetric.)

In our wine ontology, hasVintageYear
is functional. A wine has a unique vintage year.
That is, a given individual Vintage can only be associated with a
single year using the hasVintageYear property.
It is not a requirement of a FunctionalProperty
that all elements of the domain have values. See the discussion of
Vintage cardinality.

Wines have makers, which in the definition of Wine
are restricted to Winerys. Then each
Winery produces the set of wines that identify it as maker.

InverseFunctionalProperty

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

P(y,x) and P(z,x) -> y = z

Notice that producesWine in the preceding section is inverse
functional. The reason is that the inverse of a functional property
must be inverse functional. We could have defined hasMaker
and producesWine as follows and achieved the identical
effect as the preceding example.

Think of the elements of the range in an inverseFunctional property
as defining a unique key in the database sense.
Inversefunctional implies that the elements of the range
provide a unique identifier for each element of the domain.

In OWL Full, we can use tag a DatatypeProperty as
inverseFunctional. This permits us to identify a string as
a unique key.

Property Restrictions

In addition to designating property characteristics, it is possible to
further constrain the range of a property in specific contexts in a
variety of ways.

allValuesFrom, someValuesFrom

We have already seen one way to restrict the types of the elements that
make up a property. The mechanisms to
date have been global in that they apply to all
instances of the property. These next two, allValuesFrom and
someValuesFrom, are local to their containing class definition.

The maker of a Wine must be a Winery.
The allValuesFrom restriction is on the hasMaker property of
this Wine class only. Makers of Cheese are
not constrained by this local restriction.

owl:someValuesFrom is similar, but less restrictive. If we
replaced owl:allValuesFrom with owl:someValuesFrom
in the example above, it would mean that at least one of the
hasMaker properties of a Wine must point to an
individual that is a Winery.

The difference between the two formulations is the difference between
a universal and existential quantification.

Relation

Implications

allValuesFrom

For all wines, if they have
makers, all the makers are wineries.

someValuesFrom

For all wines, they have at least one maker that is a winery.

The first does not require a wine to have a maker. If it does have one or more, they
must all be wineries. The second requires that there be at least one maker
that is a winery, but there may be makers that are not wineries.

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 class with
exactly one WineYear.

We defined hasVintageYear to be a functional property. This
application of that property to Vintage asserts
something stronger, that everyVintage has
exactly one WineYear.

Cardinality expressions with values limited to '0' or '1' are part of OWL Lite.
This permits the user to indicate 'at least one', 'no more than one',
and 'exactly one'.
Positive integer values other than 0 and 1 are permitted in OWL Full.
owl:maxCardinality can be used to specify an upper bound. In
combination with owl:minCardinality it is possible to specify
a range.

hasValue allows us to define classes based on the
existence of particular property values. Hence,
an individual will be a member of such a class whenever at least one
of its property values is equal to the hasValue resource.

Here we define Burgundy wine to be dry wines. That is, their
hasSugar property must have at least one value that is equal
to Dry.

hasValue can only be used
within a property restriction. The owl:onProperty statement
indicates the restricted property. As for allValuesFrom and
someValuesFrom, this is a local restriction. It holds for
hasSugar as applied to Burgundy.

In order for ontologies 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 and then extend the notion of location to include the time
period during which it holds.

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.

It will be challenging to merge a collection of ontologies. Tool
support will almost certainly be required to ensure a consistent
knowledge base.

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
class or property in one ontology is equivalent to a class or property
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 are contradictory (all A's
are B's vs. all A's are not B's) there will be no extension (sets of
individuals and relations) that satisfies the resulting combination.

In the food ontology we want to link wine features in the descriptions
of dining courses back to the wine ontology. One way to do this is by
defining a class in the food ontology and then
declaring it identical to the existing wine class in the wine ontology.

Of course the example above is somewhat contrived, since we can always
use &vin;Wine anywhere we would #Wine and get
the same effect without redefinition. A more likely use would be in a
case were we depend on two, independently developed ontologies, and
note that they use the terms O1:foo and O2:bar to
reference the same class. sameClassAs could be used to
collapse these together so that the entailments from the two
ontologies become mutually supporting.

We have already seen that class expressions can be the targets
of subClassOf constructors. They can also be the target of
sameClassAs [OWL DL]. Again, this avoids the need to
contrive names for every class expression and provides a powerful
definitional capability based on satisfaction of a property.

TexasThings are exactly those things located in the
Texas region. The difference between using sameClassAs here
and using subClassOf is the difference between a necessary
condition and a necessary and sufficient condition. With
subClassOf, things that are located in Texas are not
necessarily TexasThings. But, using sameClassAs, if
something is located in Texas, then it must be in the class of
TexasThings.

This example does not have great utility. About all we learn from this is
that Mike likes an inexpensive local wine. A more typical use of
sameIndividualAs would be to equate individuals defined in
different documents to one another, as part of unifying two ontologies.

This brings up an important point. OWL does not have a unique
naming assumption. Just because two names are different does not
mean they refer to different individuals.

In the example above, we asserted identity between two distinct
names. But it is just as possible for this sort of identity to be
inferred.
Remember the implications that can be derived from a functional
property. Given that hasMaker is functional, the following
is not necessarily a conflict.

This is one way to assert that these three values are mutually distinct.
There will be cases where it is important to ensure such distinct
identities. Without these assertions we could describe a wine that was
both Dry and Sweet. We have
stated that the hasSugar property applied to a wine has no more than
one value. If we erred, and asserted that a wine was both Dry and
Sweet, without the differentIndividualFrom statements above,
this would imply that Dry and Sweet are identical.
With the statements above, we would instead get a contradiction.

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.
And it is possible to assert that class extensions must be disjoint.

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

Classes constructed using the set operations are
closed. The members of the class are completely specified by
the set operation.
This is an important capability.
It permits us to state that WhiteWine is exactly the
intersection of the class Wine and the set of things that are
white in color. This means that if something is white and a wine,
then it is an element of WhiteWine. Without such closed sets
we can know that white wines are wines and white, but not vice-versa.
This is an important tool for categorizing individuals.
(Note that 'rdf:parseType="Collection"' is a required syntactic element.)

Here we define Burgundy to include exactly those wines that have
at least one locatedIn relation to the Bourgogne Region.
We could have declared a new class
ThingsFromBourgogneRegion and used it as a class in the
owl:intersectionOf construct. Since we do not have any other
use for ThingsFromBourgogneRegion, the declaration above is
shorter, clearer and doesn't require the creation of a contrived name.

Finally the class WhiteBurgundy is exactly 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 WhiteBurgundy.

Union [OWL DL]

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

The class of NonConsumableThing includes as its members
all individuals that do not belong to the extension
of ConsumableThing. This set includes all
Wines, Regions, etc. It is literally the set
difference between owl:Thing and ConsumableThing.
Therefore, a typical usage pattern for
complementOf is in combination with other set
operators:

OWL provides the means to define a class via a direct enumeration of its
members. This is done using the oneOf constructor. Notably,
this definition closes the class extension, so that no other
individuals can be declared to belong to the class.

The following statement defines a class WineColor whose
members are the individuals White, Rose, and
Red.

The first thing to understand here is that no other individuals can be
a valid WineColor since the class has been defined by
enumeration and is closed.

Each element of the oneOf construct must be a validly declared
individual. An individual has to belong to some class. In the above
example, each individual was referenced by name. We used
owl:Thing as a simple cliché to introduce the reference.
Alternatively, we could have referenced the elements of the set
according to their specific type, WineColor, by:

The disjointness of a set of classes can be expressed using the
owl:disjointWith constructor. It guarantees that an
individual that is a member of one class cannot simultaneously be an
element of a specified other class.

The Pasta example demonstrates multiple disjoint classes.
Note that this only asserts that Pasta is disjoint from all
of these other classes. It does not assert, for example, that
Meat and Fruit are disjoint. In order to assert
that a set of classes are mutually disjoint, there must be an
owl:disjointWith assertion for every pair.

A common requirement is to define
as a class as the union of a set of mutually disjoint subclasses.

Here we define Fruit to be exactly the union of
SweetFruit and NonSweetFruit. And we know that
these subclasses exactly partition Fruit into two distinct subclasses
because they are disjoint.
As the number of mutually disjoint classes
grows, the number of disjointness assertions grows proportionally to
n2. However, in the use cases we have seen, n is typically
small.

A number of sites exist today that call themselves wine portals.
Google for example, provides 152,000 matches for the query "wine
portal". One of the top matches, a site called
"Wine-Portal.com",
provides access to a number of sites. Many of sites
claiming to be wine portals are mostly informational sites. For
example, wine-portal.com's first featured site, called 'cork cuisine'
(www.corkcuisine.com/),
provides information about matching
wines and foods, wines as gifts, etc. Another site billed as "the
Internet Wine Portal" (
www.cyberbacchus.com/) provides a nice
organization of a substantial amount of wine information on
numerous topics.

Perusing any of the topic areas, one finds a collection of pages
containing information and sometimes services related to the topic.
For example, 'accessories and gifts' contains information about what to
look for when buying particular wine items and also contains a
significant number of online retailers. Another top level area called
'shopping' has a subarea called 'wine shopping' from which a user can find
online (or 'street shopping') stores (categorized by country).
These two sites are just two of the many examples
today and are representative of the general notion of a wine portal providing
a collection of information and services connected to a particular topic
area.

When looking at these sites in some detail, it is not clear how much
they depend on ontologies today. For example, viewing the source
for the html does not reveal evidence of ontological usage. However,
it is clear that the sites could exploit ontologies had some wine ontologies
been available.

One simple use of ontologies in portal sites is for organization and
browsing. The listing of categories above could be generated from
the top few levels of wine related classes. Queries could exploit
wine ontologies to retrieve wine relevant information.
If one did a search for a term contained in the ontology, the query could
be expanded with subclass information in order to find more relevant answers.
Portals could be made to automatically update themselves with (candidate) information
in topic areas. With very powerful reasoning
capabilities they could even identify likely wine sales sites and
negotiate to include them as part of the portal.

We have started a
wine agent for expository purposes. In our initial design,
the wine agent's goal is to recommend wines to accompany meal courses.
This application exploits the ontology used as the basis of this guide.
This wine ontology is available in the DAML ontology library and is entitled
wines.

A personalized wine agent can provide a number of services for a human.
The agent may be used to recommend wines given a set of constraints
(such as a meal being served), the agent may find information about
a particular wine or a particular class of wines, it may look for appropriate
accessories for a wine (such as a particular kind of glass suited for that
wine varietal, etc.).

Below, we describe an example in a simple prototype system that is being
written as a student project.

Consider the following scenario:

Someone is planning a dinner party and at least one of the guests is
wine knowledgeable. The host would like to serve wine that is well
matched to the course(s) on the menu. The host would also like to
appear knowledgeable about the wines served at the event. The host
would also like to have appropriate accessories at the dinner. The host
may have decided to serve a special tomato based pasta sauce with fresh
pasta as the main course.

In order to serve wines appropriate to the meal, the host needs information
concerning wine and food pairings. In order to appear knowledgeable
about wines, the host would benefit from having access to wine information
relevant to the event. In order to have appropriate wine accessories,
the host would need to have information about what accessories are relevant
to the situation (and are within the host's price range).

With a background wine ontology, given a description of a meal, a wine
agent can suggest the type of wine to serve with the meal. The wine
agent may suggest a zinfandel as the varietal of choice for the meal.
Additionally, given a background ontology, the wine agent may suggest a
particular zinfandel, possibly Marietta Zinfandel. Given the information
that the wine should be a zinfandel, a wine agent may look for a place
to acquire either a selection of zinfandels or it may look for a particular
zinfandel wine, such as Marietta. Given a background ontology containing
appropriate sources for wine purchases (possibly filtered by the location
of the host and the location of the wine seller), the wine agent could
go to a site such as wine.com and do
a search for zinfandels returning a listing
of zinfandels for sale on that site. The wine agent could attempt
to find MariettaZinfandel
either from the winery itself or from other resellers. It could,
for example, find (by a search on Google or a structured search of selected
web sites) that winelibrary.com has a sale on Marietta Zinfandel 1999 vintage
for a discounted price of $13.99. The wine agent could
use additional filtering information such as price ranges provided either
by the consumer or as suggestions based on varietal.

The wine agent may now attempt to provide information concerning zinfandel
in general or Marietta Zinfandel in particular. It could use a background
ontology of wine sites to find information about particular wines.
For example, the winery description of its 1999
Zinfandel may be of use. Additionally reviews from respected
sources such as the Wine
Spectator may be of use. If no review of Marietta Zinfandel is
available on a favorite wine review site, it may be useful to look for
related information such as reviews on zinfandels from the same region,
in this case zinfandels from Sonoma County, California.

General background information may also be of use. The host may
also want to do some reading and may be interested in books on wine in
general or zinfandels in particular. For example, the host may be
interested in the books that Amazon.com has for sale
on zinfandel. The host may also be interested in information
concerning wines from the same region, and thus may be interested in Sonoma
zinfandels. A wine agent may have typical background information
available that is related to its main knowledge areas. For example,
this wine agent is concerned with matching foods and wines, so it may have
both free and purchasable information on this topic such as the Wine Spectator's
article on matching
food and wine.

The dinner host may also want to acquire appropriate wine accessories
prior to the event. Wine is served in wine glasses and different
wine varietals are best served in different kinds of glasses. For
example, if the host has chosen a meal course for which a zinfandel
is appropriate, the host may want to know that Riedel
is a well-known manufacturer of wine glassware. The host may also
want to be linked to the Wine Enthusiast (a well respected supplier of
wine merchandise) and be told that the Wine Enthusiast has Riedel's
Vinum Zinfandel glass for sale as a set of 4 for $63.95 (with a discount
to $59.95 if you buy two sets of 4 glasses). The host may also
be interested to know that Amazon.com has Reidel's
Sommelier Zinfandel single stem glass available for $49.99 (and claims
a list price of $65.00). Amazon also has the same Vinum
glass for sale in sets of 6 (instead of 4 on the wine enthusiast) for $79.99
(and claims a list price of $119.40). A wine agent could provide
a comparison listing of glassware that is matched to the meal (i.e., is
appropriate to be used to serve zinfandel) and then is compared by price
or other criteria chosen from a list of properties in the ontology.

The dinner host may want to consider other wine accessories. From
the ontology, we know that corkscrews are wine accessories. The background
ontology may encode subclasses of corkscrews or such information could
be found from relevant wine sites as well. The
Wine Enthusiast has a set of corkscrews
they recommend
(with descriptions of the types and price ranges). They also distinguish
corkscrews by type (level, waiter, stationary, twist, and pump) and the
dinner host may want to get information about those styles.

The wine agent may be taken to many levels of sophistication depending
upon background ontology knowledge of the domain and information and services
sites. In this example, we only exploited information
concerning wines, varietal type, food and wine combinations, some wine
accessories and their related properties. We could of course expand
this to include more information and more constraints by the customer.

This document represents the work of many people, in particular the members of the W3C Web
Ontology Working Group. Appendix B was contributed by Guus Schreiber, University
of Amsterdam, schreiber@swi.psy.uva.nl. Substantial
insight was provided by the DAML+OIL Walkthru.
Jeremy Carroll, Jeff Heflin, Leo Obrst, Kevin Page and Peter F. Patel-Schneider provided
helpful reviews. At the WG Face to Face, October 8, 2002, Stephen Buswell,
Ruediger Klein, Enrico Motta, and Evan Wallace provided a detailed review of the
ontology resulting in substantial changes.

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.

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 is provided by the first two
links below.

The Resource Description Framework (RDF) was the
first language specified by the W3C for representing semantic
information about arbitrary resources. RDF Schema
(RDFS) is a W3C candidate recommendation for an extension to RDF
to describe RDF vocabularies. RDFS can be used to create ontologies,
but it is purposefully lightweight, with less expressive power than
OWL.

Like OWL, RDFS 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.

Other efforts in the research community were already examining exactly
these sorts of features. For those who wish to delve more deeply into
this background, a partial list of projects and languages includes:

Instead of continuing with separate ontology languages for the
Semantic Web, a group of researchers, including many of the main
participants in both the OIL and DAML-ONT efforts, got together in the
Joint US/EU ad hoc Agent
Markup Language Committee to create a new web ontology language.
This language DAML+OIL built on both OIL and
DAML-ONT, was submitted to the
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.
Examples of sites that are actually making commercial use ontologies
include:

Various medical or drug-related ontologies have been developed to help
manage the overwhelming mass of current medical and biochemical research data
that can be difficult to tie together into a cohesive whole.
One major resource is the Gene
Ontology Consortium which is defining ontologies for

Molecular Function,

Biological Process, and

Cellular Components.

That site also has pointers to ontologies for

sequence attributes,

gene product attributes,

chemical substances,

pathways,

anatomies,

pathology,

physical characteristics,

experiment attributes,

classification, and

pathology.

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.
NAICS is also tied to the International Standard Industrial
Classification System (ISIC, Revision 3), developed and maintained by
the United Nations.

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 with respect to the grain size of the
production area, ranging from a complete country to a particular vineyard.
One could distinguish four types of production areas:

country: e.g., France, Italy

region: e.g., Bordeaux, Medoc, Tuscany,

town: e.g., Margaux, Montalcino, Montepulciano

vineyard, e.g., Chateau Margaux, Avignonesi

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

regions are part of countries: Tuscany lies in Italy

regions may have subregions: the Medoc region is a subpart of the
Bordeaux region

towns are located in regions: Montalcino is located in Tuscany

vineyards are located in towns: Chateau Margaux us a vineyard in
Margaux, Avignonesi in Montepulciano

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.

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

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. characterizes this as a
"place-area" relation. Various authors have criticized 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 modeling 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.