On 23/02/2010 12:35 PM, Steve Harris wrote:
> On 23 Feb 2010, at 11:37, Andy Seaborne wrote:
>> On 23/02/2010 10:18 AM, Steve Harris wrote:
>>> Just for my own edification. Is it correct that N3 already includes a
>>> path syntax similar to the SPARQL property paths one, and plans to add
>>> expressions, so will require a delimiter, or is it a first one to stick
>>> their syntax flag in the ground situation?
>
> [fullsome description of N3 and SPARQL path syntax removed]
>
> Thanks Andy, that made it a lot clearer.
>
> Limiting property paths to P position, and expressions to O seems like
> it would work, as long as PPs don't allow whitespace. Is this currently
> enforced?
It's not enforced - paths happen above the token level and inter-token
gap can be white space (otherwise the whole grammar needs "skip possible
WS here" added all over it).
But it's not necessary - as long as the parser is unambiguous about the
the end of a path and start of an expression then it would work.
For example, "+" on the end of a path will bind to the path and not the
following number
:x :p+ 123 . # Path in SPARQL 1.1, illegal in SPARQL 1.0
:x :p + 123 . # Illegal SPARQL 1.0
because the grammar rule for paths attempts to include (greedy
lookahead) any following modifier.
:x :p +123 .
has a token of "+123"
In infix notation, an expression can't start with "/" "*" and unary +/-
can be dealt with by insisting on no WS between sign and number.
Note there is already a problem with expressions, not related to PP.
:x :p (123) . # list or expression?
That's a SPARQL 1.0 induced problem and I don't how a way round it (same
applies to N3 BTW). Expressions without () are of more limited use.
> A syntax for PPs, which required (a future) expression syntax to use
> delimiters seems a little anti-social.
Agreed. We should try to keep future options open (within reason).
Another future possibility is {} for graph literals (formulae in N3).
This is messier and a better syntax to leave {} for graph literals might
be nice. Possibilities: %n,m%, and other unusual characters. Being
able to limit the search to paths below a fixed max length does seem
rather useful to constrain searching.
Literals-as-subjects, hence expressions-as-subjects, is also a future
possibility.
Andy