Re: ISSUE-48: Less verbose delete syntax

On 7 Nov 2009, at 19:25, Andy Seaborne wrote:

>>>> What about missing the template out instead:
>>>>
>>>> DELETE WHERE {?x :p ?o }
>>>
>>> If we're going to support this kind of syntax abbreviation, then  
>>> this
>>> looks better to me.
>>
>> Works for me too.
>> That's close to what I proposed in
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0315.html
>
> There are some issues still to be sorted out.
>
> What patterns are allowed?  Not all possible query patterns make
> sense.  I believe that what is going on is a mismatch between the idea
> that a pattern describes a part of the graph and the idea that a
> pattern is extracting terms from the graph.  SPARQL is the latter
> (hence DAWG is "Data Access" : getting stuff out of the RDF graph for
> onwards processing and display). This is like the "CONSTRUCT *" issue.
> It would be nice not to repeat the pattern in the template but it
> gets complicated.
>
> The graph-to-graph transform languages we have are inference and
> rules.  And rules tend to be of the style, match to get variables then
> apply template.
>
> Examples:
>
> DELETE WHERE {?x :p ?o  . FILTER ( ?o < 42 ) } # Why not?
>
> DELETE WHERE {  ?x :p ?o OPTIONAL { ?x :q ?v } } # Seems silly to me.

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

but it may be biting off too much sugar, for the first time round.

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

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

> 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

-- 
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 Sunday, 8 November 2009 19:51:10 UTC