Chapter 05A Conceptual Glossary of GQL

This chapter collects the technical vocabulary used in the semantic chapters of the book. It is not arranged alphabetically, because an alphabetic list is convenient for lookup but poor for learning a model. Instead, the terms are ordered as a reading path: elementary notions come first, and later sections build on the words that have already been introduced. The aim is that a reader can move through the chapter without encountering a central technical term before it has been explained.

The definitions are intentionally short. They do not replace the full formal development in the main chapters, but they provide a compact conceptual map of that development. When a term has a precise formal treatment elsewhere, the definition below states the role of the term and the intuition needed to follow later references. The sequence also indicates how the parts of GQL fit together: values and names support stored structures, stored structures support patterns, patterns produce tables, tables are transformed by queries, while updates, transactions, authorization, and diagnostics govern execution.

5.1 Foundations

We begin with the vocabulary that is needed before any particular data model is discussed. A statement manipulates data by means of values, and the language needs types to say which values are admissible in a given position. Names and identifiers then give the text of a statement a way to refer to things, while variables and bindings explain how evaluation records intermediate choices. The last terms in this section move from single bindings to mappings and merges, because later evaluation rules repeatedly combine partial assignments into larger assignments. No structural assumptions are needed yet; the point is only to establish the naming and binding machinery on which the rest of the chapter depends. The basic terms for this layer are:

Data: facts or stored content available to GQL for reading, returning, or changing.
Type: a classification that determines which data items are admissible in a particular place.
Value: a definite, immutable, and irreducible unit of data of some type.
Null value: the special value used to indicate the absence of other data.
Data type: a set of elements with shared characteristics representing data.
GQL-program: a complete top-level syntactic unit of GQL.
GQL-request: a GQL-program together with a possibly empty dictionary of named, typed parameter values supplied for that request.
Execution: carrying out of a GQL-request to compute a result and possibly change runtime state.
Operation: an identifiable action performed while carrying out a GQL-request.
Side effect: a change caused during execution of a GQL-request that can be detected by execution of another operation in the same or another GQL-request.
Evaluation: a computation of a result that is not permitted to cause side effects.
Procedure: a description of a computation on input arguments whose execution reports success or failure and may cause side effects.
Command: an operation not specified by a procedure written in GQL.
Statement: an operation executed as part of a procedure that may update runtime state and cause side effects.
Implementation-defined: possibly differing between GQL implementations, but specified by the implementer for each particular implementation.
Implementation-dependent: possibly differing between GQL implementations, but not required to be specified by the implementer.
Identifier: a value by which something is identified.
Name: an identifier used by people and by statement text to refer to something.
Variable: a name used inside a statement to hold a value or formal item found during evaluation.
Binding: an association between a variable name and a value.
Mapping: a partial assignment from variables to values.
Unbound variable: a variable for which the current mapping has no binding; this is distinct from a variable bound to the null value.
Compatible mappings: two mappings that agree on every variable they both bind.
Merge: the union of two compatible mappings.
Qualified name: a name made from several components, used when a short name would not be precise enough.
Object: something that the system can refer to, type, protect, or manipulate.
GQL-object: an object capable of being manipulated directly by execution of a GQL-request.
Global object identifier: an effectively immutable internal object identifier associated with a GQL-object that reifies its identity during execution of a GQL-request.
Globally identifiable object: a GQL-object associated with a global object identifier.
Syntactically resolved reference: a grammatical reference that statically identifies a GQL-object from the reference’s syntax and location.
Globally resolved reference: a reference that identifies its referent by a global object identifier.
Descriptor: a coded description of the metadata of a GQL-object.
Primary object: an independently definable GQL-object; every primary object is globally identifiable and has a descriptor.
Secondary object: a GQL-object necessarily defined as a component of another GQL-object.

5.2 Graphs

With the naming layer in place, we can introduce the structure that gives GQL its distinctive character. A graph is built from points and links, and the language treats those parts as objects that can be named, typed, selected, and changed. The first definitions below describe the bare connectivity structure: nodes, edges, endpoints, direction, loops, and multiple edges. The later definitions add labels and properties, which are the features that turn a simple connected structure into a property graph. This section also introduces the idea that a stored graph may either stand without a fixed structural contract or be checked against one. The graph vocabulary introduced here is:

Graph: a primary GQL-object comprising zero or more identifiable points and zero or more identifiable connections between them.
Node (vertex): an identifiable point in a graph that represents an entity.
Edge (relationship): an identifiable connection in a graph between two nodes.
Graph element: a node or an edge.
Source node: the node where an oriented link starts.
Destination node: the node where an oriented link ends.
Endpoint: one of the two nodes connected by an edge.
Directed edge: an edge whose endpoints have a source and a destination.
Undirected edge: an edge that may be traversed without choosing a fixed source-to-destination direction.
Directionality: the information saying whether an edge is directed or undirected.
Loop: an edge whose two endpoints are the same node.
Multiple edges: several edges between the same pair of nodes.
Multigraph: a graph that permits multiple distinct edges between the same pair of nodes.
Mixed graph: a graph that can contain both directed and undirected edges.
Label: a name attached to a node or edge to classify it.
Label set: the finite set of labels attached to one node or edge.
Edge label: a label contained in the label set of an edge; by itself it is only a classification mark and does not specify the edge’s complete structural contract.
Property key: the name used as the key part in an attribute key-value pair.
Property value: the value stored under such a key.
Property: a key-value pair attached to a node or edge.
Property map: mapping from property keys to property values for one node or edge.
Property set: the group of properties carried by one node or edge.
Property graph: a graph whose nodes and edges can have labels and properties.
GQL graph: the book’s structural property-graph model, comprising disjoint finite sets of identifiable nodes and edges together with their labels, properties, edge endpoints, and edge directionality.
Constraint: a rule that a graph must satisfy.
Constraint dictionary: a dictionary associated with a graph that maps zero or more unique names to constraints imposed directly on the graph’s elements.
Constraining graph type: an optional globally resolved reference recorded for a graph; its referent supplies the structural and integrity rules that the graph must satisfy.
Graph descriptor: optional constraining graph type together with the graph’s constraint dictionary.
Open graph: a graph that has no declared structural contract, so it is not checked against one fixed graph shape.
Closed graph: a graph that has a declared structural contract and must satisfy it.
Conformance: the fact that a value, element, graph, statement, or implementation satisfies the rules that apply to it.
Graph-entry conformance: the requirement that a graph satisfy its directly defined constraints and, when it has a constraining graph type, the structural and constraint requirements supplied by that referent.
Graph type violation: an error reported when a graph does not satisfy the structural requirements or constraints of its constraining graph type.

5.3 Context

Graphs and other GQL-objects are not interpreted in isolation. A statement is evaluated against a current store state, and names are resolved through a catalog, namespaces, and the current working defaults. The terms in this section describe that ambient setting. They explain where named objects live, how a short name is connected to a particular object, and how a session records the context and options that influence later statements. The order starts with the global store and catalog and ends with session-local choices, because session state is meaningful only after the available objects and naming rules are clear. The context terms used in this part are:

Catalog: a persistent, hierarchically organized collection of named GQL-objects.
Catalog object: a GQL-object defined, possibly transitively, in the GQL-catalog.
Primary catalog object: a GQL-object that is both a primary object and a catalog object.
GQL-schema: a persistent dictionary of primary catalog objects.
GQL-directory: a persistent dictionary of GQL-directories and GQL-schemas.
Store state: the current abstract state of the stored graphs, catalog, and other data that statements evaluate against.
Execution context: the runtime state created for an execution and updated as its operations proceed.
Catalog entry: one item in the catalog, such as a stored graph item or a type definition.
Graph entry: a catalog entry that stores a graph together with its optional constraining graph type and its own constraint dictionary.
Site: a place occupied by an instance of a specified data type.
Declared type: the unique data type common to every instance that may occupy a site, or to every result of a specified operation.
Assignment: the operation that initializes or replaces the value at a target site with a source value, applying the relevant type conversions when required.
Store assignment: assignment to a site using the assignment and type-conversion rules defined for stored values and references.
Namespace: a naming area that helps the same short name mean different things in different contexts without conflicts.
Name resolution: the process that decides which catalog object, variable, type, or local binding a name refers to.
Working schema reference: the schema reference used as the default parent for resolving relative catalog-object references.
Working graph site: a site identified by statement syntax and occupied by a reference to the graph used within its scope.
Working graph: the graph identified by the reference occupying the current working graph site.
Active context: the catalog, working schema reference, and working graph site used to interpret names and execute statements.
Session context: the context in which multiple GQL-requests of one session are executed consecutively.
Implementation configuration: the set of implementation-defined choices, such as supported limits and supported reference forms, made explicit in the semantics.
Session options: per-session settings, such as list-index behavior, that affect statement behavior.
List-behavior policy: the session setting that determines offset or ordinal list indexing, negative-index behavior, and out-of-range behavior for list element references; it does not affect list unwinding.
Session state: the session-local information, such as active context and options, that affects how statements are interpreted.

5.4 Values

The previous section located named objects in a store and explained how statements find them. We now need the vocabulary for the items that can be carried through evaluation as data. Some values are scalar, such as numbers or character strings; others are structured, such as lists and records. The section also introduces bags, because GQL keeps multiplicities in many intermediate results rather than silently collapsing duplicates. It ends with binding tables and references, which connect the value layer back to the GQL-objects introduced earlier. The value-level vocabulary is:

Base type: a set of data types that have shared characteristics.
Primary base type: the unique base type associated with a data type.
Data type descriptor: a descriptor that identifies a data type, including its declared primary base type name and associated metadata.
Value type: a data type comprising values.
GQL-object type: a data type whose elements are GQL-objects.
Material value: any value other than the null value.
Material data type: a data type that does not contain the null value.
Comparable values: two values that are capable of being compared.
Distinct values: comparable values that are distinguishable by GQL’s distinctness relation; two null values are not distinct, whereas a null value and a material value are distinct.
Nullable value type: a value type that admits the null value in addition to its ordinary material values.
Immaterial value type: the null type, which contains the null value, or the empty type, which contains no values.
Supported property value type: a non-empty value type that an implementation accepts as the type of a property value.
Scalar type: a type for a single simple value, such as an integer, string, Boolean value, date, time, or duration.
Numeric type: a scalar type for numbers, such as integer, decimal, float, or double.
Truth value: a value used by conditions: true, false, or unknown.
Boolean type: a scalar type for truth values.
Character string type: a scalar type for text.
Byte string type: a scalar type for binary data.
Temporal type: a scalar type for dates, times, date-times, or durations.
Vector type: a value type for vector-shaped values where the implementation supports them.
Collection type: a type for values that contain other values.
Bag (multiset): a collection that can contain the same item multiple times.
Multiplicity: the number of occurrences of an item in a bag.
Bag cardinality: the total number of occurrences in a bag, counting duplicates.
List value: an ordered finite collection of values.
List value type: a type describing list values, including the type of their elements, maximum size, and nullability.
Field: one named component of structured data.
Group list value type: a list type used when one variable contributes several values to one result field.
Record: a finite set of named fields, where each field has a value.
Record type: a type that states which fields a record has and what type each field may contain.
Closed record type: a record type specified with an explicit, possibly empty, set of field types.
Unit record type: the record type with no fields, used as a neutral empty row in some evaluations.
Binding table: a primary GQL-object comprising zero or more, possibly duplicate, records of one record type.
Binding table type: the GQL-object type of binding tables whose records have a specified record type.
Column: a field position shared across all records in a binding table.
Ordered binding table: a binding table whose ordering indication records an order of its record occurrences.
Unordered binding table: a binding table whose ordering indication does not determine an order of its record occurrences.
Preferred column name sequence: binding-table metadata that is either not set or is a permutation of the table’s column names.
Effective column name sequence: the preferred column name sequence when it is set, and otherwise the table’s column names in ascending order.
Binding table descriptor: the binding table type, an indication of whether the table is ordered or unordered, and a preferred column-name sequence that is either not set or is a permutation of the table’s column names.
Working record: the record in the current execution context whose fields provide scalar bindings during execution.
Working table: the binding table in the current execution context whose records drive statement execution.
Binding variable: an execution-context variable associated with an identified field of the working record or with the corresponding fields of records in the working table.
Dynamic union type: a type that can contain values from several component types, useful when different branches of a query can produce different value kinds.
Constructed value type: a value type built from other parts rather than supplied as a single primitive family.
Reference value: a value that describes a globally resolved reference to a GQL-object, such as a graph, node, edge, or binding table.
Reference value type: a type for reference values.
Graph reference value: a reference value that points to a graph object.
Node reference value: a reference value that points to a node.
Edge reference value: a reference value that points to an edge.

5.5 Expressions

With values and references in place, we can define the language forms for operating on them. An expression evaluates to a value or reports an error, while a predicate is the special case used as a condition. Because missing information is common in graph data, GQL uses three-valued logic, where a condition may be true, false, or unknown. The definitions below also introduce comparison and ordering behavior, runtime errors, and named functions. Function terminology appears here before the later routine section so that the built-in terms can be read without a forward dependency. The expression vocabulary is:

Expression: a piece of statement syntax that computes a value or returns an error.
Typing: the process of assigning and checking types for expressions, statements, properties, and results.
Static judgment: a formal type-checking statement made before runtime evaluation.
Evaluation judgment: a formal statement saying what value or error an expression evaluates to under a store state and the information available during evaluation.
Predicate: an expression used as a Boolean test.
Unknown truth value: the third truth value, represented by the null value, used when a Boolean result is unknown.
Three-valued logic: a logic with true, false, and unknown, used to ensure that the null value has a precise influence on predicates.
Connective: a Boolean operator such as conjunction, disjunction, or negation.
Short-circuiting: the possible non-evaluation of an inessential expression part, whose result cannot affect the enclosing result; if evaluating that part would raise an exception, whether it is evaluated is implementation-dependent.
Comparison: a test such as equality or sort precedence between two values.
Weak order: a total preorder on the values of a base type that determines their relative order for sorting, while allowing distinct values to be equivalent with respect to that order.
Totalization: the act of extending sort behavior so sorting has a defined policy for null values.
Null-intolerant predicate: a predicate that returns unknown when one of its relevant inputs is null.
Function: a named computation that returns a value.
Null-tolerant predicate: a predicate or function that defines a non-null result for at least some null inputs.
Strict function: a function that returns the null value if any of its arguments is the null value.
Runtime error: an error that occurs during evaluation, such as numeric overflow, access through an invalidated reference, or an invalid path representation.
Error token: the formal value used to carry information about an error result.

5.6 Schemas

Values, references, labels, and properties give us the ingredients for stored structures. Schemas describe which combinations of those ingredients are expected or allowed. In GQL, this includes the types of properties, the types of nodes and edges, and the graph types that collect such declarations into a larger contract. An open graph has no constraining graph type; a closed graph must contain only elements of the exact node and edge types specified by its constraining graph type and must satisfy that graph type’s constraints. The final terms in the section describe type relationships and the fact that a schema can change over time. The schema terms are:

Property type: a pair made of a property key and the type of values allowed for that key.
Node type: a type whose nodes have exactly its label set and property-type set.
Edge type: a type whose edges have exactly its labels and property types, its directionality, and its endpoint node types.
Element type: either a node type or an edge type.
Label test: a Boolean expression over the labels of a node or edge in a pattern; graph element type membership instead uses an exact label set.
Property signature: the finite mapping from declared property keys to their property types for an element type.
Static property signature: a property signature used during type checking before or independently of runtime values.
Node type descriptor: in the reduced book-level representation, the local type name, label set, and property signature of a node type; the fixed primary-base-type name and preferred-name metadata of the full ISO descriptor are elided.
Relationship type: the alternative standard term for an edge type; it is not an alternative term for an edge label.
Endpoint specification: the ordered source and destination node types of a directed edge type, or the endpoint node-type set of an undirected edge type.
Edge type descriptor: in the reduced book-level representation, the local type name, label set, property signature, directed or undirected kind, and endpoint specification of an edge type; the fixed primary-base-type name and preferred-name metadata of the full ISO descriptor are elided.
Structural consistency: the compatibility requirement for element types that imply one another, covering their element kind, label sets, property names, and compatible property value types.
Endpoint structural consistency: the corresponding structural compatibility requirement for the endpoint node types of edge types that imply one another.
Graph type: a primary GQL-object comprising a node type set, an edge type set, and a constraint set; when named and held by a schema, it is a catalog object.
Label vocabulary: the set of label names used in a given graph, graph type, or type-test context.
Key label set: a set of labels that is an element of a graph type and may be associated with an element type of that graph type.
Keyed element type: an element type associated with a key label set.
Graph type descriptor: the metadata describing a graph type, including its primary-base-type and preferred-name metadata, node- and edge-type descriptor sets, key-label-set dictionaries, and named constraint set dictionary; for a cataloged graph type it is a catalog object descriptor.
Subtype: a more specific type that can be used where a more general type is expected.
Subtyping: the relation that says one type is more specific than another while still satisfying the broader type’s expectations.
Inheritance: a possible future schema-language extension for reusing type requirements; it is not part of the graph-type membership rules modeled in this edition.
Widening: a safe type change that accepts all values accepted before, and possibly more.
Cast: a conversion from one type to another type.
Implicit cast: a cast or conversion the system applies automatically only where the GQL rules prescribe one; mere widening does not imply conversion.
Absent property: a property key that is not present on a node or edge.
Graph schema: a proposed future schema-language construct for describing allowed node types, edge types, graph types, properties, identity rules, and validation rules beyond the graph types modeled in this edition.
Schema state: the current schema extracted from the catalog at a point in execution.
Schema versioning: the modeling of schema changes as a sequence of schema states.
Schema evolution: the process by which schema-changing commands produce a new schema from an old one.

5.7 Paths

Once nodes and edges have identities, GQL can talk not only about individual elements but also about routes through them. A path is such a route, represented as an alternating sequence of node and edge references. At the value level, the vocabulary describes how paths are represented, inspected, and constructed. It also requires the referenced nodes and edges in a path element list to identify a valid route, independently of which graph is currently working. Finally, path modes specify whether nodes or edges may occur more than once along a path. The path vocabulary is:

Path in a graph: an alternating sequence of graph elements where each edge connects the adjacent nodes in the sequence.
Path value: a value representing an alternating sequence of node references and edge references.
Path value type: a constructed value type specified by PATH; its descriptor records the primary base type PATH VALUE DATA and whether the null value is included.
Path element list: the alternating list of nodes and edges stored inside a path value.
Path length: the number of edge steps in a path value.
Path accessor: an expression or operation that extracts information from a path value, such as its element list, nodes, edges, head, tail, or length.
Head of a path: the first node in a path.
Tail of a path: the last node in a path.
Malformed path: a path representation whose path element list contains null, does not alternate node and edge references, or has an edge that does not connect its adjacent nodes.
Path value construction: the creation of a material path value from a non-null graph-element-reference list that identifies a path.
Value-level path concatenation: the operation that joins two path values when the last node reference of the first and the first node reference of the second have the same node as their referent.
Path-value realizability: the property that a path value’s references identify a valid path, independently of the current working graph.
Walk: a path that may repeat nodes and edges.
Trail: a path that may repeat nodes but not edges.
Simple path: a path that does not repeat nodes, except that the first and last node may coincide in the allowed case.
Acyclic path: a path with no repeated nodes at all.
Path mode: the rule that selects whether a path is treated as a walk, trail, simple path, or acyclic path.
Mode filter: the test that rejects candidate paths that do not satisfy the chosen path mode.
Computed path: a path value produced during pattern evaluation rather than stored as a persistent graph object.
Stored path: a persistent path object outside the GQL core, distinct from a computed path value.

5.8 Path Search

The preceding section described what a path is. The next question is how a statement asks the system to find paths that satisfy a description. Path patterns provide that description, and prefixes refine the search by selecting a mode or by choosing only certain paths for each pair of endpoints. Because a graph can contain many possible paths between the same two nodes, the model distinguishes the generation of candidates from the selective stage that keeps only the desired ones. The final terms in this section name the bags and partitions used to express that selection precisely. The search vocabulary is:

Path pattern: a declarative description of admissible paths, optional binding for the whole path, and optional path search behavior.
Path variable: a variable that binds the whole path value found by a path pattern.
Path binding: a sequence, produced for one path pattern, whose entries associate variables or internal pattern markers with graph elements.
Anonymous path: a path found by a pattern without exposing the whole path value as a named binding.
Path prefix: the part of a path pattern that may specify a path mode and search behavior.
Search prefix: the part of a path pattern that chooses which paths to retain for each endpoint pair.
Path restrictor: a path-mode rule viewed as a filter over candidate paths.
Admissibility filter: a filter that decides which candidate paths are acceptable before they become results.
Selective path search prefix: a prefix that reduces candidate paths endpoint-by-endpoint, for example by choosing any path or the shortest paths.
Candidate set: the set of candidate path bindings produced before a selective path-search prefix reduces it.
Endpoint partition: the part of a candidate set containing path bindings with the same start and end nodes.
Length group: the part of an endpoint partition containing paths that all have the same length.

5.9 Path Expressions

Path search needs a compact way to describe which edge steps and intermediate elements are allowed. Regular path expressions fill that role. They are close in spirit to regular expressions over strings, but their units are traversal steps through a graph rather than characters in a word. The definitions below first name the expression forms and witnesses, then describe predicates and atoms used for single steps, and finally introduce the operators that combine, repeat, reverse, or guard expressions. This ordering prepares the reader for graph-pattern matching, where path expressions become part of larger patterns. Epsilon, inverse-step atoms, and general expression reversal below are auxiliary meta-language constructs used by the book; concrete GQL expresses traversal direction through its directional edge-pattern forms. The expression forms and supporting terms are:

Regular path expression: an expression that describes paths by combining steps, tests, choices, sequencing, and repetition.
Path expression: the concrete syntax form used to write a regular path expression inside a path pattern.
Path witness: a concrete path that proves a regular path expression matched.
Element pattern: a path-expression component that contributes a single node or edge step with optional tests and bindings.
Node/Edge predicate: a Boolean test over nodes or edges.
Step predicate: a test describing one allowed traversal step, including orientation, edge tests, and endpoint tests.
Step relation: the graph relation that says which source node, edge, and destination node triples satisfy a step predicate.
Label atom: a path-expression atom that matches an edge with a chosen label.
Predicate atom: a path-expression atom that matches a step by evaluating a Boolean test.
Inverse step: a path-expression step that follows an edge in the reverse direction.
Epsilon path expression: a path expression that consumes no edge and stays at the same node.
Concatenation: putting path expressions or paths one after another so the end of one connects to the start of the next.
Alternation: a path-expression choice between alternatives.
Set alternation: path-pattern alternation in which equivalent operand results are collapsed to one occurrence.
Multiset alternation: path-pattern alternation in which distinct operand derivations remain distinguishable and may contribute multiple equivalent result occurrences.
Quantifier: a path-expression suffix that controls optionality or repetition.
Restrictive path mode: trail, simple, or acyclic mode; using such a mode for every unbounded quantifier guarantees a finite path-pattern result.
Path primary: an element pattern, a parenthesized path-pattern expression, or a simplified path-pattern expression that forms the operand of path concatenation or quantification.
Bounded repetition: a quantifier that repeats a path expression between a lower and upper bound.
Unbounded repetition: a quantifier that allows arbitrarily many repetitions.
Reversal of expressions: the operation that reverses a regular path expression so it matches the same paths in the opposite direction.
Guarded expression: a path expression filtered by a local Boolean test over the path or its intermediate elements.
Well-formedness: the static rule that an expression, pattern, or statement must obey before it can be evaluated.
Finiteness: the property that evaluation produces a finite bag of results rather than an unbounded one.

5.10 Matching

Path expressions describe local movement, but GQL queries usually ask for larger shapes. A graph pattern combines element patterns and path patterns into a structure that can be matched against a graph. Matching produces assignments for variables, and those assignments must respect scoping rules: some variables are visible outside a component, while others remain local. This section therefore moves from the act of matching to exposure, reference degree, and the staged treatment of selective patterns. It ends with the distinction between matching that permits shared objects and matching that requires selected objects to remain distinct. The matching terms are:

Graph pattern: a pattern that describes graph elements and paths to be matched in a graph.
Pattern matching: the process of finding graph elements and paths that satisfy a graph pattern.
Node variable: a variable declared by a node pattern whose value represents one or more bound nodes.
Edge variable: a variable declared by an edge pattern whose value represents one or more bound edges.
Element variable: a node variable or an edge variable.
Subpath variable: a named pattern marker that is not bound to a value and cannot be referenced; it distinguishes operand derivations in path multiset alternation.
Graph pattern variable: a path variable, subpath variable, or element variable.
Multi-path binding: a tuple containing one path binding from the result of each path pattern in a graph pattern.
Match: a multi-path binding that satisfies all restrictions applicable to its graph pattern.
Reduced match: a match after auxiliary or anonymous parts have been removed or collapsed.
Temporary element variable: an element variable introduced by a syntactic transformation, scoped to its innermost path term and removed before reduced matches are formed.
Match mode: a graph-pattern restriction that applies to all path patterns simply contained in the graph pattern.
Repeatable elements match mode: the match mode that imposes no filter against the same graph edge occurring in different edge-binding positions.
Different edges match mode: the match mode that retains only multi-path bindings in which no graph edge occurs in two different edge-binding positions; matched nodes remain unrestricted.
KEEP clause: a graph-pattern clause whose path-pattern prefix is distributed to every simply contained path pattern before the clause itself is removed.
Matching semantics: the rules that explain how graph patterns produce matches and then binding tables.
Boundary variable: a variable visible at the composition boundary of a pattern component and therefore available when components are combined.
Interior variable: a variable local to a component of a path pattern.
Strict interior variable: an interior variable that is not also a boundary variable.
Variable exposure: the rule that says whether a variable is visible outside the component that introduced it.
Unconditional exposure: the case where every reduced match contains the variable, as a value-bearing binding or as a non-value subpath marker.
Conditional exposure: the case where some reduced matches may not contain the variable.
Not-exposed variable: a variable that cannot be used outside its local component.
Graph pattern YIELD clause: a clause that selects the exposed element and path variables that become output bindings, or specifies YIELD NO BINDINGS; a subpath variable cannot be yielded.
Graph-pattern binding table: a syntactic construct consisting of a graph pattern optionally followed by a YIELD clause; its semantic operator transforms an incoming binding table into a binding table over the exposed and yielded binding variables.
Singleton variable: a variable that contributes at most one value per reduced match.
Group variable: a variable that can contribute a group of values rather than one value.
Effectively bounded group: a group variable whose maximum number of values is bounded by the syntax.
Non-local reference: a reference from outside the local component where a variable was introduced.
Effectively unbounded group: a group variable whose number of values can grow without a syntactic upper bound; non-local references nevertheless remain restricted to singleton degree.
Reference degree: the classification of a referenceable binding variable as singleton, effectively bounded group, or effectively unbounded group; exposure is classified separately as unconditional, conditional, or not-exposed.
Path-variable degree: the rule that a declared path variable is a singleton inside its declaring path pattern, even if a later optional operation produces a null output value.
Propagation rule: a rule that explains how variable exposure and reference degree change through concatenation, alternation, optionality, and repetition.
Questioned path-pattern primary: a path primary followed by ?; its zero-occurrence branch makes exposed singleton-variable bindings conditional, while group-variable exposure is preserved.
Selective path pattern: a path pattern using a selective path search prefix.
Local generation: the first matching stage, where candidate path bindings are produced with local filters but before selective search.
Selective stage: the matching stage where a selective path search prefix keeps only selected paths inside each endpoint partition.
Global filtering: the stage where non-local conditions filter the combined bindings.
Reduction: the stage that removes temporary symbols and anonymous structure from raw matches.
Homomorphic matching: an informative graph-theoretic analogy in which different pattern variables may map to the same graph object if the structure still fits; it is not an additional GQL match mode.
Isomorphic matching: an informative graph-theoretic analogy in which selected pattern variables map to distinct graph objects; it is not an additional GQL match mode.
Injectivity guard: an explicit test that prevents selected variables from being mapped to the same graph object.
Explicit guard: a test added by the user or semantics to rule out unwanted matches.

5.11 Algebra

Matching produces bindings, but a query still has to combine, filter, extend, and project them. The algebra in this section treats binding tables as the central intermediate objects. Because GQL follows bag-style behavior in many places, multiplicity is introduced before the table operators. The first terms explain how duplicates are counted or collapsed; the middle terms describe table headers and compatibility; the last terms give the main row-transforming operations, including joins and optional matching. This prepares the ground for full query blocks, which assemble these operators into complete statements. The algebraic terms are:

Result multiplicity: the number of times the same binding appears because several matches or derivations lead to it.
Bag semantics: semantics where duplicates are kept and counted.
Set semantics: semantics where duplicate results are collapsed to one occurrence.
Bag union: an operation that combines bags by adding multiplicities.
Bag difference: an operation that subtracts right-side multiplicities from left-side multiplicities without going below zero.
Bag intersection: an operation that keeps the minimum multiplicity found on both sides.
Setification: the operation that collapses every positive multiplicity to one.
Unit table: the binding table with one empty record, used as a neutral starting input.
Empty binding table: a binding table of cardinality zero, distinct from the unit binding table.
Header: the set of column names and their value types for a binding table.
Column name-equal: a property that several binding tables have the same column names.
Column-combinable: a property that corresponding columns have value types that can be combined safely.
Common type: a combined type to which operands are coerced before union, difference, or intersection behavior is applied.
Selection: an operator that keeps only rows whose test evaluates to true.
Projection: an operator that keeps or computes selected output fields and discards the rest.
Extend: an operator that adds new computed fields to each row.
Join: an operator that combines rows from two binding tables when their shared fields are compatible.
Natural join: a join based on equal values in shared field names.
Natural joinability: the relation between two records whose common fields have equal values under GQL value equality, including two common fields that both contain the null value.
Name-compatible join: a natural join that relies on shared column names agreeing.
Theta-join: a join followed by an explicit Boolean guard.
Guarded join: a join that keeps only row pairs passing an additional test.
Left outer join: a join that keeps left-side rows even when the right side has no match, filling right-side fields with null values.
Optional match: matching that preserves input rows when the optional pattern finds no extension.
Correlated optional expansion: per-input-record optional evaluation that returns its compatible extensions when any exist, and otherwise returns the input record padded with null values for newly introduced columns.
Padding: the insertion of null values for right-side fields when an outer join finds no right-side match.
List unnesting: the FOR operation that emits one extended record for each element occurrence of an input list.
Semi-join: a join-like operation that keeps left rows having at least one matching right row.
Anti-join: a join-like operation that keeps left rows having no matching right row.

5.12 Queries

The previous section described the operators available for transforming binding tables. A query block arranges those operators into a unit with its own patterns, filters, and result formation. Subqueries then allow one query to be evaluated inside another, either independently or with access to the current outer row. The environment terms explain what information is available during such evaluation and how local names avoid accidental collisions with outer names. The section ends with composition rules for whole queries, where query parts are combined and duplicate-control choices determine whether repeated rows remain visible. The query-level terms are:

Query block: a unit of query evaluation containing graph patterns, algebraic operators, and a final projection.
Subquery: a query evaluated inside another query.
Uncorrelated subquery: a subquery whose result does not depend on the current outer row.
Correlated subquery: a subquery that uses values from the current outer row.
Relational subquery: a subquery used as a bag of rows.
Scalar subquery: a VALUE query whose nested query has one result field and is statically constrained, by LIMIT 1 or by summarizing all input records into one result without GROUP BY, to produce at most one record; an empty result yields null and a singleton result yields its sole value.
Row-producing subquery: a subquery that contributes rows to the surrounding algebra.
Environment: the information available during evaluation, such as the current graph, outer bindings, and callable registries.
Static environment: the compile-time or checking-time mapping from names to their meanings.
Dynamic environment: the runtime information, especially the current outer row, used during correlated evaluation.
Row environment: the mapping from field names in the current row to their values.
Global environment: the mapping for global names such as catalog objects, named graphs, types, and callable routines.
Evaluation environment: the pair of global and row environments used to evaluate expressions.
Variable hygiene: rules that prevent accidental capture or collision of local and outer variable names.
Shadowing: a situation where a local name would hide an outer name.
Pipelining: the passing of one binding table into the next statement or query block.
Primitive query statement: a basic query step such as pattern matching, filtering, or result formation.
Linear query statement: a sequence of query steps evaluated left-to-right over a working table.
Whole-query denotation: the meaning of a complete query obtained by composing all its blocks and operators.
Composite query: a query built by combining operands with set-like operators or fallback behavior.
Query part: one operand inside a composite query.
Set operator: an operator that combines compatible query results using union, difference, or intersection behavior.
Left-associative composition: the rule that a chain of operators is evaluated from the left unless parentheses say otherwise.
Fallback query conjunction: the OTHERWISE query conjunction, which selects the first non-empty operand result in a left-associative chain, or the empty combined-type result if every operand result is empty; it is not a set operator and does not provide short-circuit evaluation, because the query-part results are obtained before that selection.
Duplicate control: the rule deciding whether duplicates are preserved or collapsed.
Set quantifier: a duplicate-control rule that decides whether duplicates are preserved or removed.
Deduplication: the removal of duplicate rows by keeping one occurrence.

5.13 Result Shaping

Once a query has produced rows, the language still has to shape what the user actually sees. Ordering adds a presentation order without changing the underlying bag of rows. Exact limiting and offsetting select a contiguous part of that ordered sequence, while approximate limiting may select an implementation-dependent ordered subset, which is useful when a result is too large to return at once. Grouping and aggregation move in a different direction: they partition rows and summarize many input values into fewer output values. The final term ties these operations to the result-forming part of a query. The result-shaping terms are:

Ordering: the act of adding a row order to a binding table result.
Ordering metadata: metadata recording the emission order of rows without changing the underlying bag.
Sort key: an expression used to decide row order.
Sort direction: the choice between ascending and descending order.
Nulls policy: the rule deciding where null values appear in sorted results.
Sort specification: a sort key together with explicit or implicit choices for sort direction and null ordering.
Sort specification list: a non-empty list of sort specifications used for ordering.
Collation: rules for comparing character strings during ordering.
Peer ordering: the implementation-dependent ordering among records that are not distinct with respect to every sort specification, including its null-ordering policy.
Slicing: using OFFSET and LIMIT to retain selected records from an ordered row sequence; the retained records form a contiguous suffix or prefix only where the applicable exact operation requires it.
Exact LIMIT: limiting that retains the first requested number of records of the ordered input.
Approximate LIMIT: limiting that retains at most the requested number of records chosen by the implementation and need not retain a prefix, while preserving the selected records’ relative input order.
Pagination: using ordering and slicing to return only a page or selected portion of a larger result.
Grouping: partitioning rows so each partition can be summarized.
Grouping key: an expression whose value decides which group a row belongs to.
Grouping function: the function that maps rows to grouping keys.
Grouping set: one selected set of grouping keys used to form groups.
Aggregate function: a function that summarizes many input rows or values into one output value.
Aggregator: the semantic object that defines how an aggregate function consumes inputs and produces a result.
Global group: the single group used when aggregation is performed without explicit grouping keys.
Post-aggregation filtering: filtering that happens after grouped summaries have been computed.
Primitive result statement: the part of a query that forms the final visible result, including return items, grouping, distinctness, ordering, and pagination.

5.14 Updates

Once query results are available, GQL moves beyond retrieving graph data and begins modifying the graph itself. An update in GQL still depends on the earlier machinery: it may first use patterns and expressions to find the elements that should change, and only then produce write operations. For that reason, the section begins with data-modification statements and the graph chosen for modification. It then introduces insert and delete forms, followed by the abstract update pipeline that grounds templates into concrete operations. The final terms describe how writes are staged, combined, rejected when they conflict, and eventually represented as primitive mutations. The update vocabulary is:

Data-modification statement: a statement that inserts, deletes, or updates graph data.
Data-modification primitive: a basic write step such as insert, set, remove, delete, or a data-modifying routine call.
Linear data-modification statement: a pipeline that combines graph selection, query steps, and data-modification primitives.
Graph-selection header: an optional front part of a data-modification statement that chooses the graph to modify.
Graph expression: an expression that evaluates to a graph reference.
Read-then-update composition: an update pattern where a query first finds bindings and an update then uses those bindings to change data.
Insert graph pattern: the insert-specific pattern that describes the nodes and edges to create.
Insert path pattern: a path-shaped insert pattern that may create nodes, edges, labels, properties, and bindings together.
Insert element pattern: a node or edge pattern inside an insert graph pattern.
Bound insert element pattern: an insert element pattern that refers to an element already bound instead of creating a new one.
System-generated identifier: an identifier supplied by the system when the user omits a variable name, not retained as a user-visible output column.
Identifier allocation: the creation of fresh global object identifiers for new nodes, edges, or copies.
Incident edge: an edge connected to a node as either source or destination.
Plain delete: deleting an edge directly, or deleting a node only when every edge incident on that node is also designated for deletion by the same statement.
Dependent-object error: an error raised when an operation cannot proceed because another object still depends on the target.
Endpoint reattachment: changing an edge’s endpoints, modeled as delete plus recreate rather than an in-place update.
Update pipeline: a read-then-update form where matched bindings are used to produce updates.
Read stability: the rule that the read part of an update is evaluated against a stable view before writes are applied.
Update context: the graph, bindings, stable read view, and options needed to interpret an update.
Target reference: the concrete node or edge selected as the target of an update.
Update atom: one small abstract update action, such as setting one property or adding one label.
Update template: an update atom pattern before variables and expressions have been evaluated for a particular binding.
Ground operation: an update operation whose target and value have already been evaluated.
Grounding: the step that turns an update template into concrete ground operations for one binding.
Write set: the collection of ground operations produced by an update before they are applied.
Delta: the staged change that will transform one graph or store state into another if validation succeeds.
Coalescing: combining several writes into one canonical set of changes when they are compatible.
Write conflict: a situation where multiple writes cannot be combined without ambiguity or rule violation.
Multiple property assignments: the case where one statement produces two or more assignments to the same property of the same element, regardless of whether the values are equal; the implementation either raises 22G0M or chooses one assignment, according to its documented choice.
Idempotent label addition: adding a label in a way where repeated additions have the same final result as one addition.
Primitive mutation: one elementary graph change, such as inserting a node, deleting an edge, setting a property, or removing a label.
Set property: a primitive mutation that assigns a value to a property key.
Delete property: a primitive mutation that removes a property key from an element.
Add label: a primitive mutation that attaches a label to a node or edge.
Remove label: a primitive mutation that removes a label from a node or edge.

5.15 Constraints

Updates can create useful new facts, but they can also break assumptions that the schema is meant to protect. Constraints express those assumptions as rules that a graph must satisfy. The first terms describe the general shape of a constraint: what population it checks, how that population is selected, and what requirement must hold. The middle of the section focuses on keys and uniqueness, because those rules are central to identifying elements. The final terms describe how constraints are stored, induced from catalog declarations, checked after staged changes, and reported when validation fails. The constraint terms are:

Integrity constraint: a constraint used to prevent invalid graph states.
Registered subject: a graph whose permitted characteristics or contents are constrained by a particular integrity constraint.
Requirement: the rule a constraint imposes on every in-scope binding.
Constraint specification: the formal description of what population is checked and what requirement it must satisfy.
Constraint body: the part of a constraint specification that determines its scope and requirement without its constraint name.
Constraint normal form: an implementation-defined, deterministic, idempotent representation of a constraint body; a specification normal form additionally retains the constraint name.
Body-equivalence: the relation between constraint bodies whose deterministic normal forms are equal.
Constraint graph pattern: a graph pattern used to select the elements that a constraint checks.
Constraint scope: the set of graph elements selected for checking by a constraint.
Scope predicate: a predicate that says whether a graph element is in the scope of a constraint or type rule.
Key value component: the main element variable, an endpoint variable of an edge scope, or a property reference rooted at one of those variables and selected as one component for identifying constrained elements.
Key value component specification: the ordered sequence of zero or more key value components used to identify constrained elements.
Constraint descriptor: a descriptor containing a constraint’s name, registered subjects, deterministic scope, and key value component specification.
Key: a sequence of zero or more key value components that identifies constrained elements.
Key specification: a deterministic constraint graph pattern together with its key value component specification.
Key tuple: the tuple obtained by evaluating the key value component specification for one in-scope binding, used to compare in-scope elements.
Non-distinctness: the GQL value relation in which two null values are non-distinct.
Null-containment: the recursive property of a value or composite value containing the null value.
Key constraint: a constraint requiring in-scope key values to be recursively not null-containing and requiring elements with non-distinct key tuples to be identical.
Uniqueness constraint: a constraint requiring in-scope elements not to share non-distinct key values.
Graph-type conformance: the requirement that every element of a closed graph is of an element type in its constraining graph type and that the graph satisfies that type’s constraints.
Direct graph constraint set: the constraints defined directly in a graph’s own constraint dictionary.
Active constraint set: the constraints registered for the active graph, considered collectively, from its own dictionary and its optional constraining graph type.
Semantic constraint clause: one formal clause that a graph must satisfy.
Satisfaction relation: the relation saying that a graph satisfies a constraint or set of constraints.
Validation predicate: the check that a graph after applying a delta still satisfies all relevant constraints.
Dynamic constraint validation: the validation, by a data-modifying statement’s General Rules, of the graph’s direct constraints after a provisional graph has been produced.
Constraint enforcement: the separate checks of direct graph constraints and graph-type conformance that must succeed before a data-modifying statement succeeds.
Integrity constraint violation: a reported failure raised when graph data breaks an integrity constraint.

5.16 Effects

The update and constraint sections describe what can happen at runtime. An effect system gives a static approximation of that behavior before execution begins. It records what a statement may write, combines such information across larger statements, and checks whether different writes may interfere. This is necessarily conservative: it may prevent an optimizer reordering whose equivalence has not otherwise been established, but it does not introduce an additional rejection or warning rule for GQL programs. The terminology below therefore separates primitive effects, algebraic combination, soundness, and rules that prevent unsafe writes through missing bindings. The effect terms are:

Effect: an abstract description of what a statement may change.
Effect system: the book’s static rules that approximate modeled graph-data writes of query and data-modifying statements.
Primitive effect: the effect associated with one primitive update action.
Effect algebra: the algebra used to combine primitive effects and compare them.
Statement effect typing: the static judgment that assigns an effect to a query or data-modifying statement in the book’s limited model.
Write-purity: the property of having an empty static write effect; it does not by itself imply independence from evaluation order or context, or result determinism.
Effect soundness: the guarantee that static effects safely over-approximate runtime changes.
Static conflict approximation: a conservative static check for possible conflicts between effects.
Optimizer ordering restriction: a meta-level restriction that prevents an unproved reordering of potentially conflicting writes.
No unbound writers: the rule that an update must not write through variables that may be unbound.
Constraint-preserving execution: a data-modifying execution whose post-state passes mandatory direct-constraint validation and the separate graph-type-conformance check before the statement succeeds.

5.17 Routines

Expressions introduced functions that return values. GQL also has procedures that can be invoked by statements and may expose outputs; named procedures are primary catalog objects, whereas functions are not modeled as such here. The order follows the way such a routine is understood: first the procedure kinds, then their declared interface, then the catalog declaration and body, and finally invocation and resolution. This prepares the transition to transactions, where statements and calls are executed inside larger units of work. The routine vocabulary is:

Query procedure: a procedure whose execution does not cause side effects.
Data-modifying procedure: a procedure whose execution may cause data-modifying side effects only.
Catalog-modifying procedure: a procedure whose execution may cause catalog-modifying side effects, either alone or together with data-modifying side effects.
GQL procedure: a procedure written in GQL.
External procedure: a procedure provided through an implementation-defined mechanism.
Inline GQL procedure: a GQL procedure specified directly at its invocation site rather than as a named catalog object.
Signature: the declared input and output types of a function or procedure.
Declaration: a catalog entry that introduces a named procedure or primary object.
Parameter: an input name and type expected by a function or procedure.
Named procedure descriptor: the mandatory and optional parameters, result type, and side-effect kind of a named external procedure.
Procedure body: the variable definitions and statement block that define an inline GQL procedure.
Procedure invocation: the act of executing a procedure call.
Reference resolution: the process that follows an explicit catalog parent or the implicit current-schema parent and verifies the referenced object’s kind.

5.18 Transactions

Statements and routine calls do not always stand alone. A transaction groups work so that a sequence of reads and writes can be completed together or abandoned together. This section starts with commands and characteristics that establish the transaction’s mode, then describes successful and unsuccessful completion. It then introduces visibility and the standard’s serializable execution model, followed by snapshot and conflict-policy terminology used only for explicitly identified implementation extensions. The final terms distinguish the core isolation guarantee from those extensions. The transaction terms are:

Transaction: a bounded unit of work whose changes complete together or are rolled back together.
Transaction model: the rules for starting, sequencing, committing, rolling back, and isolating transactions.
Transaction control command: a command that starts, commits, or rolls back a transaction.
Transaction characteristic: an option such as access mode or read behavior that affects a transaction.
Transaction access mode: the setting that says whether a transaction is read-only or read-write.
Read-only transaction: a transaction mode that rejects catalog-modifying and data-modifying statements.
Read-write transaction: a transaction mode that permits writes if all other checks also pass.
Savepoint: a point inside a transaction that may support undoing part of the work.
Commit: a successful transaction completion that makes all staged changes part of the committed state.
Rollback: a successful cancellation of the current transaction’s changes, leaving none of them committed.
Atomicity: the recovery property ensuring that a successful commit has all of the transaction’s effects, while a successfully processed rollback leaves none of them committed.
Abort: a failed transaction outcome accompanied by a rollback attempt; if transaction termination cannot be processed successfully, the catalog and data state is indeterminate.
Statement sequencing: the rule that statements inside a transaction run in program order.
Visibility: the rule that decides which changes a statement or transaction can observe.
Provisional change: a transaction change made before commit and therefore not yet fully visible as committed state.
Snapshot: a fixed view of the graph or store used by a transaction or statement in an implementation extension outside the serializable core model.
Transaction snapshot: a snapshot fixed for a whole transaction by such an implementation extension.
Statement snapshot: a snapshot fixed at a statement boundary by such an implementation extension.
Isolation level: an implementation setting outside the serializable core model that controls concurrent visibility and anomalies.
Serializability: the guarantee that concurrent committed transactions have the same observable effect as some serial order.
Write-write conflict: a conflict caused by concurrent transactions trying to write overlapping entities or fields.
First-committer-wins: a snapshot-isolation policy outside the serializable core model where the first committing transaction succeeds and a conflicting later commit fails.

5.19 Authorization

Transactions determine when changes become visible, but they do not decide who is allowed to see or make those changes. Authorization supplies that control layer. The section begins with the actors that participate in access control, then introduces roles, privileges, and grants. The middle terms explain how direct and role-based grants are combined into effective privileges and how statements produce obligations that must be checked. The final terms describe object availability and authorization-identifier-indexed semantics, which connect authorization back to query results and update execution. The authorization vocabulary is:

Security: the broad concern of controlling who can see or change data and catalog objects.
Authorization: the rules that determine who may reference objects and perform operations.
Access control: authorization applied to actors, objects, and operations.
Principal: a user or other actor identified for authorization purposes.
Role: a named grouping used to organize permissions.
Privilege: permission to perform a kind of operation on an object.
Authorization identifier: an identifier that represents a principal together with the privileges under which associated requests execute; one principal may have more than one such identifier.
Privilege kind: the category of permission, such as read, write, execute, or administer, as chosen by an implementation.
Privilege level: the strength of a privilege within the implementation’s privilege ordering.
Privilege poset: the partial order saying when one privilege is strong enough to imply another.
Authorization target: a complete GQL-object to which a privilege applies in the core model, such as a graph, graph type, binding table, or named procedure.
Grant: a fact that gives a privilege on an authorization target to an authorization identifier or role.
Grantor: the authorization identifier that gives a privilege.
Grantee: the authorization identifier or role receiving a privilege.
Authorization state: the set of role and grant facts governing authorization.
Effective privilege: the combined privilege an authorization identifier has on an authorization target after considering direct grants and the grants of its roles.
Privilege obligation: a required privilege produced by type checking or statement analysis.
Obligation set: the set of privilege obligations that must be satisfied before a statement may run.
Obligation judgment: a typing-style judgment that returns both a type and the privileges required by a statement.
Authorization check: the check, before statement evaluation begins, that the effective privileges of the session authorization identifier dominate every privilege obligation of the statement.
Object availability: the implementation-defined relation determining which complete authorization targets an execution context may reference or resolve; availability of a graph does not mean availability of an induced subgraph.
Authorization-identifier-indexed semantics: query semantics relative to the session authorization identifier: ordinary semantics is used only when every referenced object is available and every obligation is satisfied; otherwise exception 42000 is raised.
Write check: an authorization or transaction-mode check performed before a modifying operation takes effect.

5.20 Diagnostics

The last section describes how execution outcomes are reported. Every preceding topic can contribute to such an outcome: expressions may fail, updates may violate constraints, transactions may conflict, and authorization checks may reject an operation. Diagnostics therefore provide a common vocabulary for successful outcomes, warnings, no-data cases, informational conditions, and failures. The section begins with status codes and conditions, then moves to status objects and the result forms carried by execution outcomes. It ends with broad error classes and the rules for choosing a reported status, closing the chapter with the mechanism by which the language communicates success or failure to the user. The diagnostic terms are:

Diagnostics: structured reporting of success, warnings, no-data outcomes, informational conditions, and failures.
Status code: a code used by the diagnostic model to identify an execution situation.
Status domain: the set of all status codes used by the diagnostic model.
Condition: a situation reported by a status code.
Status class: the first part of a status code, identifying a broad family of conditions.
Status subclass: the more specific part of a status code.
Completion condition: a condition indicating normal request completion, a non-fatal issue, or a no-data outcome.
Exception condition: a reported failure condition rather than normal completion.
Transaction rollback condition: a reported failure condition used when a transaction cannot complete successfully.
Successful completion: a completion condition indicating that the request completed without issues.
Warning: a completion condition that reports some issue, but is non-fatal.
No-data condition: a completion condition saying that no data was produced where that matters.
Informational condition: a secondary condition used for extra status information rather than the primary outcome.
Diagnostic record: structured diagnostic information associated with a reported condition.
GQL-status object: an object representing a condition and its diagnostic information, comprising a GQLSTATUS, a status description, a diagnostic-information record when supported, and an optional nested GQL-status object.
Regular result: a value or binding table produced by successful execution of an operation.
Omitted result: a result indicating successful execution of an operation that produced no value.
Execution outcome: the execution-context component comprising a primary GQL-status object, a possibly empty list of additional GQL-status objects, and an optional regular or omitted result.
Successful outcome: an execution outcome that records a result and no exception condition.
Failed outcome: an execution outcome that records an exception condition and no result.
Primary status code: the GQLSTATUS field of the primary GQL-status object attached to an execution outcome.
Additional status code: the GQLSTATUS field of an additional GQL-status object carrying secondary diagnostic information.
Result sum type: the book’s meta-level result domain that distinguishes successful results from failures.
Short-circuit failure propagation: the rule that the first failure in a compound statement stops later evaluation and is propagated upward.
Standard-defined code: a status code assigned by the standard.
Implementation-defined code: a status code or subclass chosen by an implementation within allowed ranges.
Status precedence: the rules that decide which condition becomes primary when several conditions could be reported.
Error class: a broad category of errors, such as static, dynamic, concurrency, constraint, or resource errors.
Static error: an error detected before execution, such as an unbound variable or schema mismatch.
Dynamic error: an error detected during execution, such as numeric overflow, access through an invalidated reference, or a malformed path.
Concurrency error: an error caused by isolation, conflicts, or concurrent execution.
Constraint error: an error caused by violating an integrity or graph-type constraint.
Resource error: a standard-defined or implementation-defined error caused by a resource limitation, such as timeout or memory exhaustion.
Diagnostic choice: when several raised exception conditions have the same highest priority, the implementation-dependent choice of which one becomes the status of the current request outcome.

Chapter 5 — Takeaways.

Purpose: Established the shared vocabulary used by the semantic chapters before the formal development begins.
Introduced: Core terms for foundations, graphs, context, values, expressions, schemas, paths, patterns, query composition, updates, constraints, transactions, authorization, and diagnostics.
Key distinctions: Conceptual definitions versus full formal treatment; values versus GQL-objects; stored structures versus computed results; static checks versus runtime outcomes.
Consequences: Reduced forward references in later chapters and gave readers a compact map of how the model’s components fit together.
Bridge: Prepared the transition from the introductory example to the abstract data model and pattern semantics.