Defining N-ary Relations

Natasha Noy, Stanford University
Alan Rector, University of Manchester
Last revised: May 4th, 2004

[Note: This document will be a part of a larger document that will provide an introduction and overview of all ontology design patterns produced by the Semantic Web Best Practices and Deployment Working Group]

General issue

In OWL, a property is a binary relation: it links two individuals or an individual and a value. How do we represent relations among more than two individuals? How do we represent properties of a relation, such as our certainty about them, severity or strength of a relation, relevance of a relation, and so on?

Use case examples

Several common use cases fall under the category of n-ary relations. Here are some examples:

Christine has breast cancer with high probability. There is a binary relation between the person Christine and diagnosis breast_cancer and there is a qualitative probability value describing this relation (high).
Steve has temperature, which is high, but falling. The individual Steve has two values for two different aspects of a has_temperature relation: its magnitude is high and its trend is falling.
John buys a "Lenny the Lion" book from Mary for $15 as a birthday gift. There is a relation, in which individuals John and Mary and the book Lenny_the_Lion participate in. This relation has other values such as the purpose (birthday_gift) and the amount ($15).

Representation pattern

In OWL, we have only binary relations (properties) between individuals, such as a property P between an individual A and individual B (more precisely, P is the property of A with the value B):

We would like to have another individual or simple value C to be part of this relation:

In other words, P is now a relation among A, B, and C.

The general solution to representing n-ary relations such as these is to reify the relation among several individuals or values into a separate individual object.

Depending on the relationship between A, B, and C, we distinguish two patterns to represent n-ary relationships in OWL:

In the first case (pattern 1), one of the individuals in the relationship (say, A) is distinguished from others in that it is the originator of the relationship.Just like in the case of binary relation, where P was a property of A with value B, here the reified relation is a property of A, with the value that is a complex object in itself, relating several values and individuals. Examples 1 and 2 from the list above fall under this category: Christine and Steve in these examples are individuals that the properties are describing.

In the second case (pattern 2), the n-ary relationship represents a network of participants that all play different roles in the relation, but two or more of the participants have equals "importance" in the relation. Example 3 above would usually fall into this category: At least John, Mary, and the Lenny_The_Lion book seem to be equally important in this purchasing relation.

Pattern 1:

If we need to represent a value describing a relationship (example 1, Christine has breast cancer with high probability) or represent an object of a relationship that has different aspects (example 2, Steve has temperature, which is high, but falling), we can create an individual that includes the relation object itself, as well as the additional information about the object:

For the example 1 above (Christine has breast cancer with high probability), the individual Christine has a property has_diagnosis that has another object (Diagnosis_Relation_1, an instance of the reified relation Diagnosis_Relation) as its value:

The individual Diagnosis_Relation_1 here is the reified relation representing as a single object both the diagnosis (breast_cancer) and the probability of the diagnosis (HIGH)¹:

:Christine
      a       :Person ;
      :has_diagnosis :Diagnosis_Relation_1 .

:Diagnosis_Relation_1
      a       :Diagnosis_Relation ;
      :diagnosis_probability :HIGH;
      :diagnosis_value :Breast_Cancer .

Here is a definition of the class Diagnosis_Relation:

:Diagnosis_Relation
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Disease ;
                owl:onProperty :diagnosis_value
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Probability_values ;
                owl:onProperty :diagnosis_probability
              ] .

In the definition of the Person class (of which the individual Christine is an instance) we specify a property has_diagnosis with the range restriction going to the Diagnosis_Relation class (of which Diagnosis_Relation_1 is an instance):

:Person
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Diagnosis_Relation ;
                owl:onProperty :has_diagnosis
              ] .

OWL code for this example

[N3] [RDF/XML abbrev] [Abstract syntax]

We have a different use case in the example 2 above (Steve has temperature, which is high, but falling): In the example with the diagnosis, many will view the relationship we were representing as in a fact still a binary relation between the individual Christine and the diagnosis breast_cancer that has a probability associated with it. The relationship in this example is between the individual Steve and the object representing different aspects of the temperature he has. In most intended interpretations, this relationship cannot be viewed as a binary relation with additional attributes attached to it. Rather it is a relation between the individual Steve and the complex object representing different facts about his temperature.

The OWL pattern that implements this intuition is however the same as in the pervious example. A class Person (of which the individual Steve is an instance) has a property has_temperature which has as a range a reified-relation class Temperature_Relation. Instances of the class Temperature_Relation (such as Temperature_Relation_1 in the figure) in turn have properties for temperature_value and temperature_trend.

OWL code for this example

[N3] [RDF/XML abbrev] [Abstract syntax]

Pattern 2:

In some cases, the n-ary relationship represents a network of individuals that play different roles in a structure without any single individual standing out as the originator or the owner of the relation, such as Purchase in the example 3 above (John buys a "Lenny the Lion" book from Mary for $15 as a birthday gift). Here, the relationship explicitly has more than one participant, and, in many contexts, none of them can be considered a primary one. In this case, we create an individual to represent the relation with links to all participants:

In our specific example, the representation will look as follows:

Purchase_1 is an individual instance of the Purchase class representing a reified relation:²

:Purchase_1
      a       :Purchase ;
      :has_agent :John ;
      :has_object :Lenny_The_Lion ;
      :has_purpose :Birthday_Gift ;
      :has_recipient :Mary .

where the class Purchase is defined as follows (we require that each purchase has at least an agent and an object):

:Purchase
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Purpose ;
                owl:onProperty :has_purpose
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Person ;
                owl:onProperty :has_agent
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:minCardinality "1" ;
                owl:onProperty :has_agent
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Object ;
                owl:onProperty :has_object
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:allValuesFrom :Person ;
                owl:onProperty :has_recipient
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:minCardinality "1" ;
                owl:onProperty :has_object
              ] .

OWL code for this example

[N3] [RDF/XML abbrev] [Abstract syntax]

Considerations when representing n-ary relations

In many cases, the choice between the two patterns above is subjective. We have described the difference in terms of the relative importance of various participants in the relation. In many cases, making this judgment will be difficult, and both pattern will be appropriate. For instance, if we want to represent the fact that, in human anatomy, head and neck are adjacent along the vertical axis, we can look at this relationship in two ways.
(1) We want to specify a is_adjacent_to property for the head, and the value of that property is a reified relation linking it to the neck and specifying the axis as an additional attribute in the relation (pattern 1)
(2) We want to specify an individual adjacency_relation that has head and neck as its two values for the property object and horizontal as the value for the property axis.
In our example, we did not give meaningful names to the individuals representing reified relations. These individuals usually play auxiliary purpose of grouping together several objects and do not stand on their own. As a result, it is common not to have meaningful names for them (in particular if following pattern 1) and refer to them only in the context of individuals and properties for which they are the values. Note that a similar approach is taken when reifying sentences in RDF.
Defining inverse properties with n-ary relations, using any of the two patterns above, requires more work than with binary relations. Each of the properties participating in the n-ary relation should have its own inverse property (with the proper constraints). Consider the example of John buying the Lenny_The_Lion book. We may want to have an inverse relation pointing from the Lenny_The_Lion book to the person who bought it. If we had a simple binary relation John buys Lenny_The_Lion, defining an inverse is simple: we simply define a property is_bought_by as an inverse of buys:
```
:is_bought_by
      a       owl:ObjectProperty ;
      owl:inverseOf :buys .
```
With the purchase relation reified, however, we need to add inverse relations between participants in the relation and the reified relation itself:

For example, the definitions of the inverse relations for for agent and object of a purchase, look as follows:
```
:is_agent_for
      a       owl:ObjectProperty ;
      owl:inverseOf :has_agent .
:is_object_for
      a       owl:ObjectProperty ;
      owl:inverseOf :has_object .
```
And the definition of the Person class (taking into account the inverse for the recipient property) is:
```
:Person
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :is_recipient_for ;
                owl:allValuesFrom :Purchase
              ] ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:onProperty :is_agent_for ;
                owl:allValuesFrom :Purchase
              ] .
```
Note that the value of the inverse property is_agent_for for the individual John, for example, is the individual Purchase_1 rather than the object or recipient of the purchase.

Notes

For simplicity, we represent each disease as an individual. This decision may not always be appropriate, and we refer the reader to a different note (ref to be added). Similarly, for simplicity, we represent probability values as a class that is an enumeration of three individuals (HIGH, MEDIUM, and LOW):
```
:Probability_values
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:oneOf (:HIGH :MEDIUM :LOW)
              ] . 
```
There are other ways to represent partitions of values. Please refer to a different note (ref to be added)
For simplicity, we will ignore the fact that the amount is expressed in $ and will use a simply number as the value for the property. For a discussion on how to represent units and quantities in OWL, please refer to a different note (ref to be added)