Protege OWL Plugin Short Tutorial

OWL Usage The world wide web is a natural application area of ontologies, because ontologies could be used to describe the contents of web pages. For example, the definitions from an animal ontology could be used to annotate images from certain animals, and thus tell an intelligent agent that this image shows a black squirrel, while another image shows a spotted koala. OWL defines syntax and semantics for an ontology language that can be used on the web for these purposes.

Syntax vs. Element Catalog OWL documents are typically stored in terms of an XML/RDF file. However, these files are awkward to read, and few people will want to edit them directly. Much more relevant than the syntax of OWL documents is the catalog of modeling elements that it provides.

Resource Types OWL ontologies roughly contain three types of resources: –Classes define concepts from the domain (e.g., the class Koala) –Individuals represent specific instances of classes (e.g., the pink Koala I just saw in my garden) –Properties define the values that each individual can take (e.g., the specific Koala has the color pink)

Strength of OWL Other modeling languages such as UML or XML have similar modeling constructs, and basically OWL can be compared to them. However, the strength of OWL is that it allows us to specify the meaning of classes and properties in various ways, so that intelligent programs can reason about it.

Example

Example Koala is a subclass of Marsupial –In Prot é g é, Koala is shown in the hierarchy below Marsupials, and Marsupial is listed under the necessary conditions. –This means that Koala is a kind of Marsupial. In other words, if we know that something is a Koala, then we also know that it is a Marsupial. –Subclasses inherit the characteristics of their superclasses, i.e. if we have a Koala, then all we know about Marsupials also applies to the Koala.

Example Koalas have dry eucalypt forests as their habitat –In Prot é g é, there is a necessary condition which states that the hasHabitat property must have at least one value of type DryEucalyptForest. –It can have other habitats, too, but we know that one of them must be of the given forest type.

Example Koalas are not hard working –In Prot é g é, there is a necessary condition which states that the isHardWorking property has the value false (the strange e-symbol means "has value"). –This provides some useful information about koalas in general. And they really are lazy. –The restriction means that the property isHardWorking must have the value false for all Koalas. Otherwise it cannot be a Koala, and an intelligent system would notify us about this oddity.

Example Koalas must have exactly one gender and at least one habitat –These two restrictions are inherited from the class animal, because they also hold for animals in general, and not only for koalas. –In Prot é g é, these conditions are listed under "inherited".

Restriction These examples illustrate that you basically define classes by restricting their property values. You can combine various restrictions, and they are inherited into subclasses. The combinations of these restrictions define all conditions that must hold for individuals of the given class.

Necessary Conditions All of the above conditions were necessary conditions only. They only apply in one direction: If we know that something is a koala, then we can deduce that it lives in dry eucalypt forests. If we know that something is an animal, then we can deduce that it has at least one habitat. These conditions do not hold in the other direction: If we know that something lives in a dry eucalypt forest, then we cannot deduce that this thing is necessarily a koala. It could also be a quokka, or a tasmanian devil, for example.

Necessary and Sufficient Conditions If you want to define stronger, bidirectional relationships, then you need to define necessary and sufficient conditions for a class.

Example The class MaleStudentWith3Daugthers is defined as the set of all student that fulfill the given three conditions: –All children of the Student must be of type Female (i.e. daughters) –There must be exactly three children –The Student must have male gender These conditions are listed under necessary & sufficient, i.e. anything that fulfills these conditions at the same time must be an instance of the class MaleStudentWith3Daughters.

Classifiers This is a very powerful statement, and a cornerstone of intelligent reasoning with OWL (using Description Logics). If a class has necessary & sufficient conditions, then intelligent tools can find out additional characteristics of these classes. These tools are called classifiers, and you can find some OWL classifiers on the web (e.g. Racer or FaCT). When you invoke Racer with Protege, the system will show the results of classification such as in the screenshot below.

Inferred In addition to the elements of the ontology that we have asserted, the system displays those that the classifier has inferred, Example: MaleStudentWith3Daughters is a subclass of Male –While the asserted hierarchy only shows MaleStudentWith3Daughters as a subclass of Student, the inferred hierarchy also displays it below Male. –The system has exploited the definition of MaleStudentWith3Daughters, which is a Student whose gender is male plus some other characteristics. –The class Male (not shown here, but you can browse it in Protege) is defined as the class of everything where the hasGender property has the value male. –This is a sufficient condition, and thus the system can find out that any MaleStudentWith3Daughters must also be a Male, although we never explained this to the system.

Inferred MaleStudentWith3Daughters is a subclass of Parent A Parent is defined as an animal that has at least one child. Since we stated that every MaleStudentWith3Daughters has 3 children, the system can deduce that he also has 1 child, and thus must be a Parent, too. This is also displayed in the inferred conditions of the class, where Male and Parent are now listed under the necessary conditions.

Inconsistencies Protege displays both asserted and inferred hierarchies in separate trees, and also provides a list of differences that the classifier has found. Beside changes in the class hierarchies, classifiers can also find inconsistencies between class definitions. (The following screenshot displays an inconsistent class)

Example The class KoalaWithPhD is inconsistent (displayed with a red border), because it defines the class of all Koalas where the hasDegree property has the value PhD. This is fairly uncommon in the real world, and especially contradicts the definitions of our classes. The system here exploits the knowledge that –only Persons can have a degree (formally: the domain of the property hasDegree is Person) –Persons and Marsupials are disjoint, i.e. there is no individual that is at the same time a Person and a Marsupial

Ontology Design Classification and consistency checks support the developers of ontologies very well. During ontology design, you may frequently invoke the classifier to see whether you missed some hidden relationships, or whether you introduced a contradiction. Overall, this should make ontologies much more reusable and safer to use.

Model Modification Whenever the classifier has revealed some new information, you may want to change your model. The list of asserted conditions allows you to copy and paste, and drag and drop conditions between the blocks. For example, you can convert a necessary condition into a necessary & sufficient condition using drag and drop. You can also define multiple blocks of sufficient conditions, in which case each of the blocks must be true for the class.