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

Comments on SPARQL Query Results XML Format

From: Arjohn Kampman <arjohn.kampman@aduna.biz>
Date: Wed, 23 Mar 2005 11:07:24 +0100
Message-ID: <42413FDC.8090800@aduna.biz>
To: public-rdf-dawg-comments@w3.org

Dear all,

Here's another round of feedback, this time on the query results format.
The feedback is based on version 1.20 (2005/02/28) of the editor's

* The current specification only lends itself for encoding bindings of
   values to variables. This is due to the fact that variable names are
   used as tag names. If, at some point in time (but hopefully soon:-)),
   the SPARQL language is changed to allow functions and/or operators in
   the projection, the format as it is defined now is no longer usable.
   To be a little more specific: if SPARQL would allow functions and/or
   (aggregation) operators in the SELECT-clause, then the query result
   can no longer be seen as a variable binding. Some (pseudo-) examples
   to clarify this:


   Q2: SELECT concat(X,Y), sum(A,B) WHERE ...

   IMHO, it would be wise to create a format that is more flexible with
   respect to such future extensions.

* I think the choice to use variable names for tags is poor one. Not
   only because of the things that were said above, but also because it
   will probably make validation harder. At least, the current format
   does not allow one to define a (fixed) DTD for it.

* The use of a non-fixed set of tags doesn't make it easier to parse
   back a query result the SAX-way. With a fixed set of tags, the SAX
   listener could have responded to method calls for specific tags. As it
   is now, a SAX-based parser will have to keep track of whether the
   reported element is a child of a <result> element, or it has to check
   if any of the element's attributes indicates that it is a value.

   Note that this procedure also has to be applied to the set of tags
   that are defined for the format, as this set is not disjunct with the
   set of variable names. A hopefully clarifying example:

     SELECT ?sparql ?results ?result ?boolean-result
     WHERE { ... }

   Example output:
     <?xml version="1.0"?>
     <sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
         <variable name="sparql"/>
         <variable name="results"/>
         <variable name="result"/>
         <variable name="boolean-result"/>
           <sparql bnodeid="r2"/>
           <results uri="http://work.example.org/bob/"/>
           <result xml:lang="en">Bob</result>
           <boolean-result uri="mailto:bob@work"/>

   Not a pretty sight, if you ask me...

* All unqualified tags are part of the namespace
   effectively making this a namespace with a dynamic set of elements.

* Conceptually, the boolean result doesn't have anything in common with
   the variable binding result, so why use the same format? IMHO, it
   doesn't make much sense; this is the most complex format for
   communicating a simple yes/no that I've ever seen.

   Also, because the same document structure is used, one has to analyze
   the complete document before one can decide whether it represents a
   variable binding- or boolean result.

   I would suggest to use a dedicated format for the boolean result.
   Something like the following would be a good alternative:

   <?xml version="1.0"?>
   <sparql-ask xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">

All in all, based on the above comments, I would like to ask the DAWG to
_please_ consider dropping the idea on using variable names for tags and
instead adopt a format with a fixed DTD. For example something like:

<?xml version="1.0"?>
<sparql-select xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result">
   ...  head ...
       <bnode var="x" id="r2"/>
       <uri var="hpage">http://work.example.org/bob/</uri>
       <literal var="name" xml:lang="en">Bob</literal>
       <literal var="mbox">bob@work</literal>


Arjohn Kampman

Aduna BV - http://aduna.biz/
Prinses Julianaplein 14-b, 3817 CS Amersfoort, The Netherlands
tel. +31-(0)33-4659987  fax. +31-(0)33-4659987
Received on Wednesday, 23 March 2005 10:07:57 UTC

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