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

On Feb 6, 2008, at 10:30, ext Richard Cyganiak wrote:

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


Something like http://sw.nokia.com/uriqa/URIQA.html  ???

We've been using this approach successfully for years at Nokia... FWIW.

Patrick



> 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 Tuesday, 12 February 2008 16:55:35 UTC