Re: SPARQL 1.1 Query Aggregates Review

Hi Steve all,
just to say that I am happy now with the section and consider my review of
that section done.
Birte

On 2 March 2011 10:07, Steve Harris <steve.harris@garlik.com> wrote:

> Hi Birte,
>
> On 2011-03-01, at 13:59, Birte Glimm wrote:
>
> Hi Steve,
> I have some comment for the updaed version too (see below). I still would
> prefer 11.6 to have a more complete example, e.g., showing the query which
> required the agrregate join.
>
>
> All queries require AggregateJoin, it's used to turn the grouped solution
> sequence as used by aggregates, into a solution sequence that can be
> projected etc. I added a line of text to hopefully make this clearer, but
> it's a complex section, so easy to miss.
>
> "This is required to transform the aggregates solution multisets into
> solution multisets as used in the rest of the algebra."
>
> 11.3
> ...
> >HAVING expressions
> there is an extra > now
>
>
> Fixed.
>
> 11.6
> ...evaluating the Aggregate function*s* which share a key.
>
>
> Changed to "evaluating the Aggregate expressions which share a key", as I
> think that's probably clearer.
>
> 11.7
> Note that the *bindgins*
> <y> should probably be <http://example.com/data/#y> or :y (if abbreviated)
>
>
> Those have been fixed.
>
> Thanks,
>    Steve
>
> On 28 February 2011 23:04, Steve Harris <steve.harris@garlik.com> wrote:
>
>> Thanks Birte, that's very helpful.
>>
>> I've just committed version 1.212 which addresses these problems.
>>
>> I've also added an example showing how error are handled, and fixed some
>> more typographical errors.
>>
>> - Steve
>>
>> On 2011-02-25, at 22:06, Birte Glimm wrote:
>>
>> > Steve, others,
>> > I have now reviewed Section 11 (Aggregates) and I attach my comments
>> below. Mostly there are some typos and smaller corrections, but I can't make
>> sense out of 11.6. I gues at least an example is need and probably a bit of
>> text to put that subsection into context.
>> > Best regards,
>> > Birte
>> >
>> > 11 Aggregates
>> > ...
>> > Aggregates are used where the querier wishes to see a result which is
>> > compute*d* (not computer)
>> >
>> > 11.1
>> > ...
>> > In aggregate queries and sub-queries variables that appear in the query
>> > pattern, but are not grouped by ...
>> > "not grouped by" sounds a bit strange to me, I would prefer just "but
>> > are not grouped" or "but not in the GROUP BY clause"
>> >
>> > "It should be noted that <link>as per functions</link>, aggregate
>> expressions must
>> > be alised inorder to project them from queries or subqueries. In the
>> > example obove 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."
>> >
>> > For me the link does not work.
>> > Should "alised" be aliased?
>> > obove <- above
>> >
>> > 11.2
>> > ...
>> > "Within GROUP BY clases the assignment keyword, AS, may be used. Such
>> > as GROUP BY (?x + ?y AS ?z). "
>> > clases <- clauses
>> > Such as... Is not really a complete sentence and rather belongs to the
>> previous
>> > sentence.
>> >
>> > ...
>> > "We can then Apply the set function Avg() to the group solutions, using
>> the Aggregation() algebra function, as Aggregation((?y), Avg, {}, G),
>> giving:..."
>> > apply (lowercase)
>> > I wondered what the empty set in the Aggregation() algebra function
>> > was, but in order to get any clues, one has to click on the link and
>> > read the algebra section. Maybe one can shortly comment on that
>> > already informally in Section 11.2 or choose an example that also uses
>> > that feature?
>> >
>> > 11.4
>> > ...
>> > "Note that it would not be legal to project STR(?z) as this is not a
>> > simple variable expression."
>> > I guess it would be legal to select ?newZ if I were to use (STR(?z) AS
>> > ?newZ) right? If so, it would be nice to point that out too.
>> >
>> > "Other expresisons, not using GROUP BY variables, or aggregates may have
>> non-deterministic values projected from their groups using the SAMPLE()
>> aggeregate."
>> > aggeregate <- aggregate
>> >
>> > 11.5
>> > "The set functions which underlie SPARQL aggregates all have a common
>> > signature: SetFunc(M, err), or SetFunc(M, err, scalarvals, ...) where M
>> is a
>> > multiset of lists, err is a value indicating whether the evaluation of
>> any of the
>> > expressions evaluated with respect to Ω "
>> > Here we have scalarvals again, so it might really be helpful to say a
>> > bit about that in the example in 11.2. Also I find Sigma a bit out of
>> > ontext here, it's the first time used in this section. Could the text
>> > not just say "a solution sequence"?
>> >
>> > "The name is retained due to the comonality with SQL Set Functions,
>> > which also operate over multisets."
>> > commonality
>> >
>> > "... Systems may choose to expand this set with *local using
>> extensions*, using the same notation as for functions and casts. "
>> > local extensions?
>> >
>> > 11.6
>> > "In order to project values from (sub-)queries using aggregate values,
>> > a Solution Multiset is constructed where each solution comprises the
>> > results of the Aggregate functions which share a key."
>> > Why upper case Solution Multiset and Aggregate functions?
>> >
>> > I can't really make sense out of that section. Maybe an example would
>> > help, but I neither see in what context I would need such aggregate
>> > joins nor how a query would look like that uses/requires this feature.
>> >
>> >
>> > --
>> > Dr. Birte Glimm, Room 309
>> > Computing Laboratory
>> > Parks Road
>> > Oxford
>> > OX1 3QD
>> > United Kingdom
>> > +44 (0)1865 283520
>>
>> --
>> Steve Harris, CTO, Garlik Limited
>> 1-3 Halford Road, Richmond, TW10 6AW, UK
>> +44 20 8439 8203  http://www.garlik.com/
>> Registered in England and Wales 535 7233 VAT # 849 0517 11
>> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
>>
>>
>
>
> --
> Dr. Birte Glimm, Room 309
> Computing Laboratory
> Parks Road
> Oxford
> OX1 3QD
> United Kingdom
> +44 (0)1865 283520
>
>
> --
> Steve Harris, CTO, Garlik Limited
> 1-3 Halford Road, Richmond, TW10 6AW, UK
> +44 20 8439 8203  http://www.garlik.com/
> Registered in England and Wales 535 7233 VAT # 849 0517 11
> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
>
>


-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520