Re: Discussion of property paths, SPARQL and N3

On 29/01/2010 1:07 PM, Sandro Hawke wrote:
>> On 29 Jan 2010, at 10:57, Andy Seaborne wrote:
>>> On 27/01/2010 12:58 PM, Andy Seaborne wrote:
>>>> http://lists.w3.org/Archives/Public/public-cwm-talk/2010JanMar/0002.html
>>>> and replies.
>>>>
>>>> Andy
>>>
>>> Now also a comment:
>>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Jan/0007.h
>> tml
>>>
>>> One point arising is the use of "/" as the path follow symbol.  N3
>>> uses "!" (after UUCP) and the design note
>>>
>>> http://www.w3.org/DesignIssues/N3Alternatives#Syntax
>>>
>>> where it is noted that N3 might acquire expression syntax so
>>> reserving + - * / makes sense.
>>>
>>> * and + are already used in property paths.
>>
>> I think the familiarity from regular expressions is a huge win.
>>
>>> To add expressions in patterns to SPARQL, it would take some kind of
>>> expression marker like `` or ?(?x+?y) (c.f. shell syntax).
>>
>> Alternatively a path marker would be possible, but expression marker
>> seems slightly more "natural" to me. Thinking out loud...
>>
>> // for path expressions would evoke perl inline regex, but with the /
>> for path separator as well it might be confusing:
>>
>> /foaf:knows+/foaf:name/
>>
>> with //, the path separator could be whitespace:
>>
>> /foaf:knows+ foaf:name/
>
> I think that's a viable option.  The "/" operator for sequencing is the
> one thing thats stands out to me as odd form the parsing world.  Of
> course it's quite natural from the xpath world, and sort-of natural from
> filesystems/URIs (although that feels different to me).
>
>> Anyway, I think it's fine as it is.

And it's neat that

?x foaf:name ?y

is a triple pattern and a path of 1, which is what a triple pattern is.

>
> 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'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) .

# To what does the + apply?
# Unary + or property path 1 or more?
?y eg:age + my:func(123) . 


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. 
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.


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

>
>       -- Sandro

Received on Friday, 29 January 2010 14:51:47 UTC