Re: [topicmaps-comment] referring to a topic from outside a TM

["Thomas B. Passin" <tpassin@comcast.net>]

[Bandholtz, Thomas]


I would not think about a special URN  scheme first. URNs are only names
(ok, globally uniq names, hopefully). We need an  addressing method that can
provide on-line access to the addressed node.
Today most of us use URL with *fragment identifiers* (which is not widely
implemented for XML) and not *queries* (using ? in an URI), so they are tied
to documents.

[me]

I don't see that there has to be a fundamental difference between fragment
identifiers and query  strings in practice.  If I can do a GET
http://bigmap.com/thetopicmap#tt-storm, it amounts to an index into bigmap's
topic map.  It's not defined what should be returned from that request, but
presumably it would be a topic element if tt-storm were the id of a topic.
Note that HTML browsers don't behave that way, they get the whole document
and scroll to the anchor.  As an aside, if the map has been flattened as in
PMTM4 or in an RDF version, or stored in a relational database, it's not
obvious what would constitute the correct "element" to be gotten.

If I do a GET http://bigmap.com/thetopicmap?gettopic=tt-storm, I ask the
server to do something that is up to the server, but presumably will be
related to the topic id in some way.

If I do a GET http://bigmap.com/thetopicmap/tt-storm, I am asking the server
to return a resource that is "subsidiary" to http://bigmap.com/thetopicmap.
It is up to the server to decide what a "subsidiary resource" is.  It would
be a small step to agree that the subsidiary resource would be an element
with that id (if we agreed on what an "element" should be).

Any of these ways would make sense - I favor version 1 or 3, myself - but
with any of them there has to be a spec or convention about how it will work
and what should be returned.  I would suppose that one would want an xtm
fragment to be returned - else what's an interchange format for?

The key point is the agreement or spec about the interpretation of the
request and the form of the response.  We don't have that yet, but it will
come.

The thing is to get what you want without too many network calls and too
many requests on the server.  Everyone can see how to walk a topic map bit
by bit, but how to get what you need to put that topic or association in
context so that it can be interpreted, preferably in one chunk and without
too big a load on a server, is harder.  That's what I have been posting
about.

For example, if you get an association, should you also get the topics that
play role in that association, or should you just get references to them?
The latter doesn't fit most processing models to date.

I'm not saying that these things can't be solved, I'm just saying that it's
trickier than would appear.

Cheers,

Tom P