- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Fri, 12 Mar 2010 17:29:17 +0000
- To: Axel Polleres <axel.polleres@deri.org>
- CC: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 12/03/2010 5:00 PM, Axel Polleres wrote: > One should note that - strictly speaking - bnodes aren't really variables in the > WHERE part, they just "boil down" to variables there by requiring (simple) > entailment for BGP matching, agree? No. They are non-distinguished variables. [[ 4.1.4 Syntax for Blank Nodes Blank nodes in graph patterns act as non-distinguished variables, not as references to specific blank nodes in the data being queried. ]] which is agreed text from the different interested parties from DAWG. > Summarising: I (*chair*) certainly wouldn't be a roadblock to BNODE(), but I see > two views on this issue, the second being my (*personal*) understanding that treating > Bnodes BGPs uniformly the same way as in CONSTRUCTs would not cause harm, but that > this behavior farily intuitively can be extended to expressions (both in SELECTs and FILTERs). As you were the driver for having BNODE, or some such, a mechanism for the only reason why nested CONSTRUCTs might be needed, I see little support for the feature. Let's just drop it - it's already in a time-premitting feature only. Re-interpretation of SPARQL 1.0 is not worth the effort. Andy
Received on Friday, 12 March 2010 17:29:34 UTC