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

Re: identifier to use

From: Eric Jain <Eric.Jain@isb-sib.ch>
Date: Fri, 24 Aug 2007 16:44:57 +0200
Message-ID: <46CEEEE9.10804@isb-sib.ch>
To: Phillip Lord <phillip.lord@newcastle.ac.uk>
CC: Hilmar Lapp <hlapp@duke.edu>, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>

Phillip Lord wrote:
> Actually, LSIDs are built on top of HTTP. The initial step is web service and
> http delivered. The second stage is multi-protocol which includes HTTP. 

There are other schemes up for discussion, too, but regarding LSID: If it's 
anyway built on top of HTTP, wouldn't it make sense to also use HTTP URIs?

> The other way to know whether a URI can be resolved is to use a different name
> for those which are not mean to be resolved. 

That could be an argument for URIs with no associated resolution mechanism 
-- assuming unresolvable but resolvable-looking URIs are indeed a problem.

But if you have an LSID, you don't know whether it can be resolved or not 
without trying... and that's going to be a lot more complicated and 
expensive than testing a simple HTTP URI.

> To me it makes no sense to layer multi different protocols over a single
> identifier. Imagine I get an URI like http://uniprot.org/P4543, it could
> be
> 1) a meaningless concept identifier in an ontology
> 2) a URL which resolves to a pretty web page, via a single step process
> 3) a URL which always resolve to the same data 
> 4) A URL which resolves to the current version of some spec like the W3C
>    recommendation pages. 
> 5) A URL which is meant to be considered to be a location independent ID. 
> 6) What ever else we have decided to layer onto the same identifier scheme.
> To me, it doesn't make any sense. 

Great, now we'll need a resolution ontology :-)
Received on Friday, 24 August 2007 14:45:37 UTC

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