The OWL Web Ontology Language is being designed by the W3C Web Ontology Working Group
in order to provide a language that can be used for applications
that need to understand the logical content of information instead of
just understanding the human-readable presentation of content.
The OWL language can be used to
allow the explicit representation of term vocabularies and
the relationships between entities in these vocabularies. In this
way, the language goes beyond XML, RDF and RDF-S in allowing greater
machine readable content on the web.
The OWL language is a revision of the DAML+OIL web ontology language.
This document provides an introduction to the OWL language
by providing a motivation, language
synopsis, language description with simple examples, and discussion section first
on a
a simpler version of the full OWL language called OWL lite and then on the
full OWL language.
A more complete language
description will be provided in accompanying documents.
For a more detailed introduction to both OWL and OWL lite, please see
the
OWL reference description document and the
Formal Specification of the OWL Web Ontology Language.
- Motivation
- Language Synopsis
- OWL Lite Synopsis
- OWL Lite RDF Schema Features Synopsis
- OWL Lite Equality and Inequality Synopsis
- OWL Lite Property Characteristics Synopsis
- OWL Lite Restricted Cardinality Synopsis
- OWL Lite Datatypes Synopsis
- OWL Lite Header Information Synopsis
- OWL Synopsis
- OWL Class Axioms Synopsis
- OWL Boolean Combinations of Class Expressions Synopsis
- OWL Arbitrary Cardinality synopsis
- OWL Filler Information Synopsis
Language Description of OWL Lite
- OWL Lite RDF Schema Features Description
- OWL Lite Equality and Inequality Description
- OWL Lite Property Characteristics Description
- OWL Lite Restricted Cardinality Description
- OWL Lite Datatypes
- OWL Lite Header Information
Incremental Language Description of OWL
Summary
Status
1. Motivation
The goal of this document is to provide a simple introduction to the
Ontology Web Language. This document begins by describing a subset of
the entire language called OWL Lite.
The goal of OWL Lite is to provide a language that is
viewed by tool builders to be easy enough and useful enough to support. One
expectation is that tools will facilitate the widespread adoption of OWL and
thus OWL language designers should attempt to create a language that tool
developers will flock to. An easy language implies that the language should be:
- explainable and understandable (which may imply that it is not too large)
- easier to implement than the full language
A useful language implies that the language
should be:
- expressive enough so that it can be used to model
at least some simple applications of some expected use cases.
- relatively easy to extend with features in OWL. Extensions should
not be made more difficult than necessary because of features in the core
language.
While it is widely appreciated that all of the features in languages such
DAML+OIL are important to some users, it is also understood that a languages as
expressive as DAML+OIL may be daunting to some groups who are trying to support
a tool suite for the entire language. In order to provide a target that is
approachable to a wider audience, a subgroup of the web ontology working group
was formed to propose a smaller language now referred to as OWL Lite.
This smaller language attempts to
capture many of the commonly used features of OWL and DAML+OIL. It also attempts to
describe a useful language that provides more than RDFS with the goal of adding
functionality that is important in order to support web applications. It also
attempts to choose features that do not impose too many restrictions on
toolbuilders who want to extend their support beyond this "lite" language.
This document also provides an introduction to the full OWL language by
introducing the additional features in OWL over those included in OWL Lite.
The only main difference between this version of OWL Lite and the previous description is
a limitation on cardinalities and the explicit inclusion of inverseFunctional for properties.
The document has changed in that it now describes both OWL lite
as well as the full OWL language.
2 Language Synopsis
This section contains the language synopsis for OWL Lite and OWL.
2.1 OWL Lite Synopsis
The
expanded summary listing of OWL Lite is:
2.1.1 OWL Lite RDF Schema Features Synopsis
- class
- property
- subClassOf
- subPropertyOf
- domain
- range
- individual(named and unnamed)
2.1.2 OWL Lite Equality and Inequality Synopsis
- sameClassAs
- samePropertyAs
- sameIndividualAs
- differentIndividualFrom
2.1.3 OWL Lite Property Characteristics Synopsis
- inverseOf
- transitive
- symmetric
- functional
- isTheOnlyOne (previously unambiguous property and inverseFunctional)
- eachValueFrom (universal local range restrictions; previously toClass)
- someValueFrom (existential local range restrictions; previously hasClass)
2.1.4 OWL Lite Restricted Cardinality Synopsis
-
hasAtLeast1
-
hasAtMost1 (previously unique property)
-
hasExactly1
-
hasExactly0
2.1.5 OWL Lite Datatypes Synopsis
Following the decisions of RDF Core.
2.1.6 OWL Header Information Synopsis
-
imports
-
Dublin Core Meta data
2.2 OWL Synopsis
The
expanded summary listing of OWL adds the following:
2.2.1 OWL Class Axioms Synopsis
-
oneOf (enumerated classes)
-
disjoint
-
sameClassAs applied to class expressions
-
subClassOf applied to class expressions
2.2.2 OWL Boolean Combinations of Class Expressions Synopsis
-
unionOf
-
intersectionOf
-
complementOf
2.2.3 OWL Arbitrary Cardinality Synopsis
- hasAtLeast
- hasAtMost
- hasExactly
2.2.4 OWL Filler Information Synopsis
-
Descriptions can include specific filler information
The next section contains an
expanded description of the language.
3. Language Description of OWL Lite
This section will discuss the proposed language
features in English. An abstract syntax
is used for presentation of the language.
OWL Lite has a subset of the full OWL language constructors and has a few restrictions.
Unlike the full OWL language (and DAML+OIL),
classes can not be defined in terms of arbitrary descriptions;
instead only named superclasses and certain kinds of restrictions can be used.
Equivalence for
classes, and subclass between classes are all only allowed on named classes, not arbitrary
descriptions. Similarly, property restrictions in OWL-Lite cannot have embedded descriptions,
instead only allowing class names where descriptions would be allowed in Full OWL.
It also has a limited notion of cardinality - the only
cardinalities allowed to be explicitly stated are 0 or 1.
3.1 OWL Lite RDF Schema Features Description
The limited language can be viewed as an extension of a
restricted view of the RDF language. The restrictions limit the set of
allowable models. The implications of the restriction are that every statement
valid in the language describable by this document will be valid RDF, but not
all valid RDF will be valid in the language described by the document. It
retains the following terms from RDF. These terms may be referred to as
RDF: < TERM >.
- class: Classes may be created that have a classID and a
description. A trivial class creation may be to create a class with the
classID foo that is a subclass of the root class THING. There is no limitation on cycle
creation in subclass hierarchies.
Class descriptions can either be partial, indicating that the elements of the
class satisfy
at least the stated description and perhaps others; or the class description
can be complete,
indicating that the elements of the class are precisely characterized by the stated description.
A partial person description could be that it is a subclass of mammal. From this a reasoner can deduce
that any instance of a person is an instance of a mammal.
A complete redHairedPerson description could be a person whose hair color is red.
>From this a reasoner could deduce that an instance of person whose hair color property has
a value of red in it is an instance of the class redHairedPerson.
- property: terms that are to be used as relationships between
individuals and classes may be defined as properties. Note in this document we
use individual to include both instances of RDF or OWL classes as well as
instances of datatypes like the integer 4. For example, hasChild, hasRelative,
hasSibling, hasAge, etc. may all be stated to be properties. The first three
would be expected to have values that are instances of RDF or OWL classes; the
last would have a datatype value.
- subClassOf: Class hierarchies may be created by stating that
classes are subclasses of other classes. For example, the class person could
be stated to be a subclass of the class mammal. From this a reasoner may
deduce that if X is a person, then X is a mammal.
- subPropertyOf: Property hierarchies may be created by stating that
some properties are subproperties of other properties. For example, hasSibling
may be stated to be a subproperty of hasRelative. From this a reasoner may
deduce that if X is related to Y by the hasSibling property, then X is also
related to Y by the hasRelative property.
- domain: Properties may be stated to have domains, (i.e., the first
argument of the property must be an instance of the domain class). For
example, the property hasChild may be stated to have the domain of Mammal.
From this a reasoner may deduce that if X is related to Y by the hasChild
property, i.e., Y is the child of X, then X is a Mammal. Note that these are
called global restrictions since the restriction is stated on the property and
not just on the property when it is associated with a particular class. See
the discussion below on local restrictions for more information.
- range: Properties may be stated to have ranges, (i.e., the second
argument of the property must be an instance of range class). For example, the
property hasChild may be stated to have the range of Mammal. From this a
reasoner may deduce that if X is related to Y by the hasChild property, i.e.,
Y is the child of X, then Y is a Mammal. Range is also a global restriction as
is domain above. See the discussion below on local restrictions for more
information.
- individual: Individuals may be created with an optional individual
identifier and a description. For example, an individual named Deborah may be
created as an instance of the class person. Another individual may be created
that is not given an identifier (thus it would not contain the id "Deborah")
that is an instance of the class StanfordEmployee.
3.2 OWL Lite Equality and Inequality Description
The following features related to equality or
inequality are included:
- sameClassAs: Two classes may be stated to be the same, (i.e., the
classes have the same extension). This can be used for creating synonymous
classes. It also has the side effect of effectively creating conjunctions of
classes. For example, the class CAR which is a subclass of moving vehicle may
be stated to be the sameClassAs another class Automobile which is a subclass
of expensiveThing. A reasoner may deduce that anything that is a Car is also
an instance of Automobile and thus is also an instance of expensiveThing. The
reasoner can also deduce that Car is a subclass of Automobile and Automobile
is a subclass of Car.
- samePropertyAs: Two properties may be stated to be the same. This
may be used to create synonymous properties. For example, hasLeader may be
stated to be the samePropertyAs hasHead. From this a reasoner may deduce that
is X is related to Y by the property hasLeader, X is also related to Y by the
property hasHead. The reasoner can also deduce that hasLeader is a subproperty
of hasHead and hasHead is a subProperty of hasLeader.
- sameIndividualAs: Two individuals may be stated to be the same.
This may be used to create a number of different names that may be used to
refer to an individual. This may be useful for identifying when one named
individual is the same as an unnamed individual and it also may be useful in
merging ontologies. For example, we may state that the instance Deborah is the
same individual as DeborahMcGuinness and we may also state that the instance
Deborah is the same as the instance that is a member of
AssociateDirectorKnowledgeSystemsLab.
- differentIndividualFrom: Two individuals may be stated to be
different from each other. For example, the individuals Frank and Deborah may
be stated to be different from each other. From this, the reasoner can deduce
that Frank and Deborah refer to two unique individuals. Thus, if Frank and
Deborah both fill a property that is stated to be functional (have at most 1
filler), then there is a contradiction. This can be important in systems that
do not make the unique names assumption, such as RDF.
For example, in a system that only
knew that Frank and Deborah were both instances of the class person, without
using the unique names assumption, a reasoner could not deduce that they were
distinct.
3.3 OWL Lite Property Characteristics Description
- inverseOf: Two properties may be stated to be inversely related. If
properties P1 and P2 are inversely related then if P1(X,Y) is true, then
P2(Y,X) is true. For example, hasChild and hasParent may be stated to be
inversely related. From this the reasoner that is given
hasParent(Deborah,Louise) may deduce hasChild(Louise,Deborah).
- transitive: Properties may be stated to be transitive. If a
property is transitive, then if the pair (x,y) is an instance of the
transitive property P, and the pair (y,z) is an instance of P, then the pair
(x,z) is also an instance of P. For example, if ancestor is stated to be
transitive, and if Sara is an ancestor of Louise (i.e., (Sara,Louise) is an
instance of ancestor) and Louise is an ancestor of Deborah (i.e.,
(Louise,Deborah) is an instance of ancestor), then a reasoner may deduce that
Sara is an ancestor of Deborah (i.e., (Sara,Deborah) is an instance of
ancestor.
The same DAML+OIL side conditions hold that restrict transitive
properties (and their superproperties) from having an atmost1 or an exactly1 restriction.
- symmetric: Properties may be stated to be symmetric. If a property
is symmetric, then if the pair (x,y) is an instance of the symmetric property
P, then the pair (y,x) is also an instance of P. For example, friend may be
stated to be a symmetric property. Then a reasoner that is given that Frank is
the friend of Deborah can deduce that Deborah is a friend of Frank. Note of
course that properties must have appropriate domains and ranges in order to be
made symmetric.
- functional : Properties may be stated to be functional. If a
property is functional, then it has no more than one filler. It may have 0
fillers. Another way of saying this is that the property's
minimum cardinality is zero
and its maximum cardinality is 1. For example, hasPrimaryEmployer may be
stated to be functional. If something has a primary employer, there is no more
than one number although not everyone has a primary employer. This proposal
includes the same side condition as is stated in the DAML+OIL specification
that does not allow transitive properties nor any of their superproperties to
be declared functional. For more information on the details of the limitation,
see the Warning under the property element section of the DAML+OIL reference
description or in a research
paper by Horrocks, Sattler, and Tobies showing the undecidability that
would follow from violating this restriction.
- IsTheOnlyValueFor (inverse functional): Properties may be stated to be inverse
functional. If a property is inverse functional then the inverse of the property is
functional. Thus the inverse of the property has at most one value. For example,
hasUSSocialSecurityNumber may be stated to be inverse functional. The inverse of this (which
may be referred to as isTheSocialSecurityNumberFor) has at most one value.
Thus any one person's social security number is the only value for their
hasUSSocialSecurityNumber property. From this a reasoner may deduce that no two
different things have the identical US Social Security Number. Also, a reasoner
may deduce that if two things have the same social security number, then they denote
the same thing.
- eachValueFrom (universal local range restriction): eachValueFrom is stated
on a property with respect to a class. A property on a particular class
may have a local range restriction associated with it. This states that
each value for the property must be of a certain type. For example, the class
person may have a property called hasOffspring restricted to have fillers that
are instances of the class person. This allows the property hasOffspring to be
used with other classes, possibly the class Cat and have an appropriate value
restriction associated with the use of the property on that class. In this case,
hasOffspring would have the local range restriction of Cat when associated with
the class cat and would have the local range restriction Person when associated
with the class Person. From this statement, a reasoner may deduce that if X is
the offspring of Y and Y is a Person, then X is also a person. It can also
deduce that if X is the offspring of Y and Y is a cat, then X is a cat. Note
that the reasoner can not deduce from an eachValueFrom restriction alone
that there is at least one value for the property.
- someValueFrom (existential local range restriction): someValueFrom is
stated on a property with respect to a class. A property on a particular
class may have an existential local range restriction associated with it. That is saying
that some value for the property is of a certain type. For
example, the class SemanticWebPaper may have a someValueFrom restriction on
its hasKeyword property that states that SOME keyword should be an instance of
the class SemanticWebTopic. This allows for the option of having multiple
keywords and as long as one or more is an instance of the class
SemanticWebTopic, then the paper would be consistent with the range restriction.
Unlike universal range restrictions, it does not restrict all the values of the
property to be instances of the same class. From a someValueFrom
restriction, a reasoner may deduce that there is at least one value
for the property and it is an instance of the specified class. The reasoner can
not deduce (as it could with eachValueFrom restrictions) that ALL values of
the property are instances of the specified class.
3.4 OWL Lite Restricted Cardinality Description
A restricted form of cardinality has been included in OWL Lite.
These cardinality restrictions are referred to as local restrictions since they are stated
on properties with respect to a particular class. That is, the restrictions limit
the cardinality of that property on subclasses and instances of the class.
These cardinality restrictions are considered limited because they only allow
statements concerning cardinalities of value 0 or 1 (and do not allow arbitrary
values for cardinality as is included in the full OWL language).
- hasAtLeast1:
A class may have a property that must have at least one value. For example, the class
parent may have a hasAtLeast1 restriction on its hasOffspring property. From this
a reasoner may deduce that every parent has a value for its hasOffspring property. From just
this information, the reasoner may not deduce any maximum number of offspring for parents.
- hasAtMost1 (previously unique property):
A class may have a property that may not have more than one value. For example, US citizens
may have a property hasRegisteredVotingState that has no more than one value (because
people are only allowed to vote in one state). From this a reasoner can deduce that
US citizens
may not have two or more distinct values for their hasRegisteredVotingState property.
>From a hasAtMost1 restriction alone, a reasoner may not deduce a minimum cardinality of 1.
Note that all functional properties have an atmost1 restriction on them for all classes.
- hasExactly1:
A class may have a property that has exactly one valued. For example, the class
person has exactly one value for the property hasBirthMother. From this a reasoner
may deduce that no two distinct individual Mothers may be values for the hasBirthMother
property of the same person. Note that hasExactly1 is equivalent to
the combination of hasAtLeast1 and hasAtMost1 on the same property and class and can be
viewed as a shorthand for the two restrictions.
- hasExactly0:
It may be useful to state that certain classes have no values for a particular
property. For example, the class unmarried person has exactly zero values for
the property hasSpouse.
3.5 OWL Lite Datatypes Description
- Datatypes will be included in the core language. Thus, for
example a range could be stated to be XSD:decimal. The exact details of this is
dependent upon the RDF core group's decisions on datatypes for RDF.
3.6 OWL Lite Header Information Description
- Imports:
Each imports statement references another OWL ontology containing definitions that apply
to the current ontology. Each reference consists of a URI specifying from where the ontology
is to be imported from. 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. If ontology A imports B and B imports A, then they are considered
to be equivalent.
- Dublin Core MetaData:
Ontologies also have a non-logical component (not yet specified) that can be used to record
authorship, and other non-logical information associated with a ontology. A prime candidate is to
associate with the ontology attributes from the Dublin Core meta-data standard.
4. Incremental Language Description of OWL
Full OWL extends the constructions of OWL Lite with the following:
- oneOf (enumerated classes): Classes can be defined by enumeration of the
individuals that make up the class. The class is then exactly
equal to the set of enumerated individuals, no more, no less. For
example, the class of daysOfTheWeek can be defined by simply
enumerating the instances Sunday, Monday, Tuesday etc. From this
a reasoner could deduce the maximum cardinality (7) of any property
that has daysOfTheWeek as its range.
- hasValue (property fillers): A property can be required to have a certain
individual as a value. For example, instances of the class of
dutchCitizens can be characterised as those people that have
theNetherlands as a value of their nationality. (Where
theNetherlands itself is an instance of the class of all
nationalities).
- disjointClasses: The full OWL language allows the statement that
classes are disjoint, for example stating that man and woman are
disjoint classes. From this a reasoner could conclude an
inconsistency when an instance is stated to be a member of
both and similarly could deduce that if A is an instance of Man, then A is
not an instance of Woman.
- unionOf, complementOf, and intersectionOf (Boolean combinations): OWL allows arbitrary
Boolean combinations of classes: IntersectionOf, UnionOf, and
complementOf. For example, taking the
intersection of all the class of all Dutch citizens with
the class of all people of age at least 65 defines the class of
all Dutch senior citizens. Using complement, we could state that
children are not senior citizens (i.e. the class children is a
subclass of the complement of senior citizens)
Citizenship of the European Union could be defined as the union
of the citizenship of all member states.
- hasAtLeast, hasAtMost, hasExactly (full cardinality):
While in OWL Lite,
cardinalities are
restricted
to at least, at most or exactly 1 or 0, full OWL allows
cardinality statements for arbitrary non-negative integers.
For example the class of DINKs ("Dual Income, No Kids") would
restrict the cardinality of the property hasIncome to at least 2
(while the property hasChild would have be restricted to exactly 0).
- complex class descriptions:
In many places, OIL Lite restricts the syntax to single class
names (e.g. in subClassOf or equivalentClass statements). Full
OWL extends this to allowing in those places arbitrarily complex
class descriptions, consisting of enumerated classes, property
restrictions, and Boolean combinations of these.
5. Summary
This document provides a high level description
of the OWL language by providing a feature synopsis of
both OWL Lite and the full language.
It provides simple English descriptions of the constructors along with
a simple example. It makes no attempt to include a
syntax. It also provides pointers to the other related documents
for more details.
Previous versions of the document provided the historical view of the evolution
of OWL Lite and the issues discussed in its evolution.
6. Status of this document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document.
This document is a working document for the use by W3C Members and other
interested parties. It may be updated, replaced or made obsolete by other
documents at any time.
This document has been produced as part of the W3C Semantic Web Activity, following the
procedures set out for the W3C Process.
The document has been compiled by the Web Ontology Working Group. The
goals of the Web Ontology working group are discussed in the Web Ontology Working Group
charter .
A list of current W3C Recommendations and other technical documents can be
found at http://www.w3.org/TR/.