W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > May 2005

Re: SQI: Related Work to SPARQL Protocol

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>
Message-ID: <20050513131509.GD22493@monkeyfist.com>

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

Just looking at the table of SQI methods from


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


     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

  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

     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

Note, this isn't an official WG response to yr comments, just the
opinion of one member, speaking for himself.

Kendall Clark
Received on Friday, 13 May 2005 13:15:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC