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

Stuart,

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

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.

Your argument seems to be that 303 redirects are too weak; that the  
redirect doesn't imply anything more than “try-over-there”. I would  
like to know why more than this weak implication is necessary on the  
transport layer. Strong “aboutness” and similar relationships can be  
expressed, if necessary, in a representation made available at the  
redirection target URI.

...

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.

Best,
Richard


On 6 Feb 2008, at 13:11, Williams, Stuart (HP Labs, Bristol) wrote:

>
> I wanted to resurface an idea that I can trace back to being  
> 'buried' deep in a email message from Jonathan Borden [1] when the  
> httpRange-14 permathread was in it's infancy (there may have been  
> earlier incarnations of similar a idea). Jonathan's email is on a  
> different topic and appears at the end rather of the message:
>
> The Idea:
> ---------
> <quote>
> I generally agree. "Site" is one type of resource, perhaps its special
> enough to get its own HTTP header (?) but why not just (example HTTP
> response headers):
>
> Resource-Type: http://example.org/siteOntology#Site
> Resource-Description: http://example.org/site.rdf
>
> would solve this problem, as well as [httpRange-14] in a general  
> fashion.
> </quote>
>
> Discussion:
> -----------
> At the time the idea passed by uncommented upon - probably unnoticed.
>
> I came across the idea when the mime of a "Resource-Description"  
> header struck me, did a Google search because I couldn't believe it  
> would not have been though of before and found Jonathan's message.  
> This was at a time when the httpRange-14 resolution would have been  
> regarded as an uneasy peace - in need of some time to settle rather  
> than being distrubed... howvever time has moved on... and I think it  
> is appropriate to resurface Jonathan's buried idea.
>
> I think this would address the problem of: "
>
>        Given a reference to a thing (IR or nonIR... generically a  
> thing, anything)
>        how do I (or my agent) find out *about* what that thing is.?"
>
>
> A Resource-Description: header on a 200 or 303 response would  
> explicitly refer you to a resource that the authority deploying a  
> URI for the original thing regards as descriptive of it (extended  
> metadata if you like that you'd be hard pressed to fit in existing  
> headers and which itself is *not* a awww:representation of the  
> referenced thing).
>
> This is stronger than the "303 'try-over-there <Location:>' 'hint'"  
> because the intention of the Resource-Description: is (or would be)  
> clear.
>
> Following a Resource-Description: reference that fails to yield a  
> description of the referenced thing create a detectable error or  
> 'conformance violation'. That will need some careful definition  
> because IMO it would be wrong to restrict the media type of  
> (representations of) such descriptions. So, an error of this kind  
> could only be sanctioned if no descriptive representation obtained  
> at all, or when it has a media-type that the retrieving agent  
> 'understands' and it contains no description of the original subject.
>
> In addition the narrative definition these header could be augmented  
> with (RDF) assertions that use of the header licenses
> eg:
>        Given a request with a request URI of <?u> (referring to  
> resource ?u) AND
>
>        a corresponding 2xx or 3xx response carrying one or more  
> headers
>        of the form "Resource-Description: <? 
> d>"                              AND
>
>      ?d does infact describe  ? 
> u                                                   THEN
>
>        ?u :hasDescription ?d .
>
> And probably some other rules for asserting error situations. Also,  
> there probably needs to be more consideration of precidence rules  
> with respect to the <?u>'s taken from request lines agains <?u>'s  
> taken from Content-Location: headers - maybe assertions should be  
> applied using both URI.
>
> Jonathan's  "Resource-Type:" header is interesting as well, but I  
> think less crucial.
>
> Varations
> ----------
> A slight variant of Jonathan's proposal based on a suggestion from a  
> colleague
>
>        Resource-PropertyValue: <?propertyURI> <?propertyValue>
>
> where ?propertyValue is either another URI or a simple literal value  
> (more depth thought required - but http/mime header character  
> constraints apply).
>
> This header would allow an derived RDF assertion of:
>
>        ?u ?propertyURI ?propertyValue .
>
> A property could then be define to signify :hasDescription property  
> above or rdf:type (expanded as a URI) could be used similar effect  
> to Jonathan's Resource-Type: header.
>
>
> Any way... I think that the bones of a proposal are clear. Three  
> possible RDF header definitions required:
>
>        Resource-Description:
>        Resource-Type:
>        Resource-PropertyValue:
>
> Worth Doing?
> ------------
> So... does the idea of legs... or will it die on the spike?
>
> Is anyone already engaged in trying to do something similar in  
> spirit? One well thoughout and supported approach is going to be  
> better than a multipicity of diverse but similarly intentioned  
> approaches each attracting their own communities.
>
> I guess I'd be willing to carry the ball *if* there were enough  
> feedback that it is a ball worth carrying.
>
> If so... what does it take to make it happen?
>
> Community buy-in, an internet-draft, experimental implemention and  
> in the long run, HTTP header registrations in the IANA registry [1]?
>
> How long could that take? Hmmm...
>
> Stuart
> --
> [1] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0006
> [2] http://www.rfc-editor.org/rfc/rfc3864.txt
> [3] http://www.iana.org/assignments/message-headers/message-header-index.html
>
> (Tracker, this is ISSUE-57)
>
>
>
>

Received on Wednesday, 6 February 2008 16:30:56 UTC