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

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

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 18 Feb 2011 21:31:40 +0000
Cc: Lee Feigenbaum <lee@thefigtrees.net>, Paul Gearon <gearon@ieee.org>, Alexandre Passant <Alexandre.Passant@deri.org>, Andy Seaborne <andy.seaborne@epimorphics.com>
Message-Id: <1EC52EE8-5AEF-4D55-B7E4-F490772D7A87@deri.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Hi all,

 Alex and I took a stab on the formal semantics these last few days [1], and indeed I now 
realize that we missed out the resolution about blank nodes in DELETE templates acting as 
"wild cards"[2] (although that omission was mentioned in my original review :-) we simply 
forgot it).

However, there's a mostly straightforward fix to this, I believe, see below.
If agreeable, I can work this into the spec, together with Alex.

best,
Axel

===========================================================================

Take the definition of OpDeleteInsert [3]
-----------------------------------------------
 OpDeleteInsert(GS, modify_template_DEL, modify_template_INS, P) = Dataset-UNION(Dataset-DIFF(GS, Dataset(modify_templateDEL,P)), Dataset(modify_templateINS, P))
-----------------------------------------------

This needs to be modified as follows:

-----------------------------------------------
 OpDeleteInsert(GS, modify_template_DEL, modify_template_INS, P) = Dataset-UNION(Dataset-DIFF(GS, Dataset(modify_templateDEL',P')), Dataset(modify_templateINS, P))
-----------------------------------------------

where modify_template_DEL' and P' are obtained by the following preprocessing step:

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. 

Then, modify_template_DEL', and P', respectively, denote the modify_template 
and pattern obtained by applying this rewriting repeatedly for any bnode 
in modify_template_DEL and starting with the original pattern P.


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


Alternatively, (which might be more elegant, but I can't really get my head around it this hour of the day) 
we could define the behaviour more semantically, instead of rewriting P, by joining the pattern solutions for P with a 
"universal binding" Omega_U(Var) = { (?X , term) | term in signature(GS) }. It should be obvious, that Q returns exactly Omega_U(?D).

So, summarising, I obviously mean by no means to suggest that this is a way to *implement* the feature, but it doesn't seem to be a big deal 
at all to refine the semantics to cater for the behavior given in the resolution, all is needed is a modification of OpDeleteInsert.

best,
Axel


1. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#formalModelGraphUpdate
2. http://www.w3.org/2009/sparql/meeting/2010-03-09#resolution_2
3. http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#def_deleteinsertoperation
Received on Friday, 18 February 2011 21:33:15 GMT

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