W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2007

Re: identifier to use

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>
Message-ID: <uir76bj3l.fsf@newcastle.ac.uk>

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

Received on Thursday, 23 August 2007 11:12:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:29 UTC