- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 22 Feb 2011 08:43:43 +0000
- To: Paul Gearon <gearon@ieee.org>
- Cc: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 2011-02-22, at 03:53, Paul Gearon wrote: > Hi Axel, > > This is along the lines of what I was first thinking of, though I did > forget about the named GRAPH portions. However, does it address the > question that Andy raised about re-use of the blank node, particularly > where an OPTIONAL binding is introduced? I'll reproduce his example > here: > > 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). My recollection of CONSTRUCT is that the template would match*, but only completely bound triples would be output, so CONSTRUCT { _:a :p 12 . _:a :q ?o . } WHERE { ?s :r ?q OPTIONAL { ?s :s :o } } Would give _:b1 :p 12 . This seems inline with a usecase for DELETE: "Delete this pattern, and if it exists also this pattern" e.g. DELETE { ?x :name ?name . ?x :phone ?phone . } WHERE { ?x a :Person . OPTIONAL { ?x :name ?name } OPTIONAL { ?x :phone ?phone } } When I wrote this pattern, my intention was that it would delete whatever names and phone numbers for people it could find. * but actually, I can't find anywhere in the SPARQL 1.1 draft that explicitly says that. Could well be looking in the wrong places though. - Steve > 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 >> >> >> >> >> > -- Steve Harris, CTO, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 22 February 2011 08:44:19 UTC