Re: Views on the outcomes of F2F

Like Steve, I'll respond to the things that I care about.

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.

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

>> **  Do expressions always need to be aliased to a named variable?
>> Mild consensus that aliases should be required.
>
> Disagree mildly.  Prefer to allow engine invent them.  For results-on-wire,
> must be a legal variable.  For API, who cares?

I don't like the system having to create names, but acknowledge that
it's sometimes expedient (Mulgara does it now, though I never wrote
this!). I'd prefer requiring a name, only I like to be similar to SQL
where possible, and since SQL doesn't need them, then I guess we
shouldn't.

>> **  Syntax for expressions in SELECT list
>>
>> General lack of satisfaction with either:
>>
>>     * Requiring commas if a projection uses at least one expression
>>     * Wrapping expressions and aliases with parentheses (brackets)
>
> Would like to allow optional commas everywhere (SELECT, GROUP BY, ORDER BY).

I agree here. They're optional, so there's no problem with backward
compatibility. They'll also make the SELECT clause clearer,
particularly with expressions and aliases. They are also help with
familiarity for SQL users, which is a big issue from my perspective
(and you may note, a running theme in this email).

Sorry Steve.  :-)

> Prefer (?x +?y AS ?z) because some level of () are necessary for any
> expression in SPARQL to keep it parsable by a wide variety of approaches.
>  So might as well include the AS.  This is now the leading approach out
> there.

I have no issues with this, though I'll point out that I'm a fan of
Holger's position of allowing these variables in the WHERE clause as
well (via a LET syntax).

>> **  Sub-asks and sub-selects in FILTER
>>
>> General consensus (kasei, axel, steveh, leef) to avoid
>> the complexity of any subqueries in FILTERs.
>
> Agreed - the meaning of patterns (scoping of free variables) would need
> join-like semantics and is complex.  The lack of scalar subSELECTs will be a
> potnetial area for consideration problem but is mitigated by having named
> variables in SPARQL.
>
> You can place the scalar select just be for the FILTER and AS the result
> into a variable.  This is not an equivalence, the query pattern may be
> slight different, but you can get the effect as far as I can determine.
>
> Sub-Ask is not the same as (NOT) EXISTS because EXISTS isn't join-ed with
> other results.

I agree wholeheartedly here. Other than the aforementioned issues, the
naive approach will be slow, and I really don't know where I'd start
to optimize this.

>> **  Sub-constructs in FROM and FROM NAMED
>>
>> General consensus (kasei, steveh, leef) to avoid the complexity of
>> sub-constructs in FROM. Axel is in favor, but willing to cede the point.
>
> Agreed.

This is a shame, but I guess it's practical.

Is anyone out there doing it at the moment? We "sort of" do, in that
you can use a URI that describes a query against a SPARQL endpoint,
complete with ?query=...., but it would be nice to see a common
approach that doesn't involve using URIs in a way that the spec
doesn't consider. I'd be interested in doing this in some common way
so that it can be considered in a future SPARQL.

>> **  ISSUE-39: Variable scope of alias variables
>>
>> Consensus that variables on the right-hand side of "AS" (alias variables)
>> are not in scope for the rest of the query (including projected
>> expressions), but not including outer queries of course.
>
> Disagree - this is an unnecessary restriction and results in needing
> addition nesting of SELECTs just to reuse an expression.

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

> Day 2:
>
>> 1. To close ISSUE-47 by noting consensus on keeping MODIFY in the Update
>> language, modulo any concerns expressed by Update editors, no objetions or
>> abstentions link
>
> Agree.

It's my understanding that the later resolution for ISSUE-25 overrode
this, thereby dropping MODIFY altogether:

>From the minutes: http://www.w3.org/2009/sparql/meeting/2009-11-03#resolution_4

RESOLVED: we'll have one update statement, DELETE ... INSERT ... WHERE
..., where one of DELETE or INSERT may be ommitted, and WHERE is
optional, and multiple of these may be combined in a string using ";"
as the separator.

So what is it? This is the reason I haven't updated the Update document yet.

>> 4. we'll have one update statement, DELETE ... INSERT ... WHERE ..., where
>> one of DELETE or INSERT may be ommitted, and WHERE is optional, and multiple
>> of these may be combined in a string using ";" as the separator. link
>
> I now prefer DELETE WHERE {}, that is, the pattern becomes the template.

Agree.

> This also means ";" is unnecessary.  If a syntax requires the use of ";" to
> distinguish two different forms, then I would be very worried (it's going to
> be error prone).

The reason for the ";" was to permit several operations in the one
string, as in multiple DELETEs and multiple INSERTs.

This was discussed starting at about:
 http://www.w3.org/2009/sparql/meeting/2009-11-03#line0577

> Optional ";" is tolerable for convenience but it's used in Turtle with an
> abbreviation meaning.
>
>> 5. SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY, with
>> each feature 1.1 adds to SPARQL Query being AT RISK for this. This closes
>> ISSUE-27. link
>
> I think I know what you mean but this wording is not OK.
>
> I prefer a framing of "SPARQL 1.1 Update uses SPARQL 1.1 Query; but, if
> feedback is significant, the WG will define a profile using SPARQL 1.0
> Query".  i.e. default to SPARQL 1.1.  Conformance would explicitly note 1.1
> vs 1.0.  Just 1.0 patterns is not fully compliant "SPARQL 1.1 Update" IMHO.
>
> There are always going to be engines that are incomplete.

I agree here. I feel uncomfortable defining updates in terms of 1.0
queries. Updates are part of 1.1, so the system is already going to be
weird if it is mixing 1.0 and 1.1 compliance.

Regards,
Paul Gearon

Received on Tuesday, 10 November 2009 19:24:29 UTC