- From: David Booth <david@dbooth.org>
- Date: Thu, 26 Jan 2012 11:19:18 -0500
- To: Jonathan A Rees <rees@mumble.net>
- Cc: Pat Hayes <phayes@ihmc.us>, public-awwsw@w3.org
I would paraphrase these architectures as: > A. The Ian Davis architecture - a GET/200 URI can identify anything. "By fiat, a GET/200 response means that the URI identifies that web resource, UNLESS the response content is an RDF/XML document, in which case the URI identifies whatever the RDF/XML document says it identifies." > B. The Roy Fielding architecture - a GET/200 URI identifies a "fiat" > (REST) resource. "By fiat, a GET/200 response means that the URI identifies that web resource." > C. The TimBL architecture - a GET/200 URI identifies a "generic" resource. "By fiat, a GET/200 response means that the URI identifies that web resource. And don't mint a URI that ambiguously identifies both a web resource and a toucan, because toucans are not web resources!" (I'm using the term 'web resource' instead of 'information resource' to avoid the assumption that they are disjoint with anything.) Note that neither A nor B prevents a URI from ambiguously identifying *both* a web resource and a toucan. But the GET/200 response by itself only implies -- and this is by fiat -- that it is a web resource. The URI owner can still declare that the resource is *also* a toucan. Only C would prevent the URI from ambiguously identifying both a web resource and a toucan -- merely because it says that a toucan is not a web resource. But, while well intentioned and useful as simple pragmatic advice, this admonition against minting an ambiguous URI is fundamentally impossible to follow when examined in more detail. The reason is that in general a URI does not *directly* identify a resource. Rather, it identifies a resource *indirectly*, through a *description*. That is the only practical means that we have, for a URI owner to indicate what resource the URI is intended to identify. And it is not generally possible to provide a completely unambiguous description, because one can always make finer distinctions -- distinctions that may not matter to some applications, even though they are crucial to others. For example, many applications will function perfectly well with a URI that ambiguously identifies both a document and a toucan -- producing correct output 100% of the time -- while other applications would be hopelessly confused and produce wrong output. We have no choice but to learn to deal with this ambiguity. This all plays out very cleanly in the RDF semantics, because the semantics do not in general define a unique interpretation for a URI. Rather, they constrain the set of possible interpretations. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Thursday, 26 January 2012 16:19:42 UTC