Re: ISSUE-48: Less verbose delete syntax

On 10/11/2009 06:44, Steve Harris wrote:
> On 9 Nov 2009, at 22:15, Andy Seaborne wrote:
>> On 09/11/2009 20:27, Steve Harris wrote:ILTERs
>>>
>>>
>>> I'm not so sure, FILTERs don't feel any less complex than OPTIONAL and
>>> friends.
>>
>> Don't understand - how can a filter over a BGP be as complicated as
>> one of the binary graph patterns?
>
> Well, it's just as disallowed in the template side, so the pattern still
> needs to be transformed. Admittedly it's FILTER -> nothing, but it's
> still some transformation work.
>
>> A FILTER accepts or rejects rows of the query solution table, but does
>> not change the shape of a row which is determined by the BGP.
>
> Well, it's surely a matter of perspective whether that's more or less
> complicated. I think in terms of joins, so FILTER seems more complex.

There seems to me to a natural place from SPJ at SP (Select-project) 
before we get to the J (Join).

>
>>> If we're going with simple lets just have templates (BGP + GRAPH).
>>
>> GRAPH is OK - same as with FILTER because the pattern is still a fixed
>> shape (no irregularities).
>
> Well, in any case we still need to allow for
>
> DELETE {
> template
> }
> WHERE {
> pattern
> OPTIONAL {
> pattern2
> }
> }

That's already in the SPARQL/Update document isn't it?  DELETE with 
template and pattern.  Template being a BGP-pattern only.  Or are you 
saying template involves OPTIONAL?

> CONSTRUCT can do that, so it's well defined.

The template can't involve OPTIONAL in CONSTRUCT as currently defined.

The fact that in a template, only individual triples, not patterns, with 
unbound variables are omitted sometimes does what you want, sometimes 
doesn't.

In the CONSTRUCT case, you get more triples with the single triple 
pattern exclusion and more triples in the answer is relatively safe but 
when used in DELETE that can end up removing more triples, which is not 
so safe.

If the template above is supposed to be pattern+pattern2, it can have 
strange effects for any triple pattern in pattern2 that does not use a 
variable introduced somewhere in the optional part:

{ ?x :p ?v . OPTIONAL { ?x :q ?z . ?x :r 123 } }
   ==>
{ ?x :p ?v . ?x :q ?z . ?x :r 123 }

and you can end up deleting "?x :r 123" which is otherwise guarded by a 
match of "?x :q ?z".  Opps.

So we would need an interpretation of the keyword OPTIONAL in templates.

That said:

WHERE {
   pattern
   OPTIONAL {
     pattern2
   }
}

is, I think, the same as:

DELETE WHERE { pattern pattern2 }
DELETE WHERE { pattern }

which does repeat pattern but at least only instantiates pattern2 
guarded by pattern 1.

It does not account for nested optionals, especially where inner use of 
variables in pattern3 interacts with outer use of variables of the same 
name in pattern1.


So my conclusion is that we can get BGPs, GRAPH, FILTERs to work without 
changign the template instantiation process but the graph combinations 
operations to work requires changes to the template.

 Andy

Received on Tuesday, 10 November 2009 10:26:37 UTC