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

Re: allow implicitly unbound variables in SPARQL results? (formatting fixed)

From: Jeen Broekstra <jeen.broekstra@aduna.biz>
Date: Thu, 15 Dec 2005 11:07:29 +0100
Message-ID: <43A14061.7050704@aduna.biz>
To: Lee Feigenbaum <feigenbl@us.ibm.com>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Lee Feigenbaum wrote:

> I'd like to add a bit on Elias and my objection to choice 'c'.
> Basically, the results format as it currently stands explicitly makes
> possible multiple ways of processing the results format -- either by
> variable name or by column position, given that the results format
> mandates that the order of the variable names must in each row in the
> resultset must match the order in the header of the result document.
> Option 'c' eliminates the indexed-based approach to parsing the
> results. At the very least, I feel that if the Working Group decides
> on option 'c' than the requirement that variable name order be
> preserved within the resultset should be removed.

I could live with that. It does not make processing any harder in this

> I must say that I, at least, am not particularly swayed by our 
> requirement for a  bandwidth-efficient protocol. Yes, the collapsed 
> version is more efficient, but only for a particular class of queries
>  (those featuring unbound variables). I would much rather publish a 
> less-efficient yet fully functional XML design along with an
> informative pointer to a much-more efficient binary design then
> attempt what I see as a strange compromise. (The flippant side of me
> wants to point out that the results format would be more efficient if
> it only used one-letter element names, as well.)

True, and perhaps slightly less flippant, the use of a binding element 
itself is not really necessary either:

    <bnode binding="foo">bnode1</bnode>

carries the same information. There are definitely several ways to 
optimize the XML format, bandwidth-wise. I think the decision here 
though was that we choose a slightly more elaborate format for better 
clarity, aesthetics if you will.

> Regarding the complexity of the XSLT for the collapsed version. While
> I appreciate Jeen's attempts to demonstrate that it is not 
> particularly difficult to write XSLT for the collapsed result format:
> 1) The technique that Jeen uses of remember positions and then 
> comparing current positions with expected names, is not particularly
>  elegant. Obviously, it is not incumbent upon us to produce a design 
> which allows for elegant processing, but this does bother me.
> 2) More importantly, the XSLT as currently in CVS does not work 
> correctly. I am attaching a sample input result format that produces
>  an incorrect and malformed table when used with this XSLT. I would 
> argue that this is due to the added complexity of the collapsed
> result format.

Thanks for pointing this out. Actually I think it's a result of me
trying to adapt the existing stylesheet rather than creating a new one.
I think that a stylesheet that just iterates over all header fields and
for each field retrieves the corresponding value from the result would
be a much more elegant (and much easier!) way to do it.

So I tinkered a bit, and have cleaned up the 'collapsed' stylesheet. It
now processes the result correctly, I think (and is a lot more elegant
to boot, IMHO). It's available again at:


If nothing else, this whole discussion is a great way for me to get an
XSLT education :)


Jeen Broekstra          Aduna BV
Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
http://aduna.biz        The Netherlands
tel. +31 33 46599877
Received on Thursday, 15 December 2005 10:08:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:49 UTC