Fix terminology consistencies (vertex to node and relationship to edge)

Reviewers: buda, mtomic

Reviewed By: buda

Differential Revision: https://phabricator.memgraph.io/D1526
This commit is contained in:
Ivan Paljak 2018-08-02 13:26:23 +02:00
parent 23d4391c29
commit 4d3c0a2fa5
6 changed files with 34 additions and 33 deletions

View File

@ -21,7 +21,7 @@
* [Enterprise Ed.] Improve Cartesian support in distributed queries.
* [Enterprise Ed.] Improve distributed execution of BFS.
* [Enterprise Ed.] Dynamic graph partitioner added.
* Static vertices/edges id generators exposed through the Id Cypher function.
* Static nodes/edges id generators exposed through the Id Cypher function.
* Properties on disk added.
* Telemetry added.
* SSL support added.
@ -83,7 +83,7 @@
* CASE construct (without aggregations).
* Named path support added.
* Maps can now be stored as vertex/edge properties.
* Maps can now be stored as node/edge properties.
* Map indexing supported.
* `rand` function added.
* `assert` function added.

View File

@ -63,7 +63,7 @@ with total cost of `11`. Obviously, the second query can find the true shortest
path because it has no restrictions on the length.
To handle cases when the length restriction is set, *weighted shortest path*
algorithm uses both vertex and distance as the state. This causes the search
algorithm uses both node and distance as the state. This causes the search
space to increase by the factor of the given upper bound. On the other hand, not
setting the upper bound parameter, the search space might contain the whole
graph.

View File

@ -24,15 +24,15 @@ session = driver.session()
# After each query, call either `consume()` or `data()`
session.run('CREATE (alice:Person {name: "Alice", age: 22})').consume()
# Get all the vertices from the database (potentially multiple rows).
vertices = session.run('MATCH (n) RETURN n').data()
# Get all the nodes from the database (potentially multiple rows).
nodes = session.run('MATCH (n) RETURN n').data()
# Assuming we started with an empty database, we should have Alice
# as the only row in the results.
only_row = vertices.pop()
only_row = nodes.pop()
alice = only_row["n"]
# Print out what we retrieved.
print("Found a vertex with labels '{}', name '{}' and age {}".format(
print("Found a node with labels '{}', name '{}' and age {}".format(
alice['name'], alice.labels, alice['age'])
# Remove all the data from the database.

View File

@ -14,19 +14,19 @@ to model this data as a graph and demonstrate a few example queries.
#### Data Model
Each TED talk has a main speaker, so we
identify two types of nodes — `Talk` and `Speaker`. Also, we will add
an edge of type `Gave` pointing to a `Talk` from its main `Speaker`.
Each speaker has a name so we can add property `name` to `Speaker` node.
Likewise, we'll add properties `name`, `title` and `description` to node
`Talk`. Furthermore, each talk is given in a specific TED event, so we can
create node `Event` with property `name` and relationship `InEvent` between
identify two node labels — `Talk` and `Speaker`. Also, we will add
an edge labelled `Gave` pointing to a node labelled `Talk` from its
main `Speaker`. Each speaker has a name so we can add property `name` to
`Speaker` node. Likewise, we'll add properties `name`, `title` and `description`
to node `Talk`. Furthermore, each talk is given in a specific TED event, so we
can create a node `Event` with property `name` and an edge `InEvent` between
talk and event.
Talks are tagged with keywords to facilitate searching, hence we
add node `Tag` with property `name` and relationship `HasTag` between talk and
add a node `Tag` with property `name` and an edge `HasTag` between talk and
tag. Moreover, users give ratings to each talk by selecting up to three
predefined string values. Therefore we add node `Rating` with these values as
property `name` and relationship`HasRating` with property `user_count` between
predefined string values. Therefore we add a node `Rating` with these values as
property `name` and an edge `HasRating` with property `user_count` between
talk and rating nodes.
#### Example Queries
@ -171,7 +171,7 @@ ORDER BY Speaker;
### Football Example
[Football](https://en.wikipedia.org/wiki/Association_football)
(soccer for the heathens) is a team sport played between two teams of eleven
is a team sport played between two teams of eleven
players with a spherical ball. The game is played on a rectangular pitch with
a goal at each and. The object of the game is to score by moving the ball
beyond the goal line into the opposing goal. The game is played by more than
@ -189,7 +189,7 @@ Two of the nodes will represent the teams that have played the match, while the
third node will represent the game itself. Both edges are directed from the
team nodes to the game node and are labeled as `:Played`.
Let us consider a real life example of this model—Arsene Wenger's 1000th.
Let us consider a real life example of this model—Arsene Wenger's 1000th
game in charge of Arsenal. This was a regular fixture of a 2013/2014
English Premier League, yet it was written in the stars that this historic
moment would be a big London derby against Chelsea on Stanford Bridge. The
@ -426,17 +426,17 @@ than 200 km in one go.
```opencypher
MATCH p = (:City {name: "Zagreb"})
-[:Road * bfs (e, v | e.length <= 200)]->
-[:Road * bfs (e, n | e.length <= 200)]->
(:City {name: "Paris"})
RETURN nodes(p);
```
"What is this special syntax?", you might wonder.
`(e, v | e.length <= 200)` is called a *filter lambda*. It's a function that
takes an edge symbol `e` and a vertex symbol `v` and decides whether this edge
and vertex pair should be considered valid in breadth-first expansion by
returning true or false (or nil). In the above example, lambda is returning
`(e, n | e.length <= 200)` is called a *filter lambda*. It's a function that
takes an edge symbol `e` and a node symbol `n` and decides whether this edge
and node pair should be considered valid in breadth-first expansion by
returning true or false (or Null). In the above example, lambda is returning
true if edge length is not greater than 200, because we don't want to bike more
than 200 km in one go.
@ -446,7 +446,7 @@ time. We just have to update our filter lambda.
```opencypher
MATCH p = (:City {name: "Zagreb"})
-[:Road * bfs (e, v | e.length <= 200 AND v.name != "Vienna")]->
-[:Road * bfs (e, n | e.length <= 200 AND n.name != "Vienna")]->
(:City {name: "Paris"})
RETURN nodes(p);
```
@ -461,15 +461,15 @@ shortest path from Zagreb to Paris along with the total length of the path.
```opencypher
MATCH p = (:City {name: "Zagreb"})
-[:Road * wShortest (e, v | e.length) total_weight]->
-[:Road * wShortest (e, n | e.length) total_weight]->
(:City {name: "Paris"})
RETURN nodes(p) as cities, total_weight;
```
As you can see, the syntax is quite similar to breadth-first search syntax.
Instead of a filter lambda, we need to provide a *weight lambda* and the *total
weight symbol*. Given an edge and vertex pair, weight lambda must return the
cost of expanding to the given vertex using the given edge. The path returned
weight symbol*. Given an edge and node pair, weight lambda must return the
cost of expanding to the given node using the given edge. The path returned
will have the smallest possible sum of costs and it will be stored in the total
weight symbol. A limitation of Dijkstra's algorithm is that the cost must be
non-negative.
@ -480,7 +480,7 @@ more that 200 km in one go for our bike route.
```opencypher
MATCH p = (:City {name: "Zagreb"})
-[:Road * wShortest (e, v | e.length) total_weight (e, v | e.length <= 200)]->
-[:Road * wShortest (e, n | e.length) total_weight (e, n | e.length <= 200)]->
(:City {name: "Paris"})
RETURN nodes(p) as cities, total_weight;
```
@ -489,7 +489,7 @@ RETURN nodes(p) as cities, total_weight;
```opencypher
MATCH (:City {name: "Zagreb"})
-[:Road * wShortest (e, v | e.length) total_weight]->
-[:Road * wShortest (e, n | e.length) total_weight]->
(c:City)
RETURN c, total_weight
ORDER BY total_weight DESC LIMIT 10;

View File

@ -670,7 +670,7 @@ functions.
`keys` | Returns a list keys of properties from an edge or a node. Each key is represented as a string of characters.
`labels` | Returns a list of labels from a node. Each label is represented as a character string.
`nodes` | Returns a list of nodes from a path.
`relationships` | Returns a list of relationships from a path.
`relationships` | Returns a list of relationships (edges) from a path.
`range` | Constructs a list of value in given range.
`tail` | Returns all elements after the first of a given list.
`abs` | Returns the absolute value of a number.

View File

@ -228,9 +228,10 @@ CREATE (u:User {name: "Alice"})-[:Likes]->(m:Software {name: "Memgraph"});
The above will create 2 nodes in the database, one labeled "User" with name
"Alice" and the other labeled "Software" with name "Memgraph". It will also
create a relationship that "Alice" *likes* "Memgraph".
create an edge labeled "Likes". Those three graph elements jointly represent
the fact that "Alice" *likes* "Memgraph".
To find created nodes and relationships, execute the following query:
To find created nodes and edges, execute the following query:
```opencypher
MATCH (u:User)-[r]->(x) RETURN u, r, x;
@ -261,7 +262,7 @@ Telemetry is an automated process by which some useful data is collected at
a remote point. At Memgraph, we use telemetry for the sole purpose of improving
our product, thereby collecting some data about the machine that executes the
database (CPU, memory, OS and kernel information) as well as some data about the
database runtime (CPU usage, memory usage, vertices and edges count).
database runtime (CPU usage, memory usage, node and edge count).
Here at Memgraph, we deeply care about the privacy of our users and do not
collect any sensitive information. If users wish to disable Memgraph's telemetry