Review RDFTM Guidelines

Hello,

Below is my review of the "Guidelines for RDF/Topic Maps 
Interoperability - W3C Working Group Draft 20 March 2006" as available 
here: http://www.ontopia.net/work/guidelines.pdf

Regards,

Fabien



These guidelines are interesting, very well written and I believe useful 
not only for developers of cross-formalism applications but also as a 
complement for people familiar with TM or RDF/S and wanting to get 
familiar with the other formalism.

Disclaimer: *I am not a specialist in TM* and thus the following review 
suffers from this lack of expertise. Some of my questions may be 
answered in the survey but I read these guidelines as a standalone document.


*Remark #1*
"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."
I would remove the parenthesises and their content: the note should 
remain purely technical IMHO.


*Remark #2*
"In these examples, guidance statements are preceded by a + red plus 
sign, while classes and properties from the rdftm namespace are shown in 
teal, thus: + dc:Document rdfs:subClassOf rdftm:InformationResource ."
Only at the end did I understand that guidance statements were of two types:
- the guidance statements in the RDF base for RDF2TM noted:
  " + bio:born-in rdftm:subject-role foaf:Person"
- the guidance statements in the TM base for TM2RDF noted with curly 
brackets:
  "+ { bio:born-in, rdftm:subject-role, foaf:Person }"
I think this should be explained and illustrated with an example here I 
believe

In addition (I know I am being picky here) the shade and the word "teal" 
may be unknown to non native speakers. May I suggest you use "green" for 
the colour and the word ;-)


*Detail #1*
"(NB! proposed)" is probably an edition trace otherwise I don't get it.


*Detail #2*
  "Guidelines for making this decision are given throughout Sections 
3.4–3.6 AND are collected together in Section 3.10."


*Remark #3*
"Both Topic Maps and RDF use URIrefs as identifiers (for subjects and 
resources, respectively). (…) In Topic Maps, it is always clear whether 
the URIref is a subject locator or a subject identifier. Since RDF does 
not make this distinction, the question arises, in RDF2TM, whether to 
map the URIref of a resource to a subject locator or to a subject 
identifier; and, conversely, in TM2RDF, whether to map subject locators 
or subject identifiers (or neither, or both) to the URIrefs of resources."

Here the reader might wonder why not use the properties rdfs:seeAlso or 
rdfs:isDefinedBy in RDFS to represent subject identifiers. The RDFS spec 
sounds close to the notion of subject identifiers:
- "rdfs:seeAlso is an instance of rdf:Property that is used to indicate 
a resource that might provide additional information about the subject 
resource."
- "rdfs:isDefinedBy is an instance of rdf:Property that is used to 
indicate a resource defining the subject resource. (…) It may be 
possible to retrieve representations of O from the Web, but this is not 
required. When such representations may be retrieved, no constraints are 
placed on the format of those representations."


*Remark #4*
"RDF2TM: 3.3 Identity": the first bullet also deserves an example ;-)


*Remark #5*
" Example 9
<http://en.wikipedia.org/wiki/Puccini>
->
  [puccini @"http://en.wikipedia.org/wiki/Puccini"]
"
Here I don't see where the "puccini" id of the TM comes from; shouldn't 
it be an arbitrary id?


*Remark #6*
"The property rdfs:label deserves particular attention. It may be used 
in RDF to provide a
human-readable version of a resource's name. However, in OWL it is 
defined as an instance of owl:AnnotationProperty, which means that it 
cannot be used in property axioms. This prevents these Guidelines from 
using rdfs:label as the primary mechanism for providing guidance. "
I found this a pity especially since IMHO interoperability is more 
likely to happen at the RDF/S - TM layer than at an OWL - TM layer.
In addition this point raises the more general question of the scope of 
these guidelines in terms of RDF/S vs. OWL. As they are, these 
guidelines are essentially focusing on RDF/S with a small excursion in 
OWL Lite for inverse properties.


*Remark #7*
"Example 13
[puccini = "Giacomo Puccini"]
->
_puccini tm:name-type "Giacomo Puccini" .
+ tm:name-type rdf:type rdftm:NameProperty"

I don't understand why the default naming in TM could not be mapped to 
the default naming in RDF/S
"[puccini = "Giacomo Puccini"]
->
_puccini rdfs:label "Giacomo Puccini" ."

With the built-in guidance "rdfs:label rdf:type rdftm:NameProperty"


*Remark #8*
"In Topic Maps, a name can have variants."
Concerning variants I was wondering if the rdf:Alt mechanism and the 
rdf:Value mechanism could not be used and combined to obtain the same 
result. I am not sure how to write it best but it could look like this 
(sorry I prefer RDF/XML syntax):

    <rdf:Description rdf:about="puccini">
       <foaf:name>
          <rdf:Alt>

             <rdf:li rdf:parseType="Resource">
                <rdf:value>Giacomo Puccini</rdf:value>
             </rdf:li>

             <rdf:li rdf:parseType="Resource">
                <rdf:value>puccini, giacomo</rdf:value>
                <rdftm:variant-scope rdf:resource="&tm;sort"/>
             </rdf:li>

          </rdf:Alt>
       </ foaf:name>
    </rdf:Description>

One of the reasons why I don't like the current solution is shown in 
example 18: the statements are repeated and I don't think it is trivial 
to merge them again for round-tripping.
(rdf:type rdf:Statement ; rdf:subject _tchaikovsky ; rdf:predicate 
foaf:name ; rdf:object "Tchaikovsky" )


*Remark #9*
In result of example 19, shouldn't the scope appear? i.e. ( "puccini, 
giacomo" / tm:sort )


*Remark #10*
"Untyped occurrences cannot be translated since there is no URIref 
available to create a property."
Couldn't there be a generic type for such cases.


*Remark #11*
"In order to provide this information, these Guidelines define the 
properties rdftm:subject-role
and rdftm:object-role, whose domain is rdf:Property."
What is the rationale not to use rdfs:range and rdfs:domain?


*Remark #12*
"3.6.2 N-ary relationships"
I was surprise with your choice: I thought the pattern 1B was closer to 
the notion of associations of n-arity with roles.


*Remark #13*
"3.8 Reification"
"There is no direct equivalent of the topic map itself in RDF. The 
closest equivalent is the
set of statements contained in a single RDF document, but this is not 
quite the same."
Wouldn't it be possible to do it with a rdf:Bag of statements?


*Detail #3*
Example 51 uses the language tag "no" while the second appendix 5.3 
(problem of numbering) uses "nor": (4)nor 
http://www.w3.org/2006/rdftm/rfc3066/nor


-- 
"Even one is not able to successfully translate
  one's own thoughts into words"
                         -- Friedrich Nietzsche.
  ____________
|__ _ |_  http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/
|  (_||_) INRIA Sophia Antipolis - ph# (33)(0)4 92 38 77 88

Received on Friday, 31 March 2006 10:32:13 UTC