Chapter 15Types and Schemas

This chapter introduces the static typing layer of GQL, which constrains the shape of property graphs beyond their raw data model. We describe how property types, node and edge types, and graph types are specified, and how they interact with keys, label tests, and integrity constraints to define admissible graphs.

15.1 Catalog and Name Universes

Universes of names. Let $C a t a l o g$ be the abstract carrier of well-formed hierarchical GQL-catalogs, with $C, C^{'} \in C a t a l o g$ . Its internal directory/schema structure is defined in Chapter 17. Let $𝕂$ be the (implementation-defined) universe of property keys (identifiers admissible as property names). Let $ℕ_{N}$ , $ℕ_{E}$ , $ℕ_{G}$ be name universes for node types, edge types, and graph types, respectively, and let $ℕ_{g r a p h}$ be the universe of graph entry names. These are schema-local name sets used inside the single hierarchical catalog defined in Chapter 17; they are not additional top-level catalogs. Node and edge types are secondary objects contained in graph types.

15.2 Property Types

Type universe. We reuse the value and type universes $𝕍$ and $𝕋$ fixed in Section 6.1. Let $𝕋_{p r o p} \subseteq 𝕋$ be the implementation’s supported property value types. We distinguish the selected scalar and collection fragments $𝕋_{s c a l}$ and $𝕋_{c o l l}$ of this set, with

𝕋_{s c a l} \cup 𝕋_{c o l l} \subseteq 𝕋_{p r o p} .

For $τ \in 𝕋_{p r o p}$ , we write $⟦ τ ⟧ \subseteq 𝕍$ for its values. Null belongs to this set exactly when $τ$ is nullable.

Scalar types. The selected scalar fragment used below contains (feature-set dependent precisions omitted for brevity)

\begin{aligned} 𝕋_{n u m} & = {I N T E G E R, B I G I N T, D E C I M A L (p, s), F L O A T, D O U B L E}, \\ 𝕋_{b o o l} & = {B O O L E A N}, \\ 𝕋_{t e x t} & = {S T R I N G}, \\ 𝕋_{b i n} & = {B Y T E S}, \\ 𝕋_{t e m p o r a l} & = {D A T E, Z O N E D_T I M E, L O C A L_T I M E, \\ Z O N E D_D A T E T I M E, L O C A L_D A T E T I M E, \\ D U R A T I O N (Y E A R T O M O N T H), D U R A T I O N (D A Y T O S E C O N D)}, \end{aligned}

$𝕋_{s c a l}$ is the union of these sets. (Additional scalar value types from the GQL standard can be added without changing the subsequent development.)

Collection types. One collection fragment used below consists of homogeneous list types:

L I S T ⟨ τ ⟩ \in 𝕋_{c o l l} (finite sequences over ⟦ τ ⟧) .

Other supported property value types, including applicable vector, record, and dynamic union types, remain in $𝕋_{p r o p}$ as governed by the implementation’s conformance claim.

The denotation function $⟦ \cdot ⟧ : 𝕋 \to P (𝕍)$ assigns to each type the set of admissible values.

Nullability and absence. A property type is a pair consisting of a property name and one supported property value type. Consequently, a declaration $k : τ$ admits exactly values in $⟦ τ ⟧$ : it admits a list only when $τ$ is a list type, and it admits $n u l l$ only when $τ$ is nullable. An absent property is not a value and is represented only by the totalized lookup $\hat{ρ}$ from Section 6.2.

Widening preorder and casts. Define the widening preorder $⊒$ on value types by

τ_{1} ⊒ τ_{0} \Leftrightarrow ⟦ τ_{0} ⟧ \subseteq ⟦ τ_{1} ⟧ .

A cast from $τ_{0}$ to $τ_{1}$ is in general partial, $c : ⟦ τ_{0} ⟧ ⇀ ⟦ τ_{1} ⟧$ ; failure is reported according to the cast and store-assignment rules. An implicit assignment conversion is admissible only where the GQL assignment rules establish it; widening alone does not invent a conversion. For every successful application,

v \in d o m (c) \Rightarrow c (v) \in ⟦ τ_{1} ⟧ .

Static property signatures. For a type descriptor $T$ (node or edge), its property signature is a finite map

{p t y p e}_{T} : 𝕂 ⇀ 𝕋_{p r o p}

assigning a supported property value type to each declared property key; the run-time admissible values are given directly by the denotation of that type.

Key label sets (KLS). A key label set is the possibly empty label set, subject to supported cardinality limits, associated with a keyed node or edge type in a graph type. The graph type’s node or edge key-label-set dictionary uses it to identify the corresponding keyed element type. A key label set is not by itself an integrity constraint.

15.3 Node and Edge Types

Label and property sets. Each GQL node or edge type has a fixed label set and a fixed property-type set. We represent the latter as the finite map ${p t y p e}_{T}$ above. Thus type membership uses equality of label sets and property-name sets, not an open label test or a property-closedness switch.

Reduced node-type descriptor representation. In the reduced book-level representation used here, a node type descriptor is represented by the tuple

N D e s c = ⟨ N, L_{N}, {p t y p e}_{N} ⟩,

where $N$ is the local type name, $L_{N} \subseteq 𝕃$ is its node type label set, and ${p t y p e}_{N}$ is its property signature. Key label sets and named constraints belong to the containing graph type descriptor rather than to this node type descriptor. The fixed primary-base-type name and preferred-name metadata of the full ISO descriptor are elided from this representation.

A node $v \in V$ conforms to $N$ (notation: $v : : N$ ) iff

\begin{aligned} (labels) & λ_{V} (v) = L_{N}; \\ (property names) & d o m (ρ_{V} (v)) = d o m ({p t y p e}_{N}); \\ (typing) & \forall k \in d o m ({p t y p e}_{N}) . ρ_{V} (v) (k) \in ⟦ {p t y p e}_{N} (k) ⟧ . \end{aligned}

For example, the Book node type declared in Section 4.2 is represented by

\begin{aligned} {p t y p e}_{Book} = { & isbn \mapsto S T R I N G N O T N U L L, title \mapsto S T R I N G, \\ author \mapsto S T R I N G}, \end{aligned}

{N D e s c}_{Book} = ⟨ Book, {Book}, {p t y p e}_{Book} ⟩ .

The node $b_{1}$ representing Graph DB 101 in Figure 4.1 conforms to Book: its label set is ${Book}$ , its property names are exactly ${isbn, title, author}$ , and each corresponding value belongs to the denotation of its declared type.

Reduced edge-type descriptor representation. In the reduced book-level representation used here, an edge type descriptor is represented by the tuple

E T y p e D e s c = ⟨ E T, L_{E}, {k i n d}_{E}, {e n d S p e c}_{E}, {p t y p e}_{E} ⟩,

where $E T$ is the local type name; $L_{E}$ is its edge type label set; ${k i n d}_{E} \in {d i r e c t e d, u n d i r e c t e d}$ is its directionality; ${e n d S p e c}_{E}$ is an ordered source–destination pair of node types in the directed case and a set of one or two endpoint node types in the undirected case; and ${p t y p e}_{E}$ is its property signature. The fixed primary-base-type name and preferred-name metadata of the full ISO descriptor are elided from this representation.

An edge $e \in E$ with endpoints $(s r c (e), d s t (e))$ conforms to $E T$ (notation: $e : : E T$ ) iff

\begin{aligned} (labels) & λ_{E} (e) = L_{E}; \\ (property names) & d o m (ρ_{E} (e)) = d o m ({p t y p e}_{E}); \\ (typing) & \forall k \in d o m ({p t y p e}_{E}) . ρ_{E} (e) (k) \in ⟦ {p t y p e}_{E} (k) ⟧; \\ (kind and endpoints) & d i r (e) agrees with {k i n d}_{E} and the endpoints \\ have the node types in {e n d S p e c}_{E}, \end{aligned}

For a directed type the endpoint check preserves source and destination. For an undirected type it requires the relation between the two endpoints and the one or two endpoint node types to be both left-total and right-total.

For example, let ${E T}_{i n c}$ denote the local type name, in the descriptor model used here, of the directed edge type specification carrying the label INCLUDES in Section 4.2. It is represented by

{p t y p e}_{i n c} = {due_date \mapsto D A T E, late_fee \mapsto F L O A T},

$\begin{aligned} \mathbf{ETypeDesc}_{\mathsf{inc}} ={}&\bigl\langle \mathsf{ET}_{\mathsf{inc}}, \{\texttt{INCLUDES}\}, \mathsf{directed},\\ &\langle\texttt{Loan},\texttt{Book}\rangle, \mathsf{ptype}_{\mathsf{inc}} \bigr\rangle. \end{aligned}$

The edge $e_{i n c, 1}$ in the library instance conforms to this type: its label set is ${INCLUDES}$ , it is directed from the Loan node $l$ to the Book node $b_{1}$ , and its two property values have the declared $D A T E$ and $F L O A T$ types.

Element-type implication and structural consistency. GQL does not obtain element-type membership from an open-property inheritance rule. Within one graph type, an element type $T_{1}$ implies a keyed element type $T_{0}$ when both have the same element kind, the effective key label set of $T_{0}$ is a subset of the label set of $T_{1}$ , and the key-label-set conditions of the graph type are met. Structural consistency then requires the label set and property-name set of $T_{0}$ to be subsets of those of $T_{1}$ , and each pair of same-named property value types to combine to the value type declared by $T_{0}$ under graph-type-specific combination. Implied edge types must additionally be structurally endpoint-consistent and have the same directionality. This is distinct from the ordinary value-type subtyping relation $⊑$ of Section 6.1.

15.4 Graph Types

Reduced structural graph-type descriptor component. In the reduced book-level representation used here, write

Σ = ⟨ N D e c l s, E D e c l s, N o d e K L S, E d g e K L S ⟩ .

Here $N D e c l s$ is a finite map from node type names to $N D e s c$ , and $E D e c l s$ is a finite map from edge type names to $E T y p e D e s c$ . The node key-label-set dictionary $N o d e K L S$ maps every node type key label set to its keyed node type; $E d g e K L S$ maps every edge type key label set to the corresponding set of keyed edge types. The declarations must satisfy GQL’s key-label-set implication consistency, property-value-type consistency, and endpoint consistency conditions.

Constraint dictionary (operational part). Let $C D e s c$ be the abstract carrier of key and unique constraint descriptors; its components and satisfaction semantics are defined in Chapter 16. A graph type comprises a node type set, an edge type set, and a constraint set. Its reduced descriptor representation pairs $Σ$ with the named constraint dictionary $I_{G T} : 𝔸 ⇀ C D e s c$ . See Section 15.5 below for this pair and its use in catalog entries.

Example: libraryGraphType. Let ${N D e c l s}_{l i b}$ and ${E D e c l s}_{l i b}$ be the descriptor maps induced by the node- and edge-type declarations in Section 4.2. In particular,

{N D e c l s}_{l i b} (Book) = {N D e s c}_{Book}, {E D e c l s}_{l i b} ({E T}_{i n c}) = {E T y p e D e s c}_{i n c} .

The key-label-set dictionaries are

\begin{aligned} {N o d e K L S}_{l i b} = { & {Loan} \mapsto Loan, \\ {LibraryAccount} \mapsto LibraryAccount, \\ {Reader} \mapsto Reader, \\ {LibraryCard} \mapsto LibraryCard, \\ {Book} \mapsto Book}, \\ {E d g e K L S}_{l i b} = & \emptyset . \end{aligned}

Hence the static schema is

Σ_{l i b} = ⟨ {N D e c l s}_{l i b}, {E D e c l s}_{l i b}, {N o d e K L S}_{l i b}, {E d g e K L S}_{l i b} ⟩ .

The associated constraint dictionary $I_{l i b}$ satisfies

\begin{aligned} d o m (I_{l i b}) = { & LoanHasKey, LibraryAccountHasKey, ReaderHasKey, \\ LibraryCardHasKey, BookHasKey}, \end{aligned}

and each name maps to the key-constraint descriptor induced by the corresponding declaration in Section 4.2.

15.5 Graph Entries and Constraining Types

Constraining graph type descriptor. In the reduced book-level representation used here, a $G T y p e D e s c$ is the pair $⟨ Σ, I_{G T} ⟩$ , where $Σ$ is the structural descriptor component above and $I_{G T}$ maps each constraint name to its key or unique constraint descriptor. The fixed primary-base-type name and preferred-name metadata of the full ISO descriptor are elided from this representation.

A graph $G$ is of the graph type described by $G T y p e D e s c = ⟨ Σ, I_{G T} ⟩$ exactly when every node of $G$ is of a node type in $N D e c l s$ , every edge is of an edge type in $E D e c l s$ , and every constraint of the graph type is satisfied. There is no independent “open labels” or “open properties” policy inside a graph type; openness instead means that a graph has no constraining graph type.

Graph entries. A catalog graph entry abstracts the ISO graph descriptor as

G r a p h E n t r y = ⟨ G, {G T}^{?}, I_{G} ⟩,

where $G$ is the instance graph, ${G T}^{?}$ is either a globally resolved graph type reference or $n o n e$ (no constraining graph type), and $I_{G}$ maps names to constraints defined directly on $G$ . If ${G T}^{?} = G T$ , constraint names are unique independently of their origin, so

d o m (I_{G}) \cap d o m (I_{G T}) = \emptyset .

For the library graph created in Section 4.2 and populated in Section 4.3, let $G_{l i b}$ denote the resulting graph instance and let ${G T}_{l i b}$ be the globally resolved graph type reference denoted by libraryGraphType. Since the example declares no constraints directly on the graph, its catalog entry is

{G r a p h E n t r y}_{l i b} = ⟨ G_{l i b}, {G T}_{l i b}, \emptyset ⟩ .

The empty third component means only that the graph has no directly defined constraints. The key constraints contained in the resolved libraryGraphType still apply through the constraining graph type reference in the second component.

Catalog location. Cataloged graph types and cataloged graphs are primary objects held by a GQL-schema in the single catalog $C$ of Chapter 17. Inline graph types and unnamed graphs can also be primary objects without being catalog objects. Node and edge type descriptors are secondary objects contained in a graph type; they are not parallel top-level catalog dictionaries.

Resolution. Name resolution is modeled by partial functions that consult $C$ . For graph types, write

{r e s o l v e}_{G r a p h T y p e} (C, G T) = ⟨ Σ_{G T}, I_{G T} ⟩

when the graph type reference identifies that descriptor in its parent GQL-schema.

Graph-entry conformance. Write $G ⊧_{s t r} Σ$ when every node and edge of $G$ satisfies the applicable label, property, directionality, and endpoint requirements encoded by the node and edge type declarations in $Σ$ . For a set $J \subseteq C D e s c$ , write $G ⊧_{c o n} J$ when $G$ satisfies every key or unique constraint descriptor in $J$ , with satisfaction as specified in Section 16.1. For $G E = ⟨ G, {G T}^{?}, I_{G} ⟩ \in G r a p h E n t r y$ , let

I_{d i r e c t} (G E) = r a n (I_{G})

be the constraints defined directly on the graph. For bookkeeping, the set of all constraints registered for the graph is

I_{a c t i v e} (G E) = r a n (I_{G}) \cup {\begin{matrix} r a n (I_{G T}), & {G T}^{?} = G T, \\ \emptyset, & {G T}^{?} = n o n e . \end{matrix}

but dynamic validation retains the two origins. The constraints in $I_{d i r e c t} (G E)$ are validated directly. If ${G T}^{?} = G T$ , resolution must succeed and the separate test that $G$ is of its constraining graph type requires

G ⊧_{s t r} Σ_{G T} \land G ⊧_{c o n} r a n (I_{G T}) .

Every graph must additionally satisfy $G ⊧_{c o n} I_{d i r e c t} (G E)$ . A graph with a constraining graph type is closed; a graph with ${G T}^{?} = n o n e$ is open. Constraints apply only to their registered subjects, so constraints collected for a different graph entry or graph type are never included in $I_{a c t i v e} (G E)$ .

15.6 DDL Semantics

General form. A DDL statement $D$ denotes a partial function

⟦ D ⟧ : C a t a l o g ⇀ C a t a l o g

for the catalog-modifying statements modeled here. A successful result must be a well-formed hierarchical catalog. In particular, every surviving $G r a p h E n t r y$ must still resolve its optional constraining graph type and satisfy its active graph-type and graph constraint dictionaries at the required validation point.

Node and edge type definitions. This edition of GQL has no standalone CREATE NODE TYPE or CREATE EDGE TYPE catalog-modifying statement. Node and edge type specifications are secondary objects created as body items of a graph type.

Creating graph types. The concrete syntax of CREATE GRAPH TYPE statements is governed by the core GQL grammar (where graph types are catalog objects whose bodies enumerate node types, edge types, and optional schema-level constraints). The following abbreviated BNF preserves the alternatives relevant here; the node- and edge-type nonterminals are the pattern/phrase forms of the core grammar:

BNF

create-graph-type-stmt ::=
  "CREATE" ( [ "PROPERTY" ] "GRAPH" "TYPE" [ "IF" "NOT" "EXISTS" ]
             | "OR" "REPLACE" [ "PROPERTY" ] "GRAPH" "TYPE" )
  catalog-graph-type-parent-and-name graph-type-source

graph-type-source ::= [ "AS" ] nested-graph-type-spec
                    | [ "AS" ] "COPY" "OF" graph-type-reference
                    | "LIKE" graph-expression

nested-graph-type-spec ::= "{" graph-type-body-item
                               { "," graph-type-body-item } "}"

graph-type-body-item ::= node-type-spec
                       | edge-type-spec
                       | "CONSTRAINT" constraint-spec

node-type-spec ::= node-type-pattern | node-type-phrase
edge-type-spec ::= edge-type-pattern | edge-type-phrase

property-types-spec ::= "{" [ property-type
                                   { "," property-type } ] "}"

property-type ::= property-name [ ( "::" | "TYPED" ) ] property-value-type

Semantically, a create-graph-type-stmt introduces a named graph type whose node- and edge-type items populate $N D e c l s$ and $E D e c l s$ of a tuple $Σ$ as defined above, while each property-type contributes an entry to the corresponding property signature ${p t y p e}_{T}$ . Each CONSTRAINT item populates $I_{G T}$ with a named key or unique constraint. The resulting graph type may be used as a constraining type in catalog graph entries as described in Section 15.5. A complete CREATE GRAPH TYPE statement using node types, edge types, property signatures, and key constraints appears in Section 4.2.

Alteration and conversion. The ISO standard defines creation, replacement, and dropping of graph types, but no ALTER TYPE, ALTER PROPERTY, ADD KEY, or DDL USING conversion clause. Such schema/data migration is therefore outside this core semantics. Whenever a value is assigned or explicitly cast by supported GQL syntax, the cast and store- assignment rules apply and may raise an exception; no type-set inclusion makes that conversion total by itself.

Dropping declarations. The core drop operation here is DROP [PROPERTY] GRAPH TYPE [IF EXISTS] q. It is permitted only when no existing graph in the catalog references that graph type. On success the descriptor is removed from its parent schema and destroyed. Consequently the operation neither silently changes the property type of existing data nor requires an invented property-level cast. OR REPLACE first performs this same drop and is subject to the same reference condition.

15.7 Schema Versioning

Scope. Let $S c h$ be the current schema state extracted from the catalog and ${S c h}^{'}$ a schema state produced by a supported evolution step. ISO 39075 leaves it implementation-defined which catalog-modifying procedures are under transaction control and uses a feature to govern whether data modification and catalog modification may appear in the same transaction. Where an implementation supports transactional DDL and such mixing, we model schema evolution as producing a new schema state ${S c h}^{'}$ from $S c h$ .

Schema states and versions. DDL commands produce a chain

{S c h}^{(0)} \to_{}^{{D D L}_{1}} {S c h}^{(1)} \to_{}^{{D D L}_{2}} \dots \to_{}^{{D D L}_{n}} {S c h}^{(n)} .

Whether these catalog changes participate in a transaction and any physical reorganization are implementation-defined. The standard’s statement-specific validation and execution rules remain controlling; the formal development assumes a conforming catalog state after each successful committed step.

Chapter 15 — Takeaways.

Purpose: Introduced the static typing layer and schema objects that constrained property graphs beyond the raw data model.
Introduced: Cataloged graph types containing node and edge types as secondary objects; property-type declarations; schema evolution behavior and how DDL affected the catalog state.
Key distinctions: Graph conformance to a declared type versus mere existence of a named type in the catalog; schema evolution versus ordinary data updates.
Consequences: Enabled static checking of queries and updates against declared types; assigned a precise semantic meaning to DDL operations; prepared the ground for integrity constraints defined over typed populations.
Bridge: Set up integrity constraints as the next layer that enforced correctness beyond typing.