Ensure term consistency: nodes vs vertices

site/content/3.13/about-arangodb/_index.md

@@ -21,21 +21,21 @@ cloud service, the [ArangoGraph Insights Platform](../arangograph/_index.md).
 
 ## What are Graphs?
 
-Graphs are information networks comprised of nodes and relations.
+Graphs are information networks comprised of nodes and edges.
 
-![Node - Relation - Node](../../images/data-model-graph-relation-abstract.png)
+![An arrow labeled as "Edge" pointing from one circle to another, both labeled "Node"](../../images/data-model-graph-relation-abstract-edge.png)
 
 A social network is a common example of a graph. People are represented by nodes
 and their friendships by relations.
 
-![Mary - is friend of - John](../../images/data-model-graph-relation-concrete.png)
+![Two circles labeled "Mary" and "John", with an arrow labeled "isFriendOf" pointing from "Mary" to "John"](../../images/data-model-graph-relation-concrete.png)
 
-Nodes are also called vertices (singular: vertex), and relations are edges that
-connect vertices.
-A vertex typically represents a specific entity (a person, a book, a sensor
+Nodes are also called vertices (singular: vertex), and edges are relations that
+connect nodes.
+A node typically represents a specific entity (a person, a book, a sensor
 reading, etc.) and an edge defines how one entity relates to another.
 
-![Mary - bought - Book, is friend of - John](../../images/data-model-graph-relations.png)
+![Three circles labeled "Mary", "Book", and "John", with an arrow labeled "bought" from "Mary" to "Book" and an arrow labeled "isFriendOf" from "Mary" to "John"](../../images/data-model-graph-relations.png)
 
 This paradigm of storing data feels natural because it closely matches the
 cognitive model of humans. It is an expressive data model that allows you to
@@ -50,19 +50,14 @@ JSON objects, without having to connect these objects to form a graph.
 
 ![Person Mary, Book ArangoDB](../../images/data-model-document.png)
 
-<!-- TODO:
-Seems too disconnected, what is the relation?
-Maybe multiple docs, maybe also include folders (collections)?
--->
-
 Depending on your needs, you may mix graphs and unconnected data.
 ArangoDB is designed from the ground up to support multiple data models with a
 single, composable query language.
 
 ```aql
 FOR book IN Books
-  FILTER book.title == "ArangoDB"
-  FOR person IN 2..2 INBOUND book Sales, OUTBOUND People
+  FILTER book.title == "Arango"
+  FOR person IN 2..2 INBOUND book transferred, OUTBOUND knows
     RETURN person.name
 ```
 

site/content/3.13/about-arangodb/features/core.md

@@ -14,9 +14,10 @@ aliases:
 ## General
 
 - [**Graph Database**](../../concepts/data-models.md#graph-model):
-  Native support for storing and querying graphs comprised of vertices and edges.
-  You can model complex domains because edges are documents without any
-  restrictions in complexity.
+  Native support for storing and querying graphs comprised of nodes and edges.
+  You can model complex domains because both nodes and edges are fully-fledged
+  documents, without restrictions in complexity. Edges can connect node documents
+  to express m:n relations with any depth.
 
 - [**Document Database**](../../concepts/data-models.md#document-model):
   A modern document database system that allows you to model data intuitively
@@ -73,11 +74,7 @@ aliases:
   collection, you can configure how many copies of each shard are kept in the cluster.
 
 - [**Automatic Failover Cluster**](../../deploy/cluster/_index.md#automatic-failover):
-  If a node goes down, another node takes over to avoid any downtime. <!-- TODO: Can we say that? -->
-
-{{% comment %}}
-  TODO: - **Master/Master Conflict Resolution**: What does this refer to? How does it work? MVCC?
-{{% /comment %}}
+  If a cluster node goes down, another node takes over to avoid downtime.
 
 - **Load-Balancer Support**:
   Round-robin load-balancer support for cloud environments.
@@ -111,25 +108,21 @@ aliases:
   insert-or-ignore requests, that result in one or the other operation depending
   on whether the target document exists already.
 
-- **Graph Relations**:
-  Edges can connect vertex and even edge documents to express complex m:n
-  relations with any depth, creating graphs and hyper-graphs.
-  <!-- TODO: does this refer to the data model, graph traversals, or something else? -->
-
 - [**Relational Joins**](../../aql/examples-and-query-patterns/joins.md):
   Joins similar to those in relational database systems can be leveraged to
   match up documents from different collections, allowing normalized data models.
 
 - **Advanced Path-Finding with Multiple Algorithms**:
-  Graphs can be [traversed](../../aql/graphs/traversals-explained.md) with AQL to
-  retrieve direct and indirect neighbor nodes using a fixed or variable depth.
+  Graphs can be [traversed](../../aql/graphs/traversals-explained.md) with AQL
+  in outbound, inbound, or both directions to retrieve direct and indirect
+  neighbor nodes using a fixed or variable depth.
   The [traversal order](../../aql/graphs/traversals.md) can be
   depth-first, breadth-first, or in order of increasing edge weights
   ("Weighted Traversals"). Stop conditions for pruning paths are supported.
   Traversal algorithms to get a [shortest path](../../aql/graphs/shortest-path.md),
   [all shortest paths](../../aql/graphs/all-shortest-paths.md), paths in order of
   increasing length ("[k Shortest Paths](../../aql/graphs/k-shortest-paths.md)"),
-  and to enumerate all paths between two vertices
+  and to enumerate all paths between two nodes
   ("[k Paths](../../aql/graphs/k-paths.md)") are available, too.
 
 - [**ArangoSearch for Text Search and Ranking**](../../index-and-search/arangosearch/_index.md):
@@ -235,7 +228,7 @@ aliases:
 
 - [**Traversal**](../../release-notes/version-3.7/whats-new-in-3-7.md#traversal-parallelization-enterprise-edition)
   [**Parallelization**](../../release-notes/version-3.10/whats-new-in-3-10.md#parallelism-for-sharded-graphs-enterprise-edition):
-  Parallel execution of traversal queries with many start vertices, leading to
+  Parallel execution of traversal queries with many start nodes, leading to
   faster results.
 
 - [**Traversal Projections**](../../release-notes/version-3.10/whats-new-in-3-10.md#traversal-projections-enterprise-edition):

site/content/3.13/about-arangodb/features/highlights-by-version.md

@@ -137,7 +137,7 @@ Also see [What's New in 3.11](../../release-notes/version-3.11/whats-new-in-3-11
   `arangosearch` View support that allows you to implement entity resolution.
 
 - [**Parallelism for sharded graphs**](../../release-notes/version-3.10/whats-new-in-3-10.md#parallelism-for-sharded-graphs-enterprise-edition):
-  Parallel execution of AQL traversal queries with many start vertices for all
+  Parallel execution of AQL traversal queries with many start nodes for all
   types of sharded graphs, leading to faster results.
 
 - [**Traversal Projections**](../../release-notes/version-3.10/whats-new-in-3-10.md#traversal-projections-enterprise-edition): 
@@ -175,7 +175,7 @@ Also see [What's New in 3.9](../../release-notes/version-3.9/whats-new-in-3-9.md
 - [**Weighted traversals**](../../release-notes/version-3.8/whats-new-in-3-8.md#weighted-traversals)
   and [**k Paths**](../../release-notes/version-3.8/whats-new-in-3-8.md#k-paths):
   Two new AQL graph traversal methods to emit paths in order of increasing
-  weights and to enumerate all paths between a source and a target vertex that
+  weights and to enumerate all paths between a start and a end node that
   match a given length.
 
 - **ArangoSearch**:
@@ -242,7 +242,7 @@ Also see [What's New in 3.8](../../release-notes/version-3.8/whats-new-in-3-8.md
 
 - [**Disjoint SmartGraphs**](../../release-notes/version-3.7/whats-new-in-3-7.md#disjoint-smartgraphs):
   Improve traversal execution times for SmartGraphs without edges between
-  vertices with different SmartGraph attributes.
+  nodes with different SmartGraph attribute values.
 
 - [**Traversal parallelization**](../../release-notes/version-3.7/whats-new-in-3-7.md#traversal-parallelization-enterprise-edition):
   Optional parallel execution of nested traversals for single servers and

site/content/3.13/aql/examples-and-query-patterns/actors-and-movies-dataset-queries.md

@@ -5,7 +5,7 @@ weight: 35
 description: >-
   Example queries showing different AQL query features and combinations of them
 ---
-Given a graph `[actors] – actsIn → [movies]` with two vertex collections
+Given a graph `[actors] – actsIn → [movies]` with two node collections
 **actors** and **movies** and an edge collection **actsIn** with edges pointing
 from actor to movie, plenty of interesting queries are possible:
 
@@ -287,7 +287,7 @@ db._query(`
 ### All common movies between "actor1" and "actor2"
 
 This is actually identical to the question about common actors in movie1 and
-movie2. We just have to change the starting vertices. As an example let us find
+movie2. We just have to change the starting nodes. As an example let us find
 all movies where Hugo Weaving and Keanu Reeves are co-starring:
 
 ```js
@@ -316,7 +316,7 @@ db._query(`
 ### All actors who acted in 3 or more movies
 
 Will make use of the edge index and the `COLLECT` statement of AQL for
-grouping. The basic idea is to group all edges by their start vertex
+grouping. The basic idea is to group all edges by their start node
 (which in this dataset is always the actor). Then we remove all actors with
 less than 3 movies from the result. Below query also returns the computed
 number of movies an actor has acted in:

site/content/3.13/aql/examples-and-query-patterns/joins.md

@@ -439,7 +439,7 @@ arangosh> db._query(
 ...> "LET authorsByBook = ( " +
 ...> "    FOR author, writtenBy IN INBOUND b written " +
 ...> "    RETURN { " +
-...> "        vertex: author, " +
+...> "        node: author, " +
 ...> "        edge: writtenBy " +
 ...> "    } " +
 ...> ") " +
@@ -461,7 +461,7 @@ arangosh> db._query(
     },
     "authors" : [
       {
-        "vertex" : {
+        "node" : {
           "_key" : "2935261693",
           "_id" : "authors/2935261693",
           "_rev" : "2935261693",
@@ -480,7 +480,7 @@ arangosh> db._query(
         }
       },
       {
-        "vertex" : {
+        "node" : {
           "_key" : "2938210813",
           "_id" : "authors/2938210813",
           "_rev" : "2938210813",
@@ -503,7 +503,7 @@ arangosh> db._query(
 ]
 ```
 
-Or if you want only the information stored in the vertices, you can use this query:
+Or if you want only the information stored in the nodes, you can use this query:
 
 ```js
 arangosh> db._query(

site/content/3.13/aql/examples-and-query-patterns/remove-vertex.md → site/content/3.13/aql/examples-and-query-patterns/remove-nodes.md

@@ -1,23 +1,25 @@
 ---
-title: Remove vertices with AQL
-menuTitle: Remove vertex
+title: Remove nodes with AQL
+menuTitle: Remove nodes
 weight: 45
 description: >-
-  Removing connected edges along with vertex documents directly in AQL is
+  Removing connected edges along with node documents directly in AQL is
   possible in a limited way
+aliases:
+  - remove-vertex
 ---
-Deleting vertices with associated edges is currently not handled via AQL while 
-the [graph management interface](../../graphs/general-graphs/management.md#remove-a-vertex)
+Deleting nodes with associated edges is currently not handled via AQL while 
+the [graph management interface](../../graphs/general-graphs/management.md#remove-a-node)
 and the
-[REST API for the graph module](../../develop/http-api/graphs/named-graphs.md#remove-a-vertex)
-offer a vertex deletion functionality.
+[REST API for the graph module](../../develop/http-api/graphs/named-graphs.md#remove-a-node)
+offer a node deletion functionality.
 However, as shown in this example based on the
 [Knows Graph](../../graphs/example-graphs.md#knows-graph), a query for this 
 use case can be created.
 
 ![Example Graph](../../../images/knows_graph.png)
 
-When deleting vertex **eve** from the graph, we also want the edges
+When deleting node **eve** from the graph, we also want the edges
 `eve -> alice` and `eve -> bob` to be removed.
 The involved graph and its only edge collection has to be known. In this case it 
 is the graph **knows_graph** and the edge collection **knows**.
@@ -38,7 +40,7 @@ REMOVE 'eve' IN persons
 This query executed several actions:
 - use a graph traversal of depth 1 to get the `_key` of **eve's** adjacent edges
 - remove all of these edges from the `knows` collection
-- remove vertex **eve** from the `persons` collection
+- remove node **eve** from the `persons` collection
 
 The following query shows a different design to achieve the same result:
 
@@ -53,10 +55,10 @@ LET edgeKeys = (FOR v, e IN 1..1 ANY 'persons/eve' GRAPH 'knows_graph'
 REMOVE 'eve' IN persons
 ```
 
-**Note**: The query has to be adjusted to match a graph with multiple vertex/edge collections.
+**Note**: The query has to be adjusted to match a graph with multiple node/edge collections.
 
 For example, the [City Graph](../../graphs/example-graphs.md#city-graph) 
-contains several vertex collections - `germanCity` and `frenchCity` and several 
+contains several node collections - `germanCity` and `frenchCity` and several 
 edge collections -  `french / german / international Highway`.
 
 ![Example Graph2](../../../images/cities_graph.png)

site/content/3.13/aql/examples-and-query-patterns/traversals.md

@@ -5,9 +5,9 @@ weight: 40
 description: >-
   You can combine graph queries with other AQL features like geo-spatial search
 ---
-## Finding the start vertex via a geo query
+## Finding the start node via a geo query
 
-Our first example will locate the start vertex for a graph traversal via [a geo index](../../index-and-search/indexing/working-with-indexes/geo-spatial-indexes.md).
+Our first example will locate the start node for a graph traversal via [a geo index](../../index-and-search/indexing/working-with-indexes/geo-spatial-indexes.md).
 We use the [City Graph](../../graphs/example-graphs.md#city-graph) and its geo indexes:
 
 ![Cities Example Graph](../../../images/cities_graph.png)

site/content/3.13/aql/execution-and-performance/query-profiling.md

@@ -184,13 +184,13 @@ mistakes that we see quite often:
 Bad example:
 
 ```aql
-LET vertices = (
-  FOR v IN 1..2 ANY @startVertex GRAPH 'my_graph'
+LET nodes = (
+  FOR n IN 1..2 ANY @startNode GRAPH 'my_graph'
     // <-- add a LIMIT 1 here
-    RETURN v
+    RETURN n
 )
 FOR doc IN collection
-  FILTER doc.value == vertices[0].value
+  FILTER doc.value == nodes[0].value
   RETURN doc
 ```
 
@@ -201,7 +201,7 @@ computing all paths.
 Another mistake is to start a graph traversal from the wrong side
 (if both ends are known).
 
-Assume we have two vertex collections _users_ and _products_ as well as an
+Assume we have two node collections _users_ and _products_ as well as an
 edge collection _purchased_. The graph model looks like this:
 `(users) <--[purchased]--> (products)`, i.e. every user is connected with an
 edge in _purchased_ to zero or more _products_.
@@ -212,8 +212,8 @@ as well as products of `type` _legwarmer_ we could use this query:
 ```aql
 FOR prod IN products
   FILTER prod.type == 'legwarmer'
-  FOR v,e,p IN 2..2 OUTBOUND prod purchased
-    FILTER v._key == 'playstation' // <-- last vertex of the path
+  FOR v, e, p IN 2..2 OUTBOUND prod purchased
+    FILTER v._key == 'playstation' // <-- last node of the path
     RETURN p.vertices[1] // <-- the user
 ```
 
@@ -223,7 +223,7 @@ the known _playstation_ product. This way we only need a single traversal
 to achieve the same result:
 
 ```aql
-FOR v,e,p IN 2..2 OUTBOUND 'product/playstation' purchased
-  FILTER v.type == 'legwarmer' // <-- last vertex of the path
+FOR v, e, p IN 2..2 OUTBOUND 'product/playstation' purchased
+  FILTER v.type == 'legwarmer' // <-- last node of the path
   RETURN p.vertices[1] // <-- the user
 ```

site/content/3.13/aql/graphs/_index.md

@@ -16,15 +16,15 @@ The two options in managing graphs are to either use
 
 Named graphs can be defined through the [graph-module](../../graphs/general-graphs/_index.md)
 or via the [web interface](../../components/web-interface/_index.md).
-The definition contains the name of the graph, and the vertex and edge collections
+The definition contains the name of the graph, and the node and edge collections
 involved. Since the management functions are layered on top of simple sets of
 document and edge collections, you can also use regular AQL functions to work with them. 
 
 Both variants (named graphs and loosely coupled collection sets a.k.a. anonymous graphs)
 are supported by the AQL language constructs for graph querying. These constructs
 make full use of optimizations and therefore best performance is to be expected:
 
-- [AQL Traversals](traversals.md) to follow edges connected to a start vertex,
+- [AQL Traversals](traversals.md) to follow edges connected to a start node,
   up to a variable depth. It can be combined with AQL filter conditions.
 
 - [AQL Shortest Path](shortest-path.md) to find one shortest path