On Tue, 10 Jul 2007 23:34:10 -0700, Alan Ruttenberg
<[EMAIL PROTECTED]> 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.
