Beruflich Dokumente
Kultur Dokumente
ONTOLOGIES & OWL
Session 1: Primitive Classes in OWL
By Amna Basharat Haider
Adapted by Tutorial by Nick Drummond & Matthew Horridge @ Manchester University
Overview
Pizzas – Card Sorting
Protégé Introduction
Subsumption
Creating a Class Hierarchy
Consistency
y
Disjointness
Relationships & Properties
Restrictions
Polyhierarchies ‐
P l hi hi Issues
I
FAST – NU, Islamabad, Fall 2008
Our Domain
Pizzas have been used in Manchester tutorials
y
for years.
Pizzas were selected as a domain for several
reasons:
à They are fun
Th f
à They are internationally known
à They are highly compositional
à They have a natural limit to their scope
à They are fairly neutral
Although arguments still break out over representation
t oug a gu e ts st b ea out o e ep ese tat o
Even pizzas can do this ‐ its an inevitable part of
knowledge modelling
ARGUING IS NOT BAD!
Most often it is not the domain expert that
formalises their knowledge – because of the
complexity of the modelling it is normally a
specialist “knowledge engineer”
p g g
Hopefully, as tools get easier to use, this will change
Having access to experts is critical for most
domains
Luckily, we are all experts in Pizzas, so we
j
just need some material to verify our
y
knowledge…
FAST – NU, Islamabad, Fall 2008
Reference Materials
Having references to validate decisions, and
act as provenance can be useful for
t b f l f
maintaining an ontology
Mistakes, omissions and intentions can be
more easily traced if a reference can be made
il d if f b d
à When building, we highly recommend documenting your model as you go –
keeping provenance information is a good way of doing this
We have provided you with a pizza menu and
several cards with ingredients on
FAST – NU, Islamabad, Fall 2008
Our Ontology
When building an ontology we need an application in mind –
ontologies should not be built for the sake of it
Keep the application in mind when creating concepts – this should
help you scope the project
The PizzaFinder application has been developed so that you can
plug your ontology in at the end of the day and see it in action
l t l i t th d f th d d it i ti
Let us know your ideas for extending the application
www.co-ode.org/downloads/pizzafinder/
FAST – NU, Islamabad, Fall 2008
EXERCISE 1: CARD SORTING
Card Sorting ‐ Issues
different viewpoints
à Tomato – Vegetable or Fruit?
à culinary vs biological
Ambiguity
à words not concepts
Missing Knowledge
à What is peperonata?
multiple classifications (2+ parents)
lots of missing categories (superclasses?)
competency questions
à What are we likely to want to “ask” our ontology?
Wh lik l “ k” l ?
à bear the application in mind
Person Country
Elvis Belgium
Holger
Paraguay
Kylie
Class (concept)
Latvia
S.Claus China
Hai
Individual (instance)
N‐ary relationships can be modelled with workarounds in OWL, but this
design pattern will not be discussed today
Subsumption hierarchy
Structure as asserted by the ontology engineer
owl:Thing is the root class
FAST – NU, Islamabad, Fall 2008
Subsumption
Superclass/subclass relationship, “isa”
All members of a subclass can be inferred to be members of its
superclasses
owl:Thing: superclass of all OWL Classes
A
• A subsumes B
B • A is a superclass of B
• B is a subclass of A
• All members of B are also
members of A
Properties
“available” to
Class
Disjoints
widget
Conditions Widget
Class‐specific tools (find usage etc)
You will notice that we use naming
conventions for our ontology entities
Typically, we use CamelNotation
Typically we use CamelNotation with a
starting capital for Classes
Use whatever conventions you like
It is helpful to be consistent – especially
when trying to find things in your ontology
3 Select OK
3.
* ie one created on this version of Protégé - the s/w gets updated once every few
days, so don’t count on it unless you’ve created it recently– safest to build from
the .owl file if in doubt
We’ve just created 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 automatically by
software 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
g
using OWL‐DL)
!
! !
Reasoner: A clever (probably magic) black box designed by clever people
Best to let them worry about how they work
FAST – NU, Islamabad, Fall 2008
Reasoners: Inference infer: Conclude
Reasoners are used to infer information that is
not explicitly contained within the ontology
You may also hear them being referred to as
Classifiers
Standard reasoner services are:
à Consistency Checking
à Subsumption Checking (Automatic Subsumption)
b i h ki i b i
à Equivalence Checking
à Instantiation Checking
DangerousAnimal (defined class)
Animal and
hasMouthPart some Teeth Teeth
Fangs
Shark (primitive class)
Animal and
hasMouthPart some Fangs
Shark (p
(primitive class))
Animal and
eats some (Person and Seal)
Inconsistent = cannot contain any individuals
à A well designed ontology can be compiled to check its
e des g ed o to ogy ca be co p ed to c ec ts
meaning is that intended
Publish Time
à Or at publish time – so many inferences are already made
for the user apps
Runtime Reasoning
à Or at runtime in applications as a querying mechanism
(
(esp. useful for smaller ontologies)
f l f ll t l i )
This means that the reasoner you choose is independent
of the application using it,
f h li i i i
à so you can choose the implementation you want depending on
your needs (eg some may be more optimised for speed/memory,
others may have more features)
These reasoners typically set up a service running locally
or on a remote server
Protégé‐OWL, for example can connect to reasoners over
an http:// connection
This means that the reasoner you choose is
independent of the ontology editor, so you can
independent of the ontology editor so you can
choose the implementation you want depending on
your needs (eg some may be more optimised for
speed/memory others may have more features)
speed/memory, others may have more features)
These reasoners typically set up a service running
llocally or on a remote server –
ll Protégé‐OWL can
P é é OWL
only connect to reasoners over an http://
connection
Classify taxonomy
(and check consistency)
Just check consistency
(for efficiency)
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
t d i th di l d i t lt i d
inconsistent classes turn red
moved classes turn blue
OWL assumes that
classes overlap
l l
MeatTopping
pp g VegetableTopping
= individual
i di id l
► 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
If we state that classes are disjoint
MeatTopping
pp g VegetableTopping
= individual
i di id l
► This means an individual cannot be both a MeatTopping and a
VegetableTopping at the same time
► We must do this explicitly in the interface
3 Select
3. S l t OK
Run a reasoner locally on your machine
f
Your reasoner may be found at…
Why is MeatyVegetableTopping Inconsistent?
We have asserted that a MeatyVegetableTopping is a subclass
j
of two classes we have stated are disjoint
The disjoint means nothing can be a MeatTopping and a
VegetableTopping at the same time
This means that MeatyVegetableTopping can never contain
any individuals
The class is therefore inconsistent
h l i h f i i
This is what we expect!
It can be useful to create classes we expect to be inconsistent
to “test” your model – often we refer to these classes as
“probes” – generally it is a good idea to document them as such
to avoid later confusion
This is obviously an awkward thing to manage – we will later show
you how to manage your tangle to simplify these issues
Disjoints are inherited
j down the subsumption hierarchy
p y
eg something that is a TomatoTopping cannot be a Pizza because
its superclass, PizzaTopping, is disjoint from Pizza
You should now be able to select every class and see its
siblings in the disjoints widget (if it has any)
Pizza PizzaTopping
= individual
In OWL‐DL, relationships can only be formed
between Individuals or between an
Individual and a data value.
(In OWL‐Full, Classes can be related, but this cannot be reasoned with)
Relationships are formed along Properties
We can restrict how these Properties are
used:
à Globally – by stating things about the Property
itself
à Or locally – by restricting their use for a given
Class
Object Property – relates Individuals
Datatype Property – relates Individuals to
data (int, string, float etc)
Annotation Property – for attaching
metadata to classes, individuals or
properties
i
Delete Property
New Object Property:
Associates an individual to another individual
not used today:
‐ New Datatype Property (String, int etc)
‐ New Annotation Properties for metadata
‐ New SubProperty – ie create “under” the
current selection
We often create properties using 2 standard naming
patterns:
à has… (eg
h ( hasColour)
h C l )
à is…Of (eg isTeacherOf) or other suffixes (eg …In …To)
This has several advantages:
à It is easier to find properties
à It is easier for tools to generate a more readable form
(see tooltips on the classes in the hierarchy later)
à Inverses properties typically follow this pattern
eg hasPart, isPartOf
Our example hasBase fits into this
(we will not create the inverse in this tutorial)
à Functional – if property p relates A‐B then all relations along p relate A‐
B (m..1 relation)
(B could also be a datatype value)
à I
Inverse Functional
F ti l – the inverse of the property is functional
th i f th t i f ti l
à Symmetric – if a property relates A‐B then it also relates B‐A
à AntiSymmetric
à Transitive – if a property relates A‐B and B‐C then it relates A‐C
à Reflexive
à Irreflexive
Jean
hasChild
Jean Mathew
hasParent
Jean
Implies the
same
Individual
Margaret
Peggy
Jean
Margaret
hasSibling
Jean Mathew
hasSibling
isChildOf
isChildOf
Jean Mathew
David
isChildOf
X
knows
Jean Micheal
knows
isMotherOf
Alice Bob
X
isMotherOf
The reasoner finds this inconsistent
It looks like the interface is warning us that we can’t use the
g
property more than once, but actually…
We now have a property we want to use to describe Pizza
individuals
To do this, we must go back to the Pizza class and add some
further information
This comes in the form of Restrictions
We create Restrictions using the Conditions widget
Conditions can be any kind of Class – you have already added Named
superclasses in the Conditions Widget. Restrictions are a type of
Anonymous Class
Conditions asserted by the ontology engineer
Add different types of condition
Definition
of the class
(
(later)
)
Description
of the class
Conditions inherited from superclasses
Create Restriction (next)
Create Class Expression Add Named Superclass
Restriction
Type
Filler
Expression
Expression
Syntax
Construct
check
Palette
We have created a restriction: ∃ hasBase PizzaBase
on Class Pizza as a necessary condition
Pizza PizzaBase
► “If an individual is a member of this class, it is necessary that it has
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
Every individual of the Pizza class must have at least one base
from the class PizzaBase”
We have created a restriction: ∃ hasBase PizzaBase
on Class Pizza as a necessary condition
Pizza PizzaBase
► “There can be no individual, that is a member of this class, that
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”
PizzaBase
∃ hasBase
PizzaBase
We have created a restriction: ∃ hasBase PizzaBase
on Class Pizza as a necessary condition
Pizza PizzaBase
∃ hasBase
PizzaBase