Re: ISSUE-48: Less verbose delete syntax

> 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" ] .
}


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.

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

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

>
>> A simple solution is BGP's but I think FILTERS are needed.
>> But it's weird if DELETE-WHERE-{} has pattern restrictions when
>> DELETE-{}-WHERE-{} does not.
>
> Not really, it's sugar. But, as above I think we can handle any WHERE
> pattern sensibly, if we chose to.
>
>> I see a design tension that we have not resolved. Simplicity of
>> language (only a few forms) vs expressing common use cases.
>
> Yes.
>
>> May be (I'm raisng the possibility, not proposing) we need more verbs
>> in the language and not overload the general purpose operations.
>>
>> It could also be that the ordering of templates and patterns is
>> unhelpful.
>>
>> USING { pattern }
>> DELETE { template }
>> INSERT { template }
>>
>> but this goes all the way back to having SELECT-{pattern}.
>
> Yeah :( SQL precedent makes it hard to use logical ordering sadly. I
> still kind-of regret that we didn't go for
> WHERE { }
> SELECT { }
> PROJECT { }
> for queries. But it would probably have caused confusion.
>
> However, I'll note that
> WHERE { ... } DELETE<enter>
> has the same problem as DELETE FROM ...<enter>
>
> - Steve
>

	Andy

Received on Sunday, 8 November 2009 21:23:23 UTC