Re: Uniform access to descriptions

Pat Hayes wrote:
> 
> Its not a RE invention. Nothing about the current Web changes at all: 
> it allows for a new way of using some existing Web technology, is 
> all. This way is rational and seems to conform to the current 
> architecture, provided we are willing to think a little outside of 
> our current box. And this might come as news to non-semantic Web 
> mavens, but wa are already outside that box. We've been outside it 
> ever since the TAG insisted that URIs can identify non-information 
> things.
> 
> In fact, if we were to agree on some simple protocols for content
> negotiation which themselves referred to http codes, it could provide
> a uniform mechanism for implementing the http-range decision.
> 

My thoughts exactly.  URI [a] below identifies "a wiki page" whose topic
is part of the identifier, and it is a negotiated resource.

[a] http://example.org/topic
[b] http://example.org/topic.html
[c] http://example.org/topic.xhtml
[d] http://example.org/topic.rdf

Client dereferences [a], preferring text/html. Response to [a] is 200
OK, Content-Location [b].  Client dereferences [a] preferring
application/xhtml+xml.  Response to [a] is 200 OK, Content-Location
[c].  Thus, it may be inferred from the response codes that [b] and [c]
identify equivalent representations, or variants, of the resource
identified by [a], "topic".  Also, [b] and [c] are not representations
of the concept, "a wiki page".

Client dereferences [a], preferring application/rdf+xml.  Response to
[a] is 200 OK, Content-Location [d].  Thus, it may be inferred that [d]
is also a variant of the resource identified by [a], "topic".  This
works perfectly well, if in fact [d] is an RDF representation of
"topic" and not a description of resource [a] as "a wiki page".
However, what if topic.rdf contains only the assertion that [a] "is a"
"wiki page", which *is* a description of resource [a]?

Client dereferences [a], preferring application/rdf+xml.  Response to
[a] is 303 See Other, Location [d].  This clearly means that no RDF
variant is available, however, the client _may_ be interested in a
_related_ resource of the preferred type.  Client dereferences [d],
response is 200 OK.  Clearly, dereferencing [d] has not returned a
representation of the resource identified by [a]. The client parses
topic.rdf, which describes [a] as a type of resource known as "a wiki
page". Thus, [d] is a representation of a description of "a wiki page"
and not a representation of "topic" or even a description of "topic".
Resource [d] can be said to describe resource [a], but it is clearly
not a representation of the resource identified by [a].

Under "true conneg", if [d] is not considered a variant of the resource
identified by [a], and a client dereferences [a] but only Accepts
application/rdf +xml, then a 400 Bad Request would normally be issued.
But, if [d] exists and is a *description* of the resource identified by
[a], why return an error message for [a] when we could return "See
Other"? This approach breaks nothing, far as I can tell. The corollary
here, is if a client dereferences [a] but only Accepts text/css, the
server *could* 303-redirect the request to a shared CSS file.  This
would be of absolutely no use, of course, but it wouldn't be invalid to
do it in terms of Web architecture.

-Eric

Received on Sunday, 13 April 2008 22:25:16 UTC