On 2017-10-10 11:25, Rob Vesse wrote: > Personally I am certain that Jena is correct in its interpretation of > specification and that the specification is the appropriate. > > The key point here is that any aggregation requires at least one group to > operate over, in the absence of a GROUP BY then there is an implicit group of > all Solutions. In the case where there are zero solutions you have an > implicit empty group. As has been pointed it out we can still meaningfully > aggregate over an empty group e.g. COUNT is zero
I'm not an expert and have already expressed my concerns. I'm just using common sense. I have also discussed it internally with some of my colleagues and they somehow agree with my view. The currently returned empty group doesn't have reference to any variable, etc. From the point of view of coding/automation is not a generic way of getting things. I will have to check if the resultset variables exist, etc. Besided my point is that if I get a result this means that I have a value. For instance if I looking for the highest temperatures of a set of weather station and the weather station entities are not registered, then it is impossible to get the max of the temperatures. In this case, even if using the GROUP BY, what am I grouping? There is nothing to group so no resultset should be returned. Let's say that for instance COUNT is different from other aggregate functions like MAX. COUNT is a function that always returns an integer, just by definition. On the contrary, MAX is comparing values and if there are no values to compare then there is no result. Please don't take me wrong. I just want to make a point. So sorry for opening the Pandora box on this issue ;) Regards, Jorge > Rob > > On 09/10/2017 16:19, "Andy Seaborne" <[email protected]> wrote: > > > > On 09/10/17 15:27, George News wrote: > > On 2017-10-09 12:31, james anderson wrote: > >> good afternoon; > >>> On 2017-10-09, at 12:03, George News <[email protected]> wrote: > >>> > >>> On 2017-10-09 11:53, Lorenz Buehmann wrote: > >>>> > >>>> > >>>> On 09.10.2017 10:22, George News wrote: > >>>>> Hi all, > >>>>> > >>>>> Here it goes. The MWE is below. > >>>>> > >>>>> As you can see when I execute Q_without.rq I get an empty array in > >>>>> bindings. However with Qmax_without.rq I get {} (empty object) in > >>>>> bindings. > >>>>> > >>>>> What I'm saying is that if I'm getting nothing when listing the > >>>>> matching entities, I don't know why I get an empty object when > >>>>> listing the matching entities with an aggregate operation like MAX. > >>>>> > >>>> Well, I guess Andy already gave you the answer in the beginning of > >>>> the thread: A query with an aggregate always returns a row by > >>>> convention. But compared to the aggregate function COUNT which simply > >>>> can return 0 then, MAX can't return any concrete value because the > >>>> MAX of nothing is not specified. > >>> > >>> I understood it, but I don't agree with this behaviour. Is this in the > >>> standard or is it just Jena behaviour? > >> > >> the recommendation describes the intended behaviour here : > >> > >> > >> https://www.w3.org/TR/sparql11-query/#aggregateAlgebra > >> > > > > I guess this is it. If the standard says so, we have to stick to it, > > although not in favour of that solution. > > I haven't convinced myself that Jena is right (I haven't checked - > virtuos seemed to do the same though which isn't proof but it's a > completed unconnected implementation) and even if it is, whether the > spec is saying what it means to say. I don't see different cases for > COUNT(*) and AnyAgg(?x) because I'd expect them to be different in the > case of no GROUP BY. > > The presence of GROUP BY fundamentally changes the nature of the query. > > > > > Does anybody knows a way to avoid loading the whole resultset in memory > > to check if it has one row and then rewind it to the beginning? > > ASK WHERE { pattern } > > Andy > > > > > Thanks. > > > >> > >> > >> best regards, from berlin, > >> > >> > >> --- > >> james anderson | [email protected] | http://dydra.com > >> > >> > >> > >> > >> > >> > > > > > >
