Re: URL +1, LSID -1

On Tue, 10 Jul 2007 23:34:10 -0700, Alan Ruttenberg  
<alanruttenberg@gmail.com> wrote:

> The cost of using an http identifier, and providing a 303 and a pointer  
> to more information, instead of using an LSID, seems a small cost to  
> satisfy this community.


Please correct me if I am wrong - I just re-read the spec for 303 and I  
believe I am interpreting it properly... though I may not be!  What  
worries me about the 303 solution (other than that we are not using it for  
it's primary purpose [1]) is that the redirection can only be to a  
*single* resource, specified in the Location header.

One aspect of LSIDs that has been, for me, so useful, is that the  
identifier can be bound to multiple end-points for metadata (well, for  
data too, but that's less important in this discussion since the data is  
required to be byte-identical in every case, while the metadata can vary  
 from provider to provider).  My understanding is that the 303 could only  
redirect the agent to a single alternative URI.  Am I wrong?

We use this LSID behaviour in Moby to allow the registry to provide  
metadata that it knows about a service, and the service provider to  
provide metadata that they know about a service, without having to merge  
these two sources of metadata in a single endpoint, and allow every  
provider of metadata to evolve that metadata as they see fit without  
disturbing anyone else.

As I've said before, I think that LSIDs solve a *very specific subset* of  
problems that don't seem to be raised very often in the discussions on  
this list because they aren't "typical" situations... at the moment!   
However they may become "typical" once the SW is actually up and running.   
We seem to be discussing the semantic web as if it were a database.  In  
fact, someone said earlier in this thread that we are really talking about  
building SPARQL endpoints... I disagree!  We are talking about building  
the Semantic Web - and we don't even know what the Semantic Web will look  
like!  I honestly feel we are limiting our vision if we begin this journey  
with the perception of the SW as a set of SPARQL endpoints, or a set of  
URIs that we want to be able to type into our browsers.  That may be the  
first step, and a way to bootstrap it, but surely it's more than that.

Those of us who use LSIDs use them for a reason.  Likely, that reason is  
that they solve the atypical problems that we are faced with, in an  
elegant and standards-body-approved manner.  I suspect that what is now  
atypical will become the norm as the SW comes to fruition, so burning  
bridges too early in the process is surely destructive...??  What's that  
they say about premature optimization?

I'm all for a hybrid solution - there's no need to use LSIDs in every  
case, but there seems to be a need to use them in *some* cases.

Mark

[1] "This method exists primarily to allow the output of a POST-activated  
script to redirect the user agent to a selected resource"  
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

-- 
--
Mark Wilkinson
Assistant Professor, Dept. Medical Genetics
University of British Columbia
PI Bioinformatics
iCAPTURE Centre, St. Paul's Hospital
Tel:  604 682 2344 x62129
Fax:  604 806 9274

***CONFIDENTIALITY NOTICE***
This electronic message is intended only for the use of the addressee and  
may contain information that is privileged and confidential.  Any  
dissemination, distribution or copying of this communication by  
unauthorized individuals is strictly prohibited. If you have received this  
communication in error, please notify the sender immediately by reply  
e-mail and delete the original and all copies from your system.

Received on Wednesday, 11 July 2007 16:30:47 UTC