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 13:31:17 -0400
To: public-semweb-lifesci@w3.org
Message-ID: <OF27C026BE.D4ED1F30-ON85256FDC.005E2A41-85256FDC.00604081@us.ibm.com>
Sean Martin wrote:
> 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.

EJ>I am not about to claim that there isn't any standard mechanism; the 
EJ>is that at one point someone usually has to get the actual data, and 
EJ>more work is required with a specialized mechanism, as I am sure you
EJ>discovered :-)

Certainly true Eric, although once you have the right client stacks 
installed, there is not much difference between the getURL and the getLSID 
API from the programmers point of view and in fact it is simple to take 
this even one step further.  For instance we have code where we added the 
"lsidres:" protocol to the default java protocol handler that allows us to 
call the standard java.net.url with lsid and we get back an io stream in 
the same way we would if it had been passed a url. Java programs that took 
URL's as input can now also take LSIDs. The lsid protocol handler will of 
course have the option to get a copy of the data requested from a 
multiplicity of places. It is unfortunate that java does not have 
java.net.uri defined as this would have been cleaner. 

Sorry about the repeated note earlier, I thought I had lost it in a crash 
and rewrote it, but it turns out that it was sent. I did change my mind a 
little in the rewrite though :-)

Kindest regards, Sean

Sean Martin
IBM Corp.
Received on Thursday, 7 April 2005 18:15:30 UTC

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