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

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

Received on Friday, 18 February 2011 21:47:53 UTC