- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 29 Jan 2010 08:07:02 -0500
- To: Steve Harris <steve.harris@garlik.com>
- cc: Andy Seaborne <andy.seaborne@talis.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
> 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. I think losing expressions is a problem. 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? -- Sandro
Received on Friday, 29 January 2010 13:07:09 UTC