Re: BioRDF: URI Best Practices

Hi Alan,

public-semweb-lifesci-request@w3.org wrote on 07/23/2006 11:51:35 PM:

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

Are you suggesting that programs parse URIs to see if they contain the 
ASCII string "static"? If so, how would ones program know the difference 
from any of these links?[1] I can see us heading towards heated 
discussions about URI opacity ;-)

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

Assuming you can overcome the confusion & re-educate the builders/users of 
the web and figure out some means to deal with non-compliance, and that 
such agreement is visible to a machine program without it doing a 
dereference, you could also go on to provide similar conventions to 
extract versioning and other important information from the URL string. 
e.g. can this one can actually be dereferenced & if so this is what one 
should expect; context; a digital hash etc could all be part of the URL.

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

This is true, but in the same way as LSIDs requires new infrastructure (a 
new protocol) to be deployed in clients and proxies since two different 
kinds of behavior are required, one for these new "static" URLs and one 
for everything else. As I posted earlier, the infrastructure of the http 
system that works today is exactly that part which is already used by the 
LSID resolution scheme. What does not work today is the parts added by the 
LSID scheme to compensate.

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

I am afraid I don?t see this. If you don?t have the "contract" with the 
name, it is far more complicated to deal with objects separated from their 
policies. LSIDs only ever have one policy for the data bits they name 
which makes the rules simple. You also don?t have anyone creating LSIDs by 
accident.


Kindest regards, Sean

[1] 
http://www.google.com/search?as_q=static&num=100&hl=en&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_nlo=&as_nhi=&as_occt=url&as_dt=i&as_sitesearch=&as_rights=&safe=images