- 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 issue EJ>is that at one point someone usually has to get the actual data, and here 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