Re: SPARQL 1.1 Query Aggregates Review

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