Building OWL Ontologies with Protégé (2) 

CS 431 – April 14, 2008 
Carl Lagoze – Cornell University 
Parts extracted with permission from:
Parts extracted with permission from:
 RestricJons 
•  We have created a restricJon: ∃ hasBase PizzaBase 
on Class Pizza as a necessary condiJon 

Pizza PizzaBase

► “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”
► “Every individual of the Pizza class must have at least one base
from the class PizzaBase”
 Why? Necessary condiJons 
•  We have created a restricJon: ∃ hasBase PizzaBase 
on Class Pizza as a necessary condiJon 

Pizza PizzaBase
∃ hasBase
PizzaBase

► Each necessary condition on a class is a superclass of that class

► 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 automaJcally 
by soVware 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) 

•  We will use Pellet (server‐based DIG reasoner) 
Accessing the Reasoner 
Classify taxonomy
(and check consistency)

Compute inferred types

(for individuals)

Just check consistency

(for efficiency)
 Reasoning about our Pizzas 
•  When we classify an ontology we could just use the “Check Consistency” 
bu9on but we’ll get into the habit of doing a full classifica<on as we’ll be 
doing this later 

•  The reasoner dialog will pop up while the 
reasoner works 

•  When the reasoner has finished, 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 
 PrimiJve Classes 
•  PrimiJve Class = only Necessary CondiJons 
•  Can not yet judge an individual based on primiJve 
classes – why? 

Start with
building a
disjoint tree of
primitive
classes
 Defined Classes 
•  We want to be able to definiJvely type some 
thing 
– E.g., “I know it’s a Cheesy Pizza because it has 
cheese on it” 
•  Note that this is different from “A Cheesy Pizza must 
have cheese on it”  
 CreaJng a CheeseyPizza 
•  So, we create a CheesyPizza Class (do not make it disjoint) 
and add a restricJon: 
“Every CheeseyPizza must have at least one CheeseTopping” 
•  Classifying shows that we currently don’t have enough 
informaJon to do any classificaJon 

►  We then move the conditions

from the Necessary block to
the Necessary & Sufficient
block which changes the
meaning

►  And classify again…

 Reasoner ClassificaJon 
•  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 & Sufficient CondiJons 
►  Each set of necessary & sufficient condiJons is an Equivalent Class 

∃ hasTopping
Pizza CheeseTopping

CheeseyPizza

►  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
 Defined Classes 
•  We’ve created a Defined Class, CheeseyPizza 

–  It has a definiJon. That is at least one Necessary and Sufficient condiJon 
–  Classes, all of whose individuals saJsfy this definiJon, can be inferred to be 
subclasses 
–  Therefore, we can use it like a query to “collect” subclasses that saJsfy its condiJons 
–  Reasoners can be used to organise the complexity of our hierarchy 

•  It’s marked with an equivalence symbol in the interface 
 Polyhierarchies 
•  Note that just because a Pizza is a CheesyPizza it can be 
another type of Pizza 
•  Take a look at Interes7ngPizza 

•  We need to be able to give them mulJple parents in a 
principled way 
•  We could just assert mulJple parents 

BUT…
 Asserted Polyhierarchies 
In most cases asserJng polyhierarchies is bad 

► 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

let the reasoner do it!

 Untangling 
•  We can see that certain Pizzas are now 
classified under mulJple parents 

•  MargheritaPizza can be found under both 
NamedPizza and CheeseyPizza in the 
inferred hierarchy 

Mission Successful!
 Untangling 
•  However, our unclassified version of the 
ontology is a simple tree, which is much easier 
to maintain 

•  We’ve now got a polyhierarchy without 
asserJng mulJple superclass relaJonships 
•  Plus, we also know why certain pizzas have 
been classified as CheeseyPizzas 
 Untangling 
•  We don’t currently have many kinds of 
primiJve pizza but its easy to see that if we 
had, it would have been a substanJal task to 
assert CheeseyPizza as a parent of lots, if not 
all, of them 

•  And then do it all over again for other defined 
classes like MeatyPizza or whatever 
 Viewing polyhierarchies 

•  As we now have 
mulJple 
inheritance, the 
tree view is less 
than helpful in 
viewing our 
“hierarchy” 
Viewing our Hierarchy Graphically 
 OWLViz Tab 
Show All Classes
View Asserted Model View Inferred Model

Polyhierarchy
tangle
 Using OWLViz to untangle 
•  The asserted hierarchy should, ideally, be a 
Jdy tree of disjoint primiJves 
•  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 
primiJve tree and also disjoints (including 
inherited ones) are marked (with a ¬) 
Universal RestricJon 
 Universal RestricJons 
•  “RealItalianPizzas only have bases that are 
ThinAndCrispy” 

•  A Universal RestricJon is 
added just like an 
ExistenJal one, but the 
restricJon type is different 
 What does this mean? 
►  We have created a restriction: ∀ hasBase ThinAndCrispy on
Class RealItalianPizza as a necessary condition

RealItalianPizza ThinAndCrispy

► “If an individual is a member of this class, it is necessary that it

must only have a hasBase relationship with an individual from
the class ThinAndCrispy”
 What does this mean? 
►  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
 Warning: Trivial SaJsfacJon 
►  If we had not already inherited: ∃ hasBase PizzaBase
from Class Pizza the following could hold

RealItalianPizza ThinAndCrispy
Trivially
satisfied
by this
individual

► “If an individual is a member of this class, it is necessary that it

must only have a hasBase relationship with an individual from
the class ThinAndCrispy, or no hasBase relationship at all”
► Universal Restrictions by themselves do not state “at least one”
Extending universal restricJons with 
union classes and covering axioms 
 Define a Vegetarian Pizza 
To be able to define a vegetarian pizza as 
a Pizza with only Vegetarian Toppings 

we need: 

1.  To be able to say “only” 
This requires a Universal RestricJon 
2.  To be able to create a vegetarian topping 
This requires a Union Class 
 Union Classes 
•  aka “disjuncJon” 
•  This OR That OR TheOther 
•  This      That     TheOther 
B
A B includes all A
individuals of class A and
all individuals from class B
and all individuals in the
overlap (if A and B are not
disjoint)

►  Commonly used for:

►  Covering axioms
►  Closure
 Covering Axioms 
•  Covering axiom – a union expression containing several covering 
classes 

•  A covering axiom in the Necessary & Sufficient CondiJons of a class 
means: 
the class cannot contain any instances other than those from the 
covering classes 
 VegetarianPizza ClassificaJon 

•  How come a Margherita pizza is not classified under VegetarianPizza 

•  Actually, there is nothing wrong with our definiJon of VegetarianPizza 
•  It is actually the descripJon of Margherita that is incomplete 

•  The reasoner has not got enough informaJon to infer that Margherita is 
subsumed by VegetarianPizza. Why? 

•  This is because OWL makes the Open World AssumpJon 
 Open World AssumpJon 
•  In a closed world (like DBs), the informaJon we have is everything  
•  In an open world, we assume there is always more informaJon than is 
stated 

•  Where a database, for example, returns a negaJve if it cannot find some 
data, the reasoner makes no assumpJon about the completeness of the 
informaJon it is given 
•  The reasoner cannot determine something does not hold unless it is 
explicitly stated in the model 
 Open World AssumpJon 
•  Typically we have a paiern of several ExistenJal 
restricJons on a single property with different 
fillers – like primiJve pizzas on hasTopping 

•  ExistenJal restricJons should be paraphrased by 
“amongst other things…” 

•  Must state that a descripJon is complete 
•  We need closure for the given property 
 Closing the Open World 
Closure 
•  This is in the form of a Universal RestricJon 
with a filler that is the Union of the other 
fillers for that 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 
Cardinality Constraints 
InteresJng Pizza