W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: ISSUE-12 (HAVING vs FILTER)

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 9 Feb 2010 14:10:01 +0000
Cc: "SPARQL Working Group" <public-rdf-dawg@w3.org>
Message-Id: <1BF46876-3CBB-441D-AB81-CA99A400AB53@deri.org>
To: "Andy Seaborne" <andy.seaborne@talis.com>
Thanks for the clarifications, Andy, they make sense to me.
Maybe all except the SQL analogy (we also have FILTER instead of WHERE anyways already) is very reasonable.
Concluding, I wouldn't object to resolving ISSUE-12 in the way you propose, if this is the majority opinion of the group.

Axel

On 9 Feb 2010, at 13:08, Andy Seaborne wrote:

> Ok - still something to debate ...
> 
> > ISSUE-12: hmmm...
> > IIRC, the last discussion we had about that ended in that
> >
> > {SELECT S
> > WHERE W
> > GROUP BY G
> > HAVING F}
> >
> > ist just the same as
> >
> > {SELECT S
> > WHERE W
> > GROUP BY G
> > } FILTER F
> 
> That's slightly different. HAVING happens before the projection so can
> "see" more variables.

true...

> SELECT ?x
> { ?x :p ?o }
> GROUP BY ?x
> HAVING (count(?o) > 3)
> 
> does not expose the count.

but that could be fixed by writing

> SELECT ?x  (count(?o) as ?y)
> { ?x :p ?o }
> GROUP BY ?x
> FILTER ?y >3


instead, right? So, I still think that each having could be rewritten to a FILTER, maybe at the expense of having to introduce/project additional variables.

>  This can make a difference:
> 
>   {
>   SELECT S
>   WHERE W
>   GROUP BY G
>   LIMIT 10
>   } FILTER F
> 
> puts the LIMIT before the expression restriction.
> 

yes, I see that point, true.

> You could do it with 2 sub-SELECTs, the middle one projecting from the
> working set of variables to the exposed set - not serious!
> 
> 
> You can just use the word FILTER where there is HAVING.
> 
> SELECT S
> WHERE W
> GROUP BY G
> FILTER F
> 
> 
> If we disallow aggregates in FILTERs by some means (e.g. two expression
> hierarchies, or text prohibiting them), than HAVING vs FILTER matters.
> I think we should.
> 
> Saying "not in HAVING" is easier than "not in FILTER except where FILTER
> appears as a solution modifier"
> 

I think finally, I buy that one...

> 
> Otherwise you can write:
> 
> SELECT ?x
> { ?x :p ?o
>    FILTER(count(?o) > 3)
> }
> 
> which has a sensible reading of an implicit group and we choose not to
> have implicit grouping via SELECT.  (It may have other readings as well.)
> 
> > That's why I am still hesitant to use HAVING instead of just FILTER as
> > a keyword. At least, I still am not convinced that introducing another
> > keyword is useful here. I think the dispute of the issue is still just
> > the used keyword itself, isn't it? Do we have a resolution confirming
> > to use HAVING? I remember this being the last state of discussion,
> > where no real agreement was reached:
> > http://www.w3.org/2009/sparql/meeting/2009-11-02#line0255
> > Let me know if I miss some later findings on that from the list or from a later call.
> >
> > best,
> > Axel
> 
> Does any implementation call it FILTER?
> 
> 
> 
> ARQ uses HAVING and bans aggregates in FILTER.  This is done during
> parsing but by context (so it's not in the grammar - I didn't write out
> two different sets of expression rules as there are quite a lot of them
> to get down the PrimitiveExpression.
> 
> void Project() : {  Var v ; Expr expr ; Node n ; }
> {
>    <SELECT>
>    ...
>    { allowAggregatesInExpressions = true ; }
>    ... select expressions ...
>    { allowAggregatesInExpressions = false ; }
> }
> 
> void HavingClause() : { }
> {
>      { allowAggregatesInExpressions = true ; }
>      <HAVING> (HavingCondition())+
>      { allowAggregatesInExpressions = false ; }
> }
> 
> so the last can be FILTER but it's easier to explain if it's a different
> word.
> 
> Because SQL calls it HAVING, I think we do at least need a positive
> reason to do something different because it does introduce a small
> hurdle for application writers - so what's the value to them of the
> alternative?
> 
> I was pretty neutral, on this but
> 
> + prohibition of aggregates in normal FILTERs
> + the SQL analogy
> 
> means that I'd like to see some value to application writers in calling
> it HAVING and at the moment I don't.
> 
>         Andy
> 
Received on Tuesday, 9 February 2010 14:10:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT