Informal description
This section is informative: it provides a readable, informal, but
essentially complete overview of how constructs in the two paradigms
relate to each other. Details and formal definitions are to be found in
Section 5.
The mechanism for expressing guidance is based on properties and
classes in the rdftm vocabulary. The guidance consists for the
most part in asserting properties in other vocabularies to be instances
of rdftm classes, or to have rdftm properties.
Explanatory examples are given in the [LTM] and [N3] syntaxes for Topic Maps and RDF, respectively.
Things and proxies
Topic Maps and RDF share the common purpose of enabling assertions
(or statements) to be made about things that exist in some
domain of interest. The things
about which assertions are made
are called subjects and resources in Topic Maps and
RDF, respectively.
The term subject as used in Topic Maps should not be
confused with the term as used in RDF, where it denotes one of the
components of an RDF triple. Note also that the term resource
is commonly used in Topic Maps in the sense of information
resource, which is more restricted than the RDF usage of the
term.
Subjects in Topic Maps and resources in RDF can be regarded as being
fundamentally equivalent. In practice, they can both be anything at all,
including abstractions, objects in the real world, documents, and
more.
The things about which Topic Maps and RDF allow statements to be made
are represented by proxies. In Topic Maps, those proxies are
called topics; in RDF they tend to be called
resources, like the things they represent, such that the
distinction between the thing and its proxy is blurred. A more precise
term for the proxy in RDF is RDF node
, except that the latter
includes both nodes with identity (URIs and blank nodes) and literals.
In Topic Maps, literals are strings, which are distinct from topics, so
there is not a complete equivalence between topics and RDF nodes. In
this document we use the term resource as the equivalent of both
subject and topic, in order to conform to everyday RDF
usage.
Since there is a close equivalence between topics and resources,
these should generally be mapped to each other when translating TM2RDF
or RDF2TM. More precisely:
In TM2RDF:
A topic that has one or more characteristics or identifiers
should always be mapped to a resource.
A topic that has no characteristics or identifiers cannot be
mapped to a resource, since resources only exist in the context of RDF
statements. It can also not be mapped to a property, since a property
requires a URIref, which can only come from a subject
identifier.
In RDF2TM:
A resource which is the subject of one or more RDF statements
should be mapped to a topic.
A property should be mapped to a topic which is then used to type
names, occurrences, or associations.
A resource which only occurs as the object of a statement (and
never as the subject or predicate) should be mapped to a topic if the
statement itself is mapped to an association (see Section 3.6);
otherwise it should be mapped to the value of an occurrence.
Assertions, types, and properties
The basic construct for making assertions is called a
statement in both Topic Maps and RDF. These Guidelines
recommend that RDF statements in general be mapped to TM statements, and
vice versa. However, Topic Maps distinguishes between three
kinds of statement: names, occurrences, and associations, so
the translation is not entirely straightforward:
In RDF2TM, the fundamental issue is to decide what kind of TM
statement each RDF statement should be mapped to. Guidelines for making
this decision are given throughout Sections 3.4–3.6, are collected
together in Section 3.10.
In TM2RDF, most TM statements are mapped to a single RDF
statement. However, non-binary associations and names that have variants
require special treatment. Guidelines are given in sections
3.4–3.6.
Name types, occurrence types, and association types are always mapped
to RDF properties, and vice versa. The subject identifier of the typing
topic maps to the URIref of the RDF property, and vice versa. Special
considerations applying to the handling of association role types are
covered in Section 3.6.
Identity
Both Topic Maps and RDF use URIrefs as identifiers (for subjects and
resources, respectively). However, in Topic Maps there are two ways in
which a URIref can be used to identify a subject:
directly, as the locator of an information resource that
is the subject, in which case the URIref is called a subject
locator; or
indirectly, as the locator of an information resource
that provides some human-interpretable indication of the subject, in
which case it is called a subject identifier.
In Topic Maps, it is always clear whether the URIref is a subject
locator or a subject identifier.
Since RDF does not make this distinction, the question arises, in
RDF2TM, whether to map the URIref of a resource to a subject locator or
to a subject identifier; and, conversely, in TM2RDF, whether to map
subject locators or subject identifiers (or neither, or both) to the
URIrefs of resources.
Any solution which privileges one type of identifier will lead to
unnatural results with identifiers of the other type. These Guidelines
therefore advocate a solution that retains some of the ambiguity of the
RDF approach and produces the most natural results, while at the same
time preserving information necessary for roundtripping. The solution
hinges on the assumption that topics with subject locators are
implicitly or explicitly instances of the class
rdftm:InformationResource, since in the Topic Maps paradigm,
only information resources can have subject locators, while any kind of
subject can have subject identifiers.
Item identifiers are devoid of any specified semantics and
therefore need not be preserved. However, applications are free to use
them to generate meaningful
internal IDs for blank nodes, and
vice versa. (For ease of understanding, examples in this document do
this; for example, a topic with the item identifier puccini
(and no other identifiers) is shown as an RDF blank node with the ID
_puccini.)
The rules for translating identity are as follows:
When a topic gives rise to a resource:
If the topic has one or more subject locators, one subject
locator (chosen at random) becomes the URIref of the resource; the
resource is made an instance of rdftm:InformationResource
(e.g., through the type of the resource being made an subclass of this
class); additional subject locators become owl:sameAs
properties; and any subject identifiers become
rdftm:subjectIdentifier properties (example ).
If the topic has one or more subject identifiers and no subject
locators, one subject identifier (chosen at random) becomes the URIref
of the resource. Additional subject identifiers become
owl:sameAs properties (examples and
).
Topics with neither subject identifier nor subject locator become
blank nodes (example ).
Item identifiers are discarded.
When a topic gives rise to a property:
One subject identifier (chosen at random) becomes the URIref
of the resource. Additional subject identifiers become
owl:sameAs properties.
All other identifiers are discarded.
A topic without a subject identifier cannot give rise to a
property.
In the examples below, [...] stands for statements about the
subject that must necessarily exist unless the resource is a
property.
[survey : dc:Document
%"http://www.w3.org/TR/rdftm-survey/"
@"http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey"]
▼
<http://www.w3.org/TR/rdftm-survey/>
rdftm:subjectIdentifier
<http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey> ;
[...] .
dc:Document rdfs:subClassOf rdftm:InformationResource .
[puccini @"http://en.wikipedia.org/wiki/Puccini"]
▼
<http://en.wikipedia.org/wiki/Puccini>
[...] .
[music:puccini @"http://en.wikipedia.org/wiki/Puccini"]
▼
music:puccini
owl:sameAs <http://en.wikipedia.org/wiki/Puccini> ;
[...] .
- or -
<http://en.wikipedia.org/wiki/Puccini>
owl:sameAs music:puccini ;
[...] .
[puccini]
▼
_puccini [...] .
When a resource gives rise to a topic:
If the resource is an instance of
rdftm:InformationResource, the URIref becomes a subject
locator; any owl:sameAs properties become additional subject
locators; the values of properties that are subproperties of the
property rdftm:subjectIdentifier become subject identifiers
(examples , and ).
If the resource is not explicitly an instance of
rdftm:InformationResource, the URIref becomes a subject
identifier; any owl:sameAs properties, together with the values
of properties that are subproperties of
rdftm:subjectIdentifier, become additional subject identifiers
(examples and ).
Blank nodes become topics with generated item identifiers
(example ).
When a property gives rise to a topic:
<http://www.w3.org/TR/rdftm-survey/> rdf:type dc:Document .
dc:Document rdfs:subClassOf rdftm:InformationResource .
▼
[idXYZ : dc:Document %"http://www.w3.org/TR/rdftm-survey/"]
<http://www.w3.org/TR/rdftm-survey/>
rdf:type rdftm:InformationResource ;
rdftm:subjectIdentifier <http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey> .
▼
[idXYZ : rdftm:InformationResource
%"http://www.w3.org/TR/rdftm-survey/"
@"http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey"]
<http://www.w3.org/TR/rdftm-survey/>
rdf:type dc:Document ;
skos:subjectIdentifier <http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey> .
dc:Document rdfs:subClassOf rdftm:InformationResource .
skos:subjectIdentifier rdfs:subPropertyOf rdftm:subjectIdentifier .
▼
[idXYZ : dc:Document
%"http://www.w3.org/TR/rdftm-survey/"
@"http://www.w3.org/2001/sw/BestPractices/RDFTM#Survey"]
<http://en.wikipedia.org/wiki/Puccini>
[...] .
▼
[puccini @"http://en.wikipedia.org/wiki/Puccini"]
music:puccini
owl:sameAs <http://en.wikipedia.org/wiki/Puccini> ;
[...] .
▼
[music:puccini @"http://en.wikipedia.org/wiki/Puccini"]
[puccini]
▼
_puccini [...] .
The following classes and properties are involved in the guidance for
identity:
Names
A topic name is the equivalent of an RDF statement that
assigns a label to a resource. A name thus maps to a single statement
whose predicate is the same as the name type.
In order to preserve the information that the statement has the
semantics of a topic name, the property is declared to be an instance of
the class rdftm:NameProperty.
The property rdfs:label deserves particular attention. It
may be used in RDF in order to provide a human-readable version of a
resource's name. However, in OWL it is defined as an instance of
owl:AnnotationProperty, which means that it cannot be used in
property axioms. This prevents these Guidelines from making
rdfs:label the subject of a guidance statement.
Is this correct?
However, many RDF documents use rdfs:label as a naming
property, and many RDF vocabularies declare properties that have naming
semantics (such as skos:prefLabel) to be subproperties of
rdfs:label. These Guidelines therefore recommend that
rdfs:label and any property, X, declared to be a
subproperty of rdfs:label, be translated to a topic name; in
other words, the following built-in guidance should be assumed:
rdfs:label rdf:type rdftm:NameProperty .
and, given ( X rdfs:subPropertyOf rdfs:label ):
X rdf:type rdftm:NameProperty .
Does the task force agree on this?
The rules for translating names are as follows:
A name maps to a single statement (examples and ).
The topic becomes the subject of the statement.
The name type becomes the predicate of the statement.
The value of the name becomes the object of the
statement.
The property is declared to be an instance of
rdftm:NameProperty.
In accordance with [TMDM], untyped names map
to statements whose property is tm:name-type.
[puccini = foaf:name : "Giacomo Puccini"]
▼
_puccini foaf:name "Giacomo Puccini" .
foaf:name rdf:type rdftm:NameProperty .
[puccini = "Giacomo Puccini"]
▼
_puccini tm:name-type "Giacomo Puccini" .
tm:name-type rdf:type rdftm:NameProperty .
_puccini foaf:name "Giacomo Puccini" .
foaf:name rdf:type rdftm:NameProperty .
▼
[puccini = foaf:name : "Giacomo Puccini"]
_puccini rdfs:label "Giacomo Puccini" .
▼
[puccini = rdfs:label : "Giacomo Puccini"]
_puccini foaf:name "Giacomo Puccini" .
foaf:name rdfs:subPropertyOf rdfs:label .
▼
[puccini = foaf:name : "Giacomo Puccini"]
The following classes and properties are involved in the guidance for
names:
rdf:type
rdftm:NameProperty
Variants
In Topic Maps, a name can have variants. A variant is an
alternate form of the name that is intended to be used in a specific
processing context, which itself is specified as a scope. No
equivalent construct exists in RDF. To represent a variant in RDF, the
statement that asserts the name (as described in the preceding section)
should be reified and then given the properties rdftm:variant
and rdftm:variant-scope. (See Section 3.9 for a more general
discussion of scope.)
I have changed the second property from
rdftm:scope to rdftm:variant-scope, because when a
scoped name has a variant we wouldn't know (in RDF2TM) where to put the
properties (on the name or on the variant). Thus we need a separate
rdftm:variant-scope property in order to be able to distinguish
the two. See the example in Section 3.9, where the
reified name has both scope and variant-scope
properties.
The rules for translating variants are as follows:
When a name has a variant, the name is map to a statement as
described above in section 3.4, and the statement is reified (example
).
The variant name becomes the value of an rdftm:variant
property on the statement.
Each topic in the scope of the variant name becomes the value of
a rdftm:variant-scope property on the statement.
[puccini = foaf:name : "Giacomo Puccini" ; "puccini, giacomo"]
- which is equivalent to -
[puccini = foaf:name : "Giacomo Puccini"
("puccini, giacomo" / tm:sort)]
▼
[ rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate foaf:name ;
rdf:object "Giacomo Puccini" ;
rdftm:variant "puccini, giacomo" ;
rdftm:variant-scope tm:sort
] .
foaf:name rdf:type rdftm:NameProperty .
Each block of statements consisting of a reified statement that
has an rdftm:variant property and one or more
rdftm:scope properties, and whose predicate is an instance of
rdftm:NameProperty, is translated to a name with a
variant (example ).
[ rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate foaf:name ;
rdf:object "Giacomo Puccini" ;
rdftm:variant "puccini, giacomo" ;
rdftm:variant-scope tm:sort
] .
foaf:name rdf:type rdftm:NameProperty .
▼
[puccini = foaf:name : "Giacomo Puccini" ; "puccini, giacomo"]
The following classes and properties are involved in the guidance for
variants:
rdftm:NameProperty
rdftm:variant
rdftm:variant-scope
Occurrences
An occurrence is a binary relationship between a subject and
an information resource. Occurrences can be internal or
external. The value of an external occurrence is a URI; the value
of an internal occurrence is a string whose datatype can be anything
except a URI. An occurrence thus maps to a single statement whose
predicate is the same as the occurrence type and whose value is either a
URIref, or a literal with an optional datatype. (Datatypes are covered
in Section 3.7.)
In order to preserve the information that the statement has the
semantics of an occurrence, the property is declared to be an instance
of the class rdftm:OccurrenceProperty.
Untyped occurrences cannot be translated since there is no URIref
available to create a property.
The rules for translating occurrences are as follows:
An occurrence maps to a single statement (examples and ).
The topic becomes the subject of the statement.
The type becomes the predicate of the statement.
The value of the occurrence becomes the object of the
statement.
The property is declared to be an instance of
rdftm:OccurrenceProperty.
Untyped occurrences cannot be translated.
{puccini, bio:dateOfBirth, [[1858-12-22]]}
▼
_puccini bio:dateOfBirth "1858-12-22" .
bio:dateOfBirth rdf:type rdftm:OccurrenceProperty .
{tosca, ex:synopsis, "http://www.metopera.org/synopses/tosca.html"}
▼
_tosca ex:synopsis <http://www.metopera.org/synopses/tosca.html> .
ex:synopsis rdf:type rdftm:OccurrenceProperty .
_puccini bio:dateOfBirth "1858-12-22" .
bio:dateOfBirth rdf:type rdftm:OccurrenceProperty .
▼
{puccini, bio:dateOfBirth, [[1858-12-22]]}
_tosca ex:synopsis <http://www.metopera.org/synopses/tosca.html> .
ex:synopsis rdf:type rdftm:OccurrenceProperty .
▼
{tosca, ex:synopsis, "http://www.metopera.org/synopses/tosca.html"}
The following classes and properties are involved in the guidance for
occurrences:
rdf:type
rdftm:OccurrenceProperty
Associations
Relationships between things are represented by associations in Topic
Maps and by statements in RDF. However, there are three fundamental
differences between associations and RDF statements:
An RDF statement always represents a binary relationship between
two things
(called the subject and the object); an
association, on the other hand, can represent a relationship between an
arbitrary number of participants (or role players), which are
always represented by topics.
The subject of an RDF statement is always a resource, but the
object may be either a resource or a literal. The TM equivalent of
literals (strings) cannot be role players in associations, however; an
RDF statement whose object is a literal must therefore be translated to
an (internal) occurrence or a name.
RDF statements represent directed relations, whereas
associations are inherently multidirectional. This has two major
consequences: firstly, a single relationship is often represented by
two RDF statements (one for each direction), whose properties are
the inverse of each other; and secondly, associations require additional
information (called role types) in order to express the nature of
each role player's participation in the relationship.
Translations between RDF and Topic Maps must take these fundamental
differences into account. The following sections explain the guidelines
for doing so by focusing in turn on binary associations, n-ary
associations (here defined as associations that involve three or more
role players), and unary associations (which involve just one role
player).
Binary associations
A binary association, such as the born in
relationship between
Puccini and Lucca, actually consists of five pieces of information: the
type of the association, the two role players, and the two corresponding
role types. The following example states that Puccini was born in
Lucca:
bio:born-in( puccini : foaf:Person, lucca : geo:place )
The topics 'person' and 'place' specify the types of the roles played
by Puccini and Lucca, respectively. They tell us that Puccini was born
in Lucca, and not vice versa, and are therefore vital pieces of
information. The most natural way to express this relationship in RDF is
as follows:
_puccini bio:born-in _lucca .
— that is, as a single statement whose property is
bio:born-in. In order to do this correctly, the translator
requires some additional information, viz: which of the role players
(the person or the place) should become the subject and
object of the resulting statement?
In order to provide this information, these Guidelines define the
properties rdftm:subject-role and rdftm:object-role,
whose domain is rdf:Property. They are used as follows to
express the guidance for the example above:
bio:born-in rdftm:subject-role foaf:Person .
bio:born-in rdftm:object-role geo:place . /* optional */
In TM2RDF, the rdftm:object-role property is optional, since
the translator can infer the object when the subject is known. However,
in RDF2TM, the rdftm:object-role property is required in order
to specify the identity of the second role type. In order to achieve
roundtripping, TM2RDF translators must generate this property if it is
not already specified.
The following kinds of binary association require special
treatment:
- Multiple signatures:
The Topic Maps standard does not prevent association types from
having multiple signatures, i.e., different combinations of role types,
such as in the following example:
* written-by( tosca1 : opera, puccini : composer )
written-by( tosca2 : play, sardou : playwright )
In order to keep these Guidelines as simple as possible and to
encourage best practice, no support is provided for such associations
(except in the case of n-ary associations with optional roles, as
discussed in Section 3.6.2).
Or should we allow association types to have multiple
rdftm:subject-role properties?
- Symmetric associations
In some associations (e.g., foaf:knows), both role
players have the same role type. In such cases, the choice of subject
and object will be arbitrary, and the translation will not be
deterministic.
- Type-instance and supertype-subtype
These two relationship types have special significance in RDF and
Topic Maps and therefore have built-in guidance. They are discussed in
Sections 3.6.1.1 and 3.6.1.2, respectively.
- Inverse relationships
A binary relationship that is represented by a single association
may be represented by two RDF statements whose properties are the
inverse of each other. A natural RDF2TM translation requires two such
properties to result in a single association. These guidelines therefore
recommend that the rdftm role properties only be assigned to
one of the two inverse properties and that RDF2TM translators use
the owl:inverseOf property to avoid creating duplicate
associations. TM2RDF translators should use the owl:inverseOf
property, when present, to create pairs of RDF statements that are the
inverse of each other.
- Untyped associations
Untyped associations cannot be translated since there is no
URIref available to create a property.
The rules for translating binary associations are as follows:
A binary association becomes an RDF statement (example ).
The topic playing the role whose type is the value of the
association type's rdftm:subject-role property becomes the
subject of the statement. The other topic becomes the object of the
statement.
The association type becomes the predicate of the
statement.
In the case of symmetric associations, where both role players
play the same role, the choice of subject and object is arbitrary
(example ).
If the association type has an owl:inverseOf property, a
second RDF statement should be created with the subject and object
reversed (example ).
Untyped associations cannot be translated.
bio:born-in( puccini : foaf:Person, lucca : geo:place )
{ bio:born-in, rdftm:subject-role, foaf:Person }
{ bio:born-in, rdftm:object-role , geo:place } /* optional */
▼
_puccini bio:born-in _lucca .
foaf:knows( pepper : foaf:Person, presutti : foaf:Person )
{ foaf:knows, rdftm:subject-role, foaf:Person }
{ foaf:knows, rdftm:object-role , foaf:Person } /* optional */
▼
_pepper foaf:knows _presutti .
- or -
_presutti foaf:knows _pepper .
music:composer( tosca : music:Oeuvre, puccini : music:Composer )
{ music:composer, owl:inverseOf, music:composed }
{ music:composer, rdftm:subject-role, music:Oeuvre }
▼
_tosca music:composer _puccini .
_puccini music:composed _tosca .
An RDF statement whose predicate has the properties
rdftm:subject-role and rdftm:object-role
becomes a binary association.
The role of the topic that was the subject of the statement is
set to the value of the rdftm:subject-role property. The role
of the topic that was the object of the statement is set to the value of
the rdftm:object-role property (examples and ).
Inverse statements do not result in a separate, duplicate
association (example ).
_puccini bio:born-in _lucca .
bio:born-in rdftm:subject-role foaf:Person .
bio:born-in rdftm:object-role geo:place . /* required */
▼
bio:born-in( _puccini : foaf:Person, _lucca : geo:place )
onto:pepper foaf:knows unibo:presutti .
foaf:knows rdftm:subject-role foaf:Person .
foaf:knows rdftm:object-role foaf:Person . /* required */
▼
foaf:knows( onto:pepper : foaf:Person, unibo:presutti : foaf:Person )
_tosca music:composer _puccini .
_puccini music:composed _tosca .
music:composer owl:inverseOf music:composed .
music:composer rdftm:subject-role music:Oeuvre .
music:composer rdftm:object-role music:Composer . /* required */
▼
music:composer( tosca : music:Oeuvre, puccini : music:Composer )
The following classes and properties are involved in the guidance for
binary associations:
Type-instance relationships
RDF has a predefined property called rdf:type which relates
an instance to a class. This corresponds to the predefined association
type tm:type-instance in Topic Maps (with its corresonding role
types tm:instance and tm:type).
These Guidelines recommend that tm:type-instance be
translated to rdf:type, and vice versa, and that the following
built-in guidance be assumed:
tm:type-instance
owl:sameAs rdf:type ;
rdftm:subject-role tm:instance ;
rdftm:object-role tm:type .
The rules for translating type-instance associations are as
follows:
Do we want to allow the assumed equivalence to be
overruled?
In the absence of explicit guidance to the contrary, an association
of the form
tm:type-instance( a : tm:instance, b : tm:type )
becomes an RDF statement of the form
_a rdf:type _b .
(Example ).
[puccini : music:Composer]
- which is equivalent to -
tm:type-instance( puccini : tm:instance, music:Composer : tm:type )
▼
_puccini rdf:type music:Composer .
Do we want to allow the assumed equivalence to be
overruled?
In the absence of explicit guidance to the contrary, an RDF statement
of the form
_a rdf:type _b .
becomes an association of the form
tm:type-instance( a : tm:instance, b : tm:type )
(Example ).
_puccini rdf:type music:Composer .
▼
[puccini : music:Composer]
- which is equivalent to -
tm:type-instance( puccini : tm:instance, music:Composer : tm:type )
Supertype-subtype relationships
RDF Schema has a predefined property called rdfs:subClassOf
which relates a class to its superclass. This corresponds to the
predefined association type tm:supertype-subtype in Topic Maps
(with its corresponding role types tm:supertype and
tm:subtype).
These Guidelines recommend that tm:supertype-subtype be
translated to rdfs:subClassOf and vice versa, and that the
following built-in guidance be assumed:
tm:supertype-subtype
owl:sameAs rdfs:subClassOf ;
rdftm:subject-role tm:supertype ;
rdftm:object-role tm:subtype .
The rules for translating supertype-subtype relationships are as
follows:
Do we want to allow the assumed equivalence to be
overruled?
In the absence of explicit guidance to the contrary, an association
of the form
tm:supertype-subtype( a : tm:subtype, b : tm:supertype )
becomes an RDF statement of the form
a rdfs:subClassOf b .
(Example ).
tm:supertype-subtype( music:Composer : tm:subtype, foaf:Person : tm:supertype )
▼
music:Composer rdfs:subClassOf foaf:Person .
Do we want to allow the assumed equivalence to be
overruled?
In the absence of explicit guidance to the contrary, an an RDF
statement of the form
a rdfs:subClassOf b .
becomes association of the form
tm:supertype-subtype( a : tm:subtype, b : tm:supertype )
(Example ).
music:Composer rdfs:subClassOf foaf:Person .
▼
tm:supertype-subtype( music:Composer : tm:subtype, foaf:Person : tm:supertype )
N-ary relationships
Binary associations are relatively easy to map to RDF, but, as noted
above, Topic Maps allows associations of any arity, whereas, in RDF, all
relationships are inherently binary. Work has recently been undertaken
by the SWBPD's Ontology Engineering Patterns task force [Noy et al] to define patterns for describing n-ary
relations in RDF. In order to ensure maximum interoperability, these
Guidelines build on that work and support the same patterns.
[Noy et al] identify two basic representation
patterns for n-ary relationships: Pattern 1, which they term
Introducing a new class for a relation, and Pattern 2,
Using lists for arguments in a relation. Of these, only Pattern
1 corresponds to the Topic Maps notion of n-ary relationships. Pattern
2, representing a list or sequence of arguments
, is most
naturally represented in Topic Maps using multiple, chained
associations.
[Noy et al] provide three use cases for Pattern 1.
All of them involve defining a class to represent the property, and a
resource that is an instance of that class to represent the
relationship. Each argument of the relation
(i.e., role player in
the relationship) is then linked to the resource that represents the
relationship using a single RDF statement. However, there are two subtly
different structures that can be employed:
In the first two use cases, one of the role players is the
subject of the statement connecting it to the relationship,
while the others are objects of their respective
statements.
In the third use case, every role player is the object
of the statement connecting it to the relationship.
In the first two use cases, one of the role players is regarded as
standing out
in some way and playing a more central role as the
subject of the relationship (pattern 1A). In the third use case, all
role players are regarded as being equally important; none of them can
be regarded as being the subject
of the relationship (pattern
1B).
In order to represent Pattern 1, these Guidelines define the class
rdftm:N-aryProperty. The property rdftm:subject-role
is used to distinguish between Patterns 1A and 1B.
The rules for translating n-ary associations are as follows:
An n-ary association maps to n RDF statements,
one for each role player.
Each statement connects one of the role players to a resource
which corresponds to the association type, by a property which
corresponds to the role type.
If the role type is the value of an rdftm:subject-role
property whose subject is the association type, the corresponding role
player becomes the subject of the statement (example ); otherwise it becomes the object of the statement
(example ).
A guidance statement is created stating that the association type
is an instance of rdftm:N-aryProperty
bio:killed-by( scarpia : bio:victim, floria-tosca : bio:perpetrator, stabbing : bio:method )
{ bio:killed-by, rdftm:subject-role, bio:victim }
▼
_scarpia bio:victim _killed-by00n .
_killed-by00n
rdf:type bio:killed-by ;
bio:perpetrator _floria-tosca ;
bio:method _stabbing .
bio:killed-by rdf:type rdftm:N-aryProperty .
bio:killed-by( scarpia : bio:victim, floria-tosca : bio:perpetrator, stabbing : bio:method )
▼
_killed-by00n
rdf:type bio:killed-by ;
bio:victim _scarpia ;
bio:perpetrator _floria-tosca ;
bio:method _stabbing .
bio:killed-by rdf:type rdftm:N-aryProperty .
A resource belonging to a class of type
rdftm:N-aryProperty becomes the type of an n-ary association
(example ).
Each resource that is linked to it becomes a role player in the
association.
The property becomes the role type.
If one of the participants in the relation is the subject of a
statement whose object is the relation, an rdftm:subject-role
statement is created in order to enable roundtripping (example ).
_killed-by00n
rdf:type bio:killed-by ;
bio:victim _scarpia ;
bio:perpetrator _floria-tosca ;
bio:method _stabbing .
bio:killed-by rdf:type rdftm:N-aryProperty .
▼
bio:killed-by( scarpia : bio:victim, floria-tosca : bio:perpetrator, stabbing : bio:method )
_scarpia bio:victim _killed-by00n .
_killed-by00n
rdf:type bio:killed-by ;
bio:perpetrator _floria-tosca ;
bio:method _stabbing .
bio:killed-by rdf:type rdftm:N-aryProperty .
▼
bio:killed-by( scarpia : bio:victim, floria-tosca : bio:perpetrator, stabbing : bio:method )
{ bio:killed-by, rdftm:subject-role, bio:victim }
The following classes and properties are involved in the guidance for
n-ary associations:
rdf:type
rdftm:N-aryProperty
rdftm:subject-role
Unary relationships
A unary association is a special case of the n-ary associations
described above, differing only in that the subject role can be assumed
to be played by the (only) role-player. Pattern 1A should therefore
always be chosen in TM2RDF, even if there is no explicit guidance in the
form of an rdftm:subject-role statement.
The rules for translating unary associations are as follows:
A unary association maps to a single RDF statement
(example ).
The role player becomes the subject of the
statement.
The type becomes the object of the statement.
The role type becomes the property of the statement.
A guidance statement is created stating that the association type
is an instance of rdftm:N-aryProperty
music:unfinished( turandot : work )
▼
_turandot music:unfinished _unfinished00n .
music:unfinished rdf:type rdftm:N-aryProperty .
A resource belonging to a class of type
rdftm:N-aryProperty that this the object of just one relation
becomes the type of a unary association (example ).
The subject of the statement becomes the role player in the
association.
The property becomes the role type.
_turandot music:unfinished _unfinished00n .
music:unfinished rdf:type rdftm:N-aryProperty .
▼
music:unfinished( turandot : work )
The following classes and properties are involved in the guidance for
unary associations:
rdf:type
rdftm:N-aryProperty
rdftm:subject-role
Datatypes
Both RDF and Topic Maps allow the specification of datatypes on
literals or strings. In RDF, this facility applies to any plain literal;
in Topic Maps, it applies to the values of variants and occurrences.
Both paradigms require the datatype to be specified using a URI, which,
in RDF, must come from [XML Schema]. Topic
Maps has three built-in datatypes (string, IRI, and XML), all of which
are defined in [XML Schema].
These features are essentially compatible, except for the
following:
The base name of a topic must always be a string; only variants
can have other datatypes. Thus there is a potential conflict when an RDF
statement, whose value has a datatype other than string, has guidance
that says it should be mapped to a topic name.
How do we handle this?
The value of a variant or occurrence may have a datatype that is
not covered by [XML Schema].
How do we handle this?
Other than these two edge cases, datatypes present no problems when
translating RDF2TM or TM2RDF.
The rules for translating datatypes are as follows:
{ puccini, bio:dateOfBirth, [[1858-12-22]]^xsd:date }
▼
_puccini bio:dateOfBirth "1858-12-22"^^xsd:date .
bio:dateOfBirth rdf:type rdftm:OccurrenceProperty .
_puccini bio:dateOfBirth "1858-12-22"^^xsd:date .
bio:dateOfBirth rdf:type rdftm:OccurrenceProperty .
▼
{ puccini, bio:dateOfBirth, [[1858-12-22]]^xsd:date }
Reification
RDF provides a facility called reification which allow
statements to be made about statements. Topic Maps also provides a
facility called reification which allows names, associations,
occurrences, roles, and topic maps to be regarded as topics in order for
statements to be made about them. These two facilities are basically
equivalent, except for two things:
There is no direct equivalent of the topic map itself in RDF. The
closest equivalent is the set of statements contained in a single RDF
document, but this is not quite the same.
In RDF, there is nothing that corresponds to association
roles.
As a consequence, a reified name, occurrence, or association can be
mapped to a reified RDF statement; a reified topic map or association
role cannot be mapped; and a reified RDF statement can be mapped to a
reified name, occurrence, or association. (In the case of n-ary
associations and names with variants, reification is already indicated,
so no additional reification is necessary.)
Actually n-ary associations (and unary associations) pose
a problem. In a sense they are already reified, since the translation
rules require a resource to be created to represent the relationship.
However, it is not possible to make (additional) statements about the
relationship, because an RDF2TM translator would not know how to
distinguish such statements from statements that represent roles. One
way to achieve this would be to make every role type (which becomes a
property in TM2RDF) into an instance of the class
rdftm:RoleProperty, but this adds quite an overhead to the
machinery. Is it worth it?
A reified name, occurrence or association is mapped according to
the rules defined in Sections 3.4–3.6, except that the resulting
RDF statement is reified (examples , and ).
[puccini = rdfs:label : "Giacomo Puccini" ~puccini-name]
▼
_puccini-name
rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate rdfs:label ;
rdf:object "Giacomo Puccini" .
{puccini, bio:dateOfBirth, [[1858-12-22]]} ~puccini-birthdate
▼
_puccini-birthdate
rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate bio:dateOfBirth ;
rdf:object "1858-12-22" .
bio:born-in( puccini : foaf:Person, lucca : geo:place ) ~puccini-birthplace
{ bio:born-in, rdftm:subject-role, foaf:Person }
{ bio:born-in, rdftm:object-role , foaf:Place }
▼
_puccini-birthplace
rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate bio:born-in ;
rdf:object _lucca .
A reified RDF statement is mapped to a name, occurrence or
association, as defined in Sections 3.4–3-6, except that the
resulting statement is reified. (For examples, simply invert the
immediately preceding examples.)
The following classes and properties are involved in the guidance for
reification:
Scope
Topic Maps defines the concept of scope as the context
within which a statement is valid.
A scope is composed of a set of
topics that together define that context. RDF has no equivalent concept,
nor does it define any vocabulary for the representation of context.
Scope is essentially a way to annotate a name, occurrence, or
association for the specific purpose of expressing its contextual
validity; in other words, it is a special case of making a statement
about a statement. Since the latter involves reification in both RDF and
Topic Maps, these Guidelines define a property rdftm:scope that
is to be used with reified statements in order to allow scope to be
expressed in RDF.
The rules for translating scope are as follows:
A scoped name, occurrence, or association is translated as
described in Sections 3.4–3.6, and the resulting statement is
reified (examples , ,
and ).
For each topic comprising the scope, one rdftm:scope
property, whose value is the resource corresponding to the topic in
question, is assigned to the reified statement.
If the scope is defined by a single topic that represents a
natural language, the rules for translating language tags should be used
instead (see Section 3.9.1).
Make special mention of situations where reification
is unnecessary or already performed (i.e., n-aries, names with variants,
more...)?
[puccini = foaf:name : "Giacomo Puccini" / foo bar]
▼
[ rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate foaf:name ;
rdf:object "Giacomo Puccini" ;
rdftm:scope _foo , _bar
] .
foaf:name rdf:type rdftm:NameProperty .
{tosca, music:synopsis, "http://www.metopera.org/synopses/tosca.html"}
/ opera:metopera
▼
[ rdf:type rdf:Statement ;
rdf:subject _tosca ;
rdf:predicate music:synopsis ;
rdf:object "http://www.metopera.org/synopses/tosca.html" ;
rdftm:scope opera:metopera
] .
music:synopsis rdf:type rdftm:OccurrenceProperty .
music:influenced-by( butterfly : ex:object, iris : ex:agent ) / carner
{ music:influenced-by, rdftm:subject-role, ex:object }
{ music:influenced-by, rdftm:object-role , ex:agent }
▼
[ rdf:type rdf:Statement ;
rdf:subject _butterfly ;
rdf:predicate music:influenced-by ;
rdf:object _iris ;
rdftm:scope _carner
] .
[boito = foaf:name : "Tobia Gorrio" / ex:nom-de-plume
("puccini, giacomo" / tm:sort)]
▼
[ rdf:type rdf:Statement ;
rdf:subject _puccini ;
rdf:predicate foaf:name ;
rdf:object "Giacomo Puccini" ;
rdftm:variant "puccini, giacomo" ;
rdftm:variant-scope tm:sort ;
rdftm:scope ex:nom-de-plume
] .
foaf:name rdf:type rdftm:NameProperty .
An RDF statement that has one or more
rdftm:scope properties is translated in accordance with the
rules in Sections 3.4–3.6 and the resulting name, occurrence, or
association is given a scope consisting of the topics that are the
objects of the rdftm:scope properties. (For examples, simply
invert the immediately preceding examples.)
The following classes and properties are involved in the guidance for
scope:
Language tags
RDF has a special mechanism (called language tags) for
specifying the natural language of a plain literal. The most natural way
to represent the same thing in Topic Maps is to use scope. These
Guidelines therefore recommend the following exception to the general
rule for handling scope:
A name or internal occurrence that is scoped by a single topic
that represents a natural language translates to an RDF statement with a
corresponding language tag (example ).
How do we know when it is a language?
[la-fanciulla = dc:title : "La Fanciulla del West"
= dc:title : "The Girl of the Golden West" / lang:en]
▼
_la-fanciulla
dc:title "La Fanciulla del West" ,
"The Girl of the Golden West"@en .
dc:title rdf:type rdftm:NameProperty .
An RDF plain literal with a language tag becomes the object of a
scoped name or occurrence, according to the rules defined in Sections
3.4–3.6. The scope is defined by a single topic representing the
corresponding language (examples and ).
What is the identity of that topic?
_la-fanciulla dc:title "The Girl of the Golden West"@en .
dc:title rdf:type rdftm:NameProperty .
▼
[la-fanciulla = dc:title : "The Girl of the Golden West" / lang:en]
_la-fancilla dc:description
"En opera av Puccini hvor handlingen finner sted i Amerika."@no .
dc:description rdf:type rdftm:OccurrenceProperty .
▼
{la-fanciulla, dc:description,
[[En opera av Puccini hvor handlingen finner sted i Amerika.]]
} / lang:no
RDF statements
[TBD -- This will be a collation of the rules contained in the RDF2TM
parts of Sections 3.4–3.6, which are mostly presented from the
TM2RDF perspective. This section allows the RDF2TM perspective to be
emphasised.]
What happens if there is no guidance for a particular
property? Is it assumed to be an occurrence?