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

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

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Thu, 07 Feb 2008 10:42:05 +0000
Message-ID: <47AAE07D.1040907@musc.edu>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
CC: Richard Cyganiak <richard@cyganiak.de>, "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>

>> Personally I'm uneasy about cramming too much semantics into
>> the transport layer. I think HTTP is about efficiently moving
>> representations of resources back and forth over the network.
>> It is not about describing the nature of resources or their
>> relationships.
>> That's what representations are for. I don't see how
>> Resource-Type, Resource-Description and similar headers
>> improve HTTP's ability to efficiently exchange representations.
> Firstly, I'm not so bothered about Resource-Type:... it was what was mentioned in Jonathans post.
> Secondly, it was not about solving a problem of efficent exchange of representation  - but about providing a means of, given <?u> (a URI) finding a description of ?u (a resource/thing) (which may be definitive or not) rather than a representation of <?u>. Compared to 303, Resource-Description: works uniformly for both 200 responses (=>IRs) and 303 (=>not known to be IR) - which is nice. Some have been complaining that the httpRange-14 resolution does not reliably allow you to find metadata *about* an IR (unless it is self-describing) - this is away of getting to metadata about ?u.
I felt the same as David - not very comfortable to put too much info 
into the header. 
First, what are suppose to be in the Site and what in the Description? 
If the criteria is by format, such as the latter in RDF and the former 
in anything else, then Content-Negotiation already do this.  If it is by 
content, then there must be a clear definition between data and 
metadata, which I doubt that anyone can prescribe.  Thus, instead of 
making it efficient, the approach will make the job of both data 
consumer more difficult because he/she must check both sites just in 
case nothing important is missing.

Second, I think the HTTP metadata are supposed to be about the message 
delivered, not the resource that the message represents.  As David half 
joked later, anything can be moved out of its message into the header 
for the same line of reasoning.  Then, there will soon be request of 
Resource-Foo, Resource-Bar , .... (I have at least seen one request for 
a Resource-Vocabulary tag in other mailing list.)


Received on Thursday, 7 February 2008 10:42:35 UTC

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