Re: Views on the outcomes of F2F

On 10 Nov 2009, at 19:23, Paul Gearon wrote:
> On Tue, Nov 10, 2009 at 12:20 PM, Andy Seaborne <andy.seaborne@talis.com 
> > wrote:
>>> **  ISSUE-12: HAVING vs. FILTER as keyword for limiting
>>> aggregate results
>>>
>>> General consensus in favor of using "FILTER" as the keyword,
>>> with bglimm preferring "HAVING".
>>
>> I prefer HAVING because familiarity with SQL.
>>
>> Having both is acceptable.
>
> I didn't recall preferring FILTER, though I trust that Lee got this
> correct. But now that I'm looking at it, I think I prefer HAVING due
> to familiarity with SQL. Like Steve, I'd rather not see both.

I feel it's a little odd to have HAVING, when WHERE does something  
completely different to SQL, but it's not going to ruin my year or  
anything :)

SQL has to have a separate keyword because they can't otherwise  
syntactically tell what's a WHERE and what's a HAVING, but in SPARQL  
you can tell.

>>> **  ISSUE-15: Syntax for custom aggregates
>>>
>>> Mild opinion in favor of having no keyword or special syntax
>>> for custom aggregate functions
>>
>> Neutral, currently.
>
> I'm wondering how to tell the difference a scalar function and what's
> an aggregate. Is there something really obvious that I'm not seeing?
> Will the engine just "know" which functions are aggregates, and then
> it gets documented somewhere?

Well, your engine has to be able to tell them apart for other reasons  
(the application rule is completely different for one thing). I guess  
the idea was that they would belong to different classes in your code,  
or something equivalent.

> This brings me back to wanting to see LET in the WHERE clause. I guess
> that ship has sailed. :-(

We're explicitly not chartered to do assignment - if that makes sense  
- somewhat tortured English. We voted on a list of things to be in the  
charter, and assignment was on the list that didn't make it.

You could regard it as syntactic sugar for subselect + project  
expressions, but that doesn't appear to be what Holger is after, and  
it's a little sophisitic to argue that IMHO.

Obviously nothing stops you implementing it as a local extension, just  
like many people did project expressions in SPARQL 1.0. If anything it  
will encourage standardisation in SPARQL-next.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  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 Tuesday, 10 November 2009 20:18:51 UTC