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

On 2011-02-22, at 03:53, Paul Gearon wrote:

> 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).

My recollection of CONSTRUCT is that the template would match*, but only completely bound triples would be output, so

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

Would give

_:b1 :p 12 .

This seems inline with a usecase for DELETE: "Delete this pattern, and if it exists also this pattern" e.g.

DELETE {
  ?x :name ?name .
  ?x :phone ?phone .
}
WHERE {
  ?x a :Person .
  OPTIONAL { ?x :name ?name }
  OPTIONAL { ?x :phone ?phone }
}

When I wrote this pattern, my intention was that it would delete whatever names and phone numbers for people it could find.

* but actually, I can't find anywhere in the SPARQL 1.1 draft that explicitly says that. Could well be looking in the wrong places though.

- Steve

> 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
>> 
>> 
>> 
>> 
>> 
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Tuesday, 22 February 2011 08:44:19 UTC