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

On 22 February 2011 03:53, Paul Gearon <gearon@ieee.org> wrote:
[snip]

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

In Lee's original discussion of the bnode issue
(http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0428.html),
he writes:
"And note that:
   DELETE { ?unbound :p :o } WHERE { }
...doesn't remove anything at all. ?unbound is (as its name implies) not
bound in the single solution; when this solution is applied to the
template, we get an invalid triple (because of the unbound variable),
and nothing is removed. (The current editor's draft does not spell this
out, but this is the analogous behavior to CONSTRUCT templates, and I
assume we have consensus around this.)"

Unless this has changed, also the above example shouldn't remove
anything because ?o is unbound.

However, Lee also wrote
"=== Behavior of DELETE ===
The full form of DELETE is
   DELETE { template } WHERE { pattern }
The semantics are that pattern is matched against the graph store,
yielding a solution set (a set of solutions; each solution is a set of
variable bindings; each variable binding is a pairing of a variable plus
an RDF term). Each solution in the solution set is then inserted into
the template in turn, resulting in ground triples. Each of these ground
triples is removed from the graph store (either from the graph store's
single "unnamed graph", or from the graph specified in the WITH clause,
or from the graph specified inline with a GRAPH clause."

In particular "resulting in ground triples" is just not true if the
template has bnodes because the bnodes are not changed by applying the
solution mapping and any triple with bnodes in it is not ground, see
RDF Semantics http://www.w3.org/TR/rdf-mt/#graphdefs Section 0.3: "A
ground RDF graph is one with no blank nodes."

If we really would only delete ground triples, then we won't have
problems and I have to say that I am very inclined to suggest sticking
to that, i.e., if applying the solution mapping does not yield ground
triples, nothing is being deleted.

This has the disadvantage that deleting lists is not that easy, but
apart from that no complicated rewritings and query pattern extensions
are required.

Birte

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



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Tuesday, 22 February 2011 18:17:06 UTC