- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 29 Jan 2010 10:53:57 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- cc: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
> > 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.
> > 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. I suppose your point is that expressions must be set aside with
`...` because of this problem?
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?
> 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.
-- Sandro
Received on Friday, 29 January 2010 15:54:08 UTC