- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 13 May 2005 09:15:09 -0400
- To: Bernd Simon <bernd.simon@wu-wien.ac.at>
- Cc: public-rdf-dawg-comments@w3.org, Erik Duval <Erik.Duval@cs.kuleuven.ac.be>, Stefaan Ternier <stefaan.ternier@cs.kuleuven.ac.be>, Daniel Olmedilla <olmedilla@l3s.de>, "zoltan.miklos@wu-wien.ac.at" <zoltan.miklos@wu-wien.ac.at>, Frans Van Assche <frans.van.assche@eun.org>, David Massart <david.massart@eun.org>, massimo@w3.org, "stefan.sobernig-wu-wien.ac.at" <stefan.sobernig@wu-wien.ac.at>
On Thu, May 12, 2005 at 04:10:32PM +0200, Bernd Simon wrote: > > Hi, > > Throughout the last 2 years a group of 20+ researchers have been > investigating the issue of query protocols in the context of the R&D > projects ELENA, ProLearn, Ariadne, ICLASS, .... As a result of that work > the Simple Query Interface was designed as a query-language neutral > interface for exchanging queries. Hi Bernd, I think the Data Access Working Group has some different goals and objectives with regard to protocol design than the group that produced SQI. Just looking at the table of SQI methods from http://www.wu-wien.ac.at/usr/wi/bsimon/publikationen/sqi-www-2005-05-10.pdf I can see the following significant differences: 1. we don't push any session management into the protocol itself, letting people rely on the "host" protocol mechanisms for managing sessions, which means that we are unlikely to have anything like SQI's createSession, createAnonymousSession, destroySession, and setMaxDuration (if my guess is correct about what that does) operations. 2. we don't determine result set formats procedurally, a la setResultsFormat; rather, we rely on the implicit fact that in SPARQL, there are query forms tied to particular kinds of result formats. ASK and SELECT query forms return XML result formats, according to the Variable Binding Results spec which is at http://www.w3.org/TR/2004/WD-rdf-sparql-XMLres-20041221/ CONSTRUCT and DESCRIBE return canonical RDF/XML, unless otherwise arranged. That is, we also rely on HTTP's native content-negotiation mechanism for allowing a client and server to negotiate for some other, say, serialization of RDF; or, for that matter, for transforming XML results into XHTML or SVG or whatever. 3. As for setMaxQueryResults and setResultsSetSize, there are two points to be made: first, in the knowledge base, RDF, Description Logic worlds of the Semantic Web, databases can act v. differently from SQL or XML databases. The closed versus open world assumption is one reason for these differences, and the ability to do formal inference is another reasons. But, second, and more to the point, we have put something like these two SQI methods into our query language itself, rather than in the protocol. One tradeoff of this design, of course, is that SPARQL protocol can't apply result set or query result limits to an RDF query language other than SPARQL, at least if it doesn't have those notions already in it. I think the WG is generally aware of this tradeoff; but yr message should make it more aware, so thanks. 4. Finally, as to the synchronous and asynchronous styles of query, again, we're tied pretty closely, by charter, to HTTP, and that dictates a synchronous style of interaction. Asynchronous query is possible in HTTP, if you add some stuff, but we haven't really talked about this at all. I don't know if WSDL's SOAP bindings give you asynchrony at all; if so, we might not have to solve this ourselves. But asynchrony hasn't come up in discussion, at least that I remember; and we certainly never took that on as a design objective or requirement. > I have not investigated the SPARQL protocol a lot, yet, but the first > thought that came up to my mind was, why SPARQL would need its own > protocol Well, probably strictu sensu, we're not designing a *new* protocol as much as specifying how to use at least one existing protocol, HTTP, that is, more like a subset or a profile of an existing profile (and while there may still be SOAP bindings, they wouldn't be a new protocol either). > and why the query API issue is not covered at a more general level at W3C? Ah, that I cannot answer. We were chartered to build a SPARQL-specific protocol, and I can see that SQI is meant to be more general. I don't know why the XQuery WGs didn't build a protocol; but even if they had, we might well have chosen to "do our own thing", consistent with whatever changes an XQuery protocol might have made to the DAWG charter. Note, this isn't an official WG response to yr comments, just the opinion of one member, speaking for himself. Best, Kendall Clark
Received on Friday, 13 May 2005 13:15:46 UTC