- From: Luke Wilson-Mawer <luke.wilson-mawer@garlik.com>
- Date: Tue, 10 Nov 2009 16:17:47 +0000
- To: Steve Harris <steve.harris@garlik.com>
- CC: Andy Seaborne <andy.seaborne@talis.com>, Paul Gearon <gearon@ieee.org>, public-rdf-dawg@w3.org
Steve Harris wrote:
> On 9 Nov 2009, at 21:56, Andy Seaborne wrote:
>> On 09/11/2009 20:40, Steve Harris wrote:
>>>
>>> It should follow the same rules as CONSTRUCT as far as possible, for
>>> reasons of sanity preservation. However, it's not so obvious what that
>>> means in this case.
As far as I understand it, resolution 5 (here:
http://www.w3.org/2009/sparql/meeting/2009-11-03) means that the update
spec can't depend on CONSTRUCT being changed. If we change CONSTRUCT in
query 1.1 to align with whatever ends up in the update spec, people who
are using update + query 1.0 will end up with a mismatch, although I'm
not sure how much this matters.
>>>
>>> CONSTRUCT mints "new" bNodes when you give it [] or _:b. Isn't it an
>>> error to mention bNodes with the same label in the CONSTRUCT and WHERE
>>> clauses? That makes things a little tricky.
>>
>> Error? - they are different bnodes.
>>
>> A bnode label scope is (1) the BGP in which it appears (pattern) or
>> (2) the template instantiation for CONSTRUCT.
>
> Yeah, but in (1) it's an error for it to appear in two places:
> SELECT *
> WHERE {
> { _:x <p> <o> }
> { _:x <p> <o> )
> }
> as is
> SELECT _:x
> WHERE {
> _:x <p> <o>
> }
> I wasn't sure if it was in CONSTRUCT or not, I guess not. Seems a
> little odd, but OK.
> - Steve
Received on Tuesday, 10 November 2009 16:18:16 UTC