amp, lt, gt, apos, quot"> MAY"> MUST"> MAY"> ]>
SPARQL &versionOfSPARQL; Property Paths &doc.ident; Editor's Draft : Summer 2010 &base.uri; http://www.w3.org/TR/&doc.shortname;/ http://www.w3.org/TR/2010/WD-sparql11-property-paths-20100126/ Andy Seaborne Invited Expert andy.seaborne@epimorphics.com

This document describes SPARQL Property Paths. Property Paths give a more succinct way to write parts of basic graph patterns and also extend matching of triple pattern to arbitrary length paths. Property paths do not invalidate or change any existing SPARQL query See SPARQL Query Language for RDF (W3C Recommendation 15 January 2008).

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Editors' Working Draft.

This material has be incorporated into the main SPARQL query document and readers should refer to that document. This document is out of date and may not reflect later working group decisions.

This document was produced by the SPARQL Working Group, which is part of the W3C Semantic Web Activity.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

@@@ World-Wide Web Consortium, SPARQL Working Group, 2009.

Created in electronic form.

 English Extended Backus-Naur Form (formal grammar)

$Id: Overview.xml,v 1.40 2010/09/08 20:40:31 aseaborne Exp $

Editor's Working Notes

Material being sorted out into the positions needed for integration into rq25

 

Introduction

A property path is a possible route through a graph between two graph nodes A trivial case is a property path of length exactly 1, which is a triple pattern. Property paths allow for more concise expression of some SPARQL basic graph patterns and also add the ability to match arbitrary length paths.

 Path Language

A property path expression (or just 'path') is similar to a string regular expression but over properties, not characters. The ends of the path may be RDF terms or variables. Variables can not be used as part of the path itself, only the ends. Query evaluation determines all matches of a path expression and binds subject or object as appropriate. any given path expression.

Cycles in the graph and in paths are possible.

A path of length zero connects a graph node to itself.

In the description below, uri is either a URI or a prefixed name and elt is a path element, which may itself be composed of path syntax constructs.

Syntax Form Matches
uri A URI or a prefixed name. A path of length one.
^elt Inverse path (object to subject).
!uri or !(uri1| ...|urin) Negated property set. A URI which is not one of urii
!^uri and !(uri1| ...|urij|^urij+1| ...|^urin) Negated property set. A URI which is not one of urii, nor urij+1...^urinas reverse paths
(elt) A group path elt, brackets control precedence.
elt1 / elt2 A sequence path of elt1, followed by elt2
elt1 | elt2 A alternative path of elt1, or elt2 (all possibilities are tried).
elt* A path of zero or more occurrences of elt.
elt+ A path of one or more occurrences of elt.
elt? A path of zero or one elt.
elt{n,m} A path between n and m occurrences of elt.
elt{n} Exactly n occurrences of elt.
elt{n,} n or more occurrences of elt.
elt{,n} Between 0 and n occurrences of elt.

The order of URIs, and reverse URIs, in a negated property sets is not significant and they can occur in a mixed order.

The precedence of the syntax forms is, from highest to lowest:

Precedence is left-to-right within groups.

Examples

See also uses cases.

Alternatives

Match one or both possibilities

{ :book1 dc:title | rdfs:label ?displayString }
 Sequence

Find the name of any people that Alice knows.

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows/foaf:name ?name .
}
 Sequence

Find the names of people 2 "foaf:knows" links away.

{ 
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows/foaf:knows/foaf:name ?name .
 }

This can be written as:

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows{2}/foaf:name ?name .
}

This is the same as the strict SPARQL query:

{  ?x  foaf:mbox <mailto:alice@example> .
   ?x  foaf:knows [ foaf:knows [ foaf:name ?name ]]. }

or, with explicit variables:

{
  ?x  foaf:mbox <mailto:alice@example> .
  ?x  foaf:knows ?a1 .
  ?a1 foaf:knows ?a2 .
  ?a2 foaf:name ?name .
}
 Filtering duplicates

Because someone Alice knows may well know Alice, the example above may include Alice herself. This could be avoided with: 

{ ?x foaf:mbox <mailto:alice@example> .
   ?x foaf:knows/foaf:knows ?y .
   FILTER ( ?x != ?y )
   ?y foaf:name ?name 
}
 Inverse Property Paths

These two are the same query: the second is just reversing the property direction which swaps the roles of subject and object.

{ ?x foaf:mbox <mailto:alice@example> }
{ <mailto:alice@example> ^foaf:mbox ?x }
 Inverse Path Sequence

Find all the people who know someone ?x knows.

{
  ?x foaf:knows^foaf:knows ?y .  
  FILTER(?x != ?y)
}
 Arbitrary length match

Find the names of all the people that can be reached from Alice by foaf:knows:

{
  ?x foaf:mbox <mailto:alice@example> .
  ?x foaf:knows+/foaf:name ?name .
 }
 Alternatives in an arbitrary length path 
?ancestor (ex:motherOf|ex:fatherOf)+ <#me>
 Arbitrary length match

Some forms of limited inference are possible as well. For example: all types and supertypes of a resource:

{ <http://example/thing> rdf:type/rdfs:subClassOf* ?type }

All resources and all their inferred types:

{ ?x rdf:type/rdfs:subClassOf* ?type }
 Subproperty 
{ ?x ?p ?v . ?p rdfs:subPropertyOf* :property }
 Find nodes connected but not by rdf;type (either way round) 
{ ?x !(rdf:type|^rdf:type) ?y }
 Elements in an RDF collection 
{ :list rdf:rest*/rdf:next ?element }

Note: This path expression does not gaurantee the order of the results

 Syntax

This syntax will be incorporated into the main SPARQL grammar if the time-permitting feature is accepted.

TriplesSameSubjectPath  ::=   VarOrTerm PropertyListNotEmptyPath | TriplesNode PropertyListPath
PropertyListPath  ::= PropertyListNotEmpty?
PropertyListNotEmptyPath  ::= ( VerbPath | VerbSimple ) ObjectList ( ';' ( ( VerbPath | VerbSimple ) ObjectList )? )*
VerbPath  ::= Path
VerbSimple  ::= Var
Path  ::= PathAlternative
PathAlternative  ::= PathSequence ( '|' PathSequence )*
PathSequence  ::= PathEltOrInverse ( '/' PathEltOrInverse | '^' PathElt )*
PathElt  ::= PathPrimary PathMod?
PathEltOrInverse  ::= PathElt | '^' PathElt
PathMod  ::= ( '*' | '?' | '+' | '{' ( Integer ( ',' ( '}' | Integer '}' ) | '}' ) ) )
PathPrimary  ::= ( IRIref | 'a' | '!' PathNegatedPropertySet | '(' Path ')' )
PathNegatedPropertySet  ::=  PathOneInPropertySet | ( '(' PathOneInPropertySet ( '|' PathOneInPropertySet )* )? ')' )
PathOneInPropertySet  ::=  IRIref | 'a' | '^' IRIref
Algebra

This section describes the translation of the path syntax forms into other SPARQL expressions and hence to the SPARQL algebra. Three new algebra operators are introduced: ZeroLengthPath which defines the evaluation of zero-length path (e.g. ?x :p{0} ?y), ArbitraryLengthPath which defines the evaluation of path of one or more steps (e.g. ?x :p+ ?y) and NegatedPropertySet which defines the evaluation of a path element not matching a set of properties.

Translation of Property Paths

Two steps: this set of rewrites, followed by recombining into BGPs

Notes:

  • X and Y are RDF terms or variables.
  • Occurences of 'path' on the right are recursively translated.
  • The order of forms URI and ^URI in negated property sets is not relevant.
  • UNION is SPARQL UNION.
  • Variables introduced, e.g. ?V, are fresh - not used anywhere else in the current query
Syntax Form (path) translate(path)
X uri Y Triple pattern: X uri Y
X !(:uri1|...|:urin) Y NegatedPropertySet(X,{:uri1 ... :urin} ,Y)
X !(^:uri1|...|^:urin)Y ^(X !(:uri1|...|:urin) Y)
X !(:uri1|...|:urii|^:urii+1|...|^:urim) Y  { X !(:uri1|...|:urii|)Y } UNION { X !(^:urii+1|...|^:urim) Y }
X ^path Y Y path X
X path1 / path2 Y X path1 ?V . ?V path2 Y
X path1 | path2 Y { X path1 Y } UNION { X path2 Y}
X path* Y { X path{0} Y } UNION { X path+ Y}
X path+ Y ArbitraryPath(X, path, Y)
X path? Y { X path{0} Y } UNION { X path Y}
X path{0} Y ZeroLengthPath(X, path, Y)
X path{n} Y where n > 0 X path ?V1 . ?V1 path ?V2 ... ?Vn-1 path Y
X path{n,m} Y { X path{n} Y } UNION { X path{n+1} Y } ... UNION { X path{m} Y}
X path{n,} Y X path{n} ?V . ?V path* Y
X path{,n} Y X path{0,n} Y
Material for the "Initial Definitions" section Property Paths Patterns
Definition: Property Path

A Property Path is a sequence of triples, ti in ST, such that, for i=0 to length(ST)-1, the object of ti is the same term as the subject of ti+1.

We call the subject of t0 the start of the path.

We call the object of tn the end of the path.

Property Path PP is a path in graph G if each ti is a triple of G.

Definition: Property Path Expression

A property path expression is an expression form after translation of the path syntax as defined above.

More commonly called a property path or path, when clear.

Definition: Property Path Pattern

Let PP be the set of all property path expressions. A property path pattern is a member of the set:
(RDF-T union V) x PP x (RDF-T union V)

A Property Path Pattern is a generalization of a Triple Pattern to include a property path in the property position.

 Property Path Expression Matching

To go after Basic Graph Patterns

Alt: in evaluation section

Rename "Basic Graph Patterns" as "Basic Graph Pattern Matching"

SPARQL Property Path Pattern Matching
Definition: Property Path Pattern Matching
Material for the SPARQL syntax to SPARQL algebra section

@@The material of "translate"

If the form is TriplesBlock

@@Extend for Property Paths

The result is BGP(list of triple patterns)
@@Translate can go straight to algebra form 
+ combine any adjacent triples patterns into
one BGP (but not across {} boundaries)
 Material for the SPARQL algebra section

Definition: ZeroLengthPath

A zero length path matches subjects and all objects in the graph, and also any IRIs explitictly given as endpoints of the path pattern.

Definition: ArbitraryLengthPath

An arbitrary length path P = (X (path)+ Y) is all solutions from X to Y such that a intermediate nodes in the graph are trarversed once only.

Definition: Negated Property Set

A Negated Property Set, NPS, is a pair (F,B) where F and B are sets of IRIs. F is the set of forward links and B is the set of the backward links.

 Material for the SPARQL Evaluation Semantics section

Maybe better in with the path evaluation after BGP

@@ Add X:T syntax to the intro to "Evaluation Semantics in rq25

eval(D(G), pathPattern) =
  eval(D(G), translate(x, path, y)) =

* translate(PathpathExpression) only depends on BGP, UNION, ArbitraryPath and ZeroLengthPath.

Definition: nodes(G)
  nodes(G) = { n | n is an RDF term and either n is a subject or an object of some triple T in G }

* nodes(G) is the node set of the graph.
Zero-length paths

Definition: Evaluation of ZeroLengthPath

eval(D(G), ZeroLengthPath(vx:var, path, vy:var))) = 
  { {(vx, term), (vy, term)} | term in nodes(G) }
  card[] = 1

eval(D(G), ZeroLengthPath(vx:var, path, y:term)) =
 { { (vx, y) } }
  card[] = 1

eval(D(G), ZeroLengthPath(x:term, path, vy:var)) = 
  { { (y, x) } }
  card[] = 1

* does not matter if x or y is in nodes(G) or not.

eval(D(G), ZeroLengthPath(x:term, path, y:term)) = 
  { {} }
  card[] = 1

* Multiset of one solution mapping, which is the solution mapping of no variables
Arbitrary length paths

Definition: Evaluation of ArbitraryLengthPath

An arbitrary length path @@

ArbitraryLengthPath(?x (path)+ ?y) = @@

The matching algorithm is based on following all paths, and deteching when a graph node (subject or object), has been already visited by the path. 

Definition: Evaluation of ArbitraryLengthPath

eval(D(G), ArbitraryLengthPath(x, path, y)) =

i.e. the SPARQl pattern x path+ y .


Define: ALP

ALP(x:term, path) = ALP(x:term, path), {})

ALP(x:term, path, Visited) =
  if ( x in Visited ) return empty set.
  Visited = Visited union {x}
  T = Path(x, path, y)
  R = empty list
  for t in T
    R = R + t + ALP(t, Path, Visted)
  Visited = Visited \ {x}
  result is R

then

eval(D(G), ArbitraryLengthPath(x:term, path, vy:var)) =
    { {(vy, n) | n in ALP(x, path) }

eval(D(G), ArbitraryLengthPath(vx:var, path, vy:var)) =
    multiset-union(ArbitraryLengthPath(t, path, vy) | t in nodes(G))

eval(D(G), ArbitraryLengthPath(vx:var, path, y:term)) =
   multiset-union({(vx,t} | | t in nodes(G) and y in ArbitraryLengthPath(t, path, y) })
card[]

Note that
    ArbitraryLengthPath(vx:var, path, vy:term) = ArbitraryLengthPath(y:term, ^path, vx:var)

eval(D(G), ArbitraryLengthPath(x:term, path, y:term)) = 
    { { } } if y in ALP(x, path)
    { } if y not in ALP(x, path)

Informally, this algorithm attempts to extend the multiset of results by one application of path at each step, noting which nodes it has visited for this particular path in Visited. If a node has been visited for the path under consideration, it is not a candidate for another step. A node can still be visited multiple times if there are two different paths that visit it.

 CVS History 
  $Log: Overview.xml,v $
  Revision 1.40  2010/09/08 20:40:31  aseaborne
  Material moved to query language document

  Revision 1.39  2010/08/10 15:51:00  aseaborne
  work-in-progress

  Revision 1.38  2010/08/10 14:01:33  aseaborne
  work-in-progress

  Revision 1.37  2010/08/10 10:26:20  aseaborne
  Preparing for integration into query doc

  Revision 1.36  2010/08/06 14:16:05  aseaborne
  Revise the evaluation of path expressions (work-in-progress)

  Revision 1.35  2010/08/06 12:07:33  aseaborne
  Update author details for Andy

  Revision 1.34  2010/08/05 18:55:27  aseaborne
  All terms, not all IRIs, for zeropath

  Revision 1.33  2010/07/08 15:42:41  aseaborne
  Drafting for the defn of arbitrary length path (work in-progress)

  Revision 1.32  2010/07/08 15:14:49  aseaborne
  Drafting for the defn of arbitrary length path (work in-progress)

  Revision 1.31  2010/07/08 12:37:29  aseaborne
  Defn and eval of zero length paths

  Revision 1.30  2010/07/07 14:39:36  aseaborne
  Complete translation of paths

  Revision 1.29  2010/07/06 13:46:18  aseaborne
  Clearup after publication.
  
  Remove redundant text.
  
  Remove mention of time-permitting now that the WG
  has decided to include the feature.
  
  Consolidate examples.
  
  Added "negated property sets" to syntax and examples.

  Revision 1.28  2010/06/20 15:59:26  aseaborne
  Editing notes

  Revision 1.27  2010/06/09 09:38:06  aseaborne
  Added doc structure for zero length and arbitrary length paths

  Revision 1.26  2010/06/08 12:32:46  aseaborne
  Add translation/evaluation table

  Revision 1.25  2010/05/27 16:15:22  aseaborne
  Sort out XSL processing to be self contained

  Revision 1.24  2010/05/27 16:07:38  aseaborne
  Note conclusions of TC 2010-05-27 in issues section

  Revision 1.22  2010/05/27 14:03:23  aseaborne
  Update issues

  Revision 1.21  2010/03/16 15:06:15  aseaborne
  Editor's notes

  Revision 1.20  2010/03/16 09:40:44  aseaborne
  Added editor's note

  Revision 1.19  2010/01/27 01:48:05  apollere2
  fixed broken fragment ID.

  Revision 1.18  2010/01/24 14:24:10  apollere2
  Document type is WD, not FPWD.

  Revision 1.17  2010/01/22 21:19:25  aseaborne
  Fix validation problems after XSLT transformation

  Revision 1.16  2010/01/22 16:26:23  apollere2
  XSLT conversion to gen.html for FPWD.

  Revision 1.15  2010/01/11 10:27:00  aseaborne
  Corrections and improvements in response to 2010JanMar/0099.

  Revision 1.14  2010/01/06 11:08:59  aseaborne
  Corrections and improvements in response to 2010JanMar/0055. See 2010JanMar/0057.

  Revision 1.13  2010/01/05 11:21:14  aseaborne
  Correct the description of operator precedence

  Revision 1.12  2010/01/04 12:11:14  aseaborne
  Fix markup

  Revision 1.11  2010/01/04 12:08:41  aseaborne
  Fix markup

  Revision 1.10  2010/01/04 12:07:23  aseaborne
  Fix markup

  Revision 1.9  2010/01/04 12:06:31  aseaborne
   Abstract expanded.
   Terminolgy change: "inverse", not "reverse"
   Issues section placed at front.  Added issues for path length and "^"
   Various editorial corrections.
   Fix example using foaf:knows^foaf:knows

  Revision 1.8  2009/11/06 15:11:30  aseaborne
  Transfer content from wiki

  Revision 1.7  2009/11/06 15:09:51  aseaborne
  Transfer content from wiki

  Revision 1.6  2009/11/06 15:05:47  aseaborne
  Transfer content from wiki

  Revision 1.5  2009/11/06 15:03:25  aseaborne
  Transfer content from wiki
  
  Revision 1.4  2009/11/06 14:57:35  aseaborne
  Transfer content from wiki
  
  Revision 1.3  2009/11/06 14:47:33  aseaborne
  Transfer content from wiki
  
  Revision 1.2  2009/11/06 14:34:53  aseaborne
  Transfer content from wiki
  
  Revision 1.1  2009/11/06 13:51:34  aseaborne
  xmlspec template