[topicmapmail] Question of the week : the TMDM PSIs in TM engines

[Richard Light]

In message <9DD5A617-BB7E-4D3F-A02E-531760F04905 at garshol.priv.no>, Lars 
Marius Garshol <larsga at garshol.priv.no> writes
>
>This all looks like good stuff to me! Unfortunately, the XTM you get
>seems to be lacking the
>
>   version="2.0"
>
>on the <topicMap/> element.

OK, I have added this to the XSLT, and fixed a bug whereby the same 
object-class topic could be declared more than once.

>Do you have a page somewhere that describes this, however briefly?
>Would like to mention it on the TM snippets blog.

Not yet: I am going to be talking about this work later this month, and 
will try to write something down.  I'll let this group know when there 
is something to read.

>> So to my question: is there a fundamental difference between what an
>> RDF
>> URI represents and what a Topic Maps PSI represents, such that this
>> Janus-like use of a single URI for both is a bad and dangerous
>> practice?
>
>Well, a URI generally just represents any resource. Not entirely sure
>what you mean by an RDF URI, but I assume it's the same.

What I would like to do is to use just one URI to represent a subject 
(such as "the print in the Wordsworth Museum with identity number 
GRMDC.C104.2") in both Topic Maps and RDF graphs.  Thus, in Topic Maps 
parlance it is a Published Subject Identifier; in the RDF world-view it 
represents a "Non-information resource".  (This is where the content 
negotiation comes in - requests for non-information resources are meant 
to return a "303 See Other" response and redirect you to a 
human-readable resource describing the non-information resource.)

>If you use a URI as a PSI in a topic map you are saying that the URI
>will return a human-readable description of the topic's subject.
>That's more restricted than the general case of URIs, because some (in
>fact, most) URIs don't do this.

Although requests for non-information resources are also meant to do 
this, as noted above, so this looks OK.

>I haven't seen you actually *use* this as a PSI anywhere, though.

I now include it as a <subjectIdentifier> element.

Note that this interface will, by design, only return one principal 
[museum object] topic and its associated topics (e.g. places and 
people), so there is only one PSI.  If applied to a more complete set of 
object records, the same XSLT transform will return a rather more useful 
Topic Map.  I'll have a go at expressing the identifiers for people, 
places, etc. as PSIs.

>I don't really see any problem with the content-negotiation approach.

That's reassuring, thanks.  In principle, if you put a TMQL/tolog query 
interface and SPARQL end-point in front of this database, you could then 
query it using either paradigm, and extract results either as RDF or 
XTM, at your pleasure.  (Would this be useful?!)

Richard
-- 
Richard Light