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

Re: SPARQL Results Format and Unbound Variables

From: Richard Newman <holygoat@gmail.com>
Date: Sat, 6 Aug 2005 12:31:34 -0700
Message-Id: <07658CD0-0BA8-4D07-AB8D-C1216B0B42EB@reading.ac.uk>
Cc: public-rdf-dawg-comments@w3.org
To: Ron Alford <ronwalf@umd.edu>

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

I see one clear benefit to having an explicit <unbound />: an error  
in serialisation might throw up an empty element, but explicitly  
stating that a variable is unbound disambiguates that. You are  
transferring a little more information.

So, to summarise your point, which is better?

1. Explicit:
   <binding name="..."><unbound /></binding>

2. Implicit:
   <binding name="..." />

3. Very implicit:

or, indeed, an alternative:

4. Alternative:
   <unbound name="..." />

1 is obviously verbose, as your statistics show.
2 is less verbose, and might be a good middle ground, preserving  
element names.

3 is great for some processors -- anything that uses hashes to store  
and access bindings, such as twinql[1], will gain massive speed  
benefits in serialisation (you only have to look at that result hash,  
not generate unbound entries). Tools like this will also have a  
simpler time of parsing back into hashes. It's also the most compact  
format. However, some processors might need to refer to the header.  
I'd welcome opinions from other people who have to process results XML.

4 turns 2 into an explicit statement about the lack of binding, and  
(other than introducing another element name) is arguably `better'  
than 2.

So, my opinion: leave out the element entirely for unbound entries,  
or make the verbose syntax an option in the request. You save  
significant space on some queries, and will also speed up some tools,  
at the cost of losing some (possibly useful) redundancy.

Received on Monday, 8 August 2005 04:18:43 UTC

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