W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

Re: [BioRDF] All about the LSID URI/URN

From: Phillip Lord <phillip.lord@newcastle.ac.uk>
Date: Tue, 25 Jul 2006 17:55:42 +0100
To: public-semweb-lifesci@w3.org
Message-ID: <uk661tyi9.fsf@newcastle.ac.uk>

>>>>> "HST" == Henry S Thompson <ht@inf.ed.ac.uk> writes:

  HST> Sean Martin writes:

  HST> So, register one of lsids.org, lsids.net, lsids.name or
  HST> lsids.info, and use e.g. http://lsids.or/xxx instead of
  HST> URN:LSID:xxx.  Bingo -- no new tools required, works in all
  HST> modern browsers :-).  

But if the file you are referencing is, say 5Tb, then it doesn't work
in a browser at all. With LSID's on the other hand, you may get back a
choice of methods to access the data, including one which can cope
with 5Tb of data. 

Incidentally, the approach that you are suggesting demonstrates that
LSIDs could be used in concert with URIs. In which case, putting
"http://" into the LSID adds nothing. This is, in fact, exactly how
DOI's work. But the resolution through the doi.org proxy is a
convention which can be changed without changing the dois. 

Sean is entirely correct that encoding the protocol for the transport
layer and a DNS based resolution host into the identifiers is a recipe
for instability; maybe not a problem for many things, but a disaster
for many parts of bioinformatics. I do not still want to be doing
synonym resolution when I am 60.

What I have totally failed to understand about this discussion is why
it has been couched in terms of whether we should use LSIDs or
URIs. Of course, LSIDs non standard protocol in a pain, and the two
step resolution adds latency. But, this is the cost for circumventing
URIs protocol dependency which is also difficult. 

We should just circumvent this entire discussion about which
identifier is perfect for bioinformatics because I can tell you the
answer straight out. None of them. LSIDs answer a need. So, people use


Received on Tuesday, 25 July 2006 16:55:55 UTC

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