Re: SPARQL Update 1.1 review part1

On 17/02/11 16:42, Paul Gearon wrote:
> Hi Andy,
>
> On Tue, Feb 15, 2011 at 11:58 AM, Andy Seaborne
> <andy.seaborne@epimorphics.com>  wrote:
>> Can we have some test cases for this?  because the details matter :-)
>>
>> Presumably shape matters:
>>
>> DELETE
>>   { _:a :p 12 .
>>     _:a :q ?o .
>>   }
>> WHERE {?s :r ?q OPTIONAL { ?q :s ?o } }
>>
>> Is the expectation that the delete stage effectively use the template as a
>> second round of pattern matching?  I'm assuming it's not on a per-triple
>> basis (as CONSTRUCT eliminates triples with unbounds).
>
> I presuming that the above operation should result in the removal of
> the triple from the following dataset?
> {
> :x :p 12
> }

I have no idea what the right answer is - it depends on whether, for 
rows when ?o is unbound, the triple "_:a :q ?o" is removed then the 
template is applied or if the template is applied, what happens to 
variables, and then the triples with unbounds removed.  Or something 
else entirely.

To include both possibilities in the test data:

:x :p 12 .
:x :r :z .
:x :q 10 .	#?? deleted?

:y :p 12 .
:y :r z1 .
:z1 :s 99 .
:y :q 99 .

The recorded discussions give me insufficient guidance.


>
> I had originally thought that the query could be translated into
> something like this:
>
> DELETE{
>    ?tmp_a :p 12 .
>    ?tmp_a :q ?o .
> }
> WHERE {
>    ?s :r ?q OPTIONAL { ?q :s ?o }
>    ?tmp_a :q ?o .
>    ?tmp_a ?tmp_b ?tmp_c

Interesting possible translation.

(what's ?tmp_b ?)

> }
>
> But that doesn't work, since the lack of bindings for ?o will prevent
> anything from happening. I *think* that the correct equivalent would
> be:
>
> DELETE{
>    ?tmp_a :p 12 .
>    ?tmp_a :q ?o .
> }
> WHERE {
>    ?s :r ?q OPTIONAL { ?q :s ?o }
>    ?tmp_a ?tmp_b ?tmp_c
>    OPTIONAL { ?tmp_a :q ?o }
> }

Maybe but you'll have to explain how that's going to work because I 
don't see the algoroithm to introduce the  OPTIONAL { ?tmp_a :q ?o }. 
The ?o may be a much more complex combination of graph patterns - maybe 
you've seen something I haven't.

I was looking at it as a instantiate-remove cycle:

for each solution to "WHERE {}"
   instantiate template, bnodes as fresh variables.
   if there were bNodes, match template again
     for each possible set of triples
       delete concrete triples
   else # no bnodes
     delete concrete triples

but that is not precise enough with named variables that are unbound.

I'm being to wonder whether this was the right resolution.

	Andy

Received on Thursday, 17 February 2011 17:02:20 UTC