Re: Review SPARQL Query 1.1, Section 18 (algebra)

On 02/05/11 23:17, Birte Glimm wrote:
> On 2 May 2011 21:10, Andy Seaborne<andy.seaborne@epimorphics.com>  wrote:
> [snip]
>> I've made changes:
>>
>> 1/ http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_algFilter
>>
>> Definition: Filter
>> Filter(expr, Ω, D(G)) = { μ | μ in Ω and expr(μ) is an expression that has
>> an effective boolean value of true }
>>    Note that evaluating an exists(pattern) expression uses
>>    the dataset and active graph, D(G).
>>    See the evaluation of filter.
>
> I now I am a pain in the arse, but I can't help it ;-)
>
> We now have:
> Definition: Filter
> ...
> Filter(expr, Ω, D(G)) =
>
> and:
> Definition: Evaluation of Filter(F, P)
> eval(D(G), Filter(F, P)) = Filter(F, D(G), eval(D(G),P))
>
> In the Filter Def. D(G) occurs in the third position, whereas in the
> Evaluation Def. it is used in the second position.

Fixed.

>
>> 2/ http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#defn_evalFilter
>>
>> Definition: Evaluation of Filter(F, P)
>>
>> eval(D(G), Filter(F, P)) = Filter(F, eval(D(G),P), D(G))
>>
>> and moved the definitions for substitute and exists next to eval of Filter.
>>
>> I don't think it's helpful to rewrite the whole of expression evaluation to
>> include D(G) but instead use language and highlight that the context of
>> evaluation can provide it.
>
> I am still not really happy with the way it is handled :-( Before
> FILTER (NOT) EXISTS the algebra and its evaluation was quite
> systematic; BGPs generate solutions and everything else was on top of
> that, combining and working with sets of solutions. This nice
> organisation is now gone :-( We have now a muddled interaction, which
> relies on language to explain how all this is supposed to work.
> Unfortunately, there's not much time to get anything better written up
> and I guess neither you nor I (definitely not I) have the time to work
> on this at the moment :-(

For me, it still works that way.  exists() is a form of subquery.  It is 
possible to execute the pattern once and apply substitution as a filter 
restriction under the same conditions, in the same, reverse, way that 
many SPARQL engines turn bottom up evaluation into a sequence of 
substitution/index-joins.

The LC vote is today and I don't have time to rework it.  But I believe 
that even if we rework it, no implementation would change as the 
functionality is the same.

 Andy

Received on Tuesday, 3 May 2011 08:50:35 UTC