Re: ungrouped variables used in projections - Further implications?

On 25/08/10 18:15, Axel Polleres wrote:
> Thanks for these very useful examples, Andy! (which I think brought me to another
> imprecise formulation in the spec, I think)
>
> Questions for clarification, to make sure everybody is on the same page here:
>
> 1)
>> SELECT *
>> {
>>      { SELECT ?x { ?x ?p ?o } GROUP BY ?x }
>>      ?o<p>  123 .
>> }
>
> Yup, we want to allow this, right?

Yes

>
> 2)
>>    SELECT (count(*) AS ?p) { ?s ?p ?o } GROUP BY ?s
> ...
>>    SELECT (SAMPLE(?p) AS ?p) { ?s ?p ?o } GROUP BY ?s
>
> This is seemingly (but strangely enough not quite?) in conflict with:
> "The new variable is introduced using the keyword AS; it must not already be potentially
> bound."
>
> I'd honestly prefer somehow to strenghten this restriction to:
>
> "The new variable is introduced using the keyword AS; it must not already occur in the WHERE clause."

Disagree - the GROUP example puts the inner variable out of scope.

An inner SELECT/project would do much the same - it's not just GROUPing.

Building queries by combining tested fragments is made much harder if 
there are whole-query rules that mean a fragment worked on its own 
breaks a larger query.

> Funny enough, note that the original "potentially bound" formulation is problematic/imprecise already
> without aggregates:
>
>   SELECT (?X as ?Y) WHERE { ?S ?P ?X OPTIONAL { ?S ?P ?Y FILTER(?Y != ?Y) } }
>
> Obviously, there is no way that ?Y ever returns a binding by the FILTER expression...
> so it is not "potentially bound" and that query would be syntactically ok, according to the definition.
> I guess many will agree that checking static unsatisfiability of FILTER expressions would be a nightmare for parsers :-)
>
> 3)
>> Personally, I'd be happy with forbidding the use variables of grouping
>> expressions:
>>
>>    SELECT (1/(1-?o) AS ?o1) { ?s ?p ?o } GROUP BY (1/(1-?o)) # Forbiddable
>>    SELECT ?o WHERE { ?s ?p ?o } GROUP BY (1/(1-?o)) # Forbiddable

> Without expressing any strong opinion here: This rules out the new test case agg08, or, resp.,
> turns it into a negativeSyntaxTest. I had assumed for the current version of agg08 that the
> former would be allowed whereas the latter wouldn't. That's why I had "*or expressions*" in
> my rewording proposal.

It does - it's a trade off - testing whether an expression is the same 
as another is tricky.

> I assume what Andy means here (and which I think holds) is that we could forbid expressions
> in Grouping alltogether, since they can be always emulated by subqueries, i.e.

Not what I mean.

I am suggesting simplifying by not requiring an impl to spot when two 
expressions are the same.

SELECT (1/(-?o+1) AS ?o1) ... GROUP BY (1/(1-?o))
        ^^^^^^^^^^

Use of ?o in any expression in projection (or HAVING - it's the same 
thing) is forbidden.

>     SELECT (1/(1-?o) AS ?o1) { ?s ?p ?o } GROUP BY (1/(1-?o))
>
> could be written without expression in the GROUP BY clause as:
>
>     SELECT ?o1 { SELECT (1/(1-?o) AS ?o1) { ?s ?p ?o } } GROUP BY ?o1 }
>
> So, why not just doing just that and forbidding expressions in GROUP BY in the grammar already?

Unnecessarily severe.

Doing that because minor issue of the expressions in SELECT are tricky 
seems to have the balance all wrong.

> 4) BTW, what about
>       SELECT * { ?s ?p ?o } GROUP BY ?s
>   Just to make sure everybody is on the same page here: is this also forbidden?

No - it's natural.

Define the scoping of a group as the key variables (not expressions used 
in GROUP BY) and it works out easily.

	Andy

>
> Thanks,
> Axel

Received on Wednesday, 25 August 2010 17:34:22 UTC