- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 14 Feb 2011 12:15:41 +0000
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: Matthew Perry <matthew.perry@oracle.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
I guess we do need that. Can you put something on the agenda for tomorrow's meeting? If anyone's curious to see what it looks like the text, the current draft has the error count removed. - Steve On 2011-02-14, at 12:04, Axel Polleres wrote: > Sounds very reasonable to me as well (I also remember that the err-count was more something speculative back when we introduced it). > It seems to override the following resolution though > http://www.w3.org/2009/sparql/meeting/2010-03-26#resolution_2 > > Do we need a new resolution to override it? Something like: > > PROPOSED: Drop error counts in the semantics definition of aggregate functions, overriding http://www.w3.org/2009/sparql/meeting/2010-03-26#resolution_2 with the insight that it is not needed/special aggregates could define/implement error counts. > > ? > > Axel > > On 11 Feb 2011, at 15:16, Matthew Perry wrote: > >> Ok. That works for me. >> >> - Matt >> >> On 2/11/2011 10:09 AM, Steve Harris wrote: >>> It does as written, but that's an unintended consequence, the def'n of Count() will need to be change to not count error values. >>> >>> - Steve >>> >>> On 2011-02-11, at 14:00, Matthew Perry wrote: >>> >>>> Hi Steve, >>>> >>>> Lets say M = (1, 2, 3, "a", "b") >>>> >>>> Does this change COUNT(xsd:int(?x)) from 3 to 5? >>>> >>>> - Matt >>>> >>>> On 2/11/2011 7:03 AM, Steve Harris wrote: >>>>> I've spoken with Andy on IRC, and he also agrees that it's probably better without it, so the current draft of rq25 doesn't have the error count argument. >>>>> >>>>> Following some discussion on IRC last night, I've also clarified the return types of the set functions. >>>>> >>>>> - Steve >>>>> >>>>> On 2011-02-11, at 10:55, Steve Harris wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Currently the Set Functions in Aggregates (ie. the underlying functions) are defined like: >>>>>> >>>>>> Func(M, errors, scalars) >>>>>> >>>>>> where M a multiset of the values from the group, e.g. if you have SUM(?x) and ?x is 1,2,3 in the group, then M = (1,2,3). But M is defined used ListEvalE(), so all the results which are errors are removed from the multiset. >>>>>> >>>>>> errors is a count of the errors (which where removed from M). >>>>>> >>>>>> I think it would be much simpler if instead M included the errors, and the error count argument was dropped, then it would be: >>>>>> >>>>>> M = ListEval(exprlist, range(g)) >>>>>> >>>>>> func(M, scalarvals), for non-DISTINCT >>>>>> func(Distinct(M), scalarvals), for DISTINCT >>>>>> >>>>>> Dave B also complained about the error count argument saying it was redundant in his comment. >>>>>> >>>>>> I don't quite remember why it was included? I think Andy S might have suggested it, something about future extensibility? But I don't see what function it performs. >>>>>> >>>>>> So, my question is, can anyone think of a good reason to keep it? >>>>>> >>>>>> - Steve >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >> >> >> > -- 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, 14 February 2011 12:16:17 UTC