Re: BioRDF: URI Best Practices

On Jul 21, 2006, at 2:53 PM, Sean Martin wrote:

> 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).

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.

I contend that even if you didn't have the explicit name, but we had 
some convention around how to retrieve persistence policy (along the 
lines of content negotiation or my proposal), as soon as 1 agent, 
anywhere, retrieved that policy information, and it said that the 
resource wouldn't change, and grabbed it, we would be as safe as we are 
with LSIDs - in the case that there is a 404, you check with everyone 
you know (same as lsid) and if anyone has any information about the URI 
policy (from that single dereference), then you are OK. If we adopted 
this we could inform google, wayback, etc, that they should cache the 
policy as well as the content and we would be in even better shape than 
we are with LSIDs (since these third party archivers would now have the 
policy information too).

The important thing about it is the policy, it seems.

In fact you could trivially gateway such URIs to existing LSID caching 
systems and redirectors with a trivial rewrite and preserve the 
investment - there is no doubt that we need various kinds of local 
caching and the rest that LSID currently enables for some. I'm just not 
sure we need the specialized protocol LSID resolver part of the scheme.

-Alan