W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2004

Re: Use of LSIDs in RDF

From: Greg Tyrelle <greg@tyrelle.net>
Date: Thu, 15 Apr 2004 16:27:26 +1000
To: Marja-Riitta Koivunen <marja@annotea.org>, Martin Senger <senger@ebi.ac.uk>
Cc: public-semweb-lifesci@w3.org
Message-ID: <20040415062726.GB16999@nodalpoint.org>

*** Marja-Riitta Koivunen wrote: 
  |>   I am not sure how to answer this ultimate question. Perhaps I need to
  |>understand more about HTTP URIs in order to give comparison with the URN
  |>used in LSID spec. To be honest I have tried to find more and I gave up
  |>after reading very nice article about HTTP URIs by Tim Berners-Lee
  |>(http://www.w3.org/DesignIssues/HTTP-URI.html) that gave me feeling that I
  |>am out of the league :-(

I am by no means an expert on this either :)

How URIs are used in the web architecture and the semantic web
architecture are contentious issues to say the least. Given the
importance of standardisation for the life sciences e.g. MAGE, I am
simply trying to understand how identifier schemes such as LSID fit
into the current thinking about the semantic web and URIs.

  |I think the question is mainly why reinvent a  wheel that already exixts.

Precisely.

  |Using persistent HTTP URIs is a good goal because it is standard and there 
  |exists a lot of HTTP based applications e.g. browsers that understand HTTP 
  |URIs and can provide information of the resource on the Web without 
  |anything extra.

This is the exactly the context in which I was trying to raise the
issue of using LSIDs in RDF. Technically speaking there is nothing
wrong with the current LSID specification IMO. However if I want to
allow other users to dereference LSIDs that my authority mints, it
requires me to maintain an LSID resolver. Clients must also have the
necessary libraries to dereference the LSID.

Having this infrastructure in place adds a practical burden to using
LSIDs which would go away if LSIDs were to be specified in terms of
HTTP URIs. Which, if we assume persistence is an organisational issue,
then HTTP URIs are just as good as URNs. While the RDF spec says
nothing about URIs being dereferenced to provide representations, my
practical expectation is that they should i.e. it makes that resource
more useful if I can get either a representation of that resource or
metadata about that resource.

The LSID does specify interfaces for retrieving metadata about a LSID
which is a good thing. However I'll leave the "how to get metadata
about a resource" question for later...

This leads of course to the thorny issue of whether HTTP URIs are
names or locations or both. My simple view on this is that a HTTP URI
is a name in the same sense that the LSIDs are names, however it *may*
also be dereferenced to provide a representation of the resource that
it is naming (using the existing web infrastructure).

  |When somebody defines a URN they can usually as well reserve a HTTP URI 
  |e.g. http://www.lsid.org/ and define URIs under it e.g. 
  |http://www.lsid.org/path.../enzyme1.

This maybe one possible solution, however the LSID spec says nothing
about this.

  |Why we are now ALSO discussing of using UUID URNs is because we have 
  |problems with local file: type URIs (file: URIs e.g. file//marja/myfile123) 
  |and we want to make them unambiguous when a user cannot do HTTP URIs maybe 
  |because a user does not own a http:// domain name where to publish it or 
  |for some other reason.

I can see this as an issue for individuals creating local stores of
annotated bookmarks. In the case of the life sciences it would be
easier to control as any authority using HTTP URI based LSIDs would
need to have a http:// domain name to participate.

  |After publishing we mostly want to use the HTTP URIs to be able to benefit 
  |from the common Web standards. But it is also possible for some application 
  |to benefit from the URN bit of the information when so wished.

Maybe there is a best of both worlds approach ?

_greg

-- 
Greg Tyrelle
Received on Thursday, 15 April 2004 02:36:52 UTC

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