Re: SPARQL syntax proposals

Steve Harris wrote:
> On Sat, Mar 05, 2005 at 03:31:14 +0000, Andy Seaborne wrote:
> 
>>
>>Steve Harris wrote:
>>
>>>On Fri, Mar 04, 2005 at 02:52:17 +0000, Dave Beckett wrote:
>>>
>>>
>>>>On Thu, 2005-03-03 at 16:51 -0500, Eric Prud'hommeaux wrote:
>>>>
>>>>
>>>>
>>>>>as promised, AND is now FILTER:
>>>>>SELECT ?who
>>>>>WHERE { ?who :age ?n. FILTER ?n + 1 < 5 }
>>>>
>>>>This I like, as it was pretty much how I thought about constraints - get
>>>>a bunch of triples then filter them with a big expression.
>>>
>>>
>>>Its cleaner than AND, but I think we should avoid
>>>
>>>FILTER ?x + 1 < 4 FILER ?y + 2 < 4
>>
>>Allowing FILTER to be close to a triple that binds the variable it tests is 
>>natural:
>>
>>{
>>   <v> :p ?x . FILTER ?x < 4 .
>>   <v> :q ?y . REGEXP(?y, "foo", "i") .
>>}
> 
> 
> I personally find that quite hard to read, and should that be FILTER
> REGEXP ...

Oops - yes.

>  
> 
>>Nothing to do with which syntax here.
>>
>>So I think that would need at least one dot to separate adjacent FILTERs 
>>without making special cases to drop the separator for FILTER and/or to 
>>keep them apart.
>>
>>{
>>  <v> :p ?x ;
>>      :q ?y .
>>
>>  FILTER ?x + 1 < 4 .
>>  REGEXP(?y, "foo", "i") .
>>}
>>
>>seems OK.  A corner case is:
>>
>>  FILTER ?x + 1 < 4  <http://> :p ?v .
> 
> 
> Also, FILTER ?x < 4.
> 
> which could be the floating point number 4.0, or the integer 4 and a
> terminator. (I didn't check if we do 4. or .4, but many languages do,
> including SQL).

Good point - it's floating point 4.0 - tokenizing will put the . with the 4

       (["0"-"9"])+ "." (["0"-"9"])* (<EXPONENT>)?
       | "." (["0"-"9"])+ (<EXPONENT>)?
       | (["0"-"9"])+ <EXPONENT>

Tokenizing is greedy (and, yes, that would give a systematic treatment for 
trailing . in qnames).

>  
> 
>>i.e. a triple pattern after a FILTER - not a problem technically unless (*) 
>>literals-as-subject appear and we have unary +/-
>>
>>  FILTER ?x + 1 < 4  -2 :p ?v .
>>
>>which is icky (enough lookahead (3?) resolves but the error messages are 
>>likely to be quite confusing).
> 
> 
> Its all icky. I think one of the things we should take away from SQL is
> that clearly dividing up the logical regions of the query makes it easier
> to read other peoples queries.

 From the SQL viewpoint - yes.   From the viewpoint of an artificial 
separation of FILTERs from the variables they work on, it is also confusing 
and harder to read.

SQL can be odd - it's an asymmetric "WHERE column operator value" (I think 
MySQL is more general) with multiple ANDs but no aliases.  And then there is 
"BETWEEN ... AND ..." which is different.   HAVING is also a condition and 
allows functions and aliases.

	Andy

> 
> - Steve
>

Received on Saturday, 5 March 2005 18:28:16 UTC