- 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>
On Sat, 2008-02-09 at 21:58 +0000, Booth, David (HP Software - Boston) wrote: > 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! Ian
Received on Saturday, 9 February 2008 22:54:15 UTC