Re: SPARQL 1.1 Query Aggregates Review

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

11.3
...
>HAVING expressions
there is an extra > now

11.6
...evaluating the Aggregate function*s* which share a key.

11.7
Note that the *bindgins*
<y> should probably be <http://example.com/data/#y> or :y (if abbreviated)



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