- From: Alexandre Passant <alexandre.passant@deri.org>
- Date: Tue, 29 Sep 2009 11:20:42 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: 'SPARQL Working Group' <public-rdf-dawg@w3.org>
HI, On 15 Sep 2009, at 13:38, Seaborne, Andy wrote: > 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. While imo relatively useful, I also agree that using path length can be tricky in many cases, esp. combined with entailment. Eg: :deri ex:locatedIn :galway . :galway ex:locatedIn :ireland . :ireland ex:locatedIn :europe . :europe ex:locatedIn :world . (where ex:locatedIn is transitive) Applying transitivity, we'll get :deri ex:locatedIn :galway . :deri ex:locatedIn :ireland . :deri ex:locatedIn :europe . :deri ex:locatedIn :world . :galway ex:locatedIn :ireland . :galway ex:locatedIn :europe . :galway ex:locatedIn :world . :ireland ex:locatedIn :europe . :ireland ex:locatedIn :world . :europe ex:locatedIn :world . Using Corese syntax: select ?y where { :deri $path ?y . filter (pathLength($path) > 1) } What should it return ? One would expect :ireland, :europe, :world but based on the previous entailment these resources have been defined in direct relationship with :deri which imply the path is = 1 (so not > 1 ). Or would pathLength($path) > 1 match as soon as there is at least a path that satisfy that constraint, no matter if there are others that does not. (I think that's the most natural way to do) Another use-case is described in [1] > > > 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). In that case, where should the regexp to, in the ?pathVar or pathpattern ? > > Comments, Thoughts, Suggestions? That use of PATH + the inline abbreviation sounds relevant, especially for extensions Alex. [1] http://www.w3.org/2009/sparql/wiki/Feature:PathLength > > 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 -- Dr. Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Tuesday, 29 September 2009 10:21:22 UTC