Re: Draft response for comment N3-1

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

Received on Tuesday, 23 February 2010 13:43:40 UTC