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

Re: Bnodes in DELETE templates (was: SPARQL Update 1.1 review part1)

From: Paul Gearon <gearon@ieee.org>
Date: Mon, 21 Feb 2011 22:53:15 -0500
Message-ID: <AANLkTi=Fw1aQA3Ch=B4ggHCkxPCcCDgSQ3Y6O=HzzrzZ@mail.gmail.com>
To: Axel Polleres <axel.polleres@deri.org>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Hi Axel,

This is along the lines of what I was first thinking of, though I did
forget about the named GRAPH portions. However, does it address the
question that Andy raised about re-use of the blank node, particularly
where an OPTIONAL binding is introduced? I'll reproduce his example
here:

DELETE
 { _:a :p 12 .
   _:a :q ?o .
 }
WHERE {?s :r ?q OPTIONAL { ?q :s ?o } }

So when that is applied to the following data:

:x :p 12 .
:x :r :z .
:x :q 10 .

The model you've proposed will certainly match the first triple in the
template for removal, but the ?o will be unbound, so what happens to
that part of the template? Does it get ignored, or does it prevent the
entire template from matching? (The latter is more in line with
CONSTRUCT and INSERT, but doesn't really work well with the proposed
formal model).

Is each part of the template treated as if it is a separate thing to
be deleted, or does the re-use of the same blank node label (_:a in
this case) have some kind of effect?

Regards,
Paul

On Mon, Feb 21, 2011 at 3:10 AM, Axel Polleres <axel.polleres@deri.org> wrote:
> Thanks Greg for spotting this! Actually, there were two mistakes in the P_B
> pattern below...  see inline.
>
>
> On 20 Feb 2011, at 23:40, Gregory Williams wrote:
>
> On Feb 18, 2011, at 1:31 PM, Axel Polleres wrote:
>
>> For any unnamed bnode _:B in a modify_template_DEL
>> (i) new variables ?Var_B ?Var_B1 ?Var_B2 ?Var_Bg are introduced,
>> (ii) _:B is replaced by ?Var_B in a modify_template_DEL,
>> (iii) Pattern P is replaced by P_B such that
>>
>>  P_B =  { P } UNION {
>>          SELECT DISTINCT ?Var_B
>>            {  { ?Var_B ?Var_B1 ?Var_B2 } UNION
>>               { ?Var_B1 ?Var_B ?Var_B2 } UNION
>>               { ?Var_B1 ?Var_B2 ?Var_B } UNION
>>               { GRAPH ?Var_Bg {?Var_B1 ?Var_B2 ?Var_B } } UNION
>>               { GRAPH ?Var_Bg {?D1 ?Var_B2 ?Var_B } } UNION
>>               { GRAPH ?Var_Bg {?Var_B1 ?Var_B2 ?Var_B } } }
>>
>> That is, ?Var_B binds to all possible values in the vocabulary of GS.
>
> I'm not totally swapped in on this issue, but I don't understand how this
> pattern aligns with the description. In all three named graph union
> branches, ?Var_B appears in the object position. Since ?Var_B is the only
> projected variable, don't these three branches return the same results?
>
> yes, that was a copy-paste error from an earlier version I had. The correct
> one should be
>     P_B =  { { P } { Q } }
> i.e. join, not UNION (thanks Andy, for pointing me to that offlist), where Q
> is defined as below...
>
>> I know that the definition of P_B doesn't look very nice, but this
>> definition should cover the intended semantics of [2].
>> In principle, the idea is that bnodes, that should behave as wildcard
>> should bind to *any* element in the signature of GS,
>> which is what is returned by the subquery
>>        Q = SELECT DISTINCT ?D
>>            {  { ?D ?D1 ?D2 } UNION
>>               { ?D1 ?D ?D2 } UNION
>>               { ?D1 ?D2 ?D } UNION
>>               { GRAPH ?Dg {?D1 ?D2 ?D } } UNION
>>               { GRAPH ?Dg {?D1 ?D2 ?D } } UNION
>>               { GRAPH ?Dg {?D1 ?D2 ?D } } }
>
> ...corrected version of Q:
>
>         Q = SELECT DISTINCT ?Var_B
>
>             {  { ?Var_B ?Var_B1 ?Var_B2 } UNION
>
>                { ?Var_B1 ?Var_B ?Var_B2 } UNION
>
>                { ?Var_B1 ?Var_B2 ?Var_B } UNION
>
>                { GRAPH ?Var_Bg {?Var_B ?Var_B1 ?Var_B2 } } UNION
>
>                { GRAPH ?Var_Bg {?Var_B1 ?Var_B ?Var_B2 } } UNION
>                { GRAPH ?Var_Bg {?Var_B1 ?Var_B2 ?Var_B } } }
>
> Even more obvious in this one. Am I missing something?
>
>
> Hope I got it right now ;-)
>
> Thanks,
> Axel
>
> thanks,
> .greg
>
>
>
>
>
Received on Tuesday, 22 February 2011 03:53:48 GMT

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