p.s.: I assume that the behaviour for Bnodes in INSERTs is rather the one we know from CONSTRUCT, i.e. having a
new bnode per pattern solution. I realize that the - admittedly sketchy, but hopefully understandable -
definition of Dataset() within [3] is wrong at the moment...
"where Dataset(modify_template, P) is the RDF dataset obtained from taking each query solution in the solution sequence of P, substituting for the variables in the modify_template, and combining the triples into a single (named) RDF graph by set union."
should be
"where Dataset(modify_template, P) is the RDF dataset obtained from taking each query solution in the solution sequence of P, substituting for the variables in the modify_template, and combining the resulting graphs into a single (named) *RDF graph merge*."
I hope I can provide some test cases/examples that back that up before the next TC.
cheers,
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