W3C home > Mailing lists > Public > public-cwm-talk@w3.org > January to March 2010

Re: SPARQL paths and N3 paths: some quick thoughts.

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Sun, 24 Jan 2010 19:19:39 +0000
Message-ID: <4B5C9D4B.5030801@talis.com>
To: Dan Connolly <connolly@w3.org>
CC: timbl@w3.org, public-cwm-talk@w3.org

On 22/01/2010 9:10 PM, Dan Connolly wrote:
> The SPARQL WG is looking at paths...
> http://www.w3.org/2009/sparql/docs/property-paths/Overview.xml

That doc will be published very soon.  Comments to the WG comments list 
at anytime are very welcome.  The N3 community has experience of using 
paths and I hope there will be comments (positive and negative!) 

> ... which is quite important for querying, e.g. lists:
>   select ?elt where {<alist>  rdf:rest*/rdf:first ?elt }
> Meanwhile, they're using / where n3 uses ., I think.

Yes - SPARQL prefixed names can include dots in such a way that "." as 
the path separator does not work out very well.

> They use ^ both as N3 uses it and to do the is/of thing.
> They also include regex syntax such as +,*, ? and {n,m}
> and ()s (but not for match groups).
> It's pretty hard to argue against this in SPARQL; people
> have been asking for it from the very start of the SPARQL
> design.
> Perhaps N3 should adapt in this direction?
> The one place I'm inclined to push on is is/of; I'd
> hate to lose that from N3. Though... with the @keywords
> mechanism, maybe it's not so much of a conflict.

There are some issues listed in document where the experience of people 
here would be very valuable.

# The use of "^" as a unary and binary operator may be confusing. An 
alternative is to just have a unary form and require "/^" in paths to 
combine an inverse property into a path.  The N3 path syntax includes 
binary and unary "^".

# While property paths as currently specified can be used to access RDF
lists (e.g. rdf:rest*/rdf:first), the Working Group notes that this
would be more useful if results were returned in the order they occur in 
the RDF list. This presents significant complexity in the context of the 
existing SPARQL algebra.

Received on Sunday, 24 January 2010 19:20:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:06 UTC