Re: [BioRDF] All about the LSID URI/URN

Hello Dan,

> Thanks for continuing to explain the requirements. I haven't seen
> LSID requirements that can't be met with http/DNS yet, but that
> doesn't mean they're not there.
>
> Yes, it's easy to see how starting fresh simplified some things.
> But I am not convinced that starting fresh is the only option,
> nor that working within the constraints of http/DNS won't give
> a lot more benefit for approximately the same investment.
> 
> 

I don?t know exactly why a URN style identifier was chosen over a http 
style URI for LSIDs as I was not involved at the time. My educated guess 
is that for a number of the reasons I have detailed in my earlier posts 
http URLs, as understood in common practice then & indeed now, were not 
seen to exactly fit all the requirements generated when an exact fit was 
required for them to actually be useful to their fairly fractured 
community. Nuance detail is important in this problem and I can see from 
your last reply that we are not meeting there at many levels. 

In particular though I suspect the highly distributed nature of the Life 
Science community, the perceived fragility of URL links and the URL's 
ambiguous technical/social contracts were major motivating factors and 
also the successful application of such a scheme internally by a number of 
the standard initiators.  In circumstances where there were (and perhaps 
are still) not enough obvious standards, guidance & best practices 
available to show how to make http URLs fit this particular bill, it is 
perfectly understandable why they fell back on the URN specifications.  In 
those there was clear guidance about how to make persistent identifiers 
that would work. Given the existence of other substantial persistent 
identifier efforts (e.g. ARK and DOI), it seems to me they were not alone 
nor unreasonable in their thinking. 

I was involved in the decision making surrounding the choice of the 
dereferencing protocol for the LSID standard and know that it was 
purposely based on as many preexisting existing standards as possible, 
namely the DDDS RFCs (for URN dereferencing), DNS SRV records (for service 
discovery) and SOAP/WSDL (for communicating metadata/data end points) as 
well as the common web protocols for transport (http, ftp, file://, SOAP) 
given that much data that required naming was already accessible online. 
It was entirely deliberate that as much existing precedent be used as 
possible and consequently little of the LSID protocol specification is 
completely new invention.

That said, I can also see the great benefits to allowing direct http URL 
style access to information named using the LSID scheme, which is why I 
personally would be much inclined to back the suggestion by Henry Thompson 
that the LS community go the extra step in the standard to establish the 
necessary mechanisms to link LSIDs to the web using the pattern he 
suggested from the ARK group. 

>From my point of view,  we finally have an extremely hard won LSID 
standard which is already being usefully put into practice by various 
groups in the Life Sciences community. This is no small achievement.  It 
has a fairly clear social/technical contract, although I believe there are 
improvements that can be made in the area of metadata. It seems to me that 
it, f is best used for uniquely naming LS digital objects - anything one 
can think of today as a file but there are also other valid uses.   In 
addition it seems perfectly valid to use an LSID as a URI in RDF because 
it is a URN and URNs are URIs. We intend to go on doing so while we find 
it useful for our purposes. What would be marvelous would be to start 
defining the scope of the metadata returned so we can take the existing 
usefulness to the next level.

I will look forwards to talking with you next week. Have a great weekend 
everyone.

Kindest regards, Sean

--
Sean Martin
IBM Corp