- From: Phillip Lord <phillip.lord@newcastle.ac.uk>
- Date: Thu, 23 Aug 2007 12:12:14 +0100
- To: Eric Jain <Eric.Jain@isb-sib.ch>
- Cc: Hilmar Lapp <hlapp@duke.edu>, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
>>>>> "EJ" == Eric Jain <Eric.Jain@isb-sib.ch> 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
Received on Thursday, 23 August 2007 11:12:24 UTC