Re: Work in progress on rq23

On Tue, Nov 09, 2004 at 10:01:01 +0000, Andy Seaborne wrote:
> Steve Harris wrote:
> >On Mon, Nov 08, 2004 at 03:39:32PM +0000, Andy Seaborne wrote:
> >
> >>A/ Section 6: More Pattern Matching ??? Alternatives
> >>
> >>Text added that uses UNION to handle alternatives, having looked through 
> >>the email traffic on the comments list, on this list and on what various 
> >>systems do about it.  I had a brief conversation with Steve before 
> >>travelled to let him know I would be doing this.
> >
> >
> >Andy, just to check I understand what it means - those {}'s in the UNION
> >examples are just sugar, yes?
> >
> >In principle
> >
> >SELECT ?title ?author
> >WHERE ( ?book dc10:title ?title )
> >      ( ?book dc10:creator ?author )
> >UNION ( ?book dc11:title ?title )
> >      ( ?book dc11:creator ?author )
> >
> >could be an alternative syntax? Just checking that UNION has a similar
> >binding strength to SQLs UNION.
> >
> >I prefer it without {}'s, but I'm not really bothered if theres a good
> >parser/whatever reason for it.
> >
> >- Steve
> >
> 
> Good point - the example in the doc isn't complex enough to show this and 
> I'll expand it later.
> 
> Isn't the SQL case a little different because UNION/SQL is " SQLstatement 
> UNION SQLstatement" so the grouping comes about anyway because its an SQL 
> statement, making it "SELECT ... UNION SELECT ..." not inside a SELECT 
> statement.

Yes, this was the kind of behaviour I'd like to see in SPARQL, ie. it
effectivly works like a compund query. I'm ambiavlent about wether you
have to repeat the SELECT for each WHERE or not.
 
> The UNION operator could be greedy in its binding as you have it or it 
> could be not-greedy  - both are going to lead to confusion - its like the 
> binding of "*" and "+" in arthimetic expressions except people aren't so 
> used to it.  With explict AND and OR, it's usually higher operator 
> precedence on & (i.e "&" is "*" and "|" is "+") and programmers get it 
> wrong frequently.  But our conjunction is juxtaposition which throws things 
> into confusion as to expectations based on syntax.

Well, except for the parallels with SQL.
 
> Consider these two fully grouped expressions:
> 
> # An expanded example:
> 
> SELECT ?title ?author ?price
> WHERE
>     { ( ?book dc10:title ?title ) ( ?book dc10:creator ?author ) }
>     UNION
>     { ( ?book dc11:title ?title ) ( ?book dc11:creator ?author ) }
>     (?book info:priceOnAmazon ?price )

OK, I would like this to be:

SELECT ?title ?author ?price
WHERE
    ( ?book dc10:title ?title ) ( ?book dc10:creator ?author )
    ( ?book info:priceOnAmazon ?price )
    UNION
    ( ?book dc11:title ?title ) ( ?book dc11:creator ?author )
    ( ?book info:priceOnAmazon ?price )

> Whatever we decide about UNION, one of them needs the grouping.  To remove 
> brackets, the first wants a greedy (low precedence) UNION operator, the 
> second wants a non-greedy (high precedence) form.

Well, yes, but this is the OR syntax with s/OR/UNION/, which is clearer I
think, but still not what I was trying to describe.
 
> If I had laid out your example as:
> 
> SELECT ?title ?author
> WHERE ( ?book dc10:creator ?author )
>       ( ?book dc10:title ?title ) UNION ( ?book dc11:title ?title )
>       ( ?book dc11:creator ?author )
> 
> the people might expect the other form (not that they are going to get the 
> right answers!).

Right, I take that as one more reason to to include infix graph operators.
Braces hurt readability (to me, at least), and its the presence of infix
operators that requires them.
 
> My preference is:
> + calling it OR

This is dangerous, as it a non shortcutting operation, which will be
confusing, I think. Eric and I tried to discover if there was a
non-shortcutting || in SQL (only in the constraints of course, SQL doesnt
have a table disjunction), and it turns out that you cant really tell, as
there is no obvious way to spot it in constraints.

- Steve

Received on Thursday, 11 November 2004 01:44:43 UTC