>>>>> "EJ" == Eric Jain <[EMAIL PROTECTED]> writes:
EJ> Phillip Lord wrote: >> Actually, LSIDs are domain specific, or rather they were designed to >> support the needs of the Life Sciences; this is not to say that different >> domains do not have the same needs. EJ> You're right, that's a better way to put it! >> Look at DOIs and LSIDs. They are different, they emphasise different >> things. LSIDs are based around a set of objects which potentially might >> be very large and which might exist in many versions. So LSIDs have >> two-step multi-protocol resolution. They have version numbers >> integrated. They exist in a world where services disappear. So LSIDs have >> a fail over mechanism. EJ> If I have an LSID like urn:lsid:uniprot.org:uniprot:P12345 and EJ> uniprot.org disappears (assuming there was even a resolver running there EJ> in the first place), how is that URI going to be more useful than a EJ> simple HTTP URL like http://purl.uniprot.org/uniprot/P12345? If you are EJ> lucky and happen to have a copy on some local server (which you may EJ> prefer to use even otherwise), what's the big deal with using a normal, EJ> off-the shelf URL rewriting proxy? 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. 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. Phil