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...
