Re: identifier to use

Phillip Lord wrote:
> As I understand it, there is a fail over mechanism. If uniprot.org falls over,
> the first resolution step can be performed by an LSID server not at
> uniprot.org. I can't remember exactly how this works, as I haven't read the
> spec for ages. 

Do you mean fail over at run time, so when an identifier can't be resolved, 
the resolver retries with a backup service? I don't recall seeing a 
description of such a mechanism in the specs, but that wouldn't prevent you 
from implementing a resolver that supports this. Of course you could also 
implement an HTTP proxy with such a mechanism, if it is desirable. Perhaps 
someone who is familiar with existing LSID resolver software can comment?

In general, my feeling is that there are lots of special mechanisms that 
may be useful for some application (but overkill for others), but I don't 
see any strong arguments why these couldn't be implemented with HTTP URIs 
(which have the benefit that they can also be made usable in simple ways).


> As far as I can see, LSIDs are basically location independent. The only whole
> I can see is if someone else buys uniprot.org, sets up an LSID resolution
> service and then returns crap. purls have the same issue I think. 

Yes, I guess that's a problem with all solutions that make use of the 
domain name system in some way. (But I still think the benefits of doing so 
outweigh the problems that are introduced by not using it.)

Note that any other name-based registration system could run into trouble, 
too: Let's say UniProt lost a trademark suite and was forced to change its 
name to something else, I assume that wouldn't be good for "location 
independent" identifiers such as urn:bm:uniprot:P12345...

Received on Thursday, 23 August 2007 12:19:43 UTC