Re: Discussion of property paths, SPARQL and N3

On 29/01/2010 3:53 PM, Sandro Hawke wrote:
>>> I think losing expressions is a problem.
>>
>> We are not losing expressions.
>>
>> http://www.w3.org/2009/sparql/wiki/Feature:ScalarExpressionsInTriplePatterns
>>
>> which didn't get above the cut line for this WG.
>
> I wasn't familiar with that, but using `...` doesn't seem okay to me.

That choice is, I suspect, based on background.  It's used elsewhere for 
substitution, which is, presumable, what expressions in triple patterns 
are doing.

>>> I'm working on a rule language
>>> that's also a superset of turtle (but in line with RIF, so n3 itself
>>> isn't right), and I'd hate to see these have to diverge.
>>
>>> Property paths are great.
>>>
>>> But I think *maybe* it can just be handled in a grammar.  Here's a silly
>>> example query:
>>>
>>>      {  ?x eg:age ?x_age.
>>>         ?x foaf:knows+ ?y
>>>         ?y eg:age ?x_age+1 }
>>>
>>> ... which suggests to me that, essentially, that operators can be
>>> different in the object position than in the predicate position.  I'd
>>> need to construct such a parser to be sure, though.  Does anyone see a a
>>> grammar ambiguity here?
>>
>> # List or expression?
>> ?y eg:age (1) .
>
> Yeah, but that's a problem with lists-meets-expressions, not property
> paths.

Well, you asked if there were any grammar ambiguities with expressions :-)

> I suppose your point is that expressions must be set aside with
> `...` because of this problem?

Yes.  Expressions (and cf expressions in SELECT expressions in ()) do 
need that without getting various grammar tricks.


> Yeah, maybe that's compelling.
>
>> # To what does the + apply?
>> # Unary + or property path 1 or more?
>> ?y eg:age + my:func(123) . 
>
> I don't see any use/need for a unary +.
>
>> Function calls and URIs interact in the SPARQL grammar.  So far, the
>> grammar is LL(1) which makes it available to a wide variety of parser
>> toolkits inc LALR(1) and also hand-writtern recursive decent parsers.
>
> Hmmm.  Can you do a comfortable math expression language in LL(1)?  I
> guess so....
>
>> Rewriting would make the grammar larger (an issue we face elsewhere with
>> various forms of patterns in SPARQL Update).
>>
>> That's why FILTER() has the () except for some easy cases like regex.
>>
>> ?y eg:age +1 .
>>
>> works currently because "+1" is a token, not "+" and "1".  That does not
>> work here.
>
> Sorry, what's wrong with continuing to treat +1 as a token?

Nothing - the point is it isn't unary "+" and a "1" then recombined (it 
is in Java for example "+ 53" is a legal number).  Expressions could not 
reply on the tokenizer using the whitespace to correctly choose token 
types and so direct the parser at the grammar level.

>> Literals in the subject position are possible in SPARQL already.  And
>> with reverse paths, they make even more sense in SPARQL.  Expressions in
>> the subject position can't rely on "." to terminate.
>>
>>  Andy
>
> Okay, yeah, I guess I should give up on keeping the languages unified.
> Never mind.

What's the underlying issue?  In extremis, EXPR(1+2), which is rather 
klunky, but it works and preserves the common elements of the languages. 
  That's a valuable aspect to some people.

As SPARQL has provided a basic syntax framework, it would be good to 
extend within that.  There is at least one rules language (Ymris) that 
does that.

There is always a compromise necessary once enough features are piled 
into a language.  There often aren't enough syntax forms to do 
everything without some forms needing to adapt.

 Andy

>
>       -- Sandro
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Friday, 29 January 2010 16:12:36 UTC