[topicmapmail] multiple Source Locators

[Kal Ahmed]

On Mon, 2004-08-30 at 20:05, Jan Algermissen wrote:
> 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.
> 
That is certainly true of http:// URIs, but is it true of all URI
schemes ? What about the data: URI scheme ? It is nitpicking in a sense,
but it also points out that even with a defined "Web" architecture,
there are uses of URIs which do not fit into this view.

> 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'.

I tend to agree with what you say here (with the proviso that not all
URI schemes are created equal). It is certainly better when using any
URI scheme to try and work with its intended use than in some different
direction. In defence of XTM, even the TAG hadn't worked out what the
architecture of the web was when XTM 1.0 was authored and despite all of
the collected talents of the committee we had no soothsayers or
mindreaders ;-)

As I see it, if we were follow the TAG's architecture of the web, it
would significantly limit the scope of subject locators using http://
URIs to identifying only the result of resolution of the URI (e.g. the
HTTP response).

>  
> > > (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.
> 

The reason I raised that example is that I believe that the intention
behind the RDF statement is *not* that Ora Lassila authored the series
of bytes that you receive in response to the HTTP GET, but that he
authored an HTML file that resides on a server. Which I would say is
equivalent to the way subject locator was intended to be used by the XTM
committee.

> 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.
> 

Surely you can, by placing your URIs in statements that provide such a
context. A triple like:

subject is-described-by <uri>

uses an "is-described-by" predicate to supply the new context.


> 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.
> 
I'm not sure about that, but I'm no HyTime expert either.

> 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?

...or does the addressing context affect interpretation of the result of the GET 
rather than the action performed on the address string ?


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

Aye, and its not an issue to which there is an easy answer as yet. If
there was, then RDF and Topic Maps folks would be doing that and not
spending their Monday nights typing long emails to each other ;-)

Cheers,

Kal

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