- From: Alan Ruttenberg <alanruttenberg@gmail.com>
- Date: Fri, 7 Jul 2006 16:52:01 -0400
- To: Sean Martin <sjmm@us.ibm.com>
- Cc: public-semweb-lifesci@w3.org, Dan Connolly <connolly@w3.org>
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 UTC