Re: Query Review Part 2

I comment inline.

On 15 December 2011 12:30, Andy Seaborne <andy.seaborne@epimorphics.com>wrote:

> One @@Steve.
>
> Unrelated:
>
> I also changed:
>
> -----------------
> Avg(M) = 0, where Count(M) = 0
>  ==>
> Avg(M) = "0"^^xsd:integer, where Count(M) = 0
> -----------------
>
>
> On 14/12/11 12:08, Steve Harris wrote:
>
>> Thanks for the review Birte, comments inline.
>>
>> On 2011-12-13, at 19:28, Birte Glimm wrote:
>>
>>  Hi Andy, Steve, all,
>>>
>>> here comes the second part of my Query review for Sec. 18 onwards.
>>>
>>> Best regards,
>>>
>>> Birte
>>>
>>> 18.2.2.2 uses translate(...) whereas all later transformation
>>> algorithms use Transform(...) is that intended or should this rather
>>> be unified?
>>>
>>
> Changed to "Translate" (that's the section naming usage) in pseudocode
> blocks.


Ok.

> [snip]
>


> 18.4
>
>> This might not come as a surprise, but I am (and always was) unhappy
>>> about the exist filters. In particular, we have in 18.4 a definition
>>> of Filter that has as third parameter the active graph, but this is
>>> not used in the definition. Instead, there is a kind of footnote
>>> pointing to the evaluation semantics for exists(pattern) filters.
>>> Either we have a function Filter that is defined for all SPARQL
>>> filters or we don't. I suppose we should have such a function. The
>>> problem is, that at this point the evaluation semantics can no longer
>>> be separated from the algebra functions. If we were honest here, we
>>> would define Filter somehow like this:
>>> Definition: Filter
>>> Let Ω be a multiset of solution mappings, expr an expression, and G an
>>> RDF graph.
>>> Filter(expr, Ω, G) = { μ | μ in Ω and expr(μ) is an expression that
>>> has an effective boolean value of true given that each subexpression
>>> of expr of the form exists(A) evaluates to true if and only if
>>> eval(D(G), substitute(A, μ)) is a non-empty sequence }
>>>
>>
> We could define things in that style.  At this stage, I'm inclined to
> leave the doc as-is unless there is a specific problem.  A change in style
> would have to be propagated more widely than just here.
>

My only probem is that there is no algebra function for exists filters and
what it means to filter with exists patterns is only very implicit through
that footnote. I agree that the above described change could be done later
on as it does not change the intended semantics, but it would make it
easier to understand Sec. 18.

>
> (more than this would be editorial so we can come back to it post-LC2)
>
> http://www.w3.org/2009/sparql/**wiki/PostLastCall2<http://www.w3.org/2009/sparql/wiki/PostLastCall2>


ok

>
>
>  There is no problem with using substitute here, which I would anyway
>>> move to 18.4, but having to delegate to eval here is not nice. I don't
>>> see a solution for this, but prefer a more honest definition here that
>>> shows that we now mix algebra functions with evaluation semantics.
>>> If we change to the above definition, substitute moves to 18.4 and
>>> Definition: Evaluation of Exists is obsolete since it is covered by
>>> the filter definition.
>>>
>>> Definition: Extend
>>> ...
>>> Extend(Ω , var, term) = { Extend(μ, var, term) | μ in Ω }
>>> I assume term should be expr as in the lines before. If, for some
>>> reason beyond my understanding, term is meant, it should be defined
>>> above (as mu, Omega, var and expr), I guess as an RDF term.
>>>
>>
> Something has to carry the expression from the translation stage to the
> evaluation.  We can't say Extend(?? , var, term) because the expression
> itself would be lost.
>
> I have changed:  term => expr in definition of Extend(Ω, ...)
>

Ok, that was my point. I just did not know what term is here.

>
> (see below for more on expr(μ))
>
> (IF I were redoing the definition of SPARQL, given the new material we've
> added, especially aggregates, I'd consider making the whole thing
> explicitly based on symbol manipulation but it was too late to do that at
> the start of this WG before the new material arrived.)
>
>
>  18.4.1
>>> Note that in 18.2.4.1, we get Group((1), P) if the query has an
>>> aggregate, but no GROUP BY clause. Thus, Group((1), P) should produce
>>> something meaningful in 18.4.1, but we define
>>> Group(exprlist, Ω) = { ListEval(exprlist, μ) ->  { μ' | μ' in Ω,
>>> ListEval(exprlist, μ) = ListEval(exprlist, μ') } | μ in Ω }
>>> which is
>>> Group((1), Ω) = { ListEval((1), μ) ->  { μ' | μ' in Ω, ListEval((1), μ)
>>> = ListEval((1), μ') } | μ in Ω }
>>> with Ω the solutions for P and
>>> ListEvalListEval((expr1, ..., exprn), μ) returns a list (e1, ..., en),
>>> where ei = μ(expri) or error.
>>> which is
>>> ListEvalListEval((1), μ) returns a list (e1), where e1 = μ(1) or error.
>>> What is μ(1) here? I don't think implicit grouping is mean to work
>>> based on errors. All in all, I don't understand how implicit grouping
>>> is supposed to work.
>>>
>>
>> Yes, I see. I'm not particularly happy with the notation of μ(expr) used
>> to denote evaluating expr w.r.t. μ. Previously I used •, as in μ • expr but
>> that didn't work for some people.
>>
>> Note, this isn't specifically an issue for implicit grouping, it applies
>> on any grouping with only constants, though those would be odd use cases,
>> e.g. GROUP BY 23, or GROUP BY NOW() will end up in the same place.
>>
>> I don't really have a sensible suggestion for how to fix this, the best I
>> can think of is some explanatory text saying what μ(expr) is trying to
>> express.
>>
>
> @@Steve
>
> μ is a partial mapping of variables to values.
>
> μ(expr) would be the a substitution of the variables for the terms given
> by μ.  But not the value of the expression.
>
> So with μ being ?x=1 and expr being ?x+2 then μ(expr) is the expression
> "1+2" but nothing causes a call to "+" to turn that into 3 (a value).
>
> If you want the value of expr_i given μ, then you need something like:
>   expr_i(μ)
>
> which is used elsewhere (from 1.0 days).
>
> I have explicitly stated that "expr(μ)" is the value of the expr given
> that solution mapping μ in "18.1.8 Solution Mapping"


That should also work for the aggregates.

[snip]

>
>  I find the definition names in 18.5 not very uniform. We have (picking
>> some):
>> Definition: Evaluation of Filter(F, P)
>> Definition: Evaluation of Exists
>> Definition: Evaluation of LeftJoin(P1, P2, F)
>> Definition: Evaluation of a Union Pattern
>>
>> Why not Evaluation of a Union(P1, P2) or just Evaluation of LeftJoin?
>>
>
Argument removed from title.
> Made the naming more systematic.


Ok

>
>
>  18.6
>>> As Axel pointed out that the first condition for ent. regimes should
>>> use ***E-***consistent and we also extended this part to say that the
>>> scoping graph is uniquely specified *up to RDF graph equivalence*.
>>> Thus Axel suggest to use in both Query and Ent. Regimes:
>>> 1. The scoping graph, SG, corresponding to any E-consistent active
>>> graph AG is uniquely specified up to<a
>>> href="http://www.w3.org/TR/**rdf-concepts/#section-graph-**equality<http://www.w3.org/TR/rdf-concepts/#section-graph-equality>
>>> ">RDF
>>> graph equivalence</a>  and is E-equivalent to AG.
>>> I am happy to use this in Ent. Regimes.
>>>
>>
> I have already made the first change Axel suggested ("consistent" ->
> "E-consistent").
>
> If closer synchronisation of the two texts is needed, it's "editorial".
>

Agreed, but we should not forget about it. It is confusing if there are two
slighty different definitions in the two ocuments.

Birte

>
>        Andy
>
>
>
>>>
>>>
>>> --
>>> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
>>> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
>>> University of Ulm                         Fax:   +49 731 50 24188
>>> D-89069 Ulm                               birte.glimm@uni-ulm.de
>>> Germany
>>>
>>>
>>


-- 
Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
University of Ulm                         Fax:   +49 731 50 24188
D-89069 Ulm                               birte.glimm@uni-ulm.de
Germany