[topicmapmail] multiple Source Locators

[Jan Algermissen]

Kal Ahmed wrote:
> 
> On Mon, 2004-08-30 at 18:35, Jan Algermissen wrote:
> > Stefan Lischke wrote:
> >
> > > I think "multiple subject locators" is solving alot of problems, but  on
> > > the other hand maybe creates new stuff to think about.
> > >
> > > What are you thinking about this issue?
> >
> > Stefan,
> >
> > I think, that it is a question of DECIDING what the MEANING of a subject locator
> > is. If This meaning allows multiple subject locators to address the same 'thing',
> > then, yes, we should have a set of them instead of a single one.
> >
> > Beware that this also depends on the technology that you deploy topic maps on.
> > For example, when used with the Web/URIs, an address can NEVER address a piece
> > of data, just abstractions of it, because URIs address resources (abstractions), not
> > representations (data). That is an architectural property of the Web and it
> > IMHO significantly affects the semantics of 'subject locator'.
> >
> 
> I agree. However, allowing multiple subject locators doesn't address
> this issue at all - it just creates more confusion by allowing a topic
> to have subject locators that address multiple abstractions (and
> possibly even multiple data items). IMO, the old heuristic of zero or
> one subject locator per subject is a lot easier to understand,
> communicate and design around.

Yes, I think so too, but the problem (at least for me) is that the
notion of addressing a piece of data just does not exist on the Web. When
I finally understood REST a year ago or so, I suddenly realized, that we
cannot just arbitrarily define the meaning of certain aspects of a technological
environment, but that, by using a particular environment, we are bound to its
definitions. A URI NEVER addresses a piece of data and we cannot change that
by saying that the subject address refers to the piece of data that *is* is the
subject. With URIs, this is meaningless.

Of course, it is possible to silently ignore this issue and to make a certain
use of the technology (Web architecture), massive communities even manage to
simply use HTTP as a transport protocol (which is it not) an pile a whole
other WS-* layer on top. The downside with this 'simply using HTTP' instead of
'integrating with the Web' is that you loose most of the really exciting
aspects (such as the unique addressing context in the case of XTM or the
uniform interface in the case of SOAP-style Web services).

I am not saying here that XTM is useless or wrong, I am just saying that there
are interesting advantages in trying to bring in more 'on the Web'.
 
> > (To add to the confusion: I personally have dropped the use of subject locators
> > alltogether in projects that use Topic Maps and HTTP and instead only use
> > subject indicators. This creatly improves interoperability with the
> > technology (browsers) and also with RDF.)
> >
> 
> I'm intrigued. As I understand it, in RDF you can use URIs as the
> equivalent of TM's subject locators as they are currently defined (as in
> the world famous "http://.... author 'Ora Lassila'". Does that mean that
> you restrict your RDF models to only use the equivalent of subject
> indicators ?

In the famous quote, http://.... does not refer to data, it refers to the
abstraction of some data (the data you'll receive as a response to a GET
on the URI depends to a large extend on the value of the Accept header you
send). The semantics of the HTTP URI are equivalent to 'our' subject indicator,
not to 'our' subject address.

RDF uses URIs and with RDF (and the Web in general), there can only be a single
addressing context, so I could not, for example, "restrict your RDF models to
only use the equivalent of subject indicators". Makes no sense.

This is BTW, very different from HyTime addressing (my HyTime understanding is
extremely limited, so please correct me if I am wrong), where you *can* address
a piece of data.

My personal experience is, that restricting the semantics of my (Web based) topic
map projects to the semantics actually offered by the Web, provides interesting
possibilities (e.g. in the interaction between user agents, intermediaries and
servers).

Consider this (in Web context):

What is the *significance* of what you get back when you do a GET on a
subject indicator URI?

What is the *significance* of what you get back when you do a GET on a
subject address URI?

Can you in both cases simply say "GET <uri> HTTP/1.1" or do you
have to take the different addressing contexts of subect indicator and
subject address into account?


I have puzzled around with stuff like this for months and it is really
quite fascinating (well, it was for me).


Jan



> 
> Cheers,
> 
> Kal
> 
> --
> Kal Ahmed <kal@techquila.com>
> techquila

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org