W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

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

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Fri, 7 Jul 2006 16:52:01 -0400
Message-Id: <5CD01E0D-6219-4725-89F4-D814A5A7697F@gmail.com>
Cc: public-semweb-lifesci@w3.org, Dan Connolly <connolly@w3.org>
To: Sean Martin <sjmm@us.ibm.com>

Sean, couldn't what LSID achieves be done, for instance, by having a  
convention that if someone dereferences, for example,

http://bla.com/path/to/document/foo.lsid

it is understood to obey a protocol, namely to return a snippet of  
rdf that says, here's a handle to my metadata, here's a handle to my  
data, here's my machine readable persistence policy.  Or instead of  
returning rdf, the link response mentioned in http://www.w3.org/2001/ 
tag/doc/URNsAndRegistries-50.html could be used to point to the  
auxillary information.

And if that persistence policy says that the data is immutable, then  
you can comfortably store it, and use this URI for as a handle for  
resolving, in the same way an LSID can be resolved by an http service

http://lsid.company.net/resolver/http://bla.com/path/to/document/ 
foo.lsid

The resolved could pull back whatever information you have locally,  
return source information, or redirect to the id, like a click through.

This seems to satisfy the requirement that you can tell what sort of  
thing it is from looking at it, as well as the desired ability to  
cache and indirect.

More generally any social convention that we use can accomplish the  
same thing - a provider could say (in a robots.txt-like file, or as a  
published policy) that certain paths in its tree have this sort of  
metadata available and should be treated like an lsid would.

-Alan
Received on Friday, 7 July 2006 21:14:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT