- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Sun, 23 Nov 2003 11:51:57 +0200
- To: "ext Danny Ayers" <danny666@virgilio.it>
- Cc: <www-rdf-interest-request@w3.org>, "Graham Klyne" <GK@ninebynine.org>, "Jim Hendler" <hendler@cs.umd.edu>, "Dan Brickley" <danbri@w3.org>, <www-rdf-rules@w3.org>, <www-rdf-interest@w3.org>
On Friday, Nov 21, 2003, at 20:45 Europe/Helsinki, ext Danny Ayers wrote: > > Ok, I disagree on several of the details in your last response, but I > won't > quibble. I think the list of 4 server requirements you gave (below) > are the > key, and they do nobble the mimetype approach as a general solution. A > good > set of gauntlets for any other proposals to run. > I agree. And I'd like to see them (or something analogous to them) written into the charter of the RDF Query WG. And I left out a few others, that are as important as the other 4: 5. An agent should be able to discern, from the response header alone, whether its request for a description, rather than (some other form of) representation, was understood by the server and if successful, should be able to presume that the response contains a description of the resource. The agent should not have to examine the content of the response to attempt to determine whether it is a description or something else. 6. The solution adopted, should work in a consistent fashion for operations equal or analogous to the methods GET, PUT, and DELETE. 7. An agent, having a URI meaningful to the HTTP protocol, should be able to obtain a description of the denoted resource via a single server request and having no additional knowledge other than the URI itself. These requirements together have never been met by any proposed header based solution, because, even though they might work with GET, they fail requirements #2 and #6 for PUT and DELETE operations, and also, usually #5 and/or #7 as well. I consider the URIQA extensions to be the absolutely minimal extensions necessary to meet all of these requirements. But if someone is able to propose a solution that meets these requirements without recourse to new methods, I'd love to hear it. > This is of course assuming the transport of a description in the form > you > describe is as important as you suggest. It (or something similar) > would > certainly make a lot of operations a lot easier, and oil the cogs. > > I still hold out hope that additional engineering of web servers won't > be > necessary (and rather we didn't just drop into tunnelling the simpler > queries). If an RDF Query WG, or anyone else for that matter, is able to crack this nut without introducing new methods, I'm all for that. I'm not religiously committed to a particular solution -- simply to *some* solution that meets the minimum requirements -- but unless and until someone comes up with something better, URIQA works very nicely and does the job for us. > But failing that I look forward to your instructions for deploying > URIQA ;-) > I will be releasing as open source the code for the Nokia Semantic Web Server, which provides a complete URIQA enabled server implementation, based on Intellidimensions RDF Gateway product. I will also be releasing a simplified implementation, in Java, based on Jena. Both should be available in early/mid January. Regards, Patrick > Cheers, > Danny. > > ... >>> That's a debatable point. The Concise Bounded Resource Description >>> of a >>> resource could be seen as simply just another representation of that >>> resource. >>> >> >> Yes. And I point that out in the URIQA spec. >> >> But the semantics of interacting with descriptions is specialized >> and different in significant ways from the semantics of interacting >> with arbitrary representations. >> >> When communicating with a server: >> >> 1. One must be able to indicate to the server that the request >> concerns >> a description and not a(nother form of) representation. >> >> 2. One must be able to ensure that if the server has no clue what a >> description is, that it won't do something to a(nother form of) >> representation. >> >> Furthermore, >> >> 3. A description is an abstraction for which one should >> be able to use the full richness of web functionality, e.g. content >> negotiation, etc. in conjunction with whatever SW extensions are >> deployed. >> >> 4. The distinction to be made in #1 above should not depend on >> any part of the URI itself (i.e. no special suffixes, etc.) >> >> Thus, #2 above rules out headers with PUT/DELETE, and #3 rules out >> using MIME types or similar hacks. > ... >> In short: URIQA and the RDF Net API are two different kinds of >> protocols. >> Both are needed. >
Received on Sunday, 23 November 2003 04:55:13 UTC