Re: identifier to use

>>>>> "MS" == Matthias Samwald <samwald@gmx.at> writes:

  MS> So you want to advertise what can be expected (or NOT expected) before
  MS> the web client starts the retrieval process? 

If we are to use http: based URIs for things which are never meant to be
retrieved (like ontology concepts), then it has to be before the retrieval
process, no? 


  MS> If this is desirable, why could we not, in theory, agree on different
  MS> syntactic hints in normal HTTP URIs?

  MS> For example: http://uniprot.org/P4543_concept
  MS> http://uniprot.org/P4543_web_resource
  MS> http://uniprot.org/P4543_immutable_data
  MS> http://uniprot.org/P4543_location_independent_id_(whatever_that_means)

Yes, we could invent some naming conventions and layer them over the top of
http, at least where http is capable of supporting the requirements; for the
last one, it's isn't. 

  MS> This way, we could also give Semantic Web clients a message like "you
  MS> probably don't really need to resolve this and you can probably not
  MS> expect something when you try, but if you really want to, you
  MS> can". Trying to resolve a URI does not have zero costs for a client
  MS> application, so they would probably try to follow this recommendation to
  MS> avoid unnecessary HTTP GET requests (which, in turn, helps to avoid
  MS> unnecessary net/server load).

  MS> I do not really think that something like this would find widespread
  MS> adoption, but it is certainly still more realistic than inventing and
  MS> agreeing on a wholly new protocol for each.

Well, again, little of LSID is wholly new. In fact, the LSID protocol uses
other, standard protocols.

But inventing a new protocol is precisely what happened when HTTP was
created. Why did we not just reuse ftp? 

I think we are going around in circles here, so I'll leave the conversation
there. 

Phil

Received on Friday, 24 August 2007 13:38:29 UTC