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

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




Reply via email to