Re: URL +1, LSID -1

On Thu, 12 Jul 2007 09:22:54 -0700, Roderic Page <r.page@bio.gla.ac.uk>  
wrote:


> You can NOT assume this:
>
>>   - otherwise, maybe the authority itself has a resolver at
>> http://foo.bar:8080/authority where foo.bar = the authority name
>> (thanks Mark W)
>
> Not every authority is on port 8080, nor does the authority resolver
> have to have the same name as the authority in the LSID. This is why
> you really want to look up the SRV record then pull off the WSDL file
> describing the authority.


 From what I gather talking to the developers, the existing LSID client  
stacks will go through the process of DDDS, then SRV, and if all else  
fails, they will look for a resolver at http://foo.bar:80/authority  (not  
:8080).  These are just various levels of fail-over, with that last level  
being quite badly documented and perhaps only a code-implementation rather  
than being an explicit part of the LSID spec (but since the HCLS group is  
going to be making recommendations, this is a minor point since we could  
recomend that it becomes part of the spec).  Nevertheless, that last level  
is quite useful, especially for entry-level LSID users!  Certainly it was  
at that level that I set up my first LSID resolver on my laptop computer 4  
years ago, and it significantly lowers the bar for people to start using  
the spec "in anger".


> LSIDs can be a bit complicated, but at
> least there is a very explicit protocol for getting the metadata (you
> don't have to guess, it tells you exactly how to retrieve it).

Agreed!  I like Eric's content-type negotiation also, but I like how the  
LSID gives me various possible endpoints for data and/or metadata... and  
moreover, these *don't* have to be simple "GET", but could be Web Service  
interfaces... which means that the LSID spec is ready for the next big  
step in Semantic Web evolution, which would be integration of Web Services  
into the fray!!

(again, I suggest that we think carefully about using URLs to solve a  
problem that they weren't designed to solve, and in fact, a problem that  
we haven't fully comprehended yet... in a world that already has billions  
of URLs that *don't* behave the way we probably want them to...)

M




-- 
--
Mark Wilkinson
Assistant Professor, Dept. Medical Genetics
University of British Columbia
PI Bioinformatics
iCAPTURE Centre, St. Paul's Hospital
Tel:  604 682 2344 x62129
Fax:  604 806 9274

***CONFIDENTIALITY NOTICE***
This electronic message is intended only for the use of the addressee and  
may contain information that is privileged and confidential.  Any  
dissemination, distribution or copying of this communication by  
unauthorized individuals is strictly prohibited. If you have received this  
communication in error, please notify the sender immediately by reply  
e-mail and delete the original and all copies from your system.

Received on Thursday, 12 July 2007 17:59:15 UTC