Re: Use of LSIDs in RDF

We have some problem scenarios 
(http://www.w3.org/2003/12/20-local-global.html) and discussions of IDs 
also at Annotea developers list public-annotea-dev@w3.org 
(http://lists.w3.org/Archives/Public/public-annotea-dev/2004AprJun/) and 
there seem to be some discussion also at www-rdf-interest@w3.org list.
.

At 10:20 AM 4/14/2004 +0100, Martin Senger wrote:

> > I'm new to this list so forgive me if this is not the right forum to
> > discuss these issues, nonetheless...
> >
>    Please forgive me as well... I will try to put some light on LSID
>because I was/am involved in its specification but I am surely not an
>expert on the semantic web, even not on such "trivial" things, such as
>differences between URI and URN :-), not to mention HTTP URIs...
>
> > The Life Science Identifier (LIDS) proposal [1]
> >
>    First of all, here is the latest document for the LSID spec (but what
>you said about LSID has not changed):
>http://www.omg.org/cgi-bin/doc?lifesci/03-12-02
>
> > At present HTTP URIs are the best game in town for this. So why is LSID
> > proposing URNs as a solution ?
> >
>    Well, my understanding is that URI is a generic schema for identifying
>resources, and URN is one way how to make this generic schema a concrete
>one. URN *is* URI (but not vice-versa). It seems to me (but I may be
>mistaken) that better would be to compare URN and URL: one being
>location-independent, one not.

HTTP URI is pretty concrete too, it means a URI address with http://... 
beginning.

Here is some info about URIs etc. in general http://www.w3.org/Addressing/


> > 3. Invent new infrastructure for dereferencing LSID (DDDS)
> >
>    Just a small remark: the LSID spec does not dictate that the DDDS is
>the only way how to resolve an LSID. There are more ways how to discover a
>resolution service for my particular LSID. But true is that using DDDS is
>the most impressive (and possibly the most interoperable) way.
>
> > 5. Dereferencing a LSID results in a HTTP URI
> >
>    Does it really? I think that dereferencing an LSID results in an array
>of bytes/bits representing the entity identyfied by this LSID. An always
>very persistent array of bytes/bits - expressing just one, and only one
>representation of this entity. Or, if an LSID identifies a concept, it
>results in an empty array of bytes/bits (meaning "there is no real
>representation attached to this LSID").
>
> > Which brings me to my question, why not just use persistent HTTP URIs
> > in the first place ?
> >
>    I am not sure how to answer this ultimate question. Perhaps I need to
>understand more about HTTP URIs in order to give comparison with the URN
>used in LSID spec. To be honest I have tried to find more and I gave up
>after reading very nice article about HTTP URIs by Tim Berners-Lee
>(http://www.w3.org/DesignIssues/HTTP-URI.html) that gave me feeling that I
>am out of the league :-(

I think the question is mainly why reinvent a  wheel that already exixts.

Using persistent HTTP URIs is a good goal because it is standard and there 
exists a lot of HTTP based applications e.g. browsers that understand HTTP 
URIs and can provide information of the resource on the Web without 
anything extra.

When somebody defines a URN they can usually as well reserve a HTTP URI 
e.g. http://www.lsid.org/ and define URIs under it e.g. 
http://www.lsid.org/path.../enzyme1.

HTTP URIs is what Annotea project wants to use too (and we do use them).

Why we are now ALSO discussing of using UUID URNs is because we have 
problems with local file: type URIs (file: URIs e.g. file//marja/myfile123) 
and we want to make them unambiguous when a user cannot do HTTP URIs maybe 
because a user does not own a http:// domain name where to publish it or 
for some other reason.

Adding a UUID URN to bookmarks and topics is one way to make a connection 
between a local resource that until then has been shared through e-mail and 
the published resource that now has a HTTP URI.

After publishing we mostly want to use the HTTP URIs to be able to benefit 
from the common Web standards. But it is also possible for some application 
to benefit from the URN bit of the information when so wished.

Marja


>    Martin
>
>--
>Martin Senger
>
>EMBL Outstation - Hinxton                Senger@EBI.ac.uk
>European Bioinformatics Institute        Phone: (+44) 1223 494636
>Wellcome Trust Genome Campus             (Switchboard:     494444)
>Hinxton                                  Fax  : (+44) 1223 494468
>Cambridge CB10 1SD
>United Kingdom                           http://industry.ebi.ac.uk/~senger