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

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

From: Sean Martin <sjmm@us.ibm.com>
Date: Thu, 7 Apr 2005 12:40:21 -0400
To: public-semweb-lifesci@w3.org
Message-ID: <OF62B2FD13.395753C7-ON85256FDC.00533858-85256FDC.005B96A8@us.ibm.com>
EJ>Gary Bader wrote:
GB>> Is there any standard way of resolving LSIDs that are
GB>> used in this way?

EJ>If you are asking how to actually retrieve the data for an LSID, from 
EJ>resolution service point of view, then no, I don't think there is any
EJ>standard way. This is probably one of reasons some people favor the use 
EJ>URLs as identifiers. I wouldn't go so far, but this is a problem, as 
EJ>means that your software needs to be "life-science-aware".

Unless I have completely misunderstood Gary's orginal question as stated 
above, I disagree. There is a standard [1] for dereferencing any LSID and 
retrieving its associated data and metadata documents. This is part of the 
 OMG LSID specification and has been implemented in a number client/server 
language stacks. My own team implemented [2] this standard when creating 
fully client/server protocol stacks for perl, java and a Windows COM 

In general any LSID name is mapped by the data provider down to a 
collection of ftp/http URLs or web services that the client stack may 
discover and use to retrieve the associated information. This means the 
data bytes for the same object may simultaneously be made available from 
more than once place (hmm..perhaps we should now add bit torrent like 
support to the client software to take advantage of this) as can metadata 
documents. In the case of metadata documents this feature of the protocol 
is useful since it means that metadata information from 3rd parties can be 
incorporated along with that provided by the data provider and seamlessly 
integrated by the clients for a user.

Kindest regards, Sean

[1] http://www.omg.org/docs/dtc/04-05-01.pdf
[2] http://sourceforge.net/projects/lsid/

Sean Martin
IBM Corp.
Received on Thursday, 7 April 2005 16:40:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:23 UTC