W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: ISSUE-48: Less verbose delete syntax

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Mon, 23 Nov 2009 15:48:17 +0000
Message-ID: <4B0AAEC1.8010006@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>


On 23/11/2009 14:50, Steve Harris wrote:
> On 23 Nov 2009, at 13:38, Andy Seaborne wrote:
>>>>
>>>> (The question for me is more whether we should do less, not more, than
>>>> that.)
>>>
>>> I think my preference is BGPs + GRAPH only. Possibly no bNodes too,
>>> depending on what the exact semantics of bNodes are in this case.
>>>
>>> I'm not really adverse to FILTER, but I have systems where optmising
>>> DELETE WHERE { ?x a <Foo> } etc. is really easy, but
>>> WHERE { ?x a ?type . FILTER (REGEX(STR(?type), "Foo")) } (i.e. anything
>>> that doesn't trivially optimise down to algebra expressions) is hard to
>>> do. Personal bias :)
>>>
>>> Would be nice to have some form of DELETE that will always be fast,
>>> relative to the amount of data it has to remove.
>>
>> If there is a FILTER, then it can be more work but if no FILTER is
>> mentioned, there is no reason it should get in the way. So FILTER-less
>> should be fast for you.
>>
>> With just BGP+FILTER, the FILTER is always the outermost and easy to
>> find.
>>
>> GRAPH changes that but then you don't need the FILTER to get complicated:
>>
>> DELETE WHERE { ?x a <Foo> ; :p ?o. GRAPH ?g { ?y a <Bar> ; :p ?o} }
>>
>> There's an argument that we need a "no join" restriction (join across
>> quad patterns) and so it's always of the form:
>>
>> filter?
>> graph?
>> BGP
>>
>> for optional filter and graph at the algebra level.
>
> Aren't Joins only a problem if FILTER is present?

They do make it more interesting ...

>
> DELETE WHERE {
> ?x a <Foo> .
> GRAPH ?g {
> ?x a ?y
> FILTER (?y != <Foo>)
> }
> ?y a rdf:Class .
> }

Good example - it's got 2 algebra joins in it (as had mime).  Better 
include algebra join in the list:

    BGP+GRAPH+FILTER+join.

>
> Otherwise the pattern can be reordered without changing the semantics,
> as far as I understand it.

It will depend on the implementation as to whether mixing quads+triples 
is the same.  In a quad-centric implementation, sure, it's pattern 
flattening to quad-joins.  But in others systems the triples and names 
graphs might be held differently resulting in different join 
characteristics within BGP/quad blocks and across them.

FILTER+joins (as in {}-joins) have scoping issues as per normal SPARQL.

>
>> Because it's rather easy to detect the fast forms, I think restricting
>> the syntax is not the right way to go. A clear description as
>> BGP+GRAPH+FILTER from query patterns is easier to explain (and
>> possibly parse/detect).
>
> Agreed, restricting syntax is not ideal.
>
> A grammar like 'DELETE' 'WHERE' '{' template '}' would be cleanest IMHO.
>
> - Steve
>

	Andy
Received on Monday, 23 November 2009 15:48:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT