Re: Discussion of property paths, SPARQL and N3

> 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