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

[Sean Martin]

Hello Xiaoshu,

[EMAIL PROTECTED] 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