RE: [BioRDF] All about the LSID URI/URN

Hello Xiaoshu,

public-semweb-lifesci-request@w3.org wrote on 07/07/2006 11:32:58 AM:

> 
> In short, the myth of URN vs. URL is in our perception but not in 
actuality.
> W3C's recommendation to use URI, as opposed to use URN and URL, to refer 
all
> http, ftp, lsid, mailto, etc., is a good first step. As an identifier, 
there
> is no difference between URN and URI. How to retrieve the resource is an
> implementation but not a naming issue. And my bet, as Dan's, is on HTTP.
> So, if need an identifier, allocate an HTTP namespace if you own a 
domain
> name, or request one from, for instance http://www.purl.org/, or other
> similar services. 

As I wrote in my original post, I agree that as far as unique strings go 
and naming, there is no serious difference between a URN or a URL as a URI 
-- right up until when you want to resolve them to something (what you 
call the implementation). And again it is not that I think that HTTP is a 
particularly poor URI, because in many cases it will be all one needs. It 
is certainly likely to be a popular option, especially when we decide what 
it should return. Also as I wrote earlier, if adopted, a local or 
centralized PURL type scheme can help address some of the issues arising 
--although this does introduce a couple of new issues too. 

That said, in other cases the HTTP URL as URI does not appear to address 
all the requirements and actually has a couple of problems that are hard 
to address, and so the advent of the LSID and probably other URI schemes. 
My suggestion is that it is worth spending a little time examining the 
shortcomings of HTTP URL as a URI so that we can see if other URI schemes 
beyond HTTP URLs are worthwhile. BTW, your notion that a URI string be 
passed to a web service which returns the available service end points is 
pretty much exactly what the LSID scheme does right now. It is my 
impression that those that have actually implemented LSID have found both 
that it was easy to do and that location independance turns out to be 
extremely useful in practise, especially in the realm of wide area 
collaboration.

Kindest regards, Sean

--
Sean Martin
IBM Corp