The Web Ontology Language OWL is a semantic markup language for publishing
and sharing ontologies on the World Wide Web. OWL is developed as a vocabulary
extension of
RDF (the Resource Description Framework) and is derived from the DAML+OIL Web
Ontology Language. This document contains a structured informal description
of the full set of OWL language constructs and is meant to serve as
a reference for OWL users who want to construct OWL ontologies.
Parts of this document are derived from the DAML+OIL (March 2001) Reference
Description [DAML+OIL] which was
submitted as part of the
DAML+OIL W3C Note
.
The sponsors of this document and its
predecessor documents are gratefully acknowledged.
Jeremy Carroll, Jim Hendler, Brian McBride and
Peter Patel-Schneider provided
substantive reviews and contributed text to this document. Jeff Heflin
contributed the section on deprecation. Jerome Euzenat
contributed the example for an enumerated datatype.
This document is the result of extensive discussions within the
Web Ontology Working Group
as a whole. The members of this group working group included:
Yasser al Safadi, Jean-Francois Baget, James Barnette, Sean
Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Peter
Crowther, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman,
Jerome Euzenat, Dieter Fensel, Tim Finin, Nicholas Gibbins, Pat
Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan,
Masahiro Hori, Ian Horrocks, Francesco Iannuzzelli, Mario Jeckle,
Ruediger Klein, Ora Lassila, Alexander Maedche, Massimo Marchiori,
Deborah McGuinness, Libby Miller, Enrico Motta, Leo Obrst, Laurent
Olivry , Peter Patel-Schneider, Martin Pike, Marwan Sabbouh, Guus
Schreiber, Shimizu Noboru, Michael Sintek, Michael Smith, Ned
Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, Lynne R.
Thompson, David Trastour, Frank van Harmelen, Raphael Volz, Evan
Wallace, Christopher Welty, and John Yanosy.
1. Introductory remarks
1.1 Purpose of this document
This document gives a systematic, compact and informative description
of all the modelling primitives of OWL, using the RDF/XML
exchange syntax for OWL. We expect this document to
serve as a reference guide for users of the OWL language. Readers
unfamiliar with OWL may wish to first consult the OWL Overview
document
[OWL Overview],
and subsequently the OWL Guide
[OWL Guide]
for a more narrative description and examples of the use of
the language.
This document assumes the reader is familiar with the basic concepts of
RDF [RDF Concepts] and has a
working knowledge of the RDF/XML syntax
[RDF/XML Syntax] and of RDF
Schema [RDF Schema].
The normative reference on the precise syntax of the OWL language
constructs can be found in the OWL
Semantics and Abstract Syntax document [OWL S&AS]. This
document also contains a precise definition of the meaning of the
language constructs in the form of a model-theoretic semantics.
Uses cases and requirements for the OWL language are described in the OWL
requirements document
[OWL Use Cases and Requirements].
Test cases for OWL tools are specified in the Test document
[OWL Test Cases] .
1.2 OWL Full/DL/Lite
As also discussed in the
OWL Overview document
[OWL Overview],
and subsequently the OWL Guide
[OWL Guide],
the OWL language provides two specific subsets that we believe will
be of use to implementors and language users. OWL Lite was
designed for easy implementation and to provide users with a
functional subset that will get them started in the use of OWL.
OWL DL (where DL stands for "Description Logic")
was designed to support the existing
Description Logic business segment and to provide a language subset
that has desirable computational properties for reasoning systems.
The complete OWL language (called OWL Full to distinguish it from the
subsets) relaxes some of the constraints on OWL DL so as to make available
features which may be of use to many database and knowledge
representation systems, but which violate the constraints of
Description Logic reasoners.
OWL Full and OWL DL support the same set of OWL language constructs.
Their difference lies in restrictions on the use of some of those
features and on the use of RDF features.
OWL Full allows free mixing of OWL with RDF Schema and,
like RDF Schema, does not enforce a strict separation of classes,
properties, individuals and data values. OWL DL puts constraints on the mixing
with RDF and requires disjointness of classes, properties, individuals
and data values. The main reason for having the OWL DL sublanguage is
that tool builders have developed powerful reasoning systems which
support ontologies constrained by the restrictions required for OWL
DL. For the formal definitions of the differences between OWL Full
and OWL DL the reader is referred to the Semantics and Abstract Syntax
document
[OWL S&AS].
Sect. 8.2 OWL DL
summarizes the
differences between OWL Full and OWL DL.
OWL Lite is a sublanguage of OWL DL that supports only a subset of the
OWL language constructs. OWL Lite is particularly targeted at tool
builders, who want to support OWL, but want to start with a
relatively simple basic set of language features.
OWL Lite abides by the same semantic restrictions as OWL DL,
allowing reasoning engines to guarantee certain desirable properties.
A summary of the language constructs allowed in OWL Lite is given in
Section 8.3 "OWL Lite constructs".
For a
more formal description of the subset of OWL language constructs
supported by OWL Lite the reader is referred to the Semantics and
Abstract Syntax document
[OWL S&AS].
NOTE: RDF users upgrading to OWL should be aware that OWL Lite is not
simply an extension of RDF Schema. OWL Lite is a a light
version of OWL DL and puts
constraints on the use of the RDF vocabulary (e.g., disjointness of
classes,
properties, etc.). OWL Full is designed for maximal RDF compatibility and is
therefore the natural place to start for RDF users. When opting for either OWL
DL or OWL Lite one should consider whether the advantages of OWL DL/Lite
(e.g., reasoning support) outweigh
the DL/Lite restrictions on the use of OWL and RDF constructs.
1.3 OWL syntax
An OWL ontology is encoded and written as an RDF graph
[RDF Concepts],
which is in turn a set of RDF triples.
As with any RDF graph, an OWL ontology graph can be
written in many different syntactic forms (as described in the
RDF/XML Syntax Specification (Revised)
[RDF/XML Syntax]).
This document (as does the Guide document)
uses some specific syntactic forms of RDF/XML for representing triples.
However, the meaning of an OWL ontology is solely determined by the
RDF graph. Thus, it is allowable to use any syntactic RDF
forms, as long as these
result in the same underlying set of RDF triples.
Such other syntactic forms would then carry exactly the same
prescribed meaning as the syntactic form used in this
document.
As a simple example of an alternative syntactic
form resulting in the same RDF graph, consider
the following RDF/XML syntax:
<owl:Class rdf:ID="Continent"/>
The following RDF/XML syntax:
<rdf:Description rdf:about="#Continent">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description>
encodes the same set of RDF triples, and therefore
would convey the same meaning.
1.4 OWL and RDF semantics
OWL is a vocabulary extension of RDF. Thus any RDF graph forms an OWL
Full ontology. Further, the meaning given to an RDF graph by OWL includes the
meaning given to the graph by RDF. OWL Full
ontologies can thus include arbitrary
RDF content, which is treated in a manner consistent with its treatment by RDF.
OWL assigns an additional meaning to certain RDF triples. The
OWL Semantics and Abstract Syntax document
[OWL
S&AS] specifies exactly which triples are assigned a
specific meaning, and what this meaning is.
NOTE: As remarked before,
OWL DL and OWL Lite extend the RDF vocabulary, but also put restrictions
on the use of this vocabulary.
For readability purposes the examples in this document assume the
XML entities &rdf;, &rdfs;,
&owl; and &xsd; (for XML Schema datatypes)
are defined in the same way
as in Appendix B. The same assumption holds for the
corresponding namespaces rdf:, rdfs:,
owl: and xsd:.
The examples in this document are meant to serve as illustrations of the
use of OWL language constructs. They do not form one consistent ontology. For
an extended example the reader is referred to the Guide document
[OWL Guide].
OWL's ability to express ontological information about individuals
appearing in multiple documents supports linking of data from diverse
sources in a principled way. The underlying semantics provides
support for inferences over this data that may yield unexpected
results. In particular, the ability to express equivalences using
owl:sameIndiviidualAs
can be used to state that seemingly
different individuals are actually the same.
Similarly,
owl:InverseFunctionalProperty
can be used to link
individuals together.
For example, if a property such as SocialSecurityNumber
is an
owl:InverseFunctionalProperty, then two separate individuals
could be inferred to be identical based on having the same value of
that property. When individuals are determined to be the same by such
means, information about them from different sources can be
merged. This aggregation can be used to determine facts that
are not directly represented in any one source.
This document has a set of appendices containing additional information.
Links in this document that are attached to definitions of
language constructs provide access to the
OWL Semantics and Abstract Syntax
[OWL S&AS].
Appendix A contains a
systematic set of links for each language construct to the
corresponding sections in the Guide and the S&AS documents.
Appendix B
contains an RDF schema for the OWL language constructs.
This schema defines the OWL language constructs in terms of RDF Schema
classes and properties.
This schema
provides the basis for the RDF/XML syntax of OWL. Conventionally, classes
have a leading uppercase character; properties a leading
lowercase character. Thus, owl:Ontology is a class, and
owl:imports is a property.
Appendix C gives a tabular overview of all
OWL language constructs in
terms of the built-in OWL classes and properties (the latter
with their domain and
range).
NOTE: The RDF Schema file for OWL is not expected to be imported explicitly
(i.e. with owl:imports) into an ontology. The schema
has an informative status and is
meant to provide the classes and properties to be used in the RDF/XML syntax.
This schema does not make distinctions between OWL Full, OWL DL and OWL Lite. People
that do import this schema should expect the resulting ontology to be an OWL
Full ontology.
For readers familiar with DAML+OIL, Appendix D lists
many of the changes between DAML+OIL and OWL.
2. OWL document
Information in OWL is gathered into ontologies, which can then be
stored as documents in the World Wide Web. One aspect of OWL, the
importing of ontologies, depends on this ability to store OWL
ontologies in the Web.
An OWL document consists of optional
ontology headers (generally at most one)
plus any number of
class axioms, property axioms,
and facts about individuals.
Please note that "axiom" is the formal term used in the S&AS
document. These axioms are somewhat more informally called
"definitions" in the Guide and Overview documents.
NOTE: OWL does not impose any order on OWL components.
Humans writing ontologies are likely to use some sort of ordering, for example
putting the ontology header in the beginning, but this has no impact on the
meaning. Tools should not assume any order.
As with any RDF document, the OWL code should be subelements of
an rdf:RDF element.
This enclosing element generally holds XML namespace and base declarations.
Also, an OWL ontology document often starts with several entity declarations.
For a typical example of this sort of information, see the wine.owl file,
which contains the example wine ontology
discussed in the Guide document.
The built-in vocabulary for OWL all comes from the OWL namespace
http://www.w3.org/2002/07/owl#
conventionally associated with the namespace name owl.
It is
recommended that ontologies not use names from this namespace except
for the built-in vocabulary. OWL tool builders should feel free to
signal a warning if other names from this namespace are used, but
should otherwise continue as normal.
The Web Ontology Working Group has not requested a separate MIME type for OWL
documents. Instead, we recommend to use the MIME type requested by the RDF Core
Working Group, namely application/rdf+xml
[RDF Concepts],
or alternatively the
XML MIME type application/xml.
As file extension, we recommend to use either .rdf or
.owl.
Classes provide an abstraction mechanism for grouping resources with
similar characteristics. Like RDF classes, every OWL
class is associated with a set of individuals, called the class
extension. The individuals in the class extension are called the
instances of the class. A class has an intensional meaning
(the underlying concept) which is related but not equal to its class
extension. Thus, two classes may have the same class extension, but still be
different classes.
When in this document we use wording such as "a class of individuals
..", this should be read as the "a class with a class extension containing
individuals ...".
NOTE: In OWL Lite and OWL DL an individual can never be at the same time a
class: classes and individuals form disjoint domains (as do properties and data
values). OWL Full allows the freedom of RDF Schema: a class may act as an
instance of another (meta)class (the same holds for properties).
OWL classes are described through "class descriptions", which can be
combined into "class axioms". We first describe class descriptions and
subsequently turn to class axioms.
A class description is the term used in this document (and in the OWL
Semantics and Abstract Syntax) for the basic building blocks of class axioms
(informally called class definitions in the Overview and Guide documents).
OWL distinguishes six types of class descriptions:
- a class identifier (a URI reference)
- an exhaustive enumeration of individuals
that together form the instances of a class
- a property restriction
- the intersection of two or more class
descriptions
- the union of two or more class
descriptions
- the complement of a class description
The first type describes a class through a name.
The other five types of class descriptions define an
anonymous class, respectively
a class that contains exactly the enumerated
individuals (2nd type),
a class of all individuals which satisfy a
particular property restriction (3rd type),
or a class that satisfies boolean combinations of
class descriptions (4th, 5th and 6th type).
Intersection, union and complement can be respectively seen as
the logical AND, OR and NOT operators.
The four latter types of class descriptions lead to nested class
descriptions and can thus in theory lead to arbitrarily complex class
descriptions. In practice, the level of nesting is usually limited.
A type 1 class description is syntactically represented as an named
instance of
owl:Class, a subclass of rdfs:Class:
<owl:Class rdf:ID="Human"/>
This will assert the triple "Human rdf:type owl:Class .".
NOTE: In OWL Lite and OWL DL, owl:Class
must be used for all class descriptions.
NOTE:
owl:Class is defined as a subclass of
rdfs:Class. The rationale for having a separate OWL
class construct lies in the restrictions on OWL
DL (and thus also on OWL Lite), which imply that not all RDFS classes are legal
OWL DL classes. In OWL Full these restrictions do not exist and therefore
owl:Class and rdfs:Class are the same there.
The other five forms of class descriptions are represented as anonymous
instances of owl:Class (a blank node with the rdf:type
owl:Class).
NOTE:
If one provides an RDF identifier for class descriptions of the
type 2-6, this has the extra effect of providing a way of
referring to the class description by its name, i.e., as a class
description of type 1.
See Section 3.2.3 for details.
Two OWL class identifiers are predefined, namely the classes owl:Thing
and owl:Nothing.
The class extension of owl:Thing is the set of all individuals in
the domain of discourse. The class extension of owl:Nothing is the
empty set. Consequently, every OWL class is a
subclass of owl:Thing and owl:Nothing is a subclass
of every class (for the meaning of the subclass relation, see the section on rdfs:subClassOf).
NOTE: owl:Nothing is not included in OWL Lite.
A class description of the
"enumeration" kind is defined with the
owl:oneOf
property, which points to a list of individuals
that are the instances of the class.
This enables a class to be defined by
exhaustively enumerating its instances.
The class extension of the class defined with
owl:oneOf
contains exactly the enumerated
individuals, no more, no less. The list of individuals is typically
represented with the help of the RDF construct
rdf:parseType="Collection", which provides a convenient shorthand for
writing down a set of list elements.
For example, the following RDF/XML syntax
defines a class of all continents:
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Eurasia"/>
<owl:Thing rdf:about="#Africa"/>
<owl:Thing rdf:about="#NorthAmerica"/>
<owl:Thing rdf:about="#SouthAmerica"/>
<owl:Thing rdf:about="#Australia"/>
<owl:Thing rdf:about="#Antarctica"/>
</owl:oneOf>
</owl:Class>
The RDF/XML syntax <owl:Thing rdf:about="..."/>
refers to some individual (remember:
all individuals are by definition instances of
owl:Thing).
In the section on datatypes we will see another use of
the owl:oneOf construct, namely to define an enumeration of data values.
NOTE: Enumeration is not part of OWL Lite
A property restriction is a special kind of class
description. It defines an anonymous class, namely a class of
all individuals that satisfy the restriction.
OWL distinguishes two kinds of restrictions: value constraints and cardinality
constraints.
A value constraint puts constraints on the
value range of the property when applied to this particular class
description.
For example, we might want to
refer to those individuals whose value of the property adjacentTo
should be a Region,
and then use this within a class axiom, perhaps
even a class axiom for Region itself.
Note that this is very different from rdfs:range, which is
applied to all situations in which the property is used.
A cardinality
constraint puts constraints on the number of values a property can take,
in the context of this particular class description.
For example, we might want to say that for a soccer team the
hasPlayer
property has 11 values. For a basketball team the same property
would have only 5 values.
OWL also supports a limited set of constructs for defining global property
cardinality, namely the owl:FunctionalProperty and
the owl:InverseFunctionalProperty
definitions (see the section on properties).
Property restrictions have the following general form:
<owl:Restriction>
<owl:onProperty rdf:resource="(some property)" />
(precisely one value or cardinality constraint, see below)
</owl:Restriction>
The class
owl:Restriction
is defined as a subclass of owl:Class.
A restriction class should
have exactly one triple linking
the restriction to a particular property, using the owl:onProperty
property. The restriction class should also have exactly
one triple that represents the value constraint c.q. cardinality
constraint on the property under consideration, e.g., that the
cardinality of the property is exactly 1.
Property restrictions can be applied both to datatype properties (properties for which the
range value is a data literal) and object
properties (properties for which the range value is an individual). For
more information about this distinction, see the section on
properties.
The value constraint owl:allValuesFrom
is a built-in OWL
property that links a restriction class to either a class description or a data
range. A restriction containing an owl:allValuesFrom
constraint is used to describe a class of all individuals for which all range
values of the property under consideration are either members of the class
extension of the class description or are data values within the specified data
range. In other words, it defines a class of individuals x for which holds
that if the pair (x,y) is an instance of P (the property concerned), then y
should be an instance of the class description or a value in the data range,
respectively.
A simple example:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:allValuesFrom rdf:resource="#Human" />
</owl:Restriction>
This example describes an anonymous OWL class of all individuals for which
the hasParent property only has range values of class
Human. Note that this class description does not state that the property
always has range values of this class; just that this is true for individuals
of the anonymous restriction class.
NOTE: In OWL Lite the range value of owl:allValuesFrom must be
a class identifier.
An owl:allValuesFrom
constraint is analogous to the universal (for-all) quantifier of Predicate
logic - for each instance of the class or datatype that is being defined, every
range value for P must fulfill the constraint. Also notice that the
correspondence of owl:allValuesFrom with the universal
quantifier means that an owl:allValuesFrom constraint for a
property P is trivially satisfied for an individual that has no value for
property P at all. To see why this is so, observe that the owl:allValuesFrom constraint demands that
all values of P belong to class P, and if no such values exist, the constraint
is trivially true.
The value constraint owl:someValuesFrom
is a built-in OWL property that links a restriction class to a class description or a data range. A restriction containing
an owl:someValuesFrom constraint
describes a class of all individuals for which at least one value of the
property concerned is an instance of the class description or a data value in
the data range. In other words, it defines a class of individuals x for
which there is at least one y (either an instance of the class description or
value of the data range) such that the pair (x,y) is an instance of P. This
does not exclude that there are other instances (x,y') of P for which y' does
not belong to the class description or data range.
The following example defines a class of individuals which have at least one
parent who is a physician:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:someValuesFrom rdf:resource="#Physician" />
</owl:Restriction>
The owl:someValuesFrom
constraint is analogous to the existential quantifier of Predicate logic - for
each instance of the class that is being defined, there exists at
least one value for P that fulfills the constraint.
NOTE: In OWL Lite the range value of owl:someValuesFrom must be
a class identifier.
The value constraint owl:hasValue
is a built-in OWL property that links a restriction class
to a value V, which can be either an
individual or a data value.
A restriction containing a owl:hasValue constraint
describes a class of all individuals for
which the property concerned has at least one value semantically
equal to V (it may have other values as well).
NOTE: for datatypes "semantically equal" means that
the lexical representation of the literals maps to the same
value. For individuals it means that they
either have the same URI reference or are defined as being the same
individual (see owl:sameIndividualAs).
NOTE: the value constraint owl:hasValue
is not included in OWL Lite.
The following example describes the class of individuals who have the
individual referred to as Clinton as their parent:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:hasValue rdf:resource="#Clinton" />
</owl:Restriction>
In OWL, like in RDF, it is assumed that any instance of a class may have an
arbitrary number (zero or more) of values for a particular property. To make a
property required (at least one), to allow only a specific number of values for
that property, or to insist that a property must not occur, cardinality
constraints can be used. OWL provides three constructs for restricting the
cardinality of properties locally within a class context.
NOTE: OWL Lite includes the use of all three types of cardinality constraints,
but only when used with the range values "0" or "1".
The cardinality constraint
owl:maxCardinality
is a built-in OWL property that
links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:maxCardinality constraint describes a class of
all individuals that have at most N distinct range values
(individuals or data
values) for the property concerned, where N is the range value of the
cardinality constraint. Syntactically, the cardinality constraint is represented
as an RDF property element with the corresponding rdf:datatype
attribute.
The following example describes a class of individuals that have at most
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>
RDF datatyping is discussed in more detail in
Section "6. Datatypes".
The cardinality constraint
owl:minCardinality
is a built-in OWL property that
links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:minCardinality constraint describes a class of
all individuals that have at least N distinct range values
(individuals or data
values) for the property concerned, where N is the range value of the
cardinality constraint. Syntactically, the cardinality constraint is represented
as an RDF property element with the corresponding rdf:datatype
attribute.
The following example describes a class of individuals that have at least
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:minCardinality>
</owl:Restriction>
Note that an owl:minCardinality of one or more means that a value for the
property is required of any instance of the class.
The cardinality constraint
owl:cardinality
is a built-in OWL property that
links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:cardinality constraint describes a class of
all individuals that have exactly N distinct range values
(individuals or data
values) for the property concerned, where N is the range value of the
cardinality constraint. Syntactically, the cardinality constraint is represented
as an RDF property element with the corresponding rdf:datatype
attribute.
This construct is in fact redundant as it
can always be replaced by a pair of matching
owl:minCardinality
and
owl:maxCardinality
constraints with the same value. It is included as a convenient shorthand for
the user.
The following example describes a class of individuals that have exactly
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:cardinality>
</owl:Restriction>
The three forms of class descriptions in this section represent the more
advanced class constructors that are used in Description Logic. They can be
viewed as representing the AND, OR and NOT operators on classes.
The three operators get the standard set-operator
names: intersection, union and complement. These language constructs also share the
characteristic that they contain nested class descriptions, either
one (complement) or more (union, intersection).
The owl:intersectionOf
property links a class to a list of
class descriptions.
An owl:intersectionOf statement
describes a class for which the class extension contains
precisely those individuals
that are members of the class extension of
all class descriptions in the range list.
An example:
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Tosca" />
<owl:Thing rdf:about="#Salome" />
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Turandot" />
<owl:Thing rdf:about="#Tosca" />
</owl:oneOf>
</owl:Class>
</owl:intersectionOf>
</owl:Class>
In this example the range of the intersection constraint is a list of two
class descriptions, namely two enumerations, both describing a class
with two individuals. The resulting intersection is
a class with one individual, namely
Tosca. as this is the only individual that is
common to both enumerations.
NOTE: This assumes that the three individuals are all
different. In fact, this is not by definition true in OWL.
Different URI references may refer to the
same individuals, because OWL does not have a "unique names" assumption. In
the
section on individuals one can find OWL language constructs for making
constraints about equality and difference of individuals.
NOTE: OWL Lite is restricted in its use of owl:intersectionOf.
This is discussed later in this document, see Section 3.2.3
owl:intersectionOf
can be viewed as being analogous to logical
conjunction.
The owl:unionOf
property links a class to a list of
class descriptions.
An owl:unionOf statement
describes an anonymous class for which the class extension contains
those individuals
that occur in at least one of the class extensions of the
class descriptions in the range list.
An example:
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Tosca" />
<owl:Thing rdf:about="#Salome" />
</owl:oneOf>
</owl:Class>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Turandot" />
<owl:Thing rdf:about="#Tosca" />
</owl:oneOf>
</owl:Class>
</owl:unionOf>
</owl:Class>
This class description describes a class for which the class extension
contains three individuals, namely Tosca, Salome, and Turandot
(assuming they are all different).
NOTE: owl:unionOf is not part of OWL Lite.
owl:unionOf is analogous to logical disjunction.
An
owl:complementOf
property links a class to precisely one class
description.
The owl:complementOf statement defines a class for which the class
extension contains exactly those individuals
that do not belong to the class extension of the
range class. owl:complementOf is
analogous to logical negation, but restricted to individuals only.
As an example of the use of complement,
the expression "not meat" could be written
as:
<owl:Class>
<owl:complementOf>
<owl:Class rdf:about="#Meat"/>
</owl:complementOf>
</owl:Class>
This extension of this class description contains all individual that do not
belong to the class Meat.
NOTE: owl:complementOf is not part of OWL Lite.
Class descriptions form the building blocks for defining classes
through class axioms. The simplest form of a class axiom is a class description
of type 1, It just states
the existence of a class, using
owl:Class with a class identifier.
For example, the following
class axiom declares the URI reference Human to be an OWL
class:
<owl:Class rdf:ID="Human"/>
This is correct OWL, but does not tell us very much about the class
Human. Class axioms typically contain additional components that
state necessary and/or sufficient characteristics of a class. OWL contains
three language constructs for combining class descriptions into class
axioms:
rdfs:subClassOf allows one
to say that the class extension of a
class description is a subset of the class extension of another class
description.owl:equivalentClass allows one
to say that a class description has exactly the
same class extension as another class description.owl:disjointWith allows one
to say that the class extension of a class description has no members in
common with the class extension of another class description.
Syntactically, these three language constructs
are properties that have a class description as
both domain and range. We discuss these properties in more
detail in the following subsections.
In addition, OWL allows class axioms in which a class description of the
enumeration or the set-operator type is given a name. These class axioms are
semantically equivalent to class axioms with a owl:equivalentClass
statement, so these will be discussed right after that subsection (see Section
3.2.3 Axioms for complete classes without
using owl:equivalentClass).
AXIOM SCHEMA:
class description rfs:subClassOf class
description
The rfs:subClassOf construct is
defined as part of RDF Schema
[RDF Schema]. Its meaning in OWL
is exactly the same: if the class description C1 is defined as a subclass of
class description C2, than the set of individuals in the class extension of C1
should be a subset of the set of individuals in the class extension of C2.
A class description is by definition a subclass of itself (as the subset may be
the complete set).
An example:
<owl:Class rdf:ID="Opera">
<rdfs:subClassOf rdf:resource="#MusicalWork" />
</owl:Class>
This class axiom declares a subclass relation between two OWL classes that
are described through their names (Opera and
MusicalWork).
Subclass relations provide necessary conditions for belonging to a class. In
this case, to be an opera the individual also needs to be a musical work.
NOTE: In OWL Lite the domain value of an
rdfs:subClassOf statement must be a class identifier. The range
value must be either a class identifier or a property restriction.
Class axioms can also use the other types of class descriptions, such as
property restrictions, enumerations, intersections, unions and complements.
For any class there may be any number of subClassOf axioms.
For example, we could add the following axiom about the class Opera:
<owl:Class rdf:about="#Opera">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist" />
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
This class axiom contains
a property restriction. The example states that Opera
is a subclass of an anonymous OWL class (remember: owl:Restriction
is a subclass of owl:Class) that has as its class extension
the set of all individuals
for which the property hasLibrettist has at least one
value. Thus, operas should have at least one librettist.
Class axioms can get more complex when class descriptions are nested.
For example, property restrictions with an
owl:allValuesFrom
or
owl:someValuesFrom
statement may point to any class description.
Consider the following example:
<owl:Class rdf:ID="TraditionalItalianOpera">
<rdfs:subClassOf rdf:resource="#Opera"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasOperaType"/>
<owl:someValuesFrom>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#OperaSeria"/>
<owl:Thing rdf:about="#OperaBuffa"/>
</owl:oneOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
This example shows the use of the owl:oneOf construct.
The class axiom defines traditional Italian opera as a subclass of
a class of operas that have as opera type either opera seria or
opera buffa (without an additional cardinality constraint, it could actually
have both values).
More examples can be found in the Guide document and in the
corresponding wine.owl
file.
Subclass axioms provide us with partial definitions: they represent necessary
but not sufficient conditions for establishing class membership of an
individual. In the next subsection we will see that for defining
necessary and sufficient conditions OWL provides the
owl:equivalentClass
construct. As a stepping stone to such axioms,
consider the following example:
<owl:Class rdf:ID="Operetta">
<rdfs:subClassOf rdf:resource="#MusicalWork"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist" />
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class>
<owl:complementOf rdf:resource="#Opera"/>
</owl:Class>
</rdfs:subClassOf>
</owl:Class>
This class axiom states that an operetta is a musical work, that has a
librettist and is not an opera. The use of the subclass relation leaves open
the possibility that there are other musical works that have a librettist and
are
not operas. If we had wanted to say that operetta's are exactly
those musical works that have a librettist but are not operas, we would need to use
the
owl:equivalentClass
construct.
AXIOM SCHEMA:
class description owl:equivalentClass class
description
A class axiom may contain (multiple)
owl:equivalentClass
statements. The construct owl:equivalentClass is a built-in
property that links a class description
to another class description.
The meaning of such a class axiom is that the two class descriptionss involved
have the same class extension
(i.e., both class extensions contain exactly the same set of individuals).
In its simplest form, an equivalentClass
axiom states the equivalence (in terms of their class extension)
of two named
classes. An example:
<owl:Class rdf:about="#US_President">
<equivalentClass rdf:resource="#PrincipalResidentOfWhiteHouse"/>
</owl:Class>
NOTE:
The use of owl:equivalentClass does not imply class
equality. Class equality means that the classes have the same intensional
meaning (denote the same concept). In the example above, the concept of
"President of the US" is related to, but not equal to the concept of the
principal resident of a certain estate.
Real class equality can only be expressed with the owl:sameAs construct (or its synonym
owl:sameIndividualAs, see the section on individuals).
As this requires treating classes as
individuals, class equality can only be expressed in OWL Full.
Axioms with owl:equivalentClass can also be used to define
an enumerated class by linking a type 1 class description (a class identifier)
to a type 2 class description (an enumeration).
An example:
<owl:Class rdf:ID="DaPonteOperaOfMozart">
<owl:equivalentClass>
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<Opera rdf:about="#Nozze_di_Figaro"/>
<Opera rdf:about="#Don_Giovanni"/>
<Opera rdf:about="#Cosi_fan_tutte"/>
</owl:oneOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
This class axiom defines the class of operas
that together represent the "Da Ponte operas of Mozart" (a
popular subject in musicology). By using the equivalentClass construct
we can state
necessary and sufficient conditions for class membership, in this case
consisting of an enumeration of three individuals, no less, no more.
NOTE: OWL DL does not put any constraints on the types of class descriptions
that can be used as domain and range values of an
owl:equivalentClass statement. In OWL Lite only class identifiers
and property restrictions are allowed as domain and range values.
NOTE: Although in principle different types of class descriptions are allowed
as the lefthand-side (domain value) of an equivalentClass statement,
in practice it usually is some class
identifier. The is also true for the examples in this section.
It is possible to have multiple equivalentClass axioms about the same
class.
However, this requires care. Both axioms must lead to the same
outcome, i.e. exactly the same class extension. For example, an alternate
equivalentClass axiom for Mozart's "Da Ponte operas" could be the following
one:
<owl:Class rdf:about="#DaPonteOperaOfMozart">
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComposer"/>
<owl:hasValue rdf:resource="#Wolfgang_Amadeus_Mozart"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist"/>
<owl:hasValue rdf:resource="#Lorenzo_Da_Ponte"/>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
This states that the class extension of the Da Ponte operas of Mozart
corresponds exactly to those operas which are composed
by Mozart and for which the libretto is written by Da Ponte (note: intersection
= "and"). This denotes indeed the same set of individuals as the previous
axiom.
NOTE: If we wanted to "upgrade" an axiom of the form "A
subClassOf B" to "A equivalentClass B" (meaning that the class extension of A
is not just any subset, but in fact the same set as the class extension of B),
we could add a second subClassOf axiom of the form (B subClassOf A), which by
definition makes the two class extensions equivalent
(and thus has the same meaning
as "A equivalentClass B"). Such subClassOf "cycles" are explicitly allowed. As
OWL is usable in a distributed environment, this can be a useful
feature.
AXIOM SCHEMA:
named class description of type 2 (with owl:oneOf) or
type 4-6 (with owl:intersectionOf, owl:unionOf
or owl:complementOf
OWL allows users to define class axioms by giving a name to class
descriptions of the
enumeration or set-operator type. Such a class axiom defines necessary and
sufficient conditions for establishing class membership.
An example:
<owl:Class rdf:ID="DaPonteOperaOfMozart">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Nozze_di_Figaro"/>
<owl:Thing rdf:about="#Don_Giovanni"/>
<owl:Thing rdf:about="#Cosi_fan_tutte"/>
</owl:oneOf>
</owl:Class>
This class axiom should be interpreted as follows: the class extension of
the class DaPonteOperaOfMozart is
exactly defined by the enumeration.
This class axiom is semantically equivalent to the
first example in the previous section, which included an additional
owl:equivalentClass statement. Axioms of this type can also be
constructed with owl:intersectionOf,
owl:unionOf and owl:complenentOf.
An example with a union could be:
<owl:Class rdf:ID="LivingBeing">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Plant"/>
<owl:Class rdf:about="#Animal"/>
</owl:unionOf>
</owl:Class>
This class axiom states that the class extension of
LivingBeing exactly corresponds
to the union of the class extensions of Plant
and Animal.
NOTE: OWL Lite only includes class axioms of this type which are constructed
with the owl:intersectionOf property. The range values of
intersectionOf should be class identifiers and/or property restrictions.
Thus, "complete class" axioms
using enumeration, complement and
union are not allowed in OWL Lite.
AXIOM SCHEMA:
class description owl:disjointWith class
description
A class axiom may also contain (multiple)
owl:disjointWith
statements.
The construct owl:disjointWith is a
built-in property with a class
description as domain and range values.
Each owl:disjointWith statement asserts that
the class extensions of the two class descriptions
involved have no individuals in common. Like axioms with
rdfs:subClassOf, declaring two classes to be disjoint is a partial
definition: it imposes a necessary but not sufficient condition on the
class.
This is a popular example of class disjointness:
<owl:Class rdf:about="Man">
<owl:disjointWith rdf:resource="#Woman"/>
</owl:Class>
Whether this is actually true is a matter for biologists to
decide. The following example shows a common use of class disjointness in
subclass hierarchies:
<owl:Class rdf:about="MusicDrama">
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Opera"/>
<owl:Class rdf:about="#Operetta"/>
<owl:Class rdf:about="#Musical"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
<owl:Class rdf:about="#Opera">
<rdfs:subClassOf rdf:resource="#MusicDrama"/>
</owl:Class>
<owl:Class rdf:about="#Operetta">
<rdfs:subClassOf rdf:resource="#MusicDrama"/>
<owl:disjointWith rdf:resource="#Opera"/>
</owl:Class>
<owl:Class rdf:about="#Musical">
<rdfs:subClassOf rdf:resource="#MusicDrama"/>
<owl:disjointWith rdf:resource="#Opera"/>
<owl:disjointWith rdf:resource="#Operetta"/>
</owl:Class>
Here, owl:disjointWith
statements are used together with
owl:unionOf
in order to define a set of mutually disjoint and complete subclasses of a
superclass. In natural language: every MusicDrama is either an
opera, an Operetta, or a Musical (the subclass
partitioning is complete) and individuals belonging to one subclass,
e.g.,
Opera, cannot belong to another subclass, e.g.,
Musical (disjoint or non-overlapping subclasses). This is a common
modelling notion used in many data-modelling notations.
NOTE: OWL Lite does not allow the use of owl:disjointWith.
OWL distinguishes between two types of properties:
- Object properties have a value range of
class individuals, and thus link individuals to individuals.
- Datatype properties have a value range of data values, and thus
link individuals to data values.
An object property is defined with the help of an
owl:ObjectProperty
class. A datatype property is defined through an owl:DatatypeProperty
class. Both owl:ObjectProperty and
owl:DatatypeProperty are subclasses of the RDF class
rdf:Property (see Appendix B).
NOTE: In OWL Full, object properties and datatype properties are
not disjoint. Because data values can be treated as individuals, datatype
properties are effectively subclasses of object properties.
In OWL Full owl:ObjectProperty is equivalent to
rdf:Property In practice, this
mainly has consequences for the use of
owl:InverseFunctionalProperty.
See also the OWL Full characterization in Section 8.1.
A property axiom defines characteristics of a property.
In its simplest form, a property axiom just defines the existence of
a property. For example:
<owl:ObjectProperty rdf:ID="hasParent"/>
This defines a property with the restriction that the range values should be
individuals.
Often, property axioms define additional characteristics of properties. OWL
supports the following constructs for property axioms:
- RDF Schema constructs:
rdfs:subPropertyOf,
rdfs:domain and rdfs:range
- relations to other properties:
owl:equivalentProperty and
owl:inverseOf
- global cardinality constraints:
owl:FunctionalProperty and
owl:InverseFunctionalProperty
- logical property characteristics:
owl:SymmetricProperty and
owl:TransitiveProperty
In the next subsections, the various types of property axioms are
discussed in more detail.
NOTE: In this section we use the term "property extension" in
a similar fashion to "class extension". The property extension is the set of
instances that is associated with the property. Instances of properties are not
single elements, but subject-object pairs of property statements. In relational
database
terms, property instances would be called "tuples" of a binary relation (the
property).
The constructs in this section are discussed in detail in the RDF Schema
document [RDF Schema]. The
description in this section provides a synopsis of these constructs and
provides some OWL-specific aspects and examples.
A rdfs:subPropertyOf axiom defines that the property
is a subproperty of some other property.
Formally this means that if P1 is a subproperty of P2, then the property
extension of P1 (a set of pairs) should be a subset of the property extension
of P2 (also a set of pairs).
An example:
<owl:ObjectProperty rdf:ID="hasMother">
<rdfs:subPropertyOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>
This states that all instances (pairs) contained in the property extension
of the property "hasMother" are also members of the property extension of the
property "hasParent".
Subproperty axioms can be applied to both datatype properties and object
properties.
NOTE: In OWL DL the domain and range value of a subproperty axiom
must be either both datatype properties or both object properties.
For a property one can define (multiple)
rdfs:domain axiom.
Syntactically, rdfs:domain is a built-in
property that links a property
(some instance of the class rdf:Property)
to a class
description.
An rdfs:domain axiom asserts that the domain values of this
property must belong to the class extension of
the class description.
Multiple rdfs:domain
axioms are allowed and should be interpreted as a conjunction: these
restrict the domain of the property to those individuals that belong to the
intersection of the class descriptions. If one would want to say
that multiple classes can act as domain, one should use a class description
of the owl:unionOf form.
For example, if we want to say that the domain of the property
hasBankAccount can be either a Person or a Corporation, we would need to
say something like this:
<owl:ObjectProperty rdf:ID="hasBankAccount">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Corporation"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
The rdfs:domain restrictions are global, meaning that they
cannot be used for an individual for which the class is not explicitly included
in the domain restriction. Because of this feature, rdfs:domain
axioms should be used with care.
NOTE: In OWL Lite the range value of a rdfs:domain axiom
must be a class identifier.
For a property one can define (multiple)
rdfs:range axioms.
Syntactically, rdfs:range is a built-in
property that links a property
(some instance of the class rdf:Property) to
to either a class
description or a data range.
An rdfs:range axiom asserts that the range values of this
property must belong to the class extension of
the class description or to data values in the specified data range.
Multiple range
restrictions are interpreted as stating that the range of the property is the
intersection of all ranges (i.e.,
the intersection of the class extension of the class descriptions
c.q. the intersection of the data ranges). Similar to
rdfs:domain,
multiple alternative
ranges can be specified by using a class description of the
owl:unionOf form (see the previous subsection).
Note that, unlike any of the value
constraints described in the section on class descriptions,
rdfs:range restrictions are
global. Value constraints such as owl:allValuesFrom
are used in a class description and are only
enforced on the property when applied to that class. In contrast,
rdfs:range restrictions apply to the property irrespective of the
class to which it is applied.
Thus, rdfs:range should be
used with care.
NOTE: In OWL Lite the range value of a rdfs:range axiom must be a
class identifier.
The owl:equivalentProperty
construct can be used to state that two properties have the same property
extension. Syntactically, owl:equivalentProperty is a property
with as both domain and range an instance of rdf:Property.
NOTE: Property equivalence is not the same as property
equality. Equivalent properties have the same "values" (i.e.,
the same property extension),
but may have different intensional meaning (i.e., denote different concepts).
Property equality should be expressed with the owl:sameAs construct. As this
requires that properties are treated as individuals, such axioms are only
allowed in OWL Full.
Properties have a direction, from domain to range. In practice, people often
find it useful to define relations in both directions: persons own
cars, cars are owned by persons.
The owl:inverseOf
construct can be used to define such an inverse relation between
properties.
Syntactically, owl:inverseOf is a property that takes instances
of owl:ObjectProperty as domain and range values.
An axiom of the
form P1 owl:inverseOf P2 asserts
that for every pair
(x,y) in the property extension of P1, there is a pair (y,x) in the class
extension of P2, and vice versa. Thus, owl:inverseOf is a
symmetric property.
An example:
<owl:ObjectProperty rdf:ID="hasChild">
<owl:inverseOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>
A functional property is a property that can have only one
(unique) value y for each instance x, i.e. there
cannot be two distinct range values y1 and y2 such that the pairs (x,y1) and
(x,y2) are both instances of this property.
Both object properties and datatype properties can be declared as
"functional". >For this purpose,
OWL defines the built-in class owl:FunctionalProperty
as a special subclass of the RDF class
rdf:Property.
The following axiom states that the husband property is
functional, i.e., a person can have at most one husband (a good
example of culture dependence of ontologies):
<owl:ObjectProperty rdf:ID="husband">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
</owl:ObjectProperty>
As always, there are other syntactic
variations. The example above
is semantically equivalent to the one below:
<owl:ObjectProperty rdf:ID="husband">
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
</owl:ObjectProperty>
<owl:FunctionalProperty rdf:about="#husband" />
If a
property is declared to be inverse-functional, the a range value uniquely
determines the domain value (some individual). More formally, if we state that
P is an owl:InverseFunctionalProperty, then this asserts that a
range value y can only be the value of P for a single instance x, i.e. there
cannot be two distinct instances x1 and x2 such that both pairs (x1,y) and
(x2,y) are instances of P.
Syntactically, an inverse-functional property axiom is specified by
declaring the property to be an instance of the built-in class
owl:InverseFunctionalProperty,
which is a subclass of the OWL class owl:ObjectProperty.
NOTE: Because in
OWL Full datatype properties are a subclass of object
properties, an inverse-functional property can be defined for
datatype properties. In OWL DL object properties and datatype properties are
disjoint, so an inverse-functional property cannot be defined for datatype
properties. See also Sections 8.1 and 8.2.
A typical example of an inverse-functional property:
<owl:InverseFunctionalProperty rdf:ID="biologicalMotherOf">
<rdfs:domain rdf:resource="#Woman"/>
<rdfs:range rdf:resource="#Human"/>
</owl:InverseFunctionalProperty>
This example states that for each range value (a
human) of the property biologicalMotherOf one should be able
to uniquely identify domain value (a woman). Inverse-functional
properties resemble the notion of a key in databases.
One difference with functional properties is that for inverse-functional
properties no additional object-property or datatype-property axiom is
required: inverse-functional properties are by definition object properties.
Notice that owl:FunctionalProperty and owl:InverseFunctionalProperty
specify global cardinality constraints. That is, no matter which class the
property is applied to, the cardinality constraints must hold. This is
different from the cardinality constraints contained in property restrictions. The latter are class
descriptions and are only enforced on the property when applied to that
class.
When one defines a property P to be a transitive property, this means
that if a pair (x,y) is an instance
of P, and the pair (y,z) is also instance of P, then we can infer
the the pair (x,z) is also
an instance of P.
Syntactically, a property is defined as being transitive by making it an
instance of the the built-in OWL property class
owl:TransitiveProperty,
which is defined as a subclass of owl:ObjectProperty.
Typical examples of transitive properties are properties
representing certain part-whole relations.
For example, we might want to say that the
subRegionOf property between regions is transitive:
<owl:TransitiveProperty rdf:ID="subRegionOf">
<rdfs:domain rdf:resource="#Region"/>
<rdfs:range rdf:resource="#Region"/>
</owl:TransitiveProperty>
From this an OWL reasoner should be able to derive that if
ChiantiClassico,
Tuscany and Italy are regions, and
ChiantiClassico is a subregion of Tuscany, and
Tuscany is a subregion of Italy, then
ChiantiClassico is also a subregion of Italy.
Note that because owl:TransitiveProperty is a subclass of
owl:ObjectProperty, the following syntactic variant is equivalent
to the example above:
<owl:ObjectProperty rdf:ID="subRegionOf">
<rdf:type rdf:resource="&owl;TransitiveProperty"/>
<rdfs:domain rdf:resource="#Region"/>
<rdfs:range rdf:resource="#Region"/>
</owl:ObjectProperty>
NOTE: OWL DL requires that for a transitive property no local or global
cardinality constraints should be declared on the property itself or its
subproperties, nor on the inverse of the property or its subproperties.
A symmetric property is a property for which holds that
if the pair (x,y) is an instance
of P, then the pair (y,x) is also
an instance of P.
Syntactically, a property is defined as symmetric by making it an
instance of the built-in OWL property class
owl:SymmetricProperty
is also
a subclass of owl:ObjectProperty.
A popular example of a symmetric property is the friendOf
relation:
<owl:SymmetricProperty rdf:ID="friendOf">
<rdfs:domain rdf:resource="#Human"/>
<rdfs:range rdf:resource="#Human"/>
</owl:SymmetricProperty>
Symmetric properties should have identical domains and ranges to make
sense.
Individual axioms (also called "facts") are statements about individuals,
indicating class membership and statements about relevant properties. As an
example, consider the following set of statements about an instance of the
class Opera:
<Opera rdf:ID="Tosca">
<hasComposer rdf:resource="#Giacomo_Puccini"/>
<hasLibrettist rdf:resource="#Victorien_Sardou"/>
<hasLibrettist rdf:resource="#Giuseppe_Giacosa"/>
<hasLibrettist rdf:resource="#Luigi_Illica"/>
<premiereDate rdf:datatype="&xsd;date">1900-01-14</premiereDate>
<premierePlace rdf:resource="#Roma"/>
<numberOfActs rdf:datatype="&xsd;positiveInteger">3</numberOfActs>
</Opera>
This example includes a number of facts
about the opera Tosca,
composed by Giacomo Puccini. The opera has three libretto writers. The property
premiereDate links an opera to a typed literal
with as datatype the XML Schema datatype
date. The XML schema document on datatypes
[XML Schema Datatypes]
contains the relevant information about syntax and semantics of
this datatype.
Individual axioms need not necessarily be about named individuals: they can
also refer to anonymous individuals. As an example, consider the piece of
RDF/XML below. The example defines some facts about an anonymous instance of
the class
Measurement, a quantitative observation for which facts such as
the subject under observation, the observed phenomenon, the observed value, and
the observation time are listed:
<Measurement>
<observedSubject rdf:resource="#JaneDoe"/>
<observedPhenomenon rdf:resource="#Weight"/>
<observedValue>
<Quantity>
<quantityValue rdf:datatype="&xsd;float">59.5</quantityValue>
<quantityUnit rdf:resource="#Kilogram"/>
</Quantity>
</observedValue>
<timeStamp rdf:datatype="&xsd;dateTime">2003-01-24T09:00:08+01:00</timeStamp>
</Measurement>
This individual axiom contains two anonymous individuals, namely some
Measurement and some Quantity. In natural language,
for
the subject Jane Doe the measured value of the phenomenon
Weight is some
quantity, which has a value of 59.5 using the unit of kilogram. The time of
measurement is January 24, 2003, eight seconds past nine in the morning, in the
time zone UTC+1 (winter time in Amsterdam, Berlin, Paris). As before,
float and dateTime are XML Schema datatypes, the
syntactic and semantic details of which can be found in the relevant XML Schema
documentation
[XML Schema Datatypes].
Many languages have a so-called "unique names" assumption: different names
refer to different things in the world. On the web, such an assumption is not
possible. For example, the same person could be referred to in many different
ways (i.e. with different URI references). For this reason OWL does not make
this assumption. Unless an explicit statement is being made that two URI
references refer to the same or to different individuals, OWL tools should in
principle assume either situation is possible.
OWL provides three constructs for making statements about the identity of
individuals:
owl:sameAs is used to state that two URI references refer to
the same individual. The construct owl:sameIndividualAs is a synonym
of owl:sameAsowl:differentFrom is used to state that two URI references
refer to different individualsowl:AllDifferent provides an idiom for stating that a list
of individuals are all different.
The property owl:sameAs
has as its domain and range an individual.
Such an owl:sameAs statement indicates that
two URI references actually refer to the same thing: the
individuals have the same "identity". For historical reasons, OWL also supports
owl:sameIndividualAs as a synonym with exactly the same
meaning.
For individuals such as "people" this
notion is relatively easy to understand. For example, we could state that
the following two URI references actually refer to the same person:
<owl:Human rdf:about="#William_Jefferson_Clinton">
<owl:sameAs rdf:resource="#BillClinton"/>
</owl:Human>
The owl:sameAs statements are often used in defining mappings
between ontologies. It is unrealistic to assume everybody will use the same
name to refer to individuals. That would require some grand design, which is
contrary to the spirit of the web.
In OWL Full, where class can be treated as instances of (meta)classes, we
can use the owl:sameAs construct to define class equality,
thus indicating that two concepts have the same intensional meaning.
An example:
<owl:Class rdf:ID="FootballTeam">
<owl:sameAs rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>
One could imagine this axiom to be part of a European sports ontology. The
two classes are treated here as individuals, in this case as instances of the
class owl:Class. This allows us to state that the class
FootballTeam in some European sports ontology denotes the same concept as the
class SoccerTeam in some American sports ontology. Note the difference with
the statement:
<footballTeam owl:equivalentClass us:soccerTeam />
which states that the two classes have the same class extension, but are not
(necessarily) the same concepts.
An owl:differentFrom
property links an individual to another individual.
An owl:differentFrom statement indicates that two URI references
refer to different individuals.
An example:
<Opera rdf:ID="Don_Giovanni"/>
<Opera rdf:ID="Nozze_di_Figaro">
<owl:differentFrom rdf:resource="#Don_Giovanni"/>
</Opera>
<Opera rdf:ID="Cosi_fan_tutte">
<owl:differentFrom rdf:resource="#Don_Giovanni"/>
<owl:differentFrom rdf:resource="#Nozze_di_Figaro"/>
</Opera>
This states that there are three operas, which are all different individuals.
For ontologies in which the unique-names assumption holds, the use of
owl:differentFrom is likely to lead to a large number of
statements, as all individuals have to be declared pairwise disjoint. For such
situations OWL provides a special idiom in the form of the construct owl:AllDifferent.
The owl:AllDifferent construct is a special OWL class, for which
the property owl:distinctMembers
is defined, which
links an instance of owl:AllDifferent to a list of individuals. The
intended meaning of such a statement is that all individuals in the list are
all different from each other.
An example:
<owl:AllDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<Opera rdf:about="#Don_Giovanni"/>
<Opera rdf:about="#Nozze_di_Figaro"/>
<Opera rdf:about="#Cosi_fan_tutte"/>
<Opera rdf:about="#Tosca"/>
<Opera rdf:about="#Turandot"/>
<Opera rdf:about="#Salome"/>
</owl:distinctMembers>
</owl:AllDifferent>
This states that these six URI references all
point to different operas.
NOTE: owl:distinctMembers is a special syntactical construct added
for convenience and should always be used with an owl:AllDifferent
individual as its domain value.
6. Datatypes
In a number of places in this document we have seen the notion of a
data range
for specifying a range of data values. OWL allows two types of data range
specifications:
6.1 RDF Datatypes
OWL makes use of the RDF datatyping scheme, which provides a mechanism for
referring to XML Schema datatypes
[XML Schema Datatypes]. For a
detailed description the reader is referred to the RDF documents, e.g.,
[RDF Concepts].
For the convenience of
the reader, we provide here a
synopsis of the use of RDF datatypes.
Data values are instances of the RDF Schema class
rdfs:Literal. Literals can be either
plain (no datatype) or typed. Datatypes are instances of the class
rdfs:Datatype. A
typed literal needs to have an XML attribute rdf:datatype of which
the value is recommended to be one of the following:
- A canonical URI reference to an XML Schema datatype of the form:
http://www.w3.org/2001/XMLSchema#NAME
where "NAME" should be the name of a simple XML Schema
built-in datatype, as defined in Section 3 of
[XML Schema Datatypes], with the
provisos specified below.
- The RDF datatype
rdf:XMLLiteral.
This datatype is used to
include XML content into an RDF/OWL document. The URI reference of this
datatype is:
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
For details about this datatype, see the RDF Concepts document
[RDF Concepts].
- The RDF datatype
rdfs:Literal
which is the class of literals, typed and plain. The URI reference of this
datatype is:
http://www.w3.org/2000/01/rdf-schema#Literal
The following are the recommended simple built-in XML Schema datatypes
for use in OWL ontologies:
- The primitive datatype
xsd:string,
plus the following datatypes derived from xsd:strong:
xsd:normalizedString,
xsd:token,
xsd:language,
xsd:NMTOKEN,
xsd:Name,and
xsd:NCName.
- The primitive datatype
xsd:boolean.
- The primitive numerical datatypes
xsd:decimal,
xsd:float, and
xsd:double,
plus all derived types of xsd:decimal
(
xsd:integer,
xsd:positiveInteger.
xsd:nonPositiveInteger,
xsd:negativeInteger,
xsd:nonNegativeInteger,
xsd:long,
xsd:int,
xsd:short,
xsd:byte,
xsd:unsignedLong,
xsd:unsignedInt,
xsd:unsignedShort,
xsd:unsignedByte)
- The primitive time-related datatypes:
xsd:dateTime,
xsd:time,
xsd:date,
xsd:gYearMonth,
xsd:gYear,
xsd:gMonthDay,
xsd:gDay, and
xsd:gMonth.
- The primitive datatypes
xsd:hexBinary,
xsd:base64Binary, and
xsd:anyURI.
The following datatypes are NOT recommended for use in OWL
(see for details the OWL Semantics and Abstract Syntax document
[OWL S&AS]):
xsd:duration,
xsd:QName.
xsd:ENTITY,
xsd:NOTATION,
xsd:ID,
xsd:IDREF,
xsd:IDREFS,
xsd:ENTITIES, and
xsd:NMTOKENS.
NOTE: It is not illegal, although not recommended, for applications to define
their own datatypes by defining an instance of rdfs:Datatype. Such
datatypes are "unrecognized", but are treated in a similar fashion as
"unsupported datatypes" (see Sect. 6.3
for details about how these should be treated by OWL tools).
When using datatypes, please note that even if
the range of a property is declared to be of a certain datatype, RDF still
requires a rdf:datatype attribute in a statement about this
property, otherwise it is treated as a plain literal.
An example could be the declaration of a property
that we used earlier in the Measurement example:
<owl:DatatypeProperty rdf:about="#timeStamp">
<rdfs:domain rdf:resource="#Measurement"/>
<rdf:range rdf:resource="&xsd;dateTime"/>
</owl:DatatypeProperty>
<Measurement>
<timeStamp rdf:datatype="&xsd;dateTime">2003-01-24T09:00:08+01:00</timeStamp>
</Measurement>
6.2 Enumerated datatype
In addition to the RDF datatypes, OWL provides one additional construct for
defining a range of data values, namely an enumerated datatype. This datatype
format makes use of the owl:oneOf construct, that is also used for
describing an enumerated class. In the case of
an enumerated datatype, the domain value of owl:oneOf is a blank
node of class
owl:DataRange
and the range value is a list of
literals. Unfortunately, we cannot use the
rdf:parseType="Collection" idiom for specifying the literal list,
because RDF requires the collection to be a list of RDF node
elements. Therefore we have to specify the list of data values with the basic
list constructs rdf:first, rdf:rest and
rdf:nil.
The example below specifies the range of the property
tennisGameScore to be the list of integer values {0, 15, 30, 40}:.
<owl:DatatypeProperty rdf:ID="tennisGameScore">
<rdfs:range>
<owl:DataRange>
<owl:oneOf>
<rdf:List>
<rdf:first rdf:datatype="xsd:integer">0</rdf:first>
<rdf:rest>
<rdf:List>
<rdf:first rdf:datatype="xsd:integer">15</rdf:first>
<rdf:rest>
<rdf:List>
<rdf:first rdf:datatype="xsd:integer">30</rdf:first>
<rdf:rest>
<rdf:List>
<rdf:first rdf:datatype="xsd:integer">40</rdf:first>
<rdf:rest rdf:resource="&rdf;nil" />
</rdf:List>
</rdf:rest>
</rdf:List>
</rdf:rest>
</rdf:List>
</rdf:rest>
</rdf:List>
</owl:oneOf>
</owl:DataRange>
</rdfs:range>
</owl:DatatypeProperty>
NOTE: Enumerated datatypes are not part of OWL Lite.
6.3 Support for datatype reasoning
Tools may vary in terms of support for datatype reasoning. As a minimum,
tools should support datatype reasoning for the XML Schema datatypes
xsd:string and xsd:integer. For unsupported
datatypes, lexically identical
literals should be considered equal, whereas lexically different literals
would not be known to be either equal or unequal.
Unrecognized datatypes should be treated in the same way as
unsupported datatypes.
7.1 Annotations
OWL DL allows annotations on classes, properties, individuals
and ontology headers, but only under the following conditions:
Five annotation properties are predefined by OWL, namely:
owl:versionInfordfs:labelrdfs:commentrdfs:seeAlsordfs:isDefinedBy
Here is an example of legal use of an annotation property is OWL DL:
<owl:AnnotationProperty rdf:about="&dc;creator"/>
<owl:Class rdf:about="MusicalWork">
<rdfs:label>Musical work</rdf:label>
<dc:creator>N.N.</dc:creator>
</owl:Class>
The example assumes &dc; and dc: point
respectively to the Dublin Core URI and namespace. Thus, using
Dublin Core annotations in OWL DL requires an explicit typing triple.
This ensures annotations are handled in a semantically correct fashion by OWL
DL reasoners
(see the OWL Semantics and Abstract Syntax document [OWL S&AS] for details).
An ontology header component is represented with an instance of the class
owl:Ontology, which typically identifies the containing document
with a same-document reference [section 4.2 of RFC2396], and
which may optionally contain, in any order, any number of import and/or
versioning statements.
A sample ontology header could look like this:
<owl:Ontology rdf:about="">
<owl:versionInfo>v 1.17 2003/02/26 12:56:51 mdean</owl:versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<owl:imports rdf:resource="http://www.example.org/foo"/>
</owl:Ontology>
The rdf:about="" refers to the current document.
The following sections describe the various types of statements that are
typically used within the header.
An owl:imports
statement references another OWL ontology containing definitions, whose meaning
is considered to be part of the meaning of
the importing ontology. Each reference consists of a URI
specifying from where the ontology is to be imported.
Technically, owl:imports is a property with an instance of the
class owl:Ontology as its domain and range.
The owl:imports statements are transitive, that is, if
ontology A imports B, and B imports C, then A imports both B and C.
Importing an ontology into itself is considered a null action, so if
ontology A imports B and B imports A, then they are considered to be
equivalent.
Note that the importing a document is different than creating a
namespace reference. owl:imports do not set up a shorthand notation
for names as does a namespace reference. On the other hand, the
namespace reference does not imply that all (or even any) ontological
terms from that namespace are being imported. Therefore, it is common
to have a corresponding namespace declaration for any ontology that is
imported.
An
owl:versionInfo
statement generally contains a string giving information about this
version, for example RCS/CVS keywords. This statement does not
contribute to the logical meaning of the ontology other than that
given by the RDF(S) model theory.
Although this property is typically used to make statements about
ontologies, it may be applied to any OWL construct. For example, one could
attach a owl:versionInfo statement to an OWL class.
An owl:priorVersion
statement contains a reference to another ontology. This identifies
the specified ontology as a prior version of the containing ontology.
This has no meaning in the model-theoretic semantics other than that
given by the RDF(S) model theory. However, it may be used by software
to organize ontologies by versions.
The owl:priorVersion construct is a property with an instance
of the class owl:Ontology as its domain and range.
An owl:backwardCompatibleWith
statement contains a reference to another ontology. This identifies
the specified ontology as a prior version of the containing ontology,
and further indicates that it is backward compatible with it. In
particular, this indicates that all identifiers from the previous
version have the same intended interpretations in the new version.
Thus, it is a hint to document authors that they can safely change
their documents to commit to the new version (by simply updating
namespace declarations and owl:imports statements to refer to the URL of
the new version). If owl:backwardCompatibleWith is not
declared for two versions, then compatibility should not be assumed.
owl:backwardCompatibleWith
has no meaning in the model theoretic semantics other than that given by the
RDF(S) model theory.
The owl:backwardCompatibleWith construct is a property with an instance
of the class owl:Ontology as its domain and range.
An owl:incompatibleWith
statement contains a reference to another ontology. This indicates that the
containing ontology is a later version of the referenced ontology, but is not
backward compatible with it. Essentially, this is for use by ontology authors
who want to be explicit that documents cannot upgrade to use the new version
without checking whether changes are required.
owl:incompatibleWith has
no meaning in the model theoretic semantics other than that given by the
RDF(S) model theory.
The owl:incompatiblewith construct is a property with an
instance of the class owl:Ontology as its domain and range.
Deprecation is a
feature commonly used in versioning software (for example, see the Java
programming language) to indicate that a particular feature is preserved for
backward-compatibility purposes, but may be phased out in the future. Here, a
specific identifier is said to be of type owl:DeprecatedClass
or owl:DeprecatedProperty,
where owl:DeprecatedClass is a subclass of rdfs:Class
and owl:DeprecatedProperty is a subclass of
rdf:Property. By deprecating a term, it means that the term
should not be used in new documents that commit to the ontology. This allows
an ontology to maintain backward-compatibility while phasing out an old
vocabulary (thus, it only makes sense to use deprecation in combination with
backward compatibility). As a result, it it easier for old data and
applications to migrate to a new version, and thus can increase the level of
adoption of the new version. This has no meaning in the model theoretic
semantics other than that given by the RDF(S) model theory. However, authoring
tools may use it to warn users when checking OWL markup.
An example of deprecation is:
<owl:Ontology rdf:about="">
<rdfs:comment>Vehicle Ontology, v. 1.1</rdfs:comment>
<owl:backwardCompatibleWith rdf:resource="http://www.example.org/vehicle-1.0"/>
<owl:priorVersion rdf:resource="http://www.example.org/vehicle-1.0"/>
</owl:Ontology>
<owl:DeprecatedClass rdf:ID="Car">
<rdfs:comment>Automobile is now preferred</rdfs:comment>
</owl:DeprecatedClass>
<owl:Class rdf:ID="Automobile">
<owl:equivalentClass rdf:resource="#Car"/>
<!-- note that equivalentClass only means that the classes have the same
extension, so this DOES NOT lead to the entailment that
Automobile is of type DeprecatedClass too -->
</owl:Class>
<owl:DeprecatedProperty rdf:ID="hasDriver">
<rdfs:comment>inverse property drives is now preferred</rdfs:comment>
</owl:DeprecatedProperty>
<owl:ObjectProperty rdf:ID="drives">
<owl:inverseOf rdf:resource="#hasDriver"/>
</owl:ObjectProperty>
In the introduction we briefly discussed the three sublanguages of OWL. In
this section an informative
specification is given of the differences between the
three "species" of OWL. A formal account of the differences is given in the
Semantics and Abstract Syntax document [OWL S&AS].
OWL Full is not actually a sublanguage. OWL Full contains all the OWL
language constructs and provides free, unconstrained use of RDF constructs.
In OWL Full The resource owl:Class is equivalent to
rdfs:Class. This is different from OWL DL
and OWL Lite, where owl:Class is a proper subclass of
rdfs:Class (meaning that not all RDF classes are OWL
classes in OWL DL and OWL Lite).
OWL Full also allows classes to be treated as individuals. For
example, it is perfectly legal in OWL Full to have a "Fokker-100" identifier
which acts both as a class name (denoting the set of Fokker-100 airplanes
flying around the world) and as an individual name (e.g.,
an instance of the
class AirplaneType).
In OWL Full all data values are considered to also be part of the individual
domain. In fact, in OWL Full the universe of individuals consists of
all resources.
This means that object properties and datatype properties are not
disjoint. In OWL Full owl:ObjectProperty is equivalent to
rdf:Property. The consequence is
that datatype properties are effectively
a subclass of object properties. (Note: the fact that
owl:ObjectProperty and owl:DatatypeProperty are both
subclasses of rdf:Property is not inconsistent with this).
Although from the semantics point of view it is not forbidden in OWL Full to declare
datatype properties to be inverse, transitive, or symmetric, in practice this
does not make much sense. (RDF does not allow data values as the subject of a
statement). However, for inverse-functional properties this does
make sense and such a definition is thus explicitly allowed in OWL Full.
OWL Full will typically be useful for people who want to combine the
expressivity of OWL with the flexibility and metamodelling features of RDF.
However, use of the OWL Full features means that one loses some
guarantees (see below) that OWL DL and OWL Lite can provide
for reasoning systems.
NOTE: RDF documents will generally be in OWL Full, unless they are
specifically constructed to be in OWL DL or Lite.
NOTE: Thus, in OWL Full
owl:Thing is equivalent to
rdf:Resource,
owl:Class is equivalent to
rdfs:Class, and
owl:ObjectProperty is equivalent to
rdf:Property,
OWL DL is a sublanguage of OWL which places a number of constraints on
the use of the OWL language constructs. Briefly, these constraints are the
following:
- OWL DL requires a pairwise separation between classes, datatypes,
datatype properties, object properties, annotation properties, ontology
properties (i.e., the import and versioning stuff),
individuals, data values and the built-in vocabulary. This means that, for
example, a class cannot be at the same time an individual.
- In OWL DL the set of object properties and datatype properties are
disjoint. This implies that the following four property characteristics:
can never be specified for datatype
properties
- OWL DL requires that no cardinality constraints (local nor global)
can be placed on transitive properties or their inverses or any of their
superproperties.
- Annotations are allowed only under certain conditions. See Section 7.1 for details.
- Most RDF(S) vocabulary cannot be used within OWL DL. See the OWL
Semantics and Abstract Syntax document [OWL S&AS] for details.
- All axioms must be well-formed, with no missing or extra components, and
must form a tree-like structure.
The last constraint implies that all classes and properties that one
refers to are explicitly typed as OWL classes or properties, respectively.
For example, if the ontology contains the following component:
<owl:Class rdf:ID="C1">
<rdfs:subClassOf rdf:about="#C2" />
</owl:Class>
then the ontology (or an ontology imported into this ontology)
should contain a owl:Class triple for
C2.
- Axioms (facts) about individual equality and difference must be about
named individuals.
These constraints of OWL DL may seem like an arbitrary set, but in fact
they are not. The constraints are based on work in the
area of reasoners for Description Logic, which require these restrictions to
provide the ontology builder or user with reasoning support.
In particular, the OWL DL restrictions allow the maximal subset of OWL
Full against which current research can assure that a decidable
reasoning procedure can exist for an OWL reasoner.
OWL Lite abides by all the restrictions OWL DL puts on the use of the OWL
language constructs.
In addition, OWL Lite forbids the use of:
In addition, OWL Lite requires that:
- the subject of
owl:equivalentClass triples be named classes
and the object of owl:equivalentClass triples be named classes,
restrictions, or subjects of owl:intersectionOf triples;
- the subject of
rdfs:subClassOf triples be named classes
and the object of rdfs:subClassOf triples be named classes or
restrictions;
owl:intersectionOf be used only on lists of length greater
than one that contain only named classes and restrictions;
NOTE: This is a prototypical example of legal use of
owl:intersectionOf in OWL Lite:
<owl:Class rdf:ID="Woman">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Female"/>
<owl:Class rdf:about="#Human"/>
</owl:intersectionOf>
</owl:Class/>
- the object of
owl:allValuesFrom and
owl:someValuesFrom triples be named
classes or named datatypes;
- the object of
rdf:type triples be named classes or
restrictions;
- the object of
rdfs:domain triples be named classes;
and
- the object of
rdfs:range triples be named classes or
datatypes.
The idea behind the OWL Lite expressivity limitations is that they provide a
minimal useful subset of language features, that are relatively straightforward
for tool developers to support. The language constructs of OWL Lite provide the
basics for subclass hierarchy construction: subclasses, value and cardinality
restrictions. In addition, OWL Lite allows properties to be made optional or
required (using the cardinality features).
The limitations on OWL Lite place it in a lower complexity class than OWL
DL. This can have a positive impact on the efficiency of complete reasoners
for OWL Lite.
Implementations that support only the OWL Lite vocabulary,
but otherwise relax the restrictions of OWL DL, cannot make certain
computational claims with respect to consistency and complexity.
However, such implementations may be useful in providing
interoperability of OWL systems with RDFS models, databases, markup tools, or
other non-reasoning tools.
The Web Ontology Working Group has not provided a name for this
potentially useful subset.
NOTE: This appendix only contains the OWL-specific constructs. For the RDF/RDFS
constructs see the relevant RDF documentation, in particular the RDF Schema document
[RDF Schema].
Appendix B. RDF Schema of OWL (Normative)
<?xml version="1.0"?>
<!DOCTYPE owl [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
]>
<rdf:RDF
xmlns ="&owl;"
xmlns:owl ="&owl;"
xml:base ="http://www.w3.org/2002/07/owl"
xmlns:rdf ="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:dc ="http://purl.org/dc/elements/1.1/"
>
<Ontology rdf:about="">
<versionInfo>March 18. 2003, GS</versionInfo>
<imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/>
<dc:title>Classes and properties for the Web Ontology Language OWL</dc:title>
<dc:creator>W3C Web Ontology (WebOnt) Working Group</dc:creator>
<dc:subject>OWL; Web Ontology Language; Semantic Web</dc:subject>
<dc:description>This file specifies in RDF Schema format the
built-in classes and properties that together form the basis of
the RDF/XML syntax of OWL Full, OWL DL and OWL Lite with the help
of RDF Schema. We do not expect people to import this file
explicitly into their ontology. People that do import this file
should expect their ontology to be an OWL Full ontology.
</dc:description>
<dc:publisher>W3C</dc:publisher>
<dc:date>2003-02-10</dc:date>
<dc:format>text/xml</dc:format>
<dc:language>en</dc:language>
<dc:identifier>http://www.w3.org/2002/07/owl</dc:identifier>
</Ontology>
<rdfs:Class rdf:ID="Class">
<rdfs:label>Class</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdfs;Class"/>
</rdfs:Class>
<Class rdf:ID="Thing">
<rdfs:label>Thing</rdfs:label>
<unionOf rdf:parseType="Collection">
<Class rdf:about="#Nothing"/>
<Class>
<complementOf rdf:resource="#Nothing"/>
</Class>
</unionOf>
</Class>
<Class rdf:ID="Nothing">
<rdfs:label>Nothing</rdfs:label>
<complementOf rdf:resource="#Thing"/>
</Class>
<rdf:Property rdf:ID="equivalentClass">
<rdfs:label>equivalentClass</rdfs:label>
<rdfs:subPropertyOf rdf:resource="&rdfs;subClassOf"/>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="#Class"/>
</rdf:Property>
<rdf:Property rdf:ID="disjointWith">
<rdfs:label>disjointWith</rdfs:label>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="#Class"/>
</rdf:Property>
<rdf:Property rdf:ID="equivalentProperty">
<rdfs:label>equivalentProperty</rdfs:label>
<rdfs:subPropertyOf rdf:resource="&rdfs;subPropertyOf"/>
</rdf:Property>
<rdf:Property rdf:ID="sameIndividualAs">
<rdfs:label>sameIndividualAs</rdfs:label>
<rdfs:domain rdf:resource="#Thing"/>
<rdfs:range rdf:resource="#Thing"/>
<rdfs:subPropertyOf rdf:resource="#sameAs"/>
</rdf:Property>
<rdf:Property rdf:ID="sameAs">
<rdfs:label>sameAs</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#sameIndividualAs"/>
</rdf:Property>
<rdf:Property rdf:ID="differentFrom">
<rdfs:label>differentFrom</rdfs:label>
<rdfs:domain rdf:resource="#Thing"/>
<rdfs:range rdf:resource="#Thing"/>
</rdf:Property>
<rdfs:Class rdf:ID="AllDifferent">
<rdfs:label>AllDifferent</rdfs:label>
</rdfs:Class>
<rdf:Property rdf:ID="distinctMembers">
<rdfs:label>distinctMembers</rdfs:label>
<rdfs:domain rdf:resource="#AllDifferent"/>
<rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>
<rdf:Property rdf:ID="unionOf">
<rdfs:label>unionOf</rdfs:label>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>
<rdf:Property rdf:ID="intersectionOf">
<rdfs:label>intersectionOf</rdfs:label>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>
<rdf:Property rdf:ID="complementOf">
<rdfs:label>complementOf</rdfs:label>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="#Class"/>
</rdf:Property>
<rdf:Property rdf:ID="oneOf">
<rdfs:label>oneOf</rdfs:label>
<rdfs:domain rdf:resource="#Class"/>
<rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>
<rdfs:Class rdf:ID="Restriction">
<rdfs:label>Restriction</rdfs:label>
<rdfs:subClassOf rdf:resource="#Class"/>
</rdfs:Class>
<rdf:Property rdf:ID="onProperty">
<rdfs:label>onProperty</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&rdf;Property"/>
</rdf:Property>
<rdf:Property rdf:ID="allValuesFrom">
<rdfs:label>allValuesFrom</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&rdfs;Class"/>
</rdf:Property>
<rdf:Property rdf:ID="hasValue">
<rdfs:label>hasValue</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
</rdf:Property>
<rdf:Property rdf:ID="someValuesFrom">
<rdfs:label>someValuesFrom</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&rdfs;Class"/>
</rdf:Property>
<rdf:Property rdf:ID="minCardinality">
<rdfs:label>minCardinality</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>
<rdf:Property rdf:ID="maxCardinality">
<rdfs:label>maxCardinality</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>
<rdf:Property rdf:ID="cardinality">
<rdfs:label>cardinality</rdfs:label>
<rdfs:domain rdf:resource="#Restriction"/>
<rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>
<rdfs:Class rdf:ID="ObjectProperty">
<rdfs:label>ObjectProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdfs:Class rdf:ID="DatatypeProperty">
<rdfs:label>DatatypeProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdf:Property rdf:ID="inverseOf">
<rdfs:label>inverseOf</rdfs:label>
<rdfs:domain rdf:resource="#ObjectProperty"/>
<rdfs:range rdf:resource="#ObjectProperty"/>
</rdf:Property>
<rdfs:Class rdf:ID="TransitiveProperty">
<rdfs:label>TransitiveProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="#ObjectProperty"/>
</rdfs:Class>
<rdfs:Class rdf:ID="SymmetricProperty">
<rdfs:label>SymmetricProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="#ObjectProperty"/>
</rdfs:Class>
<rdfs:Class rdf:ID="FunctionalProperty">
<rdfs:label>FunctionalProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdfs:Class rdf:ID="InverseFunctionalProperty">
<rdfs:label>InverseFunctionalProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdfs:Class rdf:ID="AnnotationProperty">
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdf:Description rdf:about="&rdfs;label">
<rdf:type rdf:resource="#AnnotationProperty"/>
</rdf:Description>
<rdf:Description rdf:about="&rdfs;comment">
<rdf:type rdf:resource="#AnnotationProperty"/>
</rdf:Description>
<rdf:Description rdf:about="&rdfs;seeAlso">
<rdf:type rdf:resource="#AnnotationProperty"/>
</rdf:Description>
<rdf:Description rdf:about="&rdfs;isDefinedBy">
<rdf:type rdf:resource="#AnnotationProperty"/>
</rdf:Description>
<rdfs:Class rdf:ID="Ontology">
<rdfs:label>Ontology</rdfs:label>
</rdfs:Class>
<rdf:Property rdf:ID="imports">
<rdfs:label>imports</rdfs:label>
<rdfs:domain rdf:resource="#Ontology"/>
<rdfs:range rdf:resource="#Ontology"/>
</rdf:Property>
<rdf:Property rdf:ID="versionInfo">
<rdfs:label>versionInfo</rdfs:label>
<rdf:type rdf:resource="#AnnotationProperty"/>
</rdf:Property>
<rdf:Property rdf:ID="priorVersion">
<rdfs:label>priorVersion</rdfs:label>
<rdfs:domain rdf:resource="#Ontology"/>
<rdfs:range rdf:resource="#Ontology"/>
</rdf:Property>
<rdf:Property rdf:ID="backwardCompatibleWith">
<rdfs:label>backwardCompatibleWith</rdfs:label>
<rdfs:domain rdf:resource="#Ontology"/>
<rdfs:range rdf:resource="#Ontology"/>
</rdf:Property>
<rdf:Property rdf:ID="incompatibleWith">
<rdfs:label>incompatibleWith</rdfs:label>
<rdfs:domain rdf:resource="#Ontology"/>
<rdfs:range rdf:resource="#Ontology"/>
</rdf:Property>
<rdfs:Class rdf:ID="DeprecatedClass">
<rdfs:label>DeprecatedClass</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdfs;Class"/>
</rdfs:Class>
<rdfs:Class rdf:ID="DeprecatedProperty">
<rdfs:label>DeprecatedProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
<rdfs:Class rdf:ID="DataRange">
<rdfs:label>DataRange</rdfs:label>
</rdfs:Class>
</rdf:RDF>
Appendix C.
OWL Quick Reference
Classes defined by OWL:
Properties defined by OWL:
Appendix D.
Changes from DAML+OIL
This section summarizes the changes from
DAML+OIL
[DAML+OIL]
to OWL.
- The semantics have changed significantly. With respect to the three
sublanguages, the DAML+OWL semantics is closests to the OWL DL semantics.
- The namespace was changed to
http://www.w3.org/2002/07/owl.
- Various updates to RDF and RDF Schema from the
RDF Core Working Group
were incorporated,
including
- Qualified restrictions were removed from the language,
resulting in the removal of the following properties:
daml:cardinalityQdaml:hasClassQdaml:maxCardinalityQdaml:minCardinalityQ
- Various properties and classes were renamed,
as shown in the following table:
-
owl:SymmetricProperty
was added.
- An
owl:DatatypeProperty
may be an
owl:InverseFunctionalProperty
in OWL Full.
-
Synonyms for RDF and RDF Schema classes and properties were removed from the language,
resulting in the removal of:
daml:commentdaml:domaindaml:labeldaml:isDefinedBydaml:Literaldaml:Propertydaml:rangedaml:seeAlsodaml:subClassOfdaml:subPropertyOfdaml:typedaml:value
-
daml:disjointUnionOf
was removed from the language,
since it can be effected using
owl:unionOf
or
rdfs:subClassOf
and
owl:disjointWith.
-
daml:equivalentTo
was renamed to
owl:sameAs,
and is no longer a superproperty of
owl:equivalentClass,
owl:equivalentProperty,
and
owl:sameIndividualAs
-
The following properties and classes were added to support versioning:
- owl:AllDifferent
and
owl:distinctMembers
were added to address the
Unique Names Assumption.
- [DAML+OIL]
-
DAML+OIL (March 2001) Reference Description.
Dan Connolly, Frank van Harmelen, Ian Horrocks,
Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein.
W3C Note 18 December 2001.
Latest version
is available at
http://www.w3.org/TR/daml+oil-reference.
- [Hendler et al,, 2002]
-
Hendler, James, Berners-Lee, Tim and Miller, Eric "Integrating
Applications on the Semantic Web," Journal of the Institute of
Electrical Engineers of Japan, Vol 122(10), October, 2002, p.
676-680. available in English at
http://www.w3.org/2002/07/swint
- [OWL S&AS]
-
Web Ontology
Language (OWL) Semantics and Abstract Syntax.
Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, eds.
W3C Working Draft 3 February 2003.
Latest version is available at
http://www.w3.org/TR/owl-semantics/.
- [OWL Overview]
-
Web Ontology Language (OWL Lite and OWL) Feature Synopsis Version 1.0.
Deborah L. McGuinness and Frank van Harmelen, eds.
W3C Working Draft 29 Jul 2002.
Latest version is available at
http://www.w3.org/TR/owl-features/.
- [OWL Guide]
-
Web Ontology Language (OWL) Guide Version 1.0.
Michael K. Smith, Christopher Welty, Raphael Volz, and Deborah McGuinness.
W3C Working Draft 4 November 2002.
Latest version is available at
http://www.w3.org/TR/owl-guide/.
- [OWL Use Cases and Requirements]
-
Web Ontology Language (OWL) Use Cases and Requirements.
Jeff Heflin, ed.
W3C Working Draft 3 February 2003.
Latest version is available at
http://www.w3.org/TR/webont-req/.
- [OWL Test Cases]
-
Web Ontology Language (OWL) Test Cases.
Jeremy J. Carroll and Jos De Roo, eds.
W3C Working Draft 24 October 2002.
Latest version is available at
http://www.w3.org/TR/owl-test/.
- [RDF Concepts]
-
Resource Description Framework (RDF): Concepts and Abstract Syntax.
Graham Klyne and Jeremy J. Carroll, eds.
W3C Working Draft 23 January 2003.
Latest version
is available at
http://www.w3.org/TR/rdf-concepts/.
- [RDF Schema]
-
RDF Vocabulary Description Language 1.0: RDF Schema.
Dan Brickley and R.V. Guha, eds.
W3C Working Draft 23 January 2003.
Latest version
is available at
http://www.w3.org/TR/rdf-schema/.
- [RDF Semantics]
-
RDF Semantics.
Patrick Hayes, ed.
W3C Working Draft 23 January 2003.
Latest version
is available at
http://www.w3.org/TR/rdf-mt/.
- [RDF/XML Syntax]
-
RDF/XML Syntax Specification (Revised).
Dave Beckett, ed.
W3C Working Draft 23 January 2003.
Latest version
is available at
http://www.w3.org/TR/rdf-syntax-grammar/.
- [XML-SCHEMA2]
- XML Schema
Part 2: Datatypes - W3C Recommendation, World Wide Web
Consortium, 2 May 2001.