Ontology Languages for
Dr. Murat Osman ÜNALIR
For the semantic web to function, computers
must have access to
structured collections of information and
sets of inference rules
They can use these to conduct automated
AI researchers have studied such systems since
long before the Web was developed
Knowledge representation is currently in a state
comparable to that of hypertext before the advent of
it is clearly a good idea, and some very nice demonstrations
but it has not yet changed the world
It contains the seeds of important applications, but to
realize its full potential it must be linked into a single
The Semantic Web
Traditional knowledge-representation systems
typically have been centralized
Requiring everyone to share exactly the same
definition of common concepts such as "parent"
But central control is stifling and increasing the
size and scope of such a system rapidly becomes
Knowledge representation systems usually
carefully limit the questions that can be asked so
that the computer can answer reliably— or
answer at all.
The problem is reminiscent of Gödel's theorem
any system that is complex enough to be useful also
encompasses unanswerable questions
much like sophisticated versions of the basic
paradox "This sentence is false."
To avoid such problems, traditional knowledge
representation systems generally have their own set of
rules for making inferences about their data
For example, a genealogy system, acting on a database
of family trees, might include the rule "a wife of an
uncle is an aunt"
Even if the data could be transferred from one system
to another, the rules, existing in a completely different
form, usually could not
Semantic Web researchers, in contrast, accept that
paradoxes and unanswerable questions are a price that
must be paid to achieve versatility
They make the language for the rules as expressive as
needed to allow the Web to reason as widely as desired
This philosophy is similar to that of the conventional
early in the Web's development, detractors pointed out that it
could never be a well-organized library
without a central database and tree structure, one would
never be sure of finding everything
They were right
The expressive power of the Web made vast amounts
of information available
Search engines now produce remarkably complete
indices of a lot of the material out there
(which would have seemed quite impractical a decade ago)
The challenge of the Semantic Web, therefore, is to
provide a language that expresses both data and rules
for reasoning about the data and that allows rules from
any existing knowledge representation system to be
exported onto the Web
Adding logic to the Web means to use rules to
choose courses of action and
This the task before the Semantic Web
community at the moment.
A mixture of mathematical and engineering
decisions complicate this task
The logic must be powerful enough
to describe complex properties of objects
but not so powerful that agents can be tricked by
being asked to consider a paradox
Fortunately, a large majority of the information
we want to express is along the lines of
"a hex-head bolt is a type of machine bolt"
this is readily written in existing languages with a
little extra vocabulary
Two important technologies for developing the Semantic Web
are already in place
eXtensible Markup Language (XML) and
the Resource Description Framework (RDF)
XML lets everyone create their own tags
hidden labels that annotate Web pages or sections of text on a page
scripts, or programs, can make use of these tags in sophisticated ways, but
the script writer has to know what the page writer uses each tag for
XML allows users to add arbitrary structure to their documents
but says nothing about what the structures mean
Meaning is expressed by RDF
which encodes it in sets of triples
each triple being rather like the subject, verb and object of an
These triples can be written using XML tags
In RDF, a document makes assertions that
particular things (people, Web pages or whatever) have
properties (such as "is a sister of," "is the author of") with
certain values (another person, another Web page)
This structure turns out to be a natural way to describe
the vast majority of the data processed by machines
Subject and object are each identified by a Universal
Resource Identifier (URI)
just as used in a link on a Web page
(URLs, Uniform Resource Locators, are the most common
type of URI)
The verbs are also identified by URIs
this enables anyone to define
a new concept
a new verb
just by defining a URI for it somewhere on the Web
Human language thrives when using the same term to
mean somewhat different things, but automation does
Imagine that a clown messenger service is hired to
deliver balloons to customers on their birthdays
Unfortunately, the service transfers the addresses from
the customer’s database to its own database,
It does not know that the "addresses" in the customer’s
database are where bills are sent and that many of them
are post office boxes
The hired clowns end up entertaining a number of
not necessarily a bad thing but certainly not the intended
Using a different URI for each specific concept solves
An address that is a mailing address can be
distinguished from one that is a street address, and both
can be distinguished from an address that is a speech
The triples of RDF form webs of information
about related things
RDF uses URIs to encode this information in a
URIs ensure that concepts are not just words in
a document but are tied to a unique definition
that everyone can find on the Web
For example, imagine that we have access to a variety
of databases with information about people, including
If we want to find people living in a specific zip code,
we need to know which fields in each database
names and which represent
RDF can specify that "(field 5 in database A) (is a field
of type) (zip code)," using URIs rather than phrases for
What is RDF?
RDF is an XML based language to describe
A particularly good use of RDF is to describe
resources, which are “opaque” like images or
RDFPic is an application to embed RDF meta
data inside JPEG images.
There are many serializations of the RDF Model
Triples: The RDF description model uses subject-
attribute (predicate, property)-object triples. These
triples are known as statements
RDF Graph: Directed Labelled Graphs
RDF/XML Syntax: RDF is essentially a data model
and does not strive to replace XML. Instead, it
builds a layer on top of it, making interoperable
exchange of semantic information possible
Capturing Knowledge with RDF
Four different scenarios where we express
As natural language sentences
In a simple triple notation called N3
In RDF/XML serialization format (triple-based
As a graph of the triples
Natural Language Sentences
Buddy Belden owns a business.
The business has a Web site accessible at
Buddy is the father of Lynne.
Sentences in N3 Notation
<#Buddy> <#owns> <#business>.
<#Buddy> <#father-of> <#Lynne>
RDF/XML and RDF Graph
Listing 5.2 RDF/XML generated from N3
Figure 5.4 Graph of N3 Notation
Other RDF Features
A simple container
Reification: making statements about statements
Types of RDF Containers
There is often need to represent groups of things.
A book created with several authors
The students in a course
Software modules in a package
RDF provides three predefined types for representing
rdf:Bag : unordered, allows duplicate
rdf:Seq : ordered, allows duplicates
A Bag is intended to represent an unordered group of resources or
literals, possibly including duplicates.
The students in course 6.001 are Amy, Tim, John, Mary and Sue.
An Alternative or Alt is intended to represent an ordered group of
resources or literals that represent alternative values.
The source code for X11 may be found at ftp.example.org,
ftp.example1.org, or ftp.example2.org .
Most systems treat data as facts
Reification treat data as assertions
Reification is not simple. Statements about
statements are too complex. Figure 5.6, Listing
Reification has not yet proven itself
Several RDF implementations and knowledge
bases disallow the use of reification.
Why is RDF Not in the Mainstream
Figure 5.7 RDF Adoption
RDF does not yet play well with XML
Parts of RDF are complex
Early RDF examples are weak
“XML/XHTML is incompatible
with RDF” is not true
The business travelling along the XML/XHTML path
assume that their direction is incompatible with the
This is not true. The fact that RDF is serialized as XML
means that both XML Schema and RDF share a
W3C resolves differences so that RDF can be
successfully embedded in XHTML and XML
Several tools to mix RDF and HTML (SMORE)
Parts of RDF are Complex
The serialization syntax
Linguistic, object-oriented, relational data (Table
Good because it unifies modelling concepts
from different domains
Bad it causes confusion. Inexact or poor
mapping to the original concepts specified by
The Serialization Syntax
Two much flexibility is a problem for validation.
Early RDF Examples are Weak
Dublin Core, RDF Site Summary (RSS) do not
highlight the unique characteristics of RDF.
Dublin Core elements are not exclusive to RDF
and can be used in HTML or XML documents.
RSS is an XML syntax that has flip-flopped
between an RDF Syntax and XML Schema
RSS do not highlight the RDF’s main strength:
Primary Reasons that RDF’s
Adoption will Grow
Improved Tool Support
Improved XML Schema Integration
Ontologies : RDFS
What is RDF Schema
An extensible, object-
oriented type system
(known as RDF Schema)
is introduced as a layer
on top of the basic RDF
Capabilities of RDFS
Class definitions can be derived from multiple
Property definitions can specify domain and
We can also think of RDFS as a set of
ontological modelling primitives on top of RDF.
Key Components of RDFS
UML Class Diagram of Employee
Expertise (Listing 5.6)
System-Analyst Software-Engineer Technology
What is Non-contextual Modelling?
Fixed context: reduce errors and increase the
throughput. In the XML.org schema there are many
specific document types for each vertical industry.
XML documents have a fixed context provided by their
root element and governing schema.
Neither the environment are stable nor the volume is
high. Flexibility and non-contextual modelling is the
best choice. Non-contextual modelling is a continuum
and not a single point.
Key Aspects of
Non-contextual Modelling uses explicit versus implicit
relationships: XML does not state the relationships
between the name and value pairs. RDF uses explicit
relationship between the name and the value.
A graph is less brittle than a tree: The order is not
important in RDF so an RDF list of statements is less
affected by change and less brittle.
It is necessary to go beyond keywords and
specify the meaning of the resources described
on the Web.
This additional layer of interpretation captures
the semantics of the data.
The OWL Web Ontology Language is a
language for defining and instantiating Web
What does this buy me that XML
and XML Schema don't?
An ontology differs from an XML schema in that it is a
knowledge representation, not a message format.
Most industry based Web standards consist of a
combination of message formats and protocol
But the specification is not designed to support
reasoning outside the transaction context. For example,
we won't in general have a mechanism to conclude that
because the Product is a type of Chardonnay it must
also be a white wine.
What does this buy me that XML
and XML Schema don't?
One advantage of OWL ontologies will be the
availability of tools that can reason about them.
Tools will provide generic support that is not specific to
the particular subject domain, which would be the case
if one were to build a system to reason about a specific
industry-standard XML schema.
Building a sound and useful reasoning system is not a
simple effort. Constructing an ontology is much more
The Species of OWL
OWL Full Full
It is unlikely that any
reasoning software will be
able to support every feature
of OWL Full.
The Structure of Ontologies
Instances of classes
Relationships between these instances
Simple Classes and Individuals
Many uses of an ontology will depend on the
ability to reason about individuals.
In order to do this in a useful fashion we need
to have a mechanism to describe the classes that
individuals belong to and the properties that
they inherit by virtue of class membership.
We can always assert specific properties about
individuals, but much of the power of
ontologies comes from class-based reasoning.
Extension of Class
Sometimes we want to emphasize the distinction
between a class as an object and a class as a set
We call the set of individuals that are members
of a class the extension of the class.
Simple Named Classes
The most basic concepts in a domain should
correspond to classes that are the roots of
various taxonomic trees.
Every individual in the OWL world is a member
of the class owl:Thing. Thus each user-defined
class is implicitly a subclass of owl:Thing.
Domain specific root classes are defined by
simply declaring a named class.
OWL also defines the empty class, owl:Nothing.
For our sample wines domain, we create three
root classes: Winery, Region, and
Formally, we know almost nothing about these
classes other than their existence, despite the use
of familiar English terms as labels.
And while the classes exist, they may have no
For all we know at the moment, these classes
might as well have been called Thing1, Thing2,
The syntax rdf:ID="Region" is used to
introduce a name, as part of its definition.
Within this document, the Region class can now
be referred to using #Region, e.g.
Other ontologies may reference this name using
its complete form,
We can refer to the winery class either using the
XML tag vin:Winery or the attribute value
More literally, it is always possible to reference a
resource using its full URI, here
The fundamental taxonomic constructor for
classes is rdfs:subClassOf.
It relates a more specific class to a more general
class. If X is a subclass of Y, then every instance
of X is also an instance of Y.
The rdfs:subClassOf relation is transitive. If X is
a subclass of Y and Y a subclass of Z then X is a
subclass of Z.
The rdfs:label entry provides an optional human
readable name for this class.
Presentation tools can make use of it.
The "lang" attribute provides support for
A label is like a comment and contributes
nothing to the logical interpretation of an
In addition to classes, we want to be able to
describe their members. We normally think of
these as individuals in our universe of things. An
individual is minimally introduced by declaring it
to be a member of a class.
<Region rdf:ID="CentralCoastRegion" />
Note that the following is identical in meaning to the
example in the preceeding slide.
<owl:Thing rdf:ID="CentralCoastRegion" />
rdf:type is an RDF property that ties an individual to a
class of which it is a member.
Classes and Individuals
This world of classes and individuals would be
pretty uninteresting if we could only define
Properties let us assert general facts about the
members of classes and specific facts about
A property is a binary relation. Two types of
properties are distinguished:
datatype properties, relations between instances of
classes and RDF literals and XML Schema datatypes
object properties, relations between instances of
When we define a property there are a number
of ways to restrict the relation.
The domain and range can be specified.
The property can be defined to be a
specialization (subproperty) of an existing
Domains and Ranges
The property madeFromGrape has a domain of
Wine and a range of WineGrape.
That is, it relates instances of the class Wine to
instances of the class WineGrape.
Multiple domains mean that the domain of the
property is the intersection of the identified
classes (and similarly for range).
Difference with Programming
Note that the use of range and domain information in OWL is
different from type information in a programming language.
Among other things, types are used to check consistency in a
In OWL, a range may be used to infer a type. For example,
<madeFromGrape rdf:resource="#ChardonnayGrape" />
We can infer that LindemansBin65Chardonnay is a wine because
the domain of madeFromGrape is Wine.
Properties, like classes, can be arranged in a
The rdfs:subPropertyOf relation in the example
in next slide means that anything with a
hasColor property with value X also has a
hasWineDescriptor property with value X.
<owl:Class rdf:ID="WineDescriptor" />
<rdfs:subClassOf rdf:resource="#WineDescriptor" />
<rdfs:domain rdf:resource="#Wine" />
<rdfs:range rdf:resource="#WineDescriptor" />
<rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
<rdfs:range rdf:resource="#WineColor" />
Properties and Datatypes
We distinguish properties according to whether they
relate individuals to individuals (object properties) or
individuals to datatypes (datatype properties).
Datatype properties may range over RDF literals or
simple types defined in accordance with XML Schema
OWL uses most of the built-in XML Schema datatypes.
References to these datatypes are by means of the URI
reference for the datatype,
Properties of Individuals
<hasMaker rdf:resource="#SantaCruzMountainVineyard" />
It is possible to specify property characteristics,
which provides a powerful mechanism for
enhanced reasoning about a property.
If a property, P, is specified as transitive then for
any x, y, and z:
P(x,y) and P(y,z) implies P(x,z)
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdfs:domain rdf:resource="&owl;Thing" />
<rdfs:range rdf:resource="#Region" />
<locatedIn rdf:resource="#CaliforniaRegion" />
<locatedIn rdf:resource="#USRegion" />
Because the SantaCruzMountainsRegion is locatedIn the CaliforniaRegion, then it
must also be locatedIn the USRegion, since locatedIn is transitive.
If a property, P, is tagged as symmetric then for
any x and y:
P(x,y) iff P(y,x)
<rdf:type rdf:resource="&owl;SymmetricProperty" />
<rdfs:domain rdf:resource="#Region" />
<rdfs:range rdf:resource="#Region" />
<locatedIn rdf:resource="#CaliforniaRegion" />
<adjacentRegion rdf:resource="#SonomaRegion" />
The MendocinoRegion is adjacent to the SonomaRegion and vice-versa. The
MendocinoRegion is located in the CaliforniaRegion but not vice versa.
If a property, P, is tagged as functional then for
all x, y, and z:
P(x,y) and P(x,z) implies y = z
<owl:Class rdf:ID="VintageYear" />
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#VintageYear" />
If a property, P, is tagged as InverseFunctional
then for all x, y and z:
P(y,x) and P(z,x) implies y = z
Think of the elements of the range in an inverse
functional property as defining a unique key in
the database sense.
owl:InverseFunctional implies that the elements
of the range provide a unique identifier for each
element of the domain.
In addition to designating property
characteristics, it is possible to further constrain
the range of a property in specific contexts in a
variety of ways.
We do this with property restrictions. The
various forms described below can only be used
within the context of an owl:Restriction. The
owl:onProperty element indicates the restricted
allValuesFrom & someValuesFrom
We have already seen one way to restrict the
types of the elements that make up a property.
The mechanisms to date have been global in
that they apply to all instances of the property.
These next two, allValuesFrom and
someValuesFrom, are local to their containing
The owl:allValuesFrom restriction requires that
for every instance of the class that has instances
of the specified property, the values of the
property are all members of the class indicated
by the owl:allValuesFrom clause.
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
<owl:onProperty rdf:resource="#hasMaker" />
<owl:allValuesFrom rdf:resource="#Winery" />
The maker of a Wine must be a Winery. The allValuesFrom restriction is on
the hasMaker property of this Wine class only. Makers of Cheese are not
constrained by this local restriction.
owl:someValuesFrom is similar.
If we replaced owl:allValuesFrom with
owl:someValuesFrom in the example above, it
would mean that at least one of the hasMaker
properties of a Wine must point to an individual
that is a Winery.
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
<owl:onProperty rdf:resource="#hasMaker" />
<owl:someValuesFrom rdf:resource="#Winery" />
allValuesFrom and someValuesFrom
The difference between the two formulations is the difference
between a universal and existential quantification.
The first does not require a wine to have a maker. If it does have
one or more, they must all be wineries. The second requires that
there be at least one maker that is a winery, but there may be
makers that are not wineries.
allValuesFrom For all wines, if they have makers, all the
makers are wineries.
someValuesFrom For all wines, they have at least one maker
that is a winery.
owl:cardinality which permits the specification
of exactly the number of elements in a relation
owl:maxCardinality can be used to specify an
owl:minCardinality can be used to specify a
In combination, the two can be used to limit the
property's cardinality to a numeric interval.
hasValue allows us to specify classes based on
the existence of particular property values.
Hence, an individual will be a member of such a
class whenever at least one of its property values
is equal to the hasValue resource.
In order for ontologies to have the maximum
impact, they need to be widely shared. In order
to minimize the intellectual effort involved in
developing an ontology they need to be re-used.
In the best of all possible worlds they need to be
composed. For example, you might adopt a date
ontology from one source and a physical
location ontology from another and then extend
the notion of location to include the time period
during which it holds.
It is important to realize that much of the effort of
developing an ontology is devoted to hooking together
classes and properties in ways that maximize
We want simple assertions about class membership to
have broad and useful implications. This is the hardest
part of ontology development. If you can find an
existing ontology that has already undergone extensive
use and refinement, it makes sense to adopt it.
It will be challenging to merge a collection of
ontologies. Tool support will almost certainly be
required to maintain consistency.
Classes and Properties
To tie together a set of component ontologies as
part of a third it is frequently useful to be able to
indicate that a particular class or property in one
ontology is equivalent to a class or property in a
This capability must be used with care. If the
combined ontologies are contradictory (all A's
are B's vs. all A's are not B's) there will be no
extension (no individuals and relations) that
satisfies the resulting combination.
Class Expressions and
We have already seen that class expressions can
be the targets of rdfs:subClassOf constructors.
They can also be the target of
Again, this avoids the need to contrive names
for every class expression and provides a
powerful definitional capability based on
satisfaction of a property
equivalentClass and subClassOf
The difference between using owl:equivalentClass here and using
rdfs:subClassOf is the difference between a necessary condition
and a necessary and sufficient condition.
With subClassOf, things that are located in Texas are not
But, using owl:equivalentClass, if something is located in Texas,
then it must be in the class of TexasThings.
subClassOf TexasThings(x) implies locatedIn(x,y) and TexasRegion(y)
equivalentClass TexasThings(x) implies locatedIn(x,y) and TexasRegion(y)
locatedIn(x,y) and TexasRegion(y) implies TexasThings(x)
Identity between Individuals
This mechanism is similar to that for classes, but
declares two individuals to be identical.
OWL does not have a unique name assumption.
Just because two names are different does not
mean they refer to different individuals.
sameAs asserts identity between two distinct
This mechanism provides the opposite effect from
<vin:WineColor rdf:about="#Red" />
<vin:WineColor rdf:about="#White" />
<vin:WineColor rdf:about="#Rose" />
OWL provides additional constructors with
which to form classes.
These constructors can be used to create so-
called class expressions.
OWL supports the basic set operations, namely
union, intersection and complement.
Additionally, classes can be enumerated.
And it is possible to assert that class extensions
must be disjoint.
Note that Class expressions can be nested
without requiring the creation of names for
every intermediate class.
This allows the use of set operations to build up
complex classes from anonymous classes or
classes with value restrictions.
Remember that OWL class extensions are sets
consisting of the individuals that are members of
OWL provides the means to manipulate class
extensions using basic set operators.
Classes constructed using the set operations are
more like definitions than anything we have seen
The members of the class are completely
specified by the set operation.
<owl:Class rdf:about="#Wine" />
<owl:onProperty rdf:resource="#hasColor" />
<owl:hasValue rdf:resource="#White" />
The construction above states that WhiteWine is
exactly the intersection of the class Wine and the set of
things that are white in color.
This means that if something is white and a wine, then
it is an instance of WhiteWine.
Without such a definition we can know that white
wines are wines and white, but not vice-versa.
This is an important tool for categorizing individuals.
The following example demonstrates the use of the
It is used exactly like the intersectionOf construct:
<owl:Class rdf:about="#SweetFruit" />
<owl:Class rdf:about="#NonSweetFruit" />
The complementOf construct selects all individuals
from the domain of discourse that do not belong to a
certain class. Usually this refers to a very large set of
<owl:Class rdf:ID="ConsumableThing" />
<owl:complementOf rdf:resource="#ConsumableThing" />
OWL provides the means to specify a class via a
direct enumeration of its members.
This is done using the oneOf construct.
Notably, this definition completely specifies the
class extension, so that no other individuals can
be declared to belong to the class.
The first thing to understand here is that no
other individuals can be a valid WineColor since
the class has been defined by enumeration
The disjointness of a set of classes can be expressed
using the owl:disjointWith constructor. It guarantees
that an individual that is a member of one class cannot
simultaneously be an instance of a specified other class.
The Pasta example demonstrates multiple
disjoint classes. Note that this only asserts that
Pasta is disjoint from all of these other classes. It
does not assert, for example, that Meat and Fruit
are disjoint. In order to assert that a set of
classes is mutually disjoint, there must be an
owl:disjointWith assertion for every pair.
Ontologies are like software, they will be
maintained and thus will change over time.
Within an owl:Ontology element, it is possible
to link to a previous version of the ontology
The owl:priorVersion property is intended to
provide this link, and can be used to track the
version history of an ontology.
Ontology versions may not be compatible with
each other. For example, a prior version of an
ontology may contain statements that contradict
the current version.
Within an owl:Ontology element, we use the
tags owl:backwardCompatibleWith and
owl:incompatibleWith to indicate compatibility
or the lack thereof with previous ontology
If owl:backwardCompatibleWith is not declared,
then compatibility should not be assumed.
In addition, owl:versionInfo provides a hook
suitable for use by versioning systems.
As opposed to the previous three tags, the
object of owl:versionInfo is a literal and the tag
can be used to annotate classes and properties in
addition to ontologies.