Introduction to Ontologies with Protege

Outline

Tutorial Set up

Download and Install Protege

All of the tutorials are designed to be used with Protege 4.0. Download it at  http://protege.stanford.edu/. The current version is Protege 4.1. Install it onto your machine.

Download the Family Ontology

Download the Family Ontology Download (click this link then scroll down to the bottom of the page and click "Original Format") and save it to your local machine. Note: The way this TRAC Wiki deals with attachments can cause problems. If you're having problems downloading the attachment (you may get a .html file when you try to download it), you can also find the ontology at  http://users.csc.calpoly.edu/~fkurfess/Courses/481/W11/Material/Ontologies/family_example.owl. This link should also work if you download the ontology directly into Protege via the Open from URL option.

Start Protege

When you open Protege you should see a welcome screen. Select "Open OWL Ontology" and browse to the location where you saved the Family Ontology.

Introducing the Family Ontology

We will be using a family ontology to show examples of how to use protege to edit/create ontologies. The individuals in this ontology correspond to this family tree:

Exploring Protege

Once you've opened the Family Ontology you will be in the Active Ontology tab. The tabs give you different views into the ontology. Above the tabs is the URI of the ontology you have open. The URI is important because it gets appended to the front of every entity in the ontology. So when I talk about class Person, I'm really talking about https://wiki.csc.calpoly.edu/OntologyTutorial/family_example.owl#Person. This is how ontologies manage namespaces and avoid naming conflicts.

What is an Ontology? An ontology is a description of a domain. Ontologies can be written in various formats and can be used by computers to reason about the domain they describe. They are also useful as a common format that allows for exchange of knowledge across applications/ platforms. The ontologies we will be working with are written in OWL 2. OWL 2 is an ontology language that defines the concepts you can use to write an ontology. If you're not familiar with ontologies, take a few minutes and explore the following links to give yourself some context before moving on:
 http://en.wikipedia.org/wiki/Ontology_%28information_science%29
 http://www-ksl.stanford.edu/kst/what-is-an-ontology.html
 http://www.w3.org/TR/owl-features/
 http://en.wikipedia.org/wiki/Web_Ontology_Language

Tab Overview

Active Ontology Tab. This tab describes information about the ontology itself such as version information and information about the ontology contents. This information is known as meta-information.

Entities. This tab has the functionality of the next four tabs combined (Classes, Object Properties, Data Properties, and Individuals). To keep things simple in this tutorial we will not be using this tab.

Classes. This is where you can edit the classes in the ontology. We will be covering this tab in detail.

Object Properties. This tab allows you to edit possible relationships between two objects. We will be covering this tab in detail.

Data Properties. This tab allows you to edit what data (strings, ints, datetime, etc) can to added to classes. We will be covering this tab in detail.

Individuals. This is where you can edit instances of classes, called Individuals. We will be covering this tab in detail.

OWL Viz. This tab has tools that allow you to visualize parts of the ontology.

DL Query. This tab has tools for querying information in the ontology.

Classes

Go ahead and switch to the Classes tab. This tab shows the ontology classes that have been defined. Ontology classes are very similar to classes in an object oriented program. Just like in object oriented programming classes in ontologies form a hierarchy. You can view this hierarchy on the right hand panel labeled Asserted class hierarchy. The root class which is at the top of the inheritance hierarchy is Thing (this is true of all OWL ontologies). If you click the triangle next to Thing you will see the classes that are descended from Thing. Click the triangle next to Person to see the classes descended from Person.

How are Ontology Classes different from Object-oriented Classes? While they are similar in most ways one important difference to remember is that a individual in an ontology can belong to 0 or more classes in addition to any inherited classes. In our family example this means that the same individual could be a Daughter and a Mother in addition to being a Person and Thing. There are ways to limit which other classes an individual of one class can belong to, but absent such explicit information individuals can be members of as few or as many classes as the ontology creator wants them to be.

Clink on class Parent on the left panel. To the bottom right is a panel labeled Description: Parent. This is where the information about the class you currently viewing is displayed. This section is broken down into five categories, four of which can be edited directly:

Equivalent classes This section describes other classes or groups that are equivalent to the selected class. In the case of Parent it is any Person who has a child.

Superclasses Are the parent class(es) of the selected class (remember- since you can have multiple classes you can also have multiple superclasses). Right now there is no superclass for Parent, even though the Asserted class hierarchy has it under Person. When we initiate reasoning later on the Person superclass will show up there.

Members This shows those individuals which are members of this class. They can be added explicitly here, or inferred later though reasoning.

Disjoint classes This allows you to explicitly select the classes that members of the selected class cannot also belong to. Because of the way Mother and Father are defined it would be redundant to mark them disjoint. Most of the time you do not need to explicitly mark classes as disjoint but it can be helpful if you are using some external reasoning or application to make the class definitions as explicit and exact as possible.

Browse through the classes provided and try to get a feel for the concepts they are trying to describe. After you are done looking at the classes go to the top menu and select Reasoner -> Fact++. This will turn on the reasoner to infer additional facts about the classes. The left panel switches to Inferred class hierarchy from Asserted class hierarchy automatically but you can click either tab switch back and forth between the views. Click on the class Daughter, you'll notice that OffSpring? has been added as a superclass. If you think about the definition of OffSpring? and the definition of Daughter, this inference should make sense. You should also notice that some individuals became members of certain classes (we'll see why why when we edit individuals later).

Now we will create a new class called Sibling. Select Person and then click the Add subclass icon. A dialog will pop up, enter Sibling into the text box.

Common Usage It is custom to create classes with nouns as their names, since this is what they represent. It is also custom to make capitalize class names- if they are multiple words capitalize each one.

Now click the + sign next to Equivalent classes. In the Class expression editor pop up enter

Person and hasSibling some Person

What this means is that you are a member of the Sibling class if you are a Person and you have a sibling that is a Person. The syntax used here is the Manchester OWL syntax and is explained in this webpage  http://www.co-ode.org/resources/reference/manchester_syntax/.

You'll notice that Sibling has no members. Select Reasoner -> Fact++ again and you'll notice Mary and Sue (and others) appear as Siblings. When you make changes to your ontology you need to run the reasoner again to make to inferences based on your changes.

Before proceeding select Reasoner -> None from the top menu. This will turn off the reasoning and hide all the inferred associations.

Object Properties

Select the Object Properties tab.

All the tabs in Protege are essentially similar. On the left is the list of Object Properties. If you click on one of the properties information about them will appear in panels to the right. Object properties are ways to relate two Objects. They are also called predicates. If you are talking about object properties you generally use the syntax object1 objectProperty object2 for example "Sam hasParent Steve."

Difference between Classes and Object Properties. In the last tab we had a class Parent. Here we have an object property hasParent. Does asserting "Sam hasParent Steve" automatically make Steve a member of class parent? Only if the class Parent is set up with the correct restrictions to make that true. The logic is all within the Parent class. To give another example, say we created an object property hasUncle, then asserted that "Sam hasUncle Cliff". Would a class Uncle magically appear? No. In order to make a class Uncle we would have to do the same thing we did this the Sibling class - create it and then add a meaningful restriction. Object properties and classes are separate concepts and we use restrictions to connect them together. We have to write those restrictions manually. So why use both? Some ontologies have lots of classes and few object properties, others are the opposite. Some use a combination. Making Mother a class makes it easy to search for all the Mothers. But its a bit more difficult to automatically search for all the Children with their respective Mothers if you don't have the hasMother relation. Likewise if you have the hasMother relation its easy to get all the x hasMother y pairs of x and y but no built in logic saying that all those y's form a special class that could have properties of its own (favoriteMothersDayGift?). Having both a Mother class and a hasMother property makes the model more complete but you could even up with a very complicated model if you tried to do this with every concept in your domain.

Clink on hasGender. You'll notice that it has a Domain and Range, just like a function. This means that "hasGender" relates People to Genders. For example "John hasGender Male" would be valid but "Male hasGender John" would not be. Domain and Range restrictions are optional, in small ontologies like this they not be needed, since its relatively easy for a human user to know what should an shouldn't be related. However, they can be very powerful in large ontologies and for use in reasoning.

Click on hasChild. It has the Inverse property hasParent. What this means is that that every time "x hasChild y" that is can be inferred "y hasParent x". You'll notice hasParent has hasChild as its inverse too.

None of our classes have Disjoint properties but this is also a useful concept. It says that two individuals cannot be connected by both properties. Imagine we add a Object property "hasSpouse". We could mark hasSpouse disjoint with hasChild so that if x hasChild y then x hasSpouse y would be invalid. This would make it impossible to mark someone as being married to their child.

Click on the hasSibling property. Some of the check boxes under characteristics are checked. Lets go over what they all mean:

Functional and Inverse functional A functional property can have only one member in the range for any member of the domain. For example hasGender is marked as functional so that each person can have only one gender. Inverse functional is the opposite- each member of the domain can correspond only one member of the range. Imagine that you would like to interface your ontology with a database of people. You might want to create a hasID property. That property could be marked as Inverse functional, since you want each ID to correspond to only one Person.

Transitive This means that "x aProperty y" and "y aProperty z" implies "x aProperty z". An easy example would be the hasSibling property. If Mary is the sibling of Jane who is the sibling of Sue then Mary should also be the sibling of Sue. However, you'll note that the hasSibling property doesn't have Transitive checked. This is because the Transitive property has a requirement that it cannot be used if there are certain other restrictions on the property (in this case its the irreflexive thats conflicting). Try checking Transitive and running the reasoner - you should get an error. Uncheck it so that you can run the reasoner later. Sometimes you'll run into examples where you are trying to express something and you get vague reasoner errors. This usually means that either you did something wrong or that what you are trying to express can't be expressed. Try to run the reasoner often when you are building your own ontologies- else you might not be able to track down where the error occurred!

Symmetric This means that "x aProperty y" implies "y aProperty x".

Asymmetric This means that if "x aProperty y" then "y aProperty x" cannot be true as well.

Reflexive This means that "x aProperty x" is always true. For example if you were modeling networks of friends you might want a property isKnownBy. This property could be reflexive, since everyone know themselves.

Irreflexive This means that "x aProperty x" is never true. In our examples it means that a person cannot be their own sibling.

Property chains are a new feature to OWL 2. They are used to assert a single property based on the existence of several properties. Lets create a new property hasGrandparent. First click the add Property button and enter "hasGrandparent" then under Description press the plus sign next to Property chains. In the text box enter:

hasParent o hasParent

Click ok and then save the model. The syntax for property chains is pretty simple. This one states that if x hasParent y and y hasParent z then x hasGrandparent z. Since this format of going from the property of one object to the property of the next object doesn't require you to use variables you use the o symbol to connect the properties in the chain. Property chains can connect more than two properties.

Data Properties

Click on the data properties tab. Data properties are just like object properties except their domains are typed literals. Click on the fullName property. This property relates Persons to strings, the string being that Person's full name. This is how you can give individuals data like dateOfBirth. The things you can do with data properties are a subset of the things you can do with object properties.

Lets add dateOfBirth to our ontology. Click the add new data property button and name the property "dateOfBirth". Make its Domain Person and its range date.

Individuals

Click on the Individuals tab. Here you can view all the instances within your ontology. The layout is similar to the other tabs.

Click on some of the individuals. You'll see that they have relatively few object property assertions. Click on Mary. She only has four object property assertions and two types. Now run the reasoner. Now Mary has 3 more inferred types and 5 more object property assertions.

Lets track where each of these came from.

Daughter If you go back to the classes page and look at the class Daughter you'll see its definition is "Person and hasParent some Person and hasGender value FemaleGender." This means that to be classified as a Daughter an individual must 1) be a Person 2) have a parent 3) be female. We can see that Mary meets these restrictions and is therefore classified as a Daughter. Mother and Sibling follow the same logic with slightly different object properties.

hasChild Tom How does the ontology know that Tom is Mary's child? If you go to the definition of hasChild you'll see that its has an inverse property hasParent. Thus if Tom hasParent Mary, Mary hasChild Tom. Going back to Individuals and clicking on Tom will confirm that he indeed has this object property. Likewise for Jim.

hasSibling Scott Both Scott and Anne are marked as "hasSibling Mary" and since hasSibling is symmetric Mary gets this property with them.

hasGrandparent Dave The property chain for hasGrandparent is "hasParent o hasParent -> hasGrandparent". Mary hasParent Bob who hasParent Dave, therefore Mary hasGrandparent Dave.

Thus we can see that a relatively small number of basic assertions about individuals can be used with class definitions and object properties to infer a larger number of assertion. This is often better than filling in all the assertions manually, since this method has less chance for data entry error.

Click the add individual button. Name the individual Tim and make him Dave's child and and Bob's sibling. Run the reasoner again and make sure Tim shows up in inferred object properties for both Dave and Bob.

Additional Resources

For a mind blowing (and potentially computer crashing)-ly large and detailed family ontology see  http://www.cs.man.ac.uk/~stevensr/ontology/family.rdf.owl. Load it up in Protege but run the reasoner at your own risk!

A description of the protege interface can be found here  http://protegewiki.stanford.edu/index.php/Protege4Views. Its a little light in parts but is a good resource.

Not sure what a particular OWL 2 concept is all about? Check here  http://www.w3.org/TR/owl2-primer/

Attachments