W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2006

Re: the LHS of OPTIONAL

From: Fred Zemke <fred.zemke@oracle.com>
Date: Thu, 23 Nov 2006 09:37:04 -0800
Message-ID: <4565DC40.1010102@oracle.com>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Steve Harris wrote:

<snip/>

>> Fred Z. and I have both advanced the idea that perhaps SPARQL should
>> require that the LHS of the OPTIONAL be explicitly demarcated by  
>> mandatory
>> curly braces. In our opinion (OK, in my opinion, but I'm guessing Fred
>> shares it), this would alleviate any confusion and make complex  queries
>> more readable.
>
>
>>> From conversations with Andy, I believe that he disagrees that  
>>> mandatory
>>
>> curlies would make queries more readable (believing instead that  the 
>> extra
>> curlies would make reading queries more difficult) and he is also  
>> worried
>> about the significant number of existing SPARQL queries that would  
>> become
>> invalid.
>
>
> I agree with Andy here. I've seen a lot of queries like:
>
> T1 .
> T2 .
> OPTIONAL { T3 }
> OPTIONAL { T4 }
> OPTIONAL { T5 }
>
> and those would become a real eyeful:
>
> {
>   {
>     { T1 .
>       T2 .
>     } OPTIONAL { T3 }
>   } OPTIONAL { T4 }
> } OPTIONAL { T5 }

Actually, this is no worse than I have seen in complex SQL queries.
However, perhaps there is a compromise here.  In rq24-algebra,
how about if we replace rule [24] OptionalGraphPattern with this:

[24] OptionalGraphPattern ::=  GroupGraphPattern ( 'OPTIONAL' 
GroupGraphPattern )+

That is, an OptionalGraphPattern consists of an initial curly-braced group
graph pattern followed by one or more OPTIONAL phrases
(OPTIONAL + GroupGraphPattern).  This way the first operand of
the first OPTIONAL is clearly marked by curly braces, and the first
operand of succeeding OPTIONAL in the chain is the phrase
to its left.  Then your example would only require one new pair of curly 
braces:

{ T1 .
T2 . }
OPTIONAL { T3 }
OPTIONAL { T4 }
OPTIONAL { T5 }

and the query processor can effectively supply the rest
as shown in your expansion.

>
> Plus, explaining, and implementing the difference between:
>
> { T1 . T2 . } OPTIONAL { T3 }
>
> and
>
> T1 . { T2 } OPTIONAL { T3 }
>
> is not something I relish.

On that we have no choice, since both are presumably legal
in the language, whether we adopt my suggestion or not.

Fred
Received on Thursday, 23 November 2006 17:37:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:27 GMT