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

P.P.S.: Reconsidering it, I *think* that the intended DELETE behavior can be achieved by an even much simpler rewriting of P:

Let modify_template_DEL' be defined as above, but P' simply 

    P' = { {P} {modify_template_DEL'} }

that should be enough: the pattern solutions for modify_template_DEL' yield all the possible 
bindings for the "bnode-variables" and return possible bindings for all other variables.
by joining these with the original P, only those bindings for the other variables "survive" that also fit the original WHERE pattern P.

I think that should be sufficient, but I still have to check it in detail. Some test cases will follow shortly in a separate email.

Axel


 
On 18 Feb 2011, at 21:31, Axel Polleres wrote:

> 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 Sunday, 20 February 2011 19:41:34 UTC