Feedback to www-rdf-logic,
please. Contributors: Tim Berners-Lee, Dan Brickley, Dan Connolly, Mike Dean,
Stefan Decker, Pat Hayes, Jeff Heflin, Jim Hendler, Ora Lassila, Deb McGuinness, Lynn
Andrea Stein, ... DAML+OIL+DT is a semantic markup language for Web resources. It builds on
earlier W3C standards such as RDF and RDF Schema, and extends these languages
with richer modelling primitives. DAML+OIL+DT provides modelling primitives
commonly found in frame-based languages.
DAML+OIL+DT extends DAML+OIL with
values from XML Schema datatypes.
The language has a clean and well
defined semantics based on description logics. This document gives a systematic, compact and informal description of all
the modelling primitives of DAML+OIL+DT. We expect this document to serve as a
reference guide for users of the DAML+OIL+DT language. A DAML+OIL+DT knowledge base is a collection of RDF
triples. DAML+OIL+DT prescribes a specific meaning for triples that use the
DAML+OIL+DT vocabulary. This document informally specifies which collections of
RDF triples constitute the DAML+OIL+DT vocabulary and what the prescribed meaning
of such triples is. As with any set of RDF triples, DAML+OIL+DT 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. As stated above, DAML+OIL+DT 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. DAML+OIL+DT only provides a semantic interpretation for
those parts of an RDF graph that instantiate the schema defined in daml+oil+dt.daml. Any additional RDF statements, resulting in additional RDF
triples are perfectly allowed, but DAML+OIL+DT is silent on the semantic
consequences (or lack thereof) of such additional triples. See Mixing Note for an example of this. A DAML+OIL+DT ontology is made up of several components, some of which are
optional, and some of which may be repeated. See the
index for a listig of all these elements. A DAML+OIL+DT ontology consists of zero or more headers, followed by
zero or more class elements, property
elements,
and instances. An The
Each 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.
DAML+OIL+DT is mostly concerned with the creation of classes that describe
(or define) part of the abstract domain. Such classes are called abstract
classes and are elements of
daml:Class, a
subclass of rdfs:Class.
DAML+OIL+DT also allows the use of XML Schema datatypes to describe
(or define) part of the datatype domain. These datatypes are used within
DAML+OIL+DT simply by including their URIs within a DAML+OIL+DT ontology.
They are (implicitly) elements of
daml:Datatype.
A Notice that the first three elements state necessary but not sufficient
conditions for class membership. The final five 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 An enumeration is a
A property restriction is a special kind of class expression. It implicitly
defines an anonymous class, namely the class of all instances that satisfy the
restriction.
There are two kinds of restrictions. The first kind,
AbstractRestriction
works on
abstract properties, i.e., properties that
relate abstract objects to other abstract objects.
The second kind
DatatypeRestriction
works on
Datatype properties, i.e., properties that
relate abstract 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.
<\span>
A Of course a cardinality constraint is simply shorthand for a pair of
minCardinality and maxCardinality constraints with equal values of N (and
similarly for cardinalityQ). 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: Note that arbitrarily complex combinations of these expressions can be
formed.See Boolean Notefor an example of
this. A
A property element contains:
Instead of a 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. Instances of both abstract classes (i.e. individuals) and of properties (i.e.
relations, pairs of individuals) are written in RDF and RDF Schema syntax.
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.
DAML+OIL+DT needs to represent unordered collections of items
(also known as bags, or multisets) in a number of constructions, such as
intersectionOf, unionOf, oneOf, disjointUnionOf and Disjoint.
DAML+OIL+DT 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 "daml:collection", the enclosed elements
must be interpreted as elements in a list structure, constructed using the
elements List, first, rest and nil. For example, the statement should be interpreted as the following construction (also
known as a consed-pair construction, from Lisp-lore): Current RDF parsers (RDF specification of
February '99) will not support the daml:collection parseType. In order to
process DAML+OIL+DT 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 daml:collection are
intended to represent unordered collections, even though the RDF datastructure
imposes a specific order on the elements. 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 we would have to write 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 syntaxin
the RDF specification for more details on this notation)
$Revision: 4.1$ of $Date: 2001/02/26$.
DAML+OIL+DT version (revision 4.1):
Frank van Harmelen, Peter F. Patel-Schneider and Ian Horrocks, editors.
Abstract
Contents
Introductory
remarks
Different syntactic forms
Mixing DAML+OIL+DT with arbitrary RDF
Language structure
Header
Ontology
element contains zero or more version information and imports
elements.
<Ontology rdf:about="">
<versionInfo>$Id: reference.html,v 1.6 2001/01/12 20:40:47 mdean Exp $</versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<imports rdf:resource="http://www.daml.org/2000/12/DAML+OIL+DT"/>
</Ontology>
Version information
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.Imports
imports
statement references another DAML+OIL+DT ontology containing definitions
that apply to the current DAML+OIL+DT 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.
Abstract Objects and Datatype Values
DAML+OIL+DT divides the universe into two 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 objects that are created within DAML+OIL+DT (or
RDF). This part is called the abstract domain.
Class element
A class element contains (part of) the definition of an abstract class.
Class
element refers
to a class name (a URI), (we will refer to this class as C) and contains
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, +DT places
no such restriction on the subClassOf relationship between classes;
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);
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;
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);
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.
The class C must be equivalent to the class defined by each of the boolean
class expression,
and
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).
Class expression
<rdfs:Class>...</rdfs:Class>
tags, or<rdfs:Class>...</rdfs:Class>
tagsThing
and Nothing
. Every
instance is a member of Thing
, and no instance is a member
Nothing
. Consequently, every class is a subclass of
Thing
and Nothing
is a subclass of every class.Enumeration
oneOf
element, containing a list of 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:
<oneOf parseType="daml:collection">
<Thing rdf:resource="#Eurasia"/>
<Thing rdf:resource="#Africa"/>
<Thing rdf:resource="#North_America"/>
<Thing rdf:resource="#South_America "/>
<Thing rdf:resource="#Australia"/>
<Thing rdf:resource="#Antarctica"/>
</oneOf>
Property restriction
There are two kinds of restrictions. The first kind,
AbstractRestriction
works on
abstract properties, i.e., properties that
relate abstract objects to other abstract objects.
The second kind
DatatypeRestriction
works on
Datatype properties, i.e., properties that
relate abstract objects to datatype values.
Both kinds of restrictions
Restriction
element contains an
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
Notice that a toClass 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
hasClass 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.toClass
element (which contains a class expression
).
A toClass element defines the class or datatype of all
instances for whom the values of property P all belong to the class
expression. In other words, it defines the class of instances 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;
hasValue
element (which contains (a reference to) an
instance or a datatype value).
A hasValue element defines the class of all instances for whom the
property P has at least one value equal to the named instance or datatype value (and
perhaps other values as well). In other words, if we call the instance
y, then it defines the class of instances x for which (x,y) is an
instance of P;
hasClass
element (which contains a class expression or a datatype references).
A hasClass element defines the class of all instances 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 instances 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.
Also notice that the correspondence of toClass with the universal
quantifier means that a toClass restriction for a property P is trivially
satisfied for an instance that has no value for property P at all. After
all, the toClass restriction demands that all values of P belong to class
P, and if no such values exist, the restriction is trivially true.
cardinality
element.
This defines the class of all instances 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;
maxCardinality
element.
This defines the class of all instances that have at most N distinct
values for the property P;
minCardinality
element.
This defines the class of all instances that have at least N distinct
values for the property P.
hasClassQ
element, containing a class expression or a datatype references:
cardinalityQ
element.
This defines the class of all instances that have exactly N distinct
values for the property P that are instances of the class expression
or datatype
(and possibly other values not belonging to the class expression or datatype). In
other words: x is an instance of the defined class (x satisfies the
restriction) if and only if there are exactly N distinct values y such
that (x,y) is an instance of P and y is an instance of the class
expression or datatype;
maxCardinalityQ
element.
This defines the class of all instances that have at most N distinct
values for the property P that are instances of the class
expression or datatype
(and possibly other values not belonging to the class expression or datatype);
minCardinalityQ
element.
This defines the class of all instances that have at least N distinct
values for the property P that are instances of the class
expression or datatype
(and possibly other values not belonging to the class
expression or datatype).
Warning: in order to
avoid "exposed content" (i.e., to hide DAML+OIL+DT annotations from
browsers), it is necessary to write cardinality constraints in an
alternative RDF format. See Cardinality Syntax Notefor
an example of this.Boolean combination of class
expressions
intersectionOf
element, containing a list of class expressions.
This defines the class that consists of exactly all the instances that are
common to all class expressions from the list. It is
analogous to logical conjunction;
unionOf
element
, containing a list of class
expressions.
This defines the class that consists exactly of all the instances that
belong to at least one of the class expressions from the list. It is analogous to logical disjunction;complementOf
element, containing a single class expression.
This defines the class that consists of exactly all instances that do not
belong to the class expression. It is analogous to
logical negation.Property element
Property
element refers to a property name (a URI) (to which
we will refer as P).
Properties that can be used in property restrictions must be either
abstract properties, which relate abstract objects to other abstract
objects, and are instances of
AbstractProperty;
or
datatype properties, which relate abstract objects to datatype
values, and are instances of
DatatypeProperty.
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;
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, the use of domain elements in DAML+OIL+DT
is deprecated.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, the use of range elements in DAML+OIL+DT
is deprecated.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),
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
inverseOf
elements (each containing a property name), for abstract 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.Property
element, it is also possible to use any
of the following elements, each of which assert additional information about
the property:
TransitiveProperty
element, which is a
subclass of AbstractProperty.
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;
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,
orUnambigousProperty
element, which is a
subclass of AbstractProperty.
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.
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 of individuals 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 a particular case of a
cardinality constraint.Instance
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>
Datatype Values
Datatype values are written in a manner that is valid RDF syntax, but which
is given a special semantics in DAML+OIL+DT.
The value is given 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
string representation is the rdf:value of the value.
So the decimal 10.5 could be input as
<xsd:decimal rdf:value="10.0">
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 XML Schema strings.
rdf:parseType="daml:collection"
<oneOf rdf:parseType="daml:collection">
<Thing rdf:resource="#red"/>
<Thing rdf:resource="#white"/>
<Thing rdf:resource="#blue"/>
</oneOf>
<List>
<first>
<Thing rdf:resource="#red">
</first>
<rest>
<List>
<first>
<Thing rdf:resource="#white">
</first>
<rest>
<List>
<first>
<Thing rdf:resource="#blue">
</first>
<rest>
<List rdf:resource="http://www.daml.org/2000/12/DAML+OIL+DT#nil">
</rest>
</List>
</rest>
</List>
</rest>
</List>
Appendix: Index of all language
elements
Notes
<rdfs:Class ID="Continents"/>
However, the following RDF statement:<rdf:Description 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.
<rdf:Description 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).
<Restriction>
<onProperty rdf:resource="#father"/>
<cardinality>1</cardinality>
</Restriction>
<Restriction cardinality="1">
<onProperty rdf:resource="#father"/>
</Restriction>
.
<complementOf>
<Class>
<unionOf parseType="daml:collection">
<Class rdf:resource="#meat"/>
<Class rdf:resource="#fish"/>
</unionOf>
</Class>
</complementOf>
<Disjoint parseType="daml:collection">
<Class>
<unionOf parseType="daml:collection">
<Class rdf:resource="#meat"/>
<Class rdf:resource="#fish"/>
</unionOf>
</Class>
<Class>
<unionOf parseType="daml:collection">
<Class rdf:resource="#plant">
<Restriction>
<onProperty rdf:resource="#is_part_of">
<hasValue rdf:resource="#plant">
</Restriction>
</unionOf>
</Class>
</Disjoint>