NOTE-rdftm-survey-20060210 123 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>
  <title>A Survey of RDF/Topic Maps Interoperability Proposals</title>
  <link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" />
</head>

<body>

<!-- HEADER SECTION -->
<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a>

<h1 id="title">A Survey of RDF/Topic Maps Interoperability Proposals</h1>

<h2>W3C Working Group Note 10 February 2006</h2>

<dl>
<dt><b>This version:</b></dt>
<dd><a
href="http://www.w3.org/TR/2006/NOTE-rdftm-survey-20060210">http://www.w3.org/TR/2006/NOTE-rdftm-survey-20060210</a></dd>

<dt><b>Latest version:</b></dt>
<dd><a
href="http://www.w3.org/TR/rdftm-survey">http://www.w3.org/TR/rdftm-survey</a></dd>

<dt><b>Previous version:</b></dt>
<dd><a href="http://www.w3.org/TR/2005/WD-rdftm-survey-20050329"
>http://www.w3.org/TR/2005/WD-rdftm-survey-20050329</a></dd>

<dt><b>Editors:</b></dt>
<dd>Steve Pepper, Ontopia &lt;<a
href="mailto:pepper@ontopia.net">pepper@ontopia.net</a>&gt;<br/>
Fabio Vitali, University of Bologna &lt;<a
href="mailto:fabio@cs.unibo.it">fabio@cs.unibo.it</a>&gt;<br/>
Lars Marius Garshol, Ontopia &lt;<a
href="mailto:larsga@ontopia.net">larsga@ontopia.net</a>&gt;<br/>
Nicola Gessa, University of Bologna &lt;<a
href="mailto:gessa@cs.unibo.it">gessa@cs.unibo.it</a>&gt;<br/>
Valentina Presutti, University of Bologna &lt;<a
href="mailto:presutti@cs.unibo.it">presutti@cs.unibo.it</a>&gt;</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
&#xa9; 2006 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>&#xae;</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>

<hr/>
<!-- end of head -->

<!-- ABSTRACT SECTION -->
<div class="abstract">

<h2><a id="abstract" name="abstract"/>Abstract</h2>

<p>The Resource Description Framework (RDF) is a model developed by the
W3C for representing information about resources in the World Wide Web.
Topic Maps is a standard for knowledge integration developed by the ISO.
This document contains a survey of existing proposals for integrating
RDF and Topic Maps data and is intended to be a starting point for
establishing standard guidelines for RDF/Topic Maps
interoperability.</p>
</div>

<!-- STATUS SECTION -->
<div class="section">

<h2><a id="status" name="status"/>Status of this Document</h2>

<p><em>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 <a href="http://www.w3.org/TR/">W3C technical
reports index</a> at http://www.w3.org/TR/.</em></p>

<p>This document was created by the RDF/Topic Maps
Interoperability Task Force (RDFTM) of the W3C <a
href="http://www.w3.org/2001/sw/BestPractices/">Semantic
Web Best Practices and Deployment Working Group</a> (SWBPD) with the
support of the ISO Topic Maps committee (ISO/IEC JTC1/SC34).
This work is part of the <a href="http://www.w3.org/2001/sw/Activity">W3C
Semantic Web Activity</a>.</p>

<p>This document is a W3C Working Group Note and the SWBPD does not
currently plan to create further revisions.  This version has no changes
from the previous (Working Draft) version.
Comments are welcome and may be sent to <a
href="mailto:public-swbp-wg@w3.org">public-swbp-wg@w3.org</a>; please
include the text "comment" in the subject line.  All messages received
at this address are viewable in a <a
href="http://lists.w3.org/Archives/Public/public-swbp-wg/"
>public archive</a>.
The patent policy for this document is the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/"
>5 February 2004 W3C Patent Policy</a>.
As this is an informational document, <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure"
>W3C patent disclosure requirements</a> do not apply.
</p>

<p>
Publication as a Working Group Note does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.
</p>
</div>

<!-- CONTENTS SECTION -->
<div class="section">

<h2><a id="contents" name="contents"/>Table of Contents</h2>

<blockquote>
<p>
  1 <a href="#introduction">Introduction</a><br />
  &nbsp; &nbsp; 1.1 <a href="#background">Background</a><br />
  &nbsp; &nbsp; 1.2 <a href="#purpose">Purpose and target audience</a><br />
  &nbsp; &nbsp; 1.3 <a href="#overview">Overview of proposals</a><br />
  2 <a href="#criteria">Criteria for evaluating the proposals</a><br />
  &nbsp; &nbsp; 2.1 <a href="#translation_features">Translation features</a><br />
  &nbsp; &nbsp; 2.2 <a href="#test_cases">Test cases</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 2.2.1 <a href="#tm2rdf_test_case">TM2RDF test case</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 2.2.2 <a href="#rdf2tm_test_case">RDF2TM test case</a><br />
  3 <a href="#proposals">Existing translation proposals</a><br />
  &nbsp; &nbsp; 3.1 <a href="#moore">The Moore Proposal</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.1.1 <a href="#moore_description">Description</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.1.2 <a href="#moore_summary">Analysis</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.1.3 <a href="#moore_test_cases">Test cases</a><br />
  &nbsp; &nbsp; 3.2 <a href="#stanford">The Stanford Proposal</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.2.1 <a href="#stanford_description">Description</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.2.2 <a href="#stanford_summary">Analysis</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.2.3 <a href="#stanford_test_cases">Test cases</a><br />
  &nbsp; &nbsp; 3.3 <a href="#ogievetsky">The Ogievetsky Proposal</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.3.1 <a href="#ogievetsky_description">Description</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.3.2 <a href="#ogievetsky_summary">Analysis</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.3.3 <a href="#ogievetsky_test_cases">Test cases</a><br />
  &nbsp; &nbsp; 3.4 <a href="#garshol">The Garshol Proposal</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.4.1 <a href="#garshol_description">Description</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.4.2 <a href="#garshol_summary">Analysis</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.4.3 <a href="#garshol_test_cases">Test cases</a><br />
  &nbsp; &nbsp; 3.5 <a href="#unibo">The Unibo Proposal</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.5.1 <a href="#unibo_description">Description</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.5.2 <a href="#unibo_summary">Analysis</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 3.5.3 <a href="#unibo_test_cases">Test cases</a><br />
  &nbsp; &nbsp; 3.6 <a href="#other_proposals">Other Proposals and Contributions</a><br />
  4 <a href="#analysis">Analysis</a><br />
  &nbsp; &nbsp; 4.1 <a href="#object_mappings_and_semantic_mappings">Object mappings and semantic mappings</a><br />
  &nbsp; &nbsp; 4.2 <a href="#naturalness">The importance of naturalness</a><br />
  &nbsp; &nbsp; 4.3 <a href="#semantic_mapping_issues">Semantic mapping issues</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.1 <a href="#identity">Identity</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.2 <a href="#names">Names</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.3 <a href="#binary_relationships">Binary relationships</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.4 <a href="#non-binary_relationships">Non-binary relationships</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.5 <a href="#occurrences">Occurrences</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.6 <a href="#types_and_subtypes">Types and subtypes</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.7 <a href="#reification">Reification</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.8 <a href="#scope">Scope</a><br />
  &nbsp; &nbsp; &nbsp; &nbsp; 4.3.9 <a href="#other_issues">Other issues</a><br />
  5 <a href="#conclusion">Conclusion</a><br />
  <a href="#acknowledgements">Acknowledgements</a><br />
  <a href="#references">References</a>
</p>
</blockquote>
</div>

<!-- INTRODUCTION SECTION -->
<div class="section" >

<h2><a id="introduction" name="introduction"/>1 Introduction</h2>

<h3><a id="background" name="background"/>1.1 Background</h3>

<p>The Resource Description Framework (RDF) is a model developed by the
W3C for representing information about resources in the World Wide Web.
Topic Maps is a standard for knowledge integration developed by the ISO.
The two specifications were developed in parallel during the late 1990's
within their separate organizations for what at first appeared to be
very different purposes. The results, however, turned out to have a lot
in common and this has led to calls for their unification.</p>

<p>While unification has to date not been possible (for a variety of
technical and political reasons), a number of attempts have been made to
uncover the synergies between RDF and Topic Maps and to find ways of
achieving interoperability at the data level. There is now widespread
recognition within the respective user communities that achieving such
interoperability is a matter of some urgency. Work has therefore been
initiated by the Semantic Web Best Practices and Deployment Working
Group of the W3C with the support of the ISO Topic Maps committee to
address this issue. The goal of this work is to provide "guidelines for
users who want to combine usage of the W3C's RDF/OWL family of
specifications and the ISO's family of Topic Maps standards." Two
deliverables are expected to be produced:</p>

<ul>
<li>A Working Group Note containing a <i>Survey</i> of existing
approaches and an analysis of their strengths and weaknesses.</li>
<li>A Working Group Note or Recommendation describing <i>Guidelines</i>
for transforming a topic map into an RDF/OWL representation and vice
versa.</li>
</ul>

<h3><a id="purpose" name="purpose"/>1.2 Purpose and target audience</h3>

<p>This document is the first of those deliverables. It consists of a
summary and analysis of the major existing proposals for achieving data
interoperability between RDF and Topic Maps. Its purpose is to prepare
the ground for a new and definitive proposal based on a synthesis of
previous work.</p>

<p>The primary goal is to achieve interoperability between RDF and
Topic Maps at the <i>data</i> level. This means that it should be
possible to translate data from one form to the other without
unacceptable loss of information or corruption of the semantics. It
should also be possible to query the results of a translation in terms
of the target model and it should be possible to share vocabularies
across the two paradigms.</p>

<p><a href="#RDF-Schema">[RDF-Schema]</a> and <a href="#OWL">[OWL]</a>
are considered relevant to this work to the extent that the classes
and properties they define are supportive of its goals. However, it is
explicity <i>not</i> a goal of the current work to enable the general
use of RDF Schema and OWL with Topic Maps, although this issue may be
addressed later.</p>

<p>This document is aimed at readers with a particularly deep interest
in the problem of RDF/Topic Maps interoperability and a willingness to
acquire the necessary understanding of both paradigms. The reader is
consequently expected to have a level of familiarity with both RDF and
Topic Maps that at least corresponds to the tutorial material in <a
href="#Pepper00">[Pepper 00]</a> and <a
href="#RDF-Primer">[RDF-Primer]</a>. To fully understand this survey,
the reader must in addition be familiar with the models described in
<a href="#TMDM">[TMDM]</a> and <a
href="#RDF-Semantics">[RDF-Semantics]</a>, and the syntaxes described in
<a href="#LTM">[LTM]</a> and <a href="#N3">[N3]</a>.</p>

<h3><a id="overview" name="overview"/>1.3 Overview of proposals</h3>

<p>Five existing proposals are covered in this survey. They have been
chosen as being sufficiently complete and well-documented to be
suitable for detailed examination. They are also representative of the
breadth of approaches that have been taken to date and can all be
considered to be seminal in one way or another. They will be referred
to by the names of their authors or, in the case of multiple authors,
by the name of the organization to which the authors are affiliated.
Each proposal builds upon and references previous work and they are
characterized here in terms of the translation directions that they
cover: i.e., RDF to Topic Maps (RDF2TM), and Topic Maps to RDF
(TM2RDF), respectively. They are, in chronological order:</p>

<dl>
<dt><i>Moore</i></dt>
<dd><p>RDF2TM and TM2RDF proposal described in <a
href="#Moore01">[Moore 01]</a>. Not implemented.</p></dd>

<dt><i>Stanford</i></dt>
<dd><p>TM2RDF proposal described in <a href="#Lacher01">[Lacher 01]</a>.
Implemented.</p></dd>

<dt><i>Ogievetsky</i></dt>
<dd><p>TM2RDF proposal described in <a href="#Ogievetsky01b">[Ogievetsky
01b]</a>. Implemented in the <i>XTM2RDF Translator</i>.</p></dd>

<dt><i>Garshol</i></dt>
<dd><p>RDF2TM and TM2RDF proposal described in <a
href="#Garshol01">[Garshol 01]</a> and <a href="#Garshol03a">[Garshol
03a]</a>. Documented in <a href="#Garshol03b">[Garshol 03b]</a>, <a
href="#Ontopia03a">[Ontopia 03a]</a>, and <a href="#Ontopia03b">[Ontopia
03b]</a>, and implemented in <i>Ontopia Knowledge Suite</i>.</p></dd>

<dt><i>Unibo</i></dt>
<dd><p>RDF2TM and TM2RDF proposal described in <a
href="#Gentilucci02">[Gentilucci 02]</a> and <a
href="#Ciancarini03">[Ciancarini 03]</a>. Implemented in
<i>Meta</i>.</p></dd>
</dl>

<p>The following proposals will only be considered briefly since they
are insufficiently complete to warrant detailed examination:</p>

<ul>
<li><a href="#Prudhommeaux02">[Prudhommeaux 02]</a></li>
<li><a href="#Vlist01">[Vlist 01]</a></li>
</ul>

<p>The following contributions are also recognized as being
relevant:</p>

<ul>
<li><a href="#Garshol02">[Garshol 02]</a>: An RDF Schema for Topic
Maps.</li>
<li><a href="#Kaminsky02">[Kaminsky 02]</a>: A metamodel for XML, RDF,
and Topic Maps.</li>
<li><a href="#Pepper03">[Pepper 03]</a>: An in-depth discussion of the
issue of identifiers in RDF and Topic Maps.</li>
<li><a href="#Vatant04">[Vatant 04]</a>: An investigation into ways in
which OWL may be applied to Topic Maps.</li>
</ul>

<p>This survey describes the five main proposals in chronological
order. Each proposal is summarized and evaluated in terms of criteria
that are described in the next section. In addition, test cases are
applied against each proposal. It is important to note that all five
proposals were published before the respective communities had
formalized their data models (in <a href="#TMDM">[TMDM]</a> and <a
href="#RDF-Semantics">[RDF-Semantics]</a>, respectively). They were also
published before the advent of the <i>Web Ontology Language</i> (<a
href="#OWL">[OWL]</a>). This accounts in part for the immaturity of
some of the proposals; any quoted statements about the limitations of
either paradigm should also be viewed in this light.</p>

<hr/>
</div>

<div class="section" >

<h2><a id="criteria" name="criteria"/>2 Criteria for evaluating the proposals</h2>

<h3><a id="translation_features" name="translation_features"/>2.1 Translation features</h3>

<p>Each translation proposal is evaluated against the following general
criteria:</p>

<dl>
<dt><i>Completeness</i></dt>
<dd><p>The criterion <i>completeness</i> is used to evaluate the extent
to which each proposal is able to handle every semantic construct that
can be expressed in the source model and provide a means to represent it
without loss of information in the target model. A complete translation
will by definition be reversible.</p></dd>

<dt><i>Naturalness</i></dt>
<dd><p>The criterion <i>naturalness</i> expresses the degree to which
the results of a translation correspond to the way in which someone
familiar with the target paradigm would naturally express the
information content in that paradigm. Naturalness normally also
confers improved <i>readability</i> on the result. The importance of
naturalness is discussed in <a href="#naturalness">section
4.2</a>.</p></dd>
</dl>

<hr/>

<h3><a id="test_cases" name="test_cases"/>2.2 Test cases</h3>

<p>This survey uses two simple test cases to enable an initial
evaluation of the criterion "naturalness". These test cases are not
intended to be complete since their purpose is merely to give a feel
for the kind of results produced by the various proposals. A complete
suite of test cases is expected to be created along with the
Guidelines for RDF/Topic Maps interoperability that the SWBPD expects
to produce.</p>

<p>Test cases and the results of translations are given in LTM and
and N3 notation (for Topic Maps and RDF respectively) in order to aid
readability. There is one test case for translations from Topic Maps to
RDF (TM2RDF) and a second for translations from RDF to Topic Maps
(RDF2TM).</p>

<p>In order to aid understanding, the two test cases are basically
identical in terms of their information content, which is taken from
<a href="#Pepper05">[Pepper 05]</a>. They consist of the assertions
that the opera Tosca was premiered on 14th January 1900, has a
synopsis at a location with a certain URL, and was composed by the
composer Giacomo Puccini.</p>

<p>Both test cases are separated into instance data (above the dotted
line comment) and ontology or schema data that might normally be
expected to come from a shared document, such as a topic map ontology or
the RDF namespace document respectively.</p>

<h4><a id="tm2rdf_test_case" name="tm2rdf_test_case"/>2.3.1 TM2RDF test case</h4>

<pre>
[puccini : person   = "Giacomo Puccini"]
[tosca   : opera    = "Tosca"]

{tosca, premiere-date, [[1900-01-14]]}
{tosca, synopsis,      "http://www.azopera.com/learn/synopsis/tosca.shtml"}

composed-by( tosca : work, puccini : composer )

               /* ------------------------------------- */

[person        = "Person"        @"http://psi.ontopia.net/music/#person"]
[composer      = "Composer"      @"http://psi.ontopia.net/music/#composer"]
[opera         = "Opera"         @"http://psi.ontopia.net/music/#opera"]
[work          = "Work"          @"http://psi.ontopia.net/music/#work"]

[premiere-date = "Premi&#232;re date" @"http://psi.ontopia.net/music/#premiere-date"]
[synopsis      = "Synopsis"      @"http://psi.ontopia.net/music/#synopsis"]
[composed-by   = "Composed by"   @"http://psi.ontopia.net/music/#composed-by"]
</pre>

<h4><a id="rdf2tm_test_case" name="rdf2tm_test_case"/>2.3.2 RDF2TM test case</h4>

<pre>
@prefix music: &lt;http://psi.ontopia.net/music/#&gt; .
@prefix rdf:   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs:  &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .

[ rdf:type music:opera;
  rdfs:label "Tosca";
  music:premiere-date "1900-01-14";
  music:synopsis &lt;http://www.azopera.com/learn/synopsis/tosca.shtml&gt;;
  music:composed-by [
    rdf:type music:person;
    rdfs:label "Giacomo Puccini" ]
] .

               # ---------------------------------------

music:person        rdfs:label "Person" .
music:opera         rdfs:label "Opera" .

music:composed-by   rdfs:label "Composed by" .
music:premiere-date rdfs:label "Premi&#232;re date" .
music:synopsis      rdfs:label "Synopsis" .
</pre>

<hr/>
</div>

<div class="section" >

<h2><a id="proposals" name="proposals"/>3 Existing translation proposals</h2>

<h3><a id="moore" name="moore"/>3.1 The Moore Proposal</h3>

<h4><a id="moore_description" name="moore_description"/>3.1.1
Description</h4>

<p><a href="#Moore01">[Moore 01]</a> was the first paper to address
the issue of interoperability between RDF and Topic Maps. The paper
starts out by presenting data models developed by the author that
"capture the isness [sic] of the two paradigms". Having presented the
two models, Moore introduces the distinction between what he calls
"mapping the model" and "modelling the model". The key difference is
that the former is "semantic", whereas the latter "uses each standard
as a tool for describing other models". The two approaches will
hereafter be termed "semantic mapping" and "object mapping",
respectively.</p>

<p>Moore provides examples of both strategies but states clearly that
semantic mapping is preferable to object mapping. The reason for this
is that a goal is to be able to run, say, a TMQL query against an RDF
model and get "expected results" ("i.e. those that would be gained
from running a query against the equivalent topic map"). Moore points
out that this is only possible when a semantic mapping approach is
used.</p>

<h5><a id="an_object_mapping" name="an_object_mapping"/>An object mapping</h5>

<p>Moore's RDF2TM object mapping approach is based on defining PSIs
for every RDF construct in his model (i.e., resource, statement,
property, subject, object, identity, literal, and model) and
expressing RDF statements as ternary associations of type
<tt>rdf-statement</tt> using the role types <tt>rdf-subject</tt>,
<tt>rdf-property</tt> and <tt>rdf-object</tt>. This raises issues with
the handling of literals (since role players in associations cannot be
strings) to which no solution is proposed.</p>

<p>The TM2RDF object mapping approach is based on defining RDF
properties for each TM construct as follows: <tt>topic</tt>,
<tt>topicassoc</tt>, <tt>instanceof</tt>, <tt>topicassocmember</tt>,
<tt>roleplayingtopic</tt>, <tt>roledefiningtopic</tt>,
<tt>topicoccur</tt>, <tt>topicname</tt>, <tt>topicnamevalue</tt>,
<tt>scopeset</tt>, <tt>subjindicatorref</tt>, <tt>resourceref</tt>. An
example of a simple binary association is given that involves five
topics (for the association type and role types, in addition to the
role-playing topics). The RDF equivalent of this requires 22 statements,
three for each of the five topics, and seven for the association
itself.</p>

<h5><a id="a_semantic_mapping" name="a_semantic_mapping"/>A semantic mapping</h5>

<p>Moore concludes that the object mapping approach, while
interesting, is of limited usefulness, and he goes on to describe a
semantic mapping approach (which he calls "mapping the model") based
on the observation that "RDF is concerned with describing the arcs
between entities with identity [whereas] Topic Maps is concerned with
describing typed relationships between entities with identity." A
number of semantic equivalences are defined, as follows:</p>

<table border="1" cellpadding="4">
<tr align="left"><th>RDF</th><th>Topic Maps</th></tr>
<tr><td>RDF model</td><td>Topic Map</td></tr>
<tr><td>Identity</td><td>SubjectIndicatorReference</td></tr>
<tr><td>Resource</td><td>Topic</td></tr>
<tr><td>Statement</td><td>Association (approximate)</td></tr>
</table>

<p>The mapping from RDF statement to association is identified as
being problematic because "RDF has three pieces of information and
Topic Map associations have five", leading the author to suspect that
a "complete" semantic mapping of the models may not be possible. The
remainder of the paper is devoted to examining how to represent RDF
statements as associations and vice versa.</p>

<p>RDF statements are viewed as binary associations whose role-players
correspond to the subject and object of the statement and have the
role types 'subject' and 'object' respectively. The mechanism for
representing the property of the statement is not fully defined, since
the text and the diagram contradict each another. However, both text
and diagram assign some significance to the name of the topic that
represents the subject role.</p>

<p>According to Moore, this approach has a problem in that 'arc' is
"not a first class entity in the TopicMap model". Why this should be a
problem is not made clear, but Moore advocates solving it by extending
the Topic Maps model with the notion of arcs (and association
templates).</p>

<p>A different approach is employed in order to view associations as
RDF statements. An incomplete example shows a binary association
represented as <i>two</i> RDF statements, with the role-playing topics
being the subject and object in the one and the object and subject in
the other. This approach is perhaps motivated by the recognition that
RDF statements have direction whereas associations do not. However
this is not stated explicitly; nor is it clear how the approach would
work with associations that involve more than two role players.</p>

<h4><a id="moore_summary" name="moore_summary"/>3.1.2 Summary</h4>

<p>Moore's object mapping approach is reasonably complete, whereas his
semantic mapping approach is just a sketch that focuses on RDF
statements and associations. Other constructs like names, occurrences
and scope are not covered. Neither approach is reversible. In the case
of the object mapping approach, the assumption is that one is working
in one domain or the other, but not in both. In the case of the
semantic mapping approach, the fact that a statement maps to a single
association whereas an association maps to two statements shows that
translations cannot be reversed.</p>

<p>Semantic mappings are shown to be superior to object mappings in
terms of naturalness. The latter yields unnatural results in both
directions. Whatever the direction, a "natural" source document leads
to an "unnatural" result and achieving a "natural" result is only
possible if the starting point is "unnatural". In the object mapping
example given in the <a href="#Moore01">[Moore 01]</a>, a simple
binary association translates to 22 RDF statements.</p>

<p>Moore's semantic mapping approach, on the other hand, achieves a
more natural result: Going from Topic Maps to RDF, a binary
association requires two RDF statements; going the other way, an RDF
statement maps to a single association.</p>

<h4><a id="moore_test_cases" name="moore_test_cases"/>3.1.3 Test cases</h4>

<h5><a id="moore_tm2rdf" name="moore_tm2rdf"/>TM2RDF</h5>

<p>The following (incomplete) result of Moore's object mapping
approach was constructed by hand, based on the binary association
example given in <a href="#Moore01">[Moore 01]</a>. It does not cover
the two occurrences in the test case since there are no examples of
how this proposal handles occurrences. Lack of clarity in <a
href="#Moore01">[Moore 01]</a> prevents the construction of a
corresponding result of the semantic mapping approach; however, the
latter could be expected to contain significantly fewer RDF
statements.</p>

<pre>
# topic 1: puccini
_:puccini
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic1 .

_:topic1
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Giacomo Puccini" .

_:puccini
 &lt;http://www.empolis.com/rdftmmapping#tm-instanceof&gt;
  "http://psi.ontopia.net/music/#person" .

# topic 2: tosca
_:tosca
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic2 .

_:topic2
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Tosca" .

_:tosca
 &lt;http://www.empolis.com/rdftmmapping#tm-instanceof&gt;
  "http://psi.ontopia.net/music/#opera" .

# topic 3: composer
&lt;http://psi.ontopia.net/music/#composer&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic3 .

_:topic3
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Composer" .

&lt;http://psi.ontopia.net/music/#composer&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-subjindicatorref&gt;
  "http://psi.ontopia.net/music/#composer" .

# topic 4: opera
&lt;http://psi.ontopia.net/music/#opera&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic4 .

_:topic4
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Opera" .

&lt;http://psi.ontopia.net/music/#opera&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-subjindicatorref&gt;
  "http://psi.ontopia.net/music/#opera" .

# topic 5: composed-by
&lt;http://psi.ontopia.net/music/#composed-by&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic5 .

_:topic5
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Composed by" .

&lt;http://psi.ontopia.net/music/#composed-by&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-subjindicatorref&gt;
  "http://psi.ontopia.net/music/#composed-by" .

# topic 6: person
&lt;http://psi.ontopia.net/music/#person&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic6 .

_:topic6
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Person" .

&lt;http://psi.ontopia.net/music/#person&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-subjindicatorref&gt;
  "http://psi.ontopia.net/music/#person" .

# topic 7: work
&lt;http://psi.ontopia.net/music/#work&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-topicname&gt;
  _:topic7 .

_:topic7
 &lt;http://www.empolis.com/rdftmmapping#tm-topicnamevalue&gt;
  "Work" .

&lt;http://psi.ontopia.net/music/#work&gt;
 &lt;http://www.empolis.com/rdftmmapping#tm-subjindicatorref&gt;
  "http://psi.ontopia.net/music/#work" .

# association
_:assoc-1
 &lt;http://www.empolis.com/rdftmmapping#tm-instanceof&gt;
  &lt;http://psi.ontopia.net/music/#composed-by&gt; .
_:assoc-1
 &lt;http://www.empolis.com/rdftmmapping#tm-topicassocmember&gt;
  _:assocmember-1 .
_:assoc-1
 &lt;http://www.empolis.com/rdftmmapping#tm-topicassocmember&gt;
  _:assocmember-2 .
_:assocmember-1
 &lt;http://www.empolis.com/rdftmmapping#tm-roledefiningtopic&gt;
  &lt;http://psi.ontopia.net/music/#composer&gt; .
_:assocmember-1
 &lt;http://www.empolis.com/rdftmmapping#tm-roleplayingtopic&gt;
  _:puccini .
_:assocmember-2
 &lt;http://www.empolis.com/rdftmmapping#tm-roledefiningtopic&gt;
  &lt;http://psi.ontopia.net/music/#work&gt; .
_:assocmember-2
 &lt;http://www.empolis.com/rdftmmapping#tm-roleplayingtopic&gt;
  _:tosca .
</pre>

<p>The main thing to note about this test result is the number of
statements required (28) to represent just a part of the information
content that would naturally be expressed in RDF using just 12
statements. Since associations require seven statements it can be
reasonably assumed that the two occurrences that are not represented
here would require a further 2*7 statements, plus two statements
(each) for the names of the occurrence types. This would bring the
total number of statements to approximately 46.</p>

<p>The verbosity (or "statement bloat") seen here is typical of TM2RDF
translation approaches that are based on object mappings, as will be
confirmed by the accounts of the Stanford and Ogievetsky
proposals.</p>

<h5><a id="moore_rdf2tm" name="moore_rdf2tm"/>RDF2TM</h5>

<p>This test case cannot be represented as a topic map in its entirety
following Moore's object mapping approach because there is no
provision for RDF statements whose objects are literals (which is the
case for eight of the 12 statements in the test case, including all
the names). The four statements whose objects are resources would each
be represented as a ternary association of type <tt>statement</tt>, as
follows:</p>

<pre>
statement( ag0 : subject, composed-by : property, ag1 : object )
</pre>

<p>(This ternary association captures the assertion that Tosca (ag0)
was composed by Puccini (ag1).)</p>

<p>The RDF2TM test case can also not be represented as a topic map in
accordance with Moore's alternative semantic mapping approach due to
insufficient information in <a href="#Moore01">[Moore 01]</a>. Each
RDF statement would in theory be represented by a single binary
association, but once again there is no provision for handling
statements whose objects are literals.</p>

<hr/>

<h3><a id="stanford" name="stanford"/>3.2 The Stanford Proposal</h3>

<h4><a id="stanford_description" name="stanford_description"/>3.2.1 Description</h4>

<p>Lacher and Decker <a href="#Lacher01">[Lacher 01]</a> focus on
making it possible to query Topic Maps using an "RDF-aware
infrastructure" that was co-developed by one of the authors. This
proposal is thus TM2RDF only.</p>

<p>Reference is made to the layered integration model of data
interoperability which separates the data integration problem into
three quasi-independent layers: the syntax layer, the object layer,
and the semantic layer. The idea is to build an RDF representation of
the topic map on the object layer and then perform a "bijective graph
transformation" such that the topic map can be viewed as RDF. Ignoring
the syntax layer means that the approach will work with both the SGML
and the XML serialization syntaxes of Topic Maps. Ignoring the
semantic layer (i.e., adopting what we have termed an object mapping
approach) has the advantage, according to the authors, that all
information is preserved. (The authors point out that a semantic
mapping "could possibly lead to a loss of information".)</p>

<p>Instead of defining their own model for Topic Maps, Lacher and
Decker use PMTM4, the Processing Model for Topic Maps, proposed by
Newcomb and Biezunski in <a href="#PMTM4">[PMTM4]</a>, which has since
been superseded by <a href="#TMDM">[TMDM]</a>.</p>

<p>PMTM4 is a graph model consisting of three node types (for topics,
associations, and scopes), and four arc types: associationMember (aM),
associationScope (aS), associationTemplate (aT), and scopeComponent
(sC). The aM arc is "peculiar" in that it is both typed and labelled
(and thus effectively has three ends) in order to connect the
association with both the role-player and its role (or role type).
Names and occurrences are regarded as specializations of associations;
URIs and strings are not part of the model.</p>

<p>To illustrate their approach Lacher and Decker show a simple
(untyped) association between the country Denmark (which has a name) and
the natural resource petroleum. This is represented as a PMTM4 graph
consisting of eight t-nodes, two a-nodes, four aM arcs, and one aT arc.
The (binary) association between Denmark and petroleum requires two aM
arcs (one for each role), and so does the name "Denmark" (since topic
names are regarded in PMTM4 as a kind of binary association).</p>

<p>Lacher and Decker define RDF classes and properties for each of the
PMTM4 node types and arc types. The transformation consists essentially
of replacing a-, t-, and s-nodes with RDF nodes of corresponding types,
and replacing arcs with corresponding properties. However in order to
handle the "three-legged" aM arcs, reification is necessary, thus
introducing one new RDF node and four new properties
(<tt>rdf:subject</tt>, <tt>rdf:predicate</tt>, <tt>rdf:object</tt> and
<tt>tms:roleLabel</tt>) for each aM arc. The resulting "RDF Topic Map
graph" is shown as a figure consisting of a total of 17 nodes and 20
arcs. (The actual totals should probably be higher since
<tt>rdf:type</tt> is only specified for a few nodes.)</p>

<p>The authors opt to represent each undirected PMTM4 arc by a single,
directed RDF arc (rather than two arcs) in order to avoid consistency
problems, pointing out that while this is not a lossy transformation,
it does require consideration when formulating queries.</p>

<p>No syntax example is given in <a href="#Lacher01">[Lacher 01]</a> to
show the result of the transformation but from the text it is clear that
node identity is either based on source locators (where XML IDs were
specified in the source topic map) or else generated (where no IDs were
specified). Subject identifiers and subject locators are not used
&#8211; presumably because the PMTM4 model does not extend to
identifiers.</p>

<p>Having constructed an RDF graph from the topic map, Lacher and Decker
show how it can be queried, together with native RDF data, by a single
query expressed in F-Logic syntax. The query uses the RDF-encoded topic
map to find all countries that have petroleum as a natural resource and
then extracts links to DMOZ Travel_and_Tourism pages for those countries
from the RDF-encoded Open Directory:</p>

<pre>
FORALL pages &lt;- Country, DMOZCountry Y,X, Z
    Y[tms:roleLabel-&gt;country;rdf:object-&gt;Country]
        @CIA_WORLD_FACTBOOK and
    X[tms:roleLabel-&gt;natural-resource;
      rdf:object-&gt;petroleum;
      rdf:subject-&gt;Z[tms:associationMember-&gt;Country]
        @CIA_WORLD_FACTBOOK]
        @CIA_WORLD_FACTBOOK and
    Country[mapsTo-&gt;DMOZCountry] and
    DMOZCountry[Travel_and_Tourism -&gt;dmozpage[links-&gt;pages]]
        @DMOZ.
</pre>

<h4><a id="stanford_summary" name="stanford_summary"/>3.2.2 Summary</h4>

<p>The Stanford approach is complete with respect to PMTM4, but the
latter is not a complete model for Topic Maps (since is does not handle
URIs and strings). The Stanford proposal itself is therefore not
complete.</p>

<p>The proposal does not score well in terms of naturalness since it
requires upwards of 20 statements to represent information that would
naturally be modelled using two statements in RDF. The TM2RDF test
cases results in approximately 160 statements.</p>

<h4><a id="stanford_test_cases" name="stanford_test_cases"/>3.2.3 Test cases</h4>

<h5><a id="stanford_tm2rdf" name="stanford_tm2rdf"/>TM2RDF</h5>

<p>A test case has been requested from the authors. The following is
an attempt to hand-code parts of the test case. Only the association
and the names of the two role-playing topics are shown. All
occurrences, type-instance relationships, and names of typing topics
are omitted. It is estimated that these would require a further 115
statements (13*2=26; + 12*2=24; + 12*5+5=65) in addition to the 45
statements shown below.</p>

<pre>
@prefix  rdf:   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix  tms:   &lt;http://www.standford.edu/rdftmmapping/tm-schema#&gt; .
@prefix  psi1:  &lt;file:psi1.xtm#&gt; .
@prefix  core:  &lt;file:core.xtm#&gt; .

### composed-by association ---------------------------
_:puccini-tosca-assoc
  rdf:type                  tms:association ;
  tms:associationTemplate   _:composed-by .

# reified statement representing composer role
_:puccini-composer-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:puccini-tosca-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        _:puccini ;
  tms:roleLabel     _:composer .

# reified statement representing work role
_:puccini-work-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:puccini-tosca-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        _:tosca ;
  tms:roleLabel     _:work .

### topic-basename association for puccini ------------
_:puccini-name-assoc
  rdf:type                  tms:association ;
  tms:associationTemplate   psi1:at-topic-basename .

# reified statement representing topic role
_:puccini-topic-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:puccini-name-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        _:puccini ;
  tms:roleLabel     core:role-topic .

# reified statement representing basename role
_:puccini-name-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:puccini-name-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        "Giacomo Puccini" ;
  tms:roleLabel     core:role-basename .

### topic-basename association for tosca --------------
_:tosca-name-assoc
  rdf:type                  tms:association ;
  tms:associationTemplate   psi1:at-topic-basename .

# reified statement representing topic role
_:tosca-topic-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:tosca-name-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        _:tosca ;
  tms:roleLabel     core:role-topic .

# reified statement representing basename role
_:tosca-name-role
  rdf:type          rdf:Statement ;
  rdf:subject       _:tosca-name-assoc ;
  rdf:predicate     tms:roleLabel ;
  rdf:object        "Tosca" ;
  tms:roleLabel     core:role-basename .

### specification of node types -----------------------
_:puccini                 rdf:type          tms:topic .
_:tosca                   rdf:type          tms:topic .
_:composed-by             rdf:type          tms:topic .
_:composer                rdf:type          tms:topic .
_:opera                   rdf:type          tms:topic .

tms:associationTemplate   rdf:type          tms:topic .
tms:roleLabel             rdf:type          tms:topic .

core:role-topic           rdf:type          tms:topic .
core:role-basename        rdf:type          tms:topic .
</pre>

<hr/>

<h3><a id="ogievetsky" name="ogievetsky"/>3.3 The Ogievetsky Proposal</h3>

<h4><a id="ogievetsky_description" name="ogievetsky_description"/>3.3.1 Description</h4>

<h5><a id="from_xtm_to_rdf" name="from_xtm_to_rdf"/>From XTM to RDF</h5>

<p><a href="#Ogievetsky01b">[Ogievetsky 01b]</a> describes both a
method for transforming topic maps expressed in XTM syntax (<a
href="#XTM1.0">[XTM1.0]</a>) to RDF and the author's XSLT-based
implementation of this approach in the <i>XTM2RDF Translator</i>.
Transformations are described in terms of the processing of XTM
elements and the approach is thus very syntax-oriented. The resulting
RDF conforms to a vocabulary (called RTM) which consists of 11 classes
and 17 properties defined partly in terms of XTM itself and partly in
terms of PMTM4, the "processing model" proposed by Newcomb and
Biezunski and described in the preceding section.</p>

<p>The classes and properties defined by the RTM vocabulary are:</p>

<dl>
<dt><b>rdfs:Class</b></dt>
<dd>t-node, topic, scope, member, association, basename, variantname,
occurrence, class-subclass, class-instance, templaterpc</dd>

<dt><b>rdf:Property</b></dt>
<dd>association-role, validIn, indicatedBy, constitutedBy, name,
templatedBy, role-topic, role-basename, role-variantname,
role-occurrence, role-superclass, role-subclass, role-class,
role-instance, role-template, role-role, role-rpc</dd>
</dl>

<p>Each <tt>&lt;topic&gt;</tt> element results in the creation of an
RDF statement of type <tt>rtm:topic</tt>. The topic's subject locator
(if any) becomes the URI of the subject of the statement, otherwise a
blank node is created. Subject identifiers (if any) result in
properties of type <tt>rtm:indicatedBy</tt>. The purpose of stating
that topics are of type <tt>rtm:topic</tt> seems to be the desire to
use <tt>rtm:topic</tt> as an element type name in order to aid
readability when using the "third RDF basic abbreviated form".</p>

<p>Associations are represented as blank nodes whose type corresponds
to the association type. In addition, for each role in the association
there is one statement whose property corresponds to the role type
(e.g. <tt>ns1:composer</tt> and <tt>ns1:work</tt> in the example
below); its value is a node of type <tt>rtm:member</tt> that
references the role player. Referencing is done through an
<tt>rtm:indicatedBy</tt> property when the role player has a subject
identifier and an <tt>rtm:constitutedBy</tt> property when the role
player has a subject locator. (The text does not state what form the
reference takes when the role player has neither.)</p>

<p>The following example shows how the association between Tosca and
Puccini is represented in RDF/XML in "third RDF basic abbreviated
form":</p>

<pre>
&lt;ns1:composed-by&gt;
  &lt;ns1:composer&gt;
    &lt;rtm:member&gt;
      &lt;rtm:indicatedBy rdf:resource="http://en.wikipedia.org/wiki/Puccini" /&gt;
    &lt;/rtm:member&gt;
  &lt;/ns1:composer&gt;
  &lt;ns1:work&gt;
    &lt;rtm:member&gt;
      &lt;rtm:indicatedBy rdf:resource="http://psi.ontopia.net/opera/#tosca" /&gt;
    &lt;/rtm:member&gt;
  &lt;/ns1:work&gt;
&lt;/ns1:composed-by&gt;
</pre>

<p>In all, seven RDF statements are used to represent the association.
(Normally in RDF, of course, a relationship like this would be
represented by a single statement.)</p>

<p>There is a very obvious similarity between the syntax shown above
and XTM, which could indicate that the desire to output readable
RDF/XML syntax (and perhaps the exigencies of XSLT-based processing)
have influenced the form of RDF chosen for the target model.</p>

<p>In accordance with PMTM4, the approach to handling associations
described above is extended to other Topic Maps constructs. Thus, the
type-instance relationship is regarded as an association of a specific
type; and occurrence, base name, and variant are all regarded as
subtypes of association with fixed pairs of role types
(topic/occurrence, topic/name, and basename/variantname,
respectively).</p>

<p>String values for names and internal occurrences are represented as
the values of <tt>rtm:name</tt> properties of member nodes. The
following example shows the base name of the composer Puccini as
output by the <i>xtm2rdf.xsl</i> XSLT stylesheet. A blank node
represents the topic-basename relationship. Syntactically, the
<tt>rtm:baseName</tt> construct has exactly the same "shape" as the
association shown above:</p>

<pre>
&lt;rtm:baseName rdf:ID="XSLTbaseName122124120120"&gt;
  &lt;rtm:role-topic&gt;
    &lt;rtm:member&gt;
      &lt;rtm:indicatedBy rdf:resource="#puccini" /&gt;
    &lt;/rtm:member&gt;
  &lt;/rtm:role-topic&gt;
  &lt;rtm:role-name&gt;
    &lt;rtm:member&gt;
      &lt;rtm:name&gt;Giacomo Puccini&lt;/rtm:name&gt;
    &lt;/rtm:member&gt;
  &lt;/rtm:role-name&gt;
&lt;/rtm:baseName&gt;
</pre>

<p>As with binary associations, seven RDF statements are required to
represent a single topic name characteristic that would naturally be
modelled using a single statement in RDF.</p>

<h5><a id="ogievetsky_round-tripping" name="ogievetsky_round-tripping"/>Round-tripping RDF to Topic Maps and back</h5>

<p>Having presented the methodology for translating XTM to RDF,
Ogievetsky considers round-tripping from RDF to XTM and back to RDF.
<a href="#Ogievetsky01b">[Ogievetsky 01b]</a> is actually a
continuation of earlier work for which only a set of slides (<a
href="#Ogievetsky01a">[Ogievetsky 01a]</a>) is available. In the
earlier work RDF data was translated into XTM, again using XSLT
stylesheets.</p>

<p>To demonstrate round-tripping <a href="#Ogievetsky01b">[Ogievetsky
01b]</a> shows an example of a Dublin Core fragment in RDF being
translated to XTM according to the methodology in <a
href="#Ogievetsky01a">[Ogievetsky 01a]</a>, and then translated back to
RDF according to the methodology in <a href="#Ogievetsky01b">[Ogievetsky
01b]</a>. The source document contains a single RDF statement asserting
that the resource <tt>ZARA.xml</tt> has the creator "Jane M. Folpe".
This translates to a topic map consisting of six TAOs (five topics and
one association), which in turn translates back to RDF as a set of no
less than 26 RDF statements. "Obviously we accumulated a lot of semantic
luggage during our roundtrip" is Ogievetsky's laconic comment.</p>

<p>The remainder of <a href="#Ogievetsky01b">[Ogievetsky 01b]</a> is
devoted to showing how "RDF Topic Maps" can be queried (using the RDF
query language SquishQL) and constrained (using DAML+OIL). The
following sample query shows how to find all topics that have names in
the scope "taxon":</p>

<pre>
SELECT ?topic, ?name
FROM  http://www.cogx.com/xtm2rdf/seacr.rtm#
WHERE
  (rdf::type ?a ?rtm::basename)
  (rtm::role-topic ?a ?m1) (rtm::indicatedBy ?m1 ?topic)
  (rtm::role-name ?a ?m2)(rtm::name ?m2 ?name)
  (rtm::validIn ?a ?s)(rtm::indicatedBy ?s this::taxon)
USING
  rdf FOR http://www.w3.org/1999/02/22-rdf-syntax-ns#
  rtm FOR http://www.cogx.com/xtm2rdf/rtm.rdf#
  this FOR  http://www.cogx.com/xtm2rdf/seacr.rtm#
</pre>

<h4><a id="ogievetsky_summary" name="analysis"/>3.3.2 Summary</h4>

<p>The proposal appears to be fairly complete in that it covers
more-or-less every aspect of XTM syntax (which requires extending the
underlying PMTM4 model in order to cater for identifiers). The example
of round-tripping shows clearly that this proposal in combination with
the undocumented RDF2TM translation fails the test of reversibility
since a single RDF statement ends up as 26 statements after the
roundtrip.</p>

<p>The proposal requires seven statements to represent information
content that would naturally be modelled using one statement in RDF and
thus rates very low in terms of naturalness. Translating the Topic Maps
test case results in an RDF document containing 125 statements.</p>

<h4><a id="ogievetsky_test_cases" name="ogievetsky_test_cases"/>3.3.3 Test cases</h4>

<h5><a id="ogievetsky_tm2rdf" name="ogievetsky_tm2rdf"/>TM2RDF</h5>

<pre>
@prefix rtm: &lt;http://www.cogx.com/xtm2rdf/rtm.rdf#&gt; .
@prefix ns1: &lt;http://psi.ontopia.net/music/#&gt; .
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix this: &lt;#&gt; .

this:XSLTbaseName121120120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Opera" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:opera ] .

this:XSLTbaseName121121120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Composer" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:composer ] .

this:XSLTbaseName121122120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Premi&#232;re date" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:premiere-date ] .

this:XSLTbaseName121123120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Composed by" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:composed-by ] .

this:XSLTbaseName121126120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Synopsis" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:synopsis ] .

this:XSLTbaseName121127120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Work" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:work ] .

this:XSLTbaseName121126120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Person" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:person ] .

this:XSLTbaseName122124120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Giacomo Puccini" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:puccini ] .

this:XSLTbaseName122125120120
  rdf:type rtm:baseName;
  rtm:role-name  [
    rdf:type rtm:member;
    rtm:name "Tosca" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:tosca ] .

this:XSLTinstanceOf120124120120
  rdf:type rtm:classInstance;
  rtm:role-class  [
    rdf:type rtm:member;
    rtm:indicatedBy ns1:person ];
  rtm:role-instance  [
    rdf:type rtm:member;
    rtm:indicatedBy this:puccini ] .

this:XSLTinstanceOf120125120120
  rdf:type rtm:classInstance;
  rtm:role-class  [
    rdf:type rtm:member;
    rtm:indicatedBy ns1:opera ];
  rtm:role-instance  [
    rdf:type rtm:member;
    rtm:indicatedBy this:tosca ] .

this:XSLToccurrence123125120120
  rdf:type ns1:premiere-date;
  rtm:role-occurrence  [
    rdf:type rtm:member;
    rtm:name "1900 (14 Jan)" ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:tosca ] .

this:XSLToccurrence124125120120
  rdf:type ns1:synopsis;
  rtm:role-occurrence  [
    rdf:type rtm:member;
    rtm:constitutedBy &lt;http://www.azopera.com/learn/synopsis/tosca.shtml&gt; ];
  rtm:role-topic  [
    rdf:type rtm:member;
    rtm:indicatedBy this:tosca ] .

[ rdf:type ns1:composed-by;
  ns1:composer  [
    rdf:type rtm:member;
    rtm:indicatedBy this:puccini ];
  ns1:work  [
    rdf:type rtm:member;
    rtm:indicatedBy this:tosca ] ].

this:composed-by
  rdf:type rtm:topic;
  rtm:indicatedBy ns1:composed-by .

this:composer
  rdf:type rtm:topic,
           rdf:Property;
  rtm:indicatedBy ns1:composer;
  rdfs:domain ns1:composed-by;
  rdfs:range rtm:member .

this:work
  rdf:type rtm:topic,
           rdf:Property;
  rtm:indicatedBy ns1:work;
  rdfs:domain ns1:composed-by;
  rdfs:range rtm:member .

this:premiere-date
  rdf:type rtm:topic,
           rdfs:Class;
  rtm:indicatedBy ns1:premiere-date;
  rdf:subClassOf rtm:occurrence .

this:synopsis
  rdf:type rtm:topic,
           rdfs:Class;
  rtm:indicatedBy ns1:synopsis;
  rdf:subClassOf rtm:occurrence .

this:opera
  rdf:type rtm:topic,
           rdfs:Class;
  rtm:indicatedBy ns1:opera .

this:person
  rdf:type rtm:topic,
           rdfs:Class;
  rtm:indicatedBy ns1:person .

this:puccini
  rdf:type rtm:topic .

this:tosca
  rdf:type rtm:topic .
</pre>

<hr/>

<h3><a id="garshol" name="garshol"/>3.4 The Garshol Proposal</h3>

<h4><a id="garshol_description" name="garshol_description"/>3.4.1 Description</h4>

<p>This proposal was originally presented in <a
href="#Garshol01">[Garshol 01]</a> as part of a comparative analysis of
the RDF and Topic Maps models. The analysis was further developed (and
extended to partially address OWL) in <a href="#Garshol03a">[Garshol
03a]</a>. The approach has been implemented by the author in the
<i>Ontopia Knowledge Suite</i>.</p>

<p><a href="#Garshol03a">[Garshol 03a]</a> starts by comparing RDF and
Topic Maps through an examination of concepts that are fundamental to
both paradigms: "symbols and things", "assertions", "identity",
"reification", "qualification", and "types and subtypes". For each
concept, Garshol shows how they are expressed in each paradigm and draws
out the similarities and differences.</p>

<h5><a id="comparing_rdf_and_topic_maps" name="comparing_rdf_and_topic_maps"/>Comparing RDF and Topic Maps</h5>

<p>According to Garshol, RDF and Topic Maps are both "identity-based
technologies"; that is, the key concept in both is <i>symbols</i>
representing identifiable <i>things</i> about which <i>assertions</i>
can be made. In Topic Maps, "things" are called "subjects"; in RDF
they are called "resources" and, despite different definitions, they
are essentially the same concept. Subjects are represented by topics;
resources are represented by RDF nodes (or "nodes" for short).
According to Garshol, the correspondence between "topic" and "node" is
close but not exact; he does not explain why, but the reason is
presumably that RDF nodes can be literals, which would be represented
as strings rather than topics in Topic Maps.</p>

<p><i>Assertions</i> express relationships between things and take the
form of "topic characteristics" in Topic Maps and "statements" in RDF.
A topic characteristic can be a name, an occurrence, or an
association. An RDF statement can thus in theory be mapped to any one
of these three kinds of construct. Special attention is paid to
associations since these can be of any arity, whereas all RDF
statements are binary. A binary association maps fairly well to an RDF
statement, but a non-binary association does not.</p>

<p>In addition, RDF statements have direction but associations do not.
Topic Maps uses the notion of "roles" to express the nature of each
subject's involvement in the relationship; in RDF this involvement is
implicit in the subject-predicate-object structure of the statement.</p>

<p>For these reasons, the correspondence between topic characteristics
and statements is considered to be close, but not exact.</p>

<p>The issue of <i>identity</i> is considered to be "quite a thorny
problem for interoperability between topic maps and RDF" since,
although Topic Maps and RDF both use URIs as identifiers, they do so
in different ways. In RDF there is only one kind of identifier and a
node can have at most one of them (blank nodes and literals have
none). In Topic Maps, topics can have any number of identifiers and a
distinction is made between "subject locators" (URIs which identify
the subject directly, formerly called "subject addresses") and
"subject identifiers" (URIs which identify the subject indirectly, via
a subject indicator). Garshol refers the reader to a more in-depth
treatment of the issue in <a href="#Pepper03">[Pepper 03]</a>, which
is discussed in <a href="#other_proposals">section 3.6</a> below.</p>

<p>Garshol's discussion of <i>reification</i> brings out certain
differences between Topic Maps and RDF but does not reach any conclusion
regarding the degree of correspondence between the two, although the
point is made that reification is not a very commonly used feature.
<i>Qualification</i> is seen as being related to reification, since the
built-in Topic Maps feature "scope" is essentially a mechanism for
making certain kinds of assertions about other assertions, but no
proposal is made regarding how to express scope in RDF.</p>

<p>The concept of <i>types and subtypes</i>, on the other hand, is
regarded as being identical in Topic Maps and RDF (except for the fact
that the subClassOf property is part of RDF Schema rather than RDF
itself).</p>

<p>Garshol summarizes his analysis by pointing to three fundamental
differences between RDF and Topic Maps that "make it technically very
difficult to merge" the two paradigms: identity, assertions, and
reification (including qualification). The rest of his paper therefore
focuses on ways to "move data between the two with as little effort as
possible" (rather than on how to unify the two models).</p>

<h5><a id="object_or_semantic" name="object_or_semantic"/>Object mappings or semantic mappings?</h5>

<p>The object mapping approach taken by <a href="#Moore01">[Moore
01]</a>, <a href="#Lacher01">[Lacher 01]</a>, <a
href="#Ogievetsky01b">[Ogievetsky 01b]</a>, and <a
href="#Garshol02">[Garshol 02]</a> is briefly considered and then
rejected as being</p>

<blockquote style="font-style: italic">
<p>both heavy-weight and rather awkward to work with. Any query or
retrieval specified in end-user terms will have to explicitly take into
account topic map model features, and information from topic maps will
not interoperate cleanly with other RDF information.</p>
</blockquote>

<p>Garshol's conclusion is that "although this [object mapping] approach
is easy to use, the results do not meet the criterion of clean
integration with other RDF data."</p>

<p>As an alternative, Garshol proposes to use vocabulary-specific
mappings underpinned by a generic mapping. Statements should in
general be mapped to names, occurrences or associations since this
provides the most "natural" results. However, it is not possible to
know which of these is most appropriate for any given statement
without an understanding of the semantics of the property in question
&#8211; hence the need for vocabulary-specific mappings. For example,
the RDF statement:</p>

<pre>
&lt;http://example.com/X&gt;
  &lt;http://example.com/Y&gt;
    "foo" .
</pre>

<p>could be mapped in Topic Maps to either a name or an internal
occurrence (since the object is a literal). Similarly, the
statement:</p>

<pre>
&lt;http://example.com/X&gt;
  &lt;http://example.com/W&gt;
    &lt;http://example.com/Z&gt; .
</pre>

<p>could be mapped to either an association or an external occurrence
(since the object is a resource). An optimal semantic translation
cannot be performed without knowledge of the semantics of the
properties <tt>Y</tt> and <tt>W</tt>.</p>

<h5><a id="rdf2tm_mapping" name="rdf2tm_mapping"/>RDF2TM mapping</h5>

<p>The solution according to Garshol is to provide additional mapping
information. This is done using an RDF vocabulary called RTM (<a
href="#Ontopia03a">[Ontopia 03a]</a>) which is used to annotate RDF
documents (or their schemas) and thus guide the translation process.
The RTM vocabulary is used for translating from RDF to Topic Maps and
consists of the following RDF properties: <tt>maps-to</tt>,
<tt>type</tt>, <tt>in-scope</tt>, <tt>subject-role</tt>,
<tt>object-role</tt>.</p>

<p>The <tt>maps-to</tt> property can have the following values:</p>

<ul>
<li><tt>rtm:basename</tt>: maps a statement to a base name</li>
<li><tt>rtm:occurrence</tt>: maps a statement to an occurrence</li>
<li><tt>rtm:association</tt>: maps a statement to association</li>
<li><tt>rtm:instance-of</tt>: maps a statement to a class-instance
association</li>
<li><tt>rtm:subject-identifier</tt>: maps the values of a statement to a
subject identifier</li>
<li><tt>rtm:subject-locator</tt>: maps the values of a statement to a
subject locator</li>
<li><tt>rtm:source-locator</tt>: maps the values of a statement to a
source locator</li>
</ul>

<p>Mappings that use <tt>rtm:occurrence</tt> or <tt>rtm:association</tt>
will automatically use the statement's property to type the resulting
Topic Maps
construct, unless <tt>rtm:type</tt> is used to override this behaviour.
The <tt>rtm:in-scope</tt> property can be used to specify scoping topics
for base names, occurrences, and associations. Finally, the
<tt>rtm:subject-role</tt> and <tt>rtm:object-role</tt> properties are
used to specify the types of role played by the subject and object of
an RDF statement when the statement maps to an association.</p>

<p>The vocabulary (and the implementations) go somewhat beyond what is
covered in <a href="#Garshol03a">[Garshol 03a]</a>. For example, it is
recognized that properties may be mapped to various kinds of
identifiers (source locators, subject identifiers, and subject
locators) or to the privileged <i>instance-of</i> relationship, in
addition to names, occurrences, and associations.</p>

<p>In addition, greater provision is made in the implementation for
defaulting. Resource URIs are always mapped to subject identifiers and
RDF statements can be imported as associations in the absence of role
type information, in which case the predefined topics <tt>subject</tt>
and <tt>object</tt> are used as role types.</p>

<h5><a id="tm2rdf_mapping" name="tm2rdf_mapping"/>TM2RDF mapping</h5>

<p>Going from Topic Maps to RDF is shown to require additional
information in order for optimal and/or predictable results to be
achieved. The following problems are identified:</p>

<ol>
<li>Choosing properties when mapping names</li>
<li>Choosing the subject when mapping associations</li>
</ol>

<p>Garshol points out a number of issues that are not addressed in his
analysis, including multiple identifiers, n-ary associations,
reification and scoping, unary associations, variant names, and a number
of (unspecified) "tricky edge cases"; for some of these he sketches
possible solutions which have since been implemented:</p>

<blockquote style="font-style: italic">
<ul>
<li><p>Multiple URIs for the same topic can be handled using the RDF
properties for equivalence found in OWL.</p></li>
<li><p>Associations with more than two roles can be turned into
resources whose type is the association type, and each role can then
be represented as a separate statement with the role type as the
property and the association resource as the subject.</p></li>
<li><p>Reification and scoping can in general be represented by using
RDF reification to represent the statement that would connect the
topic characteristic with the topic. A special property will have to
be defined for representing scope. As for the reification this is done
by simply merging the resource representing the topic characteristic
assignment with that representing the reifying topic.</p></li>
<li><p>Binary non-symmetric associations can be handled by having the
mapping contain one association from the association type to the
preferred subject role.</p></li>
<li><p>Selection of name properties can be done by having the mapping
contain an association from the topic type to a topic representing the
preferred RDF name property.</p></li>
</ul>
</blockquote>

<p>A second vocabulary (called TMR, <a href="#Ontopia03b">[Ontopia
03b]</a>), consisting of six published subjects, addresses many of these
issues. Name mapping is handled by <tt>tmr:name-property</tt>,
<tt>tmr:type</tt>, and <tt>tmr:property</tt>, and the problem of mapping
associations is solved using <tt>tmr:preferred-role</tt>,
<tt>tmr:association-type</tt>, and <tt>tmr:role-type</tt>.</p>

<p>As with the RDF2TM translation, the implementations provide some
level of defaulting. Both subject identifiers and subject locators are
automatically mapped to resource URIs. In addition, associations can be
exported to RDF in the absence of mapping information about roles; in
this case the choice of subject and object for the resulting statement
is arbitrary.</p>

<p>The remainder of <a href="#Garshol03a">[Garshol 03a]</a> is devoted
to a comparison of the respective constraint and query languages of
Topic Maps and RDF and is thus beyond the scope of this analysis.</p>

<h4><a id="garshol_summary" name="garshol_summary"/>3.4.2 Summary</h4>

<p>As currently specified the Garshol proposal provides an almost
complete solution and the author himself identifies most of the
respects in which it is incomplete. Those which are not mentioned
include containers, collections, XML literals and typed literals. A
high degree of reversibility and round-tripping is achievable,
provided appropriate reverse mappings are generated during the
translation. An issue exists with subject locators that end up as
subject identifiers when round-tripping from Topic Maps to RDF and
back to Topic Maps.</p>

<p>The proposal scores well in terms of naturalness. Even when using
default mappings the results are quite natural. The TM2RDF test case
results in an RDF document containing 13 statements. The RDF2TM test
case results in a topic map containing 25 TAOs (19 topic, three
associations, and three occurrences).</p>

<h4><a id="garshol_test_cases" name="garshol_test_cases"/>3.4.3 Test cases</h4>

<p>The test translations were performed using Ontopia's <i>Omnigator
Eight</i> (OKS 2.1.0, build 2004-12-15 #1495) <a
href="#Ontopia05">[Ontopia 05]</a>.</p>

<h5><a id="garshol_tm2rdf" name="garshol_tm2rdf"/>TM2RDF</h5>

<p>The source document was opened in the <i>Omnigator</i> and exported
to RDF with default mappings. The document was then converted to N3
format using the Mindswap RDF Converter <a
href="#Mindswap02">[Mindswap 02]</a>, and finally tidied by hand in
order to ease comparison with the source document.</p>

<p>Note that since default settings were used, the choice of Puccini
as the subject of the <tt>music:composed-by</tt> statement was
entirely abitrary. Using Garshol's mapping mechanism it would be
possible to ensure that Tosca, rather than Puccini, became the subject
of this statement. The result of the translation would then be
identical to the equivalent RDF2TM, except that the role types
'composer' and 'work' would also be present.</p>

<pre>
@prefix : &lt;http://psi.ontopia.net/music/#&gt; .
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .

[ rdf:type :person;
  rdfs:label "Giacomo Puccini";
  :composed-by  [
    rdf:type  :opera;
    rdfs:label "Tosca";
    :premiere-date "1900-01-14";
    :synopsis &lt;http://www.azopera.com/learn/synopsis/tosca.shtml&gt; ]].

:composer      rdfs:label "Composer" .
:opera         rdfs:label "Opera" .
:person        rdfs:label "Person" .
:work          rdfs:label "Work" .

:composed-by   rdfs:label "Composed by" .
:premiere-date rdfs:label "Premi&#232;re date" .
:synopsis      rdfs:label "Synopsis" .
</pre>

<h5><a id="garshol_rdf2tm" name="garshol_rdf2tm"/>RDF2TM</h5>

<p>The source document was imported to the <i>Omnigator</i> with
mappings specified using the RDF2TM plug-in. Default mappings were
used for all properties except <tt>rdfs:label</tt>, which was mapped
to a base name instead of an internal occurrence, and
<tt>music:synopsis</tt>, which was mapped to an occurrence instead of
an association. The document was then exported to LTM and tidied by
hand in order to ease comparison with the source document.</p>

<p>Note that Garshol's mapping vocabulary allows for more precise
specification of the subject and object role types, but this
capability was not used here. As a result, the role types 'work' and
'composer become 'subject' and 'object', respectively and a scoping
topic ("Generated name") is added to the names of these topics.</p>

<pre>
@"utf-8"
#VERSION "1.3"

[puccini : person = "Giacomo Puccini"]
[tosca   : opera  = "Tosca"]

{tosca, premiere-date, [[1900-01-14]]}
{tosca, synopsis,      "http://www.azopera.com/learn/synopsis/tosca.shtml"}

composed-by( tosca : subject, puccini : object )

[person = "Person"  @"http://psi.ontopia.net/music/#person"]
[opera  = "Opera"  @"http://psi.ontopia.net/music/#opera"]

[premiere-date = "Premi&#232;re date"  @"http://psi.ontopia.net/music/#premiere-date"]
[synopsis      = "Synopsis"  @"http://psi.ontopia.net/music/#synopsis"]
[composed-by   = "Composed by"  @"http://psi.ontopia.net/music/#composed-by"]

[subject  = ":subject" / gen-name  @"http://psi.ontopia.net/rdf2tm/#subject"]
[object   = ":object" / gen-name  @"http://psi.ontopia.net/rdf2tm/#object"]
[gen-name = "Generated Name"  @"http://psi.ontopia.net/rdf2tm/#gen-name"]
</pre>

<hr/>

<h3><a id="unibo" name="unibo"/>3.5 The Unibo Proposal</h3>

<h4><a id="unibo_description" name="unibo_description"/>3.5.1 Description</h4>

<p>The Unibo proposal is described briefly in <a
href="#Ciancarini03">[Ciancarini 03]</a> and more fully in
<a href="#Gentilucci02">[Gentilucci 02]</a> (in Italian). This
description draws on both sources.</p>

<p>Ciancarini et al cite the work of Moore, Lacher and Decker, and
Ogievetsky, all of which, they claim, suffers from a common drawback,
namely the "rather awkward appearance of the documents coming out of
the conversion." The authors clearly prefer Garshol's approach, which
produces much more "readable" results and which is similar to their
own. The main difference is that Garshol does not utilize the
"standard RDF and RDFS predicates" and thus always requires a mapping
to be specified.</p>

<p>Like earlier authors, Ciancarini et al recognize that there are two
fundamental approaches to tackling the problem of translation,
corresponding to what this survey calls object mapping and semantic
mapping. The first of these is seen to be problematic in that "the
converted document is necessarily very different from the one that
would have been written directly in the destination language, and
hardly readable." The problem with the second one is that it is "not
always possible" to identify semantic equivalences, and that doing so
often requires a case-by-case approach and thus has no general
usefulness.</p>

<p>The authors therefore consider a hybrid approach to be the optimal
solution and their implementation in the Meta Converter combines a
generic mapping, which tries to stay as close as possible to the
original semantics, with the ability to define specific mappings using
an XML vocabulary. Section 3.3 of [Gentilucci 02] provides a fairly
detailed overview of the generic mapping while Chapter 4 describes the
mechanism for specific mappings.</p>

<h5><a id="unibo_identity" name="unibo_identity"/>Identity</h5>

<p>Like Garshol, Ciancarini et al assume a basic equivalence between
<i>topic</i> and <i>resource</i> (although they are less clear on the
distinction between resources and RDF nodes), but they differ in how
identity is expressed. The default behaviour in the Unibo proposal is to
equate subject locators with resource URIs and to represent subject
identifiers using the RDFS property <tt>isDefinedBy</tt>. Examples given
in <a href="#Gentilucci02">[Gentilucci 02]</a> (e.g., 3.8 and 4.2) show
how this leads to resources that clearly represent non-addressable
subjects, such as "Mario Rossi" and "Format", being translated to
addressable subjects (using <tt>&lt;resourceRef&gt;</tt> for
subjectIdentity).</p>

<p>Topics that have no subject locator are translated to blank nodes
whose ID is generated from the topic's base name. When going the other
way, the ID of a blank node becomes a topic name, which is clearly
unnatural (since the ID of a blank node and a topic name have
different semantics).</p>

<h5><a id="unibo_names" name="unibo_names"/>names</h5>

<p>The Unibo proposal is alone in assuming a fundamental equivalence
of semantics between base names and the <tt>rdfs:label</tt> property:
Names that have no variants are thus easy to handle. Variant names are
seen to represent a greater challenge which is solved through the use
of four RDF predicates: baseName, variant, parameter, and variantName.
A base name that has a variant is represented through a blank node
with <tt>rdfs:label</tt> and <tt>tm2rdf:variant</tt> properties: the
former is a literal that corresponds to the value of the topic name
(i.e., the <tt>&lt;baseNameString&gt;</tt> in XTM syntax); the value
of the latter property is another blank node that has variant and
parameter properties. Thus a topic with a base name and sort name:</p>

<pre>
[mario_rossi = "Mario Rossi";"rossi mario"]
</pre>

<p>results in the following statements:</p>

<pre>
_:mario_rossi
  tm2rdf:baseName    _:bn1_mario_rossi .

_:bn1_mario_rossi
  rdfs:label         "Mario Rossi" ;
  tm2rdf:variant     _:v11_mario_rossi .

_:v11_mario_rossi
  tm2rdf:variantName "rossi mario" ;
  tm2rdf:parameter   _:param1 .

_:param1
  rdfs:isDefinedBy   &lt;http://www.topicmaps.org/xtm/1.0/core.xtm#sort&gt; .
</pre>

<h5><a id="unibo_associations_tm2rdf" name="unibo_associations_tm2rdf"/>Associations: TM2RDF</h5>

<p>Predictably, representing associations in RDF is regarded as
difficult because of what the authors term RDF's "more primitive"
(i.e., low level) nature compared to Topic Maps. A generic translation
is possible "at the level of the model," but it is "complex and
artificial" and comes at the price of "abusing the RDF way of
expressing relationships." The basic approach is similar to
Ogievetsky's in that the roles (or "members") are contained in an RDF
bag of blank nodes. However, whereas in Ogievetsky the bag <i>is</i>
the association, the Unibo proposal uses an additional resource to
represent the association; this resource has a
<tt>tm2rdf:association</tt> property, the object of which is the bag
of members. All in all, nine RDF statements are required to represent
a single binary association.</p>

<p>The <tt>tm2rdf:association</tt> property is characterized as a
"supporting predicate" whose purpose is to "add a little legibility" to
the resulting document. A variation on this is also suggested in which
the bag of members and the association become a single node: This is
effectively the same solution as Ogievetsky's.</p>

<p><a href="#Gentilucci02">[Gentilucci 02]</a> also describes two
alternative approaches in which n-ary associations are decomposed into a
number of binary relations. Both of these require six RDF statements in
order to represent a single ternary association. Given the following
association:</p>

<pre>
X( A : rA , B : rB , C : rC )
</pre>

<p>(i.e. an association of type X between topics A, B, and C playing the roles rA, rB, and rC respectively), the first of these alternative approaches results in the following six statements:</p>

<pre>
A X B .   A X C .   B X A .   B X C .   C X A .   C X B .
</pre>

<p>Role types are lost. In addition, the fact that each pair of role
players is related through the same predicate twice (both as subject and
object and as object and subject) means that only symmetrical
relationships would be represented correctly. Finally, the semantic of
A, B, and C all being involved in the <i>same</i> relationship is also
lost; this may or may not involve real loss of information depending on
the nature of the relationship.</p>

<p>The second alternative approach involves predicates that correspond
to role types and results in the following statements:</p>

<pre>
B rA A .   C rA A .   A rB B .   C rB B .  A rC C .   B rC C .
</pre>

<p>While role types are now preserved, the association type is lost
(although it could in theory be preserved through additional statements
relating it to rA, rB, and rC). In addition, it seems doubtful that the
original semantics are correctly preserved. For example: Can it be
assumed to be the case that the relationship between role players B and
A (rA) is the same as that between C and A? Finally, the point made
above about losing the semantic of the involvement of A, B, and C in the
<i>same</i> relationship also pertains here.</p>

<p>Having considered these alternatives, the Unibo proposal comes down
in favour of the approach that uses the <tt>tm2rdf:association</tt>
property, at least in the absence of more specific mapping
information.</p>

<h5><a id="unibo_associations_rdf2tm" name="unibo_associations_rdf2tm"/>Associations: RDF2TM</h5>

<p>When translating in the opposite direction, from RDF to Topic Maps,
the generic solution proposed by Unibo is to translate RDF statements
to associations. The example given in <a
href="#Gentilucci02">[Gentilucci 02]</a> results in a typed binary
association with untyped roles and does not take into consideration
the case in which the object of the RDF statement is a literal.
However, it is conceded that "it might be preferable, in certain
contexts, to apply other types of conversion" and this leads into a
discussion of "attributes" and the role of schema information.</p>

<p>The Unibo proposal recognizes that certain RDF statements are more
appropriately mapped to either internal or external occurrences, with
the occurrence type corresponding to the property of the statement,
but knowing when to do this requires some kind of schema information.
This is essentially the same as Garshol's approach, except for the
fact that Unibo uses an XML vocabulary rather than an RDF vocabulary
to specify the mapping information.</p>

<h5><a id="unibo_scope" name="unibo_scope"/>Scope</h5>

<p>In this context a proposal is put forward for representing scoped
occurrences in RDF: An <tt>rdfs:seeAlso</tt> property has a blank node
as its object; the blank node has an <tt>rdfs:isDefinedBy</tt> property
(whose object is the URI of an external occurrence) and one or more
<tt>tm2rdf:scope</tt> properties. This results in a construct whose
"shape" is very different from that of an unscoped occurrence. In
addition, given that the range of the <tt>rdfs:isDefinedBy</tt> property
is <tt>rdf:Resource</tt>, it is unclear how this approach would work
with internal occurrences.</p>

<p>A "not very elegant" way to represent scoped names is suggested that
involves defining a property, whose <tt>rdf:type</tt> is
<tt>tm2rdf:baseName</tt>, that corresponds either directly or
indirectly (it is not clear which) to each scoping topic. In addition
to being inelegant, this would not work with scopes comprised of
multiple scoping topics. The alternative is the same as that proposed
by Garshol: i.e., to qualify reified statements. To do this, Unibo
defines the <tt>tm2rdf:scope</tt> property.</p>

<p>For scoped associations, reification in the RDF sense is not
necessary since associations are already represented as resources (at
least in the default mapping). Thus, all that is required is to assign
one or more <tt>tm2rdf:scope</tt> properties to that resource. The
downside to this is that scoping is now handled in three different
ways (for generically mapped associations, for occurrences, and for
names and specifically mapped associations, respectively).</p>

<h5><a id="unibo_reification_typing_subtyping" name="unibo_reification_typing_subtyping"/>Reification, typing, and subtyping</h5>

<p>Neither reification, typing, or subtyping are regarded by Unibo as
posing problems since both RDF and Topic Maps support all three
concepts in essentially the same way: <tt>instanceOf</tt> equates to
<tt>rdf:type</tt>; the supertype-subtype relationship (represented in
Topic Maps using an association with a predefined type) equates to
<tt>rdfs:subClassOf</tt>, and reification is essentially the same in
Topic Maps and RDF.</p>

<h5><a id="specific_mappings" name="specific_mappings"/>Specific mappings</h5>

<p>The description above has focused on the Unibo proposal's approach
to generic translations. However, it is recognized that a generic
approach will not always produce optimal results and so a method is
provided for "guiding" the translation process. This consists of a
simple XML vocabulary that allows the user to specify how to translate
a (binary) association to a single RDF statement (and vice versa). As
in the Garshol proposal, this involves specifying correspondences
between association role types and the statement's subject and object.
In addition, a user can specify which RDF properties should be mapped
to occurrences rather than to associations. The following extract
shows how mappings for the TM2RDF test case would be specified:</p>

<pre>
&lt;?xml version="1.0"?&gt;
&lt;xtm2rdf&gt;
  &lt;property_associations&gt;
    &lt;li id="composed-by"&gt;
      &lt;domain_role id="work"/&gt;
      &lt;range_role id="composer"/&gt;
    &lt;/li&gt;
  &lt;/property_associations&gt;
  &lt;property_occurrences&gt;
    &lt;li id="premiere-date"/&gt;
    &lt;li id="synopsis"/&gt;
  &lt;/property_occurrences&gt;
&lt;/xtm2rdf&gt;
</pre>

<p>These mappings would cause the <tt>composed-by</tt> association to be
represented as a single statement in RDF, with Tosca ("work" = domain)
as the subject and Puccini ("composer" = range) as object. In addition,
the mapping contains information that would cause properties of type
<tt>premiere-date</tt> and <tt>synopsis</tt> to be mapped to occurrences
when going from RDF to Topic Maps. (Although not stated explicitly, this
information is presumably not required when going the other way.)</p>

<h4><a id="unibo_summary" name="unibo_summary"/>3.5.2 Summary</h4>

<p>The Unibo proposal is fairly complete but some features, e.g.,
language tags and data typing in RDF, and reification of roles and
topic maps, are not covered explicitly. The proposal permits some
degree of reversibility, but the result of a roundtrip may not always
be the same as the starting point. For example, using the generic
mappings, most RDF statements would be translated to typed
associations with untyped roles, each of which would result in several
statements when translated back to RDF.</p>

<p>The approach produces somewhat natural results in both directions
provided mapping information is supplied. Generic translations are far
less satisfactory, with a single binary association resulting in nine
RDF statements.</p>

<h4><a id="unibo_test_cases" name="unibo_test_cases"/>3.5.3 Test cases</h4>

<h5><a id="unibo_tm2rdf" name="unibo_tm2rdf"/>TM2RDF</h5>

<p>The source document was translated using the tool Meta (<a
href="#Gentilucci02">[Gentilucci 02]</a>) with the default settings.
The resulting document was then converted to N3 format using the
Mindswap RDF Converter <a href="#Mindswap02">[Mindswap 02]</a>, and
finally tidied by hand in order to ease comparison with the source
document.</p>

<pre>
@prefix : &lt;#&gt; .
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt; .
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt; .
@prefix s: &lt;http://cs.unibo.it/meta/tmschema.rdf#&gt; .

# tosca: type, name, occurrences
:tosca rdf:type :opera;
  rdfs:label "Tosca";
  rdfs:seeAlso :dataOccurrence_7a34558a,
               :dataOccurrence_d5a519a2 .

:dataOccurrence_7a34558a rdf:type :premiere-date;
  rdfs:label "1900-01-14" .

:dataOccurrence_d5a519a2 rdf:type :synopsis;
  rdfs:isDefinedBy &lt;http://www.azopera.com/learn/synopsis/tosca.shtml&gt; .

# puccini: type, name
:puccini rdf:type :person;
  rdfs:label "Giacomo Puccini" .

# association
:x1ko2ljned-b rdf:type :composed-by;
  s:association :members_x1ko2ljned-b .
:members_x1ko2ljned-b rdf:type rdf:Bag;
  rdf:_1 :x1ko2ljned-b_1;
  rdf:_2 :x1ko2ljned-b_2 .
:x1ko2ljned-b_1 rdf:type :composer;
  rdfs:isDefinedBy :puccini .
:x1ko2ljned-b_2 rdf:type :work;
  rdfs:isDefinedBy :tosca .

# typing topics
:opera rdf:type rdfs:Class;
  rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#opera&gt;;
  rdfs:label "Opera" .

:person rdf:type rdfs:Class;
  rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#person&gt;;
  rdfs:label "Person" .

:composed-by rdf:type rdfs:Class;
  rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#composed-by&gt;;
  rdfs:label "Composed by" .

:premiere-date rdf:type rdfs:Class;
  rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#premiere-date&gt;;
  rdfs:label "Premiere date" .

:synopsis rdf:type rdfs:Class;
  rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#synopsis&gt;;
  rdfs:label "Synopsis" .

:composer rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#composer&gt;;
  rdfs:label "Composer" .

:work rdfs:isDefinedBy &lt;http://psi.ontopia.net/music/#work&gt;;
  rdfs:label "Work" .
</pre>

<p>38 statements are required to represent what would naturally be
expressed as 12 statements in RDF. Much of the additional baggage is
due to the use of nine statements to represent the association between
Tosca and Puccini; specifying that the five typing topics are
instances of <tt>rdfs:Class</tt>; requiring an additional statement
for each subject identifier; and expressing occurrences via a blank
node.</p>

<p>The amount of additional baggage would be reduced somewhat
(although not completely) if Meta's ability to express additional
mapping information were used.</p>

<h5><a id="unibo_rdf2tm" name="unibo_rdf2tm"/>RDF2TM</h5>

<p>The result of this test case as delivered by the developers of Meta
seems to be in error. Among other things, the topic Puccini is missing
altogether. The editors have reported this to the developers and if
their assumption is correct the test case will be updated in the next
draft of this Survey.</p>

<pre>
[ass-ins_1 : opera = "Tosca"]
{ass-ins_1, premiere-date, "1900-01-14"}

[tosca @"http://www.azopera.com/learn/synopsis/tosca.shtml"]

synopsis( ass-ins_1, tosca )

[opera : class = "Opera" @"http://psi.ontopia.net/music/#opera"]
[composer : class = "Composer" @"http://psi.ontopia.net/music/#composer"]
[premiere-date : occurrence = "Premiere date" @"http://psi.ontopia.net/music/#premiere-date"]
[synopsis : association = "Synopsis" @"http://psi.ontopia.net/music/#synopsis"]
[composed-by : association = "Composed by" @"http://psi.ontopia.net/music/#composed-by"]

[class @"http://www.topicmaps.org/xtm/1.0/core.xtm#class"]
[association @"http://www.topicmaps.org/xtm/1.0/core.xtm#association"]
[occurrence @"http://www.topicmaps.org/xtm/1.0/core.xtm#occurrence"]
</pre>

<hr/>

<h3><a id="other_proposals" name="other_proposals"/>3.6 Other Proposals and Contributions</h3>

<p>The preceding sections have described the five most relevant
proposals for RDF/TM interoperability. A number of other proposals and
contributions have also been considered:</p>

<p>Both <a href="#Vlist01">[Vlist 01]</a> and <a
href="#Prudhommeaux02">[Prudhommeaux 02]</a> are early "first cuts"
(produced "before breakfast" and as "an evening's work" respectively).
Both are very incomplete and have been superseded by later work; they
are mentioned here for the sake of completeness.</p>

<p><a href="#Garshol02">[Garshol 02]</a> is a complete RDF Schema for
Topic Maps based on an early version of <a href="#TMDM">[TMDM]</a>. It
is similar to the Stanford and Ogievetsky proposals in that it models
Topic Maps in RDF and falls therefore into the general category of
object mappings which the author himself has since rejected. Its
principal interest lies in the fact that it is based on a more
complete and consistent model than that of PMTM4 and it will therefore
be used to illustrate the difference between object mappings and
semantic mappings in the next section.</p>

<p><a href="#Kaminsky02">[Kaminsky 02]</a> presents a conceptual
metamodel called <i>Braque</i> that is characterized by the author as
being a "superset of the most popular proposed semantic web
metamodels" (viz. XML, RDF, and Topic Maps), and defines
transformations from each of these into <i>Braque</i>. Kaminsky's work
is clearly of great interest to anyone seeking to <i>unify</i> RDF and
Topic Maps into a single model. However, that is not the mandate of
the RDFTM task force. Kaminsky's proposal cannot be considered as
a solution to the more immediate problem of interchanging RDF and
Topic Maps data, since no transformations <i>out</i> of <i>Braque</i>
are defined. <a href="#Kaminsky02">[Kaminsky 02]</a> is therefore
considered to be out of scope for the current work.</p>

<p><a href="#Pepper03">[Pepper 03]</a> provides an in-depth discussion
of identifiers in RDF and Topic Maps and is thus relevant to the issue
of identity discussed below. The authors' main goal is to clarify the
distinction between direct and indirect identification of subjects,
and to pinpoint the lack of an ontological distinction between
"resources" (in general) and "information resources" (which are a
subset of "resources"). Direct identification is possible only for
information resources; indirect identification is possible for any
kind of resource (including information resources). With the
publication of <a href="#TAG">[TAG]</a>, and the introduction of the
formal concept of <i>information resource</i> in the architecture of
the World Wide Web, these distinctions have now been recognized and
this could pave the way to solving the issue of identity, at least as
far as RDF and Topic Maps interoperability is concerned.</p>

<p><a href="#Vatant04">[Vatant 04]</a> investigates how OWL (Web
Ontology Language) may be used to constrain topic maps and has
relevance for the expression of additional information that may be
used to guide a translation. This will be more pertinent to the
Guidelines to be developed on this basis of the current survey.</p>

<hr/>
</div>

<div class="section" >

<h2><a id="analysis" name="analysis"/>4 Analysis</h2>

<p>This chapter provides a general analysis based on the preceding
discussion of existing proposals for translating data between RDF and
Topic Maps.</p>

<p>The first point to be noted is that all of the major proposals
suffer from the fact that neither Topic Maps nor RDF had stable,
formalized data models at the time they were written. PMTM4 never had
any official standing and has since been superseded by the <a
href="#TMDM">[TMDM]</a>, part 2 of the forthcoming revised Topic Maps
standard. In the case of RDF, <a
href="#RDF-Semantics">[RDF-Semantics]</a> and <a href="#OWL">[OWL]</a>
first appeared in 2004. Now that these formal models exist, it should
be possible to define complete and correct mappings at either the
object or the semantic level.</p>

<h3><a id="object_mappings_and_semantic_mappings" name="object_mappings_and_semantic_mappings"/>4.1 Object mappings and semantic mappings</h3>

<p>All the existing approaches fall into two distinct categories that
Moore originally termed "modelling the model" and "mapping the model".
Following the terminology of Lacher and Decker these might be more
appropriately termed "object mappings" and "semantic mappings"
respectively. The basic difference between the two approaches can be
summed up as follows:</p>

<ul>
<li><p>Object mappings use the low-level building blocks of one
language to describe the <i>object model</i> of the other. For
example, assuming for now that the structure of a simple binary
associations data model is a quintuple, consisting of one
(a)ssociation, two (r)oles, and two role (p)layers (p-r-a-r-p), that
association would be represented using an object mapping as four
statements that relate five resources.</p></li>

<li><p>Semantic mappings start from higher level concepts that carry
the semantics of each model and attempt to find equivalences between
them. A binary association in Topic Maps would be seen to represent
the same kind of "thing" that is often represented by an RDF statement
(i.e., a relationship between two entities) and would therefore be
represented using a single RDF statement. Where no direct semantic
equivalent can be found, the missing semantics are defined using the
facilities available in one of the two paradigms, i.e., classes,
properties, or published subjects.</p></li>
</ul>

<p>The advantage of an object mapping is that it is easy to make it
generic (provided, of course, that the object model on which it is
based is complete) and this ensures completeness without any
additional effort. The disadvantage is the unnaturalness of the
result. Semantic mappings yield much more natural results but suffer
from the disadvantage that genericity is much harder to ensure and may
in some cases require additional information not always present in the
source document.</p>

<p>Of the existing proposals, Stanford and Ogievetsky both use object
mappings based on <a href="#PMTM4">[PMTM4]</a>. Moore discusses both
an object mapping (based on his own inaccurate models) and a semantic
mapping. Garshol dismisses object mappings and concentrates solely on
semantic mappings. Unibo attempts to combine both approaches in order
to achieve the dual goals of a default, generic mapping that can be
used without additional information, and a method for providing
specific mapping information in cases where a more natural translation
is required.</p>

<h3><a id="naturalness" name="naturalness"/>4.2 The importance of naturalness</h3>

<p>The notion of "naturalness" was defined in <a
href="#translation_features">section 2.1</a> as follows:</p>

<blockquote>
<p>The criterion <i>naturalness</i> expresses the degree to which the
results of a translation correspond to the way in which someone
familiar with the target paradigm would naturally express the
information content in that paradigm. Naturalness normally also
confers improved <i>readability</i> on the result.</p>
</blockquote>

<p>Naturalness is extremely important because the result of an
"unnatural" translation is <i>structurally different</i> from data
that was originally created in the target model. This has the
following consequences, all of which lead to reduced
interoperability:</p>

<ul>
<li>the result will not merge cleanly with data originating in the
target model,</li>
<li>the result will not conform to vocabularies created in the target
model, and</li>
<li>queries written against the target model will not work with
translated data.</li>
</ul>

<p>Object mappings generally rate very low on naturalness and are
therefore subject to all three of these failings. As an example,
consider the following topic map:</p>

<pre>
{tosca, music:premiere-date, [[1900-01-14]]}
</pre>

<p>This defines an occurrence of type <tt>music:premiere-date</tt> whose
value is "1900-01-14". A semantic mapping to RDF would result in the
following translation:</p>

<pre>
_:a0  music:premiere-date  "1900-01-14" .
</pre>

<p>An object mapping would look as follows:</p>

<pre>
_:a1, rdf:type, tm:Topic .
_:a1, tm:occurrence, _:a2 .
_:a2, rdf:type: tm:Occurrence .
_:a2, tm:occurrence-type, _:a3 .
_:a3, tm:subject-identifier, music:premiere-date .
_:a2, tm:resource, "1900-01-14" .
</pre>

<p>This example uses the vocabulary defined in <a
href="#Garshol02">[Garshol 02]</a> that is based on <a
href="#TMDM">[TMDM]</a>, in order to conform to the most standard data
model for Topic Maps. It serves to illustrate the fact that object
mappings are inherently more verbose than semantic mappings. They also
involve a significant amount of indirection and can thus be expected
to lead to a lot of processing overhead. Even more important is that
the <i>semantics</i> are actually different. The result of an object
mapping consists of constructs that carry Topic Maps semantics (such
as "topic", "occurrence", "occurrence type", etc.) which RDF
processors are required to understand in order to be able to process
the result correctly.</p>

<p>As an example, consider merging the results of semantic and object
mappings respectively with native RDF data that includes the following
statement:</p>

<pre>
_:b0  music:premiere-date  "1900-11-10" .
</pre>

<p>This statement asserts that some resource had its premiere date on
1900-11-10. A merged result that used the semantic mapping would look as
follows:</p>

<pre>
_:a0  music:premiere-date  "1900-01-14" .
_:b0  music:premiere-date  "1900-11-10" .
</pre>

<p>This would be easily queryable (for example for all premi&#232;res that
took place in the year 1900) in terms of the <tt>music</tt> vocabulary
alone. Contrast this with the following result of merging where one of
the components is based on an object mapping:</p>

<pre>
_:a1, rdf:type, tm:Topic .
_:a1, tm:occurrence, _:a2 .
_:a2, rdf:type: tm:Occurrence .
_:a2, tm:occurrence-type, _:a3 .
_:a3, tm:subject-identifier, music:premiere-date .
_:a2, tm:resource, "1900-01-14" .
_:b0  music:premiere-date  "1900-11-10" .
</pre>

<p>This would clearly be much harder to query and would require
knowledge of the <tt>tm</tt> vocabulary in addition to the
<tt>music</tt> vocabulary. The very complexity of the queries given by
Lacher and Decker, and Ogievetsky, respectively, speaks volumes in
this regard.</p>

<p>Given the importance of naturalness it would seem to make sense to
prefer a semantic mapping, provided that a sufficient degree of
completeness can be achieved. The following section therefore looks at
the issues involved in defining semantic mappings with a particular
emphasis on determining whether the existence of formal data models
for Topic Maps and RDF now makes it possible to ensure completeness as
well as naturalness.</p>

<h3><a id="semantic_mapping_issues" name="semantic_mapping_issues"/>4.3 Semantic mapping issues</h3>

<h4><a id="identity" name="identity"/>4.3.1 Identity</h4>

<p>Although both RDF and Topic Maps use URIs as identifiers, they
differ crucially in that Topic Maps offers <i>two</i> modes of
identification, direct (using subject locators) and indirect (using
subject identifiers), whereas RDF offers only one. This prompts the
question, which Topic Maps construct(s) should be regarded as being
semantically equivalent to the URI of an RDF resource? Subject
identifiers, subject locators, ... or both?</p>

<p>Since identifiers are not part of the PMTM4 model, this issue is
simply ignored in the Stanford proposal. Moore's position is not
stated explicitly, but the examples he gives indicate that subject
identifiers, at least, are regarded as equivalents. Both Ogievetsky
and Unibo favour subject locators and define a separate property for
handling subject identifiers. Garshol translates URIs to subject
identifiers when going from RDF to Topic Maps, but is more agnostic
when going the other way, translating <i>both</i> subject identifiers
<i>and</i> subject locators to URIs.</p>

<p>There are problems with all of these approaches. Clearly,
identifiers have to be mapped somehow, otherwise there will be loss of
information. Equating URIs in RDF with subject locators is problematic
in several ways. Firstly it leads to incorrect semantics (as the
description of the Unibo proposal shows). Secondly, the result is less
natural (since the identifier of a non-addressable subject like
Puccini will not be treated as the URI of the corresponding resource,
as would be most natural in RDF). Finally, the identifiers of
occurrence types and association types (which are typically subject
identifiers) could not be used as the URIs of RDF properties.</p>

<p>Equating URIs with subject identifiers rather than subject locators
also yields unnatural results, since the identifier of an addressable
subject (i.e., an information resource) will not become the URI of the
corresponding resource, as would be most natural in RDF. However, this
alternative does not exhibit the other problems that result from
favouring subject locators.</p>

<p>There is a dilemma here and Garshol's agnosticism is in some ways a
recognition of it. As a result, his TM2RDF translations exhibit the
highest degree of naturalness as far as identity is concerned.
Unfortunately he loses the information about whether the URI
originated in a subject identifier or a subject locator and is thus
reduced to translating every URI to a subject identifier when going
the other way. This leads to problems with round-tripping, as noted
above.</p>

<p>The ideal solution would be to allow <i>either</i> subject
identifiers <i>or</i> subject locators to be regarded as URIs (and
vice versa), but at the same time to retain sufficient information
when going from Topic Maps to RDF to be able to perform
round-tripping. The recognition in <a href="#TAG">[TAG]</a> of the
distinction between resources in general and information resources,
and the insights in <a href="#Pepper03">[Pepper 03]</a>, may provide
the foundation for such a solution.</p>

<p>The issue of multiple identifiers is treated explicitly by Garshol
only. For those proposals that regard the subject locator as the
semantic equivalent of a resource's URI and define a custom property
for subject identifiers (Ogievetsky and Unibo), this was a non-issue
as long as topics could only have one subject locator. However, in the
forthcoming version of ISO 13250 multiple subject locators will be
allowed and then the issue will have to be faced explicitly. Garshol's
proposal to use equivalence properties defined in OWL (i.e.,
<tt>owl:sameAs</tt>, <tt>owl:equivalentClass</tt>, and
<tt>owl:equivalentProperty</tt>) should clearly be investigated in more
detail since such an approach is likely to lead to increased
interoperability between RDF and Topic Maps.</p>

<h4><a id="names" name="names"/>4.3.2 Names</h4>

<p>In RDF the name of a resource is usually represented by a single
statement. ("Name" is here defined to mean a label used by a human to
name a subject.) RDF Schema defines a property for this purpose
(<tt>rdfs:label</tt>) but many vocabularies define their own
properties (e.g., <tt>dc:title</tt>, <tt>foaf:name</tt>, etc.). An
accurate semantic mapping from Topic Maps can be achieved by
translating base names to such properties.</p>

<p>Both Garshol and Unibo take this approach, differing only in that
Unibo always maps a base name to <tt>rdfs:label</tt> (and vice versa),
while Garshol allows base names (including scoped base names) to be
mapped to other properties. It should be noted that both proposals were
written before the introduction of typed names in the Topic Maps model
so neither can be considered a complete solution today.</p>

<p>In Topic Maps a base name can have variants. These are alternative
forms of a name that are intended to be used in specific processing
contexts, such as sorting and display. Of the semantic mapping
proposals, only Unibo provides a solution for handling variant names;
this is done by representing names that have variants as complex
objects, an approach that seems sound enough, except for the
introduction of what appears to be a superfluous blank node as the
value of the <tt>tm2rdf:parameter</tt> property.</p>

<h4><a id="binary_relationships" name="binary_relationships"/>4.3.3 Binary relationships</h4>

<p>Representations of binary relationships have somewhat different
topographies in RDF and Topic Maps. RDF uses a single statement (or
sometimes two statements that are the inverse of each other), in which
the subject and object represent the two resources that participate in
the relationship. The nature of those two resources' involvement in
the relationship can be adduced from their positions as subject and
object.</p>

<p>In Topic Maps there is no concept of subject and object in a binary
association because the association has no direction. The nature of
the two participating topics' involvement in the relationship is
stated explicitly through their <i>role types</i>.</p>

<p>The challenge when translating from Topic Maps to RDF is to know
which role-playing topic should become the subject of the resulting
statement and how to preserve the role types. When going from RDF to
Topic Maps, the challenge is to know which role types to assign to the
subject and object of the statement respectively and how to preserve
knowledge of what the subject and object were.</p>

<p>Both Garshol and Unibo solve this by allowing additional information
to be provided that allows the RDF subject and object to be connected
with their respective role types. Unibo uses a single XML vocabulary
that is external to the document being translated. Garshol uses an RDF
vocabulary for going from RDF to Topic Maps, and a set of Published
Subjects for going from Topic Maps to RDF. Garshol's approach has the
advantage of allowing source documents to be self-describing (the
mappings can be included in the source documents or their schemas). The
disadvantage of Garshol is the use of two different vocabularies, one
for each direction. A cleaner solution would be to use a single
vocabulary.</p>

<p>In the absence of additional information, Unibo falls back to an
object mapping that requires nine RDF statements to represent a single
binary association. Garshol, on the other hand, performs a semantic
mapping anyway, using the predefined classes <tt>subject</tt> and
<tt>object</tt> when going from RDF to Topic Maps, and selecting a
role-player at random to be the subject of the resulting statement
when going from Topic Maps to RDF. As currently implemented this leads
to loss of information and the inability to perform round-tripping.
However, it is perfectly feasible for the latter translation to retain
the information necessary to perform round-tripping (in the form of an
annotation to the schema using Garshol's own RTM vocabulary).</p>

<h4><a id="non-binary_relationships" name="non-binary_relationships"/>4.3.4 Non-binary relationships</h4>

<p>One major difference between the models of RDF and Topic Maps is
that the latter permits non-binary relationships to be expressed
directly: An association may have one, two, or more role players. In
RDF on the other hand the base model permits only binary
relationships.</p>

<p>Most of the existing proposals for translating associations with
more than two role-players are unsatisfactory, since they result in a
large number of RDF statements. <a href="#Noy04">[Noy 04]</a> proposes
patterns for representing n-ary relations in RDF in which the relation
is "re-represented" as a class rather than a property. Each such
pattern requires <i>n</i> statements in order to express the
relationship. Using the example given in <a href="#unibo_description">section
3.5.1</a> the result would be one of the following, depending on the
pattern used (<tt>P</tt> stands for the re-represented relation):</p>

<pre>
P rdf:type X .   P rA A .   P rB B .   P rC C .   # Pattern 2
P rdf:type X .   A rA P .   P rB B .   P rC C .   # Pattern 1
</pre>

<p>The first of these (labelled "Pattern 2") is identical to Garshol's
proposal for n-ary associations. If such patterns are adopted in the
RDF community it would seem to be advisable, in the interest of
compatibility, to follow them as closely as possible when translating
n-ary associations from Topic Maps to RDF.</p>

<p>Topic Maps also permits unary associations, i.e. "relationships"
that only involve a single role player. Although seldom used, they do
occur occasionally in order to express the equivalent of boolean
properties (which might be regarded as binary relationships in which
one of the role players is the subject "true"). The following example
from <a href="#Pepper05">[Pepper 05]</a> asserts that the opera
<i>Turandot</i> is unfinished:</p>

<pre>
unfinished( turandot : work )
</pre>

<p>None of the existing semantic mapping proposals caters explicitly
for unary associations.</p>

<h4><a id="occurrences" name="occurrences"/>4.3.5 Occurrences</h4>

<p>Both Garshol and Unibo recognize that occurrences are most naturally
represented as single RDF statements where the property corresponds to
the occurrence type. Internal and external occurrences correspond to
statements whose objects are literals and resources respectively. Going
from Topic Maps to RDF presents no problems at all; going the other way
seems to require additional information in order to distinguish an
internal occurrence from a name, and an external occurrence from an
association or identifier.</p>

<p>It is unclear how Unibo behaves in the absence of additional mapping
information. The default in Garshol (at least as implemented in the
<i>Omnigator</i> is to translate statements whose objects are literals
to internal occurrences and statements whose objects are resources to
associations.</p>

<h4><a id="types_and_subtypes" name="types_and_subtypes"/>4.3.6 Types and subtypes</h4>

<p>Garshol and Unibo agree on the fundamental semantic equivalence
between the concept of type-instance in <a href="#TMDM">[TMDM]</a> and
<tt>rdf:type</tt>, on the one hand; and between supertype-subtype and
<tt>rdfs:subClassOf</tt> on the other. In addition, association types
and occurrence types are regarded as equivalent to RDF properties.
Role types present particular problems, as discussed above, and name
types, as already noted, did not exist at the time the proposals were
written.</p>

<h4><a id="reification" name="reification"/>4.3.7 Reification</h4>

<p>Only Garshol and Unibo mention reification and neither proposal
regards it as being problematic. In actual fact, Unibo only talks
explicitly about the reification of associations, while Garshol
mentions reified names, occurrences, and associations. Neither
proposal covers the reification of topic maps and association
roles.</p>

<h4><a id="scope" name="scope"/>4.3.8 Scope</h4>

<p>The concept of scope is peculiar to Topic Maps and has been
regarded as one of the major stumbling blocks for RDF/Topic Maps
interoperability. All the existing proposals discuss the issue in one
form or another but only Garshol and Unibo do so in terms of its
semantics, i.e., as a way to express the contextual validity of an
assertion. Garshol makes the point that scope is most properly
regarded as a special kind of assertion made about another assertion.
Since assertions about assertions are handled through reification in
both paradigms, and reification translates rather easily, Garshol
proposes to translate scope using reification together with a property
that captures the semantics of contextual validity.</p>

<p>Garshol treats scoped base names as a special case, however, and
allows a base name in a particular scope to be translated to a
specific property. For example, a base name in the scope 'nickname'
might be translated using the <tt>foaf:nick</tt> property. While this
undoubtedly yields more natural results (much more natural than
translating to, say, a reified <tt>rdfs:label</tt> statement with an
<tt>rdftm:scoped-by</tt> property), such special-casing introduces a
degree of inconsistency in the handling of scope. Why should only base
names be treated in this way? Why not associations and occurrences as
well?</p>

<p>The answer may be that associations and occurrences have types
whereas names do not (or did not, until recently). It could be argued
that the lack of typed names in Topic Maps has led to scoped names
being used in ways that distort the semantics of scope. Or, to put it
another way: Given that the forthcoming revised Topic Maps standard
will permit typed names, would it be more appropriate to represent a
nickname as a name of type 'nickname' (or <tt>foaf:nick</tt>) rather
than a name in the scope 'nickname'? If so, it would be possible to
avoid treating scoped names as a special case and still obtain natural
results.</p>

<p>Unibo handles scope in three different ways (one of which involves
reification) depending on the kind of construct in question. This is
clearly even more inconsistent, and it is probably also unnecessary
since the reification approach seems to be usable for scoping any kind
of topic characteristic.</p>

<h4><a id="other_issues" name="other_issues"/>4.3.9 Other issues</h4>

<p>None of the existing proposals discuss how to represent RDF
containers and collections, language tags, XML literals or typed
literals in Topic Maps. Of these issues, the latter two are addressed
by recent datatyping extensions to the Topic Maps model. Language
tagging can be seen as a kind of contextual information akin to scope
and treated accordingly. Containers and collections may or may not
require special treatment: Since they are expressed using the
fundamental building blocks of RDF (nodes and arcs), they may be
represented using associations in Topic Maps. The semantics would not
be lost and could be recovered when round-tripping. However, they would
not be "visible" in terms of some equivalent Topic Maps construct.</p>

<hr/>
</div>

<div class="section" >

<h2><a id="conclusion" name="conclusion"/>5 Conclusion</h2>

<p>The main result of this document is the identification and
comparison of five different proposals addressing a number of issues
related to data interoperability and translation between RDF and Topic
Maps.</p>

<p>Among the several possible criteria for evaluating these proposals,
two, completeness and naturalness, have been selected as the most
relevant and appropriate for evaluating the qualities and limitations
of each proposal. <i>Completeness,</i> defined as the extent to which
any semantic structure in the source model is correctly (i.e., without
losing or adding information) translated into the destination model,
provides a clear indication of the semantic power of each translation
approach. <i>Naturalness,</i> defined as the extent to which a
translated model resembles in structure and content an equivalent
model expressed directly in the target paradigm, provides an
indication of the level of integration that each approach offers for
the translated result to merge and interact with other models
expressed in the same paradigm.</p>

<p>The analysis of the proposals identified two main approaches
towards translation, which we dubbed "object mapping" (providing a
translation of every structural component of the source paradigm) and
"semantic mapping" (providing a structure corresponding to every
conceptual structure of the source model). Although it is not the
purpose of this document to provide suggestions and guidelines for
translation paths between RDF and Topic Maps, the relative merits of
semantic mapping over object mapping are clearly apparent and strongly
imply that further guidelines pursue semantic mapping as the basis of
any recommended approach to translation.</p>

<p>A number of outstanding issues need to be considered when providing
a semantic mapping of the two paradigms, including identity,
non-binary associations, roles, etc. Furthermore, semantic mapping has
constraints in its applicability when the source model uses constructs
that are not directly mappable into the target paradigm. In this case,
two possible approaches can be foreseen, each championed by one of the
two most recent proposals: Each asks the user for additional
information for disambiguating these structures, but Garshol
<i>requires</i> this to be provided (at least when going from RDF to
Topic Maps), while Unibo falls back to object mapping in this
case.</p>

<p>The analysis of the options and solutions provided in literature,
therefore, clearly shows the advantages of semantic mapping, but at
the same time lists the issues that need to be addressed and solved in
any future translation approach. However, now that both RDF and Topic
Maps have formal data models, and with the help of RDF Schema and OWL,
it seems likely that most, if not all, of the issues we have listed
here can be resolved without resorting to the restricted
interoperability offered by object mapping.</p>

<hr/>
</div>

<!-- ACKNOWLEDGEMENTS SECTION -->
<div class="section" >

<h2><a id="acknowledgements" name="acknowledgements"/>Acknowledgements</h2>

<p>The editors wish to thank Nikita Ogievetsky for providing the test
case result in <a href="#ogievetsky">section 3.3</a>, and
Natasha Noy, Mike Uschold, David Wood, and Ralph Swick of the Semantic
Web Best Practices and Deployment Working Group for reviewing earlier
versions of this document.</p>

<hr/>
</div>

<!-- REFERENCES SECTION -->
<div class="section" >

<h2><a id="references" name="references"/>References</h2>

<dl>
<dt id="Ciancarini03"><b>[Ciancarini 03]</b></dt>
<dd>Ciancarini, Paolo; Gentilucci, Riccardo; Pirruccio, Marco; Presutti, Valentina; Vitali, Fabio: <i>Metadata on the Web: On the integration of RDF and Topic Maps</i>, <a href="http://www.idealliance.org/papers/extreme03/html/2003/Presutti01/EML2003Presutti01.html">http://www.idealliance.org/papers/extreme03/html/2003/Presutti01/EML2003Presutti01.html</a> (2003)</dd>

<dt id="Garshol01"><b>[Garshol 01]</b></dt>
<dd>Garshol, Lars Marius: <i>Topic maps, RDF, DAML, OIL: A comparison</i>, <a href="http://www.ontopia.net/topicmaps/materials/tmrdfoildaml.html">http://www.ontopia.net/topicmaps/materials/tmrdfoildaml.html</a> (2001)</dd>

<dt id="Garshol02"><b>[Garshol 02]</b></dt>
<dd>Garshol, Lars Marius: <i>An RDF Schema for topic maps</i>, <a href="http://psi.ontopia.net/rdf/">http://psi.ontopia.net/rdf/</a> (2002)</dd>

<dt id="Garshol03a"><b>[Garshol 03a]</b></dt>
<dd>Garshol, Lars Marius: <i>Living with Topic Maps and RDF</i>, <a href="http://www.ontopia.net/topicmaps/materials/tmrdf.html">http://www.ontopia.net/topicmaps/materials/tmrdf.html</a> (2003)</dd>

<dt id="Garshol03b"><b>[Garshol 03b]</b></dt>
<dd>Garshol, Lars Marius: <i>The RTM RDF to topic maps mapping: Definition and introduction</i>, <a href="http://www.ontopia.net/topicmaps/materials/rdf2tm.html">http://www.ontopia.net/topicmaps/materials/rdf2tm.html</a> (2003)</dd>

<dt id="Gentilucci02"><b>[Gentilucci 02]</b></dt>
<dd>Gentilucci, Riccardo; Pirruccio, Marco: <i>Metainformazioni sul World Wide Web: Conversione di formato e navigazione</i>, University of Bologna, Masters Thesis, (2002; in print; in Italian)</dd>

<dt id="Kaminsky02"><b>[Kaminsky 02]</b></dt>
<dd>Kaminsky, Piotr: <i>Integrating Information on the Semantic Web Using Partially Ordered Multi Hypersets</i>, <a href="http://www.ideanest.com/braque/Thesis-web.pdf">http://www.ideanest.com/braque/Thesis-web.pdf</a> (2002)</dd>

<dt id="Lacher01"><b>[Lacher 01]</b></dt>
<dd>Lacher, Martin S.; Decker, Stefan: <i>On the Integration of Topic Maps and RDF Data</i>, <a href="http://www.idealliance.org/papers/extreme03/html/2001/Lacher01/EML2001Lacher01-toc.html">http://www.idealliance.org/papers/extreme03/html/2001/Lacher01/EML2001Lacher01-toc.html</a> (2001)</dd>

<dt id="LTM"><b>[LTM]</b></dt>
<dd>Garshol, Lars Marius: <i>The Linear Topic Map Notation: Definition and introduction, version 1.2</i>, <a href="http://www.ontopia.net/download/ltm.html">http://www.ontopia.net/download/ltm.html</a> (2002)</dd>

<dt id="Mindswap02"><b>[Mindswap 02]</b></dt>
<dd>MindSwap: <i>RDF Converter</i>, <a href="http://www.mindswap.org/2002/rdfconvert/">http://www.mindswap.org/2002/rdfconvert/</a> (2002)</dd>

<dt id="Moore01"><b>[Moore 01]</b></dt>
<dd>Moore, Graham: <i>RDF and Topic Maps: An exercise in convergence</i>, <a href="http://xml.coverpages.org/moore-topicmapsrdf200105.pdf">http://xml.coverpages.org/moore-topicmapsrdf200105.pdf</a> (2001)</dd>

<dt id="N3"><b>[N3]</b></dt>
<dd>Berners-Lee, Tim: <i>Notation 3</i>, <a href="http://www.w3.org/DesignIssues/Notation3.html">http://www.w3.org/DesignIssues/Notation3.html</a> (2001)</dd>

<dt id="Noy04"><b>[Noy 04]</b></dt>
<dd>Noy, Natasha; Rector, Alan: <i>Defining N-ary Relations on the Semantic Web: Use With Individuals</i>, <a href="http://www.w3.org/TR/swbp-n-aryRelations/">http://www.w3.org/TR/swbp-n-aryRelations/</a> (2004)</dd>

<dt id="Ogievetsky01a"><b>[Ogievetsky 01a]</b></dt>
<dd>Ogievetsky, Nikita: <i>Harvesting XML Topic Maps from RDF</i>, <a href="http://www.cogx.com/kt2001">http://www.cogx.com/kt2001</a> (2001)</dd>

<dt id="Ogievetsky01b"><b>[Ogievetsky 01b]</b></dt>
<dd>Ogievetsky, Nikita: <i>XML Topic Maps through RDF glasses</i>,
<a href="http://www.cogx.com/?si=urn:cogx:resource:rdfglasses"
>http://www.cogx.com/?si=urn:cogx:resource:rdfglasses</a> (2001)</dd>

<dt id="Ogievetsky02"><b>[Ogievetsky 02]</b></dt>
<dd>Ogievetsky, Nikita: <i>DAML and Quantum Topic Maps</i>, <a href="http://www.cogx.com/kt2002/">http://www.cogx.com/kt2002/</a> (2002)</dd>

<dt id="Ontopia03a"><b>[Ontopia 03a]</b></dt>
<dd>Ontopia: <i>RTM: An RDF-to-TM mapping</i>, <a href="http://psi.ontopia.net/rdf2tm/">http://psi.ontopia.net/rdf2tm/</a> (2003)</dd>

<dt id="Ontopia03b"><b>[Ontopia 03b]</b></dt>
<dd>Ontopia: <i>TMR: A TM-to-RDF mapping</i>, <a href="http://psi.ontopia.net/tm2rdf/">http://psi.ontopia.net/tm2rdf/</a> (2003)</dd>

<dt id="Ontopia04"><b>[Ontopia 04]</b></dt>
<dd>Ontopia: <i>tolog: Language tutorial</i>, <a href="http://www.ontopia.net/omnigator/docs/query/tutorial.html">http://www.ontopia.net/omnigator/docs/query/tutorial.html</a> (2004)</dd>

<dt id="Ontopia05"><b>[Ontopia 05]</b></dt>
<dd>Ontopia: <i>Omnigator Eight</i>, <a href="http://www.ontopia.net/omnigator/">http://www.ontopia.net/omnigator/</a> (2005)</dd>

<dt id="OWL"><b>[OWL]</b></dt>
<dd>Smith, Michael K.; Welty, Chris; McGuiness, Deborah L.: <i>OWL Web Ontology Language Guide</i>, <a href="http://www.w3.org/TR/owl-guide/">http://www.w3.org/TR/owl-guide/</a> (W3C Recommendation, 2004)</dd>

<dt id="Pepper00"><b>[Pepper 00]</b></dt>
<dd>Pepper, Steve: <i>The TAO of Topic Maps: Finding the Way in the Age of Infoglut</i>, <a href="http://www.ontopia.net/topicmaps/materials/tao.html">http://www.ontopia.net/topicmaps/materials/tao.html</a> (2000)</dd>

<dt id="Pepper03"><b>[Pepper 03]</b></dt>
<dd>Pepper, Steve; Schwab, Sylvia: <i>Curing the Web's Identity Crisis: Subject Indicators for RDF</i>, <a href="http://www.ontopia.net/topicmaps/materials/identitycrisis.html">http://www.ontopia.net/topicmaps/materials/identitycrisis.html</a> (2003)</dd>

<dt id="Pepper05"><b>[Pepper 05]</b></dt>
<dd>Pepper, Steve: <i>Italian Opera Topic Map</i>, <a href="http://www.ontopia.net/omnigator/docs/navigator/opera.hytm">http://www.ontopia.net/omnigator/docs/navigator/opera.hytm</a> (2005)</dd>

<dt id="PMTM4"><b>[PMTM4]</b></dt>
<dd>Biezunski, Michel; Newcomb, Steven R.: <i>Topicmaps.net's Processing Model for XTM 1.0, version 1.0.2</i>, <a href="http://topicmaps.net/pmtm4.htm">http://topicmaps.net/pmtm4.htm</a> (2001)</dd>

<dt id="Prudhommeaux02"><b>[Prudhommeaux 02]</b></dt>
<dd>Prud'hommeaux, Eric; Moore, Graham: <i>RDF Topic Map Mapping</i>, <a href="http://www.w3.org/2002/06/09-RDF-topic-maps/">http://www.w3.org/2002/06/09-RDF-topic-maps/</a> (2002)</dd>

<dt id="RDF-Primer"><b>[RDF-Primer]</b></dt>
<dd>Manola, Frank; Miller, Eric: <i>RDF Primer</i>, <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a> (W3C Recommendation, 2004)</dd>

<dt id="RDF-Schema"><b>[RDF-Schema]</b></dt>
<dd>Brickley, Dan; Guha, R.V.: <i>RDF Schema</i>, <a
href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a> (W3C Recommendation, 2004)</dd>

<dt id="RDF-Semantics"><b>[RDF-Semantics]</b></dt>
<dd>Hayes, Patrick: <i>RDF Semantics</i>, <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">http://www.w3.org/TR/2004/REC-rdf-mt-20040210/</a> (W3C Recommendation, 2004)</dd>

<dt id="TAG"><b>[TAG]</b></dt>
<dd>Jacobs, Ian; Walsh, Norman: <i>Architecture of the World Wide Web, Volume One</i>, <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a> (W3C Recommendation, 2004)</dd>

<dt id="TMDM"><b>[TMDM]</b></dt>
<dd>Garshol, Lars Marius; Moore, Graham: <i>ISO/IEC 13250: Topic Maps &#8212; Data Model</i>, <a href="http://www.isotopicmaps.org/sam/sam-model/">http://www.isotopicmaps.org/sam/sam-model/</a> (Final Committee Draft, 2005)</dd>

<dt id="TMRM"><b>[TMRM]</b></dt>
<dd>Durusau, Patrick; Newcomb, Steven R.: <i>ISO/IEC 13250: Topic Maps &#8212; Reference Model</i>, <a href="http://www.isotopicmaps.org/tmmm/TMMM-4.6/TMMM-4.6.html">http://www.isotopicmaps.org/tmmm/TMMM-4.6/TMMM-4.6.html</a> (Working Draft, 2004)</dd>

<dt id="Vatant04"><b>[Vatant 04]</b></dt>
<dd>Vatant, Bernard: <i>Ontology-driven topic maps</i>, <a href="http://www.idealliance.org/europe/04/call/xmlpapers/03-03-03.91/.03-03-03.html">http://www.idealliance.org/europe/04/call/xmlpapers/03-03-03.91/.03-03-03.html</a> (2004)</dd>

<dt id="Vlist01"><b>[Vlist 01]</b></dt>
<dd>Vlist, Eric van der: <i>Representing XML Topic Maps as RDF</i>, <a href="http://lists.w3.org/Archives/Public/www-rdf-interest/2001Mar/0050.html">http://lists.w3.org/Archives/Public/www-rdf-interest/2001Mar/0050.html</a> (2001)</dd>

<dt id="XTM1.0"><b>[XTM1.0]</b></dt>
<dd>Pepper, Steve; Moore, Graham: <i>XML Topic Maps (XTM) 1.0</i>, <a href="http://www.topicmaps.org/xtm/1.0/">http://www.topicmaps.org/xtm/1.0/</a> (2001)</dd>

<dt id="XTM1.1"><b>[XTM1.1]</b></dt>
<dd>Garshol, Lars Marius; Moore, Graham: <i>ISO/IEC 13250: Topic Maps &#8212; XML Syntax</i>, <a href="http://www.isotopicmaps.org/sam/sam-xtm/">http://www.isotopicmaps.org/sam/sam-xtm/</a> (Final Committee Draft, 2005)</dd>
</dl>
</div>

<p><a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" /></a></p>

</body>
</html>