>>>>> "EJ" == Eric Jain <[EMAIL PROTECTED]> writes:
EJ> Phillip Lord wrote: >> I don't understand the desire to implement everything using HTTP. EJ> Likewise, I don't understand the desire to implement everything using EJ> anything but HTTP :-) If there is an existing system that is EJ> (incredibly) widely adopted and that can be built upon, surely that's EJ> the way to go? 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. >> Why call lots of things, which are actually several protocols by a name >> which suggests that they are all one. How to distinguish between an HTTP >> URI which allows you to do location independent, two step resolution and >> one which doesn't. Well, one solution would be, perhaps, to call it >> something different, say, perhaps, LSID? EJ> You could have the concept of LS HTTP URIs that follow certain EJ> conventions, may be useful for some, but I don't quite see the problem EJ> with the fact that you will be able to resolve some HTTP URIs, but not EJ> others: The only way to know whether a URI can be resolved or not, in EJ> the end, is to try; some systems just seem to make doing so harder... 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. 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. Phil
