W3C home > Mailing lists > Public > www-tag@w3.org > February 2008

RE: [httpRedirections-57] Resource-Decription Header: a possible proposal to consider.

From: Ian Davis <lists@iandavis.com>
Date: Sat, 09 Feb 2008 22:49:04 +0000
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
Message-Id: <1202597344.11814.26.camel@localhost>

On Sat, 2008-02-09 at 21:58 +0000, Booth, David (HP Software - Boston)
> Okay, if you want fewer round trips, then the following technique could be used instead.   Publish the URI http://example/doc#ir to denote your desired awww:InformationResource.  When an app attempts to follow its nose to learn what resource that URI denotes, it will dereference the racine http://example/doc , whereupon you can serve RDF saying something like this (in n3):
>   <http://example/doc#ir> hasResourceDescriptionAt "http://example/doc/metadata" .
>   <http://example/doc#ir> hasBits "... [bits go here] ..." .
> which of course would be nearly equivalent to returning a Resource-Description HTTP header, and it would be just as easy to check conformance.

How would this support content negotiation on the Information Resource?
Or content encoding, ranges or caching? I suppose you could write some
RDF to support them but aren't you just going to end up reimplementing
HTTP in RDF which is then to be transmitted over HTTP!

Received on Saturday, 9 February 2008 22:54:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:55 UTC