SPARQL 1.1 comments relating to BINGINGS (also minor editorial comments)

Hello,

Just some comments relating to the current semantics of BINDINGS in the 
SPARQL 1.1 specification relating to a question here [1]. I also have 
minor editorial comment later regarding a lack of examples for 
constructor functions.

It seems that the current definition for BINDINGS is as a table that is 
joined with the query results after the query has been executed. 
However, a substitution of variables would seemingly lead to more 
intuitive results, and allow for interaction with the substitutions 
within the query (e.g., within FILTERs, functions, etc.). I know this 
has probably been discussed before, and while I'm not familiar with the 
particulars, I thought I'd lend my perspective.

An example motivating this latter semantics (direct substitution) for 
BINDINGS is as follows [1]. Consider that you have an integer 0-6 
representing days of the week. Now you want to map that to names of the 
week. Seemingly BINDINGS offers a neat solution for these cases (here 
binding the day integer to 0 for brevity):

SELECT *
WHERE {
     BIND (0 AS ?dayID)

     FILTER (?dayIDCheck = ?dayID)
}
BINDINGS ?dayIDCheck ?dayName {
     (0 "Sunday"@en)
     (1 "Monday"@en)
     (2 "Tuesday"@en)
     (3 "Wednesday"@en)
     (4 "Thursday"@en)
     (5 "Friday"@en)
     (6 "Saturday"@en)
}

This does not work as expected since ?dayIDCheck will be considered as 
UNBOUND by the filter. For me, this leads to unintuitive operation. 
Without the FILTER, the result tuples look like:

=========================================
| ?dayID| ?dayIDCheck	| ?dayName	|
=========================================
| 0	| 0		| "Sunday"@en	|
| 0	| 1           	| "Monday"@en	|
| 0	| 2           	| "Tuesday"@en	|
| ...	| ...         	| ...		|
=========================================

The intuition I hold is that FILTER should be applied directly on the 
result tuples themselves after they are generated (although they can be 
pushed down as an optimisation when equivalent). Again, the intuition of 
the FILTER in the above case does not hold due to the current execution 
of BINDINGS.

(The above use-case can be alterately implemented using nested IFs [2].)

Also, a minor editorial comment: would be great to see an example for 
constructor functions [3]. It took me quite a while to figure out that 
the function name for each cast is the datatype itself, and not the 
strings "bool", "dbl", etc. Admittedly I've only scanned the document, 
but I would not be alone in that. Perhaps I'm also stupid, but I would 
not be alone in that either. Would be great to see an example or two 
here (rather than have to go to the XQuery documentation, Google it, 
find nothing, then guess that the function name is probably the datatype 
URI ten minutes later).

Also, a nested IF example would be a great for [4], just as a hint 
rather than as a necessity.

Cheers,
Aidan

[1] http://answers.semanticweb.com/questions/15441/cases-in-sparql-11
[2] 
http://answers.semanticweb.com/questions/15434/getting-days-of-the-week-from-datetime-in-sparql?page=1#15438
[3] http://www.w3.org/TR/sparql11-query/#FunctionMapping
[4] http://www.w3.org/TR/sparql11-query/#func-if

Received on Wednesday, 28 March 2012 18:32:18 UTC