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

I cannot agree with Dan anymore.  

URN is a mis-conceived concept.  The key to make a persistent URI is in the
effort of making it persistant rather than what its name implies.  Sure, URL
can change from time to time.  But who can ganrantee that a URN will not
change?

It is also wrong to think that a URL-resource can only be fected from the
given URL.  URL is at first a URI, i.e., a string identifier.  We certainly
can request a copy of the resource by giving the URI to, for example, a web
service.  The suggested location is the "prefered" location but not the
"only" location.

Before the TAG made the resolution on the httpRange-14 issue, I though LSID
spec does have a valid point in making the distinction between data and
metadata.  But after that httpRange-14 issue is solved, I am not sure why
the entire LSID spec can not be replaced with standard web services.

Given a resource URI (or URL if you insist), a reasonable senario is to
return back, after a 303, a brief RDF description of the requested resource
along with a list of web services where the resource or the description of
the resource can be fetched. With the current support on HTTP, it is a lot
cheaper, simpler, and perhaps securer than rolling out a whole set of new
specs and infrastructure.

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.    

Xiaoshu 

> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org 
> [mailto:public-semweb-lifesci-request@w3.org] On Behalf Of 
> Dan Connolly
> Sent: Friday, July 07, 2006 8:58 AM
> To: public-semweb-lifesci@w3.org
> Cc: Henry S. Thompson
> Subject: Re: [BioRDF] All about the LSID URI/URN
> 
> 
> http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006
Jun/0210.html
> 
> > The root of the problem is that the URL contains in it more 
> than just 
> > a name. It also contains the network location where the 
> only copy of 
> > the named object can be found (this is the hostname or ip address)
> 
> Which URL is that? It's not true of all URLs. Take, for example,
>   http://www.w3.org/TR/2006/WD-wsdl20-rdf-20060518/
> 
> That URL does not contain the network location where the only 
> copy can be found; there are several copies on mirrors around 
> the globe.
> 
> $ host www.w3.org
> www.w3.org has address 128.30.52.46
> www.w3.org has address 193.51.208.69
> www.w3.org has address 193.51.208.70
> www.w3.org has address 128.30.52.31
> www.w3.org has address 128.30.52.45
> 
> 
> FYI, the TAG is working on a finding on URNs, Namespaces, and 
> Registries; the current draft has a brief treatment of this 
> issue of location (in)dependence...
> http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html#loc_i
> ndependent
> 
> 
> > as well as the only means by which one may retrieve it (the 
> protocol, 
> > usually http, https or ftp). The first question to ask 
> yourself here 
> > is that when you are uniquely naming (in all of space and time!) a 
> > file/digital object which will be usefully copied far and 
> wide, does 
> > it make sense to include as an integral part of that name the only 
> > protocol by which it can ever be accessed and the only 
> place where one 
> > can find that copy?
> 
> If a better protocol comes along, odds are good that it will 
> be usable with names starting with http: .
> 
> See section 2.3 Protocol Independence
> http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html#proto
> col_independent
> 
> 
> > Unfortunately when it
> > comes to URL?s there is no way to know that what is served one day 
> > will be served out the next simply by looking at the URL 
> string. There 
> > is no social convention or technical contract to support 
> the behavior 
> > that would be required.
> 
> Again, that's not true for all URLs. There are social and 
> technical means to establish that
> 
>   http://www.w3.org/TR/2006/WD-wsdl20-rdf-20060518/
> 
> can be cached for a long time.
> 
> The social mechanism includes published policies such as...
> 
> "As of this note, persistent resources include:
>      1. ...
>      2. Those which start "http://www.w3.org/TR/" immediately followed
>         by four decimal digits."
>  --- http://www.w3.org/Consortium/Persistence
> 
> and the technical mechanisms include HTTP caching headers:
>   Expires: Sat, 07 Jul 2007 12:51:56 GMT
> 
>   (a 1 year expiry time is the maximum time per rfc2616)
> 
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
> 
> 
> 
>

Received on Friday, 7 July 2006 15:35:32 UTC