- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 15 Sep 2009 12:38:30 +0000
- To: 'SPARQL Working Group' <public-rdf-dawg@w3.org>
Property paths task force. http://www.w3.org/2009/sparql/wiki/TaskForce:PropertyPaths My preference for discussions is on-list so everyone can join in as they see fit - if that is going to get in the way of the must-do features, then we may need to replan but I can see it as being appropriate because there are interactions with entailment (and others). My suggestion for how to proceed is to first have some email discussion about scoping then have a telecon moving towards choosing a strawman and create issues against that. But I suggest we first work on whether certain major topics are in or out first. There are a number of systems that that provide implementation experience of paths. ARQ [1], SPARQLer [2], PSPARQL [3], Corese [4] There has been some theory work as well. And from these are some scope issues to be considered such as: + variables in paths + being able to work with the length of the path + being able to work with the path found (and I'm sure there are others, large and small.) If we take some kind of path matching as a baseline (no variables, no values, no path-valued variables), what are the implications of these issues over that baseline? Variables in paths: what happens about ?s ?p* ?o when there are no ?p ? This could also lead to easily written very expensive query executions. Having access to the length of the path needs to say what happens for loops and for multiple paths between the same two graph nodes. Path-values variables enable functions on the path in FILTERs and SELECT expressions but need to work with results format. Personally, I think path-valued variables are a step too far at the moment but if there is a way to leave that open for the future then that would be ideal. I don’t understand the implication of path lengths yet - ARQ's property paths match once per end point pair how ever found. I do think having a general matching construct like PATH(?s, pathpattern, ?o) which allows additional features in the future (c.f MATCH in Corese - maybe PATH(?pathVar, ?s, pathpattern, ?o)) but the inline syntax is also very convenient. Maybe the inline syntax is an abbreviation for PATH(something). Comments, Thoughts, Suggestions? Andy [1] http://jena.sourceforge.net/ARQ/property_paths.html [2] http://www.eswc2007.org/pdf/eswc07-kochut.pdf [3] http://psparql.inrialpes.fr/ [4] http://www-sop.inria.fr/edelweiss/software/corese/v2_4_1/manual/next.php http://www.w3.org/2009/sparql/wiki/Feature:PropertyPaths http://www.w3.org/2009/sparql/wiki/Feature:PathLength
Received on Tuesday, 15 September 2009 12:39:43 UTC