Guus Schreiber
Version: 31 May 2005
This document is intended for people starting to use OWL, the W3C Web Ontology language [OWL Overview] and who are puzzled about how OWL constructs work, in particular OWL restrictions. In the course of this note we also discuss some basic ontology-engineering principles.
Basic knowledge of RDF and OWL is assumed, as well as previous modeling experience in a data-modeling language such as UML. The examples in this note use the N3 Turtle syntax [N3 Turtle]. In our experience this syntax is much more readable than RDF/XML.
Note:` In Protege you can use the option "Save as | N3" to generate this format for your ontology.
Understanding OWL requires some understanding of how Description
Logic (DL) models the world.
In DL many things are represented with the help of the
subsumption relation (OWL uses the rdfs:subClassOf
for
representing subsumption). We give an example to illustrate
this DL modeling style. Suppose we want to state the red wines should have the color
"red" as the value of their color
property. In OWL we
state this by saying (in words):
"Red wine is a subclass of all things that have a red color."
Thus, all red wines form a subset of all things that have a red color. Well, it means the same thing, but at first this might seem like a strange way of saying it. DL often makes use of the notion of an "anonymous class" to express various types of constraints on classes. An OWL restriction is such an anonymous class. In N3 the red-wine example looks like this:
:RedWine a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :color ; owl:hasValue red^^<http://www.w3.org/2001/XMLSchema#string> ] .
If you're still confused, try to read this while leaving out the subClassOf line (this is incorrect syntax, of course, but just for argument sake):
:RedWine a owl:Class ; [ a owl:Restriction ; owl:onProperty :color ; owl:hasValue red^^<http://www.w3.org/2001/XMLSchema#string> ] .
This might look more familiar to people from a pure data-modeling background: you can read it as a UML class with an attribute color and a value constraint for the attribute.
Actually, the subclass relation is essential for understanding the semantics of the restriction: it is a necessary but not sufficient condition for the class. In subsumption terms: there might be things that are red and not wines, hence the subset/subclass definition.
As an example of a necessary and sufficient condition, take a look at the following definition:
:RedThing a owl:Class ; owl:equivalentClass [ a owl:Restriction ; owl:onProperty :color ; owl:hasValue red^^<http://www.w3.org/2001/XMLSchema#string> ]
Here, owl:equivalentClass
is used instead of
rdfs:subClassOf
. The definition states that the set of red
things is exactly the same as the class of things that have the value
"red" for its color
property .
The notion of a sufficient condition is absent in UML, so readers coming from that background will have to get familiar with this. Such classes are also sometimes called "defined classes"; the other classes (with just necessary conditions) are sometimes called "primitive classes". Reasoners can automatically establish whether an individual is a member of a defined class; for primitive classes membership has to be stated explicitly.
Intuitively, OWL properties look very much like familiar UML constructs such as associations and attributes. More precisely, OWL datatype properties are reminiscent of UML attributes; the same holds for OWL object properties and UML associations. However, there are three important differences:
owl:inverseOf
statements in
OWL representations to model bidirectionality. http://www.example.org/wine#color
). UML associations and
attributes need not to be unique; it is perfectly legal to use the same
attribute or association name in/between different classes with
different incompatible constraints.
UML note:
Some UML users might think that there is one more difference, namely that
OWL datatype properties can take multiple values, while UML attributes
cannot. The latter is not true however: in the class-attribute box you
can specify, for example, color: string[]
which means
that the the attribute can have any number of values.
The last difference is probably the most difficult one to handle. People used to UML should be aware of the consequence of the global scope of OWL properties. One consequence of this feature is that using a definition like:
:color a owl:DatatypeProperty ; rdfs:domain :Wine .
would imply that
we cannot use this color property for any other class than
wine (and its subclasses). Similarly, if we would define that the
rdfs:range
of color
is {red white
rose}
, then this
would not allow us to specify any other color value
color property. As ontologies are typically meant for sharing and
reuse, this may not be what tie ontology engineer intended.
Guideline:
If you really want to specify a global domain and range for a
property, then choose a property name that makes the intended use
as clear as possible, e.g. wineColor
instead of
color
. This will make life easier for other people
who want to use this ontology.
OWL restrictions provide a way of specifying local domain and range constraints, so should be considered as alternatives whenever you want to specify constraints on a property. The next subsection gives a small worked example which illustrates this.
Suppose we want to construct an ontology about persons and the objects
they create. We use the term Artefact
for objects
that are the result of human activity. Assume we have defined a property
creatorOf
(and its inverse createdBy
) and we
want to use it to link persons to artefacts. So, what do we need to
say about persons with respect to artefact creation? Well, all things
created by persons are artefacts:
:Person a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :creatorOf ; owl:allValuesFrom :Artefact ] .
So, all things created by a person are necessarily
artefacts. Without further restriction, a particular person might
create any number of artefacts, including zero. Let's also take a look
at the definition of Artefact
itself:
:Artefact a owl:Class ; owl:equivalentClass [ a owl:Restriction ; owl:onProperty :createdBy ; owl:someValuesFrom :Person ].
This definition states that artefacts are things that are created by
at least one person (see more about owl:someValuesFrom
in
the next subsection). Like with the RedThing
, this is a
necessary and sufficient condition: if we find out that something is
created by a person, we can derive with certainty that
this thing is an artefact.
Note the difference in style between OWL restrictions and
rdfs:domain/range
constraints:
the former are defined on the class
and only hold for this class; the latter are defined on the property
and thus have a global scope. From an ontology-engineering perspective
the use of OWL restrictions is often more appealing, as it makes less
ontological commitment.
Ontological Commitment. Each statement in an ontology commits the user of this ontology to a particular view of the domain. If a definition in an ontology is stronger than needed, than we say that the ontology is over-committed. For example, if we state that the name of a person must have a first name and a last name we are introducing a western bias into the ontology and may not be able to use the ontology in all intended cases [see, for example, this email discussion on name definitions]. Ontology engineers usually try to define an ontology with a minimal set of ontological commitments. You can translate this into an (oversimplified) slogan: "smaller ontologies are better!". The article of Gruber [Gruber, 1995] gives some principles for minimal commitments.
Ontologies and data models The difference between ontologies and data models does not lie in the language being used: you can define an ontology in a basic ER language (although you will be hampered in what you can say); similarly, you can write a data model with OWL. Writing something in OWL does not make it an ontology! The key difference is not the language the intended use. A data model is a model of the information in some restricted well-delimited application domain, whereas an ontology is intended to provide a set of shared concepts for multiple users and applications. To put it simply: data models live in a relatively small closed world; ontologies are meant for an open, distributed world (hence their importance for the Web). So, defining a name as consisting of a first name and a last name might be perfectly OK in a data model, but may be viewed as incorrect in an ontology. It must be added that there is a tendency to extend the scope of data models, e.g. in large companies, and thus there is an increasing tendency to "ontologize" data models.
One last example: suppose we define artists as a subset of persons who
have created an art object (the latter being
defined as a subclass of artefacts). The
following definition is an initial attempt to define
Artist
:
:Artist a owl:Class ; rdfs:subClassOf :Person ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :creatorOf ; owl:someValuesFrom :ArtObject ] .
With such a definition you have to ask yourself the question: are there persons who have created art objects who we do not consider to be artists? Verify for yourself that the definition is consistent with the existence of such persons. The alternative would have been to make a stronger ontological commitment, as in the following alternative definition:
:RealArtist a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:intersectionOf ( :Person [ a owl:Restriction ; owl:onProperty :creatorOf ; owl:someValuesFrom :ArtObject ]) ] .
This states that all persons who created an art object are artists.
Reading tip: Read the intersection as a logical "AND". So, an artist must be a person AND must belong to the set of things that have created an art object.
We are not going to tell what is the correct modeling choice; universal truths in ontology engineering are rare. Contemporary ontology engineering is really an engineering discipline in which we make choices about how to conceptualize th world from different perspectives, and such choices typically depend on the current perspective. However, it is important to be aware that the second definition makes a stronger ontological commitment.
Guideline: When in doubt about a modeling decision, choose the option which introduces less ontological commitments. It is usually easier to strengthen a definition later, than vice versa.
Code of the example: [RDF/XML] [N3 Turtle]
Typically, OWL property restrictions are described as consisting of two groups, namely:
owl:allValuesFrom
,
owl:someValuesFrom
,
owl:hasValue
owl:cardinality
,
owl:minCardinality
,
owl:maxCardinality
However, this is slightly misleading, as
owl:someValuesFrom
is actually both a value and a
cardinality constraint: it states that the cardinality o certain types
of values must be non-zero. In fact, owl:someValuesFrom
is an
example of an
"qualified cardinality restrictions" (QCRs), where the term
"qualified" means
that we do not express restrictions on the overall number of values of a
property, but only on the number of values of a certain type (i.e.,
class, datatype).
Typically, qualified cardinality restrictions are used to specify
the component types in some part-of structure such as parts of the
human body or membership of a committee. For example, if we want to
say that a selection committee for a job should have at least one
female member, we can state this using owl:someValuesFrom
in the following way:
:SelectionCommittee a owl:Class ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :committeeMember ; owl:allValuesFrom :Person ] . rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :committeeMember ; owl:someValuesFrom :FemalePerson ] .
So, a selection committee has members who are persons and must have at least one female person as its member.
Note that this definition of a selection committee actually allows the comittee to consist of a single female person. In reality, we will probably want to add cardinality constraints about the minimum/maximum size of the committee.
So far, so good. But what if we want to state that the selection
committee should have at least two female committee members? To put is
more general: how do we model QCRs of a cardinality other than "1 or
more" (the case covered by owl:someValuesFrom
)? There is
no direct way of expressing this in OWL. However, there is a common
workaround to achieve this:
owl:allValuesFrom
or rdfs:range
) and a cardinality constraint on the
subproperty, which together specify the QCR. Here is an example of this workaround:
:committeeMemberFemale a owl:ObjectProperty ; rdfs:subPropertyOf :committeeMember . :SelectionCommittee a owl:Class rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :committeeMemberFemale ; owl:allValuesFrom :FemalePerson ] ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty :committeeMemberFemale ; owl:minCardinality "2"^^<http://www.w3.org/2001/XMLSchema#int> ] .
The example defines subproperty of committeeMember
,
intended to represent the subset of female committee
members. Subsequently, the value range and the cardinality of this
subproperty are constrained to represent the fact that there should be
at least two female committee members in a selection committee.
The work-around is OK for simple cases. The workaround really becomes problematic in cases where complicated part-of relations dominate the ontology. Examples could be elaborate anatomical structures, the structure of chemical compounds or the structure of large artifacts such ships or airplanes (see the use cases provided by Rector Rector). Introducing subproperty relations for all the variants is cumbersome. The W3C Web Ontology Working Group has postponed the issue of full representation of QCRs, but has at the same time already suggested a OWL representation for them (see proposal). It is very well possible that a future reincarnation of the OWL group will include this extension into the language. OWL users who require QCRS for describing complex part-whole relations may want to use this extensions, even though these are not yet endorsed.
[Gruber, 1995] Thomas R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. International Journal of Human-Computer Studies, 43(5-6):907-928, 1995. http://tomgruber.org/writing/onto-design.htm
[N3 Turtle] Dave Beckett. Turtle - Terse RDF Triple Language Institute for Learning and Research Technology University of Bristol http://www.ilrt.bris.ac.uk/discovery/2004/01/turtle/
[N-ary relations] Natasha Noy and Alan Rector. Defining N-ary Relations on the Semantic Web: Use With Individuals W3C Working Draft 21 July 2004 Latest version: http://www.w3.org/TR/swbp-n-aryRelations
[OWL Overview] OWL Web Ontology Language Overview. Deborah L. McGuinness and Frank van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/