Re: Views on the outcomes of F2F

On Tue, Nov 10, 2009 at 3:18 PM, Steve Harris <steve.harris@garlik.com> wrote:
> 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.

I realize we don't *need* them to be different words, but the fact
that it's doing something a little different makes me think that it
makes sense to have a different word. But it's really just the
familiarity for SQL users that I'm thinking of here.


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

Sure, but the parser won't know, will it?

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

Oh, I do. I borrowed the ARQ syntax (thanks Andy), and it took me all
of 20 minutes to code, test and deploy. I find it really useful, and
can see why people like it.

I believe that the main reason this never made it into the charter
because AS with subselects was considered equivalent. Personally, I
think that was the wrong approach, but I always had bigger priorities.
I've just become concerned about it again after getting feedback over
the FPWD (not just from Holger, though he's the most vocal).

Since it's not in the charter, but it looks like being important, then
it would be nice to see something like a note about it. That way
anyone who wants to implement it has some documentation on the common
way to do it. I don't know the process for notes though.

Paul

Received on Tuesday, 10 November 2009 20:29:30 UTC