AW: Content negotiation flamewar (was: Re: "Hash URIs" and content negotiation)

In litteris suis de Montag, 13. November 2006 11:33,
semantic-web-request@w3.org <>scripsit:

Hi all,

> On 13 Nov 2006, at 06:03, Alan Ruttenberg wrote:
>> Why can't our agents retrieve RDF (and RDF only) when they need
>> discovery information like this.
> 
> Because the Web is designed to be data format agnostic. The
> only reason why we can contemplate evolving the HTML-based WWW
> into an RDF- based Semantic Web today is because the Web was
> designed to be usable with any kind of data format in the first place.
> 
>> Here is another proposal. Conneg is vastly simplified: For uri U, the
>> only option is to retrieve RDF instead of the resource. That rdf
>> would itself be given a name(URI) distinct from U. That rdf returned
>> neither describes U, nor what U is about (so if U names an rdf
>> document, the conneged RDF is not the same as the RDF resource U
>> names). Rather it is RDF that describes the set of documents that
>> the server considers relevant to serve in place of U. These can
>> either be rdf:about the same subject (such as translations in
>> different human languages), or same as the document, where sameas
>> means there is a lossless, unambiguous, machine implementable
>> translation between the two documents (same size gif->png ok gif-
>>> jpeg quality 8 not ok). The RDF would use some standard set of
>> relations to describe the relationship of the proposed documents to
>> U, and various properties of these documents (like their file
>> formats, languages, etc).  Based on this information, the agent can
>> decide whether the original document, or some other, is relevant to
>> retrieve for the task at hand. In a browser, I would expect the
>> browser to show me a different URI in the address bar if an
>> alternate document was chosen.
> 
> Let's take this a bit further.
> 
> First, the proposal requires two HTTP requests to retrieve a
> representation. I think we can do better. The client could
> indicate in its request that it prefers a representation with
> certain features, and the server would send along the best
> match if availabe.
> This should be optional of course. The server should be
> allowed to leave the choice entirely to the client, and the
> client should be able to indicate that it only wants the
> format inventory and no matching representation.
> 
> Second, in the vast majority of cases, a client will be
> interested only in *one* representation, and the other URIs
> and details of the other representation in the response will
> just be noise. So, to keep bandwidth down and to keep
> client-side processing simple, the server should tailor the
> answer so it just contains
> 
> - the URI where to find the best-matching representation, and
> - indications about how the other available representations
> differ from that one.
> 
> The client could then vary its request to ask for the location
> of other representations.
> 
> Third, the proposal requires all Web clients to support RDF.
> That's a heavy burden, because at the moment HTTP is such a
> simple protocol, and RDF parsers are fairly complex. So let's
> encode the format inventory in a simpler way. How about HTTP
> headers? They are dead easy and have been around since forever.
> 
> Oh, but all of this is already available in HTTP/1.1, and
> implemented in today's HTTP clients.
> 
> In summary, the proposal doesn't add new capabilities to the
> Web, requires all HTTP clients to support the complex RDF
> syntax, increases the minimum number of requests to retrieve a
> representation from one to two, increases bandwidth usage, and
> removes the format- neutrality of the Web infrastructure. I'm
> afraid it won't be popular.

<disclaimer>
I'm not very experienced with all this stuff, so please bear with me if
I say something stupid
</disclaimer>

So, someone wants to access http://example.com/resources/foo which is
the URI for the resource "foo". In the accept-header, the client
indicates that it prefers application/rdf+xml . The server finds out
that it has a rdf/xml representation under
http://example.com/resources/foo.rdf and sends this back WITHOUT A
REDIRECT. Instead it sets the Content-Location header to
http://example.com/resources/foo.rdf to indicate that the returned
content was not at the requested URI, but at the specified location.
Similar of course for all other formats (like text/html).

On the surface it seems clean, but something tells me that this is not
compatible with http-range-14 ...

Can anyone please tell me I'm wrong?

Lars
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationstechnik
Adickesallee 1
60322 Frankfurt
http://www.d-nb.de/

Received on Monday, 13 November 2006 12:38:37 UTC