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

Hello Xiaoshu

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
> Sent: 07 February 2008 10:42
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: Richard Cyganiak; www-tag@w3.org; Graham Klyne; Jonathan Borden
> Subject: Re: [httpRedirections-57] Resource-Decription
> Header: a possible proposal to consider.
>
> Stuart,
> >> 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.

Fair enough. However, *if* it turns out to be the case that there is a desire to may arbitrary propery-value assertions (one example of which being a Resource-Description: header and another being a Resource-Type: header - generalising for an arbitrary RDF property value assertion is far more efficient in terms of process (# of IETF drafts or W3C Notes) that need to be run tthrough a standardisation process) and far more flexible. That said, there is nothing that can be said in such PV assertions that couldn't be said by whatever resource is deployed at the other end of a Resource-Description: reference. So... a balance of simplicity, complexity and flexibility.

> First, what are suppose to be in the Site and what in the Description?

Don't understand the question. <...#Site> arose from the context in which Jonathan Borden made the original (in the sense that that's where I first saw it) suggestion rather than as an intrinsic part of what he suggested.

> If the criteria is by format, such as the latter in RDF and
> the former in anything else, then Content-Negotiation already
> do this.

Certainly *if* a thing is self-descriptive, however in general a thing and a description of a thing are distinct resources - and that is not where content-negotiation should be used. Content-negotion is (or should be) used for negotiating between different awww:representations of the *same* thing.

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

I think that it is inescapable that there may be multiple accounts (descriptions) of a given resource, each with their own provenance. Which of those accounts you choose to believe, whether they are consistent with each other or not an whether they are consistent with anything that a self-descriptive resource may say of itself... How you determine that you have in some sense a 'complete' account of some resource (possibly aggregated from many sources - some which you may be skeptical of) is way beyond anything one would expected of humble little header.

> Second, I think the HTTP metadata are supposed to be about
> the message delivered, not the resource that the message
> represents.

I think that you will find that the HTTP spec speaks of entity headers (which largely pertain to a response message itself) along with both request and response headers some of which are about resource(s) (eg: Location:). Jeff Mogul does a good job of examining this in [1] - there may also be more recent works elsewhere.

[1] http://www2002.org/CDROM/refereed/444.pdf

> 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.)
>
> Regards,
>
> Xiaoshu


Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 11 February 2008 12:39:23 UTC