- From: Eric Jain <Eric.Jain@isb-sib.ch>
- Date: Fri, 24 Aug 2007 16:44:57 +0200
- 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