- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Mon, 23 Nov 2009 13:38:17 +0000
- To: Steve Harris <steve.harris@garlik.com>
- CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 23/11/2009 10:53, Steve Harris wrote:
> On 22 Nov 2009, at 16:05, Andy Seaborne wrote:
>
> [snipped a lot]
>
>> My current preference is:
>>
>> DELETE WHERE { X }
>>
>> where X is BGPs + GRAPH + FILTER.
>>
>>
>> (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.
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).
Andy
>
> - Steve
>
Received on Monday, 23 November 2009 13:38:42 UTC