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

Stuart,

Some disconnected thoughts...

-  Personally, I find the approach is appealing (except extending it to 
Resource-PropertyValue, which I'm not convinced is really helpful).

- I think this approach could play well with an idea that Steve Pepper submitted 
to the WWW2006 identity and reference on the web workshop, "The Case for 
Published Subjects" (see http://www.ibiblio.org/hhalpin/irw2006/), which I felt 
at the time was generally well-liked by those present.

- the mechanisms may work fine when the protocol is HTTP, but what about when 
FTP is used.  I guess it's no worse in this respect than the current TAG 
recommendation.

- Re. Sean Palmer's Internet draft:  simply publishing an I-D will not, of 
itself, cause a new header field to be registered.  The author shoulkd create a 
permanent document somewhere (publishing the I-D on the W3C site is technically 
OK, but IETF people have an expectation that I-Ds are transient, so making it a 
W3 Note or similar might be more appropriate), then request review for inclusion 
as a provisional header field.  To achieve permanent header field status, 
evidence of community consensus or widespread use should be offered - one way 
would be to propose it for standards-track approval in the IETF, or similar in W3C.

- there is a kind-of precedent for this .. in a past life, we prepared a 
proposal for email which became part of the VPIM document set: 
http://www.ietf.org/rfc/rfc3458.txt (in this case, the new header field was not 
so clearly semantic in intent, but it addressed a similar tricky issue that had 
been raised).

#g
--


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

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Thursday, 7 February 2008 08:56:45 UTC