On 3 Jul 2015, at 08:33, james anderson <[email protected]> wrote:
>
> good morning,
>
>> On 2015-07-03, at 04:51, Jeremy J Carroll <[email protected]> wrote:
>>
>> Yes this text seems to be in tension with 11.4
>> http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#aggregateRestrictions
>> In a query level which uses aggregates, only expressions consisting of
>> aggregates and constants may be projected
>>
>> I guess it may be talking about the exception, the variables in the GROUP BY
>> itself, which would be treated correctly by replacing with a SAMPLE()
>> aggregation, since in each group the values of the group by variable are
>> always the same, and SAMPLE of the multiset of values is just the value
>> itself.
>>
>> Jeremy
>>
>>
>>> On Jul 2, 2015, at 9:12 AM, Matthew Horridge
>>> <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> I’ve been reading through the definition of SPARQL in the SPARQL 1.1. Query
>>> Language Document. In particular, section 18.2.4, which describes how to
>>> convert aggregate queries into the SPARQL algebra.
>>>
>>> The algorithm listed in 18.2.4.1, which I’ve pasted in below talks about
>>> “unaggregated variables”. However, there isn’t a definition for
>>> “unaggregated variable” in the spec, and it isn’t totally clear to me what
>>> an “unaggregated variable” is. If anyone could provide me with a precise
>>> definition for what an “unaggregated variable” is, and thus clarify this
>>> part of the spec, I would really appreciate it.
>>>
>>> Thanks a lot,
>>>
>>> Matthew
>>>
>>>
>>>
>>>
>>>
>>> For each (X AS Var) in SELECT, each HAVING(X), and each ORDER BY X in Q
>
> given this text and the phrase, "replacing aggregate expressions”, above,
> “unaggregated variable” is not a defined term, as such, but rather applies to
> any “X” which is not an aggregate expression, that is, which is just a
> variable.
From memory, it was intended to indicate that it was OK to project explicitly
grouped variables, for e.g. in:
SELECT ?x (SUM(?c) AS ?sum)
WHERE { ?x :count ?c }
GROUP BY ?x
Regards,
Steve
