- 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 the 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 of EJ>URLs as identifiers. I wouldn't go so far, but this is a problem, as this 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 client. 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