- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 12 Feb 2008 12:22:02 -0600
- To: "ext Jonathan Rees" <jar@creativecommons.org>
- 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>
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 UTC