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: Sun, 10 Feb 2008 11:24:48 +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: <1202642688.3981.24.camel@localhost>

On Sun, 2008-02-10 at 07:51 +0000, Booth, David (HP Software - Boston)
> > From: Ian Davis
> > 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).

This is what I meant when I wrote "I suppose you could write some RDF to
support them". I appreciate you could do it, but it seems unusual to
want to recreate the metadata/content model that HTTP already provides
in a layer on top of HTTP. Isn't that the kind of path that SOAP took?

> 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.

I think there's a big difference between defining the semantics of a
single header versus creating a whole transfer scheme in RDF.

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

The simplest way of linking an information resource to a description of
it without altering the information resource.

> Thanks
> David Booth, Ph.D.


Received on Sunday, 10 February 2008 11:30:00 UTC

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