ProtegeOWLTutorial (Compatibility Mode)

A PRACTICAL INTRODUCTION TO
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!

You are the Expert
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…
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
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

Our Application
www.co-ode.org/downloads/pizzafinder/
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

OWL Constructs
Person Country
Elvis Belgium
Holger
Paraguay
Kylie
Class (concept)
Latvia
S.Claus China
Hai
Individual (instance)
Flipper arrow = relationship

label = Property
Animal
Rudolph

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 description, not its name
Classes do not have to be named – they can be logical expressions –
Classes do not have to be named they can be logical expressions eg
things that have colour Blue
A Class should be described such that it is possible for it to contain
Individuals (unless the intention is to represent the empty class)
Classes that cannot possibly contain any Individuals are said to be
inconsistent

OWL Constructs: Properties
Eg hasPart, isInhabitedBy, isNextTo, occursBefore
p
Properties are used to relate Individuals
We often say that Individuals are related along a given property
Relationships in OWL are binary:
Subject Æ predicate Æ Object
Individual a Æ hasProperty Æ Individual b
nick_drummond Æ givesTutorial Æ Manchester_ProtegeOWL_tutorial_29_June_2005
N‐ary relationships can be modelled with workarounds in OWL, but this
design pattern will not be discussed today

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

…
Is a knowledge modelling environment
Is free, open source software
Is developed by Stanford Medical
Informatics
Has a large user community (approx 30k)

…
core is based on Frames (object oriented)
modelling
d lli
has an open architecture that allows other
modelling languages to be built on top
d lli l t b b ilt t
supports development of plugins to allow
b k d / i
backend / interface extensions
f i
now supports OWL through the Protégé‐
OWL plugin
So let’s
let s have a look
look…

Protégé‐OWL

Class Hierarchy
Subsumption hierarchy
Structure as asserted by the ontology engineer
owl:Thing is the root class
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

Class Editor
Class annotations (for class metadata)
Class name and documentation
Properties
“available” to
Class
Disjoints
widget
Conditions Widget
Class‐specific tools (find usage etc)

EXERCISE 2: CREATE CLASS HIERARCHY
Exercise 2: Create Class Hierarchy
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

Saving OWL Files
OWL = easy to make mistakes = save regularly

1. Select File Æ Save Project As
A dialog (as shown) will pop up
2. Select a file directly by clicking the button on the top right

You will notice that 2 files are created
.pprj – the project file
this just stores information about the GUI
and the workspace
.owl – the OWL file
this is where
here your
o r ontolog
ontology is stored in
RDF/OWL format
3 Select OK
3.

Loading OWL files
1. If you only have an OWL

file:
- FileÆ New Project
- Select OWL Files as the type
- Tick Create from existing sources
- Next to select the .owl file
2. If you’ve got a valid project file*:

- File Æ Open Project
- select the .pprj file
* 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

Consistency Checking
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)

REASONERS AND INFERENCE
Reasoners & Inference
?
? ?
!
! !
Reasoner: A clever (probably magic) black box designed by clever people
Best to let them worry about how they work
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

Automatic Classification
Trivial example
DangerousAnimal (defined class)
Animal and
hasMouthPart some Teeth Teeth
Fangs
Shark (primitive class)
Animal and
hasMouthPart some Fangs

Consistency Checking
Shark (p
(primitive class))
Animal and
eats some (Person and Seal)
Inconsistent = cannot contain any individuals
Person Seal Disjoint (Person, Seal)

Person and Seal = empty
Cannot have some empty

When to use a Reasoner
Modelling /Compile Time Reasoning
à We often use one during development as an ontology
g p gy
compiler.
à 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 )

Reasoners and the tools
Many of the editing tools and APIs support the use of
reasoners implementing the DIG (Description Logics
Implementation Group) interface
I l t ti G ) i t f
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

Reasoners and Protégé
Protégé‐OWL supports the use of reasoners
p g
implementing the DIG interface
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

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” button but we’ll get into the habit of doing a full
classification as we ll be doing this later
classification 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
t d i th di l d i t lt i d
inconsistent classes turn red
moved classes turn blue

Disjointness
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

Disjointness
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
► 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

Save Your Work
OWL = easy to make mistakes – save regularly

1. Select File Æ Save
A dialog (as shown) will pop up
2. Select a file using a file selector by clicking the button on the top right
You will notice that there are 2 files created

.pprj
pp j – the p
project
j file
this just stores information about the GUI
and the workspace
.owl – the OWL file
this iis where
thi h your ontology
t l iis stored
t d iin
RDF/OWL format
3 Select
3. S l t OK
38 CS646: N. Drummond, M. Horridge 29/11/2004

EXERCISE 3: ADD DISJOINTS
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
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

Other Inconsistencies?
Your ontology is likely to have several classes with multiple parents
We call this a tangle
g
As we have seen, a class cannot have 2 disjoint parents – it will be
inconsistent
To remove other inconsistencies you will have to be careful about
y
where your disjoints are – remove disjoints between multiple
parents by hand
This is obviously an awkward thing to manage – we will later show
you how to manage your tangle to simplify these issues

What have we got?
We’ve created a tangled graph (not a tree – multiple

parents) of mostly disjoint classes
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)

What are we missing?
This is not a semantically rich model
Apart from is kind of (subsumption) and
Apart from “is kind of” (subsumption) is not kind of
and “is not kind of”
(disjoint), we currently don’t have any other information of interest
We want to say more about Pizza Individuals, such as their
relationship with other Individuals
Pizza PizzaTopping
= individual

RELATIONSHIPS IN OWL
Relationships in OWL
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

OWL Properties
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

Properties Tab: Property Browser
Note that Properties can be in a
hierarchy, although we are not going to
be using this feature today
b i hi f d

Creating Properties
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

Creating Properties
We tend to name properties using camelNotation with a
lowercase letter to begin
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)

Property Characteristics
à Inverses – if property p has inverse property q, and p relates A‐B, then
it can be inferred q relates B‐A
à 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

Functional Property
If Peggy and Margaret are not stated Different
à Inferred same ggy
Peggy
Else
à Inconsistency
Implies the same

Individual
Jean
FAST – NU, Islamabad, Fall 2008 Margaret

Inverse Property
hasChild
Jean Mathew
hasParent

Inverse Functional Property
Peggy If Peggy and Margaret are not stated Different
à Inferred same
Else
à Inconsistency
Jean
Implies the
same
Individual
Margaret

Transitive Property
Peggy
Jean
Margaret

Symmetric Properties
hasSibling
Jean Mathew
hasSibling

AntiSymmetric Properties
isChildOf
isChildOf
Jean Mathew
David
isChildOf
X

Reflexive Property
knows
Jean Micheal
knows

IrReflexive Property
isMotherOf
Alice Bob
X
isMotherOf

Functional Properties
An individual can only have relationships with at most one other
individual along a functional property
eg Setting hasBase to Functional means:
“Every Pizza can have at most one PizzaBase”
D
Description of DoubleBasePizza:
i ti f D bl B Pi
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…

PROPERTIES AND RESTRICTIONS
Associating Properties with Classes
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 Widget
Conditions asserted by the ontology engineer
Add different types of condition
Definition
of the class
(
(later)
)
Description
of the class
Conditions inherited from superclasses

Conditions Types
Logical (Anonymous) Classes
Create Restriction (next)
Create Class Expression Add Named Superclass

Creating Restrictions
Restricted Property
Restriction
Type
Filler
Expression
Expression
Syntax
Construct
check
Palette

What does this mean?
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”

What does this mean?
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”

Why?

PizzaBase
∃ hasBase
PizzaBase
► Each Restriction or Class Expression describes the set of all

individuals that satisfy the condition

Why? Necessary conditions
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,
restriction all Pizzas must satisfy
the restriction that they have at least one base from PizzaBase

EXERCISE 4: PROPERTIES &
RESTRICTIONS

ProtegeOWLTutorial (Compatibility Mode)

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ProtegeOWLTutorial (Compatibility Mode)

Hochgeladen von

Copyright:

Verfügbare Formate

A PRACTICAL INTRODUCTION TO

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

Flipper arrow = relationship

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

OWL = easy to make mistakes = save regularly

2. Select a file directly by clicking the button on the top right

FAST – NU, Islamabad, Fall 2008

1. If you only have an OWL

2. If you’ve got a valid project file*:

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

Person Seal Disjoint (Person, Seal)

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

Compute inferred types

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

Add siblings as disjoint

List of disjoint classes

FAST – NU, Islamabad, Fall 2008

OWL = easy to make mistakes – save regularly

You will notice that there are 2 files created

38 CS646: N. Drummond, M. Horridge 29/11/2004

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

 We’ve created a tangled graph (not a tree – multiple

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

Implies the same

FAST – NU, Islamabad, Fall 2008 Margaret

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

We’ve created a tangled graph (not a tree – multiple

We have created a restriction: ∃ hasBase PizzaBase