From Cypher 9 to GQL: Conceptual overview of multiple named graphs and composable queries

From Cypher 9 to GQL:
Conceptual overview of
Multiple Named Graphs
and Composable Queries
Petra Selmer, Alastair Green
Neo4j Query Languages Standards and Research
1

Cypher 9: A single, implicit graph (with three disconnected components)
3

Cypher 9: Create a disconnected component
//create nodes
CREATE (london:City {name: ‘London’})
CREATE (wood:CriminalEvent {name: ‘Babes..’, ...})
CREATE (battle:WarEvent {name: ‘Battle of..’, ...})
CREATE (king:RoyalEvent {name: ‘Coronation...’, ...})
//create relationships
CREATE (wood)-[:IN_CITY]->(london),
(battle)-[:IN_CITY]->(london),
(king)-[:IN_CITY]->(london)
4

Cypher 9: Projecting a table from a graph
Assume we have the following graph, containing
events (labelled by event types) and the cities in which
they occurred
We wish to return only the criminal events (i.e. labelled
with CriminalEvents) and the cities in which they
occurred (i.e. nodes labelled with City)
5

Cypher 9: Projecting a table from a graph (cont.)
MATCH (e:CriminalEvent)-[r:IN_CITY]->(c:City)
RETURN e, r, c
6
e r c
node(15) (Babes murders) relationship(23) node(16) (London)
node(21) (Shootout diner) relationship(26) node(22) (New York)
node(17) (Staten Island ferry) relationship(25) node(22) (New York)
node(19) (Mad Bomber) relationship(27) node(22) (New York)

GQL: Two distinct, named graphs (segmented by application domain)
Actors Events
8
Base

GQL: Projecting one of these graphs from the original single graph
//conceptual syntax
CREATE GRAPH Events {
FROM GRAPH Base
MATCH ()-[:IN_CITY]->()
RETURN GRAPH
}
9
Events

GQL: Projecting the CriminalEvents subgraph from the Events graph
//conceptual syntax
CREATE GRAPH CriminalEvents {
FROM Events
MATCH (e:CriminalEvents)-[:IN_CITY]->()
RETURN GRAPH
}
CriminalEvents
10

GQL: Projecting a new graph (“what the browser does”)
There is an experimental extension to the Neo4j Python driver that deduplicates nodes in the
binding table received as a result of RETURN <node>, <rel>, <node>
def __new__(cls, graph, n_id):
try:
inst = graph._nodes[n_id]
except KeyError:
inst = graph._nodes[n_id] = Entity.__new__(cls, graph, n_id)
inst._labels = set()
return inst
The Neo4j browser does the same thing (the code is more obscure)
https://github.com/neo4j/neo4j-browser/blob/master/src/shared/services/bolt/boltMappings.js#L169
Cypher for Apache Spark has similar functionality
11

In GQL the deduplication operation enables graph projection
In conceptual syntax
MATCH (a)-[R]-(b)
// deduplicate the nodes ← HERE
RETURN GRAPH
12

Options for the RETURNed GRAPH
The returned graph could be sent to a query processor (e.g. a client driver session)
Or it could be named conceptual syntax
{MATCH (a)-[R]-(b) … RETURN GRAPH} AS otc.trades.population.new
The scope/lifecycle of the graph name could vary by implementation
For example
Cypher for Apache Spark has volatile and non-volatile graph names in one Catalog
Other implementations might offer volatile query/session + Catalog persistent names
13

GQL: Querying the named graph CriminalEvents to get summary data
14
CriminalEvents

We wish to return (in a table) the number of criminal events, grouped by the city and year
FROM CriminalEvents
MATCH (e)-[:IN_CITY]->(c)
RETURN c.name AS City, e.year AS Year,
count(e) AS NumberOfCriminalEvents
City Year NumberOfCriminalEvents
London 1970 1
New York 1940 1
New York 1986 2
15

16
City Year NumberOfCriminalEvents
London 1970 1
New York 1940 1
New York 1986 2
Base graph
Summary data
CriminalEvents (view)Events (view)

Categorizing queries by their return type
Queries can return
Cypher 9 A table RETURN a, r.name AS n, b
Cypher 9 Nothing (e.g. updating/deleting some properties or entities)
Cypher 10/GQL A graph (Cypher 10/GQL) RETURN GRAPH
18

19
References and values, in Cypher 9 and GQL
In Cypher 9 all entities (nodes, edges) in the (single, default) graph are values
A binding table, during the execution of a query, contains references
It is possible to test, for example, if the start node of a relationship is the same entity as the end
node, which gives us multiple references to a single entity
In GQL, the proposal is to allow references to also be stored in a graph
A graph might be made up of values, or references, or both
A graph with references therefore shares the underlying value object with another graph
And a graph which references a reference entity in another graph is creating a reference chain

A reminder: the base graph (Base) and two views (Actors, Events)
Actors Events
20
Base

Starting from Events
21
Events

Extracting the Actor nodes from Actors
22
Actors

Copy into a new, distinct graph
Wherever the data came from
(literals or MATCHes in another
graph) it forms new entities in the
created graph
Everything is by value
23
ActorsAndEvents

Refer back to a source graph from the new graph (pure view)
All the data in the new graph is a
reference to an existing graph
Allows subtraction but not addition:
a view of a true sub-graph
24

New entities by value:
BORN_IN (100, 101, 102)
Entities by reference
Copy some, refer to others
25
ActorsAndEvents

26
Graphs with values/references are possible
They can be detached, or “snapped away” as a whole
Value copy
They can be superimposed and left strongly connected to their source graph(s)
Reference only
They can be a mixture (for example a roll-up value or a new relationship might be present
by value, but dimensional data may be drawn from the source graph)
Reference + value copies (Mixed)

Named queries
The name of a named query can be used in place of the return value of the query
Which means that a named query could equate to a table, nothing or a graph
In principle a named query could be viewed just as a way of modularizing code
But it’s perhaps more interesting to think of it as equivalent to a VIEW in SQL
Or as a “higher-order function”
27

Ways of working with a graph
In conceptual syntax you could imagine
FROM { MATCH ... RETURN GRAPH}
FROM otc.trades.history // a named graph that is stored persistently
FROM otc.trades.population.new // a named query that dynamically returns a graph
And indeed in nested sub-queries
FROM {FROM otc.trades.history MATCH … RETURN GRAPH} MATCH … RETURN a, b, c
28

Concurrent or Complex queries (subqueries)
QUERY {} AS PLONK, QUERY {} AS PLINK, QUERY {} AS PLUNK
{PLINK PLONK PLUNK} ← that’s a sequence, if that’s true then the output of one is known to its successors
If PLINK creates a table then PLONK can use it in WITH
If you view the scope of the “Query” as being the top-level complex query then names will create the connections
{PLINK PLONK PLUNK} ← that’s a parallel operation, so no sharing between queries ← implementation can parallelize and inspect for common inputs and there
will be multiple outputs
{ {RG} AS one {FROM one RG} as TWO {from TWO RT} } ← on the table, basic behaviour of subqueries
{ parallel{ {} AS one {CANNOT say FROM one} }}
{ FROM {FROM { RG 1} RG } RT } ← compose(), and no andThen()
29

Mixture of copied and referenced
Iff the named query retyrns a graph, can we think of it as a view
Image: show
30

From Cypher 9 to GQL: Conceptual overview of multiple named graphs and composable queries

More Related Content

What's hot (19)

Similar to From Cypher 9 to GQL: Conceptual overview of multiple named graphs and composable queries (20)

More from openCypher (20)

Recently uploaded (20)

From Cypher 9 to GQL: Conceptual overview of multiple named graphs and composable queries