�ݺ�ߣ

Building OWL Ontologies with Protege
CS 431 – April 9, 2008
Carl Lagoze – Cornell University

Parts extracted with permission from:

Resources
• Protégé ‐ hJp://protege.stanford.edu/
– General open‐source ontology modeling system with OWL plug‐in
– Use the 3.4 beta
– MulSple plug‐ins are available, download full
• Pellet ‐ hJp://pellet.owldl.com/
– Open‐source OWL DL reasoner
– Server‐based (DIG protocol port 8081)
– Integrates with �ʰ��ǳ�é��é‐O�³��

Resources (2)
• CO‐ODE Resources ‐ hJp://www.co‐ode.org/
– Protégé OWL Tutorial ‐ hJp://www.co‐ode.org/
resources/tutorials/protege‐owl‐tutorial.php
– Tutorial: A PracScal IntroducSon to Ontologies &
OWL ‐ hJp://www.co‐ode.org/resources/
tutorials/intro/

What is an Ontology?
• A formal specificaSon of conceptualizaSon
shared in a community
• Vocabulary for defining a set of things that
exist in a world view
• FormalizaSon allows communicaSon across
applicaSon systems and extension
• Global vs. Domain‐specific

Components of an Ontology
• Vocabulary (concepts)
• Structure (aJributes of concepts and hierarchy)
• RelaSonships between concepts
• Logical characterisScs of relaSonships
– Domain and range restricSons
– ProperSes of relaSons (symmetry, transiSvity)
– Cardinality of relaSons
– etc.

Some guiding rules of ontology design
• In most cases there are many ways to model a domain
• Ontology development, like program development, is
by nature iteraSve
• The ontology should closely correspond to the objects
(nouns) and relaSonships (verbs) in the sentences
describing your domain of interest
• When building an ontology we need an applicaSon in
mind – ontologies should not be built for the sake of it
• Keep the applicaSon in mind when creaSng concepts –
this should help you scope the project

Our ApplicaSon
www.co-ode.org/downloads/pizzafinder/

Ontology Design is non‐trivial
• diﬀerent viewpoints
– Tomato – Vegetable or Fruit?
– culinary vs biological
• Ambiguity
– words not concepts
• Missing Knowledge
– What is peperonata?
• mulSple classiﬁcaSons (2+ parents)
• lots of missing categories (superclasses?)
• competency quesSons
– What are we likely to want to “ask” our ontology?
– bear the applicaSon in mind

OWL Constructs:
Classes
Eg Mammal, Tree, Person, Building, Fluid, Company
• Classes are sets of Individuals
• aka “Type”, “Concept”, “Category”
• Membership of a Class is dependent on its logical descripSon, not its name
• Classes do not have to be named – they can be logical expressions – eg
things that have color Blue
• A Class should be described such that it is possible for it to contain
Individuals (unless the intenSon is to represent the empty class)
• Classes that cannot possibly contain any Individuals are said to be
inconsistent

OWL Constructs: ProperSes
Eg hasPart, isInhabitedBy, isNextTo, occursBefore
• ProperSes are used to relate Individuals
• We ohen say that Individuals are related along a given
property
• RelaSonships in OWL are binary:
Subject  predicate  Object
Individual a  hasProperty  Individual b
nick_drummond  givesTutorial  Manchester_ProtegeOWL_tutorial_29_June_2005

OWL Constructs: Individuals
Eg me, you, this lecture, this room
• Individuals are the objects in the domain
• aka “Instance”, “Object”
• Individuals may be (and are likely to be) a
member of mulSple Classes

Components of OWL Ontologies:
Individuals
Unique name assumption: Two individuals are not equivalent
(even if ids are different) unless explicitly stated so (open world)

Components of OWL Ontologies:
ProperSes among Individuals

Components of OWL Ontologies: Classes,
ProperSes, and Individuals
• All individuals must be in a class
• Define sets of individuals

�ʰ��ǳ�é��é‐O�³��

Class Hierarchy Subsumption hierarchy
Structure as asserted by the ontology engineer
owl:Thing is the root class

SubsumpSon
• Superclass/subclass relaSonship, “isa”
• All members of a subclass can be inferred to be members of its
superclasses
owl:Thing: superclass of all OWL Classes
B
A
• A subsumes B
• A is a superclass of B
• B is a subclass of A
• All members of B are also
members of A
Defined explicitly or inferred by
a reasoner

Disjointness
• OWL assumes that classes overlap
MeatTopping VegetableTopping
= individual
► This means an individual could be both a MeatTopping and a
VegetableTopping at the same time
► We want to state this is not the case

Disjointness
• If we state that classes are disjoint
MeatTopping VegetableTopping
= individual
► This means an individual cannot be both a MeatTopping and
a VegetableTopping at the same time
► We must do this explicitly in the interface

ClassesTab: Disjoints Widget
Add siblings as disjoint
Add new disjoint Remove disjoint siblings
List of disjoint classes

RestricSons
• We have created a restricSon: ∃ hasBase PizzaBase
on Class Pizza as a necessary condiSon
► “If an individual is a member of this class, it is necessary that it
has at least one hasBase relationship with an individual from the
class PizzaBase”
Pizza PizzaBase
► “Every individual of the Pizza class must have at least one base
from the class PizzaBase”

What does this mean?
Pizza PizzaBase
► “There can be no individual, that is a member of this class, that
does not have at least one hasBase relationship with an
individual from the class PizzaBase”

∃ hasBase
PizzaBase
Why?
PizzaBase
► Each Restriction or Class Expression describes the set of all
individuals that satisfy the condition

Pizza
Why? Necessary condiSons
► Each necessary condition on a class is a superclass of that class
PizzaBase
∃ hasBase
PizzaBase
► ie The restriction ∃ hasBase PizzaBase is a superclass of Pizza
► As Pizza is a subclass of the restriction, all Pizzas must satisfy
the restriction that they have at least one base from PizzaBase

Consistency Checking
• Create a class that doesn’t really make sense
– What is a MeatyVegetableTopping?
• We’d like to be able to check the logical consistency of
our model
• This is one of the tasks that can be done automaScally
by sohware known as a Reasoner
• Being able to use a reasoner is one of the main
advantages of using a logic‐based formalism such as
OWL (and why we are using OWL‐DL)

Reasoners
• Reasoners are used to infer informaSon that is
not explicitly contained within the ontology
• You may also hear them being referred to as
Classiﬁers
• Standard reasoner services are:
– Consistency Checking
– SubsumpSon Checking
– Equivalence Checking
– InstanSaSon Checking

Reasoners and Protégé
• �ʰ��ǳ�é��é‐O�³��supports the use of reasoners implemenSng the
DIG interface
• This means that the reasoner you choose is independent of
the ontology editor, so you can choose the implementaSon
you want depending on your needs (eg some may be more
opSmised for speed/memory, others may have more features)
• These reasoners typically set up a service running locally or on
a remote server – �ʰ��ǳ�é��é‐O�³��can only connect to reasoners
over an hJp:// connecSon
• We will use Pellet

Accessing the Reasoner
Classify taxonomy
(and check consistency)
Just check consistency
(for efficiency)
Compute inferred types
(for individuals)

Reasoning about our Pizzas
• When we classify an ontology we could just use the “Check Consistency”
bu;on but we’ll get into the habit of doing a full classiﬁca>on as we’ll be
doing this later
• The reasoner dialog will pop up while the
reasoner works
• When the reasoner has ﬁnished, you will see an inferred hierarchy
appear, which will show any movement of classes in the hierarchy
• If the reasoner has inferred anything about our model, this is reported in
the reasoner dialog and in a separate results window
• inconsistent classes turn red
• moved classes turn blue

PrimiSve Classes
• PrimiSve Class = only Necessary CondiSons
• Can not yet judge an individual based on primiSve
classes – why?
Start with
building a
disjoint tree of
primitive
classes

Polyhierarchies
• We want to create a VegetarianPizza
• Some of our exisSng Pizzas should be types of
VegetarianPizza
• However, they could also be types of SpicyPizza or
CheeseyPizza
• We need to be able to give them mulSple parents in a
principled way
• We could just assert mulSple parents like we did with
MeatyVegetableTopping (without disjoints)
BUT…

Asserted Polyhierarchies
In most cases asserSng polyhierarchies is bad
let the reasoner do it!
► We lose some encapsulation of knowledge
► Why is this class a subclass of that one?
► Difficult to maintain
► Adding new classes becomes difficult because all subclasses may
need to be updated
► Extracting from a graph is harder than from a tree

CheeseyPizza
• A CheeseyPizza is any pizza that has some
cheese on it
• We would expect then, that some pizzas
might be named pizzas and cheesey pizzas
(among other things later on)
• We can use the reasoner to help us
produce this polyhierarchy without having
to assert mulSple parents

CreaSng a CheeseyPizza
• We normally create primiSve classes and then migrate them to defined
classes
• All of our defined pizzas will be direct subclasses of Pizza
• So, we create a CheesyPizza Class (do not make it disjoint) and add a
restricSon:
“Every CheeseyPizza must have at least one CheeseTopping”
• Classifying shows that we currently don’t have enough informaSon to do any
classificaSon
► We then move the conditions
from the Necessary block to
the Necessary & Sufficient
block which changes the
meaning
► And classify again…

Reasoner ClassiﬁcaSon
• The reasoner has been able to infer that anything that is a Pizza that
has at least one topping from CheeseTopping is a CheeseyPizza
► The inferred hierarchy is
updated to reflect this and
moved classes are highlighted
in blue

Why?
Necessary & Suﬃcient CondiSons
► Each set of necessary & suﬃcient condiSons is an Equivalent Class
► CheeseyPizza is equivalent to the intersection of Pizza and ∃ hasTopping
CheeseTopping
► Classes, all of whose individuals fit this definition are found to be subclasses of
CheeseyPizza, or are subsumed by CheeseyPizza
Pizza
∃ hasTopping
CheeseTopping
CheeseyPizza

Untangling
• We can see that certain Pizzas are now
classiﬁed under mulSple parents
• MargheritaPizza can be found under both
NamedPizza and CheeseyPizza in the
inferred hierarchy
Mission Successful!

Untangling
• However, our unclassiﬁed version of the
ontology is a simple tree, which is much easier
to maintain
• We’ve now got a polyhierarchy without
asserSng mulSple superclass relaSonships
• Plus, we also know why certain pizzas have
been classiﬁed as CheeseyPizzas

Untangling
• We don’t currently have many kinds of
primiSve pizza but its easy to see that if we
had, it would have been a substanSal task to
assert CheeseyPizza as a parent of lots, if not
all, of them
• And then do it all over again for other deﬁned
classes like MeatyPizza or whatever

Viewing polyhierarchies
• As we now have
mulSple
inheritance, the
tree view is less
than helpful in
viewing our
“hierarchy”

�վ��ɾ��Բ��ǳܰ��ᾱ��Ұ��󾱳��

OWLViz Tab
Polyhierarchy
tangle
View Inferred ModelView Asserted Model
Show All Classes

Using OWLViz to untangle
• The asserted hierarchy should, ideally, be a
Sdy tree of disjoint primiSves
• The inferred hierarchy will be tangled
• By switching from the asserted to the inferred
hierarchy, it is easy to see the changes made
by the reasoner
• OWLViz can be used to spot tangles in the
primiSve tree and also disjoints (including
inherited ones) are marked (with a ¬)

Defined Classes
• We’ve created a Defined Class, CheeseyPizza
– It has a definiSon. That is at least one Necessary and Sufficient condiSon
– Classes, all of whose individuals saSsfy this definiSon, can be inferred to be
subclasses
– Therefore, we can use it like a query to “collect” subclasses that saSsfy its condiSons
– Reasoners can be used to organise the complexity of our hierarchy
• It’s marked with an equivalence symbol in the interface
• Defined classes are rarely disjoint

Define a Vegetarian Pizza
• Not as easy as it looks…
• Define in words?
– “a pizza with only vegetarian toppings”?
– “a pizza with no meat (or fish) toppings”?
– “a pizza that is not a MeatyPizza”?
• More than one way to model this
We’ll start with the first example

Deﬁne a Vegetarian Pizza
To be able to deﬁne a vegetarian pizza as
a Pizza with only Vegetarian Toppings
we need:
1. To be able to create a vegetarian topping
This requires a Union Class
2. To be able to say “only”
This requires a Universal RestricSon

• aka “disjuncSon”
• This OR That OR TheOther
• This That TheOther
Union Classes
► Commonly used for:
► Covering axioms
► Closure
A
B
A B includes all
individuals of class A and
all individuals from class B
and all individuals in the
overlap (if A and B are not
disjoint)

Covering Axioms
• Covering axiom – a union expression containing several covering
classes
• A covering axiom in the Necessary & Suﬃcient CondiSons of a class
means:
the class cannot contain any instances other than those from the
covering classes
• NB. If the covering classes are subclasses of the covered class, the
covering axiom only needs to be a Necessary condiSon – it doesn’t
harm to make it Necessary & Suﬃcient though – its just redundant

Covering PizzaBase
• In this example, the class PizzaBase is
covered by ThinAndCrispy or
DeepPan
• “All PizzaBases must be
ThinAndCrispy or DeepPan”
• “There are no other types of
PizzaBase”
PizzaBase
DeepPan
ThinAndCrispy
PizzaBase ≡ ThinAndCrispy DeepPan

Universal RestricSons
• We need to say our VegetarianPizza can only
have toppings that are vegetarian toppings
• We can do this by creaSng a Universal or
AllValuesFrom restricSon
• �±�’l��ﬁr��Ǵǰ��油��…

Real Italian Pizzas
• “RealItalianPizzas only have bases that are
ThinAndCrispy”
• A Universal RestricSon is
added just like an
ExistenSal one, but the
restricSon type is diﬀerent
• For now, this can be primiSve – you can make it
deﬁned if you like

must only have a hasBase relationship with an individual from
the class ThinAndCrispy”
RealItalianPizza ThinAndCrispy
► We have created a restriction: ∀ hasBase ThinAndCrispy on
Class RealItalianPizza as a necessary condition

DeepPan RealItalianPizza ThinAndCrispy
► “No individual of the RealItalianPizza class can have a base
from a class other than ThinAndCrispy”
► NB. DeepPan and ThinAndCrispy are disjoint
► We have created a restriction: ∀ hasBase ThinAndCrispy on
Class RealItalianPizza as a necessary condition

Warning: Trivial SaSsfacSon
RealItalianPizza ThinAndCrispy
must only have a hasBase relationship with an individual from
the class ThinAndCrispy, or no hasBase relationship at all”
Trivially
satisfied
by this
individual
► Universal Restrictions by themselves do not state “at least one”
► If we had not already inherited: ∃ hasBase PizzaBase
from Class Pizza the following could hold

VegetarianPizza ClassificaSon
• Nothing classifies under VegetarianPizza
• Actually, there is nothing wrong with our definiSon of VegetarianPizza
• It is actually the descripSons of our Pizzas that are incomplete
• The reasoner has not got enough informaSon to infer that any Pizza is
subsumed by VegetarianPizza
• This is because OWL makes the Open World AssumpSon

Open World AssumpSon
• In a closed world (like DBs), the informaSon we have is everything
• In an open world, we assume there is always more informaSon than is
stated
• Where a database, for example, returns a negaSve if it cannot ﬁnd some
data, the reasoner makes no assumpSon about the completeness of the
informaSon it is given
• The reasoner cannot determine something does not hold unless it is
explicitly stated in the model

Open World AssumpSon
• Typically we have a paJern of several ExistenSal
restricSons on a single property with diﬀerent
ﬁllers – like primiSve pizzas on hasTopping
• ExistenSal restricSons should be paraphrased by
“amongst other things…”
• Must state that a descripSon is complete
• We need closure for the given property

Closure
• This is in the form of a Universal RestricSon
with a ﬁller that is the Union of the other
ﬁllers for that property
• Closure works along a single property

Closure example: MargheritaPizza
All MargheritaPizzas must have:
at least 1 topping from MozzarellaTopping and
at least 1 topping from TomatoTopping and
only toppings from MozzarellaTopping or TomatoTopping
• The last part is paraphrased into “no other toppings”
• The union closes the hasTopping property on MargheritaPizza

�ݺ�ߣ

Lecture 4-09-08

Convert to study guideBETA

More Related Content

Lecture 4-09-08