W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > February 2007

RE: URIs for NCBI data + relevance to proposed URI Resolution ontology

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Mon, 26 Feb 2007 15:14:05 -0500
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C202220EAE@tayexc19.americas.cpqcorp.net>
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


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

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

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.

1. http://dbooth.org/2006/urn2http/

David Booth, Ph.D.
HP Software
Phone: +1 617 629 8881
Received on Monday, 26 February 2007 20:14:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:23 UTC