Re: SPARQL Update 1.1 review part1

On Thu, Feb 17, 2011 at 12:01 PM, Andy Seaborne
<andy.seaborne@epimorphics.com> wrote:

In an effort to keep the size of my emails manageable, I'm trying to
just leave local context for my replies.

<snip/>
>>> DELETE
>>>  { _:a :p 12 .
>>>    _:a :q ?o .
>>>  }
>>> WHERE {?s :r ?q OPTIONAL { ?q :s ?o } }

<snip/>

>> 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.

I agree that I can't tell for sure. But my reading on the "wildcard"
requirement for the blank node (_:a) made me think that the part of
the template that doesn't include the ?o {_:a :p 12} should be applied
regardless.

> To include both possibilities in the test data:
>
> :x :p 12 .
> :x :r :z .
> :x :q 10 .      #?? deleted?

I don't see how. That would require the ?o to be bound to 10 at some
point, but this doesn't happen. Am I missing something? Is this the
data that you meant to post?

> :y :p 12 .
> :y :r z1 .
> :z1 :s 99 .
> :y :q 99 .
>
> The recorded discussions give me insufficient guidance.

It seems pretty clear that the second part of the data will have [:y
:p 12] and [:y :q 99] removed, leaving just:
 :y :r z1 .
 :z1 :s 99 .

But I don't know what happens if ?o never gets bound.


>> 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 ?)

Just a variable that isn't used anywhere else. Instead of using it, I
could have said:
DELETE{
  ?tmp_a :p 12 .
  ?tmp_a :q ?o .
}
WHERE {
  ?s :r ?q OPTIONAL { ?q :s ?o }
  ?tmp_a :q ?o .
  ?tmp_a [] []
}

The point was to bind ?tmp_a to everything that ever appears as a
subject. I didn't care about the predicate and object positions.

>> 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.

My view was unfortunately simplistic. The general idea was:

1. If a blank node appears in the template in an otherwise grounded
triple pattern (as in {_:a :p 12}) then treat the blank node as a
variable, and introduce a new pattern to the WHERE clause which binds
that variable to everything. So {_:a :p 12} would replace _:a with ?a
and introduce a WHERE clause pattern of {?a [] []}.

2. If a blank node appears in the template, is accompanied by a
variable in a triple pattern, and every possible solution of the WHERE
clause has that variable bound, then treat the blank node as a
variable, and introduce a new pattern to the WHERE clause which binds
that variable to everything. So {_:a :x ?y} would replace _:a with ?a
and introduce a WHERE clause pattern of {?a [] []}. This will result
in a lot of possible patterns that do not require deletion, so the
where clause pattern can be reduced to {?a :x ?y}, resulting in the
same things being removed.

3. If a blank node appears in the template, is accompanied by a
variable in a triple pattern, and that variable may be unbound in some
solutions (due to an OPTIONAL or a UNION), then treat the blank node
as a variable, and introduce a new pattern in the WHERE clause, as per
#2, but this time the pattern is OPTIONAL.


I've tried to keep the above prose terse, so I apologize if it's unclear.

Now I'm not saying that this is correct, as it's only my first go at
it, and I haven't tried to implement this yet, but it seems to be on
the right track. It's the closest I can get, so far.

> 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.

As you can probably see, I've been trying to avoid a new operation.
Instead, I've been trying to map it into a normal DELETE/WHERE. Of
course, I may be unsuccessful in this, but then I'm not sure how to do
it with a new operation (like your suggestion here) either.

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

I've made my views clear on this. I'm expecting that this conversation
either demonstrates a clear path, or else it becomes a reductio ad
absurdum, forcing a reconsideration of the resolution. I'm not seeing
the former yet.

Regards,
Paul

Received on Thursday, 17 February 2011 18:05:27 UTC