1. A Practical Introduction to Ontologies & OWL
Session 1: Primitive Classes in OWL
Nick Drummond & Matthew Horridge

2. Overview Pizzas – Card Sorting Protégé Introduction Subsumption
Creating a Class Hierarchy
Consistency
Disjointness
Relationships & Properties
Restrictions
Polyhierarchies - Issues

3. Our Domain Pizzas have been used in Manchester tutorials for years.
Pizzas were selected as a domain for several reasons:
They are fun
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
Even pizzas can do this - its an inevitable part of knowledge modelling
ARGUING IS NOT BAD!

4. 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” 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 just need some material to verify our knowledge…

5. Reference Materials
Having references to validate decisions, and act as provenance can be useful for maintaining an ontology
Mistakes, omissions and intentions can be more easily traced if a reference can be made
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

6. 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 Let us know your ideas for extending the application

7. Our Application

8. Exercise 1: Card Sorting

9. Card Sorting - Issues different viewpoints Ambiguity Missing Knowledge
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?
bear the application in mind

10. OWL Constructs Person Country Class (concept) Individual (instance)
lives_in
Person
Country
Elvis
Hai
Holger
Kylie
S.Claus
Belgium
Paraguay
China
Latvia
lives_in
Class (concept)
lives_in
Individual (instance)
has_pet
has_pet
arrow = relationship
label = Property
Rudolph
Flipper
has_pet
Animal

11. 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 – 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

12. OWL Constructs: Properties
Eg hasPart, isInhabitedBy, isNextTo, occursBefore
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

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

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

15. … core is based on Frames (object oriented) modelling
has an open architecture that allows other modelling languages to be built on top
supports development of plugins to allow backend / interface extensions
now supports OWL through the Protégé-OWL plugin
So let’s have a look…

16. Protégé-OWL

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

18. 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
A is a superclass of B
B is a subclass of A
All members of B are also members of A B

19. 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)

20. Exercise 2: Create Class Hierarchy
Before you start:
If you are borrowing a laptop, please take a note of the number on the top cover
Please save all files to: My Documents\ontologies
Because you will be needing your work again tomorrow

21. Exercise 2: Create Class Hierarchy
You will notice that we use naming conventions for our ontology entities
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

22. Saving OWL Files OWL = easy to make mistakes = save regularly
Select File  Save Project As A dialog (as shown) will pop up
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 your ontology is stored in RDF/OWL format
Select OK

23. Loading OWL files
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
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

24. 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 using OWL-DL)

25. Reasoners
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
Equivalence Checking
Instantiation Checking
Reasoners can be used at runtime in applications as a querying mechanism (esp useful for smaller ontologies)
We will use one during development as an ontology “compiler”. A well designed ontology can be compiled to check its meaning is that intended

26. Reasoners and Protégé
Protégé-OWL supports the use of reasoners implementing the DIG interface
This means that the reasoner you choose is 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)
These reasoners typically set up a service running locally or on a remote server – Protégé-OWL can only connect to reasoners over an connection

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

28. 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
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

29. 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

30. 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

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

32. Exercise 3: Add Disjoints
Run a reasoner locally on your machine
Your reasoner may be found at…

33. Why is MeatyVegetableTopping Inconsistent?
We have asserted that a MeatyVegetableTopping is a subclass 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
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

34. Other Inconsistencies?
Your ontology is likely to have several classes with multiple parents
We call this a tangle
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 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

35. What have we got?
We’ve created a tangled graph (not a tree – multiple parents) of mostly disjoint classes
Disjoints are inherited down the subsumption hierarchy 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)

36. What are we missing? This is not a semantically rich model
Apart from “is kind of” (subsumption) 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

37. 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

38. 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

39. Properties Tab: Property Browser
Note that Properties can be in a hierarchy, although we are not going to be using this feature today

40. 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

41. 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 hasColour)
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)

42. 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

43. Conditions Widget Conditions asserted by the ontology engineer
Add different types of condition
Definition
of the class
(later)
Description
Conditions inherited from superclasses

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

45. Creating Restrictions
Type
Restricted Property
Filler
Expression
Syntax
check
Expression
Construct
Palette

46. What does this mean?
We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition
hasBase
Pizza
PizzaBase
hasBase
hasBase
hasBase
“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”

47. What does this mean?
We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition
hasBase
Pizza
PizzaBase
hasBase
“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
hasBase

48. Why?
We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition
hasBase
 hasBase PizzaBase
hasBase
hasBase
PizzaBase
hasBase
hasBase
hasBase
Each Restriction or Class Expression describes the set of all individuals that satisfy the condition

49. Why? Necessary conditions
We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition
hasBase
hasBase
Pizza
hasBase
PizzaBase
 hasBase PizzaBase
hasBase
hasBase
hasBase
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

50. Exercise 4: Properties & Restrictions

51. Restriction Types       Existential, someValuesFrom
“Some”, “At least one” 
Universal, allValuesFrom
“Only” 
hasValue
“equals x” 
Cardinality
“Exactly n” 
Max Cardinality
“At most n” 
Min Cardinality
“At least n”

52. Primitive Classes
All classes in our ontology so far are Primitive
We describe primitive pizzas
Primitive Class = only Necessary Conditions
They are marked as plain orange circles in the class hierarchy
We condone building a disjoint tree of primitive classes

53. Polyhierarchies
By the end of this tutorial we intent to create a VegetarianPizza
Some of our existing Pizzas should be types of VegetarianPizza
However, they could also be types of SpicyPizza or CheeseyPizza
We need to be able to give them multiple parents in a principled way
We could just assert multiple parents like we did with MeatyVegetableTopping (without disjoints)
BUT…

54. Asserted Polyhierarchies
We believe asserting 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!

55. Summary You should now be able to:
extract Knowledge (and act as an expert)
identify components of the Protégé-OWL Interface
create Primitive Classes
create Properties
create some basic Restrictions on a Class using Existential qualifiers