W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2005

RE: [BioPAX-discuss] LSID Best practices...

From: <Eric.Neumann@sanofi-aventis.com>
Date: Thu, 7 Apr 2005 11:20:44 -0400
Message-ID: <81BE96441EAC744B8F6E1E738C53F95801165C73@sccsmxsusr05.pharma.aventis.com>
To: <Eric.Jain@isb-sib.ch>, <bader@cbio.mskcc.org>, <public-semweb-lifesci@w3.org>



I asked Tim Berns-Lee a related question about alternative ways of using URNs for retrievals; specifically, is it proper to concatenate a URL (for an LSID handler) with a URN? Here was the original question:


Is it at all possible to define a URI as the concatenation of a URI and a URN? 

For example (taken from http://lsid.biopathways.org/resolver/):   

   
  	http://lsid.biopathways.org/resolver/data/ +            	urn:lsid:ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:5851672 

 	=> 

 	http://lsid.biopathways.org/resolver/data/urn:lsid: 
	ncbi.nlm.nih.gov.lsid.biopathways.org:genbank_gi:5851672 
 
 
Here was Tim's response:

-----Original Message----- 
From: Tim Berners-Lee [mailto:timbl@w3.org] 
Sent: Thu 3/10/2005 9:28 AM 
To: Neumann, Eric PH/US 
Cc: wilbanks@creativecommons.org; eric@w3.org; em@w3.org; swick@w3.org 
Subject: Re: URIs and URNs : simple resolution? 

Yes, you certianly can do this. 
You'd probably strip off the 'urn:lsid:'


One way is to say that these urns are defined to be equivalent to the  
given http URLs. 
Another way is to say that you are offering a persistent lookup service  
at the http server. 


For example, you will find in W3C archived list email messages a header  
like 


        X-Archived-At:  
        http://www.w3.org/mid/200503091442.43471.vatton@inrialpes.fr 


which indicates that the mail can be retrieved with that HTTP url.  
However, inside 
it you'll see that that HTTP URL is only the message identifier  
expressed as a URI  (mid:) 
and then mapped into an HTTp by the mid: being replaced by  
http://www.w3.org/mid/ 


The HTTP server runs a lookup srvice for the MIDs of any email which  
have been though the 
W3C system. 


---- End of Message ------------

>From his response it is quite clear that a handler URL (by an authority or any other third party) can have the full or prefix-cleaned LSID appended to it (like in the mid: case), and when this new URL is HTTP called, a web-service can handle the resolution directly. All that is needed is for any client or server software to treat LSIDs specially (if someone request for what data and metadata is known about it) creating this new URL/URI with a specified handler URL, and the data or metadata would be returned.

The key point stated by both Eric J and Sean is that the LSID IS A URI, and so is ALWAYS treated as a unique RDF node in a graph. That is a very critical point to be maintained. You do not get this guarentee from using any internal ID, only if the RDF node is unique through the URI.

Beyond that issue, LSID resolution can be done either through internal resolvers, or as Tim says by pointing to and calling external/public resolvers (handlers). The community must decide what are the best practices to adopt, and then we need to agree to follow them.

Eric


> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org
> [mailto:public-semweb-lifesci-request@w3.org]On Behalf Of Eric Jain
> Sent: Thursday, April 07, 2005 10:23 AM
> To: Gary Bader
> Cc: public-semweb-lifesci@w3.org
> Subject: Re: [BioPAX-discuss] LSID Best practices...
> 
> 
> 
> Gary Bader wrote:
> > Is there any standard way of resolving LSIDs that are 
> > used in this way? 
> 
> If you are asking how to actually retrieve the data for an 
> LSID, from the 
> resolution service point of view, then no, I don't think there is any 
> standard way. This is probably one of reasons some people 
> favor the use of 
> URLs as identifiers. I wouldn't go so far, but this is a 
> problem, as this 
> means that your software needs to be "life-science-aware".
> 
> 
Received on Thursday, 7 April 2005 15:20:49 GMT

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