3. Guidance rules
This section provides a complete overview of how constructs in the
two paradigms relate to each other.
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.
3.1 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 internally in computer systems by symbols,
proxies. In Topic Maps, those proxies are called
topics; in RDF they tend to be called resources, like
the things they represent. A more precise term for the proxy in RDF is
RDF node
, except that the latter includes both nodes with
identity (denoted by URIrefs), 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.
The close semantic equivalence between topics and resources indicates
that these should be mapped to each other when translating TM2RDF or
RDF2TM. More precisely:
In TM2RDF:
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 subject or property) 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.
3.2 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 always 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.
3.3 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 property:
One resource is created for each subject identifier with the
subject identifier becoming the URIref that denotes the resource. The
resources are related to each other through owl:sameAs
properties (example ).
A topic without a subject identifier cannot give rise to a
property.
More generally, 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 resource is created for each subject identifier with the
subject identifier becoming the URIref that denotes the resource. The
resources are related to each other through owl:sameAs
properties (examples and
).
Topics with neither subject identifier nor subject locator become
blank nodes (example ).
Item identifiers are discarded.
In the examples below, [...] stands for statements about the
subject that must necessarily exist unless the resource is a
property.
[composed-by
@"http://psi.ontopia.net/music/#composed-by"
@"http://www.kanzaki.com/ns/music#composer"]
▼
<http://www.kanzaki.com/ns/music#composer>
owl:sameAs <http://psi.ontopia.net/music/#composed-by> ;
[...] .
[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 a property, the URIref becomes a subject
identifier; any owl:sameAs properties and the values of
properties that are subproperties of rdftm:subjectIdentifier
become additional subject identifiers.
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 ).
<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:
3.4 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 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 using
rdfs:label as the primary mechanism for providing guidance.
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 .
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
rdfs:label
rdfs:subPropertyOf
rdftm:NameProperty
3.4.1 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.)
The rules for translating variants are as follows:
When a name has a variant, the name is mapped to a statement as
described above in section 3.4, and the statement is reified (example
). If the name has multiple variants, one
reified statement is created for each variant (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 .
[tchaikovsky = foaf:name : "Tchaikovsky"
("Tschaikowski" / skos:altname)
("Tchaïkovski" / skos:altname) ]
▼
[ rdf:type rdf:Statement ;
rdf:subject _tchaikovsky ;
rdf:predicate foaf:name ;
rdf:object "Tchaikovsky" ;
rdftm:variant "Tschaikowski" ;
rdftm:variant-scope skos:altname ]
.
[ rdf:type rdf:Statement ;
rdf:subject _tchaikovsky ;
rdf:predicate foaf:name ;
rdf:object "Tchaikovsky" ;
rdftm:variant "Tchaïkovski" ;
rdftm:variant-scope skos:altname ]
.
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
3.5 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
3.6 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).
3.6.1 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).
- 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:
3.6.1.1 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:
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 .
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 )
3.6.1.2 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:subtype ;
rdftm:object-role tm:supertype .
The rules for translating supertype-subtype relationships are as
follows:
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 .
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 )
3.6.2 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 and 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
A guidance statement is created for each role type stating that
the role type is an instance of rdftm:RoleProperty
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:victim rdf:type rdftm:RoleProperty .
bio:perpetrator rdf:type rdftm:RoleProperty .
bio:method rdf:type rdftm:RoleProperty .
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 .
bio:victim rdf:type rdftm:RoleProperty .
bio:perpetrator rdf:type rdftm:RoleProperty .
bio:method rdf:type rdftm:RoleProperty .
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 through a property whose type
is rdftm:RoleProperty becomes a role player in the
association.
The property becomes the role type.
If one of the role players is the subject of its property (rather
than the object), 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:victim rdf:type rdftm:RoleProperty .
bio:perpetrator rdf:type rdftm:RoleProperty .
bio:method rdf:type rdftm:RoleProperty .
▼
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:victim rdf:type rdftm:RoleProperty .
bio:perpetrator rdf:type rdftm:RoleProperty .
bio:method rdf:type rdftm:RoleProperty .
▼
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:RoleProperty
rdftm:subject-role
3.6.3 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 : music:work )
▼
_turandot music:work _unfinished00n .
_unfinished00n rdf:type music:unfinished .
music:unfinished rdf:type rdftm:N-aryProperty .
music:work rdf:type rdftm:RoleProperty .
A resource belonging to a class of type
rdftm:N-aryProperty that is linked to exactly one resource
through a property whose type is rdftm:RoleProperty becomes the
type of a unary association (example ).
The resource that is linked to it through a property whose type
is rdftm:RoleProperty becomes the role player in the
association.
The property becomes the role type.
_turandot music:work _unfinished00n .
_unfinished00n rdf:type music:unfinished .
music:unfinished rdf:type rdftm:N-aryProperty .
music:work rdf:type rdftm:RoleProperty .
▼
music:unfinished( turandot : work )
The following classes and properties are involved in the guidance for
unary associations:
rdf:type
rdftm:N-aryProperty
rdftm:RoleProperty
rdftm:subject-role
3.7 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.
These features are essentially compatible, except for the potential
for 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. Since
the base name of a topic can only be a string, this guidance cannot be
followed and the conflict should be reported as an error.
Other than this edge case, 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 }
3.8 Reification
RDF provides a facility called reification which allows
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, most reified names, occurrences, and associations
can be mapped to reified RDF statements. Reified names with variants and
reified non-binary associations require no special treatment since the
translation of such constructs to RDF in any case requires the creation
of a resource to represent the relationship. Reified topic maps and
association roles cannot be mapped to RDF. A reified RDF statement can
be mapped to a reified name, occurrence, or association.
A reified name with no variants, a reified occurrence, or a
reified binary association is mapped according to the rules defined in
Sections 3.4, 3.5, and 3.6.1, respectively, and 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.5, and 3.6.1, respectively,
except that the resulting statement is reified. (For examples, simply
invert the examples in the preceding section.)
The following classes and properties are involved in the guidance for
reification:
3.9 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 that has no variants, a scoped occurrence, or a
scoped binary association is translated as described in Sections 3.4,
3.5, and 3.6.1, respectively, and the resulting statement is reified
(examples , ,
and ).
A scoped name that has one or more variants or a scoped
non-binary association is translated as described in Sections 3.4,
3.6.2, and 3.6.3, respectively. (Reification is not necessary since the
relationship is represented as a resource by default.)
For each topic comprising the scope, one rdftm:scope
property is assigned to the resource that represents the relationship,
and its value is set to the resource corresponding to the topic in
question.
If the scope is defined by a single topic that represents a
natural language, the rules for translating language tags should be
applied instead (see Section 3.9.1).
[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 .
A resource that has a set of properties corresponding to a
reified statement, a name with variants, or a non-binary association,
and has one or more rdftm:scope properties is translated in
accordance with the rules in Sections 3.4, 3.5 and 3.6. 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
examples in the preceding section.)
The following classes and properties are involved in the guidance for
scope:
3.9.1 Language tags
RDF has a special mechanism (called language tags) for
specifying the natural language of a plain literal. This mechanism is
based on the xml:lang attribute whose values are defined by
[RFC 3066]. 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 is an instance of the class rdftm:Language translates to
an RDF statement with a corresponding language tag (example ).
The corresponding language tag
is the name of the subject
identifier (of the language topic), which must be in the namespace
http://www.w3.org/2006/rdftm/rfc3066/. This document defines a
set of published subjects for all possible lower-case forms of RFC 3066
language tags. (Note: RFC 3066 language tags are themselves case
insensitive, so RDF2TM processors must convert to lower case.)
#PREFIX lang @"http://www.w3.org/2006/rdftm/rfc3066/"
[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 ).
The identity of the language topic is found by concatenating the
string http://www.w3.org/2006/rdftm/rfc3066/ with the
lower-cased form of the language tag. The resulting URI is used as the
subject identifier of the topic.
_la-fanciulla dc:title "The Girl of the Golden West"@en-US .
dc:title rdf:type rdftm:NameProperty .
▼
#PREFIX lang @"http://www.w3.org/2006/rdftm/rfc3066/"
[la-fanciulla = dc:title : "The Girl of the Golden West" / lang:en-us]
_la-fancilla dc:description
"En opera av Puccini hvor handlingen finner sted i Amerika."@no .
dc:description rdf:type rdftm:OccurrenceProperty .
▼
#PREFIX lang @"http://www.w3.org/2006/rdftm/rfc3066/"
{la-fanciulla, dc:description,
[[En opera av Puccini hvor handlingen finner sted i Amerika.]]
} / lang:no
3.10 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. It will be written once Sections 3.4–3.6 have been
reviewed by the Working Group.]