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

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

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Sun, 10 Feb 2008 07:51:06 +0000
To: Ian Davis <lists@iandavis.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: <184112FE564ADF4F8F9C3FA01AE50009DED1018124@G1W0486.americas.hpqcorp.net>

> From: Ian Davis
>
> 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!

I'm not sure I understand what you want to achieve.  In the example above, the user agent cannot GET from the awww:InformationResource that http://example/doc#ir denotes, because that URI has a fragment identifier, and no other URI for it was given.  But caching, content encoding and ranges would still work the same when GETting from http://example/doc, wouldn't they?  And if you want to supply multiple media types you could either do it by supplying the bits in multiple ways:

> >   <http://example/doc#ir> hasBitsInRDF "... [bits go here] ..." .
> >   <http://example/doc#ir> hasBitsInHTML "... [bits go here] ..." .
> >   <http://example/doc#ir> hasBitsInPlainText "... [bits go here] ..." .

(along with corresponding metadata for each media type).

Bear in mind that if the user agent is going to make use of a new Resource-Description HTTP header then it would have to know the conventions implied by that header.  And if we make that assumption then the user agent could just as well be expected to understand a particular set of RDF conventions.

But again, I'm not sure I am understanding what you want to achieve, so if I have missed it please explain.

Thanks


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.
Received on Sunday, 10 February 2008 07:53:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:52 GMT