W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

Re: SPARQL 1.1 Query Review Part 1

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 08 Dec 2011 09:10:11 +0000
Message-ID: <4EE07EF3.90805@epimorphics.com>
To: public-rdf-dawg@w3.org


On 07/12/11 14:10, Steve Harris wrote:
> On 2011-12-07, at 13:11, Andy Seaborne wrote:
>>
>> On 06/12/11 22:53, Steve Harris wrote:
>>>>> "[...] In aggregate queries and sub-queries variables that
>>>>> appear
>>>>>>> in the query pattern, but are not in the GROUP BY clause
>>>>>>> cannot be projected nor used in project expressions." I
>>>>>>> would add a comma after "GROUP BY clause"
>>>>>
>>>>> Done
>>>>>
>>>>>>> I don't think this is correct. I can select expressions
>>>>>>> with aggrated variables that are not grouped: SELECT
>>>>>>> (SAMPLE(?x) AS ?y) { ?x :p ?z } GROUP BY ?z
>>>>>
>>>>> @@Steve
>>> I believe that's as the group intended.
>>
>> I think Birte's point is that SAMPLE(?x) uses a variable in a
>> select expression, but it's not GROUP BY'ed.
>>
>> As currently worded, that's not allowed.
>
> We have:
>
> “In aggregate queries and sub-queries variables that appear in the
> query pattern, but are not in the GROUP BY clause cannot be projected
> nor used in select expressions. In order to project arbitrary
> expressions the SAMPLE aggregate may be used. For details see the
> section on Projection Restrictions.”

But SAMPLE(?x) is part of a SELECT expression.

SAMPLE(?x) is using variable that is forbidden by this text as ?x is not 
GROUP BY'ed.

The text forbids just as it correctly forbids (?x + 1).

It needs to allow use of ungrouped variables in an aggregate function.

Editorial:

A comma or two would be good:
"In aggregate queries and sub-queries, "
                                    ^^^^^^
", but are not in the GROUP BY clause,"
                                    ^^^^^^

> I could change to “nor used directly in select expressions”, does
> that make it clearer? I think the bit about SAMPLE makes it
> reasonably clear, but it could be better.
>
>>>>>>> "It is an error for aggregates to project variables with
>>>>>>> a name already used in other aggregate projections."
>>>>>>> Isn't it even forbidden to use any variable that is used
>>>>>>> elsewhere? SELECT (SAMPLE(?x) AS ?y) { ?x :p ?y } GROUP
>>>>>>> BY ?y would not be valid, right?
>>>>>
>>>>> @@Steve
>>> I'm not really sure, that seems like more of a general select
>>> expressions restriction - I thought that was allowed at one time
>>> though?
>>>
>>> I guess it wouldn't hurt to reiterate if that is the case, Andy?
>>
>> Agreed - restate the condition.
>
> OK, changed to:
>
> “It should be noted that as per functions, aggregate expressions are
> required to be aliased (again, similar to the BIND clause, using the
> keyword AS) in order to project them from queries or subqueries. In
> the example above this is done using the variable ?totalPrice. It is
> an error for aggregates to project variables with a name already used
> in other aggregate projections, or in the WHERE clause.”
>
> Is that OK? The previous para already includes a link to the
> projection restrictions.

Fine

>
> - Steve
>

	Andy
Received on Thursday, 8 December 2011 09:10:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:47 GMT