- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Tue, 22 Dec 2009 11:24:01 +0000
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
Can we raise an ISSUE for this so it does not get lost, please? Andy On 21/12/2009 23:56, Steve Harris wrote: > On 21 Dec 2009, at 18:07, Andy Seaborne wrote: > >> Steve and I were discussing aggregates on IRC: this is for the record >> because we didn't have time to complete the discussion there and then. >> >> What we both want is that >> >> sum(1, unbound) -> 1 >> >> sum(1, 2/0) -> error >> >> i.e skip unbounds in the group but return error on bad expressions. >> >> COALESCE does not help because it treats both as the same. And does >> not work for min and max which are multi-datatype. >> >> The key text is: >> >> [[ >> Definition: Aggregation >> >> Any unbound values exp · μ' do not appear in the resulting value multiset >> ]] >> >> which (my reading) that says evaluate exp on μ' then see if it's unbound. >> >> But the single variable case sum(?x) has an expression of ?x so exp · >> μ' is called on unbound ?x (which is an error) then the test is made >> to see if it's unbound (it's not - it's now error). >> >> We could special-case evaluation of aggregates. If it's a single >> variable, then return value or unbound. If it's any other expression >> (including ?x+0), then evaluate as normal, i.e. error. There are >> otherways for sum (e.g. the value of unbound is always zero) but is >> using the special feature that zero is the identity value for + so >> does not work for other aggregates. > > Another option would be to say that if there are any variables appearing > in exp (other than as an argument to COALESCE) that are unbound in μ', > the result in unbound. > > It's unfortunate for aggregates that eval(?x) for unbound ?x is an error. > > - Steve > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit > http://www.messagelabs.com/email______________________________________________________________________ >
Received on Tuesday, 22 December 2009 11:24:20 UTC