RE: BioRDF: URI Best Practices

--Alan

> 	XW> Should a LSID resolver decide not to resolve a 
> particular LSID, wouldn't it 
> 	XW> be the same effect as a broken link?   
> 	
> 	Not really for a number of reasons. The first is that 
> you may well already have it stored somewhere accessible if 
> it has ever been seen by you or anyone in your organization 
> before (since even the first version of the software for 
> resolution supports local archiving/caching) and if you don't 
> find it at home you/your machine can ask if one of your 
> friends/colleagues has a copy or if some other third party 
> does. You have a unique name and a means that you can use to 
> ask them either formally (protocol) or informally (email). 

The meaning of a 404 does not imply the "represented" resource does not
exist.  If implies that the representation of the resource can not be
transferred to you at this particular location at this particular time.

For example, you can still retrieve the representation of some broken URLs
from google cache.  What does it mean to you?  As I have repeatedly said,
don't think HTTP URI as a URL.  Think it as a URI first.  TAG is trying to
define the relationship between the schema part of the HTTP URI, i.e., the
"http" in "http://foo.com" to the HTTP transport protocol.  I am not if
there is a final finding yet.  But the schema -> protocol is definetly not a
MUST relationship.

> Doesn't this work for the http://my.com/foo.lsid I suggested 
> as an http replacement for lsid. Let's change the name to be 
> even more clear. Suppose we have a convention that when we 
> want to pass out a URL with content that will never change, 
> we name it http://my.com/foo.static. Issuers of such 
> identifiers promise that the "data" of such a resource will 
> never change, in the same way that a current lsid provider 
> would. Clients that care about caching know that they can. If 
> the resource becomes 404 at some point you can safely know 
> that you can pass the handle around to your friends and if 
> their software cached it, it will be the right data? It's 
> still a unique name, etc.

Convention is only good if it can be enforced.  If you really think those
conventions are useful, you should propose to the TAG group.  But I don't
think it is a good idea to propose a life-science specific convention
because then what if we want to connect life-science data to say geo-science
data?

Data persistency, and equivalency, is always a big and important problem.
And I don't think it will be simply solved via naming. 

Xiaoshu

Received on Monday, 24 July 2006 14:12:09 UTC