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

Re: SPARQL 1.1 Query Review Part 1

From: Birte Glimm <birte.glimm@uni-ulm.de>
Date: Thu, 8 Dec 2011 10:54:27 +0100
Message-ID: <CABt65OcVS30LZkcDzE=DB3jPVCD2105ne9PkSvWFFAyMatRKfA@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>, Steve Harris <steve.harris@garlik.com>
Cc: public-rdf-dawg@w3.org
Sorry for being a bit late with my response. Apart from the points
currently under discussion, all my comments have been addressed.
Regarding my comment on 11.2, where Steve couldn't find the text, I
think I somehow looked at the LC doc instead of the current editors'
draft for this section. The current section seems fine.

I comment inline on the remaining issue.

Birte

On 8 December 2011 10:10, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>
>
> 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.

Yes, that's my point.

>> 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.

How about rephrasing as follows:
“In aggregate queries and sub-queries, variables that appear in the
query pattern, but are not in the GROUP BY clause, can only be
projected or used in select expressions if they are aggregated. The
SAMPLE aggregate may be used for this purpose. For details see the
section on Projection Restrictions.”

> 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.

Makes it slightly clearer.

>>>>>>>> "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.

Seems ok to me now.

>
> Fine
>
>>
>> - Steve
>>
>
>        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
Received on Thursday, 8 December 2011 09:55:09 GMT

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