OwlBestPractices
category:Drop === OWL 1.0 /Protege-OWL Tips, Warnings, and Best Practices
=
The following were extracted from the CO-ODE Protege-OWL Tutorial (2004), with some additions using recent examples from OBO Foundry ontology development efforts.
| ^ Issue | ^ Topic | Comment | Page |
| ^ 1 | ^ Class construction and necessary constraints | < In OWL classes are built up of descriptions that specify the conditions that must be satisfied by an individual for it to be a member of the class. | ^ 14 |
| ^ 2 | ^ Mulitple Inheritance | < Individuals may belong to more than one class. | ^ 14 |
| ^ 3 | ^ Open World Assumption (OWA) & Disjoints | < OWL Classes are assumed to overlap. We therefore cannot assume that an individual is not a member of a particular class simply because it has not been asserted to be a member of that class. In order to separate a group of classes we must make them disjoint from one another. This ensures that an individual which has been asserted to be a member of one of the classes in the group cannot be a member of any other classes in that group.. | ^ 20 |
| ^ 4 | ^ Sub-classing implications | < _In OWL subclass means necessary implication. In other words, if <MouseARO:heart> is a subclass of <CARO:heart> then ALL instances of <MouseARO:heart> are instances of <CARO:heart>, without exception � if something is a <MouseARO:heart> then this implies that it is also a <CARO:heart>..._ | ^ 23 |
| ^ 5 | ^ Ontology Normalization | < Being able to use a reasoner to automatically compute the class hierarchy is one of the major benefits of building an ontology using the OWL-DL sub-language. Indeed, when constructing very large ontologies (with upwards of several thousand classes in them) the use of a reasoner to compute subclass-superclass relationships between classes becomes almost vital. Without a reasoner it is very difficult to keep large ontologies in a maintainable and logically correct state. In cases where ontologies can have classes that have many superclasses (multiple inheritance) it is nearly always a good idea to construct the class hierarchy as a simple tree. Classes in the asserted hierarchy (manually constructed hierarchy) therefore have no more than one superclass. Computing and maintaining multiple inheritance is the job of the reasoner. This technique (Sometimes know as ontology normalisation) helps to keep the ontology in a maintainable and modular state. Not only does this promote the reuse of the ontology by other ontologies and applications, it also minimises human errors that are inherent in maintaining a multiple inheritance hierarchy. | ^ 62 |
| ^ 6 | ^ defined vs. described classes | < _It is important to realise that, in general, classes will never be placed as sub-classes of primitive/partial/described classes (i.e. classes that only have necessary conditions) by the reasoner. The exception to this is when a property has a domain that is a primitive class. This can coerce classes to be reclassified under the primitive class that is the domain of the property � the use of property domains to cause such effects is strongly discouraged._ | ^ 64 |
| ^ 7 | ^ inferred graph relations | < _Despite that fact that this facility exists (adding inferred relations to the explicitly defined assertions), it is generally considered a bad idea to put computed/inferred relationships into the �manually constructed� or asserted model whilst an ontology is being developed � we therefore advise against using this button during the development of an ontology._ | ^ 64 |
| ^ 8 | ^ universal constrains are necessary but not sufficient to close a class | < The above universal restriction for ALL hasTopping restrictions on individuals of this class, hasTopping = MozzarellaTopping_ also describes the individuals that do not participate in any hasTopping relationships. An individual that does not participate in any hasTopping relationships what so ever, by definition does not have any hasTopping relationships to individuals that aren�t members of the class MozzarellaTopping and the restriction is therefore satisfied._ | ^ 65 |
| ^ 9 | ^ universal constrains do not imply the existence of a instance exhibiting the constraint | < For a given property, universal restrictions do not specify the existence of a relationship. They merely state that if a relationship exists for the property then it must be to individuals that are members of a specific class. | ^ 65 |
| ^ 10 | ^ Union logical OR; Intersection logical AND | < _In situations like the above example, a common mistake is to use an intersection instead of a union. For example, CheeseTopping INTERSECTION VegetableTopping. This reads, CheeseTopping and VegetableTopping. Although �CheeseTopping and VegetableTopping� might be a natural thing to say in English, this logically means something that is simultaneously a kind of CheeseTopping and VegetableTopping. This is obviously incorrect as demonstrated in section 4.9.4. If the classes CheeseTopping and VegetableTopping were not disjoint, this would have been a logically legitimate thing to say � it would not be inconsistent and therefore would not be �spotted� by the reasoner._ | ^ 68 |
| ^ 11 | ^ defined vs. described classes | < _It is important to realise that, in general, classes will never be placed as sub-classes of primitive/partial/described classes (i.e. classes that only have necessary conditions) by the reasoner. The exception to this is when a property has a domain that is a primitive class. This can coerce classes to be reclassified under the primitive class that is the domain of the property � the use of property domains to cause such effects is strongly discouraged._ | ^ 68 |
| ^ 12 | ^ combining restrictions in a universal constraint | < _In the above example it might have been tempting to create two universal restrictions � one for CheeseTopping (for ALL instances of class, hasTopping relation CheeseTopping) and one for VegetableTopping (for ALL instances of class, hasTopping relation VegetableTopping). However, when multiple restrictions are used (for any type of restriction) the total description is taken to be the intersection of the individual restrictions. This would have therefore been equivalent to one restriction with a filler that is the intersection of MozzarellaTopping and TomatoTopping � as explained above this would have been logically incorrect._ | ^ 68 |
| ^ 13 | ^ closure axioms | < "For every 'hasTopping" assertion, they MUST be either 'hasMozerellaTopping' OR 'hasTomatoTopping'" + "There exist at least one 'hasTopping' assertion that is a 'hasMozerellaTopping' assertion + "There exist at least one 'hasTopping' assertion that is a 'hasTomatoTopping' assertion" his now says that if an individual is a member of the class MargeritaPizza then it must be a member of the class Pizza, and it must have at least one topping that is a kind of MozzarellaTopping and it must have at least one topping that is a member of the class TomatoTopping and the toppings must only be kinds of MozzarellaTopping or TomatoTopping | ^ 71 |
| ^ 14 | ^ closure axioms | < A common error in situations such as above is to only use universal restrictions in descriptions. For example, describing a MargheritaPizza by making it a subclass of Pizza and then only using (For every 'hasTopping" assertion, they MUST be either 'hasMozerellaTopping' OR 'hasTomatoTopping') without any existential restrictions. However, because of the semantics of the universal restriction, this actually means either: things that are Pizzas and only have toppings that are MozzarellaTopping or TomatoTopping, OR, things that are Pizzas and do not have any toppings at all. | ^ 71 |
| ^ 15 | ^ relying on the reasoner and inferred hierarchies - manually asserted heirarchy limited to single inheritance | < _Figure 4.58 shows the current asserted and inferred hierarchies. It is clear to see that the asserted hierarchy is simpler and �cleaner� than the �tangled� inferred hierarchy. Although the ontology is only very simple at this stage, it should be becoming clear that the use of a reasoner can help (especially in the case of large ontologies) to maintain a multiple inheritance hierarchy for us._ | ^ 72
?>
|
