OWL is a semantic markup language for publishing and sharing
ontologies on the World Wide Web.
@@ details on link to D+O etc.
This Working Draft is the first version of the Ontology Web
Language (OWL) 1.0 specification. The Web
Ontology Working Group expects to update it to reflect changes in
requirements until such time as OWL becomes a W3C Recommendation.
The working group has not reached consensus on all issues, and has
produced an online
issues list
that maintains the current status
of all issues being considered.
Links to associated issues are highlighted.
Comments on this document should be sent to
public-webont-comments@w3.org,
a mailing list with
public
archive.
General discussion of related technology is welcome in
www-rdf-logic.
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 document has been produced as part of the W3C Semantic Web Activity (Activity Statement)
following the procedures set out for the
W3C
Process. The document has been written by the
Web Ontology Working
Group. The goals of the Web Ontology working group are
discussed in the
Web Ontology
Working Group charter.
This document is derived from the
DAML+OIL (March 2001) Reference Description
included in the
DAML+OIL submission.
The work of the authors, editors, and sponsors of that and predecessor documents
is gratefully acknowledged.
- Introductory remarks
- Language structure
- rdf:parseType="owl:collection"
1. Introductory remarks
This document gives a systematic, compact and informal description of all
the modelling primitives of 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 @@ guide documents for a more
narrative description of example uses of the language.
- The normative reference on the precise syntax of the language constructs
is the machine readable RDF Schema definition
of OWL, also included as Appendix C.
- @@ abstract syntax
- A precise definition of the
meaning of the language constructs is given in the
@@ Formal Specification.
- A layering of language features is given in the
@@ Feature Synopsis.
- Several other documents have been prepared describing how
other syntactic realizations of the abstract syntax can be used to
produce documents that map into this normative syntax. These
documents include:
- @@ UML
- @@ XML
- @@ frame syntax ??
- @@ N3 ??
- @@ any others???
An OWL knowledge base is a collection of RDF
triples as defined in the
RDF Model and Syntax Specification.
OWL prescribes a
specific meaning for triples that use the
OWL vocabulary. This document specifies which collections of
RDF triples constitute the OWL vocabulary and what the prescribed meaning
of such triples is.
Different syntactic forms
As with any set of RDF triples, OWL triples can be
represented in many different syntactic forms (as described in the RDF specification). The
current document uses a specific RDF syntactic form for these triples.
However, it is also allowed to use any other syntactic RDF form that
results in the same underlying set of RDF triples as the syntax used in this
document. Such other syntactic form would then carry exactly the same
prescribed meaning as the equivalent syntactic form used in this
document. See Syntax Note for an
example of this.
Mixing OWL with arbitrary RDF
As stated above, OWL assigns a specific meaning to
certain RDF triples. The model-theoretic
semantics specifies exactly which triples are assigned a specific meaning,
and what this meaning is. OWL only provides a semantic interpretation for
those parts of an RDF graph that instantiate the schema defined in http://www.w3.org/@@/owl.
Any additional RDF statements, resulting in additional RDF
triples are perfectly allowed, but OWL is silent on the semantic
consequences (or lack thereof) of such additional triples.
See Mixing Note for an example of
this.
The KIF axiomatization provides a meaning for all RDF triples, but non
OWL triples are only modelled as triples, nothing deeper.
2. Language structure
An OWL ontology is made up of several components, some of which are
optional, and some of which may be repeated. See the
index for a listing of all these components.
Througout this document, OWL constructs will be presented in a
structured format, and not as bare RDF triples.
This structured RDF format is more natural to read, but, of course, any way
of generating the same RDF triples as generated by the structured RDF
format is equivalent.
An OWL ontology consists of zero or more headers, followed
by zero or more class elements, property elements,
and instances.
An owl:Ontology
element contains zero or more version information
and imports elements.
<Ontology rdf:about="">
<versionInfo>$Id: NOTE-OWL-reference-20011218.html,v 1.6
2001/12/18 22:12:09 connolly Exp $</versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<imports rdf:resource="http://www.w3.org/@@/owl"/>
</Ontology>
The
owl:versionInfo element generally contains a string giving
information about this version, for example RCS/CVS keywords. This element
does not contribute to the logical meaning of the ontology. See the example
above.
See issue #5.14-Ontology-versioning.
Each owl:imports
statement references another OWL ontology containing definitions
that apply to the current OWL resource.
Each reference consists of a URI specifying from where the
ontology is to be imported from. See the example above.
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.
See issue #5.6-daml:imports-as-magic-syntax.
Note that namespaces only provide a mechanism for
creating unique names for elements, and do not actually include
definitions in the way that imports does. Similarly, imports statements
do not set up a shorthand notation for names. Therefore, it is common to
have imports statements that correspond to each namespace. However,
additional imports may be used for ontologies that provide definitions
without introducing any new names.
See issue #4.4-Extra-logical-feature-set.
Objects and Datatype Values
OWL divides the universe into two disjoint parts. One part
consists of the values that belong to XML Schema datatypes. This part
is called the datatype domain. The other part consists of (individual)
objects that are considered to be members of classes described within
OWL (or RDF). This part is called the object domain.
See issue
#5.1-Uniform-treatment-of-literal/data-values.
OWL is mostly concerned with the creation of classes that describe
(or define) part of the object domain. Such classes are called object
classes and are elements of
owl:Class, a
subclass of rdfs:Class.
OWL also allows the use of XML Schema datatypes to describe
(or define) part of the datatype domain. These
datatypes are used within
OWL simply by including their URIs within an OWL ontology.
They are (implicitly) elements of
owl:Datatype.
Datatypes are not OWL individual objects.
See issue #5.8-Datatypes.
A class element, owl:Class, contains (part of) the definition
of an object class.
A class element refers to a class name (a URI), (we will refer to this class
as C) and contains
- zero or more
rdfs:subClassOf elements (each containing a class-expression).
Each subClassOf element asserts that C is a subclass of the
class-expression mentioned in the element. (Each class-expression defines
a (possibly anonymous) class).
Warning: The RDF Schema
specification demands that the subclass-relation between classes must
be acyclic. We believe this to be too restrictive, since a cycle of
subclass relationships provides a useful way
to assert equality between classes. Consequently, OWL places
no such restriction on the subClassOf relationship between classes;
- zero or more
owl:disjointWith elements (each containing a class-expression).
Each disjointWith element asserts that C is disjoint with the
class-expression in the element (ie. C must have no instances in common
with it);
- zero or more
owl:disjointUnionOf elements (each containing a list of class-expressions).
Each disjointUnionOf element asserts that C has the same instances as the
disjoint union of the class-expressions element. More precisely: all of
the classes defined by the class-expressions of a disjointUnionOf element
must be pairwise disjoint (i.e. there can be no individual that is an
instance of more than one of the class expressions in the list.), and
their union must be equal to C;
See issue @@ TBD.
- zero or more
owl:sameClassAs elements (each containing a class-expression).
Each sameClassAs element asserts that C is equivalent to the
class-expression in the element (ie. C and all the class-expression must
have the same instances);
- zero or more
owl:equivalentTo elements (each
containing a class
expression)
When applied to a class, the equivalentTo element has
the same semantics as the sameClassAs element.
Warning: the
use of sameClassAs is favoured over the use of equivalentTo, since
sameClassAs is declared as a subProperty of subClassOf, while equivalentTo
is not. This makes the meaning of sameClassAs at least partly available to
an RDF Schema-only agent, while the meaning of equivalentTo is completely
opaque to such an agent.
See issue #4.6-EquivalentTo.
- zero or more boolean combinations of class
expressions.
The class C must be equivalent to the class defined by each of the boolean
class expression,
and
- zero or more enumeration elements.
Each enumeration element asserts that C contains exactly the instances
enumerated in the element (i.e: no more, no less). Although it is formally
allowed to have multiple such assertions about C, as soon as two of the
enumerations are not equivalent, the class C immediately becomes
inconsistent (since C cannot be equivalent to both of these enumerations
at once).
Notice that the first two elements state necessary but not sufficient
conditions for class membership. The final four elements state both necessary
and sufficient conditions.
A class expression is the name used in this document for either
Each class expression either refers to a named class, namely the class that
is identified by the URI, or implicitly defines an anonymous class,
respectively the class that contains exactly the enumerated elements, or the
class of all instances which satisfy the property-restriction, or the class
that satisfies the boolean combination of such expressions.
Two class names are already predefined, namely the classes
owl:Thing
and owl:Nothing. Every
object is a member of owl:Thing, and no object is a member
owl:Nothing. Consequently, every class is a subclass of
owl:Thing and owl:Nothing is a subclass of
every class.
An enumeration is a
owl:oneOf element, containing a list of the objects
that are its instances.
This enables us to define a class by exhaustively enumerating its elements.
The class defined by the oneOf element contains exactly the enumerated
elements, no more, no less. For example:
<owl:oneOf parseType="owl:collection">
<owl:Thing rdf:about="#Eurasia"/>
<owl:Thing rdf:about="#Africa"/>
<owl:Thing rdf:about="#North_America"/>
<owl:Thing rdf:about="#South_America "/>
<owl:Thing rdf:about="#Australia"/>
<owl:Thing rdf:about="#Antarctica"/>
</oneOf>
A property restriction is a special kind of class
expression. It implicitly defines an anonymous class, namely the class of
all objects that satisfy the restriction.
There are two kinds of restrictions. The first kind,
ObjectRestriction,
works on
object properties, i.e., properties that
relate objects to other objects.
The second kind,
DatatypeRestriction,
works on
datatype properties, i.e., properties that
relate objects to datatype values.
Both kinds of restrictions are created using the same syntax, with the
usual difference being whether a class element or a datatype reference is
used.
It is also possible to create restrictions that are neither
restrictions nor datatype restrictions, but these restrictions are not
handled within OWL.
See issue #5.9-Malformed-DAML+OIL-Restrictions.
A owl:Restriction element contains an
owl:onProperty element, which refers to a property name (a
URI) (we will refer to this property as P) and one or more of the
following
- elements indicating the type of restriction:
- an
owl:allValuesFrom
element (which contains a class expression
).
An allValuesFrom element defines the class of all
objects for whom the values of property P all belong to
the class
expression. In other words, it defines the class of object x
for which it holds that if the pair (x,y) is an instance of P, then y
is an instance of the class-expression or
datatype;
- an
owl:hasValue
element (which contains (a reference to) an
individual object or a datatype value).
A hasValue element defines the class of all objects for
whom the property P has at least one value equal to the
named object or datatype value (and
perhaps other values as well). In other words, if we call the instance
y, then it defines the class of objects x for which (x,y)
is an instance of P;
- an
owl:someValuesFrom
element (which contains a class expression
or a datatype
references).
A someValuesFrom element defines the class of all objects for
which at least one value of the property P is a member of the class
expression or datatype.
In other words, it defines the class of objects x for
which there is
at least one instance y of the class-expression or datatype such
that (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 expression or datatype.
Notice that an 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. The
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 fulfils the restriction.
Also notice that the correspondence of allValuesFrom with the universal
quantifier means that an allValuesFrom restriction for a property P is trivially
satisfied for an instance that has no value for property P at all. To see
why this is so, observe that the allValuesFrom restriction demands that all
values of P belong to class P, and if no such values exist, the
restriction is trivially true.
- elements containing a non-negative integer (to which we will refer as N)
indicating a cardinality restriction:
See issue #4.2-Cardinality-Constructs-Levels.
- an
owl:cardinality element.
This defines the class of all objects that have exactly N
distinct
values for the property P, i.e. x is an instance of the defined class
if and only if there are N distinct values y such that (x,y) is an
instance of P;
- an
owl:maxCardinality element.
This defines the class of all objects that have at most N
distinct values for the property P;
- an
owl:minCardinality element.
This defines the class of all objects that have at least N
distinct values for the property P.
When there are multiple restrictions listed
as part of a single Restriction element, the property P has to satisfy all of
the restrictions (i.e., multiple restrictions are read as a
conjunction).
Notice that the restrictedBy element which was
associated with slot-restrictions in earlier versions of the language has now
been removed, since it is completely synonymous with subClassOf.
A boolean combination of class expressions can be constructed from:
- an
owl:intersectionOf element, containing a list of class expressions.
This defines the class that consists of exactly all the objects that are
common to all class expressions from the list. It is
analogous to logical conjunction;
- an
owl:unionOf
element, containing a list of class
expressions.
This defines the class that consists exactly of all the objects that
belong to at least one of the class expressions from the
list. It is analogous to logical disjunction;
- an
owl:complementOf element, containing a single class expression.
This defines the class that consists of exactly all objects
that do not belong to the class expression. It is
analogous to logical negation, but restricted to objects
only.
Note that arbitrarily complex combinations of these expressions can be
formed. See Boolean Notefor an example of
this.
A rdf:Property element refers to a property name (a URI)
(to which
we will refer as P).
Properties that are used in property restrictions should be either
properties, which relate objects to other objects, and are instances of
ObjectProperty;
or
datatype properties, which relate objects to datatype
values, and are instances of
DatatypeProperty.
A property element contains:
- zero or more
rdfs:subPropertyOf elements, each containing a property
name.
Each subPropertyOf element states that P is a subproperty of the property
named in the element. This means that every pair (x,y) that is an instance
of P is also an instance of the named property;
- zero or more
rdfs:domain elements (each containing a class expression).
Each domain element asserts that the property P only applies to instances
of the class expression of the element. More formally: if a pair (x,y) is
an instance of P, then x is an instance of the class expression. This
implies that multiple domain expressions restrict the domain of P to the
intersection of the class expressions.
Warning: This is contrary to the semantics of the domain
element in the RDF Schema
specification, which we believe to be flawed. Note that unlike any of
the property restrictions mentioned
above, these
domain restrictions are global. The property restrictions above are part
of a class element, and are only enforced on the property when applied to
that class. In contrast, domain restrictions apply to the property
irrespective of the Class to which it is applied. This is by virtue of
their semantics in RDF Schema;
Because of this, domain elements should be used with
great care in OWL.
- zero or more
rdfs:range
elements (each containing a class expression).
Each range element asserts that the property P only assumes values that
are instances of the class expression of the element. More formally: a
pair (x,y) can only be an instance of P if y is an instance of the class
expression.
Warning: Although the RDF Schema
specification only allows one range restriction for each property, it
seems quite natural to allow multiple range restrictions. These would then
again be interpreted as saying that the range of P must be the
intersection of all the class expressions. Furthermore, as with domain
restrictions, range restrictions are global, by virtue of RDF Schema;
Because of this, range elements should be used with
great care in OWL.
- zero or more
owl:samePropertyAs elements (each containing a property
name).
Each samePropertyAs element asserts that P is equivalent to the named
property (i.e. they must have the same instances),
- zero or more
equivalentTo elements (each
containing a property name).
When applied to a property, the equivalentTo element
has the same semantics as the samePropertyAs element;
Warning: the use of samePropertyAs is
favoured over the use of equivalentTo, since samePropertyAs is declared as
a subProperty of subPropertyOf, while equivalentTo is not. This makes the
meaning of samePropertyAs at least partly available to an RDF Schema-only
agent, while the meaning of equivalentTo is completely opaque to such an
agent.
and
- zero or more
owl:inverseOf elements (each containing a property name),
for properties only.
Each inverseOf element asserts that P is the inverse relation of the named
property. More formally: if the pair (x,y) is an instance of P, than the
pair (y,x) is an instance of the named property.
See issue #4.5-InverseOf.
Instead of an object property or datatype property element, it is also
possible to
use any of the following elements, each of which assert additional
information about the property:
- an
owl:TransitiveProperty element, which is a
subclass of ObjectProperty.
This asserts that P is transitive, i.e: if the pair (x,y) is an instance
of P, and the pair (y,z) is an instance of P, then the pair (x,z) is also
an instance of P;
- an
owl:SymmetricProperty element, which is a
subclass of ObjectProperty.
This asserts that P is symmetric, i.e: if the pair (x,y) is an instance
of P, then the pair (y,x) is also
an instance of P;
- an
owl:UniqueProperty
element.
This asserts that P can only have one (unique) value y for each instance
x, i.e: there cannot be two distinct instances y1 and y2 such that the
pairs (x,y1) and (x,y2) are both instances of P. Of course, this is a
shorthand notation for the maxCardinality restriction of 1.
See issue #4.1-UniqueProp-BadName.
or
- an
owl:UnambigousProperty element, which is a
subclass of ObjectProperty.
This asserts that an instance 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 (x1,y) and (x2,y) are both instances of P. Notice that the
inverse property of a UniqueProperty is always an UnambigousProperty and
vice versa.
See issue #4.1-UniqueProp-BadName.
Notice that UniqueProperty and UnambiguousProperty
specify global cardinality restrictions. That is, no matter what class the
property is applied to, the cardinality constraints must hold, unlike the
various cardinality properties used in property
restrictions, which are part of a
class element, and are only enforced on the property when applied to that
class.
A property is a binary relation that may or may not be defined in the
ontology. If it is not defined, then it is assumed to be a binary relation
with no globally applicable constraints, i.e. any pair with first element
an object and second element an object or datatype value
could be an instance of the property.
Warning: If a transitive property (or any of its
superproperties) is used in a cardinality constraint, then class consistency
is no longer necessarily decidable. Of course, UniqueProperty is a particular case of a
cardinality constraint.
Instances of both classes
(i.e., objects) and of properties (i.e., pairs) are written in
RDF and
RDF Schema
syntax.
See the specification of these languages for more details on the various
syntactic forms that are allowed. Here we list just some of the most common
notations:
<continent rdf:ID="Asia"/>
<rdf:Description rdf:ID="Asia">
<rdf:type>
<rdfs:Class rdf:about="#continent"/>
</rdf:type>
</rdf:Description>
<rdf:Description rdf:ID="India">
<is_part_of rdf:resource="#Asia"/>
</rdf:Description>
There is no unique name assumption for objects in OWL.
To state that objects are the same, an
owl:sameIndividualAs element
is used.
(Note that owl:equivalentTo can be also used here, but
owl:sameIndividual is preferred.
To state that objects are distinct,
an owl:differentIndividualFrom
element is used.
The situation is different for datatype values, where XML Schema Datatype
identity is used.
Datatype values are written in a manner that is valid RDF syntax, but which
is given a special semantics in OWL.
The preferred method is to give a lexical representation of the value as a
string, along with an XML Schema datatype that is
used to provide the type of the value as well as the parsing mechanism to
go from the string to the value itself.
The XML Schema datatype is the rdf:type of the value, and the
lexical representation is the rdf:value of the value.
So the decimal 10.5 could be input as
<xsd:decimal rdf:value="10.5">
provided that xsd was defined as the URI of the XML Schema
Datatype specification.
As a nod to backward compatability, literals that occur outside this sort
of construction are interpreted as any of the XML Schema Datatype values
with this lexical representation. These values are mostly unusable unless
some typing information is available, such as a range for a property.
The question of whether any XML Schema datatype can be used in such
constructions, or whether only certain XML Schema dataypes can be so used
(such as only the predefined datatypes), remains open.
See issue #4.3-Structured-Datatypes.
See issue #5.7-Range-restrictions-should-not-be-separate-URIs.
OWL needs to represent unordered collections of items
(also known as bags, or multisets) in a number of constructions, such as
intersectionOf, unionOf, oneOf, and disjointUnionOf.
OWL exploits the rdf:parseType attribute to extend the syntax for RDF
with a convenient notation for such collections. Whenever an element has the
rdf:parseType attribute with value "owl:collection", the enclosed elements
must be interpreted as elements in a list structure, constructed using the
elements List, first, rest and nil.
See issue #5.5-List-syntax-or-semantics.
For example, the statement
<oneOf rdf:parseType="owl:collection">
<Thing rdf:about="#red"/>
<Thing rdf:about="#white"/>
<Thing rdf:about="#blue"/>
</oneOf>
should be interpreted as the following construction (also
known as a consed-pair construction, from Lisp-lore):
<List>
<first>
<Thing rdf:about="#red">
</first>
<rest>
<List>
<first>
<Thing rdf:about="#white">
</first>
<rest>
<List>
<first>
<Thing rdf:about="#blue">
</first>
<rest>
<List rdf:resource="http://www.w3.org/@@/owl#nil">
</rest>
</List>
</rest>
</List>
</rest>
</List>
Current RDF parsers (RDF specification of
February '99) will not support the owl:collection parseType. In order to
process OWL documents, such parsers will have to be extended, or a
separate preprocessing stage is required which translates the first form above
into the second before the DAM+OIL code is given as input to the RDF
parser.
Note that structures of parseType owl:collection are
intended to represent unordered collections, even
though the RDF datastructure imposes a specific order on the elements.
Appendix B. Notes
- Syntax Note:
- As a simple example of an alternative syntactic
form resulting in the same set of RDF triples, consider the statement in
this document that "an OWL class definition consists at least of an
rdfs:class element", which suggests the following syntactic form:
<rdfs:Class rdf:ID="Continents"/>
However, the following RDF statement:
<rdf:Description rdf:ID="Continents">
<rdf:Type resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>
results in exactly the same set of RDF triples, and is therefore
perfectly allowed as a class definition.
Another example is the two notations that we
discuss for cardinality constraints below. Again, both these forms
result in the same set of RDF triples, and are thus equivalent.
- Mixing
Note:
- For example, take the class definition for Person
from OWL-ex.owl, and then
add
<rdf:Description rdf:about="#Person">
<Creator>Ora Lassila</Creator>
</rdf:Description>
then the semantics don't say what this means or what
it would imply for instances of Person. (Beyond of course the minimal
Subject-Verb-Object semantics of RDF).
- Cardinality
Syntax Note:
- As an example of content-hiding syntax for
cardinality expressions, instead of the standard notation:
<Restriction>
<onProperty rdf:resource="#father"/>
<cardinality>1</cardinality>
</Restriction>
we would have to write
<Restriction cardinality="1">
<onProperty rdf:resource="#father"/>
</Restriction>
to avoid any exposed content. The cardinality
elements are the only ones for which this alternative notation is
required to avoid exposed content.
(See
the section on abbreviated syntax
in the RDF specification for more details on this notation).
- Boolean
Note:
- As an example of a combination of boolean
operators, the expression "neither meat nor fish" could be written
as:
<complementOf>
<Class>
<unionOf parseType="owl:collection">
<Class rdf:resource="#meat"/>
<Class rdf:resource="#fish"/>
</unionOf>
</Class>
</complementOf>
Appendix C.
http://www.w3.org/@@/owl
@@ include content from http://www.w3.org/@@/owl.
- @@