Proposed Compliance Level 1 for WebOnt's Ontology Language OWL
- This version:
- 15 May 2002
- Previous version:
13 May 2002
- Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University )
Deborah L. McGuinness.
All Rights Reserved.
Distribution policies are governed by the W3C intellectual property
This document proposes a description of Level 1 compliance
for the web ontology working group language.
The goal 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:
A useful language implies that the language should be:
explainable and understandable (which may imply that it is not too large)
easy to implement
The document contains a motivation, history, language synopsis,
language description with simple examples, and discussion section.
Once the language description is agreed upon,
a more complete language description will be provided.
a step above RDF/S (thereby allowing users to implement applications that
were inconvenient or impossible with RDF/S)
relatively easy to extend with features in DAML+OIL/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 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.
This language attempts to capture many of the commonly used features
of 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 impose as few restrictions as
possible on toolbuilders who want to extend their support beyond
this compliance level. Thus, one of the considerations the design group
used before adding new features was feature interaction.
This proposal is the immediate result of a
held at the
Knowledge Representation and Reasoning Conference
in Toulouse France on Monday April 22.
Attendees of the meeting included:
Ian Horrocks, Hermann ter Horst, Peter Patel-Schneider,
Frank van Harmelen, Chris Welty, and Deborah McGuinness.
At the Webont
face to face meeting, the issue of a smaller language was
discussed. As input to the discussion, the first
proposal for OWL and
presentation was considered.
The result was an action that a group revisit a compliance level
below the full generality of DAML+OIL.
The group consists of Mike Dean, Enrico Motta,
Raphael Volz, Ian Horrocks, Frank van Harmelen, and Deborah McGuinness.
The meeting at KR was to handle the action item and generate a proposal
for the compliance level. Van Harmelen and McGuinness
wrote up the results of the
meeting and posted a
proposal for the compliance level and solicited comments.
The next section contains the summary of the proposal.
This language is takes as its starting point the proposal from
van Harmelen coined as RDF Schema on Steroids
and adds two kinds of functionality:
The expanded summary listing of this proposal includes:
properties that can be declared functional
datatypes (subject to the datatype resolution by the RDF Core Working Group).
RDF Schema features
individual(named and unnamed)
Equality and Inequality
The next section contains an expanded description of the language.
functionality of properties (properties with min cardinality 0 and max
cardinality 1. The same DAML+OIL side conditions hold that a transitive
property (nor its superproperties) may not be declared functional.)
datatypes (following the decisions of RDF Core)
This section will discuss the proposed language features in English.
Following group consensus on the language, an additional section will be added
containing a more formal specification. An abstract syntax is used for
presentation of the language.
RDF Schema features
The language does not differ from
RDF in these core features.
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.
Some would call this a primitive class definition in that it does not
provide a way to specify sufficient conditions for class membership.
property: terms that are to be used as relationships between individuals
and classes may be defined as properties. For example, hasChild, hasRelative,
and hasSibling may all be stated to be properties.
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
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).
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 further discussion on this point in relation to local
range: Properties may be stated to have ranges, (i.e., the second
argument of the property must be an instance of range class).
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.
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
Equality and Inequality
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
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.
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.
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
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.
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.
functionality of properties
: 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 its minimum cardinality is zero
and its maximum cardinality is 1.
For example, hasUSSocialSecurityNumber may be stated to be functional.
If something has a United States Social Security number, there is no
more than one number although not everyone has a United States Social Security
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.
: 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.
This section provides some perspective on the proposal to date and
Previous sections attempted to minimize subjective statements.
This section however reflects the interpretation of the editor.
There was little resistance to the basic proposal in that there were
very few suggestions to take features out of the core set.
Previously some members of webont have made compelling points concerning
the usefulness of local range restrictions and some dangers of global range
restrictions. In response to the acknowledgement by many that local
restrictions seem to be the preferred modeling mode, there was one suggestion
to eliminate global domain and range restrictions from the core language.
This however would mean removing something that is in RDF and has
not received additional support.
Thus, the remainder of the discussion concerns
discussion points relating to possible additions to the language.
There were two kinds of responses concerning additions to the language.
One type of comment stated that the core language should have feature X.
Another type of comment revolved around the strategy for choosing
what should go in the core language.
We first consider some of the issues involved in choosing features.
Some members (see for example, a posting from
Horrocks) have made the point that it is not possible to
come up with a single ordering of features for inclusion in terms of importance.
There is agreement that one total ordering that is agreed upon
by the group is not an achievable goal.
There is also agreement that adding some features after other features
are already in the language may make the addition more difficult than
adding the same feature to a language that does not include certain
These two issues together may lead one to conclude that a core language
should stay small so as not to unfairly penalize tool implementors who
need to add features to the core language.
After a briefing of the proposal to the EU/US Joint Committee,
the suggestion was made that this core language might attempt to cover
50-75 percent of the needs of the typical user. (See for example,
the posting by
McGuinness relating a suggestion by Mike Dean).
While of course typical user is not precisely defined and thus, this is
a vague statement, the intent of covering most of the needs of a typical user
is likely to be at odds with the goal of keeping the language small enough
to be easy to explain to a broad user base and easy to implement by a wide
variety of tool implementors.
The editor's summary of the strategy discussion is mostly in agreement
with a posting by
van Harmelen where he states that there was one approach taken
to determine the core language at the face to face meeting that failed.
That approach was to include features for which anyone could make a compelling
case for inclusion. The approach failed since the resulting core language
differed very little from DAML+OIL and many believed this was too
"top heavy" a language for widespread adoption.
There is another approach taken in Toulouse to define a core language
that does not penalize implementors addition of new features by features
already in the language while providing a small explainable
core language that is a step above RDFS.
It is open to debate if one or two features can be added to the Toulouse core
language that will maintain the principles followed in Toulouse and meet
more of the needs of the typical user.
One other type of general comment concerned presentation.
There was one request to standardize our documents on the use of
relation instead of role or property.
A few other emails brought up the issue of not using the primitive vs. defined
distinction, however another email stated that it was important to
point out that some modeling languages that we may want to provide interfaces
to such as UML, only provide primitive modeling capabilities so it may
be important for our documentation to point out the differences.
The next set of topics could be grouped as requests for
language features to be added to the core set.
The next set of topics are roughly ordered by the amount of email
traffic that was generated on the topic.
Existential and universal local range restrictions:
There is agreement that local range restrictions are useful.
In the discussion in Toulouse, there were strong cases made by Horrocks
for existential local range restrictions and by McGuinness and van Harmelen
for universal local range restrictions.
Additional postings stating the case for existential range restrictions
can be seen for example in the posting by
Additional postings stating the case for universal range restrictions
can be seen for example in the posting by
Mike Dean and
A debate over the utility of universal vs. existential range restrictions
was carried on through email since many believed that we might choose to
put in just one of the two in the core. Both sides made strong cases
for the utility of the feature. Existential local range restrictions
along with functional roles
can capture a lot of what is needed in many applications and universal
local range restrictions along
with minimum cardinality can capture a lot of what is needed in many
Some of the postings at the end of the discussion
thread capture some of the examples on both sides (e.g., postings
The editor's summary concerning the discussion is that both features are
useful and necessary in a number of applications. Universal local range
restrictions may see more use in knowledge bases however that may be because
more applications used languages with this representational construct.
Cardinality: There were a number of requests for
more cardinality than what is available with functional roles. (Functional
roles allow one to state max cardinality 1.) (See for example, postings by
Mike Dean, Enrico Motta, and
The editor's summary of the requests are that many would like at least
min cardinality 1 and some number would like unrestricted min and max
cardinality. One note, universal local range restrictions are more useful
if the language has a way of stating min cardinality 1.
Functionality of roles: There were some postings asking
for clarification on functionality of roles and
also stating that functionality was not enough. There was also a suggestion
that global functional roles may be dangerous. (See for example, postings by
The editor's summary of this topic is that clarification has been provided
on the mailing list that functional roles means min cardinality 0 and
max cardinality 1. The resolution of cardinality in the core language
may make this issue disappear.
Modification of descriptions: There was a suggestion
that descriptions may need to be modified from
previously published and used descriptions in ontologies.
(See for example, postings by
The editor's summary on this topic is that modifying the meaning of terms
is dangerous and once this was pointed out, the requests for language support
for this feature disappeared.
Compliance with rule engines: There was a request that
the low compliance level be compatible and implementable with rules engines.
(See for example, postings by
The editor's summary is that no one disagreed with this request and no one
proposed that the core language violated the request.
This document captures the state of the proposal for the compliance level
one for OWL. It summarizes the proposal and introduces the language
through simple English examples. It attempts to capture the ongoing discussion
The goal is to gain consensus on the core compliance level by resolving any
remaining issues. The editor's summary of remaining issues include the
for choosing language features for the compliance level and
what choices to make concerning cardinality and local range restrictions.
One more recent request was to get consensus on what term to use for relations,
roles, or properties with the request to use the term relation.
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
A list of current W3C Recommendations and other technical documents can be
found at http://www.w3.org/TR/.