Decision Incubator Tools/OWL Tutorial

OWL Tutorial

To familiarize with the OWL constructs available and their semantics, you should performed the following small modeling exercise. It takes you through some of the features of OWL and also some of the pitfalls. Before you start you should be aware of what OWL and RDF are and have some idea (at least a vague one) of the logics behind.

So, let's model! Your model should be within OWL-DL, meaning the DL-species of OWL 1.0. Treat the statements below as the requirements of your model, they should all be explicitly represented. The result of your modeling should take into account mainly these requirements, but also some modeling best practices, such as:

• Use a resolvable URI for your ontology. In principle, all ontologies should be accessible online and have a resolvable URI, but of course for this exercise you can give the ontology an invented URI. The URI of the ontology should correspond to the base namespace of the ontology.
• Use a naming convention for your ontology. Space is not allowed in identifiers for OWL entities, decide if you want to use _ or maybe the camel notation.
• Since ontologies define concepts, naming is more important than in for example programming. Many times potential users will look only at your model in order to decide what it means and if they can reuse it. Crazy, I know... but documentation practices are not wide spread in this field. However, even despite this an ontology should be as clear and self-explaining as possible. This means...
  • Class names should be singular, unless you really mean that the instances will represent sets of things. Example: The class Country would have an instance UK to denote the country, while the class Countries would have instances like MediterraneanCountries, i.e. the instances should be sets of countries.
  • As far as possible the class hierarchy should be reflected in the class names, meaning that more specific classes will most likely have longer names. Example: In a product ontology we could have the class Product, with the subclass Software, in turn with the subclass Microsoft. What is wrong? If we see all the classes together, all seems well, but what happens when we look at another class with a restriction looking like "allowedToBuy allValuesFrom Microsoft", does it mean that this class of customers are only allowed to buy instances of the Microsoft corporation? Not really... then we have to look at the class Microsoft and note that it is a subclass of Software, and Product, to realize that we most likely mean they are only allowed to buy software products from Microsoft. A better naming would have been Product - SoftwareProduct - MicrosoftSoftwareProduct.
  • Property names should be meaningful and "readable" together with the classes they are applied to. For a human being it is much easier to understand a property if you can read out the relation. Example: An ontology has a property "has" holding between instances of "Person" and other instances of "Person". Depending on the intended use of the ontology this could have many meanings, maybe the person has another person on their e-mail contact list or on facebook, maybe a person has a spouse or a child. A fact would read just "Bill has Bob", which doesn't say much about what it means, we would have to start looking at restrictions and comments to find out more. A better approach would be to in the first case name the relation something like "hasContact" so that a fact would read "Bill hasContact Bob", and in the second case maybe "hasSpouse" and "hasChild" so that facts would be "Bill hasSpouse Mary" and "Bill hasChild Bob", which are immediately clear to the reader.
• To make properties more clear and allow for easier reasoning, always add inverses of object properties if they exist.
• Always add labels and comments to all classes and properties. The label should give a human readable name for the entity, and the comment should explain the intention of the entity, i.e. the intended meaning.

Design an ontology containing statements representing the following sentences:

   1.  A doll is a kind of toy (hint)
   2.  Young women are defined as young persons that are also female (hint)
   3.  A young person cannot be both a young man and a young woman (hint)
   4.  Young persons are either young men or young women (hint)
   5.  Lenore and Emily are famous dolls (hint)
   6.  All young women play with some doll (hint)
   7.  Young women play only with famous dolls (hint)
   8.  Young men play with at least one toy (hint)
   9.  Clara is a young woman (hint)
   10. Clara and Laura are different individuals (hint)
   11. Lalu is the same person as Laura (hint)
   12. To dress a toy is a special case of playing, where the toy is a doll (hint)
   13. To be dressed by a young person is the inverse relation of a young person dressing a doll (hint)
   14. To be related to a person is a transitive relation that holds between persons, 
       a more specific (non-transitive) relation is the parent-child relation. (hint)

To see that you understood the basics, play around with the reasoner a bit. Try to make some classifications (using the classes that have equivalentClass definitions), try to make your ontology inconsistent etc.

An example solution can be found here http://www.ontology.se/examples/toys-and-dolls.owl

Note that this is not the only possible solution, merely an example of an ontology modeling the above sentences.