Re: SPARQL 1.1 Query Aggregates Review

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

Received on Monday, 28 February 2011 23:05:24 UTC