- 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