Phil wrote: > 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. So you want to advertise what can be expected (or NOT expected) before the web client starts the retrieval process? If this is desirable, why could we not, in theory, agree on different syntactic hints in normal HTTP URIs? For example: http://uniprot.org/P4543_concept http://uniprot.org/P4543_web_resource http://uniprot.org/P4543_immutable_data http://uniprot.org/P4543_location_independent_id_(whatever_that_means) This way, we could also give Semantic Web clients a message like "you probably don't really need to resolve this and you can probably not expect something when you try, but if you really want to, you can". Trying to resolve a URI does not have zero costs for a client application, so they would probably try to follow this recommendation to avoid unnecessary HTTP GET requests (which, in turn, helps to avoid unnecessary net/server load). I do not really think that something like this would find widespread adoption, but it is certainly still more realistic than inventing and agreeing on a wholly new protocol for each. cheers, Matthias Samwald . -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
