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

Hello Henry,
Apologies if at any point I appear to be shifting the goal posts on you, 
but the LSID scheme seems to have been developed in response to a 
significant list of requirements gathered from a large number of stake 
holders  across the Life Science industry, so there is a fair amount of 
thinking behind what it has to do which may not be immediately apparent.

> 
> So, register one of lsids.org, lsids.net, lsids.name or lsids.info,
> and use e.g. http://lsids.or/xxx instead of URN:LSID:xxx.  Bingo -- no
> new tools required, works in all modern browsers :-).  Implement as
> much or as little redirection, caching etc. as you wish in the server
> you run at lsids.info:80, just as you would using DDDS.

The problem with this approach is that individual Life Science 
organizations want to create their own LSIDs for private and some times 
public consumption as well as consume those provided publicly or privately 
by their partners, colleagues and government. Organizations may easily be 
responsible for creating many hundreds of thousands of identifier name 
digital objects (gene sequences, image/x-ray/cat/mri scans, spreadsheets, 
intermediate 'in-silico' experiment processing results, 'in-silico' 
experimental provenance etc). Some times they will do this offline or 
behind corporate firewalls. Many are likely to be extremely unwilling to 
use a centralized approach to naming and resolution for privacy as well as 
scaling & availability concerns.
 
Quite a number would like to be able to make permanent archive copies of 
named objects and keep them behind their firewalls so as to be able to 
keep knowledge of their access private, but still continue using the 
public name.


> 
> > LSIDs are independent of any particular transport protocol and
> > indeed already make use of any of the commonly used ones
> > simultaneously (ftp, http, SOAP, file:// etc). The thing to remember
> > here is that we are not thinking about URIs in the abstract here,
> > but rather a 'living, breathing system' intended for naming digital
> > objects that will be copied/archived far and wide. It was deemed
> > important to support as many mechanisms as possible (including
> > future ones) to support that copying/archiving process without
> > losing track of the unique name.
> 
> So all LSID clients have to support all those protocols?  Doesn't
> sound like a likely route to wide deployment. . .  Or are you proxying
> all requests through a few central servers, who choose what protocols
> to use for the initial fetch?  If so, no problem doing that with
> 'http'-scheme URIs either. . .

Both of these approaches are in practice today. The two major browsers 
have plug-ins that allow them to directly resolve LSIDs and there is also 
software available that allows anyone to quickly implement their own web 
gateway like the one at http://lsid.biopathways.org/resolver/ 

However another and perhaps more common use at least in the early adopter 
community is to access LSID dereferenced information programmatically. 
More likely than not, there is nothing much useful to actually 
see/manipulate in a web browser when looking at the results of an LSID 
dereference - at least not for a human! There are at least three or four 
software language library client stacks freely available that anyone can 
use in their programs for automation of processes that include data with 
LSID naming. When you get down to it, it does not take much to get client 
library coverage across the languages that are commonly used to program 
Life Sciences applications, especially since the base libraries (DNS, WWW, 
and Web Services) are already ubiquitous. 

Kindest regards, Sean

--
Sean Martin
IBM Corp.