Path Pattern Queries

[thobe]

This is first draft of a proposal for adding Path Patterns to Cypher. There is still work to be done here before this is finalised.

CIP2017-02-06

[thobe]

This proposal should eventually be able to fulfil the requirements outlined in #179.

[Mats-SX]

Nice CIP!

[Mats-SX]

We could use 'outgoing' instead of 'left-to-right', and 'incoming' instead of 'right-to-left'.

[thobe]

That would imply a particular traversal order, which I think is saying too much, with left-to-right and right-to-left we are only talking about the direction with regard to how the pattern is written.

[Mats-SX]

Will it be the job of the query compiler to determine reflexiveness of the defined predicate, and issue an error if non-reflexive predicates are defined (or used) without direction?

[thobe]

I'd say that either the query compiler issues an error, or the behaviour of the path predicate is undefined (i.e. the behaviour in such a case is outside of the scope of the specification).

I'd prefer for an implementation to issue an error, but I don't know how hard that analysis is to perform, and I thus don't want to mandate that at this point (it needs further analysis).

[Mats-SX]

This applies to the definition of a predicate, right? I imagine that it will be perfectly possible to reverse the direction in the Regular Path Pattern, like so:

MATCH (a)<-/pred/-(b)
PATH (a)-/pred/->(b) IS
     (a)-[:KNOWS]->(b)

How about it being used in an undirected Regular Path Pattern?

MATCH (a)-/pred/-(b)
PATH (a)-/pred/->(b) IS
     (a)-[:KNOWS]->(b)

[thobe]

Both of those are perfectly valid. The undirected use of a directed defined path predicate is the same as an OR/UNION between the two directions.

I.e. (a)-/pred/-(b) is the same as (a)-/<pred | pred>/-(b) (which is the same as (a)-/pred> | <pred/-(b) or (a)-/<pred>/-(b) or (a)<-/pred/->(b)).

[petraselmer]

I think it would be a good idea to mention somewhere that these are essentially RPQs, since RPQs are the standard term for these sorts of queries.

[petraselmer]

For 1 - 4 below, it would be great if these could be supplemented with regex notation

[thobe]

As in an example of what the syntax looks like?

[petraselmer]

Is it not meant to be "a syntax that is deprecated" (as RPPs are only being introduced now)?

[thobe]

I've tried writing the text as if Regular Path Patterns are already in the language, since when this text is merged, it will be in the language. Although is works in that case as well.

[petraselmer]

Aha - ok, that makes sense

[petraselmer]

"suffixing" -> "suffix"

[petraselmer]

The "giving that part the interpretation of being undirected" section is a bit unwieldy - maybe something along the lines of "indicating that that part of the pattern is undirected"

[thobe]

I've updated the document to unify the Path Pattern syntax with normal Pattern syntax. I have not yet updated the grammar to reflect that, I'll do that imminently.

[thobe]

I think it is important to note which things that is currently valid Cypher will have changed semantics under this proposal:

• Binding a variable under repetition will no longer be possible. I.e. this pattern is now invalid: (a)-[rels*]->(b), the way to achieve such a binding is by binding the pattern to a path variable (p=(a)-[-*]->(b)) and using the relationships function to access the relationships of the path (WITH *, relationships(p) AS rels).
• Property predicates will have a different scope if colons are used when separating alternatives of relationship types. The pattern ()-[:FOO|:BAR{baz=17}]-() used to mean any relationship of type FOO or type BAR where the property baz has value 17, but under this proposal the semantics would be any relationship of type FOO or any relationship of type BAR where the property baz has value 17, i.e. under the old semantics the property predicate applied to both relationship types, but under the new semantics it only applies to the BAR relationships. The old semantics are still used if colon is not used in the listing of relationship types as in ()-[:FOO|BAR{baz=17}]-().

[thobe]

Notable example queries that cannot be expressed using this syntax includes:

• Paths between two nodes that does not match a given pattern.
  Cypher can still express such a cartesian product, but not as a path.
• Paths where the value of a given property in all nodes of the path differs from the value of that property at the first node of the path.
  This is one of the canonical examples of Regular Expressions with Memory (REMs)
• Paths where a certain property has a different value in all nodes.

[Mats-SX]

This section is mostly repetition of the section Directions above. Perhaps replace this with a reference to that section? Something like

Using the arrowhead syntax introduced in [[directions]], consider the following query

[Mats-SX]

The example DPP does define direction of the relationships, which perhaps it should not, in order to be an example of when leaving the definition out is okay (reflexivity)?

[thobe]

But it is an example of when the named path pattern itself is undirected - and the direction is left out on the next row.

[Mats-SX]

Ah, so the meaning is that it is allowed to omit the direction of a path pattern that references a DPP, but only when the DPP is reflexive. Got it.

[petraselmer]

Two things:

1. Please can some more examples be added to further exemplify the use of this feature?

For example, drawn from life sciences, it would be good to see these queries:
Query 1) 'Return all pairs of directly-connected nodes (a,b) where every second node in the path must have label A.'
Query 2) 'Return all pairs of directly-connected nodes (a,b) where there are at least 2 instances of a node labelled with X linked to a node labelled with Y in the path.'

2. Your comment beginning 'Notable example queries that cannot be expressed using this syntax includes....' is very pertinent. Can this be added to the CIP itself for the purposes of rigour and completeness?

[Mats-SX]

Perhaps we should add a reference to this claim.

[thobe]

I wrote up some slides that give an overview of the history of this proposal, what is has been influenced by and what other things has been influenced by it. This information should provide some insight into some of the design choices made in this CIP.

The slides are available on the opencypher.org/references page

[gsvgit]

It looks like examples are not match with grammar for NamedPathPredicate. In examples like

PATH PATTERN unreciprocated_love = (a)-[:LOVES]->(b)

we see, that it should be something like PatternPart (maybe without [Variable, '='] part) in NamedPathPredicate after = instead of PathPattern.

So, I think that correct rule should be

NamedPathPredicate   = 'PATH', 'PATTERN', NamedPathName, '=', NodePattern, {(EdgePattern | PathPattern), NodePattern}, [Where] ;

[thobe]

Yes, you are right, thank you!