The Web Ontology Language OWL is a semantic markup language for publishing
and sharing ontologies on the World Wide Web. OWL is 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.
This is a W3C Working Draft for review by W3C members and other
interested parties. It is a draft document and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference materials or
to cite them as other than "work in progress." A list of current
W3C Recommendations and other technical documents can be found at
http://www.w3.org/TR/.
This Working Draft corresponds to the OWL Web Ontology
Language 1.0 specification, which is
being developed by the W3C Web Ontology Working Group.
This document has been produced as part of the W3C Semantic Web Activity (Activity Statement)
following the procedures set out for the
W3C
Process. The goals of the Web Ontology working group are
discussed in the
Web Ontology
Working Group charter.
There are no patent disclosures related to this work at the
time of this writing.
Comments on this document should be sent to public-webont-comments@w3.org,
a mailing list with a public
archive. General discussion of related technology is welcome in www-rdf-logic.
Parts of this document are derived from the DAML+OIL (March 2001) Reference
Description [DAML+OIL] which was
subsequently submitted as a
DAML+OIL W3C Note
. The authors othis document were
Dan Connolly, Frank van Harmelen, Jim Hendler, Ian Horrocks,
Deborah McGuinness, Peter Patel-Schneider, and Lynn Andrea Stein.
The sponsors of this document ans its
predecessor documents are also gratefully acknowledged.
Jeremy Carrol, Peter Patel-Schneider, and Jim Hendler perovided
substantive reviews and contributed text to this document.This document is the
result of extensive discussions within the Web Ontology Working Group as a
whole. The members of this working group were .... (@@ include member list)
1. Introductory remarks
1.1 Purpose of this document
This document gives a systematic, compact and informal 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 of example uses of
the language.
The normative reference on the precise syntax of the language
constructs can be found in the machine-readable RDF Schema definition
of OWL (included as Appendix B) and in the OWL
Abstract Syntax and Semantics document [OWL AS&S]. The latter
document also contains a precise definition of the meaning of the
language constructs in the form of a model-theoretic semantics.
1.2 OWL Full/DL/Lite
As also discussed in the OWL Overview and OWL Guide documents, we
distinguish between OWL Full, OWL DL and OWL Lite. In particular,
the OWL language provides two specific subsets that we believe will
be of great 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
Description Logic (OWL DL) 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 but 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 language constructs.
Their difference lies in restrictions on the use of some of those
features. OWL Full allows free mixing of OWL with RDF Schema and,
like RDF Schema, does not enforce a strict separation of classes,
properties, and individuals. OWL DL puts constraints on the mixing
with RDF and requires disjointness of classes, properties and
individuals. 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 Abstract Syntax and
Semantics document
[OWL AS&S].
Section "8. OWL Lite/DL/Full constructs"
summarizes the
differences between OWL Full and OWL DL.
OWL Lite is a sublanguage of OWL 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 was
designed to extend the modeling capabilities of RDFS
by adding some common features used in extending vocabularies
and thesauri into ontologies.
OWL Lite also abides to 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 Abstract Syntax
and Semantics document
[OWL AS&S].
1.3 OWL Syntax
The exchange syntax for OWL is the XML serialization of RDF (RDF/XML).
The RDF/XML syntax is
defined in the RDF/XML Syntax Specification (Revised)
[RDF/XML Syntax].
An OWL ontology is thus in fact a set of RDF triples.
As with any set of RDF triples, OWL triples can be
represented 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 these triples.
However, the meaning of an OWL ontology is solely determined by the resulting
set of triples. Thus, it is allowed to use syntactic RDF
forms other, 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 set of RDF triples, consider
the following syntactic form:
<owl:Class rdf:ID="Continent"/>
The following RDF statement:
<rdf:Description rdf:about="#Continent">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description>
results in exactly the same set of RDF triples, and is therefore
perfectly allowed as a class description.
1.4 OWL and RDF semantics
OWL is a vocabulary extension of RDF. Thus any RDF graph forms an OWL
ontology. Further, the meaning given to an RDF graph by OWL includes the
meaning given to the graph by RDF. OWL ontologies can thus include arbitrary
RDF content, which is treated in a manner consistent with its treatment by RDF.
As stated above, OWL assigns an additional meaning to certain RDF triples. The
OWL Abstract Syntax and Semantics [OWL
AS&S] specifies exactly which triples are assigned a
specific meaning, and what this meaning is.
2. Language structure
An OWL ontology is generally written as a sequence of composite
components involving particular OWL language constructs.
Appendix
A provides a listing of all of these language constructs. Throughout this
document, OWL constructs will be presented in a structured RDF/XML format, and
not as bare RDF triples. This structured RDF/XML format is more natural to
read, but, as said before, any way of generating the same RDF triples as
generated by the structured RDF format is equivalent.
Several language constructs employ the
rdf:parseType="Collection"
vocabulary (an addition in the revised RDF syntax specification)
to describe collections of similar things, which
would otherwise be difficult to represent in a triple format.
An OWL ontology consists of an optional
ontology header and any number of
class axioms, property axioms,
and individual axioms.
Please note that "axiom" is the formal term used in the AS&S
document. These axioms are somewhat more informally called
"definitions" in the Guide and Overview documents.
As with all RDF documents, the OWL code should be inside an
<rdf:RDF> tag. The document can contain the usual XML entity and
namespace declarations. For a typical XML header, see the
wine.owl,
containing the example ontology
discussed in the Guide document.
Links in the text attached to definitions of
language constructs provide access to the
OWL Abstract Syntax and Semantics
[OWL AS&S].
Appendix A contains a
systematic set of links for each language construct to the
corresponding section in the Guide and the AS&S document.
Appendix C gives an overview of all
OWL language constructs in
terms of the built-in OWL classes and properties as defined in the
owl.owl file (see Appendix B)
A ontology header component is
represented with an instance of the class
owl:Ontology, which
identifies the containing document 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>$Id: owl-ref-proposed.html,v 1.151 2003/01/22 06:17:53 mdean Exp $
</owl:versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<owl:imports rdf:resource="http://www.w3.org/2002/07/owl"/>
</owl:Ontology>
The rdf:about="" refers to the current document.
The following sections describe the various types of statements that can be
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.
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 namespaces only provide a mechanism for
creating unique names, and do not actually include definitions in the
way that owl:imports does. Similarly,
owl:imports statements do not set up a shorthand notation
for names. Therefore, it is common to have corresponding
namespace definitions
and owl:imports statements.
If an OWL Lite ontology imports an OWL DL or OWL Full ontology, it
effectively becomes an OWL DL or OWL Full ontology. Similarly, an
OWL DL ontology that imports a OWL Full ontology becomes an OWL Full ontology.
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.
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.
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.
Like owl:priorVersion, this has no meaning in the model
theoretic semantics other than that given by the RDF(S) model theory.
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 classes are viewed as sets of individuals, These individuals are the
instances of the class. 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). OWL
Full allows the freedom of RDF Schema: a class may act as an instance of
another (meta)class (the same holds for properties).
For understanding the OWL class constructs, the notion of a class as a set
of members (individuals) is crucial. Almost all OWL
definitions are expressed in
terms of this set notion. Subclass relations imply subset relations.
The meaning of the language constructs
depends heavily on these notions.
OWL's view of
classes as sets and subclasses as subsets
can be traced back to its origins in description logic.
People familiar with data modelling but unfamiliar with description logic
may initially have a hard time understanding the basic modelling approach.
As a guideline, keep the following example in mind. Imagine you want to state
that graduate courses must have a faculty member as a tutor. In the
description logic way of thinking you express this as follows:
"a GraduateCourse is a
subclass of the class of things
that have the class FacultyMember as value type
for the CourseTutor relation". It means exactly the same thing, it's just a
different way of saying it.
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
Abstract Syntax and Semantics) for the basic building blocks of class axioms
(informally called class definitions in the Overview and Guide documents).
OWL class descriptions can take six forms:
- a class name (indicated with 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 form defines c.q. refers to a class name.
The other five forms of class descriptions implicitly define an
anonymous class, respectively
the class that contains exactly the enumerated
individuals (2nd form),
the class of all instances which satisfy the
property restriction (3rd form),
or the class that satisfies boolean combinations of
such descriptions (4th, 5th and 6th form).
Intersection, union and complement can be respectively seen as
the logical AND, OR and NOT operator.
These three forms 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.
Each of the different forms is discussed
in more detail below.
Two OWL class names are predefined, namely the classes owl:Thing
and owl:Nothing.
Every individual is an instance of owl:Thing, and no individual is
an instance of owl:Nothing. Consequently, every class is a
subclass of owl:Thing and owl:Nothing is a subclass
of every class.
A class description of the
"enumeration" type is defined with the
owl:oneOf
statement, which contains a collection of individuals
that are the instances of the class.
This enables us to define a class by exhaustively enumerating its instances.
The class defined by the
owl:oneOf
element contains exactly the enumerated
elements, no more, no less. The collection is typically
represented with the help of the RDF construct
rdf:parseType="Collection", which provides a convenient shorthand for
writing down a set of elements.
For example, the following owl:oneOf
statement defines the 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>
A statement of the form <owl:Thing rdf:about="..."/>
refers to some individual (all individuals are by definition instances of
owl:Thing).
Note that we have not given a name to this class. Class descriptions
should be seen as the building blocks for class definitions (formally denoted
as "class axioms"). In the section "Class axioms" we
discuss how we can combine class descriptions in class axioms .
@@ Make a note here about OWL Full/DL differences here??
In the section on properties we will see another use of
the owl:oneOf construct, namely to define an enumeration of data values.
A property restriction is a special kind of class
description. It implicitly defines an anonymous class, namely the class of
all individuals that satisfy the restriction.
There are two kinds of restrictions: value restrictions and cardinality
restrictions.
A value restriction puts constraints on the
value range of the property when applied to this particular class
description. For example, we might want to say that for the class
Region the value of the property adjacentTo should
also be a Region. Note the difference with the RDF Schema
construct rdfs:range, which applies to all situations in which the
property is used.
A cardinality
restriction 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 format:
<owl:Restriction>
<owl:onProperty rdf:resource="(some property)" />
(one or more value and/or cardinality restrictions, see below)
</owl:Restriction>
@@ Note that only one value/cardinality restriction is allowed in a given
Restriction.?!
owl:Restriction
is defined as a subclass of owl:Class. A restriction is thus a
special type of OWL class. A restriction class contains a statement linking the
restriction to a particular property, using the owl:onProperty
construct. The restriction class also contains
a statements that can be used to specify value
and/or cardinality restrictions on the property, 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.
An owl:allValuesFrom
restriction contains either a class description
or a data range and defines the class of all
individuals for which the range values of the property under consideration
all belong to this class
description resp. the data range.
In other words, it defines the class of individuals x
for which it 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 the anonymous OWL class (set of individuals) for which
it holds that the "hasParent" property has only 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.
Notice that an owl:allValuesFrom
restriction is analogous to the universal (for-all) quantifier of Predicate
logic - for each instance of the class or datatype that is being defined, every
value for P must fulfill the restriction. Also notice that the correspondence
of owl:allValuesFrom with the
universal quantifier means that an owl:allValuesFrom restriction 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 restriction demands that
all values of P belong to class P, and if no such values exist, the restriction
is trivially true.
The value restriction owl:someValuesFrom
contains a class description or a data range. An owl:someValuesFrom statement defines
the 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 the 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 the class of individuals who 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
restriction is analogous to the existential quantifier of Predicate logic - for
each instance of the class or datatype that is being defined, there exists at
least one value for P that fulfills the restriction.
An owl:hasValue
restriction contains a reference to an
individual or a datatype value.
An owl:hasValue element defines the class of all objects for
whom the property concerned has at least one value equal to the
referenced individual or datatype value (but it may have
other values as well).
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>
The default cardinality of properties is "any". OWL provides three constructs
for cardinality restrictions on properties.
An owl:maxCardinality
restriction defines the class of all individuals that have at
least N distinct individuals (or data values) for the property
concerned, where N is the number specified between the begin and end
owl:cardinality tag.
The following example describes the class of individuals that have at most
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:maxCardinality>2</owl:maxCardinality>
</owl:Restriction>
An owl:minCardinality
restriction defines the class of individuals that have at
most N distinct individuals / data values for the property
concerned, where N is the number specified between the begin and end
owl:cardinality tag.
The following example describes the class of individuals that have at least
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:minCardinality>2</owl:minCardinality>
</owl:Restriction>
An owl:cardinality
restriction defines the class of all individuals that have
exactly N distinct individuals (or data values) for the
property concerned, where N is the number specified between the begin and end
owl:cardinality tag. This construct is in fact redundant as it
can always be replaced by a pair of matching
owl:minCardinality
and
owl:maxCardinality
restrictions with the same value. It is included as a convenient shorthand for
the user.
The following example describes the class of individuals that have exactly
two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:cardinality>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. As OWL views
classes as sets of individuals, these operators get the standard set-operator
names: intersection, union and complement. These language constructs share the
characteristic that they contain one (complement) or more (union, intersection)
nested class descriptions.
A class description of the form owl:intersectionOf
contains a list of nested
class descriptions.
An intersection
describes an anonymous class that consists of exactly those individuals
that are common to
all class descriptions in the 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>
The sample intersection contains two enumerations, both describing a class
with two individuals. The intersection is
the class with the individual common to both enumerations, namely
"Tosca".
owl:intersectionOf
can be viewed as being analogous to logical
conjunction.
A owl:unionOf
class contains a list of class descriptions..
This describes the (anonymous) class that consists exactly of those individuals
that belong to at least one of the class descriptions from the 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 the class with the
three individuals "Tosca", "Salome", and "Turandot" (sets do not contain
duplicates).
owl:unionOf is analogous to logical disjunction.
A class description of the form
owl:complementOf
contains precisely one nested class
description..
The owl:complementOf construct defines the class that
consists of exactly those individuals
that do not belong to the class description. owl:complementOf is
analogous to logical negation, but restricted to individuals only.
Note that arbitrarily complex combinations of these descriptions can be
formed. As an example of a combination of the set operators,
the expression "neither meat nor fish" could be written
as:
<owl:Class>
<owl:complementOf>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Meat"/>
<owl:Class rdf:about="#Fish"/>
</owl:unionOf>
</owl:Class>
</owl:complementOf>
</owl:Class>
@@ Reconsider example, Peter said it was incorrect
Class descriptions form the building blocks for defining classes
through class axioms. The simplest form of a class axiom just states
the existence of a class, using
owl:Class.
For example, the following piece of OWL
creates the URI reference "Human" and
states that it is an OWL class name.
<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 such definitions:
subClassOf allows one
to say that a class description is a subclass of another class
description.sameClassAs allows one
to say that a class description is equivalent to another class
description.disjointWith allows one
to say that a class description is disjoint with another class (i.e.
description).
We discuss these three language constructs in more detail in the
following subsections.
Many typical class axioms in OWL are of the form:
"some class name" rdfs:subClassOf "some class description".
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.
Class axioms can also use the other types of class descriptions, such as
property restrictions, enumerations, intersections, unions and complements.
The common format is: "some class name" rdfs:subClassOf "some class
description". 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>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
This class axiom uses a property restriction. The example says that "Opera"
is a subclass of an anonymous OWL class (remember: owl:Restriction
is a subclass of owl:Class) that describes the class of
individuals for which the property "hasLibrettist" has at least one value. In
short, operas should have at least one librettist.
Note also the use of rdf:about instead of rdf:ID,
which was used in the first example. Informally one could say that
rdf:ID creates a URI reference for a resource, and that
rdf:about refers to a URI reference. Therefore, it is common that
the first axiom about a particular class uses the rdf:ID construct, and that
subsequent axioms use the rdf:about construct.
A final point about the previous two examples is that multiple subclass
axioms for the same class define in fact an intersection: the class at the
lefthand side should be a subclass of both class descriptions. Thus, the
following two class axioms are semantically equivalent (the latter is however
not part of OWL Lite):
<owl:Class rdf:ID="Opera">
<rdfs:subClassOf rdf:resource="#MusicalWork" />
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist" />
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Opera">
<rdfs:subClassOf>
<owl:Class>
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MusicalWork"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasLibrettist" />
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
</rdfs:subClassOf>
</owl:Class>
The use of intersection (and union and complement) leads to nested class
descriptions. Another form of nested class descriptions can occur when defining
property restrictions with the
owl:allValuesFrom
or
owl:someValuesFrom
constructs, because these point to a class
description. An 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
the class of operas that have as an "opera type" either "opera seria" or
"opera buffa" (without a further cardinality restriction, it could actually
also have both values).
More examples can be found in the Guide document and in the corresponding
wine.owl file.
Subclass axioms provide as 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:sameClassAs
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>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 operettas are exactly
those musical works that have a librettist and are not operas, we need to use
the
owl:sameClassAs
construct.
A class axiom may contain (multiple)
owl:sameClassAs
statements. The typical format of such a class axiom is:
"some class name" owl:sameClassAs "some class description".
The meaning of such an class axiom is that both classes have the same extension
(i,e, they have exactly the same set of individuals).
In its simplest form, a same-class axiom states the equivalence of two named
classes. This is typically used in ontology mapping to indicate that a class in
one ontology is actually the same as a class in another ontology. (@@ make note
about difference with sameAs). An example:
<owl:Class rdf:about="#FootballTeam">
<owl:sameClassAs rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>
One could imagine this class axiom to be part of a European sports
ontology, in which we want to say that the class "SoccerTeam" in another
ontology is actually the same class.
owl:sameClassAs is also used to define enumerated classes: a class
for which we can enumerate all individuals. An example:
<owl:Class rdf:ID="DaPonteOperaOfMozart">
<owl:sameClassAs>
<owl:Class>
<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>
</owl:sameClassAs>
</owl:Class>
This class axiom defines the class of individuals
representing the Da Ponte operas of Mozart (a
popular subject in musicology). By using the same-class 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.
It is possible to have multiple same-class axioms about the same class name.
However, this requires great care. Both axioms must led to the same
outcome. ie. exactly the same set of individuals. For example, an alternate
same-class axiom for the Da Ponte operas could be the following one:
<owl:Class rdf:about="#DaPonteOperaOfMozart">
<owl:sameClassAs>
<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:sameClassAs>
</owl:Class>
So, this class corresponds to exactly 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 that if we also had a class axiom such as:
<owl:Class rdf:about="#DaPonteOperaOfMozart">
<rdfs:subClassOf rdf:resource="#Opera"/>
</owl:Class>
we would have to make sure that all instances of the class as defined
earlier are indeed operas (the class name suggests this is true, but that has
no semantic meaning).
OWL allows users to define class axioms with an implicit same-class
statement. For example, the first class axiom could also have been written down
as:
<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 read as the class "DaPonteOperaOfMozart" is
exactly defined by the enumeration. It is semantically equivalent to the
version with the owl:sameClassAs statement, but this shorthand may
be more intuitive for some users. Another example of this form 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 of living beings exactly corresponds
to the union of plants and animals.
@@ Guideline about explicit vs. implicit form??
Note: RDFS and OWL allow cycles of subclass relationships as a
means to assert equality between classes. Thus, if we state that A is a
subclass of B and vice versa, then A is the same class as B.
A class axiom may also contain (multiple)
owl:disjointWith
statements. The typical format of such axioms is similar to
the previous ones, namely:
Each owl:disjointWith statement asserts the two class description
involved have no class instances in common. Like axioms with
rdfs:subClassOf, declaring two classes to be disjoint is a partial
definition: they impose necessary but not sufficient conditions on the
class. This is a popular example:
<owl:Class rdf:about="Man">
<owl:disjointWith rdf:resource="#Woman"/>
</owl:Class>
although whether this is always 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:sameClassAs>
<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:sameClassAs>
</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>
owl:disjointWith
can be used together with
owl:unionOf
to define a set of mutually disjoint and complete subclasses of a
superclass.
OWL distinguishes between two types of properties:
- object properties have a value range of
class individuals, and thus link individuals to individuals
("individual-valued property" would probably have been a bit
better term).
- 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
construct. A datatype property is defined through an owl:DatatypeProperty
construct. Both owl:ObjectProperty and
owl:DatatypeProperty are subclasses of the RDF class
rdf:Property (see Appendix B).
[Advanced 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 practice, this
has only consequences for the use of
owl:InverseFunctionalProperty.
See also the OWL Full characterization in Section 8.1.]
A property axiom is typically contained within an
owl:ObjectProperty c.q. owl:DatatypeProperty
component. The axiom usually defines/references a property name, and may
include the following additional components (any number, any order):
- RDF Schema constructs:
rdfs:subPropertyOf,
rdfs:domain and rdfs:range
- relations to other properties:
owl:samePropertyAs and
owl:inverseOf
- global cardinality constraints:
owl:FunctionalProperty and
owl:InverseFunctionalProperty
- logical property characteristics:
owl:SymmetricProperty and
owl:TransitiveProperty
In the next subsections, these property-related language constructs are
discussed in more detail.
A rdfs:subPropertyOf statement defines that the property
is a subproperty of some other property.
Formally this means that every pair (x,y) that is an instance
of the subproperty is also an instance of the superproperty.
An example:
<owl:ObjectProperty rdf:ID="hasMother">
<rdfs:subPropertyOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>
This says that all instances (pairs) of the property "hasMother" are also
instances of the property "hasParent".
For a property one can define (multiple)
rdfs:domain statements.
Each domain statement points to a class
description. The meaning is the same as in RDF Schema:
an rdfs:domain statement asserts that the domain of the property
consists of those individuals that are instances of the class description.
Multiple rdfs;domain
statements 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>
<owlClass>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Corporation"/>
</owl:unionOf>
</owlClass>
</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:range statements should be used with
care.
An rdfs:range statement points to a class description or to a data range. Each rdfs:range statement
asserts that the property only takes range values that are instances of the
class description c.q. data values belonging to the data range. Multiple range
restrictions are interpreted as stating that the range of the property is the
intersection of all ranges (i.e.,
intersection of the class descriptions
c.q. intersection of the data ranges). Similar to
rdfs:domain,
multiple disjoint 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
restrictions mentioned earlier, rdfs:range restrictions are
global. The property restrictions constitute 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. This is by virtue of their semantics in RDF
Schema. Thus, rdfs:range should be
used with care.
An owl:samePropertyAs
statement points to another property. A statement of the form P1
owl:samePropertyAs P2 asserts that P1 is equivalent to P2, i.e. P1 and
P2 have exactly the same instances (pairs). This is typically used in ontology
mapping to indicate that two properties with different names refer to the same
notion.
An owl:inverseOf
statement points to another property that is its inverse. A statement of the
form P1 owl:inverseOf P2 asserts that P1 is the inverse relation
of P2. For example, the property "owns" could be defined as the inverse of
"ownedBy". More formally: if P1 is the inverse of P2, then for every pair
(x,y) which is an instance of P1, there is also a pair (y,x) which is an
instance of P2.
The owl:inverseOf construct only makes sense when applied to
object properties, as both the domain and the range of the property must be
classes.
OWL defines the class owl:FunctionalProperty
as a special subclass of the RDF class
rdf:Property. This asserts that the
property can only have 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. This corresponds to the notion of
"optional" value encountered in many data-modelling notations.
There are two typical syntactic variations for writing down functional
properties:
<owl:FunctionalProperty rdf:ID="husband">
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
</owl:FunctionalProperty>
<owl:ObjectProperty rdf:ID="husband">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
</owl:ObjectProperty>
The only difference between the two examples is that the second property
axiom gives rise to one additional triple, namely that the property "husband"
is an object property. As always, there are many other syntactic
variations. For example, the second example above
is semantically equal 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" />
The construct
owl:InverseFunctionalProperty
is, as a subclass of the
OWL class owl:ObjectProperty. For an inverse-functional property,
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.
[Advanced 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 the 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="hasSocialSecurityNumber">
<rdfs:domain rdf:resource="Person"/>
</owl:InverseFunctionalProperty>
This example corresponds to our intuition that every social security number
should uniquely identify a human individual (whether that is really always true
is another matter). Inverse-functional properties resemble the notion of a key
in databases.
Notice that
owl:FunctionalProperty
and
owl:InverseFunctionalProperty
specify global cardinality restrictions. 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.
The OWL property class
owl:TransitiveProperty
is a subclass of owl:ObjectProperty.
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.
Properties representing certain part-whole relations are
frequently encountered examples of transitive
behavior. 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 "Chianti
Classico", "Tuscany" and "Italy" are regions, and "Chianti Classico" is a
subregion of "Tuscany", and "Tuscany" is a subregion of "Italy", then "Chianti
Classico" 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 also the difference with
functional and inverse-functional
properties, which can be both object and datatype properties.
The OWL property class
owl:SymmetricProperty
is, like
owl:TransitiveProperty,
a subclass of owl:ObjectProperty.
A symmetric property is a property for which it holds that
if the pair (x,y) is an instance
of P, then the pair (y,x) is also
an instance of P.
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
(although we might want to extend the definition in the example to include also
(other) animals).
@@ Is this a hard constraint in OWL??
@@ still needs to be updated.
7. Datatypes
OWL also allows the use of XML Schema datatypes to describe
(or define) part of the datatype domain.
@@ update this with link to relevant RDF document plus example. Also include
link to the table of datatypes in the Guide (or duplicate this table?).
In the introduction we briefly discussed the three sublanguages of OWL. In this
section a informal specification is given of each of the three "species" of
OWL. A formal account of the differences is given in the
Abstract Syntax and Semantics document [OWL AS&S].
If an OWL Lite ontology imports an OWL DL or OWL Full ontology, it
effectively becomes an OWL DL resp. OWL Full ontology. In a similar vein, an
OWL DL ontology that imports a OWL Full ontology becomes an OWL Full ontology.
OWL Full is not actually a sublanguage. OWL Full contains all the OWL
language constructs and provides free, unconstrained mixing of OWL and RDF. The
construct <owl:Class> is equivalent to
<rdfs:Class>. This is different from OWL DL
and OWL Lite, where <owl:Class> is a subclass of
<rdfs:Class> (meaning that not all RDF classes are OWL
classes). 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 be also part of the individual
domain. This means that object properties and datatype properties are not
disjoint. In OWL Full owl:ObjectProperty is the same class as
rdf:Property. The consequence is
that datatype properties are effectively
a subclass of object properties (note that the definitions in
owl.owl
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 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.
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, individuals, and built-in
vocabulary. Thus, 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 restrictions should be placed on
transitive properties or their superproperties.
- In OWL DL all descriptions must be well-formed, with no missing or extra
components, and must form tree-like structures.
The last constraint implies that all classes and properties that one refers
to are explicitly defined 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 should also contain a class axiom for "C2".
@@ Should C2 be an owl:Class to be in OWL DL?
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 restriction 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 to all the restrictions OWL DL puts on the use of the OWL
language constructs. In addition, OWL Lite puts the following restrictions on
the use of the OWL vocabulary:
- Restrictions with respect to an ontology header: none.
- Restrictions with respect to class axioms:
- Class descriptions are only allowed to be
either class names or property restrictions. Thus, an enumeration or a set
operation (intersection, union, complement) is not allowed in OWL Lite.
- Class axioms can only contain rdfs:subClassOf
or a owl:sameClassAs. Thus, the use of
the owl:disjointWith statement is not allowed
in OWL Lite.
- The lefthand-side of a class axiom should always be a class name.
- In value restrictions, only owl:allValuesFrom and owl:someValuesFrom may be used. The hasValue construct is outside the scope of OWL
Lite.
- In cardinality restrictions only the values "0" and "1" can be used to
define the minimum, maximum or exact cardinality. Remember that the default
cardinality is "any".
- The class
Nothing is not part of
OWL Lite; the class Thing is.
- Restrictions on property axioms:
- The limitation of class descriptions (see above) to class names and
property restrictions also applies to domain and range statements for object
properties.
- The range of a datatype property is not allowed to be an enumeration of data values. Only the name of a
datatype is allowed.
- Restrictions on individual axioms ("facts"): none
The idea behind the OWL Lite restrictions 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, plus some mapping constructs (in particular sameClassAs).
In addition, OWL Lite allows
properties to be made optional or required (using the cardinality
features).
OWL Lite is constrained to be a subset of OWL DL, thus assuring it
retains the desirable reasoning features of that sublanguage. In
addition, 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 databases, markup tools, or
other non-reasoning tools. The Web Ontology Working Group has not
designed a specific such subset or provided a name for it.
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.
Once again, 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:sameClassAs rdf:resource="#Car"/>
<!-- note that sameClass 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>
Appendix B.
http://www.w3.org/2002/07/owl
<?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>
$Id: owl.owl,v 1.23 2003/01/17 00:08:11 mdean Exp $
</versionInfo>
<imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/>
<dc:title>OWL Web Ontology Language</dc:title>
<dc:creator>W3C Web Ontology (WebOnt) Working Group</dc:creator>
<dc:subject>OWL; Web Ontology Language; Semantic Web</dc:subject>
<dc:description>Classes and properties for the OWL Web Ontology
Language
</dc:description>
<dc:publisher>W3C</dc:publisher>
<dc:date>2003-01-15</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="sameClassAs">
<rdfs:label>sameClassAs</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="samePropertyAs">
<rdfs:label>samePropertyAs</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"/>
</rdf:Property>
<rdf:Property rdf:ID="sameAs">
<rdfs:label>sameAs</rdfs:label>
<samePropertyAs 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="someValuesFrom">
<rdfs:label>someValuesFrom</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="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="#ObjectProperty"/>
</rdfs:Class>
<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"/>
</rdf:Property>
<rdf:Property rdf:ID="versionInfo">
<rdfs:label>versionInfo</rdfs:label>
</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:subPropertyOf rdf:resource="#priorVersion"/>
</rdf:Property>
<rdf:Property rdf:ID="incompatibleWith">
<rdfs:label>incompatibleWith</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#priorVersion" />
</rdf:Property>
<rdfs:Class rdf:ID="DeprecatedClass">
<rdfs:label>DeprecatedClass</rdfs:label>
<rdfs:subClassOf rdf:resource="#Class"/>
</rdfs:Class>
<rdfs:Class rdf:ID="DeprecatedProperty">
<rdfs:label>DeprecatedProperty</rdfs:label>
<rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>
</rdf:RDF>
Appendix C.
OWL Quick Reference
Classes defined by OWL:
Properties defined by OWL:
Appendix D.
Changes from DAML+OIL
@@To be updated (GS)
This section summarizes the changes from
DAML+OIL
[DAML+OIL]
to OWL.
- 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:sameClassAs,
owl:samePropertyAs,
and
owl:sameIndividualAs
-
The following properties and classes were added to support versioning:
- owl:AllDifferentFrom
and
owl:distinctMembers
were added to address the
Unique Names Assumption.
@@To be updated (GS)
- [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.
- [OWL Abstract Syntax]
-
Web Ontology Language (OWL) Abstract Syntax and Semantics.
Peter F. Patel-Schneider, Patrick Hayes, Ian Horrocks, and Frank van Harmelen.
W3C Working Draft 8 November 2002.
Latest version is available at
http://www.w3.org/TR/owl-semantics/.
Editor's draft is available at
http://www-db.research.bell-labs.com/user/pfps/owl/semantics/.
- [OWL Overview]
-
Web Ontology Language (OWL Lite and OWL) Feature Synopsis Version 1.0.
Deborah L. McGuinness and Frank van Harmelen.
W3C Working Draft 29 Jul 2002.
Latest version is available at
http://www.w3.org/TR/owl-features/.
Editor's draft is available at http://www.ksl.stanford.edu/people/dlm/webont/OWLFeatureSynopsis.htm.
- [OWL Guide]
-
Web Ontology Language (OWL) Guide Version 1.0.
Michael K. Smith, Raphael Volz, and Deborah McGuinness.
W3C Working Draft 4 November 2002.
Latest version is available at
http://www.w3.org/TR/owl-guide/.
- [OWL Issues]
-
Web Ontology Issue Status.
Michael K. Smith, ed.
18 December 2002.
Latest version is available at
http://www.w3.org/2001/sw/WebOnt/webont-issues.
- [OWL Requirements]
-
Requirements for a Web Ontology Language.
Jeff Heflin, Raphael Volz, and Jonathan Dale.
W3C Working Draft 8 July 2002.
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.
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 8 November 2002.
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 30 April 2002.
Latest version
is available at
http://www.w3.org/TR/rdf-schema/.
- [RDF Semantics]
-
RDF Semantics.
Patrick Hayes, ed.
W3C Working Draft 12 November 2002.
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 25 March 2002.
Latest version
is available at
http://www.w3.org/TR/rdf-syntax-grammar/.