W3C home > Mailing lists > Public > www-tag@w3.org > February 2008

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

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Tue, 12 Feb 2008 12:22:02 -0600
Message-Id: <EAFB3F0D-3EA5-4628-899B-5D4DC1B80607@nokia.com>
Cc: ext Richard Cyganiak <richard@cyganiak.de>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
To: "ext Jonathan Rees" <jar@creativecommons.org>


On Feb 12, 2008, at 12:08, ext Jonathan Rees wrote:

>
> On Feb 12, 2008, at 11:47 AM, Patrick Stickler wrote:
>>
>> Something like http://sw.nokia.com/uriqa/URIQA.html  ???
>>
>> We've been using this approach successfully for years at Nokia...  
>> FWIW.
>>
>> Patrick
>
> Yes, very much like that, but dissing the answer to your question
> "Why not first use a HEAD request to get another URI via which the  
> description can be accessed?"
> which is what we're proposing here.
>
> I like the FAQ, but the way - concise and useful.
>
> Technically your solution is superior, I think, but it has a larger  
> implementation burden.

I think that depends on the underlying server implementation.

Our implementation on top of RDF Gateway was almost "trivial" to  
integrate. We
simply associated the required behavior with the new methods. Granted  
the
server platform was pretty flexible about supporting custom methods,  
and not
all server platforms are, but in our case at least it was very easy.

It also maintains a clean separation between the traditional HTTP  
verb semantics
(dealing with representations) and the new URIQA verb semantics,  
dealing with
descriptions; and also allows one to serve descriptions of resources  
which (for
various reasons) do not have accessible representations (e.g. perhaps  
you have not
subscribed to a service, so can't access via GET, but can at least  
get descriptive
information about it, or perhaps the resource has been retired, and  
there is no
alternative representation for which a 302 or 303 is appropriate, etc.)


> Link: or Resource-description: can be implemented directly in  
> Apache 2.3 configuration files with no additional programming,  
> while MGET would require some changes to the server code.

Actually not. You can hook the URIQA behavior into the 500 response  
behavior. There
were some examples some time ago using PHP, but other options likely  
exist. Apache
allows servers to provide custom responses to 500 errors -- and that  
response may
very well be to first look if the "unsupported" (by the core Apache  
server) method
is a URIQA method, and if so, respond accordingly -- otherwise, treat  
it as a real
error.

>
> The fact that the same functionality has been designed and  
> implemented over and over again suggests that a standardization  
> effort would pay off.

Quite. I've often wished for enough time to implement an Apache  
module for URIQA,
but my plate remains overfull with my "real" job.  I keep hoping  
someone with
more time and energy will beat me to it (anyone know a research  
student needing
a project? ;-)

Cheers,

Patrick


>
> Jonathan
>
Received on Tuesday, 12 February 2008 18:35:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:52 GMT