- From: Aidan Hogan <aidan.hogan@deri.org>
- Date: Wed, 28 Mar 2012 19:31:42 +0100
- To: public-rdf-dawg-comments@w3.org
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