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
