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.


Reply via email to