1. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester A Practical Introduction to Ontologies & OWL Session 1: Primitive Classes in OWL Michael Lutz based on Slides from the Co-ode OWL Tutorial available from http://www.co-ode.org/resources/tutorials/intro/

2. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Overview ►Pizzas – Card Sorting ►Protégé Introduction ►Subsumption ►Creating a Class Hierarchy ►Consistency ►Disjointness ►Relationships & Properties ►Restrictions ►Polyhierarchies - Issues

3. based on “A Practical Introduction to Ontologies & OWL” © 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!

4. based on “A Practical Introduction to Ontologies & OWL” © 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…

5. based on “A Practical Introduction to Ontologies & OWL” © 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

6. based on “A Practical Introduction to Ontologies & OWL” © 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

7. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Our Application www.co-ode.org/downloads/pizzafinder/

8. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Exercise 1: Card Sorting

9. based on “A Practical Introduction to Ontologies & OWL” © 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

10. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester OWL Constructs PersonCountry Class (concept) Animal Individual (instance) Belgium Paraguay China Latvia Elvis Hai Holger Kylie S.Claus Rudolph Flipper arrow = relationship label = Property lives_in has_pet

11. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester OWL Constructs: Classes E.g. 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 – e.g. 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. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester OWL Constructs: Properties E.g. 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 michael_lutz  givesTutorial  SOGIS_Vienna_April_2006 ►N-ary relationships can be modelled with workarounds in OWL, but this design pattern will not be discussed today

13. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester OWL Constructs: Individuals E.g. 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. based on “A Practical Introduction to Ontologies & OWL” © 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) ►core is based on Frames (object oriented) modelling ►now supports OWL through the Protégé-OWL plugin So let’s have a look…

15. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Protégé-OWL

16. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Class Hierarchy Subsumption hierarchy Structure as asserted by the ontology engineer owl:Thing is the root class

17. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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 B 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

18. based on “A Practical Introduction to Ontologies & OWL” © 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)

19. based on “A Practical Introduction to Ontologies & OWL” © 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

20. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Saving OWL Files 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 OWL = easy to make mistakes = save regularly

21. based on “A Practical Introduction to Ontologies & OWL” © 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 you’ve got a valid project file*: - File  Open Project - select the.pprj file * ieone 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

22. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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)

23. based on “A Practical Introduction to Ontologies & OWL” © 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)

24. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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 http:// connection

25. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Accessing the Reasoner Classify taxonomy (and check consistency) Just check consistency (for efficiency) Compute inferred types (for individuals)

26. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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

27. based on “A Practical Introduction to Ontologies & OWL” © 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

28. based on “A Practical Introduction to Ontologies & OWL” © 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

29. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester ClassesTab: Disjoints Widget Add siblings as disjoint Add new disjoint Remove disjoint siblings List of disjoint classes

30. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Exercise 3: Add Disjoints ►Run a reasoner locally on your machine ►Your reasoner may be found at…

31. based on “A Practical Introduction to Ontologies & OWL” © 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

32. based on “A Practical Introduction to Ontologies & OWL” © 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

33. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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 e.g. 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)

34. based on “A Practical Introduction to Ontologies & OWL” © 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 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

35. based on “A Practical Introduction to Ontologies & OWL” © 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

36. based on “A Practical Introduction to Ontologies & OWL” © 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

37. based on “A Practical Introduction to Ontologies & OWL” © 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

38. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Creating Properties not used today: - New Datatype Property (String, int etc) New Object Property: Associates an individual to another individual Delete Property - New Annotation Properties for metadata - New SubProperty – ie create “under” the current selection

39. based on “A Practical Introduction to Ontologies & OWL” © 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… (e.g. hasColour) ►is…Of (e.g. isTeacherOf) or other suffixes (e.g. …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 e.g. hasPart, isPartOf ►Our example hasBase fits into this (we will not create the inverse in this tutorial)

40. based on “A Practical Introduction to Ontologies & OWL” © 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

41. based on “A Practical Introduction to Ontologies & OWL” © 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

42. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Conditions Types Logical (Anonymous) Classes Add Named Superclass Create Restriction (next) Create Class Expression

43. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Creating Restrictions Restriction Type Restricted Property Filler Expression Syntax check Expression Construct Palette

44. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester What does this mean? ►We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition ►“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” Pizza PizzaBase hasBase

45. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester What does this mean? ►We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition ►“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” Pizza PizzaBase hasBase

46. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester  hasBase PizzaBase Why? ►We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition PizzaBase hasBase ►Each Restriction or Class Expression describes the set of all individuals that satisfy the condition

47. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Pizza Why? N ecessary conditions ►We have created a restriction:  hasBase PizzaBase on Class Pizza as a necessary condition ►Each necessary condition on a class is a superclass of that class PizzaBase hasBase  hasBase PizzaBase ►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

48. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester Exercise 4: Properties & Restrictions

49. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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”

50. based on “A Practical Introduction to Ontologies & OWL” © 2005, The University of Manchester 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