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.
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 submitted as part of the DAML+OIL W3C Note. The
authors of this 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 and its predecessor documents are also
gratefully acknowledged.
Jeremy Carroll, Jim Hendler, Brian McBride and Peter Patel-Schneider
provided substantive reviews and contributed text to this document. 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 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 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 machine-readable RDF Schema 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, 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 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 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, 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
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 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 Abstract Syntax and
Semantics document [OWL
AS&S].
1.3 OWL syntax
An OWL ontology is represented as 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
representing triples. However, the meaning of an OWL ontology is solely
determined by the resulting set of triples. Thus, it is allowed 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
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.
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. 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.
1.5 Annotations
@@ Explain use of annotations such as rdfs:comment,
isDefinedBy. seeAlso, etc,
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 an illustration of the
use of OWL language constructs. They do not form one consistent ontology. For
such examples the reader is referred to the Guide document [OWL Guide].
2. Language
structure
An OWL document 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.
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 all RDF documents, the OWL code should be enclosed in a
<rdf:RDF> begin and end tag. The document can contain standard XML
entity and namespace declarations. For a typical XML header, see the wine.owl file, which
contains the example wine 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 sections in the Guide and the
AS&S 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).
@@ This file was always named "owl.owl". Does this mean that
Appendix B should be extended to represent a "real" OWL ontology of OWL,
using OWL constructs to define OWL constructs. For DAML+OIL the decision was
made (?!) to limit this specification to RDF Schema constructs to avoid
circular definitions (for example, using "onProperty" to define
"onProperty"). We could also provide both an RDF schema and an OWL ontology
of OWL.
For readers familiar with DAML+OIL, Appendix D lists
the changes between DAML+OIL and OWL.
Certain URI references are reserved for use by OWL and may not be used for
any purpose not sanctioned by the OWL specifications. Specifically, URI
references with the following leading substring are reserved for the OWL
vocabulary:
http://www.w3.org/2002/07/owl# (conventionally
associated with namespace prefix owl:)
Used with the RDF/XML serialization, these URI prefix strings correspond
to XML namespaces associated with the OWL vocabulary terms.
A 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>$Id: Overview.html,v 1.3 2018/10/09 13:18:27 denis 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 are
typically used within the header.
@@ domain/range constraints of the import and versioning
properties should be checked
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.
owl:backwardCompatibleWith is defined as a subproperty of owl:priorVersion, and thus has also
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:incompatibleWith is defined as a subproperty of owl:priorVersion, and thus has also
no meaning in the model theoretic semantics other than that given by the
RDF(S) model theory.
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.
@@ include example.@@ cite Martin and Odell,Ch. 2
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
Abstract Syntax and Semantics) 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 the property restriction (3rd type), or a class
that satisfies boolean combinations of such descriptions (4th, 5th and 6th
type). Intersection, union and complement can be respectively seen as the
logical AND, OR and NOT operators. These three 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 instance of
owl:Class, a subclass of rdfs:Class:
<owl:Class rdf:ID="Human"/>
This will assert the triple "Human rdf:type owl:Class .".
The other five forms of class descriptions are represented as anonymous
instances of owl:Class (a blank node with the rdf:type
owl:Class) and includes certain statements about properties of this
anonymous class.
NOTE: If one uses the syntactic form of class descriptions of
type 2-6, but with a class identifier, OWL treats this as a specific kind of
class axiom. See Section 4.2 for details.
NOTE: Class descriptions of type 1 can always be used as a
stand-alone class axiom (see Section 4.2). OWL DL allows the use of class
descriptions of type 2-6 only within particular types of class axioms (see
Sections 4.2 and 8.2). OWL
Full does not impose such a restriction: every class description is in itself
a valid OWL Full class axiom.
Class descriptions of type 2-6 are discussed in more detail in the
following subsections.
Two OWL class names 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 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" type is defined with the owl:oneOf
property, which points to a list of individuals that are the instances of the class. This enables us to define a
class 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
owl:oneOf statement 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>
A statement of the form <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.
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 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)" />
(a value or cardinality restriction, see below)
</owl:Restriction>
The class owl:Restriction
is defined as a subclass of owl:Class.
A restriction class should have exactly one statement linking the restriction
to a particular property, using the owl:onProperty
property. The restriction class should also have exactly one statement that
represents the value restriction c.q. cardinality restriction 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.
An owl:allValuesFrom
restriction is a property that links a restriction class to either a class description or a data
range. A restriction containing an owl:allValuesFrom
statement s 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.
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 range 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
is a property that links a restriction class to a class description or a data
range. A restriction containing an owl:someValuesFrom
statement 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
restriction 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 restriction.
An owl:hasValue
restriction is a 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 statement 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 restriction 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>
The default cardinality of properties is "any". 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 restrictions, but only when used with the range values "0" or
"1".
An owl:maxCardinality
property links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:maxCardinality statement 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 statement. Syntactically, the cardinality statement
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 "7. Datatypes".
An owl:minCardinality
property links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:minCardinality statement 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 statement. Syntactically, the cardinality statement
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>
An owl:cardinality
property links a restriction class to a data value belonging to the range of
the XML Schema datatype nonNegativeInteger. A restriction
containing an owl:cardinality statement 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 statement. Syntactically, the cardinality statement 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
restrictions 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 statement is a list of two
class description, 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 statements about equality and difference of
individuals.
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).
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 "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
Note that arbitrarily complex combinations of these set-operator class
descriptions can be formed.
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.
NOTE: In OWL Full every type of class description is also a
valid class axiom. OWL DL and OWL Lite impose restrictions on the ways in
which class descriptions of type 2-6 can be used to form class axioms.
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 such definitions:
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 the section Axioms for
complete classes without using owl:equivalentClass).
The property rfs:subClassOf 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: OWL DL only allows a class identifier to be the domain
value of an rdfs:subClassOf statement. OWL Lite has the
additional restriction that only class identifiers or property restrictions
are allowed as range values.
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.
@@ mention of the use of rdf:about versus
rdf:ID ??
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:
<owl:Class rdf:ID="Opera">
<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>
</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 rdf:datatype="&xsd;nonNegativeInteger">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 may point to a 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 restriction, 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 operettas are exactly
those musical works that have a librettist and are not operas, we would need
to use the owl:equivalentClass
construct.
A class axiom may contain (multiple) owl:equivalentClass
@@ statements. The property owl:equivalentClass links a class
description to another class description. The meaning of such a class axiom
is that the two classes 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.
owl:equivalentClass is also 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="DaPonteperaOfMozart">
<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 great 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 equal (and thus has the
same meaning as "A equivalentClass B"). Such subClassOf "cycles" are
explicitly allowed. As OWL should be usable in a distributed environment,
this may be a useful feature.
OWL allows users to define class axioms by giving a name to classes 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.
@@ Guideline about explicit vs. implicit form of complete
classes??
A class axiom may also contain (multiple) owl:disjointWith
statements. The construct owl:disjointWith is a property with a
class description as domain and range. Each owl:disjointWith
statement asserts that the class extensions of the two class description
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 DL does not put any constraints on the types of
class descriptions that can be used as domain and range values of an
owl:disjointWith statement. 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 ("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
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 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 properties. 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 defining such property
characteristics:
- 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, these property-related language constructs 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 statement 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 statements can be applied to both datatype properties and
object properties.
NOTE: In OWL DL the domain and range value of a subproperty
statement should be either both datatype properties or both object
properties.
For a property one can define (multiple) rdfs:domain
statements. Syntactically, rdfs:domain is a property that links
a property (some instance of the class rdf:Property) to a class description. An rdfs:domain
statement asserts that the domain values of this property must belong to the
class extension 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>
<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 statements should be used with care.
NOTE: In OWL Lite the range value of a
rdfs:domain statement may only contain class identifiers or
property restrictions.
For a property one can define (multiple) rdfs:range
statements. Syntactically, rdfs:range is a 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 statement
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
restrictions described in the section on class descriptions,
rdfs:range restrictions are global. Value restrictions 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 statement may only contain class identifiers or
property restrictions.
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 statements can only
be made in OWL Full.
An example of two equivalent properties:
@@ include example of equivalent properties
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. A
statement 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>
@@ make a note that in OWL Full it is allowed to apply
inverseOf to datatype properties (as they are a subclass of object properties
in OWL Full). Is there is a test case for this?!
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 other syntactic variations. For
example, the second 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" />
The construct owl:InverseFunctionalProperty
is also a subclass of the OWL class owl:ObjectProperty. 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.
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="hasSocialSecurityNumber">
<rdfs:domain rdf:resource="Person"/>
</owl:InverseFunctionalProperty>
This example states that a 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. 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 "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>
The OWL property class owl:SymmetricProperty
is, like owl:TransitiveProperty, a
subclass of owl:ObjectProperty. 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.
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
@@ Is this a hard constraint in OWL??
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>
These axioms include a number of statements about the opera
Tosca, composed by Giacomo Puccini. The opera has three libretto
writers. The property premiereDate links an opera to a 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 example
below. The example defines some facts about an anonymous instance of the
class Measurement, a quantitative observation for which facts
such as the observed subject, 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,
phenomenon weight for the subject Jane Doe. The measured value 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.
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:Different 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="#Tools"/>
<Opera rdf:about="#Turandot"/>
<Opera rdf:about="#Salome"/>
</owl:distinctMembers>
</owl:AllDifferent>
This states that these six URI references all point to different
operas.
@@ Include example of how to add to this list?!
7. 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:
7.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. A typed literal needs to have an RDF attribute
rdf:datatype of which the value should be a URI reference to an
XML Schema datatype. 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>
The datatype dateTime is defined by XML Schema.
The OWL Guide document [OWL Guide]
contains a table of frequently-used data types. For a full listing, see the
XML Schema documentation [XML Schema
Datatypes].
@@ Discuss use of XMLLiteral, QName as datatypes
7.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 range value of
owl:oneOf is a list of literals. Unfortunately, we cannot use
the rdf:parseType="Collection" idiom for specifying this 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>
<rdfs:Class>
<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>
</rdfs:Class>
</rdfs:range>
</owl:DatatypeProperty>
NOTE: Enumerated datatypes are not part of OWL Lite.
@@ What should be the class of the enumerated datatype? It
cannot be rdfs:Datatype, because that should be an XML Schema datatype. For
the moment, we used rdfs:Class (as AS&S does), but this may puzzle
people. The alternative is to define a class owl:Datatype.
In the introduction we briefly discussed the three sublanguages of OWL. In
this section an informal specification is given of the differences between
the three "species" of OWL. A formal account of the differences is given in
the Abstract Syntax and Semantics document [OWL AS&S].
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 proper 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 also be part of the
individual domain. 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.
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, data values and
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 restrictions should be placed on
transitive properties or their superproperties.
- In OWL DL anonymous classes are only allowed to occur in the following
places in class axioms:
- within the range value of a
rdfs:subclass,
owl:equivalentClass or owl:disjointWith
statement
- as the domain value of a
owl:equivalentClass or
owl:disjointWith statement
- 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 in the same ontology 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 owl:Class axiom for
"C2".
An OWL DL ontology that imports a OWL Full ontology becomes an OWL Full
ontology.
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:
- OWL Lite allows three types of class axioms:
- Class axioms with a rdfs:subClassOf statement. In these
axioms the domain should be a class identifier and the range
should be either a class identifier or a property
restriction.
- Class axioms with an owl:equivalentClass statement. In
these axioms both the domain and range should be either a class
identifier or a property restriction.
- Class axioms that consist of a class description of the
owl:intersectionOf type, with a class identifier as
the domain value of the intersection statement. The range should
be a list of class identifiers and/or property restrictions. An
example:
<owl:Class rdf:ID="Woman">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Female"/>
<owl:Class rdf:about="#Human"/>
</owl:intersectionOf>
</owl:Class/>
Thus, the use of class axioms containing owl:disjointWith statements and the use
of class description of the enumeration, union and complement types
are never allowed in OWL Lite.
- 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:
- Only class descriptions of the class-identifier and
property-restriction type are allowed at the righthand-side of domain
and range statements for object properties.
- The range of a datatype property is not allowed to be an enumerated datatype. Only the name of
an RDF datatype is allowed.
- Restrictions on individual axioms ("facts"): none
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).
If an OWL Lite ontology imports an OWL DL or OWL Full ontology, it
effectively becomes an OWL DL resp. OWL Full ontology.
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: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>
Appendix B. RDF Schema of 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
xml:base ="http://www.w3.org/2002/07/owl"
xmlns ="&owl;"
xmlns:owl ="&owl;"
xmlns:rdf ="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:dc ="http://purl.org/dc/elements/1.1/"
>
<Ontology rdf:about="">
<versionInfo>owl.owl,v 1.21</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 specified in RDF Schema
</dc:description>
<dc:publisher>W3C</dc:publisher>
<dc:date>Jan 15, 2003</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"/>
</rdf:Property>
<rdf:Property rdf:ID="sameAs">
<rdfs:label>sameAs</rdfs:label>
<EquivalentProperty 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="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>
<rdfs:domain rdf:resource="#Ontology"/>
</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
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: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.
- [OWL Abstract Syntax]
- Web
Ontology Language (OWL) Abstract Syntax and
Semantics. 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/. 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,
eds. 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/OWLOverview.htm.
- [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/. Editor's
draft is available at
http://www.w3.org/2001/sw/WebOnt/guide-src/Guide.html.
- [OWL 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.