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

Stuart,

There seem to be two issues worth discussing here:

1. The perceived need for a generic “metadata channel” in HTTP,

2. the perceived need for stronger semantics than 303's “try-over- 
there”.

More inline.

On 6 Feb 2008, at 17:30, Williams, Stuart (HP Labs, Bristol) wrote:
>> There's also the
>>
>>    Link: site.rdf;rel=meta
>>
>> pattern, which seems more or less the same as
>> Resource-Description (except that AFAIK it is intended for
>> use on information resources only).
>
> Ok.. that's interesting, I hadn't come across that - probably  
> looking (or not) in the wrong places - don't remember seeing it in  
> the versions "Cool URIs for Semantic Web" that I've read.

It isn't in Cool URIs for SW, which focuses only on an accessible  
explanation of httpRange-14.

Resurrecting the Link: header has been proposed in a couple of places,  
and has some appeal because of it's similarity to HTML's <link> element.

[snip]
> 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.

Good point.

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

On the other hand it's not evident to me that HTTP *should* have the  
ability to locate metadata about IRs. This problem can be addressed by  
layering another mechanism on top of HTTP, e.g. by embedding the  
metadata in the IR's representation, or linking to the metadata from  
the IR's representation, or by providing the metadata in an external  
well-known location a la sitemaps or POWDER.

I would like to see more evidence that shows a need for a generic  
protocol-level mechanism. Elsewhere in this thread, Jonathan cites  
experiences with LSIDs as one data point. Is there more?

>> Your argument seems to be that 303 redirects are too weak;
>> that the redirect doesn't imply anything more than
>> "try-over-there".
>
> There are some who make that complaint about 303. They want to be  
> able to make stronger assertions at least about what is at the end  
> of the redirect chain - in particular they like to be able to assert  
> that some (architectural) conformance requirement has been violated  
> *if* following the chain does not yield a description of (amongst  
> other things) ?u. IMO 303 does not and cannot give such an assurance.
>
>> I would like to know why more than this
>> weak implication is necessary on the transport layer.
>
> Others will have to speak up on that... but roughly AFAIUI its about  
> what it would mean to conform and detecting when a source has failed  
> to conform.
>
>> Strong
>> "aboutness" and similar relationships can be expressed, if
>> necessary, in a representation made available at the
>> redirection target URI.
>>
>> ...
>
> I agree... but if no such expressions are found after diligently  
> following such a chain, one has no basis for complaint, no stick to  
> wield to say that any one did anything wrong... one can only  
> complain that they weren't as helpful as the could have been.

I don't think that HTTP should come with conformance requirements for  
the content transported with it.

AFAIK, HTTP doesn't have any language that discourages 302-redirecting  
into a 404-responding resource, although obviously doing so is not  
helpful.

AFAIK, HTTP doesn't have any language that discourages serving  
representations that are wildly inconsistent over time, although  
obviously doing so is not helpful.

IMHO, HTTP shouldn't have any language that discourages serving  
totally off-topic stuff at the end of a 303, although obviously doing  
so is not helpful.

HTTP is concerned with the transport of representations of resources.  
The nature and relationships of those representations are a separate  
concern.

Richard



>> Regarding the Resource-PropertyValue header, I propose to
>> generalize it into a Subject-Predicate-Object header. We
>> could build the Semantic Web using only HTTP HEAD. I also
>> propose new HTTP verbs HEADPOST, HEADPUT and HEADDELETE to
>> modify all those new HTTP headers.
>
> :-) I trust that you are joking!

>
>
>>
>> Best,
>> Richard
>>
>
> Regards
>
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> Berks RG12 1HN
> Registered No: 690597 England
> (Tracker, this is ISSUE-57)
>

Received on Thursday, 7 February 2008 11:36:23 UTC