W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: [TF-PP] Scoping the design space

From: Alexandre Passant <alexandre.passant@deri.org>
Date: Tue, 29 Sep 2009 11:20:42 +0100
Cc: 'SPARQL Working Group' <public-rdf-dawg@w3.org>
Message-Id: <8DD74A0C-151E-4FF6-A994-3137E1E91BFF@deri.org>
To: "Seaborne, Andy" <andy.seaborne@hp.com>

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.


: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


[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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC