SPARQL 1.1 Property Paths @import url("../shared/local.css");
code { font-family: monospace; }
div.constraint, div.issue, div.note, div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; } ol.enumla { list-style-type: lower-alpha; } ol.enumlr { list-style-type: lower-roman; } ol.enumua { list-style-type: upper-alpha; } ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em; margin-top: 0em; margin-bottom: 0em} div.exampleOuter {border: 4px double gray; margin: 0em; padding: 0em} div.exampleInner { background-color: #d5dee3; border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; border-bottom-width: 4px; border-bottom-style: double; border-bottom-color: #d3d3d3; padding: 4px; margin: 0em } div.exampleWrapper { margin: 4px } div.exampleHeader { font-weight: bold; margin: 4px}
em.rfc2119 { text-transform: lowercase; font-variant: small-caps; font-style: normal; } Obsolete Draft This document is obsolete. The normative text is: SPARQL 1.1 Query Language, Section 9: Property Paths This version: http://www.w3.org/TR/2010/WD-sparql11-property-paths-20100126/ Latest version: http://www.w3.org/TR/sparql11-property-paths/ Editor: Andy Seaborne, Talis Information Limited <[email protected]> Copyright W3C ® MIT ERCIM Keio liability trademark document use 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. Property paths are a time-permitting 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 This is the First Public Working Draft This is a time-permitting feature Comments on this document should be sent to [email protected] public archive [email protected] public archive This document was produced by the SPARQL Working Group W3C Semantic Web Activity No Endorsement Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Patents This document was produced by a group operating under the 5 February 2004 W3C Patent Policy public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy 1 Introduction Document Conventions Outstanding Issues Path Language Path Terminology Examples Simple Paths Complex Paths Syntax Algebra Evaluation A References CVS History 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. EBNF This section notes significant areas of discussion. Comments from the community are actively sought on these matters, as well as the rest of the document. Please send comments to [email protected] The use of " ^ /^ N3 path syntax ^ While property paths as currently specified can be used to access RDF lists (e.g. rdf:rest*/rdf:first), the Working Group notes that this would be more useful if results were returned in the order they occur in the RDF list. This presents significant complexity in the context of the existing SPARQL algebra. The WG has discussed providing access to the length of matched paths, which would provide greater functionality but would complicate path evaluation. At this time, the WG's primary aim is to specify a core set of functionality while not blocking future enhancements. How does this interact with inference when SPARQL is used with systems carrying out inference as part of query processing? Paths expressions match once even if there are multiple possible paths between two points (c.f. SPARQL BGP) A property path expression (or just 'path') is similar to a string regular expression but over properties, not characters. Query evaluation determines all matches of a path expression and binds subject or object as appropriate. Only one match per route through the graph is recorded - no duplicates for any given path expression. In the description below, uri elt Syntax Form Matches uri A URI or a prefixed name. A path of length one. ^elt Inverse path (object to subject). (elt) A group path elt elt1 / elt2 A sequence path of elt1 elt2 elt1 ^ elt2 Shorthand for elt1 / ^elt2 elt1 elt2 elt1 | elt2 A alternative path of elt1 elt2 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 elt elt{n,} n elt elt{,n} Between 0 and n elt A zero occurrence of a path element always matches. Precedence: URI, prefixed names Groups Unary operators * ? + {} Unary ^ inverse links Binary operators / Binary operator | Precedence is left-to-right within groups. Paths are "simple" if they involve only operators / (sequence), ^ (inverse, unary or binary) and the form { n n A path of just a URI is still a single triple pattern. A path is "complex" if it involves one or more of the operators *,?, + and {} {n} A path of length zero connects a graph node to itself. Cycles in paths are possible and are handled. Paths do not need to be anchored at one end or the other,
although this can lead to large numbers of result because the whole graph is searched. See also uses cases Find the name of any people that Alice knows. { ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows/foaf:name ?name . } Find the names of people 2 " foaf:knows { ?x foaf:mbox <mailto:alice@example> . ?x foaf:knows/foaf:knows/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 . } 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 } 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 } Find all the people who know someone ?x { ?x foaf:knows^foaf:knows ?y . FILTER(?x != ?y) } 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 . } 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 } 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' | '(' Path ')' ) @@Will need to introduce temporary variables to expand simple paths. @@Unfinished section Path evaluation yields a set of bindings of variables (excluding any system-generated variables). If there are two or more paths, from <a> to <b>, only a unique solution is returned. Cycles are permitted and included in matches. Cycle detection is necessary. Triple patterns are equivalent to a path of length exactly one. $Log: Overview.html,v $ Revision 1.4 2018/10/09 13:23:18 denis fix validation of xhtml documents
Revision 1.3 2017/10/02 10:42:16 denis add fixup.js to old specs
Revision 1.2 2014/01/10 19:59:41 sandro *** empty log message ***
Revision 1.1 2010-01-27 16:24:12 bertails sparql
Revision 1.9 2010/01/27 01:48:05 apollere2 fixed broken fragment ID.
Revision 1.8 2010/01/24 14:46:12 apollere2 Minor typo fix.CVS: ----------------------------------------------------------------------
Revision 1.7 2010/01/24 14:45:21 apollere2 Changed Editor's draft to First Public working draft.
Revision 1.6 2010/01/24 14:40:51 apollere2 Added no-endorsement boiler plate.
Revision 1.5 2010/01/24 14:34:30 apollere2 Fixes of URIs in gen.html.
Revision 1.4 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 2010JanMar/0055 2010JanMar/0057