DAML+OIL (March 2001) Reference Description (original) (raw)

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. DAML+OIL (March 2001) extends DAML+OIL (December 2000) with values from XML Schema datatypes. DAML+OIL was built from the original DAML ontology language DAML-ONT (October 2000) in an effort to combine many of the language components of OIL. The language has a clean and well defined semantics.

Status of this document

This document is a submission to the World Wide Web Consortium from Lucent Technologies (see Submission Request,W3C Staff Comment).

Please send comments to Peter F. Patel-Schneiderpfps@research.bell-labs.com, or, preferably, to the publicly archived distribution list,www-rdf-logic@w3.org[archive].

This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.

A list of current W3C technical documents can be found at the Technical Reports page.

Introductory remarks
Language structure
rdf:parseType="daml:collection"

Appendices

Appendix A. Index of all language elements
Appendix B. Notes
Appendix C. http://www.w3.org/2001/10/daml+oil

1. Introductory remarks

This document gives a systematic, compact and informal description of all the modelling primitives of DAML+OIL (March 2001). We expect this document to serve as a reference guide for users of the DAML+OIL language.

Readers unfamiliar with DAML+OIL should first consult the DAML+OIL walkthrough for a more narrative description of an example use of the language.
The normative reference on the precise syntax of the language constructs is the machine readable RDF Schema definition of DAML+OIL, also included as Appendix C.
Two references that give a precise definition of the meaning of the language constructs are the model-theoretic semantics and the KIF axiomatization.

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 http://www.w3.org/2001/10/daml+oil. 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. The KIF axiomatization provides a meaning for all RDF triples, but non DAML+OIL triples are only modelled as triples, nothing deeper.

2. 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 listing of all these components. Througout this document, DAML+OIL 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.

A DAML+OIL ontology consists of zero or more headers, followed by zero or more class elements, property elements, and instances.

An daml:Ontologyelement contains zero or more version informationand imports elements.

$Id: NOTE-daml+oil-reference-20011218.html,v 1.7 2017/10/02 10:23:30 denis Exp $ An example ontology

Version information

Thedaml: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 daml:importsstatement 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. 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 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.

Objects and Datatype Values

DAML+OIL 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 DAML+OIL (or RDF). This part is called the object domain.

DAML+OIL 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 ofdaml:Class, a subclass of rdfs:Class. DAML+OIL (March 2001) also allows the use of XML Schema datatypes to describe (or define) part of the datatype domain. These datatypes are used within DAML+OIL simply by including their URIs within a DAML+OIL ontology. They are (implicitly) elements of daml:Datatype. Datatypes are not DAML+OIL individual objects.

Class elements

A class element, daml: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 morerdfs: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, DAML+OIL (March 2001) places no such restriction on the subClassOf relationship between classes;
zero or moredaml: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 moredaml: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;
zero or moredaml: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 moredaml: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.
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.

Class expressions

A class expression is the name used in this document for either

a class name (a URI), or
an enumeration, enclosed in<daml:Class>...</daml:Class> tags, or
a property-restriction, or
or a boolean combination of class expressions, enclosed in <rdfs:Class>...</rdfs:Class> tags

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 daml:Thingand daml:Nothing. Every object is a member of daml:Thing, and no object is a member daml:Nothing. Consequently, every class is a subclass ofdaml:Thing and daml:Nothing is a subclass of every class.

Enumerations

An enumeration is adaml: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:

<daml:oneOf parseType="daml:collection"> <daml:Thing rdf:about="#Eurasia"/> <daml:Thing rdf:about="#Africa"/> <daml:Thing rdf:about="#North_America"/> <daml:Thing rdf:about="#South_America "/> <daml:Thing rdf:about="#Australia"/> <daml:Thing rdf:about="#Antarctica"/>

Property restrictions

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

A daml:Restriction element contains andaml: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:
- a daml:toClass element (which contains a class expression ).
  A toClass 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;
- adaml: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;
- Adaml:hasClass element (which contains a class expression or a datatype references).
  A hasClass 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 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.
  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. To see why this is so, observe that the toClass 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 an unqualified cardinality restriction:
- adaml: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;
- adaml:maxCardinality element.
  This defines the class of all objects that have at most N distinct values for the property P;
- adaml:minCardinality element.
  This defines the class of all objects that have at least N distinct values for the property P.
elements containing a non-negative integer (to which we will refer as N)indicating a qualified cardinality restriction, and containing a daml:hasClassQ element, containing a class expression or a datatype references:
- adaml:cardinalityQ element.
  This defines the class of all objects 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;
- adaml:maxCardinalityQ element.
  This defines the class of all objects 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);
- adaml:minCardinalityQ element.
  This defines the class of all objects 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).
  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).
  Warning: in order to avoid "exposed content" (i.e., to hide DAML+OIL annotations from browsers), it is necessary to write cardinality constraints in an alternative RDF format. See Cardinality Syntax Notefor an example of this.

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:

andaml: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;
a daml: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;
adaml: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.

Property elements

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 morerdfs: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 morerdfs: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 DAML+OIL.
zero or morerdfs: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 DAML+OIL.
zero or moredaml: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 moredaml: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.

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:

adaml: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;
adaml: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,
or
andaml: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.

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 a particular case of a cardinality constraint.

Instances

Instances of both classes (i.e., objects) and of properties (i.e., pairs) are written in RDF and RDF Schemasyntax.
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:

<rdf:Description rdf:ID="Asia"> rdf:type <rdfs:Class rdf:about="#continent"/>

<rdf:Description rdf:ID="India">

There is no unique name assumption for objects in DAML+OIL. To state that objects are the same, adaml:sameIndividualAs element is used. (Note that daml:equivalentTo can be also used here, butdaml:sameIndividual is preferred. To state that objects are distinct, a daml:differentIndividualFromelement is used. The situation is different for datatype values, where XML Schema Datatype identity is used.

Datatype Values

Datatype values are written in a manner that is valid RDF syntax, but which is given a special semantics in DAML+OIL. 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.

3. 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, and disjointUnionOf. 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

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 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 A. Index of all language elements

cardinality
cardinalityQ
Class
complementOf
Datatype
DatatypeProperty
DatatypeRestriction
Datatype value
differentIndividualFrom
disjointUnionOf
disjointWith
domain
equivalentTo
hasClass
hasClassQ
hasValue
imports
intersectionOf
inverseOf
maxCardinality
maxCardinalityQ
minCardinality
minCardinalityQ
ObjectClass
ObjectProperty
ObjectRestriction
oneOf
onProperty
Ontology
Property
range
Restriction
sameClassAs
sameIndividualAs
samePropertyAs
subClassOf
subPropertyOf
toClass
TransitiveProperty
UnambigousProperty
unionOf
UniqueProperty
versionInfo

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 "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="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

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"> Ora Lassila

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:

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

Boolean Note:

As an example of a combination of boolean operators, the expression "neither meat nor fish" could be written as:

Appendix C. http://www.w3.org/2001/10/daml+oil

<rdf:RDF xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:daml="http://www.w3.org/2001/10/daml+oil#" xmlns ="http://www.w3.org/2001/10/daml+oil#"

<rdf:Description rdf:about=""> $Id: NOTE-daml+oil-reference-20011218.html,v 1.7 2017/10/02 10:23:30 denis Exp $

<rdfs:Class rdf:ID="Class"> rdfs:labelClass rdfs:comment The class of all "object" classes <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

<rdfs:Class rdf:ID="Datatype"> rdfs:labelDatatype rdfs:comment The class of all datatype classes <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

Thing The most general (object) class in DAML. This is equal to the union of any class and its complement. Nothing the class with no things in it.

<rdf:Property rdf:ID="equivalentTo"> rdfs:labelequivalentTo rdfs:comment for equivalentTo(X, Y), read X is an equivalent term to Y.

<rdf:Property rdf:ID="sameClassAs"> rdfs:labelsameClassAs rdfs:comment for sameClassAs(X, Y), read X is an equivalent class to Y. cf OIL Equivalent <rdfs:subPropertyOf rdf:resource="#equivalentTo"/> <rdfs:subPropertyOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#subClassOf"/> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/>

<rdf:Property rdf:ID="samePropertyAs"> rdfs:labelsamePropertyAs rdfs:comment for samePropertyAs(P, R), read P is an equivalent property to R. <rdfs:subPropertyOf rdf:resource="#equivalentTo"/> <rdfs:subPropertyOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#subPropertyOf"/>

<rdf:Property rdf:ID="sameIndividualAs"> rdfs:labelsameIndividualAs rdfs:comment for sameIndividualAs(a, b), read a is the same individual as b. <rdfs:subPropertyOf rdf:resource="#equivalentTo"/> <rdfs:domain rdf:resource="#Thing"/> <rdfs:range rdf:resource="#Thing"/>

<rdf:Property rdf:ID="disjointWith"> rdfs:labeldisjointWith rdfs:comment for disjointWith(X, Y) read: X and Y have no members in common. cf OIL Disjoint <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/>

<rdf:Property rdf:ID="differentIndividualFrom"> rdfs:labeldifferentIndividualFrom rdfs:comment for differentIndividualFrom(a, b), read a is not the same individual as b. <rdfs:domain rdf:resource="#Thing"/> <rdfs:range rdf:resource="#Thing"/>

<rdf:Property rdf:ID="unionOf"> rdfs:labelunionOf rdfs:comment for unionOf(X, Y) read: X is the union of the classes in the list Y; i.e. if something is in any of the classes in Y, it's in X, and vice versa. cf OIL OR <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#List"/>

<rdf:Property rdf:ID="disjointUnionOf"> rdfs:labeldisjointUnionOf rdfs:comment for disjointUnionOf(X, Y) read: X is the disjoint union of the classes in the list Y: (a) for any c1 and c2 in Y, disjointWith(c1, c2), and (b) unionOf(X, Y). i.e. if something is in any of the classes in Y, it's in X, and vice versa. cf OIL disjoint-covered <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#List"/>

<rdf:Property rdf:ID="intersectionOf"> rdfs:labelintersectionOf rdfs:comment for intersectionOf(X, Y) read: X is the intersection of the classes in the list Y; i.e. if something is in all the classes in Y, then it's in X, and vice versa. cf OIL AND <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#List"/>

<rdf:Property rdf:ID="complementOf"> rdfs:labelcomplementOf rdfs:comment for complementOf(X, Y) read: X is the complement of Y; if something is in Y, then it's not in X, and vice versa. cf OIL NOT <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/>

<rdf:Property rdf:ID="oneOf"> rdfs:labeloneOf rdfs:comment for oneOf(C, L) read everything in C is one of the things in L; This lets us define classes by enumerating the members. cf OIL OneOf <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#List"/>

<rdfs:Class rdf:ID="Restriction"> rdfs:labelRestriction rdfs:comment something is in the class R if it satisfies the attached restrictions, and vice versa. <rdfs:subClassOf rdf:resource="#Class"/>

<rdf:Property rdf:ID="onProperty"> rdfs:labelonProperty rdfs:comment for onProperty(R, P), read: R is a restricted with respect to property P. <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdf:Property rdf:ID="toClass"> rdfs:labeltoClass rdfs:comment for onProperty(R, P) and toClass(R, X), read: i is in class R if and only if for all j, P(i, j) implies type(j, X). cf OIL ValueType <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

<rdf:Property rdf:ID="hasValue"> rdfs:labelhasValue rdfs:comment for onProperty(R, P) and hasValue(R, V), read: i is in class R if and only if P(i, V). cf OIL HasFiller <rdfs:domain rdf:resource="#Restriction"/>

<rdf:Property rdf:ID="hasClass"> rdfs:labelhasClass rdfs:comment for onProperty(R, P) and hasClass(R, X), read: i is in class R if and only if for some j, P(i, j) and type(j, X). cf OIL HasValue <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

<rdf:Property rdf:ID="minCardinality"> rdfs:labelminCardinality rdfs:comment for onProperty(R, P) and minCardinality(R, n), read: i is in class R if and only if there are at least n distinct j with P(i, j). cf OIL MinCardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdf:Property rdf:ID="maxCardinality"> rdfs:labelmaxCardinality rdfs:comment for onProperty(R, P) and maxCardinality(R, n), read: i is in class R if and only if there are at most n distinct j with P(i, j). cf OIL MaxCardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdf:Property rdf:ID="cardinality"> rdfs:labelcardinality rdfs:comment for onProperty(R, P) and cardinality(R, n), read: i is in class R if and only if there are exactly n distinct j with P(i, j). cf OIL Cardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdf:Property rdf:ID="hasClassQ"> rdfs:labelhasClassQ rdfs:comment property for specifying class restriction with cardinalityQ constraints <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/01/rdf-schema#Class"/>

<rdf:Property rdf:ID="minCardinalityQ"> rdfs:labelminCardinality rdfs:comment for onProperty(R, P), minCardinalityQ(R, n) and hasClassQ(R, X), read: i is in class R if and only if there are at least n distinct j with P(i, j) and type(j, X). cf OIL MinCardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdf:Property rdf:ID="maxCardinalityQ"> rdfs:labelmaxCardinality rdfs:comment for onProperty(R, P), maxCardinalityQ(R, n) and hasClassQ(R, X), read: i is in class R if and only if there are at most n distinct j with P(i, j) and type(j, X). cf OIL MaxCardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdf:Property rdf:ID="cardinalityQ"> rdfs:labelcardinality rdfs:comment for onProperty(R, P), cardinalityQ(R, n) and hasClassQ(R, X), read: i is in class R if and only if there are exactly n distinct j with P(i, j) and type(j, X). cf OIL Cardinality <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/2000/10/XMLSchema#nonNegativeInteger"/>

<rdfs:Class rdf:ID="ObjectProperty"> rdfs:labelObjectProperty rdfs:comment if P is an ObjectProperty, and P(x, y), then y is an object. <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdfs:Class rdf:ID="DatatypeProperty"> rdfs:labelDatatypeProperty rdfs:comment if P is a DatatypeProperty, and P(x, y), then y is a data value. <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdf:Property rdf:ID="inverseOf"> rdfs:labelinverseOf rdfs:comment for inverseOf(R, S) read: R is the inverse of S; i.e. if R(x, y) then S(y, x) and vice versa. cf OIL inverseRelationOf <rdfs:domain rdf:resource="#ObjectProperty"/> <rdfs:range rdf:resource="#ObjectProperty"/>

<rdfs:Class rdf:ID="TransitiveProperty"> rdfs:labelTransitiveProperty rdfs:comment if P is a TransitiveProperty, then if P(x, y) and P(y, z) then P(x, z). cf OIL TransitiveProperty. <rdfs:subClassOf rdf:resource="#ObjectProperty"/>

<rdfs:Class rdf:ID="UniqueProperty"> rdfs:labelUniqueProperty rdfs:comment compare with maxCardinality=1; e.g. integer successor: if P is a UniqueProperty, then if P(x, y) and P(x, z) then y=z. cf OIL FunctionalProperty. <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdfs:Class rdf:ID="UnambiguousProperty"> rdfs:labelUnambiguousProperty rdfs:comment if P is an UnambiguousProperty, then if P(x, y) and P(z, y) then x=z. aka injective. e.g. if firstBorne(m, Susan) and firstBorne(n, Susan) then m and n are the same. <rdfs:subClassOf rdf:resource="#ObjectProperty"/>

<rdfs:Class rdf:ID="List"> <rdfs:subClassOf rdf:resource="" title="undefined" rel="noopener noreferrer">http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq"/>

the empty list; this used to be called Empty.

<rdf:Property rdf:ID="first"> <rdfs:domain rdf:resource="#List"/>

<rdf:Property rdf:ID="rest"> <rdfs:domain rdf:resource="#List"/> <rdfs:range rdf:resource="#List"/>

<rdf:Property rdf:ID="item"> rdfs:comment for item(L, I) read: I is an item in L; either first(L, I) or item(R, I) where rest(L, R). <rdfs:domain rdf:resource="#List"/>

<rdfs:Class rdf:ID="Ontology"> rdfs:labelOntology rdfs:comment An Ontology is a document that describes a vocabulary of terms for communication between (human and) automated agents.

<rdf:Property rdf:ID="versionInfo"> rdfs:labelversionInfo rdfs:comment generally, a string giving information about this version; e.g. RCS/CVS keywords

<rdf:Property rdf:ID="imports"> rdfs:labelimports rdfs:comment for imports(X, Y) read: X imports Y; i.e. X asserts the* contents of Y by reference; i.e. if imports(X, Y) and you believe X and Y says something, then you should believe it. Note: "the contents" is, in the general case, an il-formed definite description. Different interactions with a resource may expose contents that vary with time, data format, preferred language, requestor credentials, etc. So for "the contents", read "any contents".

<rdf:Property rdf:ID="subPropertyOf">

<rdfs:Class rdf:ID="Literal">

<rdfs:Class rdf:ID="Property">

<rdf:Property rdf:ID="type">

<rdf:Property rdf:ID="value">

<rdf:Property rdf:ID="subClassOf">

<rdf:Property rdf:ID="domain">

<rdf:Property rdf:ID="range">

<rdf:Property rdf:ID="label">

<rdf:Property rdf:ID="comment">

<rdf:Property rdf:ID="seeAlso">

<rdf:Property rdf:ID="isDefinedBy"> <rdfs:subPropertyOf rdf:resource="#seeAlso"/>

Acknowledgments

The following individuals were also involved in preparing the DAML+OIL (March 2001) release. See individual documents and previous releases for additional information.

The contributions of participants on the www-rdf-logic@w3.orgemail list are also acknowledged.

This work was supported in part by the US Defense Advanced Research Projects Agency under the auspices of the DARPA Agent Markup Language (DAML) Project, Prof. James Hendler, program manager.