Reification of properties in an ontology

Abstract

Reification is a technique enabling a richer description of a property. Traditionally, “reification” has been used to support descriptions of the source of knowledge; instead of statements of fact such as “father kicked the cat”, we can say “I saw father kicked the cat”. However, more broadly, reification can support many different kinds of statements about properties. In this article, we consider a design pattern for reification in OWL, the advantages and disadvantages of using this pattern and where its use is appropriate.

Authors

Robert Stevens
School of Computer Science,
The University of Manchester

Phillip Lord
School of Computing Science
Newcastle University

Introduction

Ontologies generally deal with clear statements of fact, such as “Father kicked the Cat”. Unfortunately for the ontologist, the world they are attempting to model is often considerably less clear; they may be required to support a broad range of statements that modify or contextualise this fact: “I saw father kick the cat”, “from the bruising, father probably kicked the cat”, “while in a rage, father kicked the cat”. The contextualisation, for example, enables statements that would otherwise appear to be contradictory to exist in an ontology: “John saw father kick the cat”, “Paul saw father didn’t kick the cat”.

Support for Reification

Some knowledge representation languages such as RDF directly support reification. However, OWL does not allow the ontologist to qualify properties in this way. The solution is to use the n-ary relation pattern. In approximate English paraphrase, we might replace “I saw Father kick the cat” with three statements:

Father engaged_in Kicking
Kicking was_received_by the Cat
Kicking was_observed_by Me

In this example, we have removed the single property (kicked), and replaced it with three others (engaged_in, was_recieved_by, was_observed_by) and a class (Kicking). In general, each form of reification will require an extra relationship. For example:

Father engaged_in Kicking
Kicking was_recieved_by the Cat
Kicking was_evidenced_by bruising

Our example has taken the verb “kick” and used it as a property and this is a common technique. Ontologically, these verbs can also been seen as processes that would be represented as classes. So we can take the gerund form of “kick” and form the class “kicking”. the same thing happens with nominalisation of bverbs: taking a biology example, “phosphorylates” becomes a class “phosphorylation”. Ontologically this is seen as good practice. There is a temptation to overload property use in ontologies; reification means more classes are used, but the same properties linking entities together are used.

It is also possible to add some of the extra statements about properties extra-logically in the form of annotations. For example, the Gene Ontology Associations (GOA) uses evidence codes to describe confidence in an annotation of a gene product with a GO term.

Advantages and Disadvantages

There are both advantages and dis-advantages to using reification in an OWL ontology. The key advantage is that it allows the ontologist to produce a model which is appropriate to the domain. A binary relationship has only two objects involved, but often a modeller needs more than two and reification is the way to achieve this. Without reification, different opinions or probabilities cannot easily be expressed within the logical component of the ontology.

This is an over-riding advantage, but it does come at a significant cost. The main problem is that it increases the complexity of the ontology; there are more entities, both classes and properties, involved. As well as causing a significant cost at development time, this also means that queries over, annotation with or other uses of the ontology become more complex. Finally, with OWL, the reified “property” has now become a class, so the ability to specific characteristics such as functionality, transitivity or symmetricality of the property are lost; this can be overcome in some cases, but again at a cost in complexity.