Re: allow implicitly unbound variables in SPARQL results?

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 aka 
> >


> 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

>  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
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 26 October 2005 13:20:19 UTC