Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
OWL is a semantic markup language for publishing and sharing ontologies on the World Wide Web. OWL is derived from the DAML+OIL Web Ontology Language [DAML+OIL] and builds upon the Resource Description Framework [RDF/XML Syntax].
This Working Draft is the first version of the OWL Web Ontology Language 1.0 specification. The Web Ontology (WebOnt) Working Group expects to update it to reflect changes in requirements until such time as OWL becomes a W3C Recommendation. The working group has not reached consensus on all issues, and has produced an online issues list [OWL Issues] that maintains the current status of all issues being considered. Links to associated issues are highlighted.
Several outstanding global issues may impact various sections of this document. See issue #5.3-Semantic-Layering. See issue #5.10-DAML-OIL-semantics-is-too-weak.
Editorial notes to be addressed in future revisions are also highlighted.
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.
There are no patent disclosures related to this work at the time of this writing.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference materials or to cite them as other than "work in progress." A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
This document has been produced as part of the W3C Semantic Web Activity (Activity Statement) following the procedures set out for the W3C Process. The document has been written by the Web Ontology Working Group. The goals of the Web Ontology working group are discussed in the Web Ontology Working Group charter.
This document is derived from the DAML+OIL (March 2001) Reference Description [DAML+OIL] included in the DAML+OIL submission. The work of the authors, editors, and sponsors of that and predecessor documents is gratefully acknowledged.
This document gives a systematic, compact and informal description of all the modelling primitives of OWL. We expect this document to serve as a reference guide for users of the OWL language.
An OWL knowledge base is a collection of RDF triples as defined in the RDF/XML Syntax Specification (Revised) [RDF/XML Syntax]. OWL prescribes a specific meaning for triples that use the OWL vocabulary. This document specifies which collections of RDF triples constitute the OWL vocabulary and what the prescribed meaning of such triples is.
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]). The current document uses a specific RDF syntactic form for these triples. However, it is also allowed to use any other syntactic RDF form that results in the same underlying set of RDF triples as the syntax used in this document. Such other syntactic form would then carry exactly the same prescribed meaning as the equivalent syntactic form used in this document. See Syntax Note for an example of this.
As stated above, OWL assigns a specific meaning to certain RDF triples. The future Formal Specification specifies exactly which triples are assigned a specific meaning, and what this meaning is. OWL only provides a semantic interpretation for those parts of an RDF graph that instantiate the schema defined in http://www.w3.org/2002/07/owl. Any additional RDF statements, resulting in additional RDF triples are perfectly allowed, but OWL is silent on the semantic consequences (or lack thereof) of such additional triples. See Mixing Note for an example of this.
An OWL ontology is made up of several components, some of which are optional, and some of which may be repeated. See the index for a listing of all these components. Througout this document, OWL constructs will be presented in a structured format, and not as bare RDF triples. This structured RDF format is more natural to read, but, of course, any way of generating the same RDF triples as generated by the structured RDF format is equivalent.
Several components employ lists constructed using the rdf:List, rdf:first, rdf:rest, rdf:nil, and rdf:parseType="Collection" vocabulary [Ed: identify link] recently added to RDF.
An OWL ontology consists of zero or more headers, followed by zero or more class elements, property elements, and instances.
An owl:Ontology
element contains zero or more version information
and imports elements.
<Ontology rdf:about=""> <versionInfo>$Id: Overview.html,v 1.5 2017/10/02 10:25:44 denis Exp $</versionInfo> <rdfs:comment>An example ontology</rdfs:comment> <imports rdf:resource="http://www.w3.org/2002/07/owl"/> </Ontology>
The
owl:versionInfo element generally contains a string giving
information about this version, for example RCS/CVS keywords. This element
does not contribute to the logical meaning of the ontology. See the example
above.
See issue #5.14-Ontology-versioning.
Each owl:imports
statement references another OWL ontology containing definitions
that apply to the current OWL resource.
Each reference consists of a URI specifying from where the
ontology is to be imported from. See the example above.
Imports
statements are transitive, that is, if ontology A imports B, and B
imports C, then A imports both B and C. Importing an ontology into
itself is considered a null action, so if ontology A imports B and B
imports A, then they are considered to be equivalent.
See issue #5.6-daml:imports-as-magic-syntax.
Note that namespaces only provide a mechanism for creating unique names for elements, and do not actually include definitions in the way that imports does. Similarly, imports statements do not set up a shorthand notation for names. Therefore, it is common to have imports statements that correspond to each namespace. However, additional imports may be used for ontologies that provide definitions without introducing any new names.
See issue #4.4-Extra-logical-feature-set.
OWL divides the universe into two disjoint parts. One part consists of the values that belong to XML Schema datatypes. This part is called the datatype domain. The other part consists of (individual) objects that are considered to be members of classes described within OWL (or RDF). This part is called the object domain. See issue #5.1-Uniform-treatment-of-literal/data-values.
OWL is mostly concerned with the creation of classes that describe (or define) part of the object domain. Such classes are called object classes and are elements of owl:Class, a subclass of rdfs:Class. OWL also allows the use of XML Schema datatypes to describe (or define) part of the datatype domain. These datatypes are used within OWL simply by including their URIs within an OWL ontology. They are (implicitly) elements of owl:Datatype. Datatypes are not OWL individual objects. See issue #5.8-Datatypes.
A class element, owl:Class, contains (part of) the definition
of an object class.
See issue #5.22-owl:Class-still-needed.
A class element refers to a class name (a URI), (we will refer to this class
as C) and contains
rdfs:subClassOf elements (each containing a class-expression). owl:disjointWith elements (each containing a class-expression).owl:disjointUnionOf elements (each containing a list of class-expressions).owl:sameClassAs elements (each containing a class-expression).owl:equivalentTo elements (each
containing a class
expression)Notice that the first two elements state necessary but not sufficient
conditions for class membership. The final five elements state both necessary
and sufficient conditions.
A class expression is the name used in this document for either
<owl:Class>...</owl:Class> tags, or<rdfs:Class>...</rdfs:Class>
tagsEach class expression either refers to a named class, namely the class that is identified by the URI, or implicitly defines an anonymous class, respectively the class that contains exactly the enumerated elements, or the class of all instances which satisfy the property-restriction, or the class that satisfies the boolean combination of such expressions.
Two class names are already predefined, namely the classes
owl:Thing
and owl:Nothing. Every
object is a member of owl:Thing, and no object is a member
owl:Nothing. Consequently, every class is a subclass of
owl:Thing and owl:Nothing is a subclass of
every class.
An enumeration is a
owl:oneOf element, containing a list of the objects
that are its instances.
This enables us to define a class by exhaustively enumerating its elements.
The class defined by the oneOf element contains exactly the enumerated
elements, no more, no less. For example:
<owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Eurasia"/> <owl:Thing rdf:about="#Africa"/> <owl:Thing rdf:about="#North_America"/> <owl:Thing rdf:about="#South_America "/> <owl:Thing rdf:about="#Australia"/> <owl:Thing rdf:about="#Antarctica"/> </oneOf>
A property restriction is a special kind of class expression. It implicitly defines an anonymous class, namely the class of all objects that satisfy the restriction. There are two kinds of restrictions. The first kind, ObjectRestriction, works on object properties, i.e., properties that relate objects to other objects. The second kind, DatatypeRestriction, works on datatype properties, i.e., properties that relate objects to datatype values. Both kinds of restrictions are created using the same syntax, with the usual difference being whether a class element or a datatype reference is used. It is also possible to create restrictions that are neither restrictions nor datatype restrictions, but these restrictions are not handled within OWL.
A owl:Restriction element contains an
owl:onProperty element, which refers to a property name (a
URI) (we will refer to this property as P) and one or more of the
following
owl:allValuesFrom
element (which contains a class expression
).owl:hasValue
element (which contains (a reference to) an
individual object or a datatype value).owl:someValuesFrom
element (which contains a class expression
or a datatype
references).owl:cardinality element.owl:maxCardinality element.owl:minCardinality element.The OWL syntax currently allows restrictions that are malformed. Restrictions with missing components (e.g., an owl:Restriction element with no owl:onProperty element) have no semantic impact, even though treating them as RDF would indicate that there should be some semantic import. Restrictions with extra components (e.g., an owl:Restriction element with multiple different owl:onProperty elements) have unusual and misleading semantic impact (in general equating the extensions of two or more well-formed restrictions). Use of such constructs should be avoided. See issue #5.9-Malformed-DAML+OIL-Restrictions.
A boolean combination of class expressions can be constructed from:
owl:intersectionOf element, containing a list of class expressions. owl:unionOf
element, containing a list of class
expressions. owl:complementOf element, containing a single class expression.Note that arbitrarily complex combinations of these expressions can be formed. See Boolean Note for an example of this.
A rdf:Property element refers to a property name (a URI)
(to which
we will refer as P).
Properties that are used in property restrictions should be either
properties, which relate objects to other objects, and are instances of
ObjectProperty;
or
datatype properties, which relate objects to datatype
values, and are instances of
DatatypeProperty.
A property element contains:
rdfs:subPropertyOf elements, each containing a property
name.rdfs:domain elements (each containing a class expression).rdfs:range
elements (each containing a class expression).owl:samePropertyAs elements (each containing a property
name).equivalentTo elements (each
containing a property name).owl:inverseOf elements (each containing a property name),
for properties only.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:
owl:TransitiveProperty element, which is a
subclass of ObjectProperty.owl:SymmetricProperty element, which is a
subclass of ObjectProperty.owl:FunctionalProperty
element.owl:InverseFunctionalProperty element, which is a
subclass of ObjectProperty.Notice that FunctionalProperty and InverseFunctionalProperty
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, FunctionalProperty is a particular case of a
cardinality constraint.
Instances of both classes
(i.e., objects) and of properties (i.e., pairs) are written in
RDF/XML syntax.
See the
RDF/XML Syntax Specification(Revised)
for more details on the various
syntactic forms that are allowed. Here we list just some of the most common
notations:
<Continent rdf:ID="Asia"/>
<rdf:Description rdf:ID="Asia">
<rdf:type>
<rdfs:Class rdf:about="#Continent"/>
</rdf:type>
</rdf:Description>
<rdf:Description rdf:ID="India">
<isPartOf rdf:resource="#Asia"/>
</rdf:Description>
There is no unique name assumption for objects in OWL.
To state that objects are the same, an
owl:sameIndividualAs element
is used.
(Note that owl:equivalentTo can be also used here, but
owl:sameIndividualAs is preferred.)
To state that objects are distinct,
an owl:differentIndividualFrom
element is used.
The situation is different for datatype values, where XML Schema Datatype
identity is used.
Datatype values are written in a manner that is valid RDF syntax, but which is given a special semantics in OWL. The preferred method is to give a lexical representation of the value as a string, along with an XML Schema datatype that is used to provide the type of the value as well as the parsing mechanism to go from the string to the value itself. The XML Schema datatype is the rdf:type of the value, and the lexical representation is the rdf:value of the value. So the decimal 10.5 could be input as <xsd:decimal rdf:value="10.5"/> provided that xsd was defined as the URI of the XML Schema Datatype specification.
As a nod to backward compatability, literals that occur outside this sort of construction are interpreted as any of the XML Schema Datatype values with this lexical representation. These values are mostly unusable unless some typing information is available, such as a range for a property.
The question of whether any XML Schema datatype can be used in such constructions, or whether only certain XML Schema dataypes can be so used (such as only the predefined datatypes), remains open. See issue #4.3-Structured-Datatypes. See issue #5.7-Range-restrictions-should-not-be-separate-URIs.
<rdfs:Class rdf:ID="Continents"/>
However, the following RDF statement:
<rdf:Description rdf:ID="Continents"> <rdf:Type resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description>
results in exactly the same set of RDF triples, and is therefore
perfectly allowed as a class definition.
Another example is the two notations that we
discuss for cardinality constraints below. Again, both these forms
result in the same set of RDF triples, and are thus equivalent.
<rdf:Description rdf:about="#Person">
<Creator>Ora Lassila</Creator>
</rdf:Description>
then the semantics don't say what this means or what
it would imply for instances of Person. (Beyond of course the minimal
Subject-Verb-Object semantics of RDF).
<Restriction> <onProperty rdf:resource="#father"/> <cardinality>1</cardinality> </Restriction>
we would have to write
<Restriction cardinality="1"> <onProperty rdf:resource="#father"/> </Restriction>
to avoid any exposed content. The cardinality
elements are the only ones for which this alternative notation is
required to avoid exposed content.
(See
[Ed: identify link]
the section on abbreviated syntax
in the RDF specification for more details on this notation).
<complementOf> <Class> <unionOf rdf:parseType="Collection"> <Class rdf:resource="#meat"/> <Class rdf:resource="#fish"/> </unionOf> </Class> </complementOf>