W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

RE: First attempt at a grammar for SPARQL/query 1.1

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 31 Aug 2009 13:41:22 +0000
To: Gregory Williams <greg@evilfunhouse.com>
CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693CEC242E@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: Gregory Williams [mailto:greg@evilfunhouse.com]
> Sent: 30 August 2009 05:17
> To: Seaborne, Andy
> Cc: public-rdf-dawg@w3.org Group
> Subject: Re: First attempt at a grammar for SPARQL/query 1.1
> On Aug 28, 2009, at 1:22 PM, Seaborne, Andy wrote:
> > It includes:
> >
> > + GROUP BY/HAVING [17], [18], [19], [20]
> This had come up briefly in an early telecon, but is there a reason to
> prefer 'HAVING' to 'FILTER', the keyword we've already got for this
> sort of thing?
> .greg

Hi Greg,

The condition that comes after the grouping does behave like a FILTER and the FILTER keyword could be used.  It does behave slightly differently because an aggregate is legal at that point whereas it's not in a FILTER in a pattern:

    HAVING (SUM(?x)>2)

Also, SQL uses the word HAVING, so there is some familiarity there.

There was discussion about only allowing variables (and expressions?) but not aggregates but that then leads to needing the aggregate projected as a named variable even if only needed in the HAVING but not in the results.


Received on Monday, 31 August 2009 13:42:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC