W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: [TF-LIB] BNode

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Fri, 12 Mar 2010 17:29:17 +0000
Message-ID: <4B9A79ED.5090809@talis.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT