- From: Booth, David (HP Software - Boston) <dbooth@hp.com>
- Date: Mon, 26 Feb 2007 15:14:05 -0500
- To: "William Bug" <William.Bug@DrexelMed.edu>, "Eric Neumann" <eneumann@teranode.com>
- Cc: "W3C HCLSIG hcls" <public-semweb-lifesci@w3.org>, "Olivier Bodenreider" <olivier@nlm.nih.gov>, "Alan Ruttenberg" <alanruttenberg@gmail.com>, <samwald@gmx.at>
> From: Eric Neumann [mailto:eneumann@teranode.com] > To: Kwan, Kathy (NIH/NLM/NCBI) [E] > > Kathy, > > Yes, we are leaning towards a URL "http" > identifier, thus requiring no additional urn (lsid) > resolution mechanism. Great! And as a reminder, if a resource owner also wants to offer the resolution functionality that LSIDs provide, then the owner could still do that using a special purpose http URI prefix[1], such as http://entrez.example/2007/lsid: . So for a URI like http://entrez.example/2007/lsid:authority:namespace:identifier:revision a naive client dereferencing the URI would thus use HTTP, but an LSID-aware client might access the data using an LSID-aware proxy, which would: - recognize the http://entrez.example/2007/lsid: prefix; - convert it to urn:lsid: and - resolve the result using LSID resolution. Of course, the proxy would not need to be hard-coded to recognize the prefix. It could merely read some string pattern matching rules (or an ontology) to map http://entrez.example/2007/lsid: URIs to urn:lsid: URIs. Furthermore, the resource metadata returned when the http URI is naively dereferenced using HTTP could include a pointer to the URI pattern matching rules (or an ontology), so that an LSID-aware proxy that did not previouly recognize the http://entrez.example/2007/lsid: prefix could be automatically bootstrapped to learn of its special meaning. Reference 1. http://dbooth.org/2006/urn2http/ David Booth, Ph.D. HP Software dbooth@hp.com Phone: +1 617 629 8881
Received on Monday, 26 February 2007 20:14:21 UTC