Re: identifier to use

>>>>> "EJ" == Eric Jain <Eric.Jain@isb-sib.ch> 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

Received on Friday, 24 August 2007 10:19:04 UTC