> From: Eric Neumann [mailto:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Phone: +1 617 629 8881