Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
In Semantic Web languages, such as RDF and OWL, a property is a binary relation: it is used to link 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 it, severity or strength of a relation, relevance of a relation, and so on? The document presents ontology patterns for representing n-ary relations and discusses what users must consider when choosing these patterns.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
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.
This document is a W3C Working Draft and is expected to change. The SWBPD WG does not expect this document to become a Recommendation. Rather, after further development, review and refinement, it will be published and maintained as a WG Note.
This document is a Public Working Draft. We encourage public comments. Please send comments to public-swbp-wg@w3.org
Open issues, todo items:Publication as a draft does not imply endorsement by the W3C Membership. This document is a draft and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than work in progress.
In Semantic Web languages, such as RDF and OWL, a property is a binary relation: it is used to link 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 instance, such as our certainty about it, severity or strength of a relation, its relevance, and so on?
Several common use cases fall under the category of n-ary relations. Here are some examples:
Christine and diagnosis breast_tumor
and there is a qualitative probability value describing this relation (high).Steve has two values for two different aspects of a has_temperature
relation: its magnitude is high and its trend
is falling.John,
entity books.example.com and the book Lenny_the_Lion
participate. This relation has other components as well such as the purpose
(birthday_gift) and the amount ($15). LAX, DFW, JFK.
Note that the order of the airports is important and indicates the order in
which the flight visits these airports.In Semantic Web languages, such as RDF and 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 instance:
In other words, P is now an instance of a relation among A,
B, and C. Furthermore, there may be several other
individuals or values such as C that are part of this relation
instance.
One common solution to representing n-ary relations such as these by using only binary relations is to create a special kind of a class. Individual instances of such special classes correspond to instances of a given n-ary relation and relate the components that are involved in that instance of the relation. Another solution is to represent several individuals participating in the relation as a collection or an ordered list.
Depending on the relation among A, B, and C,
we distinguish three patterns to represent n-ary relations in RDF and
OWL: two patterns that introduce a new class for an n-ary relation (pattern
1 and pattern 2)and one pattern that uses a list
to encapsulate several arguments (pattern 3).
We present two patterns where we create a new class to represent an n-ary relation. A specific relation linking several individuals and values is then an instance of this class. Note that while these two patterns are equivalent logically, they provide two different viewpoints and users may find one or the other more convenient in a given situation (see Considerations when introducing a new class for a relation).
In the first case (pattern 1), one of the individuals
in the relation (say, A) is distinguished from others in that it
is the subject of the relation. Just like in the case of a binary relation,
where P was a property of A with value B,
here the instance of the relation itself is a property value of A.
This value 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 relation
represents a network of participants that all play different roles in the relation,
but two or more of the participants have equal "importance" in the
relation. Example 3 above would usually fall into this category: At least John,
books.example.com, and the Lenny_The_Lion book seem
to be equally important in this purchasing relation.
If we need to represent an additional attribute describing a relation instance (example 1, Christine has breast tumor with high probability) or represent a relation instance that has different components (example 2, Steve has temperature, which is high, but falling), we can create an individual that includes the relation instance itself, as well as the additional information about this instance:
For the example 1 above (Christine has breast tumor with high probability),
the individual Christine has a property has_diagnosis
that has another object (Diagnosis_1, an instance of the relation
Diagnosis_Relation) as its value:
The individual Diagnosis_1 here represents a single object encapsulating
both the diagnosis (breast_tumor) and the probability of the diagnosis
(HIGH)2. It contains
all the information held in the original 3 arguments: who is being diagnosed,
what the diagnosis is, and what the probability is.
:Christine
a :Person ;
:has_diagnosis :Diagnosis_1 . :Diagnosis_1
a :Diagnosis_Relation ;
:diagnosis_probability :HIGH;
:diagnosis_value :Breast_Tumor .
Each of the 3 arguments in the original n-ary relation—who is being diagnosed,
what the diagnosis is, and what the probability is—gives rise to a true
binary relationship. In this case, there are three: has_diagnosis,
diagnosis_value and diagnosis_probability.3
The class definitions for the individuals in this pattern look as follows:
The additional labels on the links indicate the OWL restrictions on the properties.
We define both diagnosis_value and diagnosis_probability
as functional properties. We also require that each instance of Diagnosis_Relation
has exactly one value for Disease.
In RDFS, the links represent rdfs:range constraints on the properties.
For example, the class Diagnosis_Relation is the range of the property
has_diagnosis.
Here is a definition of the class Diagnosis_Relation
in OWL, assuming that both properties—diagnosis_value and
diagnosis_probability—are defined as functional (we provide
full code for the example in OWL and RDFS below):
:Diagnosis_Relation
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:someValuesFrom :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_1 is an instance):
:Person
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :Diagnosis_Relation ;
owl:onProperty :has_diagnosis
] .
[RDFS]
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_tumor
that has a probability associated with it. The relation in this example is between
the individual Steve and the object representing different aspects
of the temperature he has. In most intended interpretations, this instance of
a relation cannot be viewed as a binary relation with additional attributes
attached to it. Rather it is a relation instance relating the individual Steve
and the complex object representing different facts about his temperature.
The RDFS and OWL patterns that implement this intuition are however the same
as in the previous example. A class Person (of which the individual
Steve is an instance) has a property has_temperature
which has as a range the relation class Temperature_Relation. Instances
of the class Temperature_Relation (such as Temperature_1
in the figure) in turn have properties for temperature_value and
temperature_trend.
[RDFS]
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 subject or the "owner" of the relation, such as Purchase
in the example 3 above (John buys a "Lenny the Lion" book from
books.example.com for $15 as a birthday gift). Here, the relation 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
instance 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 an instance of a relation:4
:Purchase_1
a :Purchase ;
:buyer :John ;
:object :Lenny_The_Lion ;
:purpose :Birthday_Gift ;
:seller :books.example.com .
The following diagram shows the corresponding classes and properties. For the
sake of the example, we specify that each purchase has exactly one buyer
(a Person), exactly one seller (a Company),
exactly one amount and at least one object (an Object).
The diagram refers to OWL restrictions. In RDFS the arrows can be treated as
rdfs:range links.
The class Purchase is defined as follows in OWL (see the RDFS
file below for the definition in RDFS):
:Purchase
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :Purpose ;
owl:onProperty :purpose
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:cardinality 1 ;
owl:onProperty :buyer
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :buyer ;
owl:someValuesFrom :Person
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:cardinality 1 ;
owl:onProperty :seller
] ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :seller ;
owl:someValuesFrom :Company
] ; rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :object ;
owl:someValuesFrom :Object
] .
[RDFS]
is_adjacent_to property for the head,
and the value of that property is a relation instance linking it to the neck
and specifying the axis as an additional attribute in the relation
instance (pattern 1)adjacency_relation that
has head and neck as its two values for the property
object and vertical as the value for the property
axis.Diagnosis_Relation
to have a property about_patient. Then the individual patient
(Christine) will be the value of this property for the instance
of an n-ary relation rather than having the instance of an n-ary relation
itself as the value of one of its properties.John buying the Lenny_The_Lion book. We may want
to have an instance of 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_byWith the purchase relation represented as an instance, however, we need to add inverse relations between participants in the relation and the instance relation itself:
a owl:ObjectProperty ;
owl:inverseOf :buys .
agent
and object of a purchase, look as follows::is_buyer_forAnd the definition of the
a owl:ObjectProperty ;
owl:inverseOf :buyer . :is_object_for
a owl:ObjectProperty ;
owl:inverseOf :has_object .
Person class (taking into account the
inverse for the recipient property) is::PersonNote that the value of the inverse property
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:onProperty :is_buyer_for ;
owl:allValuesFrom :Purchase
] .
is_buyer_for for
the individual John, for example, is the individual Purchase_1
rather than the object or recipient of the purchase.Some n-ary relations do not naturally fall into either of the two patterns above, but are more similar to a list or sequence of arguments. The example 4 above (United Airlines flight 3177 visits the following airports: LAX, DFW, and JFK) falls into this category. In this example, the relation holds between the flight and the airports it visits, in the order of the arrival of the aircraft at each airport in turn. This relation might hold between many different numbers of arguments, and there is no natural way to break it up into a set of distinct properties relating the flight to each airport. At the same time, the order of the arguments is highly meaningful.
In cases where all but one participants in a relation do not have a specific role and essentially form a list, it is natural to connect the airport arguments into a sequence and to relate the flight to this sequence. We represent the sequence as a list, where each list item points to its content and to the rest of the list:
RDF in fact supplies a vocabulary for just this purpose—the collection
vocabulary. Thus, implementation of this pattern in RDF is straightforward:
We simply use rdf:List for this purpose. Individuals List_1,
List_2, List_3 and Empty_List are instances
of rdf:List; the property has_contents is, in fact,
the property rdf:first and the property rest_of_list
is simply rdf:rest. We provide the full RDFS
code for this example.
We can use the same rdf:List construct in OWL. However, using
rdf:List this way in OWL puts the ontology in OWL Full. If we want to keep the
ontology in OWL-DL, we can explicitly define the properties in the figure above
in our OWL ontology:
[RDFS]
rdf:first
and rdf:rest or has_contents and rest_of_list—(and
the empty-list individual) for any number of arguments and any number of instances,
and it permits some elegant techniques for manipulating the sequences. These
patterns are commonly used in programming, and have been called S-expressions,
or linked list structures.rdf:List
directly.It may be natural to think of RDF
reification when representing n-ary relations. Using the RDF reification
vocabulary to represent n-ary relations in general is a bad idea. The RDF reification
vocabulary is designed to talk about statements—individuals that
are instances of rdf:Statement. A statement is a object, predicate,
subject triple and reification in RDF is used to put additional information
about this triple. This information may include the source of the information
in the triple, for example. In n-ary relations, however, additional arguments
in the relation do not usually characterize the statement but rather provide
additional information about the relation instance itself. Thus, it is more
natural to talk about instances of a diagnosis relation or a purchase rather
than about a statement.
@@TODO
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 note on Representing Specified Values in OWL [Specified Values ]. In RDF Schema version, we represent them simply as strings, also for simplicity reasons.
rdf:value
that is appropriate in examples such as the Diagnosis example here. While
rdf:value has no meaning on its own, RDF specification encourages
its use as a vocabulary element to identify the "main" component
of a structured value of a property. Therefore, in our example, we made diagnosis_value
a subproperty of rdf:value property instead of diagnosis_value
property to indicate that diagnosis_value is indeed the "main"
component of a diagnosis.