- 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