W3C

Web Ontology Language (OWL)
Reference Version 1.0

Editor's Draft document - no W3C status at this time

This version:
$Id: owl-ref-proposed.html,v 1.151 2003/01/22 06:17:53 mdean Exp $
Latest published version:
http://www.w3.org/TR/owl-ref/
Latest version:
http://www.daml.org/2002/06/webont/owl-ref-proposed
Previous version:
http://www.w3.org/TR/2002/WD-owl-ref-20021112/
Editors:
Mike Dean
Guus Schreiber

Abstract

The Web Ontology Language OWL is a semantic markup language for publishing and sharing ontologies on the World Wide Web. OWL is a vocabulary extension of RDF (the Resource Description Framework) and is derived from the DAML+OIL Web Ontology Language. This document contains a structured informal description of the full set of OWL language constructs and is meant to serve as a reference for OWL users who want to construct OWL ontologies.

Status of this document

This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference materials or to cite them as other than "work in progress." A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

This Working Draft corresponds to the OWL Web Ontology Language 1.0 specification, which is being developed by the W3C Web Ontology Working Group. This document has been produced as part of the W3C Semantic Web Activity (Activity Statement) following the procedures set out for the W3C Process. The goals of the Web Ontology working group are discussed in the Web Ontology Working Group charter.

There are no patent disclosures related to this work at the time of this writing.

Comments on this document should be sent to public-webont-comments@w3.org, a mailing list with a public archive. General discussion of related technology is welcome in www-rdf-logic.

Acknowledgments

Parts of this document are derived from the DAML+OIL (March 2001) Reference Description [DAML+OIL] which was subsequently submitted as a DAML+OIL W3C Note . The authors othis document were Dan Connolly, Frank van Harmelen, Jim Hendler, Ian Horrocks, Deborah McGuinness, Peter Patel-Schneider, and Lynn Andrea Stein. The sponsors of this document ans its predecessor documents are also gratefully acknowledged.

Jeremy Carrol, Peter Patel-Schneider, and Jim Hendler perovided substantive reviews and contributed text to this document.This document is the result of extensive discussions within the Web Ontology Working Group as a whole. The members of this working group were .... (@@ include member list)

Table of contents


1. Introductory remarks

1.1 Purpose of this document

This document gives a systematic, compact and informal description of all the modelling primitives of OWL, using the RDF/XML exchange syntax for OWL. We expect this document to serve as a reference guide for users of the OWL language. Readers unfamiliar with OWL may wish to first consult the OWL Overview document [OWL Overview], and subsequently the OWL Guide [OWL Guide] for a more narrative description of example uses of the language.

The normative reference on the precise syntax of the language constructs can be found in the machine-readable RDF Schema definition of OWL (included as Appendix B) and in the OWL Abstract Syntax and Semantics document [OWL AS&S]. The latter document also contains a precise definition of the meaning of the language constructs in the form of a model-theoretic semantics.

1.2 OWL Full/DL/Lite

As also discussed in the OWL Overview and OWL Guide documents, we distinguish between OWL Full, OWL DL and OWL Lite. In particular, the OWL language provides two specific subsets that we believe will be of great use to implementors and language users. OWL Lite was designed for easy implementation and to provide users with a functional subset that will get them started in the use of OWL. OWL Description Logic (OWL DL) was designed to support the existing Description Logic business segment and to provide a language subset that has desirable computational properties for reasoning systems. The complete OWL language (called OWL Full to distinguish it from the subsets) relaxes some of the constraints on OWL DL so as to make available features which may but of use to many database and knowledge representation systems, but which violate the constraints of description logic reasoners.

OWL Full and OWL DL support the same set of language constructs. Their difference lies in restrictions on the use of some of those features. OWL Full allows free mixing of OWL with RDF Schema and, like RDF Schema, does not enforce a strict separation of classes, properties, and individuals. OWL DL puts constraints on the mixing with RDF and requires disjointness of classes, properties and individuals. The main reason for having the OWL DL sublanguage is that tool builders have developed powerful reasoning systems which support ontologies constrained by the restrictions required for OWL DL. For the formal definitions of the differences between OWL Full and OWL DL the reader is referred to the Abstract Syntax and Semantics document [OWL AS&S]. Section "8. OWL Lite/DL/Full constructs" summarizes the differences between OWL Full and OWL DL.

OWL Lite is a sublanguage of OWL that supports only a subset of the OWL language constructs. OWL Lite is particularly targeted at tool builders, who want to support OWL, but want to start with a relatively simple basic set of language features. OWL Lite was designed to extend the modeling capabilities of RDFS by adding some common features used in extending vocabularies and thesauri into ontologies. OWL Lite also abides to the same semantic restrictions as OWL DL, allowing reasoning engines to guarantee certain desirable properties. A summary of the language constructs allowed in OWL Lite is given in Section "8.3 OWL Lite constructs". For a more formal description of the subset of OWL language constructs supported by OWL Lite the reader is referred to the Abstract Syntax and Semantics document [OWL AS&S].

1.3 OWL Syntax

The exchange syntax for OWL is the XML serialization of RDF (RDF/XML). The RDF/XML syntax is defined in the RDF/XML Syntax Specification (Revised) [RDF/XML Syntax].

An OWL ontology is thus in fact a set of RDF triples. As with any set of RDF triples, OWL triples can be represented in many different syntactic forms (as described in the RDF/XML Syntax Specification (Revised) [RDF/XML Syntax]). This document (as does the Guide document) uses some specific syntactic forms of RDF/XML for these triples. However, the meaning of an OWL ontology is solely determined by the resulting set of triples. Thus, it is allowed to use syntactic RDF forms other, as long as these result in the same underlying set of RDF triples. Such other syntactic forms would then carry exactly the same prescribed meaning as the syntactic form used in this document.

As a simple example of an alternative syntactic form resulting in the same set of RDF triples, consider the following syntactic form:

<owl:Class rdf:ID="Continent"/> 

The following RDF statement:

<rdf:Description rdf:about="#Continent">
  <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description> 

results in exactly the same set of RDF triples, and is therefore perfectly allowed as a class description.

1.4 OWL and RDF semantics

OWL is a vocabulary extension of RDF. Thus any RDF graph forms an OWL ontology. Further, the meaning given to an RDF graph by OWL includes the meaning given to the graph by RDF. OWL ontologies can thus include arbitrary RDF content, which is treated in a manner consistent with its treatment by RDF. As stated above, OWL assigns an additional meaning to certain RDF triples. The OWL Abstract Syntax and Semantics [OWL AS&S] specifies exactly which triples are assigned a specific meaning, and what this meaning is.

2. Language structure

An OWL ontology is generally written as a sequence of composite components involving particular OWL language constructs. Appendix A provides a listing of all of these language constructs. Throughout this document, OWL constructs will be presented in a structured RDF/XML format, and not as bare RDF triples. This structured RDF/XML format is more natural to read, but, as said before, any way of generating the same RDF triples as generated by the structured RDF format is equivalent.

Several language constructs employ the rdf:parseType="Collection" vocabulary (an addition in the revised RDF syntax specification) to describe collections of similar things, which would otherwise be difficult to represent in a triple format.

An OWL ontology consists of an optional ontology header and any number of class axioms, property axioms, and individual axioms. Please note that "axiom" is the formal term used in the AS&S document. These axioms are somewhat more informally called "definitions" in the Guide and Overview documents.

As with all RDF documents, the OWL code should be inside an <rdf:RDF> tag. The document can contain the usual XML entity and namespace declarations. For a typical XML header, see the wine.owl, containing the example ontology discussed in the Guide document.

Links in the text attached to definitions of language constructs provide access to the OWL Abstract Syntax and Semantics [OWL AS&S]. Appendix A contains a systematic set of links for each language construct to the corresponding section in the Guide and the AS&S document. Appendix C gives an overview of all OWL language constructs in terms of the built-in OWL classes and properties as defined in the owl.owl file (see Appendix B)

3. Ontology header

owl:Ontology

A ontology header component is represented with an instance of the class owl:Ontology, which identifies the containing document and which may optionally contain, in any order, any number of import and/or versioning statements.

A sample ontology header could look like this:

<owl:Ontology rdf:about="">
  <owl:versionInfo>$Id: owl-ref-proposed.html,v 1.151 2003/01/22 06:17:53 mdean Exp $
  </owl:versionInfo>
  <rdfs:comment>An example ontology</rdfs:comment>
  <owl:imports rdf:resource="http://www.w3.org/2002/07/owl"/>
</owl:Ontology>

The rdf:about="" refers to the current document. The following sections describe the various types of statements that can be used within the header.

owl:imports

An owl:imports statement references another OWL ontology containing definitions, whose meaning is considered to be part of the meaning of the importing ontology. Each reference consists of a URI specifying from where the ontology is to be imported. owl:imports statements are transitive, that is, if ontology A imports B, and B imports C, then A imports both B and C.

Importing an ontology into itself is considered a null action, so if ontology A imports B and B imports A, then they are considered to be equivalent.

Note that namespaces only provide a mechanism for creating unique names, and do not actually include definitions in the way that owl:imports does. Similarly, owl:imports statements do not set up a shorthand notation for names. Therefore, it is common to have corresponding namespace definitions and owl:imports statements.

If an OWL Lite ontology imports an OWL DL or OWL Full ontology, it effectively becomes an OWL DL or OWL Full ontology. Similarly, an OWL DL ontology that imports a OWL Full ontology becomes an OWL Full ontology.

owl:versionInfo

An owl:versionInfo statement generally contains a string giving information about this version, for example RCS/CVS keywords. This statement does not contribute to the logical meaning of the ontology other than that given by the RDF(S) model theory.

owl:priorVersion

An owl:priorVersion statement contains a reference to another ontology. This identifies the specified ontology as a prior version of the containing ontology. This has no meaning in the model-theoretic semantics other than that given by the RDF(S) model theory. However, it may be used by software to organize ontologies by versions.

owl:backwardCompatibleWith

An owl:backwardCompatibleWith statement contains a reference to another ontology. This identifies the specified ontology as a prior version of the containing ontology, and further indicates that it is backward compatible with it. In particular, this indicates that all identifiers from the previous version have the same intended interpretations in the new version. Thus, it is a hint to document authors that they can safely change their documents to commit to the new version (by simply updating namespace declarations and owl:imports statements to refer to the URL of the new version). If owl:backwardCompatibleWith is not declared for two versions, then compatibility should not be assumed. Like owl:priorVersion, this has no meaning in the model theoretic semantics other than that given by the RDF(S) model theory.

owl:incompatibleWith

An owl:incompatibleWith statement contains a reference to another ontology. This indicates that the containing ontology is a later version of the referenced ontology, but is not backward compatible with it. Essentially, this is for use by ontology authors who want to be explicit that documents cannot upgrade to use the new version without checking whether changes are required.

4. Classes

OWL classes are viewed as sets of individuals, These individuals are the instances of the class. In OWL Lite and OWL DL an individual can never be at the same time a class: classes and individuals form disjoint domains (as do properties). OWL Full allows the freedom of RDF Schema: a class may act as an instance of another (meta)class (the same holds for properties).

For understanding the OWL class constructs, the notion of a class as a set of members (individuals) is crucial. Almost all OWL definitions are expressed in terms of this set notion. Subclass relations imply subset relations. The meaning of the language constructs depends heavily on these notions. OWL's view of classes as sets and subclasses as subsets can be traced back to its origins in description logic. People familiar with data modelling but unfamiliar with description logic may initially have a hard time understanding the basic modelling approach. As a guideline, keep the following example in mind. Imagine you want to state that graduate courses must have a faculty member as a tutor. In the description logic way of thinking you express this as follows: "a GraduateCourse is a subclass of the class of things that have the class FacultyMember as value type for the CourseTutor relation". It means exactly the same thing, it's just a different way of saying it.

OWL classes are described through "class descriptions", which can be combined into "class axioms". We first describe class descriptions and subsequently turn to class axioms.

4.1 Class descriptions

A class description is the term used in this document (and in the OWL Abstract Syntax and Semantics) for the basic building blocks of class axioms (informally called class definitions in the Overview and Guide documents). OWL class descriptions can take six forms:

  1. a class name (indicated with a URI reference)
  2. an exhaustive enumeration of individuals that together form the instances of a class
  3. a property restriction
  4. the intersection of two or more class descriptions
  5. the union of two or more class descriptions
  6. the complement of a class description

The first form defines c.q. refers to a class name. The other five forms of class descriptions implicitly define an anonymous class, respectively the class that contains exactly the enumerated individuals (2nd form), the class of all instances which satisfy the property restriction (3rd form), or the class that satisfies boolean combinations of such descriptions (4th, 5th and 6th form). Intersection, union and complement can be respectively seen as the logical AND, OR and NOT operator. These three forms of class descriptions lead to nested class descriptions and can thus in theory lead to arbitrarily complex class descriptions. In practice, the level of nesting is usually limited.

Each of the different forms is discussed in more detail below.

Two OWL class names are predefined, namely the classes owl:Thing and owl:Nothing. Every individual is an instance of owl:Thing, and no individual is an instance of owl:Nothing. Consequently, every class is a subclass of owl:Thing and owl:Nothing is a subclass of every class.

4.1.1 Enumeration

A class description of the "enumeration" type is defined with the owl:oneOf statement, which contains a collection of individuals that are the instances of the class. This enables us to define a class by exhaustively enumerating its instances. The class defined by the owl:oneOf element contains exactly the enumerated elements, no more, no less. The collection is typically represented with the help of the RDF construct rdf:parseType="Collection", which provides a convenient shorthand for writing down a set of elements. For example, the following owl:oneOf statement defines the class of all continents:

<owl:Class>
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#Eurasia"/>
    <owl:Thing rdf:about="#Africa"/>
    <owl:Thing rdf:about="#NorthAmerica"/>
    <owl:Thing rdf:about="#SouthAmerica"/>
    <owl:Thing rdf:about="#Australia"/>
    <owl:Thing rdf:about="#Antarctica"/>
  </owl:oneOf>
</owl:Class>

A statement of the form <owl:Thing rdf:about="..."/> refers to some individual (all individuals are by definition instances of owl:Thing). Note that we have not given a name to this class. Class descriptions should be seen as the building blocks for class definitions (formally denoted as "class axioms"). In the section "Class axioms" we discuss how we can combine class descriptions in class axioms .

@@ Make a note here about OWL Full/DL differences here??

In the section on properties we will see another use of the owl:oneOf construct, namely to define an enumeration of data values.

4.1.2 Property restrictions

A property restriction is a special kind of class description. It implicitly defines an anonymous class, namely the class of all individuals that satisfy the restriction. There are two kinds of restrictions: value restrictions and cardinality restrictions.

A value restriction puts constraints on the value range of the property when applied to this particular class description. For example, we might want to say that for the class Region the value of the property adjacentTo should also be a Region. Note the difference with the RDF Schema construct rdfs:range, which applies to all situations in which the property is used.

A cardinality restriction puts constraints on the number of values a property can take, in the context of this particular class description. For example, we might want to say that for a soccer team the "hasPlayer" property has 11 values. For a basketball team the same property would have only 5 values.

OWL also supports a limited set of constructs for defining global property cardinality, namely the owl:FunctionalProperty and the owl:InverseFunctionalProperty definitions (see the section on properties).

Property restrictions have the following general format:

<owl:Restriction>
  <owl:onProperty rdf:resource="(some property)" />
  (one or more value and/or cardinality restrictions, see below)
</owl:Restriction>
@@ Note that only one value/cardinality restriction is allowed in a given Restriction.?!

owl:Restriction is defined as a subclass of owl:Class. A restriction is thus a special type of OWL class. A restriction class contains a statement linking the restriction to a particular property, using the owl:onProperty construct. The restriction class also contains a statements that can be used to specify value and/or cardinality restrictions on the property, e.g. that the cardinality of the property is exactly 1.

Property restrictions can be applied both to "datatype properties" (properties for which the range value is a data literal) and "object properties" (properties for which the range value is an individual). For more information about this distinction, see the section on properties.

4.1.2.1 Value restrictions
owl:allValuesFrom

An owl:allValuesFrom restriction contains either a class description or a data range and defines the class of all individuals for which the range values of the property under consideration all belong to this class description resp. the data range. In other words, it defines the class of individuals x for which it holds that if the pair (x,y) is an instance of P (the property concerned), then y should be an instance of the class description or a value in the data range, respectively.

A simple example:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:allValuesFrom rdf:resource="#Human"  />
</owl:Restriction>

This example describes the anonymous OWL class (set of individuals) for which it holds that the "hasParent" property has only range values of class "Human". Note that this class description does not state that the property always has range values of this class; just that this is true for individuals of the anonymous restriction class.

Notice that an owl:allValuesFrom restriction is analogous to the universal (for-all) quantifier of Predicate logic - for each instance of the class or datatype that is being defined, every value for P must fulfill the restriction. Also notice that the correspondence of owl:allValuesFrom with the universal quantifier means that an owl:allValuesFrom restriction for a property P is trivially satisfied for an individual that has no value for property P at all. To see why this is so, observe that the owl:allValuesFrom restriction demands that all values of P belong to class P, and if no such values exist, the restriction is trivially true.

owl:someValuesFrom

The value restriction owl:someValuesFrom contains a class description or a data range. An owl:someValuesFrom statement defines the class of all individuals for which at least one value of the property concerned is an instance of the class description or a data value in the data range. In other words, it defines the class of individuals x for which there is at least one y (either an instance of the class description or value of the data range) such that the pair (x,y) is an instance of P. This does not exclude that there are other instances (x,y') of P for which y' does not belong to the class description or data range.

The following example defines the class of individuals who have at least one parent who is a physician:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:someValuesFrom rdf:resource="#Physician" />
</owl:Restriction>

The owl:someValuesFrom restriction is analogous to the existential quantifier of Predicate logic - for each instance of the class or datatype that is being defined, there exists at least one value for P that fulfills the restriction.

owl:hasValue

An owl:hasValue restriction contains a reference to an individual or a datatype value. An owl:hasValue element defines the class of all objects for whom the property concerned has at least one value equal to the referenced individual or datatype value (but it may have other values as well).

The following example describes the class of individuals who have the individual referred to as "Clinton" as their parent:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:hasValue rdf:resource="#Clinton" />
</owl:Restriction>
4.1.2.2 Cardinality restrictions
The default cardinality of properties is "any". OWL provides three constructs for cardinality restrictions on properties.
owl:maxCardinality

An owl:maxCardinality restriction defines the class of all individuals that have at least N distinct individuals (or data values) for the property concerned, where N is the number specified between the begin and end owl:cardinality tag.

The following example describes the class of individuals that have at most two parents:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:maxCardinality>2</owl:maxCardinality>
</owl:Restriction>
owl:minCardinality

An owl:minCardinality restriction defines the class of individuals that have at most N distinct individuals / data values for the property concerned, where N is the number specified between the begin and end owl:cardinality tag.

The following example describes the class of individuals that have at least two parents:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:minCardinality>2</owl:minCardinality>
</owl:Restriction>
owl:cardinality

An owl:cardinality restriction defines the class of all individuals that have exactly N distinct individuals (or data values) for the property concerned, where N is the number specified between the begin and end owl:cardinality tag. This construct is in fact redundant as it can always be replaced by a pair of matching owl:minCardinality and owl:maxCardinality restrictions with the same value. It is included as a convenient shorthand for the user.

The following example describes the class of individuals that have exactly two parents:

<owl:Restriction>
  <owl:onProperty rdf:resource="#hasParent" />
  <owl:cardinality>2</owl:cardinality>
</owl:Restriction>

4.1.3 Intersection, union and complement

The three forms of class descriptions in this section represent the more advanced class constructors that are used in description logic. They can be viewed as representing the AND, OR and NOT operators on classes. As OWL views classes as sets of individuals, these operators get the standard set-operator names: intersection, union and complement. These language constructs share the characteristic that they contain one (complement) or more (union, intersection) nested class descriptions.

owl:intersectionOf

A class description of the form owl:intersectionOf contains a list of nested class descriptions. An intersection describes an anonymous class that consists of exactly those individuals that are common to all class descriptions in the list.

An example:

<owl:Class>
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Tosca" />
        <owl:Thing rdf:about="#Salome" />
      </owl:oneOf>
    </owl:Class>
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Turandot" />
        <owl:Thing rdf:about="#Tosca" />
      </owl:oneOf>
    </owl:Class>
  </owl:intersectionOf>
</owl:Class>

The sample intersection contains two enumerations, both describing a class with two individuals. The intersection is the class with the individual common to both enumerations, namely "Tosca".

owl:intersectionOf can be viewed as being analogous to logical conjunction.

owl:unionOf

A owl:unionOf class contains a list of class descriptions.. This describes the (anonymous) class that consists exactly of those individuals that belong to at least one of the class descriptions from the list.

An example:

<owl:Class>
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Tosca" />
        <owl:Thing rdf:about="#Salome" />
      </owl:oneOf>
    </owl:Class>
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Turandot" />
        <owl:Thing rdf:about="#Tosca" />
      </owl:oneOf>
    </owl:Class>
  </owl:unionOf>
</owl:Class>

This class description describes the class with the three individuals "Tosca", "Salome", and "Turandot" (sets do not contain duplicates).

owl:unionOf is analogous to logical disjunction.

owl:complementOf

A class description of the form owl:complementOf contains precisely one nested class description.. The owl:complementOf construct defines the class that consists of exactly those individuals that do not belong to the class description. owl:complementOf is analogous to logical negation, but restricted to individuals only.

Note that arbitrarily complex combinations of these descriptions can be formed. As an example of a combination of the set operators, the expression "neither meat nor fish" could be written as:

<owl:Class>
  <owl:complementOf>
    <owl:Class>
      <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:about="#Meat"/>
        <owl:Class rdf:about="#Fish"/>
      </owl:unionOf>
    </owl:Class>
  </owl:complementOf>
</owl:Class>
@@ Reconsider example, Peter said it was incorrect

4.2 Class axioms

Class descriptions form the building blocks for defining classes through class axioms. The simplest form of a class axiom just states the existence of a class, using owl:Class. For example, the following piece of OWL creates the URI reference "Human" and states that it is an OWL class name.
<owl:Class rdf:ID="Human"/>
This is correct OWL, but does not tell us very much about the class "Human". Class axioms typically contain additional components that state necessary and/or sufficient characteristics of a class. OWL contains three language constructs for such definitions: We discuss these three language constructs in more detail in the following subsections.
rdfs:subClassOf
Many typical class axioms in OWL are of the form: "some class name" rdfs:subClassOf "some class description". An example:
<owl:Class rdf:ID="Opera">
  <rdfs:subClassOf rdf:resource="#MusicalWork" />
</owl:Class>

This class axiom declares a subclass relation between two OWL classes that are described through their names ("Opera" and "MusicalWork"). Subclass relations provide necessary conditions for belonging to a class. In this case, to be an opera the individual also needs to be a musical work.

Class axioms can also use the other types of class descriptions, such as property restrictions, enumerations, intersections, unions and complements. The common format is: "some class name" rdfs:subClassOf "some class description". For any class there may be any number of subClassOf axioms. For example, we could add the following axiom about the class "Opera":

<owl:Class rdf:about="#Opera">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasLibrettist" />
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

This class axiom uses a property restriction. The example says that "Opera" is a subclass of an anonymous OWL class (remember: owl:Restriction is a subclass of owl:Class) that describes the class of individuals for which the property "hasLibrettist" has at least one value. In short, operas should have at least one librettist.

Note also the use of rdf:about instead of rdf:ID, which was used in the first example. Informally one could say that rdf:ID creates a URI reference for a resource, and that rdf:about refers to a URI reference. Therefore, it is common that the first axiom about a particular class uses the rdf:ID construct, and that subsequent axioms use the rdf:about construct.

A final point about the previous two examples is that multiple subclass axioms for the same class define in fact an intersection: the class at the lefthand side should be a subclass of both class descriptions. Thus, the following two class axioms are semantically equivalent (the latter is however not part of OWL Lite):

<owl:Class rdf:ID="Opera">
  <rdfs:subClassOf rdf:resource="#MusicalWork" />
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasLibrettist" />
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

<owl:Class rdf:ID="Opera">
  <rdfs:subClassOf>
    <owl:Class>
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Class rdf:about="#MusicalWork"/>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#hasLibrettist" />
          <owl:minCardinality>1</owl:minCardinality>
        </owl:Restriction>
      </owl:intersectionOf>
    </owl:Class>
  </rdfs:subClassOf>
</owl:Class>

The use of intersection (and union and complement) leads to nested class descriptions. Another form of nested class descriptions can occur when defining property restrictions with the owl:allValuesFrom or owl:someValuesFrom constructs, because these point to a class description. An example:

<owl:Class rdf:ID="TraditionalItalianOpera">
  <rdfs:subClassOf rdf:resource="#Opera"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasOperaType"/>
      <owl:someValuesFrom>
        <owl:Class>
          <owl:oneOf rdf:parseType="Collection">
            <owl:Thing rdf:about="#OperaSeria"/>
            <owl:Thing rdf:about="#OperaBuffa"/>
          </owl:oneOf>
        </owl:Class>
      </owl:someValuesFrom>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

This example shows the use of the owl:oneOf construct. The class axiom defines "traditional Italian opera" as a subclass of the class of operas that have as an "opera type" either "opera seria" or "opera buffa" (without a further cardinality restriction, it could actually also have both values).

More examples can be found in the Guide document and in the corresponding wine.owl file. Subclass axioms provide as with partial definitions: they represent necessary but not sufficient conditions for establishing class membership of an individual. In the next subsection we will see that for defining necessary and sufficient conditions OWL provides the owl:sameClassAs construct. As a stepping stone to such axioms, consider the following example:

<owl:Class rdf:ID="Operetta">
  <rdfs:subClassOf rdf:resource="#MusicalWork"/>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasLibrettist" />
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Class>
      <owl:complementOf rdf:resource="#Opera"/>
    </owl:Class>
  </rdfs:subClassOf> 
</owl:Class>

This class axiom states that an operetta is a musical work, that has a librettist and is not an opera. The use of the subclass relation leaves open the possibility that there are other musical works that have a librettist and are not operas. If we had wanted to say that operettas are exactly those musical works that have a librettist and are not operas, we need to use the owl:sameClassAs construct.

rdfs:sameClassAs

A class axiom may contain (multiple) owl:sameClassAs statements. The typical format of such a class axiom is: "some class name" owl:sameClassAs "some class description". The meaning of such an class axiom is that both classes have the same extension (i,e, they have exactly the same set of individuals).

In its simplest form, a same-class axiom states the equivalence of two named classes. This is typically used in ontology mapping to indicate that a class in one ontology is actually the same as a class in another ontology. (@@ make note about difference with sameAs). An example:

<owl:Class rdf:about="#FootballTeam">
  <owl:sameClassAs rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>

One could imagine this class axiom to be part of a European sports ontology, in which we want to say that the class "SoccerTeam" in another ontology is actually the same class.

owl:sameClassAs is also used to define enumerated classes: a class for which we can enumerate all individuals. An example:

<owl:Class rdf:ID="DaPonteOperaOfMozart">
  <owl:sameClassAs>
    <owl:Class>
      <owl:oneOf rdf:parseType="Collection">
        <owl:Thing rdf:about="#Nozze_di_Figaro"/>
        <owl:Thing rdf:about="#Don_Giovanni"/>
        <owl:Thing rdf:about="#Cosi_fan_tutte"/>
      </owl:oneOf>
    </owl:Class>
  </owl:sameClassAs>
</owl:Class>

This class axiom defines the class of individuals representing the Da Ponte operas of Mozart (a popular subject in musicology). By using the same-class construct we can state necessary and sufficient conditions for class membership, in this case consisting of an enumeration of three individuals, no less, no more.

It is possible to have multiple same-class axioms about the same class name. However, this requires great care. Both axioms must led to the same outcome. ie. exactly the same set of individuals. For example, an alternate same-class axiom for the Da Ponte operas could be the following one:

<owl:Class rdf:about="#DaPonteOperaOfMozart">
  <owl:sameClassAs>
    <owl:Class>
      <owl:intersectionOf rdf:parseType="Collection">
        <owl:Restriction>
          <owl:onProperty rdf:resource="#hasComposer"/>
          <owl:hasValue rdf:resource="#Wolfgang_Amadeus_Mozart"/>
        </owl:Restriction>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#hasLibrettist"/>
          <owl:hasValue rdf:resource="#Lorenzo_Da_Ponte"/>
        </owl:Restriction>
      </owl:intersectionOf>
    </owl:Class>
  </owl:sameClassAs>
</owl:Class>

So, this class corresponds to exactly those operas which are composed by Mozart and for which the libretto is written by Da Ponte (note: intersection = "and"). This denotes indeed the same set of individuals as the previous axiom. Note that if we also had a class axiom such as:

<owl:Class rdf:about="#DaPonteOperaOfMozart">
  <rdfs:subClassOf rdf:resource="#Opera"/>
</owl:Class>

we would have to make sure that all instances of the class as defined earlier are indeed operas (the class name suggests this is true, but that has no semantic meaning).

OWL allows users to define class axioms with an implicit same-class statement. For example, the first class axiom could also have been written down as:

<owl:Class rdf:ID="DaPonteOperaOfMozart">
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#Nozze_di_Figaro"/>
    <owl:Thing rdf:about="#Don_Giovanni"/>
    <owl:Thing rdf:about="#Cosi_fan_tutte"/>
  </owl:oneOf>
</owl:Class>

This class axiom should be read as the class "DaPonteOperaOfMozart" is exactly defined by the enumeration. It is semantically equivalent to the version with the owl:sameClassAs statement, but this shorthand may be more intuitive for some users. Another example of this form could be:

<owl:Class rdf:ID="LivingBeing">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Plant"/>
    <owl:Class rdf:about="#Animal"/>
  </owl:unionOf>
</owl:Class>

This class axiom states that the class of living beings exactly corresponds to the union of plants and animals.

@@ Guideline about explicit vs. implicit form??

Note: RDFS and OWL allow cycles of subclass relationships as a means to assert equality between classes. Thus, if we state that A is a subclass of B and vice versa, then A is the same class as B.

owl:disjointWith

A class axiom may also contain (multiple) owl:disjointWith statements. The typical format of such axioms is similar to the previous ones, namely: Each owl:disjointWith statement asserts the two class description involved have no class instances in common. Like axioms with rdfs:subClassOf, declaring two classes to be disjoint is a partial definition: they impose necessary but not sufficient conditions on the class. This is a popular example:

<owl:Class rdf:about="Man">
  <owl:disjointWith rdf:resource="#Woman"/>
</owl:Class>

although whether this is always true is a matter for biologists to decide. The following example shows a common use of class disjointness in subclass hierarchies:

<owl:Class rdf:about="MusicDrama">
  <owl:sameClassAs>
    <owl:Class>
      <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:about="#Opera"/>
        <owl:Class rdf:about="#Operetta"/>
        <owl:Class rdf:about="#Musical"/>
      </owl:unionOf>
    </owl:Class>
  </owl:sameClassAs>
</owl:Class>

<owl:Class rdf:about="#Opera">
  <rdfs:subClassOf rdf:resource="#MusicDrama"/>
</owl:Class>

<owl:Class rdf:about="#Operetta">
  <rdfs:subClassOf rdf:resource="#MusicDrama"/>
  <owl:disjointWith rdf:resource="#Opera"/>
</owl:Class>

<owl:Class rdf:about="#Musical">
  <rdfs:subClassOf rdf:resource="#MusicDrama"/>
  <owl:disjointWith rdf:resource="#Opera"/>
  <owl:disjointWith rdf:resource="#Operetta"/>
</owl:Class>

owl:disjointWith can be used together with owl:unionOf to define a set of mutually disjoint and complete subclasses of a superclass.

5. Properties

OWL distinguishes between two types of properties:

An object property is defined with the help of an owl:ObjectProperty construct. A datatype property is defined through an owl:DatatypeProperty construct. Both owl:ObjectProperty and owl:DatatypeProperty are subclasses of the RDF class rdf:Property (see Appendix B).

[Advanced note: In OWL Full, object properties and datatype properties are not disjoint. Because data values can be treated as individuals, datatype properties are effectively subclasses of object properties. In practice, this has only consequences for the use of owl:InverseFunctionalProperty. See also the OWL Full characterization in Section 8.1.]

A property axiom is typically contained within an owl:ObjectProperty c.q. owl:DatatypeProperty component. The axiom usually defines/references a property name, and may include the following additional components (any number, any order):

In the next subsections, these property-related language constructs are discussed in more detail.

5.1 RDF Schema property constructs

rdfs:subPropertyOf

A rdfs:subPropertyOf statement defines that the property is a subproperty of some other property. Formally this means that every pair (x,y) that is an instance of the subproperty is also an instance of the superproperty.

An example:

<owl:ObjectProperty rdf:ID="hasMother">
  <rdfs:subPropertyOf rdf:resource="#hasParent"/>
</owl:ObjectProperty>

This says that all instances (pairs) of the property "hasMother" are also instances of the property "hasParent".

rdfs:domain

For a property one can define (multiple) rdfs:domain statements. Each domain statement points to a class description. The meaning is the same as in RDF Schema: an rdfs:domain statement asserts that the domain of the property consists of those individuals that are instances of the class description.

Multiple rdfs;domain statements are allowed and should be interpreted as a conjunction: these restrict the domain of the property to those individuals that belong to the intersection of the class descriptions. If one would want to say that multiple classes can act as domain, one should use a class description of the owl:unionOf form. For example, if we want to say that the domain of the property "hasBankAccount" can be either a "Person" or a "Corporation", we would need to say something like this:

<owl:ObjectProperty rdf:ID="hasBankAccount">
  <rdfs:domain>
    <owlClass>    
      <owl:unionOf rdf:parseType="Collection">
        <owl:Class rdf:about="#Person"/>
        <owl:Class rdf:about="#Corporation"/>
      </owl:unionOf>
    </owlClass>    
  </rdfs:domain>
</owl:ObjectProperty>

The rdfs:domain restrictions are global, meaning that they cannot be used for an individual for which the class is not explicitly included in the domain restriction. Because of this feature, rdfs:range statements should be used with care.

rdfs:range

An rdfs:range statement points to a class description or to a data range. Each rdfs:range statement asserts that the property only takes range values that are instances of the class description c.q. data values belonging to the data range. Multiple range restrictions are interpreted as stating that the range of the property is the intersection of all ranges (i.e., intersection of the class descriptions c.q. intersection of the data ranges). Similar to rdfs:domain, multiple disjoint ranges can be specified by using a class description of the owl:unionOf form (see the previous subsection).

Note that unlike any of the value restrictions mentioned earlier, rdfs:range restrictions are global. The property restrictions constitute a class description and are only enforced on the property when applied to that class. In contrast, rdfs:range restrictions apply to the property irrespective of the class to which it is applied. This is by virtue of their semantics in RDF Schema. Thus, rdfs:range should be used with care.

5.2 Relations to other properties

owl:samePropertyAs

An owl:samePropertyAs statement points to another property. A statement of the form P1 owl:samePropertyAs P2 asserts that P1 is equivalent to P2, i.e. P1 and P2 have exactly the same instances (pairs). This is typically used in ontology mapping to indicate that two properties with different names refer to the same notion.

owl:inverseOf

An owl:inverseOf statement points to another property that is its inverse. A statement of the form P1 owl:inverseOf P2 asserts that P1 is the inverse relation of P2. For example, the property "owns" could be defined as the inverse of "ownedBy". More formally: if P1 is the inverse of P2, then for every pair (x,y) which is an instance of P1, there is also a pair (y,x) which is an instance of P2.

The owl:inverseOf construct only makes sense when applied to object properties, as both the domain and the range of the property must be classes.

5.3 Global cardinality restrictions on properties

owl:FunctionalProperty

OWL defines the class owl:FunctionalProperty as a special subclass of the RDF class rdf:Property. This asserts that the property can only have one (unique) value y for each instance x, i.e. there cannot be two distinct range values y1 and y2 such that the pairs (x,y1) and (x,y2) are both instances of this property. This corresponds to the notion of "optional" value encountered in many data-modelling notations.

There are two typical syntactic variations for writing down functional properties:

<owl:FunctionalProperty rdf:ID="husband">
  <rdfs:domain rdf:resource="#Woman" />
  <rdfs:range  rdf:resource="#Man" />
</owl:FunctionalProperty>

<owl:ObjectProperty rdf:ID="husband">
  <rdf:type    rdf:resource="&owl;FunctionalProperty" />
  <rdfs:domain rdf:resource="#Woman" />
  <rdfs:range  rdf:resource="#Man" />
</owl:ObjectProperty>

The only difference between the two examples is that the second property axiom gives rise to one additional triple, namely that the property "husband" is an object property. As always, there are many other syntactic variations. For example, the second example above is semantically equal to the one below:

<owl:ObjectProperty rdf:ID="husband">
  <rdfs:domain rdf:resource="#Woman" />
  <rdfs:range  rdf:resource="#Man" />
</owl:ObjectProperty>

<owl:FunctionalProperty rdf:about="#husband" />

owl:InverseFunctionalProperty

The construct owl:InverseFunctionalProperty is, as a subclass of the OWL class owl:ObjectProperty. For an inverse-functional property, a range value uniquely determines the domain value (some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a range value y can only be the value of P for a single instance x, i.e. there cannot be two distinct instances x1 and x2 such that both pairs (x1,y) and (x2,y) are instances of P.

[Advanced note: Because in OWL Full datatype properties are a subclass of object properties, an inverse-functional property can be defined for datatype properties. In OWL DL object properties and datatype properties are disjoint, so the inverse-functional property cannot be defined for datatype properties. See also Sections 8.1 and 8.2.]

A typical example of an inverse-functional property:

<owl:InverseFunctionalProperty rdf:ID="hasSocialSecurityNumber">
  <rdfs:domain rdf:resource="Person"/>
</owl:InverseFunctionalProperty>

This example corresponds to our intuition that every social security number should uniquely identify a human individual (whether that is really always true is another matter). Inverse-functional properties resemble the notion of a key in databases.

Notice that owl:FunctionalProperty and owl:InverseFunctionalProperty specify global cardinality restrictions. That is, no matter which class the property is applied to, the cardinality constraints must hold. This is different from the cardinality constraints contained in property restrictions. The latter are class descriptions and are only enforced on the property when applied to that class.

5.4 Logical characteristics of properties

owl:TransitiveProperty

The OWL property class owl:TransitiveProperty is a subclass of owl:ObjectProperty. When one defines a property P to be a transitive property, this means that if a pair (x,y) is an instance of P, and the pair (y,z) is also instance of P, then we can infer the the pair (x,z) is also an instance of P. Properties representing certain part-whole relations are frequently encountered examples of transitive behavior. For example, we might want to say that the "subRegionOf" property between regions is transitive:

<owl:TransitiveProperty rdf:ID="subRegionOf">
  <rdfs:domain rdf:resource="#Region"/>
  <rdfs:range  rdf:resource="#Region"/>
</owl:TransitiveProperty>

From this an OWL reasoner should be able to derive that if "Chianti Classico", "Tuscany" and "Italy" are regions, and "Chianti Classico" is a subregion of "Tuscany", and "Tuscany" is a subregion of "Italy", then "Chianti Classico" is also a subregion of "Italy".

Note that because owl:TransitiveProperty is a subclass of owl:ObjectProperty, the following syntactic variant is equivalent to the example above:

<owl:ObjectProperty rdf:ID="subRegionOf">
  <rdf:type rdf:resource="&owl;TransitiveProperty"/>
  <rdfs:domain rdf:resource="#Region"/>
  <rdfs:range  rdf:resource="#Region"/>
</owl:ObjectProperty>

Note also the difference with functional and inverse-functional properties, which can be both object and datatype properties.

owl:SymmetricProperty

The OWL property class owl:SymmetricProperty is, like owl:TransitiveProperty, a subclass of owl:ObjectProperty. A symmetric property is a property for which it holds that if the pair (x,y) is an instance of P, then the pair (y,x) is also an instance of P.

A popular example of a symmetric property is the "friendOf" relation:

<owl:SymmetricProperty rdf:ID="friendOf">
  <rdfs:domain rdf:resource="#Human"/>
  <rdfs:range  rdf:resource="#Human"/>
</owl:SymmetricProperty>

Symmetric properties should have identical domains and ranges to make sense (although we might want to extend the definition in the example to include also (other) animals).

@@ Is this a hard constraint in OWL??

6. Individuals

@@ still needs to be updated.

7. Datatypes

OWL also allows the use of XML Schema datatypes to describe (or define) part of the datatype domain. @@ update this with link to relevant RDF document plus example. Also include link to the table of datatypes in the Guide (or duplicate this table?).

8. OWL Full, OWL DL and OWL Lite

In the introduction we briefly discussed the three sublanguages of OWL. In this section a informal specification is given of each of the three "species" of OWL. A formal account of the differences is given in the Abstract Syntax and Semantics document [OWL AS&S].

If an OWL Lite ontology imports an OWL DL or OWL Full ontology, it effectively becomes an OWL DL resp. OWL Full ontology. In a similar vein, an OWL DL ontology that imports a OWL Full ontology becomes an OWL Full ontology.

8.1 OWL Full

OWL Full is not actually a sublanguage. OWL Full contains all the OWL language constructs and provides free, unconstrained mixing of OWL and RDF. The construct <owl:Class> is equivalent to <rdfs:Class>. This is different from OWL DL and OWL Lite, where <owl:Class> is a subclass of <rdfs:Class> (meaning that not all RDF classes are OWL classes). OWL Full also allows classes to be treated as individuals. For example, it is perfectly legal in OWL Full to have a "Fokker-100" identifier which acts both as a class name (denoting the set of Fokker-100 airplanes flying around the world) and as an individual name (e.g. an instance of the class "AirplaneType").

In OWL Full all data values are considered to be also part of the individual domain. This means that object properties and datatype properties are not disjoint. In OWL Full owl:ObjectProperty is the same class as rdf:Property. The consequence is that datatype properties are effectively a subclass of object properties (note that the definitions in owl.owl that owl:ObjectProperty and owl:DatatypeProperty are both subclasses of rdf:Property is not inconsistent with this). Although from the semantics point of view it is not forbidden to declare datatype properties to be inverse, transitive, or symmetric, in practice this does not make much sense (RDF does not allow data values as the subject of a statement). However, for inverse-functional properties this does make sense and such a definition is thus explicitly allowed in OWL Full.

OWL Full will typically be useful for people who want to combine the expressivity of OWL with the flexibility and metamodelling features of RDF. However, use of the OWL Full features means that one loses some guarantees (see below) that OWL DL and OWL Lite can provide for reasoning systems.

8.2 OWL DL

OWL DL is a sublanguage of OWL which places a number of constraints on the use of the OWL language constructs. Briefly, these constraints are the following:

The last constraint implies that all classes and properties that one refers to are explicitly defined as OWL classes or properties, respectively. For example, if the ontology contains the following component:

<owl:Class rdf:ID="C1">
  <rdfs:subClassOf rdf:about="#C2" />
</owl:Class>

then the ontology should also contain a class axiom for "C2".

@@ Should C2 be an owl:Class to be in OWL DL?

These constraints of OWL DL may seem like an arbitrary set, but in fact they are not. The constraints are based on work in the area of reasoners for description logic, which require these restriction to provide the ontology builder or user with reasoning support. In particular, the OWL DL restrictions allow the maximal subset of OWL Full against which current research can assure that a decidable reasoning procedure can exist for an OWL reasoner.

8.3 OWL Lite

OWL Lite abides to all the restrictions OWL DL puts on the use of the OWL language constructs. In addition, OWL Lite puts the following restrictions on the use of the OWL vocabulary:

The idea behind the OWL Lite restrictions is that they provide a minimal useful subset of language features, that are relatively straightforward for tool developers to support. The language constructs of OWL Lite provide the basics for subclass hierarchy construction: subclasses, value and cardinality restrictions, plus some mapping constructs (in particular sameClassAs). In addition, OWL Lite allows properties to be made optional or required (using the cardinality features).

OWL Lite is constrained to be a subset of OWL DL, thus assuring it retains the desirable reasoning features of that sublanguage. In addition, implementations that support only the OWL Lite vocabulary, but otherwise relax the restrictions of OWL DL, cannot make certain computational claims with respect to consistency and complexity. However, such implementations may be useful in providing interoperability of OWL systems with databases, markup tools, or other non-reasoning tools. The Web Ontology Working Group has not designed a specific such subset or provided a name for it.

9. Class and property deprecation

Deprecation is a feature commonly used in versioning software (for example, see the Java programming language) to indicate that a particular feature is preserved for backward-compatibility purposes, but may be phased out in the future. Here, a specific identifier is said to be of type owl:DeprecatedClass or owl:DeprecatedProperty, where owl:DeprecatedClass is a subclass of rdfs:Class and owl:DeprecatedProperty is a subclass of rdf:Property. By deprecating a term, it means that the term should not be used in new documents that commit to the ontology. This allows an ontology to maintain backward-compatibility while phasing out an old vocabulary (thus, it only makes sense to use deprecation in combination with backward compatibility). As a result, it it easier for old data and applications to migrate to a new version, and thus can increase the level of adoption of the new version. Once again, this has no meaning in the model theoretic semantics other than that given by the RDF(S) model theory. However, authoring tools may use it to warn users when checking OWL markup.

An example of deprecation is:

<owl:Ontology rdf:about="">
  <rdfs:comment>Vehicle Ontology, v. 1.1</rdfs:comment>
  <owl:backwardCompatibleWith rdf:resource="http://www.example.org/vehicle-1.0"/>
  <owl:priorVersion rdf:resource="http://www.example.org/vehicle-1.0"/>
</owl:Ontology>

<owl:DeprecatedClass rdf:ID="Car">
  <rdfs:comment>Automobile is now preferred</rdfs:comment>
</owl:DeprecatedClass>

<owl:Class rdf:ID="Automobile">
  <owl:sameClassAs rdf:resource="#Car"/>
  <!-- note that sameClass only means that the classes have the same
   extension, so this DOES NOT lead to the entailment that
   Automobile is of type DeprecatedClass too -->	
</owl:Class>

<owl:DeprecatedProperty rdf:ID="hasDriver">
  <rdfs:comment>inverse property drives is now preferred</rdfs:comment>
</owl:DeprecatedProperty>

<owl:ObjectProperty rdf:ID="drives">
  <owl:inverseOf rdf:resource="#hasDriver"/>
</owl:ObjectProperty>

Appendix A. Index of all language elements

[OWL Reference]
(this document)
[OWL Abstract Syntax]
(normative)
[OWL Guide]
(examples)
owl:AllDifferentFrom owl:AllDifferentFrom owl:AllDifferentFrom
owl:allValuesFrom owl:allValuesFrom owl:allValuesFrom
owl:backwardCompatibleWith owl:backwardCompatibleWith owl:backwardCompatibleWith
owl:cardinality owl:cardinality owl:cardinality
owl:Class owl:Class owl:Class
owl:complementOf owl:complementOf owl:complementOf
rdfs:Datatype
owl:DatatypeProperty owl:DatatypeProperty owl:DatatypeProperty
owl:DeprecatedClass owl:DeprecatedClass owl:DeprecatedClass
owl:DeprecatedProperty owl:DeprecatedProperty owl:DeprecatedProperty
owl:differentFrom owl:differentFrom owl:differentFrom
owl:disjointWith owl:disjointWith owl:disjointWith
owl:distinctMembers owl:distinctMembers owl:distinctMembers
rdfs:domain
owl:FunctionalProperty owl:FunctionalProperty owl:FunctionalProperty
owl:hasValue owl:hasValue owl:hasValue
owl:imports owl:imports owl:imports
owl:incompatibleWith owl:incompatibleWith owl:incompatibleWith
owl:intersectionOf owl:intersectionOf owl:intersectionOf
owl:InverseFunctionalProperty owl:InverseFunctionalProperty owl:InverseFunctionalProperty
owl:inverseOf owl:inverseOf owl:inverseOf
owl:maxCardinality owl:maxCardinality owl:maxCardinality
owl:minCardinality owl:minCardinality owl:minCardinality
owl:Nothing owl:Nothing owl:Nothing
owl:ObjectProperty owl:ObjectProperty owl:ObjectProperty
owl:oneOf owl:oneOf owl:oneOf
owl:onProperty owl:onProperty owl:onProperty
owl:Ontology owl:Ontology owl:Ontology
owl:priorVersion owl:priorVersion owl:priorVersion
rdf:Property
rdfs:range
owl:Restriction owl:Restriction owl:Restriction
owl:sameAs owl:sameAs owl:sameAs
owl:sameClassAs owl:sameClassAs owl:sameClassAs
owl:sameIndividualAs owl:sameIndividualAs owl:sameIndividualAs
owl:samePropertyAs owl:samePropertyAs owl:samePropertyAs
owl:someValuesFrom owl:someValuesFrom owl:someValuesFrom
rdfs:subClassOf
rdfs:subPropertyOf
owl:SymmetricProperty owl:SymmetricProperty owl:SymmetricProperty
owl:Thing owl:Thing owl:Thing
owl:TransitiveProperty owl:TransitiveProperty owl:TransitiveProperty
owl:unionOf owl:unionOf owl:unionOf
owl:versionInfo owl:versionInfo owl:versionInfo

Appendix B. http://www.w3.org/2002/07/owl

<?xml version="1.0"?>
<!DOCTYPE owl [
     <!ENTITY rdf  "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
     <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
     <!ENTITY xsd  "http://www.w3.org/2001/XMLSchema#" >
     <!ENTITY owl  "http://www.w3.org/2002/07/owl#" >
   ]>

<rdf:RDF
  xmlns     ="&owl;"
  xmlns:owl ="&owl;"
  xml:base  ="http://www.w3.org/2002/07/owl"
  xmlns:rdf ="&rdf;"
  xmlns:rdfs="&rdfs;"
  xmlns:dc  ="http://purl.org/dc/elements/1.1/"
>

<Ontology rdf:about="">
  <versionInfo>
    $Id: owl.owl,v 1.23 2003/01/17 00:08:11 mdean Exp $
  </versionInfo>
  <imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/>
  <dc:title>OWL Web Ontology Language</dc:title>
  <dc:creator>W3C Web Ontology (WebOnt) Working Group</dc:creator>
  <dc:subject>OWL; Web Ontology Language; Semantic Web</dc:subject>
  <dc:description>Classes and properties for the OWL Web Ontology 
    Language
  </dc:description>
  <dc:publisher>W3C</dc:publisher>
  <dc:date>2003-01-15</dc:date>
  <dc:format>text/xml</dc:format>
  <dc:language>en</dc:language>
  <dc:identifier>http://www.w3.org/2002/07/owl</dc:identifier>
</Ontology>

<rdfs:Class rdf:ID="Class">
  <rdfs:label>Class</rdfs:label>
  <rdfs:subClassOf rdf:resource="&rdfs;Class"/>
</rdfs:Class>

<Class rdf:ID="Thing">
  <rdfs:label>Thing</rdfs:label>
  <unionOf rdf:parseType="Collection">
    <Class rdf:about="#Nothing"/>
    <Class>
      <complementOf rdf:resource="#Nothing"/>
    </Class>
  </unionOf>
</Class>

<Class rdf:ID="Nothing">
  <rdfs:label>Nothing</rdfs:label>
  <complementOf rdf:resource="#Thing"/>
</Class>

<rdf:Property rdf:ID="sameClassAs">
  <rdfs:label>sameClassAs</rdfs:label>
  <rdfs:subPropertyOf rdf:resource="&rdfs;subClassOf"/>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="#Class"/>
</rdf:Property>

<rdf:Property rdf:ID="disjointWith">
  <rdfs:label>disjointWith</rdfs:label>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="#Class"/>
</rdf:Property>

<rdf:Property rdf:ID="samePropertyAs">
  <rdfs:label>samePropertyAs</rdfs:label>
  <rdfs:subPropertyOf rdf:resource="&rdfs;subPropertyOf"/>
</rdf:Property>

<rdf:Property rdf:ID="sameIndividualAs">
  <rdfs:label>sameIndividualAs</rdfs:label>
  <rdfs:domain rdf:resource="#Thing"/>
  <rdfs:range rdf:resource="#Thing"/>
</rdf:Property>

<rdf:Property rdf:ID="sameAs"> 
  <rdfs:label>sameAs</rdfs:label>
  <samePropertyAs rdf:resource="#sameIndividualAs"/>
</rdf:Property>

<rdf:Property rdf:ID="differentFrom">
  <rdfs:label>differentFrom</rdfs:label>
  <rdfs:domain rdf:resource="#Thing"/>
  <rdfs:range rdf:resource="#Thing"/>
</rdf:Property>

<rdfs:Class rdf:ID="AllDifferent">
  <rdfs:label>AllDifferent</rdfs:label>
</rdfs:Class>

<rdf:Property rdf:ID="distinctMembers">
  <rdfs:label>distinctMembers</rdfs:label>
  <rdfs:domain rdf:resource="#AllDifferent"/>
  <rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>
  
<rdf:Property rdf:ID="unionOf">
  <rdfs:label>unionOf</rdfs:label>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>

<rdf:Property rdf:ID="intersectionOf">
  <rdfs:label>intersectionOf</rdfs:label>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>

<rdf:Property rdf:ID="complementOf">
  <rdfs:label>complementOf</rdfs:label>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="#Class"/>
</rdf:Property>

<rdf:Property rdf:ID="oneOf">
  <rdfs:label>oneOf</rdfs:label>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="&rdf;List"/>
</rdf:Property>

<rdfs:Class rdf:ID="Restriction">
  <rdfs:label>Restriction</rdfs:label>
  <rdfs:subClassOf rdf:resource="#Class"/>
</rdfs:Class>

<rdf:Property rdf:ID="onProperty">
  <rdfs:label>onProperty</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&rdf;Property"/>
</rdf:Property>

<rdf:Property rdf:ID="allValuesFrom">
  <rdfs:label>allValuesFrom</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&rdfs;Class"/>
</rdf:Property>

<rdf:Property rdf:ID="someValuesFrom">
  <rdfs:label>someValuesFrom</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&rdfs;Class"/>
</rdf:Property>

<rdf:Property rdf:ID="hasValue">
  <rdfs:label>hasValue</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
</rdf:Property>

<rdf:Property rdf:ID="minCardinality">
  <rdfs:label>minCardinality</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>

<rdf:Property rdf:ID="maxCardinality">
  <rdfs:label>maxCardinality</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>

<rdf:Property rdf:ID="cardinality">
  <rdfs:label>cardinality</rdfs:label>
  <rdfs:domain rdf:resource="#Restriction"/>
  <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/>
</rdf:Property>

<rdfs:Class rdf:ID="ObjectProperty">
  <rdfs:label>ObjectProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>

<rdfs:Class rdf:ID="DatatypeProperty">
  <rdfs:label>DatatypeProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>

<rdf:Property rdf:ID="inverseOf">
  <rdfs:label>inverseOf</rdfs:label>
  <rdfs:domain rdf:resource="#ObjectProperty"/>
  <rdfs:range rdf:resource="#ObjectProperty"/>
</rdf:Property>

<rdfs:Class rdf:ID="TransitiveProperty">
  <rdfs:label>TransitiveProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="#ObjectProperty"/>
</rdfs:Class>

<rdfs:Class rdf:ID="SymmetricProperty">
  <rdfs:label>SymmetricProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="#ObjectProperty"/>
</rdfs:Class>

<rdfs:Class rdf:ID="FunctionalProperty">
  <rdfs:label>FunctionalProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>

<rdfs:Class rdf:ID="InverseFunctionalProperty">
  <rdfs:label>InverseFunctionalProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="#ObjectProperty"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Ontology">
  <rdfs:label>Ontology</rdfs:label>
</rdfs:Class>

<rdf:Property rdf:ID="imports">
  <rdfs:label>imports</rdfs:label>
  <rdfs:domain rdf:resource="#Ontology"/>
</rdf:Property>

<rdf:Property rdf:ID="versionInfo">
  <rdfs:label>versionInfo</rdfs:label>
</rdf:Property>

<rdf:Property rdf:ID="priorVersion">
  <rdfs:label>priorVersion</rdfs:label>
  <rdfs:domain rdf:resource="#Ontology"/>
  <rdfs:range rdf:resource="#Ontology"/>
</rdf:Property>

<rdf:Property rdf:ID="backwardCompatibleWith">
  <rdfs:label>backwardCompatibleWith</rdfs:label>
  <rdfs:subPropertyOf rdf:resource="#priorVersion"/>
</rdf:Property>

<rdf:Property rdf:ID="incompatibleWith">
  <rdfs:label>incompatibleWith</rdfs:label>
  <rdfs:subPropertyOf rdf:resource="#priorVersion" />
</rdf:Property>

<rdfs:Class rdf:ID="DeprecatedClass">
  <rdfs:label>DeprecatedClass</rdfs:label>
  <rdfs:subClassOf rdf:resource="#Class"/>
</rdfs:Class>

<rdfs:Class rdf:ID="DeprecatedProperty">
  <rdfs:label>DeprecatedProperty</rdfs:label>
  <rdfs:subClassOf rdf:resource="&rdf;Property"/>
</rdfs:Class>

</rdf:RDF>

Appendix C. OWL Quick Reference

Classes defined by OWL:
rdfs:Class
owl:AllDifferentFrom
owl:Class
owl:DatatypeProperty
owl:DeprecatedClass
owl:DeprecatedProperty
owl:FunctionalProperty
owl:InverseFunctionalProperty
owl:Nothing
owl:ObjectProperty
owl:Ontology
owl:Restriction
owl:SymmetricProperty
owl:Thing

Properties defined by OWL:

rdf:Property rdfs:domain rdfs:range
owl:allValuesFrom owl:Restriction rdfs:Class
owl:backwardCompatibleWith owl:Ontology owl:Ontology
owl:cardinality owl:Restriction xsd:nonNegativeInteger
owl:complementOf owl:Class owl:Class
owl:differentFrom owl:Thing owl:Thing
owl:disjointWith owl:Class owl:Class
owl:distinctMembers owl:AllDifferentFrom rdf:List
owl:hasValue owl:Restriction
owl:imports owl:Ontology
owl:incompatibleWith owl:Ontology owl:Ontology
owl:intersectionOf owl:Class rdf:List
owl:inverseOf owl:ObjectProperty owl:ObjectProperty
owl:maxCardinality owl:Restriction xsd:nonNegativeInteger
owl:minCardinality owl:Restriction xsd:nonNegativeInteger
owl:oneOf owl:Class rdf:List
owl:onProperty owl:Restriction rdf:Property
owl:priorVersion owl:Ontology owl:Ontology
owl:sameAs owl:Thing owl:Thing
owl:sameClassAs owl:Class owl:Class
owl:sameIndividualAs owl:Thing owl:Thing
owl:samePropertyAs rdf:Property rdf:Property
owl:someValuesFrom owl:Restriction rdfs:Class
owl:unionOf owl:Class rdf:List
owl:versionInfo

Appendix D. Changes from DAML+OIL

@@To be updated (GS)

This section summarizes the changes from DAML+OIL [DAML+OIL] to OWL.

  1. The namespace was changed to http://www.w3.org/2002/07/owl.
  2. Various updates to RDF and RDF Schema from the RDF Core Working Group were incorporated, including
  3. Qualified restrictions were removed from the language, resulting in the removal of the following properties:
  4. Various properties and classes were renamed, as shown in the following table:
    DAML+OIL OWL
    daml:differentIndividualFrom owl:differentFrom
    daml:hasClass owl:someValuesFrom
    daml:toClass owl:allValuesFrom
    daml:UnambiguousProperty owl:InverseFunctionalProperty
    daml:UniqueProperty owl:FunctionalProperty
  5. owl:SymmetricProperty was added.
  6. An owl:DatatypeProperty may be an owl:InverseFunctionalProperty in OWL Full.
  7. Synonyms for RDF and RDF Schema classes and properties were removed from the language, resulting in the removal of:
  8. daml:disjointUnionOf was removed from the language, since it can be effected using owl:unionOf or rdfs:subClassOf and owl:disjointWith.
  9. daml:equivalentTo was renamed to owl:sameAs, and is no longer a superproperty of owl:sameClassAs, owl:samePropertyAs, and owl:sameIndividualAs
  10. The following properties and classes were added to support versioning:
  11. owl:AllDifferentFrom and owl:distinctMembers were added to address the Unique Names Assumption.

References

@@To be updated (GS)
[DAML+OIL]
DAML+OIL (March 2001) Reference Description. Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Note 18 December 2001. Latest version is available at http://www.w3.org/TR/daml+oil-reference.
[OWL Abstract Syntax]
Web Ontology Language (OWL) Abstract Syntax and Semantics. Peter F. Patel-Schneider, Patrick Hayes, Ian Horrocks, and Frank van Harmelen. W3C Working Draft 8 November 2002. Latest version is available at http://www.w3.org/TR/owl-semantics/. Editor's draft is available at http://www-db.research.bell-labs.com/user/pfps/owl/semantics/.
[OWL Overview]
Web Ontology Language (OWL Lite and OWL) Feature Synopsis Version 1.0. Deborah L. McGuinness and Frank van Harmelen. W3C Working Draft 29 Jul 2002. Latest version is available at http://www.w3.org/TR/owl-features/. Editor's draft is available at http://www.ksl.stanford.edu/people/dlm/webont/OWLFeatureSynopsis.htm.
[OWL Guide]
Web Ontology Language (OWL) Guide Version 1.0. Michael K. Smith, Raphael Volz, and Deborah McGuinness. W3C Working Draft 4 November 2002. Latest version is available at http://www.w3.org/TR/owl-guide/.
[OWL Issues]
Web Ontology Issue Status. Michael K. Smith, ed. 18 December 2002. Latest version is available at http://www.w3.org/2001/sw/WebOnt/webont-issues.
[OWL Requirements]
Requirements for a Web Ontology Language. Jeff Heflin, Raphael Volz, and Jonathan Dale. W3C Working Draft 8 July 2002. Latest version is available at http://www.w3.org/TR/webont-req/.
[OWL Test Cases]
Web Ontology Language (OWL) Test Cases. Jeremy J. Carroll and Jos De Roo. W3C Working Draft 24 October 2002. Latest version is available at http://www.w3.org/TR/owl-test/.
[RDF Concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne and Jeremy J. Carroll, eds. W3C Working Draft 8 November 2002. Latest version is available at http://www.w3.org/TR/rdf-concepts/.
[RDF Schema]
RDF Vocabulary Description Language 1.0: RDF Schema. Dan Brickley and R.V. Guha, eds. W3C Working Draft 30 April 2002. Latest version is available at http://www.w3.org/TR/rdf-schema/.
[RDF Semantics]
RDF Semantics. Patrick Hayes, ed. W3C Working Draft 12 November 2002. Latest version is available at http://www.w3.org/TR/rdf-mt/.
[RDF/XML Syntax]
RDF/XML Syntax Specification (Revised). Dave Beckett, ed. W3C Working Draft 25 March 2002. Latest version is available at http://www.w3.org/TR/rdf-syntax-grammar/.