A Practical Introduction to Ontologies & OWL

Session 1: Primitive Classes in OWL

Nick Drummond & Matthew Horridge

O p e n G A LE N

BioHealth Informatics Group

Overview
Pizzas Card Sorting

Protg Introduction
Subsumption Creating a Class Hierarchy

Consistency
Disjointness Relationships & Properties Restrictions Polyhierarchies - Issues

Copyright 2005, The University of Manchester

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!

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

Our Application

www.co-ode.org/downloads/pizzafinder/
Copyright 2005, The University of Manchester

Exercise 1: Card Sorting

Copyright 2005, The University of Manchester

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? bear the application in mind

Copyright 2005, The University of Manchester

OWL Constructs

Person
Elvis Holger Paraguay Kylie S.Claus Latvia

Country
Belgium

Class (concept)
China

Hai

Individual (instance) arrow = relationship label = Property

Flipper

Animal
Rudolph

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester


Is a knowledge modelling environment

Is free, open source software

Is developed by Stanford Medical Informatics Has a large user community (approx 30k)

Copyright 2005, The University of Manchester


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 Protg-OWL plugin

So lets have a look

Copyright 2005, The University of Manchester

Protg-OWL

Copyright 2005, The University of Manchester

Class Hierarchy
Subsumption hierarchy Structure as asserted by the ontology engineer

owl:Thing is the root class

Copyright 2005, The University of Manchester

Subsumption
Superclass/subclass relationship, isa All members of a subclass can be inferred to be members of its superclasses
A B A subsumes B A is a superclass of B B is a subclass of A All members of B are also members of A

owl:Thing: superclass of all OWL Classes

Copyright 2005, The University of Manchester

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)

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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 your ontology is stored in RDF/OWL format

3. Select OK

Copyright 2005, The University of Manchester

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 youve got a valid project file*:

- File Open Project - select the .pprj file
* ie one created on this version of Protg - the s/w gets updated once every few days, so dont count on it unless youve created it recently safest to build from the .owl file if in doubt

Copyright 2005, The University of Manchester

Consistency Checking
Weve just created a class that doesnt really make sense
What is a MeatyVegetableTopping?

Wed 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)
Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

Reasoners and Protg

Protg-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 Protg-OWL can only connect to reasoners over an http:// connection

Copyright 2005, The University of Manchester

Accessing the Reasoner

Classify taxonomy (and check consistency) Compute inferred types (for individuals)

Just check consistency (for efficiency)

Copyright 2005, The University of Manchester

Reasoning about our Pizzas

When we classify an ontology we could just use the Check Consistency button but well get into the habit of doing a full classification as well 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
Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

ClassesTab: Disjoints Widget

Add siblings as disjoint Add new disjoint Remove disjoint siblings

List of disjoint classes

Copyright 2005, The University of Manchester

Exercise 3: Add Disjoints

Run a reasoner locally on your machine

Your reasoner may be found at

Copyright 2005, The University of Manchester

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
Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

What have we got?

Weve 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)

Copyright 2005, The University of Manchester

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 dont have any other information of interest We want to say more about Pizza Individuals, such as their relationship with other Individuals

Pizza

PizzaTopping

= individual

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

Properties Tab: Property Browser

Note that Properties can be in a hierarchy, although we are not going to be using this feature today

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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) isOf (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)

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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
Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

Creating Restrictions
Restricted Property

Restriction Type
Filler Expression

Expression Construct Palette

Syntax check

Copyright 2005, The University of Manchester

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 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
Copyright 2005, The University of Manchester

What does this mean?

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 does not have at least one hasBase relationship with an individual from the class PizzaBase

Copyright 2005, The University of Manchester

Why?
We have created a restriction: hasBase PizzaBase on Class Pizza as a necessary condition

PizzaBase hasBase PizzaBase

Each Restriction or Class Expression describes the set of all individuals that satisfy the condition

Copyright 2005, The University of Manchester

Why? Necessary conditions

We have created a restriction: hasBase PizzaBase on Class Pizza as a necessary condition

Pizza hasBase PizzaBase

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
Copyright 2005, The University of Manchester

Exercise 4: Properties & Restrictions

Copyright 2005, The University of Manchester

Restriction Types

Existential, someValuesFrom Universal, allValuesFrom hasValue Cardinality Max Cardinality Min Cardinality Some, At least one Only equals x Exactly n At most n At least n

Copyright 2005, The University of Manchester

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

Copyright 2005, The University of Manchester

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
Copyright 2005, The University of Manchester

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!

Copyright 2005, The University of Manchester

Summary
You should now be able to: extract Knowledge (and act as an expert) identify components of the Protg-OWL Interface

create Primitive Classes

create Properties create some basic Restrictions on a Class using Existential qualifiers

Copyright 2005, The University of Manchester