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
