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

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 13:13:51 UTC