W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: allow implicitly unbound variables in SPARQL results?

From: Dan Connolly <connolly@w3.org>
Date: Wed, 26 Oct 2005 08:19:59 -0500
To: Jeen Broekstra <jeen@aduna.biz>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-Id: <1130332799.27261.510.camel@dirk>

On Wed, 2005-10-26 at 15:04 +0200, Jeen Broekstra wrote:
> Dan Connolly wrote: 
> > This request seems pretty reasonable:
> > 
> > [[ There are at least two ways to trim the results back down with 
> > just syntax changes.  The least intrusive change would be to just 
> > drop the <unbound> tag, and have it be implicit with <binding 
> > name=".."/>.  More drastic is to just drop the entire <binding> tag
> >  when the variable is unbound, since the information can be 
> > retrieved from the head. ]] -- SPARQL Results Format and Unbound 
> > Variables http://www.w3.org/mid/42F4CEEB.5090306@umd.edu aka 
> > http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Aug/0043

[...]

> Also, of course, as Steve already mentioned, it makes writing XSLT
> forms for query results quite a bit harder.
> 
> The major argument in favor of the change is the size of the
> serialized result set in cases like queries with UNION, or with lots
> of optionals. However, IMHO minimizing the size of the serialization
> has never been a major design goal of the XML result format,

Perhaps you missed a bit of WG history...

[[
4.7 Bandwidth-efficient Protocol

The access protocol design shall address bandwidth utilization issues;
that is, it shall allow for at least one result format that does not
make excessive use of network bandwidth for a given collection of
results.
]]
 -- http://www.w3.org/TR/rdf-dawg-uc/#d4.7




>  nor
> should it be.

Taken literally, that's a request to reconsider objective 4.7.
I'm not going to take you literally, for now.

>  To be blunt: if you want to minimize the number of bytes
> on the line, use compression, or better yet, dump XML and use a binary
> format.

If you're interested in fleshing out a design using compression
or a binary format, perhaps the WG would support that and the
commentor would be receptive. Note that the comment comes with
measurement numbers, like any design in this space should.

> 
> Of course that does not mean that we should never care about the
> verbosity of the XML result format, but I think that in this case
> there are significant disadvantages to allowing this, against a
> advantage of which I am uncertain there are not other, better ways of
> solving it.
> 
> In the request, another option was mentioned: not dropping the
> <binding> element, but dropping <unbound> (and hence having an empty
> <binding> element). Although slightly more regular this is still more
> expensive to process than the current LC format. As an example of
> this: the current Sesame SPARQL XML result parser completely skips
> binding elements and just jumps directly to the uri, literal, bnode or
> unbound element. In the proposed format, this will no longer be
> possible and instead it will have to do a check for each binding
> element to see if it contains a subelement.
> 
> Not saying that that is fiendishly difficult to do of course, but it
> does make processing, or writing XSLT, more complex.
> 
> Long story short: I have a preference for keeping the spec the way it
> is now.

Do you have any argument that you think would satisfy the commentor?

> By the way, if size of the serialization does become a major design
> goal, there are other, more obvious changes to make to the format: the
> binding element could be dropped altogether, for example. I'm not
> advocating this, I think regularity and ease of processing are more
> important features than number of bytes.
> 
> Jeen
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Wednesday, 26 October 2005 13:20:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT