Reference description of the
DAML+OIL ontology markup language

Frank van Harmelen, Ian Horrocks (editors)

Contributors: Tim Berners-Lee, Dan Brickley, Dan Connolly, Mike Dean, Stefan Decker, Pat Hayes, Jeff Heflin, Jim Hendler, Deb McGuinness, Lynn Andrea Stein

Abstract

DAML+OIL 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 provides modelling primitives commonly found in frame-based languages. 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. We expect this document to serve as a reference guide for users of the DAML+OIL language.

Contents

Introductory remarks

A DAML+OIL knowledge base is a collection of RDF triples. DAML+OIL prescribes a specific meaning for triples that use the DAML+OIL vocabulary. This document informally specifies which collections of RDF triples constitute the DAML+OIL vocabulary and what the prescribed meaning of such triples is.

Different syntactic forms

As with any set of RDF triples, DAML+OIL 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 DAML+OIL with arbitrary RDF

As stated above, DAML+OIL 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 only provides a semantic interpretation for those parts of an RDF graph that instantiate the schema defined in daml+oil.daml. Any additional RDF statements, resulting in additional RDF triples are perfectly allowed, but DAML+OIL is silent on the semantic consequences (or lack thereof) of such additional triples. See Mixing Note for an example of this.

Language structure

A DAML+OIL 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 ontology consists of zero or more headers, followed by zero or more class elements, property elements, axioms and instances.

Header

An 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"/>
</Ontology>

Version information

The 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

Each imports statement references another DAML+OIL ontology containing definitions that apply to the current DAML+OIL 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.

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.

Class element

A Class element refers to a class name (a URI), (we will refer to this class as C) and contains

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.

Class expression

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 Thing 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.

Note: Future versions of DAML+OIL are expected to provide support for "concrete domains" such as integers, strings, etc. No such concrete domains are provided in the current version.

Enumeration

An enumeration is a 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

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.
A 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

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.

Boolean combination of class expressions

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.

Property element

A Property element refers to a property name (a URI) (to which we will refer as P), and contains:

Instead of a Property element, it is also possible to use any of the following elements, each of which assert additional information about the property:

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 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 decidable. Of course, UniqueProperty is a a particular case of a cardinality constraint.

Axiom

A Disjoint element contains a list of class-expressions.

A Disjoint element asserts that all of (the classes defined by) these class expressions are pairwise disjoint. In other words: no pair of two class-expressions from the list have any instances in common.

When all the class-expressions in the list are class names, then a Disjoint assertion could have been made with a number of disjointWith elements for each of the individual classes, and the Disjoint assertion is only a convenient shorthand in this case. However, the Disjoint element also allows us to make disjointness statements about arbitrarily complex class-expressions. See Disjoint Notefor an example of this.

Of course, all of the other elements described above are axioms that assert facts about the classes, properties and instances of an ontology. All of the axioms described so far are associated with either a Class element or a Property element (or any of the variants of the Property element). The disjoint axiom is the only axiom in DAML+OIL that is not associated with either aClass element or (a variant of) a Propertyelement.

Instance

Instances of both classes (i.e. individuals) and of properties (i.e. relations, pairs of individuals) 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>

rdf:parseType="daml:collection"

DAML+OIL 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 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

<oneOf rdf:parseType="daml:collection">
  <Thing rdf:resource="#red"/>
  <Thing rdf:resource="#white"/>
  <Thing rdf:resource="#blue"/>
</oneOf>

should be interpreted as the following construction (also known as a consed-pair construction, from Lisp-lore):

<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#nil">
     </rest>
    </List>
   </rest>
  </List>
 </rest>
</List>

Current RDF parsers (RDF specification of February '99) will not support the daml:collection parseType. In order to process DAML+OIL 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.

Appendix: Index of all language elements

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 "a DAML+OIL class definition consists at least of an rdfs:class element", which suggests the following syntactic form:
<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.

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 daml+oil-ex.daml, and then add
<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).

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 syntaxin 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="daml:collection"> 
   <Class rdf:resource="#meat"/>
   <Class rdf:resource="#fish"/> 
  </unionOf> 
 </Class>
</complementOf>

Disjoint Note:
For example, the following combination a Disjoint element with class expressions to state that "meat or fish" is disjoint from "plants or parts of plants".
<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>

$Revision: 1.6 $ of $Date: 2001/01/12 20:40:47 $