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 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 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 the First 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 is a draft document 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 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 it, severity or strength of a relation, relevance of a relation, and so on?
Several common use cases fall under the category of n-ary relations. Here are some examples:
Christine
and diagnosis breast_cancer
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 Amazon.com
and the book Lenny_the_Lion
participate
in. This relation has other values such as the purpose (birthday_gift
)
and the amount ($15
). 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:
In other words, P
is now a relation among A
, B
,
and C
.
A common solution to representing n-ary relations such as these is to create an individual which stands for an instance of the relation and relates the things that are involved in that instance of the relation. We can think of the original relation then as a class of all these relation instances.
Depending on the relation between A
, B
, and C
,
we distinguish two patterns to represent n-ary relations in RDF and OWL:
In the first case (pattern 1), one of the individuals
in the relation (say, A
) is distinguished from others in that
it is the originator of the relation. Just like in the case of
binary relation, where P
was a property of A
with
value B
, here the instance of the relation itself 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 relation
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
,
Amazon.com
, and the Lenny_The_Lion
book seem to be
equally important in this purchasing relation.
An interested reader may also want to look at the discussion of reification
[3] and rdf:value
[4]
in RDF.
If we need to represent a value describing a relation (example 1, Christine has breast cancer with high probability) or represent an object of a relation 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
relation Diagnosis_Relation
) as its value:
The individual Diagnosis_Relation_1
here represents a single object
both the diagnosis (breast_cancer
) and the probability of the diagnosis
(HIGH
)1:
:Christine
a :Person ;
:has_diagnosis :Diagnosis_Relation_1 . :Diagnosis_Relation_1
a :Diagnosis_Relation ;
:diagnosis_probability :HIGH;
:diagnosis_value :Breast_Cancer .
The corresponding class definitions 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 individual 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_Relation_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_cancer
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 relation
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 RDFS and OWL patterns that implement this intuition are 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 the 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
.
[RDFS]
[N3] [RDF/XML abbrev] [Abstract syntax]
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
Amazon.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
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 relation:2
:Purchase_1
a :Purchase ;
:buyer :John ;
:object :Lenny_The_Lion ;
:purpose :Birthday_Gift ;
:seller :Amazon.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) 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 linking it to the neck
and specifying the axis
as an additional attribute in the relation
(pattern 1)adjacency_relation
that
has head
and neck
as its two values for the property
object
and horizontal
as the value for the property
axis
.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_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.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, in OWL 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). In RDF Schema version, we represent them simply as strings, also for simplicity reasons.
[1] http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0091.html
[2] http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0016.html
[3] http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#reification
[4] http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue