Re: ISSUE-48: Less verbose delete syntax

On 8 Nov 2009, at 21:22, Andy Seaborne wrote:

>> I can think of good uses for it.
>>
>> DELETE
>> WHERE {
>> ?x a foaf:Person .
>> OPTIONAL { ?x foaf:name ?name }
>> OPTIONAL { ?x foaf:mbox_sha1sum ?sha1 }
>> ...
>> }
>
> Let's see if this is workable - but I don't see how this generalized  
> template as well as pattern works if it's any pattern.
>
> As Ivan pointed out a while ago, some variables and parts of a query  
> are there to restrict not to return.
>
> e.g. delete people who know "Steve"
>
> { ?x a foaf:Person .
>  ?x ?p ?o .
>  ?x foaf:knows ?y .
>  ?y foaf:name "Steve"
> }
>
> { ?x a foaf:Person .
>  ?x ?p ?o .
>  ?x foaf:knows [ foaf:name "Steve" ] .
> }

Yeah... but I think if I saw

DELETE WHERE {
  ?x a foaf:Person .
  ?x ?p ?o .
  ?x foaf:knows [ foaf:name "Steve" ] .
}

I wouldn't be surprised by what happened.

Like you say below, EXISTS { ?x foaf:knows [ foaf:name "Steve" ] }  
would be a more logical thing to write for that bit.

> looks like a possible way to do it but have I misunderstood because  
> it looks like it deletes a lot more.
>
> Obscurely
>
> { SELECT ?x ?p ?o
>  { ?x a foaf:Person .
>    ?x ?p ?o .
>    ?x foaf:knows ?y .
>    ?y foaf:name "Steve"
>  }
> }
>
> might do the right thing for a possibly non-obvious reasons.
>
>
>>
>> but it may be biting off too much sugar, for the first time round.
>
> Noted - still want to know what it might look like.

Indeed.

>>> DELETE WHERE { { ?x :p ?o } UNION { ?x :q ?v } } # Do as two  
>>> operations?
>>
>> Yep, seems unnecessary. Though, if OPTIONAL is allowed it might  
>> seem odd
>> if UNION is not.
>>
>>> These are a natural reading as identifying triples in the graph but
>>> that's fundamentally different from what SPARQL evaluation is doing.
>>> Adding "means all triples you touch for a positive answer" is not so
>>> clearcut.
>>
>> An alternative definition would be to collapse all the OPTIONAL (and
>> UNION) expressions into a BGP as X in DELETE { X } and apply  
>> CONSTRUCT
>> rules to the DELETE evaluation, so triples with unbound variables  
>> aren't
>> used.
>
> FILTERs ?
> OPTIONAL/!bound ?

FILTERs would have to be dropped in the DELETE { X } section, I was  
taking that as read from your initial example.

I /think/ OPTIONAL + !BOUND will do what you'd expect:

DELETE WHERE {
   ?x a foaf:Person .
   ?x ?p ?o
   OPTIONAL {
     ?x foaf:name ?name .
   }
   FILTER(!BOUND(?name))
}

?x will only bind for foaf:People that have no name.

>> NOT EXISTS in DELETE WHERE though is a sight more screwy, but  
>> omitting
>> it from the "output" may give the expected behaviour:
>>
>> DELETE
>> WHERE {
>> ?x a foaf:Person .
>> ?x ?y ?z .
>> NOT EXISTS { ?x foaf:name "John Smith" }
>> }
>
> :-)
>
> Actually, EXISTs (and not putting it in the overall pattern  
> addresses the case I have above.  But we do seem to stepped into a  
> template language of some kind which might be a step too far for now.

Yeah, it has a slight feeling of death by a thousand cuts. I'm tempted  
to bash out an implementation for experiments though, so see how it is  
in practice, it has a certain reasonable flow to it.

The rule I have in mind is a recursive descent where:

GRAPH -> GRAPH
OPTIONAL -> JOIN
UNION -> JOIN
FILTER -> ignore
(NOT) EXISTS -> ignore

DELETE+INSERT following CONSTRUCT semantics makes a lot of sense, re.  
Kjetil's (SQL) SELECT * transformed to DELETE usecase. That's a strong  
usecase for me, "suck it and see" is not a very good idea, especially  
in a language without transactions.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  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 Monday, 9 November 2009 10:32:56 UTC