- 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