RE: Lee's feature proposal

 
On Fri, May 1, 2009 at 10:30 AM, Lee Feigenbaum <lee@thefigtrees.net> wrote:

> As I've said repeatedly, I think the OPTIONAL/!bound construct is a major,
> major stumbling block to learning the language. I think it's just about
the
> most important thing the WG can do from an educational point of view to
fix
> that. (I personally ranked Negation 4th in my survey response). All of
which
> is to say, you don't have to convince me of this.

Yes, but it seems someone needs to be convinced in order for us to
work on it. :>

> I'm happy to include it in the proposal, acknowledging that Andy is spot
on
> that it's a list of features and not implementations. I mainly left it out
> since the number of features I was proposing was beginning to scare me vis
a
> vis our timeline.

Again, fair enough, but we're roughly treating all the features as
equivalently substantive in terms of how much it will take to get them
specified, and I don't believe that's really true (nor does anyone
else, I should think). Also, negation just strikes me as something we
*have* to fix or we'll be embarrassed.


Colleagues

I would see negation, i.e. SQL exists and not exists, which also imply SQL
quantified subqueries,  (all/some), as an almost self-evident consequence of
query nesting.  We have done all this in SQL and SPARQL.

It is possible to do all this if one can put a select in the place of a
triple pattern and have a limit of 1 for the select.  This provides the
equivalent of scalar subquery (select in a scalar  expression)  and
exists/not exists.  

We note that in SQL, scope rules are different for subqueries in an
expression position and subqueries in the table position (in from clause).
Insofar SPARQL does the same, it will likely need different rules also, as
we have done.  But that will be seen.

In short, I see negation as very closely related to subqueries and the cost
of having an exists/not exists syntax instead of the obscure hack with
optional and bound test is minimal.

I do not think that syntax ought to be absolutely minimalistic as concerns
query nesting.  Even though the combination of SQL derived table and limit
and outer join would in principle make subqueries in a search
condition/expression position (exists/not eexists/scalar subquery/quantified
subquary) redundant, having the latter syntax makes for more readability and
by our experience does not make a significant difference to the SQL compiler
writer.  

Orri

Received on Friday, 1 May 2009 19:54:49 UTC