Matching and Rewriting Rules in Object-Oriented Databases

Abstract

Graph query languages such as Cypher are widely adopted to match and retrieve data in a graph representation, due to their ability to retrieve and transform information. Even though the most natural way to match and transform information is through rewriting rules, those are scarcely or partially adopted in graph query languages. Their inability to do so has a major impact on the subsequent way the information is structured, as it might then appear more natural to provide major constraints over the data representation to fix the way the information should be represented. On the other hand, recent works are starting to move towards the opposite direction, as the provision of a truly general semistructured model (GSM) allows to both represent all the available data formats (Network-Based, Relational, and Semistructured) as well as support a holistic query language expressing all major queries in such languages. In this paper, we show that the usage of GSM enables the definition of a general rewriting mechanism which can be expressed in current graph query languages only at the cost of adhering the query to the specificity of the underlying data representation. We formalise the proposed query language in terms declarative graph rewriting mechanisms described as a set of production rules $L\to R$ while both providing restriction to the characterisation of L, and extending it to support structural graph nesting operations, useful to aggregate similar information around an entry-point of interest. We further achieve our declarative requirements by determining the order in which the data should be rewritten and multiple rules should be applied while ensuring the application of such updates on the GSM database is persisted in subsequent rewriting calls. We discuss how GSM, by fully supporting index-based data representation, allows for a better physical model implementation leveraging the benefits of columnar database storage. Preliminary benchmarks show the scalability of this proposed implementation in comparison with state-of-the-art implementations.

1. Introduction

Query languages [1] fulfill the aim of retrieving and manipulating data after being adequately processed according to a physical model requiring preliminary data loading and indexing operations. Good declarative languages for manipulating information, such as SQL [2], are agnostic from the underlying physical model while expressing the information need of combining (JOIN), filtering (WHERE) and grouping (e.g., COUNT(*) over GROUP BY-s) data over its logical representation. This language can also be truly declarative as it does not require a user to explicitly convey this in terms of operations to be performed over the data rather than instructing the machine which information should be used and which types of transformations should be applied. Due to the intrinsic nature of graph data representation, graph query languages such as Gremlin [3], Cypher [4], or SPARQL [5] are procedural (i.e., navigational) due to the navigational structure of the data, thus heavily requiring the user to inform the language how to match and transform the data. These considerations extend to how edge and vertex data should be treated, thus adding further complexity [6,7].

On the other hand, graph grammars [8] provide a high-level declarative way to match specific sub-graphs of interest from vertex-labelled graphs for then rewriting them into another subgraph of interest, thus updating the original graph of interest. These consist in a set of rules ${\{L_i\to R_i\}}_{1\le i\le N}$, where each rule $L_i\to R_i$ consists of two graphs $L_i$ and $R_i$ possibly sharing a common subgraph K: while $K\subseteq L$ specifies a potential removal of either vertices or edges, $K\subseteq R$ specifies their addition. Automating the application of such rules requires explicitly following a graph navigational order for applying each matched subgraph to the structure [9] to guarantee the generation of a unique acceptable graph representation resulting from the querying data. As a by-product of exploiting topological sorts for scheduling visiting and rewriting operations, we then require to precisely identify an entry match vertex for each $L_i$ from a rule, thus precisely determining from which position within the graph the rewriting rule should be applied, and in which order.

At the time of writing, the aforementioned graph query languages are not able to express graph grammars natively without resorting to explicitly instructing the query language how to restructure the underlying graph data representation (Lemma 7); furthermore, the replacement of previously matched vertices with new ones invalidates previous matches, thus forcing the user to pipeline different queries until convergence is reached. On the other hand, we would expect any graph query language to directly express the rewriting mechanism by directly expressing the set of rules, without necessarily instructing the querying language in which order such operations shall be performed. Furthermore, when a property-graph model is chosen, and morphisms are expressed through the properties associated with the vertices and edges rather than their associated IDs as per the current Cypher and Neo4j v5.20 specifications, this makes the deletion of vertices and their update through the resulting morphisms quite impractical, as such data model provides no clear way to refer to both vertices and edges via unique identifiers. As a result of these considerations, we then derive that, at the time of writing, both the graph query languages and their underlying representational model are insufficient to adequately express rewriting rules as general as the ones postulated by graph grammars over graphs containing property-value associations, independently from their representation of choice [10].

To overcome the aforementioned limitations, we propose a query language, for the first time directly expressing such rewriting desiderata: we restrict the set of all the possible matching graphs $L_i$ into ego-nets containing one entry-point while incorporating nesting operations (Section 6.1); as updating graph vertices’ properties breaks the declarative assumption as the user should specify the order in which the operations are performed, we relax the language declarativity for the sole rewritings. To better support this query language, we completely shift the data model of interest to object-oriented databases, where relationships across objects are expressed through object “containment” relationships, and where both objects and such containments are uniquely identified. By also requiring that any object shall never contain itself at any nesting level [6], we obtain cycle-free containment relationships.

The paper is structured as follows: after providing some preliminary notation used throughout the paper (Section 2), we introduce the relational and the graph data models from current literature, while focusing on both their data representation and associated query languages (Section 3). Their juxtaposition motivates the proposal of our Generalised Semistructured Model (Section 4), for which we outline both the logical and physical data model, where the latter leverages state-of-the-art columnar relational database representations [11]; we also introduce the concept of a view for a generalised semistructured model, as well as introduce some morphism notation used throughout the paper. After introducing the designated operator for instantiating the morphisms by joining matched containments stored in distinct sets of tables (Section 5), we finally propose our query language for matching and rewriting object-oriented databases expressed in the aforementioned GSM model (Section 6). We characterise the formal semantics of such novel graph query language in pseudocode notation (Algorithm from Section 6) characterised in terms of both algorithmic and algebraic notation (Section 6.3 and Section 6.4) for the matching part, as well as in terms of Structured Operational Semantics (SOS) [12] for describing the rewriting steps (Section 6.5). The remaining sections discuss some of the expressiveness properties of such query language if compared to Cypher (Section 7), discuss its time complexity (Section 8), and benchmark it against Cypher running over Neo4j v5.20, showing the extreme inefficiency of property graph computational model (Section 9), which are fairly restricted due to the impossibility of conveying a novel single query for any possible graph schema (Lemmas in Section 7). Scalability tests show that our solution outperforms Cypher and Neo4j v5.20, providing the query language standard nearer to the recently proposed GQL, by two orders of magnitude (Section 9.1) while providing a computational throughput being 600 times faster than Neo4j by solving more queries in the same comparable amount of time (Section 9.1). Last, we draw our final conclusions where we propose some future works (Section 10). To improve the paper’s readability, we move some definitions (Appendix A) and the full set of proofs for the Lemmas and Corollaries (Appendix B) to the Appendix.

These main contributions are then obtained in terms of the following ancillary results:

• Definition of a novel nested relational algebra natural equi-join operator for composing nested morphisms, also supporting left outer joins by parameter tuning (Section 5).
• Definition of an object-oriented database view for updating the databases on the fly without the need for heavy restructuring of the loaded and indexed physical model (Section 4.3).
• As the latter view relies on the definition of a logical model extending GSM (Section 4.1), we show that the physical model is isomorphic to an indexed set of GSM databases expressed within the logical model (Lemma 1).

2. Preliminary Notation

We denote sets $S=\{x_1,\dots ,x_n\}$ of cardinality $\left|S\right|=n$ as standard. The power set $\wp \left(S\right)$ of any set S is the set of all subsets of S, including the empty set ∅ and S itself. Formally, $\wp \left(S\right)=\left\{S^{\prime }\right|S^{\prime }\subseteq S\}$.

We define a finite function $f:A\rightharpoonup B$ via its graph$[(x_1,f\left(x_1\right)),\dots ,(x_n,f\left(x_n\right))]$ explicating the association between a value from the domain of f ($\{x_i,\dots ,x_i\}=dom\left(f\right)$) and a non-NULL codomain value. Using an abuse of notation, we denote the restriction${f|}_X$ as the evaluation of f over a domain $X\cap dom\left(f\right)$, i.e., ${f|}_X=\left[(x,f\left(x\right))\right|x\in X\cap dom\left(f\right)]$. We can also denote $f\left(x\right):=C$ where C is the definition of the function over x as $x\mapsto C$. With an abuse of notation, we denote $\left|f\right|$ as the cardinality of its domain, i.e., $\left|f\right|=|dom(f\left)\right|$. We say that two functions f and $f^{\prime }$ are equivalent, $f\dot{=}{f}^{\prime }$, if and only if they both share the same domain and, for each element of their domain, both functions return the same codomain value, i.e., $f\dot{=}{f}^{\prime }\iff dom\left(f\right)=dom\left(f^{\prime }\right)\wedge \forall x\in dom\left(f\right).f\left(x\right)=f^{\prime }\left(x\right)$.

A tuple or indexed set $t=\langle t_1,\dots ,t_n\rangle$ of length$\left|t\right|=n$ is defined as a finite function in $\mathbb{N}\rightharpoonup \mathcal{V}$ where $t_i$ has i as a natural-valued independent variable representing the index of the tuple, and the dependent variable corresponds to the element $t\left(i\right)$ in the tuple.

A binary relation ℜ on a set A is said to be an equivalence relation if and only if it is reflexive ($\forall x\in A.x\Re x$), symmetric ($\forall x,y.x\Re y\iff y\Re x$), and transitive ($\forall x,y,z.x\Re y\wedge y\Re z\Rightarrow x\Re z$). Given a set A and an equivalence relationship ℜ, an equivalence class ${\left[x\right]}_{\Re }\subseteq A$ for $x\in A$ is the set of all the elements in A that are equivalent to x, i.e., ${\left[x\right]}_{\Re }=\{y\in A|x\Re y\}$. Given a set A and an equivalence relationship ℜ, the quotient set ${\displaystyle \raisebox{1ex}{$A$}\!\left/ \!\raisebox{-1ex}{$\Re $}\right.}$ is the set of all the equivalence classes of A, i.e., ${\displaystyle \raisebox{1ex}{$A$}\!\left/ \!\raisebox{-1ex}{$\Re $}\right.}=\left\{{\left[x\right]}_{\Re }\right|x\in A\}$. We denote ${\dot{=}}_X$ as the equivalence relationship denoting two functions as equivalent if they are equivalent after the same restriction over X, i.e., $f{\dot{=}}_X{f}^{\prime }\iff f{{|}_X\dot{=}{f}^{\prime }|}_X$.

Given a set of all the possible string attributes ${\mathsf{\Sigma }}^{*}$ and a set of all the possible values $\mathcal{V}$, a record is defined as a finite function $f:A\rightharpoonup \mathcal{V}$ with $A\subseteq {\mathsf{\Sigma }}^{*}$ [13]. Given two records represented as finite functions f and $f^{\prime }$, we denote $f\oplus f^{\prime }$ as the overriding of f by $f^{\prime }$ returning $f^{\prime }\left(x\right)$ for each $x\in dom\left(f^{\prime }\right)$ and $f\left(x\right)$ otherwise. Given this, we can also denote the graph of a function as ${\oplus }_{x_i\in dom\left(f\right)}\left[(x_i,f\left(x_i\right))\right]\equiv \left[(x_i,f\left(x_i\right))\right|x_i\in dom\left(f\right)]$. We denote as NULL   a void value not representing a sensible value in $\mathcal{V}$: using the usual notation in the database area at the cost of committing an abuse of notation, we say that $f\left(x\right)$ returns NULL   if and only if f is not defined over x (i.e., $x\notin dom\left(f\right)$). We say that a record $ϵ$ is empty if no attribute is associated with a value in $\mathcal{V}$ (i.e., $dom\left(ϵ\right)=\varnothing$ and $\forall x\in \mathcal{V}.ϵ\left(x\right)=\mathtt{NULL}$).

Higher-Order Functions

Higher-Order Functions (HOFs) are functions that either take one or more functions as arguments or return a function as a result. We provide the definition of some HOFs used in this paper:

• The zipping operator maps n tuples (or records) $t^1,\dots ,t^n$ to a record of tuples (or records) r defined as $r\left(i\right)=\langle t_i^1,\dots ,t_i^n\rangle$ if and only if all n tuples are defined over i:

  $$\zeta (t^1,\dots ,t^n)=\left[\langle t_i^1,\dots ,t_i^n\rangle \right|i\le i\le min\left(\right|t^1|,\dots ,|t^n\left|\right),\forall 1\le j\le n.i\in dom\left(t^j\right)]$$
• Given a function $f:A\to B$ and a generic collection C, the mapping operator returns a new collection by applying f to each component of C:

  $$\mu (f,C)=\left\{\begin{array}{cc}\left\{f\right(x\left)\right|x\in C\}\hfill & C\mathrm{i}\mathrm{s} \mathrm{a} \mathbf{set}\hfill \\ \left[f\right(C\left)\right(i\left)\right|i\in dom\left(C\right)]\hfill & C\mathrm{i}\mathrm{s} \mathrm{a} \mathbf{record}\hfill \\ \langle f\left(C_1\right),\dots ,f\left(C_n\right)\rangle \hfill & C\mathrm{i}\mathrm{s} \mathrm{a} \mathbf{tuple}\hfill \end{array}\right.$$
• Given a binary predicate p and a collection C, the  filter function trims C by restricting it to its values satisfying p:

  $$\mathsf{ϝ}(p,C)=\left\{\begin{array}{cc}\{x\in C|p\left(x\right)\}\hfill & C\mathrm{is} \mathrm{a} \mathbf{set}\hfill \\ \left[x\right(C\left)\right(x\left)\right|x\in dom\left(C\right),p\left(C\right(x\left)\right)]\hfill & C\mathrm{is} \mathrm{a} \mathbf{record}\hfill \\ x\mapsto {argmin}_{\begin{array}{c}\left|C\right|\ge i\ge x\\ \mathrm{s}.\mathrm{t}.p\left(C_i\right)\end{array}}{C}_i\hfill & C\mathrm{is} \mathrm{a} \mathbf{tuple}\hfill \end{array}\right.$$
• Given a binary function $f:A\times \mathcal{V}\to A$, an initial value $\alpha \in A$ (accumulator), and a tuple C, the (left) fold operator is a tail-recursive function returning either $\alpha$ for an empty tuple, or $f(\dots f(\alpha ,t_1),t_n)$ for a tuple $t=\langle t_1,\dots ,t_n\rangle$:

  $$\Lambda (f,\alpha ,C)=\left\{\begin{array}{cc}\alpha \hfill & \left|C\right|=0\hfill \\ \Lambda (f,f(\alpha ,C\left(m\right)),C{|}_{dom\left(C\right)\setminus \left\{m\right\}})\hfill & \left|C\right|\ne 0\wedge m:=mindom\left(C\right)\hfill \end{array}\right.$$
• Given a collection of strings C and a separator s, collapse (also referred to as join in programming languages such as Javascript or Python ) returns a single string where all the strings in C are separated by s. Given “^” the usual string concatenation operator, this can be expressed in terms of $\Lambda$ as follows:

  $$\lambda (C,s):=\Lambda (^,s,C)$$
  When s is a space “␣”, then we can use $\lambda \left(C\right)$ as a shorthand.
• Given a function $f:A\rightharpoonup B$ and two values $a\in A$ and $b\in B$, the update of f so that it will return b for a and will return any other previous value for $f\left(x\right)$ otherwise is defined as follows:

  $${\mathrm{P}\mathrm{UT}}_f(a,b):=f\oplus \left[(a,b)\right]$$

  (1)
• Given a (finite) function f and an input value y, the HOF optionally obtaining the value of $f\left(y\right)$ if $y\in dom\left(f\right)$ and returning z otherwise is defined as:

  $${\mathrm{O}\mathrm{PT}\mathrm{G}\mathrm{ET}}_f(y,z):=\left\{\begin{array}{cc}f\left(y\right)\hfill & y\in dom\left(f\right)\hfill \\ z\hfill & \mathrm{oth}.\hfill \end{array}\right.$$
  Please observe that we can use this function in combination with Put to set multiple nested functions:

  $${\mathrm{P}\mathrm{UT}}_f^2(\langle i,j\rangle ,v):={\mathrm{P}\mathrm{UT}}_f(i,{\mathrm{P}\mathrm{UT}}_{{\mathrm{O}\mathrm{PT}\mathrm{G}\mathrm{ET}}_f(i,\varnothing )}(j,v))$$

  (2)

3. Related Works

This section outlines different logical models and query languages for both graph data (Section 3.1.1 and Section 3.1.2) and the nested relational model (Section 3.2.1 and Section 3.2.2), while starting from their mathematical foundations. We then discuss an efficient physical model used for the relational model (Section 3.2.3).

3.1. Graph Data

3.1.1. Logical Model

Direct Acyclic Graphs (DAGs) and Topological Sort

A digraph $\gamma =(V,E)$ consists of vertices V and edges E being a subset of $V^2$. We say that such a graph is weighted if its definition is extended as $(V,E,\omega )$ where $\omega :E\rightharpoonup \mathbb{R}$ is a weight function associating each edge in the graph to a real value. A closed trail is a sequence of distinct edges $(s_1,d_1),\dots ,(s_n,d_n)\in E$ which edge $(s_i,d_i)$ is such that $s_i=d_{i-1}$ and $d_i=s_{i+1}$ if any, and where $s_1=d_n$. We say that a digraph is acyclic if it contains no closed trails consisting of at least one edge, and we refer to it as a Direct Acyclic Graph (DAG).

If we assume that edges in a graph reflect dependency relationships across their vertices, a natural way to determine the visiting order of the vertices is first to sort its vertices topologically [14], thus inducing an operational scheduling order [11]. This requires the underlying graph to be a DAG. Notwithstanding this, any DAG might come with multiple possible valid topological sorts; among these, the scheduling of tasks operations usually prefers visiting the operations bottom-up in a layered way, thus ensuring the operations are always applied starting from the sub-graphs having less structural-refactoring requirements that the higher ones [11].

We say that a topological sort of a DAG $(V,E)$ is a linear ordering of its vertices in a tuple t with $\left|t\right|=\left|V\right|$ so that for any edge $(u,v)\in E$ we have i and $j>0$ such that $u=t_i$ and $v=t_{i+j}$. Given this linear ordering of the vertices, we can always define a layering algorithm [15] where vertices sharing no mutual interdependencies are placed in the same layer, and where all the vertices appearing in the shallowest layer will be connected by transitive closure to all the vertices in the deeper layers, while the vertices in the deepest layer will share no interconnection with the other vertices in the graph. To do so, we can use Algorithm 1: we use timestamps for determining the layer ID: we associate all vertices with no outgoing edge to the deepest layer 0 (Line 5) and, for all the remaining vertices, we set the vertex to the layer immediately below to the one of the deepest outgoing vertex (Line 9).

Algorithm 1 Layering DAGs from a vertex topological order in t

1: function LayerFromTopologicalSort(G $=(V,E)$, t) 2:     time$:=\langle -1,\dots ,-1\rangle$                 ▹$\left|\mathrm{time}\right|=\left|t\right|$ 3:     firstVisit $:=\mathbf{true}$ 4:     for all $p\in \mathsf{Reverse}\left(t\right)$ do 5:         time[p]$:=0$ 6:         if firstVisit then 7:            firstVisit$:=$false 8:         else if $\mathrm{In}\left(p\right)\ne \varnothing$ then 9:            time [p]$:=max\left\{\mathrm{time}\right[u\left]\right|u\in \mathrm{O}\mathrm{UT}\left(p\right)\}+1$ 10:         end if 11:     end for 12:     return time 13: end function

When the graph is cyclic, we can use heuristics to approximate the vertex order, such as using the progressive ID associated with the vertices to disambiguate and choose an ordering when required.

Property Graphs

Property graphs [16] represent multigraphs (i.e., digraphs allowing for multiple edges among two distinct vertices) expressing both vertices and edges as multi-labelled records. The usefulness of this data model is remarked by its implementation in almost all recent Graph DBMSs, such as Neo4j [4].

Definition 1 

(Property Graph). A property graph [9] is a tuple $(V,E,L,A,U,\ell ,\kappa ,\lambda )$, where V and E are sets of distinct integer identifiers ($V\subseteq \mathbb{N}$, $E\subseteq \mathbb{N}$, $V\cap E=\varnothing$). L is a set of labels, A is a set of attributes and U is a set of values. $\ell :V\cup E\rightharpoonup \wp \left(L\right)$ maps each vertex or edge to a set of labels; $\kappa :V\cup E\rightharpoonup A\rightharpoonup U$ maps each vertex or edge within the graph and each attribute within A, to a value in U; last, $\lambda :E\rightharpoonup V\times V$ maps each edge $e\in E$ to a pair of vertices $\lambda \left(e\right)=(s,t)\in V\times V$, where s is the source vertex and t is the target.

Property graphs do not support aggregated values, as values in U cannot contain either vertices or edges, nor U is made to contain a collection of values.

RDF

The Resource Description Framework (RDF) [17] distinguishes resources via Unique Resource Identifiers (URI), be them vertices or edges within a graph; those are linked to their properties or other resources via triples, acting as edges. RDF is commonly used in the semantic web and in the ontology field [18,19]. Thus, modern reasoners such as Jena [20] or Pellet [21] assume such data structure as the default graph data model.

Definition 2 (RDF (Graph Data) Model). 

An RDF (Graph data) model [9] is defined as a set of triples $(s,p,o)$, where s is called “subject”, p is the “predicate” and o is the “object”. Such triple describes an edge with label p linking the source vertex s to the destination vertex o. Such predicate can also be a source vertex [10]. Each vertex is either identified by a unique URI identifier or by a blank vertex $b_i$. Each predicate is only described by a URI identifier.

Despite this model using unique resource identifiers for either vertices or edges differently from property graphs, RDF is forced to express attribute-value associations for vertices as additional edges through reification. Thus, property graphs can be entirely expressed as RDF triplestore systems as follows:

Definition 3 

(Property Graph over Triplestore). Given a property graph $G=(V,E,A,U,\ell ,\kappa ,{\lambda }^{\prime })$, each vertex $v_i\in V$ induces a set of triples $(v_i,\alpha ,\beta )$ for each $\alpha \in A$ such that $\kappa (v_i,\alpha )=\beta$ having $\beta \ne \mathtt{NULL}$. Each edge $e_j\in E$ induces a set of triples $(s,e_j,d)$ such that ${\lambda }^{\prime }\left(e_j\right)=(s,d)$ and another set of triples $(e_j,{\alpha }^{\prime },{\beta }^{\prime })$ for each ${\alpha }^{\prime }\in A$ such that $\kappa (e_j,{\alpha }^{\prime })={\beta }^{\prime }$ having ${\beta }^{\prime }\ne \mathtt{NULL}$.

The inverse transformation is not always possible as RDF properties as property graphs do not allow the representation of edges departing from other edges. RDF also supports the unique identification of distinct databases being loaded within the same physical storage through named graphs via a resource identifier. Even though it allows named graphs to appear as triplet subjects, such named graphs can appear as neither objects nor properties, thus not overcoming property graphs’ limitations on representing nested data.

Notwithstanding the model’s innate ability to represent both vertices and edges via URIs, the inability of the data model to directly associate each URI with a data record while requiring it to express the property-value associations via triplets, requires the expression of property updates via the deletion and subsequent creation of new triplets of the data, which might be quite impractical. Given all the above, we still focus our attention on the Property Graph model, as it better matches our data representation desiderata by associating to vertices labels, property-value associations, as well as binary relationships without any data duplications.

3.1.2. Query Languages

Despite the recent adoption of a novel graph query language standard, GQL, (https://www.iso.org/obp/ui/en/#!iso:std:76120:en accessed on 19 April 2024), its definition has still to be implemented yet in existing systems. This motivates us to briefly survey currently available languages. Different from the more common characterisation of graph query languages in terms of their potential of expressing traversal queries [22], a better analysis of such languages involves their ability to generate new data. Our previous work [9] proposed the following characterisation:

• Graph Traversal and Pattern Matching:  these are mainly navigational languages performing the graph visit through “tractable” algorithms through polynomial time visits with respect to the graph size [18,23,24]. Consequently, such solutions do not necessarily involve running a subgraph isomorphism problem, except when expressly requested by specific semantics [22,25].
• (Simple) Graph Grammars:  as discussed in the forthcoming paragraph, they can add and remove new vertices and edges that do not necessarily depend on previously matched data, but they are unable to express full data transformation operations.
• Graph Algebras:  these are mainly designed either to change the structure of property graphs through unary operators or to combine them through n-ary (often binary) ones. These are not to be confused with the path-algebras for expressing graph traversal and pattern-matching constructs, as they allow us to completely transform graphs alongside the data associated with them as well as deal with graph data collections [26,27,28,29].
• “Proper” Graph Query Languages:  We say that a graph query language is “proper” when its expressive power includes all the aforementioned query languages, and possibly expresses the graph algebraic operators while being able to express, to some extent, graph grammar rewriting rules independently from their ability to express them in a fully-declarative way. This is achieved to some extent in commonly available languages, such as SPARQL and Cypher [4].

Graph Grammars

Graph grammars [30] are the theoretical foundations of current graph query languages, as they express the capability of matching specific patterns L [31] within the data through reachability queries while applying modifications to the underlying graph database structure (graph rewriting) R, thus producing a single graph grammar production rule $L\stackrel{f}{\to }R$, where there is an implicit morphism between some of the vertices (and edges) matched in L and the ones appearing in R: the vertices (and edges) only appearing in R are considered as newly inserted vertices, while the vertices (and edges) only appearing in L are considered as removed edges; we preserve the remaining matched vertices. Each rule is then considered as a function f, taking a graph database as an input and returning a transformed graph.

The process of matching L is usually expressed in terms of subgraph isomorphism: given two graphs G and L, we determine whether G contains a subgraph $G_i$ that is isomorphic to L, i.e., there is a bijective correspondence $L\stackrel{{\mu }_i^L}{\leftrightarrow }{G}_0$ between the vertices and edges of L and $G_i$. In graph query languages, we consider G as our graph database and return $f\left(G_i\right)$ for each matched subgraph $G_i$. When no rewriting is considered, each possible match $G_0$ for L is usually represented in a tabular form [31,32], where the column header provides the vertex and edge identifiers (e.g., variables) j from L, each row reflects each matched graph $G_i$, and each cell corresponding to the column j represents ${\mu }_i\left(j\right)$.  Figure 1 shows the process of querying a graph g (Figure 1a) through a pattern L (Figure 1b), for which all the subgraphs matching in the former could be reported as morphisms listed as rows within a table, which column headers reflect the vertex and edge variables occurring in the graph pattern (Figure 1c).

 Figure 2 illustrates graph grammar rules as defined in GraphLog [33] for both matching and transforming any graph: we can first create the new vertices required in R, while updating or removing x as determined by the vertex or edge $f\left({\mu }_i^{-1}\left(x\right)\right)$ occurring in R. Deletions can be performed as the last operations from R. GraphLog still allows running of one single grammar rule at a time, while authors assume to have a graph where vertices are associated with data values and edges are labelled. Then, the rewriting operations derived from R will be applied to every subgraph being matched via a previously identified morphism in $MT[L,g]$ for each graph g of interest. Still, GraphLog considered neither the possibility of simultaneously applying multiple rewriting rules to the same graph nor a formal definition of which order the rules should be applied. The latter is required to ensure that any update on the graph can be performed incrementally while ensuring that any update to a vertex u via th information stored in its neighbours will always rely on the assumption that each neighbour will not be updated in any other subsequent step, thus guaranteeing that the information in u will never become stale.

This paper solves the ordering issue by applying the changes on the vertices according to their inverse topological order, thus updating the vertices sharing the least dependencies with their direct descendants first.

Furthermore, as GraphLog authors are considering a no-property graph model, authors do not consider the possibility of updating multiple property value associations over a vertex, while not providing a formal definition of how aggregation functions over vertex data should be defined. While the first problem can be solved only by properly exploiting a suitable data model, the latter is solved by the combined provision of nested morphism, explicitly nesting the vertices associated with a grouped variable, while exploiting a scripting language for expressing how level data manipulations when strictly required. Given these considerations, we will also discuss graph data models (Section 3.1) and their respective query languages (Section 3.1.2).

Proper Graph Query Languages

Given the above, we will mainly focus our attention on the last type of language. Even though these languages can be closed under either property graphs or RDF, graphs must not be considered as their main output result, since specific keywords like RETURN for Cypher and CONSTRUCT for SPARQL must be used to force the query result to return graphs. Given also the fact that such languages have not been formalised from the graph returning point of view, such languages prove to be quite slow in producing new graph outputs [6,7].

GQL is largely inspired by Cypher, for which this standard might be considered its natural extension. Such query language enables the partial definition of graph grammar operations by supporting the following operators restructuring vertices and edges within the graph: SET, for setting new values within vertices and edges, MERGE, for merging a set of attributes within a single vertex or edges, REMOVE for removing labels and properties from vertices and edges and CREATE for the creating of new vertices, edges and paths.

Notwithstanding the former, such language cannot express all the possible data transformation operations, thus requiring an extension via its APOC library (https://Neo4j.com/developer/Neo4j-apoc/, accessed on 13 November 2023) for defining User-Defined Functions (UDF) in a controlled way, like concatenating the properties associated with vertices’ multiple matches:

Thus, Cypher can collect values for then generating one single vertex (See also Listing A2) but, due to the structural limitations of the query language (not supporting nested morphisms) and data model (not supporting explicit identifiers for both vertices and edges), it does not support the nesting of entire sub-patterns of the original matching.

A further limitation of Cypher is the inability to create a relationship with a variable as the name, as standard Cypher syntax only allows a string parameter. Using the APOC library we can use apoc.create.relationship to pass a variable name from an existing vertex for example. Given our last query creating the vertex x, we can continue the aforementioned query:

As there are no associated formal semantics for the entirety of this language’s operators except its fragment related to graph traversal and matching [16], for our proofs regarding this language (e.g., Lemma 7) we are forced to reduce our arguments to common-sense reasoning an experience-driven observation from the usage of Cypher over Neo4j similarly to the considerations in the former paragraph. In fact, such algebra does not involve the creation of new graphs: this is also reflected by its query evaluation plan, which preferred evaluation is a morphism table rather than expressing the rewriting in terms of updated and resulting property graph. As a result, the process of creating or deleting vertices and edges is not optimised.

Overall, Cypher suffers from the limitations posed by the property graph data model which, by having no direct way to refer to the matched vertices or edges by reference, forces the querying user to always refer to the properties associated with them; as a consequence, the resulting morphism tables are carrying out redundant information that cannot reap the efficient data model posed by columnar databases, where entire records can be referenced by their ID. This is evident for statements, voiding objects represented within the morphisms. This limitation of the property graph model, jointly with the need for representing acyclic graphs, motivates us to use the Generalised Semistructured Model (GSM) as an underlying data model for representing graphs, thus allowing us to refer to the vertices and edges by their ID [34]. Consequently, our implementation represents morphisms for acyclic property graphs as per  Figure 1c.

 Figure 3a provides a possible property graph instantiation of the digraph originally presented in  Figure 1a. Notwithstanding the former definition, Neo4j’s implementation of the Property Graph model substantially differs from the aforementioned mathematical definition, as it does not allow the definition of an explicit resource identifier for both vertices and edges. After expressing the matching query in  Figure 1b in Cypher as *, the resulting morphism table from  Figure 3b does not explicitly reference the IDs referring to the specific vertices and edges, thus making it quite impractical to update the values associated with the vertices while continuing to restructure the graph, as this will require to re-match the previously updated data to retain it in the match. Although this issue might be partially solved by exploiting explicit incremental views over the property graph model [32], this solution had no application in Neo4j v5.20, thus making it impossible to fully test its feasibility within the available system. Furthermore, the elimination of an object previously matched within a morphism will update the table by providing an empty object rather than providing a NULL match. This will motivate us to investigate other ID-based graph data models.

Neo4j lists some additional existing limitations beyond APOC and the expressibility of graph grammars in a declarative way with Cypher within their documentation (https://Neo4j.com/docs/operations-manual/current/authentication-authorization/limitations/, accessed on 13 November 2023), mainly related to the interplay between data access security requirements and query computations.

At the time of writing, the most studied graph query language both in terms of semantics and expressive power is SPARQL, which allows a specific class of queries that can be sensibly optimised [5,31]. The algebraic language used to formally represent SPARQL performs queries’ incremental evaluations [35], and hence allows for boosting the querying process while data undergoes updates (both incremental and decremental).

While the clauses represented within the WHERE statement are mapped to an optimisable intermediate algebra [31,36], thus including the execution of “optional joins” paths [37] for the optional matching of paths, such considerations do not apply for the constraints related to the graph update or return, such as CONSTRUCT, INSERT, and DELETE. While CONSTRUCT is required for returning a graph view as a final outcome, INSERT and DELETE create and remove RDF triplets by chaining them with matching operations. These operations also come with sensible limitations: while the first does not allow the return of updated graphs that can be subsequently queried by the same matching algorithm, the two latter statements merely update the underlying data structure and require the re-computation of the overall matching query to retain the updated results. We will partially address these limitations in our query language and data model by associating ID properties directly via an object-oriented representation while keeping track of the updated information on an intermediate view, which is always accessible within the query evaluation phase.

Last but not least, the usage of so-called named graphs allows for the selection of over two distinct RDF graphs, which substantially differs from the queries expressible on Cypher, where those can be only computed by one graph database at a time. Notwithstanding the former, the latest graph query language standard is very different from SPARQL, hence, for the rest of the paper, we are going to draw our attention to Cypher.

3.2. Nested Relational Model

3.2.1. Logical Model

A nested relational model describes data represented in tabular format, where each table, composed of multiple records, comes with a schema.

Given a set of attributes ${\mathsf{\Sigma }}^{*}$ and a set of datatypes$\mathcal{T}$, a schema $S\in \mathcal{T}$ is a finite function mapping each string attribute in ${\mathsf{\Sigma }}^{\star }$ to its associated data type ($S:{\mathsf{\Sigma }}^{*}\rightharpoonup \mathcal{T}$). A schema is said to be not nested if it maps attributes to all basic data types, and nested otherwise. This syncretises the traditional function-based notation for schemas within the traditional relational model [13] with the tree-based characterisation of nested schemas

In this paper, we restrict the basic datatypes in $\mathcal{B}\subseteq \mathcal{T}$ to the following ones: vertex-ID ni, containment-ID ci, and a label or string str. Each of these types is associated with a set of possible values through a $\overline{\mathcal{B}}$ function: vertex- and containment-ID are associated with natural numbers ($\overline{\mathcal{B}}\left(\mathtt{ni}\right)=\overline{\mathcal{B}}\left(\mathtt{ci}\right)=\mathbb{N}$), while the string type is associated with the set of all the possible strings ($\overline{\mathcal{B}}\left(\mathtt{str}\right)={\mathsf{\Sigma }}^{*}$).

A record $\mathsf{\Gamma }$, associated with a schema $S\left(\mathsf{\Gamma }\right)=S$, is also a finite function mapping each attribute in $dom\left(S\right)$ to a possible value, either a natural number, a string, or a list of records (tables) as specified by the associated schema S ($\forall x\in dom\left(\mathsf{\Gamma }\right).\mathsf{\Gamma }\left(x\right)\in \overline{\mathcal{B}}\left(S\left(x\right)\right)$). We define a table T with schema $S\left(T\right)=S$ as a list of records all having schema S, i.e., $\forall \mathsf{\Gamma }\in T.S\left(T\right)=S\left(\mathsf{\Gamma }\right)$.

3.2.2. Query Languages

Relational algebra [13] is the de facto standard to decompose relational queries expressed in SQL to its most fundamental operational constituents while providing well-founded semantics for SQL. This algebra was later extended [38,39] to consider nested relationships. Relational algebra was also adapted to represent the combination of single edge/triple traversals in SPARQL, so as to express the traversal semantics of both required and optional patterns [5].

We now detail a set of operators of interest that will be used across the paper.

We relax the union operation from standard relational algebra by exploiting the notion of outer union [40]: given two tables t and s, respectively, with schema S and U, their outer union is a table $t\bigsqcup s$ with schema $S\oplus U$ and containing each record from each table where shared attributes are associated with the same types ($\forall x\in dom\left(S\right)\cap dom\left(U\right).S\left(x\right)=U\left(x\right)$):

$$t\bigsqcup s=\left\{\mathsf{\Gamma }\right|\mathsf{\Gamma }\in t\vee \mathsf{\Gamma }\in s\}$$

(3)

A restriction [13] or projection [41] operation ${\pi }_L\left(t\right)$ over a relational table t with schema S returns a new table ${\pi }_L\left(t\right)$ with schema in ${S|}_L$ where both its schema and its records have a domain restricted to the attributes in L:

$${\pi }_L\left(t\right):=\langle {\mathsf{\Gamma }|}_L\mid \mathsf{\Gamma }\in t\rangle$$

A renaming [41] operation $R_{L\to R}\left(t\right)$ over a relational table t with schema S and $L\subseteq dom\left(S\right)$ replaces all the occurrences of attributes in L with ones in R, thus returning a new table with schema ${S|}_{dom\left(S\right)\setminus L}\oplus \left[(r_i,S\left(l_i\right))\right|\langle l_i,r_i\rangle \in \zeta (L,R)]$:

$$R_{L\to R}\left(t\right)=〈{\mathsf{\Gamma }|}_{dom\left(\mathsf{\Gamma }\right)\setminus L}\oplus \left[(r_i,\mathsf{\Gamma }\left(l_i\right))\right|\langle l_i,r_i\rangle \in \zeta (L,R),l_i\in dom\left(\mathsf{\Gamma }\right)]|\mathsf{\Gamma }\in t〉$$

(4)

A nesting [38] operation ${\nu }_{B\to A}$ over a table t with schema S returns a new table ${\nu }_{B\to A}\left(t\right)$ with schema ${S|}_{dom\left(S\right)\setminus B}\oplus \left[(A,S{|}_B)\right]$, where all the attributes referring to B are nested within the attribute A, which is associated with the type ${S|}_B$ resulting from the nested attributes. Operatively, it coalesces all the tuples in t sharing the same values not in B as a single equivalence class c: we then restrict one representative of this class to the attributes not in B for then extending it by associating to a novel attribute A the projection of c over the attributes in B, i.e., ${\pi }_B\left(c\right)$:

$${\nu }_{B\to A}\left(t\right):=\langle {(minc)|}_{dom\left(S\right)\setminus B}\oplus \left[(A,{\pi }_B\left(c\right))\right]\mid c\in {\displaystyle \raisebox{1ex}{$t$}\!\left/ \!\raisebox{-1ex}{${·|}_{dom\left(S\right)\setminus B}\dot{=}{·|}_{dom\left(S\right)\setminus B}$}\right.}\rangle$$

(5)

A (natural) join [42] between two non-nested tables t and s with schemas S and U, respectively, if $dom\left(S\right)\cap dom\left(U\right)$ then it combines records from both tables that share the same attributes, and otherwise extends each record from the left table with a record coming from the right one (cross product):

$$t\bowtie s=\langle {\mathsf{\Gamma }}_i\oplus {\mathsf{\Gamma }}_j\mid {\mathsf{\Gamma }}_i\in t,{\mathsf{\Gamma }}_j\in s,({\mathsf{\Gamma }}_i\oplus {\mathsf{\Gamma }}_j){{|}_S={\mathsf{\Gamma }}_i,({\mathsf{\Gamma }}_i\oplus {\mathsf{\Gamma }}_j)|}_U={\mathsf{\Gamma }}_j\rangle$$

Given a sequence of attributes $\overrightarrow{L}=\langle L_1\dots L_n\rangle$, this operation can be extended to join the relationship coming from the right at any desired depth level by specifying a suitable path to traverse the nested schema from the left relationship [38]:

$$t{}^{\overrightarrow{L}}\bowtie s=\left\{\begin{array}{cc}t\bowtie s\hfill & \overrightarrow{L}=\varnothing \hfill \\ \langle \tilde{t}{|}_{S\setminus \left\{L_1\right\}},\oplus \left(\tilde{t}\left(L_1\right){}^{\langle L_2,\dots ,L_n\rangle }\bowtie s\right)\mid \tilde{t}\in t\rangle \hfill & \overrightarrow{L}=L_1,L_2,\dots ,L_n\hfill \end{array}\right.$$

(6)

This paper will automate the determination of $\overrightarrow{L}$ given the schemas of the two tables (Section 5). Although it can be shown that the nested relational model can be easily represented in terms of the traditional not-nested relational model [43], this paper uses the nested relational model for compactly representing graph nesting operations over morphisms. Last, the left (outer) join  t s extends the results from $t\bowtie s$ by also adding all the records from t having no matching tuples in s:

(7)

As per SPARQL semantics, the left outer join represents patterns that might optionally appear.

3.2.3. Columnar Physical Model

Columnar physical models offer a fast and efficient way to store and retrieve data where each table ℜ with a schema having a domain $\{\mathtt{id},A_1,\dots ,A_n\}$ is decomposed into distinct binary relations ${\Re }_{A_i}$ with a schema with domain $\{\mathtt{id},A_i\}$ for each attribute $A_i$ in $dom(\Re )$, thus requiring to only refer to one record by its ID while representing data boolean conditions through algebraic operations. As this decomposition guarantees that the full-outer natural join ${\Re }_{A_i}$ of the decomposed tables is equivalent to the initial relation ℜ, we can avoid listing NULL values in each ${\Re }_{A_i}$, thus limiting our space allocation to the values effectively present in our original table ℜ. Another reason for adopting a logical model compatible with this columnar physical model is to keep provenance information [44] while querying and manipulating the data while carrying out data transformations. By exploiting the features of the physical representation, we are no longer required to use the logical model for representing both data and provenance information as per previous attempts for RDF graph data [45], as the columnar physical model allows natively supporting id information for both objects (i.e., vertices) and containments (i.e., edges), thus further extending the RDF model by extensively providing unique ID similarly to what was originally postulated by the EPGM data model for allowing efficient distributed computation [46]. These considerations remark on the generality of our proposed model relying upon this representation.

We now discuss a specific instantiation of this columnar relational model for representing temporal logs: KnoBAB [11]. Although this representation might sound distant from the aim of supporting an Object-Oriented database, Section 4.2 will outline how this might be achieved. KnoBAB stores each temporal log into three distinct types of tables: (i) a CountingTable storing the number of occurrences n of a specific activity label $\mathsf{a}\in \mathsf{\Sigma }$ in a trace ${\sigma }^i\in \mathcal{L}$ as a record $\langle \mathsf{a},i,n\rangle$. Such a table, created in almost linear time while scanning the log, comes at no significant cost at data loading. (ii) An ActivityTable preserving the traces’ temporal information through records $\langle \mathtt{id},\mathsf{a},i,j,p,x\rangle$ asserting that the j-th event ${\sigma }_j^i$ of the i-th log trace ${\sigma }^i$ comes with an activity label a and it is stored as the id-th record of such a table. p (and x) points to the records containing the immediately preceding (and following) event of the trace, thus allowing linear scans of the traces. This is of the uttermost importance as the records are sorted by activity label, trace ID, and event ID for enhancing query run times. (iii) The model also instantiates as many AttributeTable^κ as the keys $\kappa \in K$ in the data payload associated with temporal events, where each record $\langle \mathsf{a},v,\mathtt{id}\rangle$ remarks that the event occurring as the $\mathtt{id}$-th element within the ${\mathrm{ActivityTable}}_{\mathcal{L}}$ table with activity label a associates a key $\kappa$ to a non-NULL value v. This data model also come with primary and secondary indices further enhancing the access to the underlying data model; further details are provided in [11].

At the time of writing, no property graph database exploits such a model for efficiently querying data, in particular, Neo4j v5.20 stores property graphs using a simple data model representation where the whole vertices, relationships, or properties are stored in distinct tables (https://Neo4j.com/developer/kb/understanding-data-on-disk/, accessed on 24 August 2024). This substantially differs from the assumptions of the columnar physical model, prescribing the necessity for decomposing any data representation in multiple different tables, thus making the overall search more efficient by assuming that each data record can be associated with a unique ID. To implement a model under these assumptions, we then require both our logical (Section 4.1) and physical (Section 4.2) model to support explicit identifiers for both objects (acting as graph vertices) and containment relationships (acting as graph edges). Although Neo4j v5.20 guarantees to represent records in fixed-size to fasten up the data retrieval process, this is insufficient to ensure fast access to edges or vertices associated with a specific label. On the other hand, our solution tries to address this limitation by explicitly indexing objects and containments by label information.

Concerning triple stores for RDF data. The only database effectively using column-based storage is Virtuoso v1.1 (https://virtuoso.openlinksw.com/whitepapers/Virtuoso_a_Hybrid_RDBMS_Graph_Column_Store.html, accessed on 24 August 2024): this solution is mainly exploited for fast retrieving the data based on the subject, predicate, and object values. As the underlying physical model does not differentiate between vertices and edges due to the specificity of the logical model requiring that both relationships among vertices (URIs) and properties associated with those must be represented via triples, it is not possible to further optimise the data access by reducing the overall size of the data to be navigated and searched. On the other hand, our proposed physical model (Section 4.2) will store this information into separate tables: the ActivityTable, registering all the objects (and therefore, vertices) being loaded, an AttributeTable^κ storing key-value properties associated with the objects, and a PhiTable^κ for representing the containment relationships (and therefore, edges).

Last, both Virtuoso v1.1 and Neo4j v5.20 do not exploit query caching mechanisms as the ones proposed in [47] for also enhancing the execution of multiple relational queries. This approach, on the other hand, was recently implemented in KnoBAB, thus reinforcing our previous claims for extending such previous implementation to adapt it to a novel logical model. In particular, the Algorithm presented in Section 6.3 partially implements this mechanism for caching intermediate traversal queries that might be shared across patterns to be matched, thus avoiding visiting the same data multiple times for different pattern matching.

4. Generalised Semistructured Model v2.0

We continue the discussion of this paper’s methodology by discussing the logical model (Section 4.1) as a further extension of the Generalised Semistructured Model [34] to explicitly support property-value associations for vertices via $\pi$. Although we propose no property-value extension for containments, we argue that this is minor and does not substantially change the theoretical and implementation results discussed in this paper for Generalised Graph Grammar. We also introduce a novel columnar-oriented physical model (Section 4.2 on the next page) being a direct application of our previous work on temporal databases [11] already supporting collections of databases (log of traces): this will be revised for loading and indexing collection of GSM databases defining our overall physical storage. As the external data to be loaded into the physical model directly represents the logical model, we show that these two representations are isomorphic (Lemma 1) by defining explicitly the loading and serialisation operations (Algorithm from Section 4.2).

As directly updating the physical model with the changes specified in the rewriting steps of the graph grammar rules might require massive restructuring costs, we instead keep track of such changes in a separate non-indexed representation acting as an incremental view to the entire database. We then refer to this additional structure as a GSM view $\Delta \left(g\right)$ for each GSM database g loaded in the physical model (Section 4.3). We then characterise the semantics of $\Delta \left(g\right)$ by defining the updating function for g as a materialisation function considering the incremental changes recorded in $\Delta \left(g\right)$ (Section 4.3.2 on page 19).

Last, as we consider the execution of the rewriting steps for each graph as a transformation of the vertices and edges as referenced within each morphism, modulo the updates tracked in $\Delta \left(g\right)$, it becomes necessary to introduce some preliminary notation for resolving vertex and edge variables from such morphism (Section 4.4).

4.1. Logical Model

The logical model for GSM describes a single object-oriented database g as a tuple $\langle O,\ell ,\xi ,ϵ,\pi ,\varphi ,t_{\varphi }\rangle$, where $O\subseteq \mathbb{N}$ is a collection of objects (references). Each object is associated with a tuple of possible types $\ell \left(o\right)$ and to a tuple of string-representations $\xi \left(o\right)$ providing its human-readable descriptions. As an object might be the result of an automated entity-relationship extraction process, each object is associated with a list of confidence values $ϵ:O\rightharpoonup \wp \left(\mathbb{R}\right)$ describing the trustworthiness of the provided information. Differently from the previous definition [34], we extend the previous model to also associate each object to an explicit property-value association for each object $o\in O$ through a finite function $\pi :O\times {\mathsf{\Sigma }}^{*}\rightharpoonup \mathcal{V}$.

Differently from our previous definition of our GSM model, we express object relationships through uniquely identified vertex containments similar to edges as in  Figure 1a, to explicitly reference such containments in morphism tables similarly to  Figure 1c. We associate each object o with a containment attribute $\kappa$ referring to multiple containment IDs via $\varphi (o,\kappa )\in \wp \left(\mathbb{N}\right)$. An explicit index $t_{\varphi }$ maps each of these IDs to a concrete containment $\langle o_j,w\rangle$ denoting that $o_j$ is contained in o through the containment relationship $\kappa$ with a confidence score of w. This separation between indices and values is necessary to allow the removal of containment values when computing queries efficiently. This also guarantees the correct correspondence between each value $\iota$ in the domain of $t_{\varphi }$ to the label associated with the $\iota$-th containment requiring each $\iota$ will be associated with one solve containment relationship (e.g., ${argmin}_{\kappa \in {\mathsf{\Sigma }}^{*}}\exists j\in g.\iota \in \varphi (j,\kappa )$).

We avoid objects containing themselves at any nesting level by imposing a recursion constraint [6] to be checked at indexing time: this allows both the definition of sound structural aggregations, which can be then conveniently used to represent multi-dimensional data-warehouses [34]. Thus, we freely assume that no object shall store the same containment reference across containment attributes [6]: $\forall o,\kappa .\forall o^{\prime },{\kappa }^{\prime }.\left(\left(o=o^{\prime }\wedge \kappa \ne {\kappa }^{\prime }\right)\vee o\ne o^{\prime }\right)\Rightarrow \varphi (o,\kappa )\cap \varphi (o^{\prime },{\kappa }^{\prime })=\varnothing$. This property can also be adapted to conveniently represent Direct Acyclic Graphs, by representing each vertex $v\in V$ of a weighted property-graph $G=(V,E)$ as a GSM object, and each edge $u\to v\in E$ with weight w and label $\kappa$ reflects a containment $\langle v,w\rangle \in t_{\varphi }\left(\varphi (i,\kappa )\right)$. Given this isomorphism $g\simeq G_g$, we can also apply a layered and reverse topological ordering of the vertices of g and denote it as $O_{\mathsf{rtopo}}\left(g\right)$.

The Python code provided in Appendix A.5 showcases the possibility of instantiating Python objects within the GSM model via the implementation of an adequate transformation function, mapping all native types as $\pi$ key-value properties of a GSM object, while associating the others to $\varphi$ and $t_{\varphi }$ containment relationships (Line 222). Containments also enable the representation of other object-oriented data structures, such as dictionaries/maps (Line 144) and linear data structures (Line 164), thus enabling a direct representation of JSON and nested relational data (Line 53). As per our previous work [9], GSM also supports the representation of XML (Line 117) and property graph data (Line 65). This also achieves the representation aim of EPGM by natively supporting unique identifiers for both vertices and edges, to better operate on those by directly referring to their IDs without the need to necessarily carry out all of its associated payload information [46]. As such, this model leverages all the pros and cons of the previous graph data models by framing them within an object-oriented semistructured model.

4.2. Physical Model

We now describe how the former model can be represented in primary memory for fastening up the matching and rewriting mechanism.

First, we would like to support the loading of multiple GSM databases while being able to operate over them simultaneously similar to the named graphs in the RDF model. Differently from Neo4j v5.20 and similarly to RDF’s named graphs, we ensure a unique and progressive ID across different databases.

We directly exploit our ActivityTable for listing all the objects appearing within each loaded GSM: as such, the id-th record $\langle id,a,g,i,p,x\rangle$ will refer to the i-th object in the g-th GSM database, while a will refer to the first label of ${\ell }_j\left(i\right)$, that is ${\ell }_j\left(i\right)\left[1\right]$.

We extend KnoBAB’s ActivityTable to represent the $\varphi$ containment relationship; the result is a PhiTable^κ for each containment attribute $\kappa$: each record $\langle {\ell }_0,g,o_{\mathtt{src}},w,o_{\mathtt{dst}},\iota \rangle$ refers to a specific GSM database g through which object $o_i$ associated with the first label ${\ell }_0={\ell }_g\left(o_i\right)\left[0\right]$ contains $o_j$ with an uncertainty score of w and is associated with an index $\iota$: this expresses the idea that $\iota \in \varphi (o_{\mathtt{src}},\kappa )$ with $t_{\varphi }\left(\iota \right)=\langle o_{\mathtt{dst}},w\rangle$. At the indexing phase, the table is sorted by lexicographical order over the record’s constituents. We extend this table with two indices: a primary index $P_I^1$ mapping each first occurring ℓ value to the first and the last object within the collection, and a secondary index $P_I^2$ mapping such each database ID g and object ID $o_i$ to a collection of containment records expressing $\mu (t_{\varphi },\varphi (o_i,\kappa ))$ for each $o_i$ and $\kappa$ such that $\varphi (o_i,\kappa )\ne \varnothing$.

We retain the AttributeTable^κ for expressing the properties associated with the GSM vertices, for which we keep the same interpretation from Section 3.2.3 on page 12: thus, each record $\langle \mathsf{a},v,\mathtt{id}\rangle$ refers to $\varphi (o_i,\kappa )=v$ where $o_i$ appears as the id-th record within the ${\mathrm{ActivityTable}}_{\mathcal{L}}$, now used to list all the objects occurring across GSM models.

Last, ℓ and $\xi$ properties are stored in a one-column table and a secondary index mapping each database ID and object ID to a list of records referring to the strings associated with the object ID. The same approach is also used to store the confidence values $ϵ$ associated with each GSM object.

Algorithm 2 shows the algorithms used for loading all of the GSM databases $g_i$ to be loaded of interest to a single columnar database representation $db$, as well as providing the algorithm used to serialize back the stored data into a GSM model for data visualisation and materialisation purposes. Given this, we can easily prove the isomorphism between the two shared data structures, thus also providing proof of the correctness of the two transformations which, as a result, explains the formal characterisation of such an algorithm.

Algorithm 2 Loading a Logical Model into the Physical Model and serialising it back

1: function LoadingAndIndexing($G=\{g_1,\dots ,g_n\}$) 2:     for all $g_i=\langle O_i,{\ell }_i,{\xi }_i,{ϵ}_i,{\pi }_i,{\varphi }_i,t_{i,\varphi }\rangle \in G$ do 3:         for all $j\in O_i$ do 4:            $L_i\left(j\right):={\ell }_i\left(j\right)$; $X_i\left(j\right):={\xi }_i\left(j\right)$; $C_i\left(j\right):={ϵ}_i\left(j\right)$ 5:            ActivityTable.add($\langle \ell \left(j\right)\left[0\right],i,j,\mathtt{NULL},\mathtt{NULL}\rangle$) 6:         end for 7:     end for 8:     Index(ActivityTable)                     ▹ Also sorting the table, [11] 9:     for all $\kappa \in {\mathsf{\Sigma }}^{*},j\in O_i$s.t. ActivityTable [r] = $\langle {\ell }_i\left(j\right)\left[0\right],i,j,p,x\rangle$ do 10:         for all $\iota \in {\varphi }_i(j,\kappa )$ s.t. $t_{i,\varphi }\left(\iota \right)=\langle t,w\rangle$ do 11:            PhiTableκ.add($\langle \ell \left(j\right)\left[0\right),i,j,w,t,\iota \rangle$) 12:         end for 13:         if  ${\pi }_i(j,\kappa )\ne \mathtt{NULL}$ then, AttributeTableκ.add($\langle {\ell }_i\left(j\right)\left[0\right],\pi (j,\kappa ),r\rangle$) 14:     end for 15:     Index(ActivityTableκ, PhiTableκ|$\kappa \in {\mathsf{\Sigma }}^{*}$)                     ▹ As in [11] 16:     return $db:=\langle L,X,C,\mathsf{ActivityTable},\left[(\kappa ,{\mathsf{AttributeTable}}^{\kappa })\right|\kappa \in {\mathsf{\Sigma }}^{*}],\left[(\kappa ,{\mathsf{PhiTable}}^{\kappa })\right|\kappa \in {\mathsf{\Sigma }}^{*}]\rangle$ 17: end function     18: function Serialisation($db$) 19:     $n:={max}_{r\in \mathtt{AttributeTable}}r\left(1\right)$ Determining the maximum number of GSM databases 20:     for all $i:=0$ to n do 21:         $O_i:=\left\{j|\exists l,p,x.\langle l,i,j,p,x\rangle \in \mathsf{ActivityTable}\right\}$ 22:         ${\ell }_i:=\left[(i,L_i\left(j\right))\right|j\in O_i]$; ${\xi }_i:=\left[(i,X_i\left(j\right))\right|j\in O_i]$; ${ϵ}_i:=\left[(i,C_i\left(j\right))\right|j\in O_i]$ 23:         ${\pi }_i:=\left[((j,\kappa ),v)\right|\langle l,v,r\rangle \in {\mathsf{AttributeTable}}^{\kappa },\exists p,x.\langle l,i,j,p,x\rangle \in \mathsf{ActivityTable},\kappa \in {\mathsf{\Sigma }}^{*}]$ 24:         ${\varphi }_i:=\left[((s,\kappa ),\left\{{\iota }^{\prime }\right|\exists l^{\prime },w^{\prime },d^{\prime },\langle l^{\prime },i,j,w^{\prime },d^{\prime },{\iota }^{\prime }\rangle \in {\mathsf{PhiTable}}^k\})\right|\langle l,i,s,w,d,\iota \rangle \in {\mathsf{PhiTable}}^{\kappa }\kappa \in {\mathsf{\Sigma }}^{*}]$ 25:         $t_{i,\varphi }:=(\iota ,\{d,w\})\left|\langle l,i,s,w,d,\iota \rangle \in {\mathsf{PhiTable}}^{\kappa },\kappa \in {\mathsf{\Sigma }}^{*}\right]$ 26:         yield $\langle O_i,{\ell }_i,{\xi }_i,{ϵ}_i,{\pi }_i,{\varphi }_i,t_{i,\varphi }\rangle$ 27:     end for 28: end function

Lemma 1. 

A collection of logical model GSM databases ${\langle g_i\rangle }_{i\le n}$ is isomorphic to the ones loaded and indexed physical model.

The proof is given in Appendix B.1. We refer to Section 8 for proofs related to the time complexity for loading, indexing, and serialising operations.

4.3. GSM View $\Delta \left(g\right)$

To avoid massive restructuring costs while updating the information indexed in the physical model, we use a direct extension of the logical model to keep track of which objects were newly generated, removed, or updated during the application of the rule rewriting mechanisms. At query time, we instantiate a view $\Delta \left(g_i\right)$ for each $g_i$ being loaded within the physical model (Section 6.5). We want our view to support the following operations: (i) creation of new objects, (ii) update of the type/labelling information ℓ, (iii) updating the human-readable value characterisation $\xi$, (iv) update of the containment values, (v) removal of specific objects, and  (vi) substitution of previously matched vertices with newly-created or other previously matched ones. While we are not explicitly supporting the removal of specific properties or values, these can be easily simulated by setting specific fields to empty strings or values. A view for $g_i$ is defined as follows:

$$\Delta \left(g_i\right)=\langle g_i^{\Delta },{\mathsf{\Gamma }}_i,{\mathsf{\Gamma }}_i^v,O_i^{+},O_i^{-},E_i^{-},{\rho }_i\rangle$$

(8)

where $g_i^{\Delta }=\langle O_i^{\Delta },{\ell }_i^{\Delta },{\xi }_i^{\Delta },{ϵ}_i^{\Delta },{\pi }_i^{\Delta },{\varphi }_i^{\Delta },t_{\varphi ,i}^{\Delta }\rangle$ is a GSM database holding all the objects being newly inserted alongside with the properties as well as the updated properties for the objects within the graph g (i–iv), $\mathsf{\Gamma }$ refers to the nested morphism being considered while evaluating the query, ${\mathsf{\Gamma }}^v$ denotes the extension of such morphism with the newly inserted objects through variable declaration, which resulting objects are then collected in $O^{+}$ (i). $O^{-}$ (and $E^{-}$) tracks all the removed objects (and specific containment objects, resp.) through their ID (v). Last, $\rho$ is a replacement map ${⨁}_i\left[(o_i,o_{\alpha \left(i\right)})\right]$ to be used when evaluating the transformations over morphisms occurring at a higher topological sort layer, stating to refer to an object $o_{\alpha \left(i\right)}$ when $o_i$ occurs (vi). ${\mathsf{\Gamma }}^v$ and $O^{+}$ are used to retain the updated information locally to each evaluated morphism, while the rest are shared across the evaluation of each distinct morphism.

We equip $\Delta \left(g\right)$ with update operations reflecting the insertion, deletion, update, and replacement operations as per rewriting semantics associated with each graph grammar production rule. Such operations are the following:

Start: 

re-initialises the view to evaluating a new morphism ${\mathsf{\Gamma }}^{\prime }$ by discarding any information being local to each specific morphism:

$${\mathrm{S}\mathrm{TART}}_{\Delta \left(g\right)}\left({\mathsf{\Gamma }}^{\prime }\right)=\langle g^{\Delta },{\mathsf{\Gamma }}^{\prime },\varnothing ,\varnothing ,O^{-},E^{-},\rho \rangle$$

(9)

DelCont: 

We remove the i-th containment relationship from the database:

$${\mathrm{D}\mathrm{EL}\mathrm{C}\mathrm{ONT}}_{\Delta \left(g\right)}\left(i\right):=\langle g^{\Delta },\mathsf{\Gamma },{\mathsf{\Gamma }}^v,O^{+},O^{-},E^{-}\cup \left\{i\right\},\rho \rangle$$

NewObj: 

Generates a new empty object associated with a variable j and with a new unique object ID $\left|g\right|+|g^{\Delta }|+1$:

$$\begin{array}{cc}\hfill {\mathrm{N}\mathrm{EW}\mathrm{O}\mathrm{BJ}}_{\Delta \left(g\right)}\left(j\right):=& \mathbf{let}\mathtt{fresh}:=\left|g\right|+|g^{\Delta }|+1\mathbf{in}\hfill \\ & \langle g^{\Delta },\mathsf{\Gamma },{\mathrm{P}\mathrm{UT}}_{{\mathsf{\Gamma }}^v}\left(j,{\mathsf{\Gamma }}^v\left(j\right)\cup \left\{\mathtt{fresh}\right\}\right),O^{+}\cup \left\{\mathtt{fresh}\right\},O^{-},E^{-},\rho \rangle \hfill \end{array}$$

ReplObj: 

replaces $o_i$ with $o_j$ if and only if $o_j$ was not removed ($o_j\notin O^{-}$):

$${\mathrm{R}\mathrm{EPL}\mathrm{O}\mathrm{BJ}}_{\Delta \left(g\right)}\left((o_i,o_j)\right):=\left\{\begin{array}{cc}\Delta \left(g\right)\hfill & o_j\in O^{-}\hfill \\ \langle g^{\Delta },\mathsf{\Gamma },{\mathsf{\Gamma }}^v,O^{+},O^{-},E^{-},\rho \circ \left[(o_i,o_j)\right]\rangle \hfill & \mathrm{oth}.\hfill \end{array}\right.$$

DelObj: 

We remove an object $o_i$ only if this was already in g or if this was inserted in a previous evaluation of a morphism and, within the evaluation of the current morphism, we remove the original object $o_i$ being replaced by $\tilde{o}=\rho \left(o_i\right)$:

$$\begin{array}{cc}\hfill {\mathrm{D}\mathrm{EL}\mathrm{O}\mathrm{BJ}}_{\Delta \left(g\right)}\left(o_i\right):=& \mathbf{let}\tilde{o}:={\mathrm{O}\mathrm{PT}\mathrm{G}\mathrm{ET}}_{\rho }\left(o_i\right)\mathbf{in}\hfill \\ & \left\{\begin{array}{cc}\langle g^{\Delta },{\mathsf{\Gamma }}^{\prime },\varnothing ,O^{+},O^{-}\cup \left\{o_i\right\},E^{-},\rho \rangle \hfill & \tilde{o}\in O^{+}\hfill \\ \langle g^{\Delta },{\mathsf{\Gamma }}^{\prime },\varnothing ,O^{+},O^{-}\cup \left\{\tilde{o}\right\},E^{-},\rho \rangle \hfill & \mathrm{oth}.\hfill \end{array}\right.\hfill \end{array}$$

Update: 

updates one of the object property functions by specifying which of those should be updated. In other words, this is the extension of Put² (Equation (2)) as a higher function for updating the view alongside one of these components:

$${\mathrm{U}\mathrm{PDATE}}_{\Delta \left(g_i\right)}^f(\langle i,j\rangle ,u):=\left\{\begin{array}{cc}\langle O_i^{\Delta },Pu{t}_{{\ell }_i^{\Delta }}^2(\langle i,j\rangle ,u),{\xi }_i^{\Delta },{ϵ}_i^{\Delta },{\pi }_i^{\Delta },{\varphi }_i^{\Delta },t_{\varphi ,i}^{\Delta }\rangle \hfill & f\equiv \ell \hfill \\ \langle O_i^{\Delta },{\ell }_i^{\Delta },{\mathrm{P}\mathrm{UT}}_{{\xi }_i^{\Delta }}^2(\langle i,j\rangle ,u),{ϵ}_i^{\Delta },{\pi }_i^{\Delta },{\varphi }_i^{\Delta },t_{\varphi ,i}^{\Delta }\rangle \hfill & f\equiv \xi \hfill \\ \langle O_i^{\Delta },{\ell }_i^{\Delta },{\xi }_i^{\Delta },{ϵ}_i^{\Delta },Pu{t}_{{\pi }_i^{\Delta }}(\langle i,j\rangle ,u),{\varphi }_i^{\Delta },t_{\varphi ,i}^{\Delta }\rangle \hfill & f\equiv \pi \hfill \\ \mathbf{let}n:=|dom(t_{i,\varphi }^{\Delta }\left)\right|\mathbf{in}\hfill & f\equiv \varphi \hfill \\ \mathbf{let}\tilde{\varphi }:=Pu{t}_{{\varphi }_i^{\Delta }}(\langle i,j\rangle ,\{n,\dots ,n+\left|u\right|\left\}\right)\mathbf{in}\hfill & \\ \mathbf{let}\tilde{t}:=t_{\varphi ,i}^{\Delta }\oplus \underset{0\le j<\left|u\right|}{⨁}\left[(j+n,u\left(j\right))\right]\mathbf{in}\hfill & \\ \langle O_i^{\Delta },{\ell }_i^{\Delta },{\xi }_i^{\Delta },{ϵ}_i^{\Delta },{\pi }_i^{\Delta },\tilde{\varphi },\tilde{t}\rangle \hfill \end{array}\right.$$

Concerning the time complexity, we can easily see that all operations take $O\left(1\right)$ time to compute by assuming efficient hash-based sets and dictionaries. Concerning ${\mathrm{U}\mathrm{PDATE}}^{\varphi }$, this operation takes $O\left(1\right)$ time, as we are merely inserting one pair at a time.

4.3.1. Object Replacement and Resolution

As our query language will have variables to be resolved via matched morphisms and view updates (Appendix A.1), we focus on specific variable resolution operations. Replacement operations should be interpreted as a reflexive and transitive closure over the step-wise replacement operations performed while running the rewriting query (Section 6.5 on page 33).

Definition 4 

(Active Replacement). The active replacement function resolves any object ID x into its final replacement vertex following the chain of subsequent unique substitutions of each single vertex in ρ, or otherwise returns x:

$${\rho }_{\Delta \left(g\right)}^{\star }\left(x\right):=\left\{\begin{array}{cc}{\rho }^n\left(x\right)\hfill & n^{\prime }=arg\underset{n\in \mathbb{N}}{max}.x\in dom\left({\rho }^n\right)\wedge {\rho }^n\left(x\right)\ne {\rho }^{n+1}\left(x\right)\hfill \\ x\hfill & \mathrm{oth}.\hfill \end{array}\right.$$

During an evaluation of a morphism to be rewritten, such replacements and changes should be effective from the next morphism while we would like to preserve the original information while evaluating the current morphism.

Definition 5 

(Local Replacament). The local replacement function blocks any notion of replacement while evaluating the original data matched by the current morphism while activating the changes from the evaluation of any subsequent morphism where such newly-created vertices from the current morphism will not be considered:

$$\downarrow {\rho }_{\Delta \left(g\right)}\left(x\right):=\left\{\begin{array}{cc}{\rho }^{\star }\left(x\right)\hfill & {\rho }^{\star }\left(x\right)\notin O^{+}\hfill \\ x\hfill & \mathrm{oth}.\hfill \end{array}\right.$$

We consider objects as removed if they have no effective replacements to be enacted in any subsequent morphism evaluation: $x\in dom\left(\rho \right)\wedge x\in O^{-}$. Thus, we also need to resolve objects’ properties (such as ℓ, $\xi$, $\pi$, and $\varphi$) by considering the changes registered in $\Delta \left(g_i\right)$. We want to define a HOF property extraction that is independent of the specific function of choice. By exploiting the notion of local replacement (Definition 5), we obtain the following definition:

Definition 6 

(Property Resolution). Given any property access function $\ell ,\xi ,\varphi ,\pi$, a GSM database $g_i$ and a corresponding view $\Delta \left(g_i\right)$ we define the following property resolution high-order function:

$$\downarrow {\rho }_{\Delta \left(g\right)}^f\left(o\right)=\left\{\begin{array}{cc}\varnothing \hfill & \downarrow {\rho }_{\Delta \left(g\right)}\left(o\right)\in O_i^{-}\hfill \\ f_{\Delta \left(g_i\right)}(\downarrow {\rho }_{\Delta \left(g\right)}\left(o\right))\hfill & \downarrow {\rho }_{\Delta \left(g\right)}\left(o\right)\in O_i^{\Delta }\wedge f_{\Delta \left(g_i\right)}(\downarrow {\rho }_{\Delta \left(g\right)}\left(o\right))\ne \varnothing \hfill \\ f_{g_i}(\downarrow {\rho }_{g_i}\left(o\right))\hfill & \mathrm{oth}.\hfill \end{array}\right.$$

where we ignore any value associated with a removed vertex in $O_i^{-}$ (first case), we consider any value stored in $\Delta \left(g_i\right)$ as overriding any other value originally in the loaded graph (second case), while returning the original value if the object underwent no updates (last case).

4.3.2. View Materialisation

Last, we define a materialisation function as a function updating a GSM database $g_i$ with the updates stored in the incremental view $\Delta \left(g_i\right)$. We consider all the objects being inserted (implicitly associated with a $1.0$$\epsilon$ score) and removed, as well as extending all the properties as per the view, thus removing containment relationships originating from or arriving at GSM objects.

$$\begin{array}{cc}\hfill {\mathrm{MATERIALISE}}^{\prime }(g_i,\Delta \left(g_i\right))=& \langle O_i\cup O_i^{+}\setminus O_i^{-},\hfill \\ & \ell \oplus {\ell }_i^{\Delta },\hfill \\ & \xi \oplus {\xi }_i^{\Delta },\hfill \\ & ϵ\oplus \left(\underset{o\in O_i^{\Delta }\setminus O_i^{-}}{⨁}\left[(o,1.0)\right]\right),\hfill \\ & \pi \oplus {\pi }_i^{\Delta },\hfill \\ & \underset{\langle p,k\rangle \in dom\left(\varphi \right)}{⨁}\left[(\langle p,k\rangle ,\mathsf{ϝ}(y\mapsto y\notin E_i^{-},\varphi (p,k)))\right]\oplus {\varphi }_i^{\Delta },\hfill \\ & (t_{\varphi }\oplus t_{\varphi ,i}^{\Delta })\rangle \hfill \end{array}$$

As a rewriting mechanism might add edges violating the recursion constraint, we prune the containments loading to its violation by adopting the following heuristic: after approximating the topological sort by prioritising the object ID, we remove all the containments generating a cycle where the contained object has an ID with a lower value than its container ID. From this definition, we then derive the definition of the update of all the GSM databases loaded in the physical model G with their corresponding updates in $\Delta$ via the following expression:

$$\mathrm{MATERIALISE}(G,\Delta )=\mu ({\mathrm{MATERIALISE}}^{\prime },\zeta (G,\Delta ))$$

(10)

4.4. Morphism Notation

We consider nested relationships mapping attributes to either basic data types or to not nested schemas, as our query language will syntactically avoid the possibility of arbitrary nesting depths. Given this, any attribute $A_i$ can nest at a maximum level 1 of depth. This will then motivate a similar requirement for the envisioned operator for composing matched containments (collected in relational tables) into nested morphisms (Section 5).

As our query language requires resolving variables by associating each variable $A_i$ to the values stored in a specific morphism $\mathsf{\Gamma }$, we need a dedicated function enabling this. We can define a value extraction function for each morphism $\mathsf{\Gamma }$ and attribute $A_i\in dom\left(\mathsf{\Gamma }\right)$, returning directly the value associated with $A_i$ in $\mathsf{\Gamma }$ if $A_i$ directly appears in the schema of $\mathsf{\Gamma }$ ($dom\left(\mathsf{\Gamma }\right)$), and otherwise returns the list of all the possible values associated with it within a nested relationship $A_j$ having $A_i$ in its domain:

$${\mathrm{I}\mathrm{DX}}_{\mathsf{\Gamma }}\left(A_i\right):=\mathbf{let}S:=S\left(\mathsf{\Gamma }\right)\mathbf{in}\left\{\begin{array}{cc}\langle \mathsf{\Gamma }\left(A_i\right)\rangle \hfill & S\left(A_i\right)\in \mathcal{B}\hfill \\ \langle {\gamma }_i\left(A_i\right)|{\gamma }_i\in \mathsf{\Gamma }\left(A_j\right)\rangle \hfill & \exists !A_j.A_i\in dom\left(S\left(A_j\right)\right)\hfill \\ \varnothing \hfill & \mathrm{oth}.\hfill \end{array}\right.$$

(11)

When resolving a variable, we need to determine whether this refers to a containment or to an object, thus selecting to remove the most appropriate type of constituent indicated within a morphism. So, we can define a function similar to the former for extracting the basic datatypes associated with a given attribute:

$${\mathrm{TI}\mathrm{DX}}_{\mathsf{\Gamma }}\left(A_i\right):=\mathbf{let}S:=S\left(\mathsf{\Gamma }\right)\mathbf{in}\left\{\begin{array}{cc}S\left(A_i\right)\hfill & S\left(A_i\right)\in \mathcal{B}\hfill \\ \left(S\left(A_j\right)\right)\left(A_i\right)\hfill & \exists !A_j.A_i\in dom\left(S\left(A_j\right)\right)\wedge S\left(A_j\right)\left(A_i\right)\in \mathcal{B}\hfill \\ \varnothing \hfill & \mathrm{oth}.\hfill \end{array}\right.$$

(12)

We also need a function determining the occurrence of an attribute x nested in one of the attributes of S. This will be used for both automating the discovery of the path $\overrightarrow{L}$ for joining nested tables from our recently designed operator (Section 5) or for determining whether two variables belong to the same nested cell of the morphism while updating the GSM view. This boils down to defining a function returning $A_j$ if $A_i$ is an attribute of a table nested in $A_j$, and NULL otherwise.

$${\mathrm{I}\mathrm{D}\mathrm{N}\mathrm{EST}}_S\left(A_i\right):={argmin}_{\begin{array}{c}{A}_j\in dom\left(S\right)\\ \mathrm{s}.\mathrm{t}.S\left(A_j\right)\ne \mathcal{B}\end{array}}{A}_i\in dom\left(S\left(A_j\right)\right)$$

(13)

Last, we need a function for returning all the object and containment IDs under the circumstance that these contribute to the satisfaction of a boolean expression. We then define such a function returning such IDs at any level of depth of a nested morphism:

$$SE\left(\mathsf{\Gamma }\right)=\mathbf{let}S=\mathcal{S}\left(\mathsf{\Gamma }\right)\mathbf{in}\{x\in dom\left(\mathsf{\Gamma }\right)|S\left(x\right)\in \mathcal{B}\}\cup \bigcup _{x\in dom\left(S\right),S\left(x\right)\notin \mathcal{B}}SE\left(\mathsf{\Gamma }\left(x\right)\right)$$

(14)

5. Nested Natural Equi-Join

Although previous literature defines nested natural join, no known algorithmic implementation is available. As our query language will return nested morphisms by gradually composing intermediate tables through natural or left joins is, therefore, important to provide an implementation for such an operator. This will be required to combine tables derived from the containment matching (Section 6.3) into nested morphisms, where it is required to join via attributes appearing within nested tables (Section 6.4). Our lemmas show the necessity of this operator by demonstrating the impossibility of expressing it via Equation (6) directly, while capturing the desired features for generating nested morphisms.

We propose for the first time Algorithm 3 for computing the nested (left outer) equi-join with a path $\overrightarrow{L}$ of depth at most 1. The only parameter provided to the algorithm is whether we want a left outer equi-join or a natural one otherwise (isLeft) and, given that the determination of the nesting path will depend on the schema of both the left and right operand, we automate (Line 9) the determination of the $\overrightarrow{L}=\langle N\rangle$ path along which compute the nested join for which, we freely assume that we navigate on the nested schema of the left operand similarly to Equation (6): this assumption comes from our practical use case scenario that we are gradually composing the morphisms provided as a left operand argument with the containment relationships provided as the right operand. Furthermore, to apply the definition from Equation (6) while automating the discovery of the path to navigate to nest the relationship, we require that each attribute appearing from the right table schema might appear as nested in one single attribute from the left table or, otherwise, we cannot automatically determine which left attribute to choose to nest the graph visit (Line 8). Otherwise, we determine a unique attribute from the left table alongside which apply the path descent (Line 9).

Algorithm 3 Nested Natural Equi-Join

1: function ${\mathrm{N}\mathrm{ESTED}\mathrm{N}\mathrm{ATURAL}\mathrm{E}\mathrm{QUIJOIN}}_{\mathtt{isLeft}}$($L,R$) 2:     $S_L:=S\left(L\right)$; $S_R:=S\left(R\right)$ 3:     $\mathit{IR}:=\left(dom\left(S_L\right)\setminus \{x\in dom\left(S_L\right)|S_L\left(x\right)\notin \mathcal{B}\}\right)\cap dom\left(S_R\right)$ 4:     if  $\mathit{IR}=\varnothing$ then  return $L\times R$                 ▹ Cross Product 5:     if $\bigcup \{dom\left(A_i\right)|A_i\in dom\left(S_L\right)\wedge S_L\left(A_i\right)\notin \mathcal{B}\}\cap dom\left(S_R\right)=\varnothing$ then 6:         if  isLeft then  return  L R else  return $L\bowtie R$ 7:     end if     8:     assert $\left|{\bigcup }_{x\in dom\left(S_R\right)}{\mathrm{I}\mathrm{D}\mathrm{N}\mathrm{EST}}_{S_L}\left(x\right)\right|=1$               ▹ Equation (13) 9:     $N:=min{\bigcup }_{x\in dom\left(S_R\right)}{\mathrm{I}\mathrm{D}\mathrm{N}\mathrm{EST}}_{S_L}\left(x\right)$ 10:     $LM:={⨁}_{c\in {\displaystyle \raisebox{1ex}{$L$}\!\left/ \!\raisebox{-1ex}{${\dot{=}}_{IR}$}\right.}}\left[(c\left(IR\right),{\pi }_{S_L\setminus IR}\left(c\right))\right]$ 11:     $RM:={⨁}_{c\in {\displaystyle \raisebox{1ex}{$R$}\!\left/ \!\raisebox{-1ex}{${\dot{=}}_{IR}$}\right.}}\left[(c\left(IR\right),{\pi }_{S_R\setminus IR}\left(c\right))\right]$ 12:     for all $k\in dom\left(LM\right)\cup dom\left(RM\right)$ do 13:         if $k\notin dom\left(RM\right)$ and isLeft then 14:            for  $y\in LM\left(k\right)$ yield $k\oplus y$ 15:         else if $k\in dom\left(LM\right)$ then 16:            for all $y\in LM\left(k\right),z\in RM\left(k\right)$ do 17:                $y^{\prime }:=$copyof y 18:                $y^{\prime }\left(N\right):=$ if  isLeft then  return $y^{\prime }\left(N\right)$ Z else  return $y^{\prime }\left(N\right)\bowtie z$ 19:                yield $k\oplus y^{\prime }$ 20:            end for 21:         end if 22:     end for 23: end function

The algorithm also takes into account whether no nesting path $\overrightarrow{L}=\langle N\rangle$ is derivable, thus resorting to traditional relational algebra operations: if there are no shared attributes, we boil down to the execution of a cross product (Line 4) and, if  none of the attributes from the right table appear within a nested attribute from the left table, then we boil down to a classical left-outer or natural equijoin depending on the isLeft parameter (Line 6).

Otherwise, we know that some attributes from the right table appear as nested within the same attribute N of the left table and that the two tables share the same non-nested attributes. Then, we initialize the join across the two tables by first identifying the nested attribute N from the left (Line 9). Given $\mathit{IR}$, the attributes appearing as nonnested attributes from the left table also appear in the right one, we partition the tables by ${\dot{=}}_{\mathit{IR}}$, thus identifying the records having the same values for the same attributes in $\mathit{IR}$ (Lines 10–11). Then, we start producing the results for the nested join by iterating over the values k appearing in either of the two tables (Line 12): if k appears only over the left table and we want to compute a left nested join (Line 13), we reconstruct the original rows appearing from such table and return them (Line 14). Last, we only consider values k for IR appearing on both tables and, for each row y from the left table having values in k, we compute the left (or natural equi-)join of $y\left(N\right)$ with each row z from the right table and combine the results with k (Line 18).

Properties

We prove that ${}^{\overrightarrow{L}}\bowtie$ cannot trivially boil down to ⋈ unless $\overrightarrow{L}=\varnothing$; otherwise, if $A_i$ is in $\overrightarrow{L}$ not appearing as an attribute for the to-be-joined table schemas, we will be left out with the left table and not a classic un-nested natural join. Proofs are postponed to Appendix B.2.

Lemma 2. 

Given $S\left(t\right)=S$ and $\overrightarrow{L}=\langle A_1,A_2,\dots ,A_n\rangle$, if $A_1\notin dom\left(S\right)$, then $t{}^{\overrightarrow{L}}\bowtie s=t$

As this is not a desired feature for an operator whose application should be automated, this justifies the need for a novel nested algebra operator for composing nested morphisms, which should shift to left joins [37] for composing optional patterns provided within the right operand (isLeft), while also backtracking to natural joins or cross products if no nested attribute is shared across matched containments. The following lemma discards the possibility of the aforementioned limitation to occur from our operator, by instead capturing the notion of cross-products when tables are not sharing non-nested attributes.

Lemma 3. 

Given tables L and R, respectively, with schema S and U with non-shared attributes ($dom\left(S\right)\cap dom\left(U\right)=\varnothing$), either  NestedNaturalEquijoin_False($L,R$) or NestedNaturalEquijoin_True($L,R$) compute $L\times R$.

We also demonstrate that the proposed operator falls back to the natural join when no attribute nested in the left operand appears in the right one, while also capturing the notion of left join by changing the isLeft

Lemma 4. 

Given tables L and R, respectively, with schema S and U where no nested attribute appearing in the left table appears in the schema of the second, thenNestedNaturalEquijoin_false($L,R$)$=L\bowtie R$ andNestedNaturalEquijoin_true($L,R$)$=L$R.

The next lemma observes that our proposed operator not only nests the computation of the join operator within a table, but also implements an equijoin doing a value match across the table fields that are shared within the shallowest level. This is a desideratum to guarantee the composition of nested morphisms within the same GSM database ID, thus requiring sharing at least the same dbid field (Section 6.3). Still, these operations cannot be expressed through the nested join operator available from the current literature (Equation (6)).

Lemma 5. 

Given tables L and R, respectively, with schema S and U, that is $S\left(L\right)=S$ and $S\left(R\right)=U$, where the left table has a column N ( $N\in dom\left(S\right)$) being nested ($S\left(N\right)\notin \mathcal{B}$) and also appearing in the right table ($N\in dom\left(U\right)$), NestedNaturalEquijoin_false($L,R$) cannot be expressed in terms of $L{}^{\langle N\rangle }\bowtie R$ for $N\in dom\left(S\right)\cap dom\left(U\right)$, $N\in dom\left(S\right(N\left)\right)$, and $dom\left(S\right(N\left)\right)\cap dom\left(U\right)\ne \varnothing$.

6. Generalised Graph Grammar

After a preliminary and example-driven representation of the proposed query language (Section 6.1), we characterise the semantics of the proposed query language in terms of procedural semantics being subsumed in Algorithm 4. This is defined by the following phases: after determining the order of application of the matching and rewriting rules (Line 2), we match and cache the traversal of each containment relationship to reduce the number of accesses to the physical model (Line 3), from which we then proceed to the instantiation of the morphisms, to produce the $MT[·,·]$ table (Line 4). This fulfills the matching phase. Finally, by visiting the objects from each GSM database in reverse topological order, we then access each morphism stored in $MT[·,·]$ for then applying (Line 5) the rewriting rules according to the sorting in Line 2. As this last phase produces the views for each $g_i$ GSM database we then materialise this view and store the resulting logical model on disk (Line 6). Each of the forthcoming sections discusses each of the aforementioned phases.

Algorithm 4 Generalised Graph Grammar (gg) evaluation

1: function GeneralisedGraphGrammars(gg, $G=\{g_1,\dots ,g_n\}$)     ▹$G\simeq db$ (Lemma 1) 2:     SortRules(gg)                          ▹ Algorithm 5 3:     CacheIntermediateResults(gg, $db$)                 ▹ Algorithm 6 4:     InstantiateMorphisms(gg, $db$)                   ▹ Algorithm 7 5:     $\Delta :=$GenerateGraphViews(gg, G)                  ▹ Algorithm 8 6:     return materialise($G,\Delta$)                    ▹ Equation (10) 7: end function

6.1. Syntax and Informal Semantics

We now discuss our novel’s proposed matching and rewriting language by taking inspiration from graph grammar. To achieve language declarativeness, we do not force the user to specify the order of application of the rules as in graph rewriting.

Figure 4 provides the Backus-Naur Form (BNF) [48] for the proposed query language for matching and rewriting object-oriented databases by extending the original definition of graph grammars. Each query (gg) is a list of semi-colon-separated rules (rule), where each of those describes a matching and rewriting rule, $L_i{\to }_{\Theta }{R}_i$. For each uniquely identified rule (pt), we identify a match $L_i$ (obj cont+joining*) and an optional (?) rewrite $R_i$ (op*obj). Those are separated by an optional condition predicate $\Theta$ (Appendix A.2 on page 43), providing the conditions upon which the rewriting needs to be applied to the database view, and  ↪.

$L_i$ is characterised by one single entry-point similarly to GraphQL [49] as well as other navigational approaches to visiting graph-based data [50], thus defining the main GSM object through which we relativise the graphs’ structural changes or update around its neighbouring vertices, as defined by its ego-network cont of objects being either contained (- - clabel -> obj) or containing (<- clabel - - obj) the entry-point obj. While objects should be always referred to through variables, containment relationships might be optionally referred to through a variable. Edge traversal beyond the ego-net is expressed through additional edges (joining). We require that at least one of the edges should be a mandatory one. Differently from Cypher, we can match containments by providing more possible alternatives for the containment label rather than just considering one single alternative: this acts as the SPARQL’s union operator across differently matched edges, each for a distinct edge label. Please observe that this boils down to a potentially polynomial sub-problem of the usual subgraph isomorphism problem, being still in NP despite the results in Section 8 proposed for the present query language.

Up to this point, all these features are shared with graph query languages. We now start discussing features extending those: we generate nested embeddings by structurally grouping entry-point matches sharing the same containing vertex: this is achieved by specifying the need to group an object (≫) along one of its containment vertices via a containment relationship remarked with ∀. Last, we use return statements in the rewritings to specify which entry-point objects should be replaced by any other matched or newly created objects.

Example 1. 

Listing 1 expresses the graph grammar rules from  Figure 2 in our proposed language with minor extensions: we achieve declarativeness when associating multiple string values coming from nested vertices (and therefore, associated with a single variable) to one single vertex, as strings will be normally space-joined (Line 12) with a syntax equivalent to setting such properties where no nestings are in a morphism (Line 2). A return statement at Line 22 guarantees that, while considering matching a GSM database from  Figure 3a, objects 2 and 3 for Alice and Bob in X will be replaced by the newly instantiated “Alice Bob” object h when considering the subsequent creation of the edge “plays” (Line 31). This remarks the need for visiting the GSM database in topological order to minimise the rewriting costs when the updates are applied. This is also guaranteed by the matching assumption only considering objects within the entry-point’s ego-net, as we ensure to pass on the information by layers via return statements.  Figure 5a shows the result of this rewrite.

Figure 4. Proposed language for Graph Grammars over the GSM expressed in ANTLR4-flavoured BNF notation [51]. Terminal symbols are expressed in green. $script$ refers to a double-quoted string representing a program in the Script v2.0 language [34]. Similarly to Regular Expression syntax [48], ? refer to optional sub-expressions, + (or *) indicate one (or zero) or more occurrences of a given sub-expression.

Figure 4. Proposed language for Graph Grammars over the GSM expressed in ANTLR4-flavoured BNF notation [51]. Terminal symbols are expressed in green. $script$ refers to a double-quoted string representing a program in the Script v2.0 language [34]. Similarly to Regular Expression syntax [48], ? refer to optional sub-expressions, + (or *) indicate one (or zero) or more occurrences of a given sub-expression.

Figure 5. Applying the rewriting rules expressed in  Figure 2 to the graph originally presented in  Figure 3a: different colours refer to different matching rules. Filled vertices in the left (and right) graph refer to the distinct vertex entry-points (and newly generated components), while uparrows ↑ are used to differentiate containment IDs from the ones for the objects. (a) Generating a binary relationship between the subject as a single entity and the direct object. (b) Morphisms $M[p_3,g_0]$. (c) Morphisms $M[p_2,g_0]$, where * refers to sub-matches nested over the entry point (See Algorithm from Section 6.4).

Figure 5. Applying the rewriting rules expressed in  Figure 2 to the graph originally presented in  Figure 3a: different colours refer to different matching rules. Filled vertices in the left (and right) graph refer to the distinct vertex entry-points (and newly generated components), while uparrows ↑ are used to differentiate containment IDs from the ones for the objects. (a) Generating a binary relationship between the subject as a single entity and the direct object. (b) Morphisms $M[p_3,g_0]$. (c) Morphisms $M[p_2,g_0]$, where * refers to sub-matches nested over the entry point (See Algorithm from Section 6.4).

Listing 1. 

Expressing the graph grammar rules represented visually in Figure 2 in our proposed language (file: paper_simple.txt).

When grouping entry-points, we require those to be grouped over one same containing object, to  unambiguously refer the nested entry-points to one single morphism. This allows the query language to coalesce morphisms.

Example 2. 

The usefulness of a nested morphism representation can be promptly shown with the example in Figure 5 while focusing on the morphism tables referring to the matching of the subject-verb.object structure of a sentence (Figure 5b). Each morphism can contain two distinct nested relationships, one referring to the subject (S) and one to the object (Z). The possibility of representing such values in a nested morphism allows us to better group vertices to be considered while referring to those with the same variable while keeping unique entry-point instances.

Example 3. 

With reference to the morphism resulting from matching (con-)/dis-junctions with a sentence (Figure 5c), entry-point grouping allows the creation of one single vertex matching as a single subject for the sentence, thus ensuring the creation of one final single vertex per group of matched entry-points.

We also show how the language allows us to break the declarativeness assumption when we want to specifically compose values according to a specific value composition function:

Example 4. 

The user is free to break this declarative assumption by directly specifying the order of combination when it is required to combine the values from different variables. This can be observed in a longer query considering more morphosyntactic language features, which is provided online (https://github.com/datagram-db/datagram-db/blob/v2.0/data/test/einstein/einstein_query.txt, accessed on 18 July 2024). This can be used to fully rewrite the database as per Figure 6. As the creation of the will-not-have containment in this will require combining values from vertices 3, 8, and 9 and, respectively, associated with variables V,A, and N, we can use a scripting language as a direct extension of Script v2.0 [34] for determining the order of strings’ composition. Please observe that this formulation, contrary to Neo4j’s APOC in v5.20, also supports optional object matches, where the values associated with non-existingNULLobjects are resolved into empty strings (see Proof for Lemma 7 in Appendix B.3).

By explicitly expressing a containment relationship across the nested entry-point X via so-called hook containments defining equivalence classes, we split the nested morphism $\mathsf{\Gamma }$ into as many new morphisms as the equivalence classes in ${\displaystyle \frac{{\mathsf{Idx}}_{\mathsf{\Gamma }}\left(X\right)}{\Re }}$ (see Section 6.3).

Example 5. 

We appreciate the usefulness of such morphism splitting while looking at a more convoluted example, as the one considering the rewriting in the sentence depicted in Figure 6a: vertices Matt and Trayand play and havefrom conjunctions but at different branches of the sentence structure. Furthermore, all four constituent vertices have the same containing vertex believe for which, if no hook relationship was considered, they would have been added within the same morphism as per the previous example.

Still, given that those vertices are associated with different conjas they appear in different coordinating conjunctions, we can use this as a hook relationship to distinguish those, for then obtaining two separate morphisms as illustrated by the first two rows in Figure 7b. Thus, hooks help in splitting nested entry-points structurally by identifying similar elements through structural information.

Last, these examples provide an intuitive motivation for why the matching within our query language can express distances of at most one containment relationship from the entry-point match. We want to guarantee that, given two objects matching the query entry-points, located at different distances from the vertex appearing last within the reverse topological order, these are still reachable within the distance of crossing a single containment. Similarly to semistructured data literature, we refer to one as its (direct) ancestor and to the other as its (direct) descendant. If the entry point considering in its match the aforementioned direct descendant object is replaced with another object, be it recently created during the application of the rewriting rules or already existing within the database, we want this information to be passed directly during the execution of the rewriting associated with the match of the object of the direct descendant. For this, we need both an explicit return mechanism, which allows the possibility of explicitly telling the objects appearing at the higher layers induced by the topological order that the previous object has been replaced, and to keep the match size compact, so that we can guarantee that any entry-point value updated at a lower level is retrieved immediately.

6.2. Determining the Order of Application of the Rules

We determine the application order of our language rules for each entry-point vertex of interest (Algorithm 5). This boils down to solving a scheduling problem, which requires first determining the interdependencies across the graph grammar rules. All the matching constructs $L_i$ for each rule $L_i{\to }_{\Theta }{R}_i$ in our query gg have variables that might be shared across morphisms.

Algorithm 5 Sorting the Graph Grammar rules by application order

1: procedure SortRules(gg) 2:     $V:=\left\{{\mathtt{p}}_i\right|{\mathtt{p}}_i=L_i{\to }_{\Theta }{R}_i\in \mathtt{gg}\}$ 3:     $E:=\{{\mathtt{p}}_i\to {\mathtt{p}}_j|{\mathtt{p}}_i.\mathtt{res}\ne \mathtt{NULL}\wedge {\mathtt{p}}_i.\mathtt{res}={\mathtt{p}}_j.\mathtt{entrypoint}\vee$ 3:                          ${\mathtt{p}}_i.\mathtt{entrypoint}={\mathtt{p}}_j.\mathtt{entrypoint},{\mathtt{p}}_i\in V,{\mathtt{p}}_j\in V\}$ 4:     $G:=(V,E)$ 5:     time$:=$LayerFromTopologicalSort(G,${\mathsf{ApproxV}}_{\mathsf{topo}}$(G))▹ Algorithm 1 6:     sort each x in gg by time $\left[x\right]$ in ascending order 7: end procedure

As per Example 1, each rewriting $R_i$ might replace the entry-points with a single new object, or we preserve the previously matched ones otherwise. These are then input to any later morphism being considered while applying the rewritings. For this, we might consider the variables across patterns as hints to the query language on how the updated or matched objects are going to influence their updates, thus declaring their interdependencies. By reducing this to a dependency ordering, we consider the dependency graphs for the matching and rewriting rules, (Line 4), where each vertex represents a rule (Line 2). Each edge connecting two vertices (or patterns) represents a connection between the entry-point or returned variable from the source pattern and any other non-entrypoint variable occurring in the target pattern (Line 3). As the resulting graph might contain loops as some patterns might exhibit mutual dependencies, we are then forced to run an approximated topological sorting algorithm (Line 5) to determine an approximated scheduling order across such tasks through a DFS visit of the graph [52]: we start traversing the graph from the first rule appearing in the graph grammar while avoiding visiting edges leading to already-visited vertices; if we visited all the vertices reachable from such initial vertex while still having unvisited ones, we recommence the same visit starting from the earliest vertex that was not already visited. We add each visited vertex inside a stack after each of its children has been fully visited. By doing so, we prioritise the rules’ declaration order which then acts as a heuristic for guiding the algorithm to decide upon a specific visiting order.

6.3. Containment Matching

With Algorithm 6, we define the steps realising containment matching for each $L_i$ from a rule $p_i$ to later on generate a morphism table $MT[L_i,g_j]$ per GSM database $g_j$, as discussed in Section 6.4. The algorithm works as follows: (i) after caching the PhiTable^κ referenced by the containments in the matching patterns to minimize the tables’ access in a uniform schema specification, (ii) we specialise such tables to the specific schema induced by the variables’ names and nesting occurring in the matching $L_i$. Last, (iii) we collect the matching containments by separating them between required or optional ones.

Algorithm 6 Intermediate Edge Result Caching

1: procedure UniqueCacheId($c=(q,\mathtt{isOut}),L$) 2:     global queryCache, queryMap, emptySet 3:     if  $L=\varnothing$ then  emptySet = emptySet $\cup \left\{c\right\}$ else  4:     for all $l\in L$ do 5:         queryCache = queryCache $\cup \left\{l\right\}$ 6:     end for 7: end procedure 8: function FromDB($\kappa ,db$) 9:     $t:=\langle \rangle ;S\left(t\right):=[(\mathtt{dbid},\mathbb{N}),(\mathtt{src},\mathtt{ni}),(\mathtt{edge},\mathtt{ci}),(\mathtt{edgeLabel},{\mathsf{\Sigma }}^{*}),(\mathtt{dst},\mathtt{ni})]$ 10:     if ${\mathsf{PhiTable}}^{\kappa }\in db$ then 11:         $t:=\langle \left[\right(\mathtt{dbid},i),(\mathtt{src},j),(\mathtt{edge},r),(\mathtt{edgeLabel},\kappa ),(\mathtt{dst},d\left)\right]\mid$ 11: $r<|{\mathsf{PhiTable}}^{\kappa }|,{\mathsf{PhiTable}}^{\kappa }\left(r\right)=\langle l,i,j,w,d,\iota \rangle \rangle$ 12:     end if 13:     return t 14: end function 15: function ToTable($t,x,y,l_x,nestCont$) 16:     if  $l_x=\mathtt{NULL}$ then $t:=R_{\mathtt{src},\mathtt{dst}\to x,y}\left({\pi }_{\mathtt{dbid},\mathtt{src},\mathtt{dst}}\left(t\right)\right)$ 17:     else  $t:=R_{\mathtt{src},\mathtt{edge},\mathtt{edgeLabel},\mathtt{dst}\to x,l_x,l_x+“\_{\mathtt{label}}^{”},y}\left(t\right)$ 18:     if  nestCont then  $t:={\nu }_{l_x,y\to y}\left(t\right)$ 19:     return t 20: end function     21: procedure CacheIntermediateResults(gg, $db$) 22:     global queryCache, queryMap, emptySet 23:     for all $p_i=L{\to }_{\Theta }R\in \mathtt{gg}$ s.t. $L\equiv \langle ep,in,out,join,\mathtt{hook}\rangle$ do 24:         for all  $q\in in$ s.t. $q=\langle u,l,l_x,\mathtt{all},\mathtt{opt}\rangle$do  UniqueCacheId($(q,\mathbf{false}),l$) 25:         for all $q\in out$ s.t. $q=\langle u,l,l_x,\mathtt{all},\mathtt{opt}\rangle$ do  UniqueCacheId($(q,\mathbf{true}),l$) 26:         for all $q\in join$ s.t. $q=\langle u,l,l_x,\mathtt{all},\mathtt{opt},v\rangle$do  UniqueCacheId($(q,\mathbf{true}),l$) 27:         queryCache = queryCache $\cup \mathsf{hook}$ 28:     end for 29:     if  emptySet $\ne \varnothing$ then  queryCache $=\left\{\kappa \right|{\mathsf{PhiTable}}^{\kappa }\in db\}$ 30:     cache $:={⨁}_{x\in \mathrm{q}\mathrm{u}\mathrm{e}\mathrm{r}\mathrm{y}\mathrm{C}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}}\left[(x,\mathrm{F}\mathrm{R}\mathrm{O}\mathrm{M}\mathrm{D}\mathrm{B}(x,db))\right]$ 31:     for all $p_i=L{\to }_{\Theta }R\in \mathtt{gg}$ s.t. $L\equiv \langle \langle ep,{\mathtt{agg}}_{ep}\rangle ,in,out,join,\mathtt{hook}\rangle$ do 32:         ${\mathrm{hook}}_i:={\pi }_{\mathtt{dbid},\mathtt{src},\mathtt{dst}}\left({\bigsqcup }_{j\in \mathtt{hook}}\mathrm{T}\mathrm{O}\mathrm{T}\mathrm{A}\mathrm{B}\mathrm{L}\mathrm{E}(\mathrm{cache}\left(i\right),\mathtt{src},\mathtt{dst},\mathtt{NULL},\mathbf{false})\right)$ 33:         for all $q\in out,\iota \in \mathrm{q}\mathrm{u}\mathrm{e}\mathrm{r}\mathrm{y}\mathrm{C}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}(q,\mathbf{true})$ s.t. $q=\langle \langle u,{\mathtt{agg}}_u\rangle ,l,l_x,\mathtt{all},\mathtt{opt}\rangle$ do 34:            $t:=\mathrm{T}\mathrm{O}\mathrm{T}\mathrm{ABLE}(\mathrm{c}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}\left(\iota \right),ep,u,l_x,\mathtt{all}\mathbf{and}{\mathtt{agg}}_u)$ 35:            if  opt then  $\mathrm{o}\mathrm{p}{\mathrm{t}}_i:=\mathrm{o}\mathrm{p}{\mathrm{t}}_i\cup \left\{t\right\}$ else $\mathrm{r}\mathrm{e}{\mathrm{q}}_i:=\mathrm{r}\mathrm{e}{\mathrm{q}}_i\cup \left\{t\right\}$ 36:         end for 37:         for all $q\in in,\iota \in \mathrm{q}\mathrm{u}\mathrm{e}\mathrm{r}\mathrm{y}\mathrm{C}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}(q,\mathbf{false})$ s.t. $q=\langle \langle u,{\mathtt{agg}}_u\rangle ,l,l_x,\mathtt{all},\mathtt{opt}\rangle$ do 38:            $t:=\mathrm{T}\mathrm{O}\mathrm{T}\mathrm{ABLE}(\mathrm{c}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}\left(\iota \right),u,ep,l_x,\mathbf{false})$ 39:            if  opt then  $\mathrm{o}\mathrm{p}{\mathrm{t}}_i:=\mathrm{o}\mathrm{p}{\mathrm{t}}_i\cup \left\{t\right\}$ else $\mathrm{r}\mathrm{e}{\mathrm{q}}_i:=\mathrm{r}\mathrm{e}{\mathrm{q}}_i\cup \left\{t\right\}$ 40:         end for 41:         for all $q\in join$ s.t. $q=\langle \langle u,\mathbf{false}\rangle ,l,l_x,\mathtt{all},\mathtt{opt},\langle v,{\mathtt{agg}}_v\rangle \rangle$ do 42:            $t:=\mathrm{T}\mathrm{O}\mathrm{T}\mathrm{ABLE}(\mathrm{c}\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{e}\left(\iota \right),u,v,l_x,\mathtt{all}\mathbf{and}{\mathtt{agg}}_u)$ 43:            if  opt then  $\mathrm{o}\mathrm{p}{\mathrm{t}}_i:=\mathrm{o}\mathrm{p}{\mathrm{t}}_i\cup \left\{t\right\}$ else $\mathrm{r}\mathrm{e}{\mathrm{q}}_i:=\mathrm{r}\mathrm{e}{\mathrm{q}}_i\cup \left\{t\right\}$ 44:         end for 45:     end for 46: end procedure

6.3.1. Pseudocode Notation for $L_i$

We describe the notation used in our pseudocode being the machine readable representation of the query syntax discussed in Section 6.1.

We define each object variable as a pair $\langle x,\mathbf{agg}\rangle \in \mathcal{N}={\mathsf{\Sigma }}^{*}\times \{0,1\}$, where x is the variable name and agg denotes whether the vertex should be aggregated (1) or not (0). In our pseudocode, each matching $L_i$ is represented as the tuple $\langle ep,in,out,join,\mathtt{hook}\rangle$, where $ep\in \mathcal{N}$ specifies the pattern entry-point and each ingoing (or outgoing) edge is represented by a pair $\langle u,l,l_x,\mathtt{all},\mathtt{opt},v\rangle$, where $u\in \mathcal{N}$ remarks the variable associated with the container (or contained) object alongside the containment relationship through $\varphi$ and $t_{\varphi }$, $l\in \wp \left({\mathsf{\Sigma }}^{*}\right)$ provides a potentially empty-set of containment relationships, $l_x$ is an optional containment variable, all$\in \{0,1\}$ determines whether the edges should be considered in the aggregation or not, and opt$\in \{0,1\}$ determines whether the match should be considered as optional or not. The join edges extend such records as $\langle u,l,l_x,\mathtt{all},\mathtt{opt}\rangle$ by specifying both the containment ($v\in \mathcal{N}$) and container ($u\in \mathcal{N}$) variable explicitly, and hook$\in \wp \left({\mathsf{\Sigma }}^{*}\right)$ determines whether the aggregated entry-points over the single incoming container should be subdivided in equivalence classes according to the containment labels in hook, and we perform no clustering otherwise.

6.3.2. Procedural Semantics for Matching and Caching Containments

We now narrate the operations required to match each containment occurring across patterns while representing those as relational tables expressing either required (req_i), optional (opt_i), or hook-driven equivalence relationships (hook_i) per pattern $p_i$.

First, we define the semantics associated with the matching of each object ego-net as described in ToTable from Algorithm 6 (Line 15): either containment (src)- -[$l_x:L$]->(dst) or (dst)<-[$l_x:L$]- -(src) are represented as records with fixed schema (Line 9) where each record refers to a single containment $\iota$ (edge) in $\varphi (\mathtt{src},\ell )$ for a container src, where $\langle \mathtt{dst},w\rangle =t_{\varphi }\left(\iota \right)$ and dst refers to the contained object; in this, we also retain the containing db as dbid and the containment $\ell \in L$ (edgeLabel). At this stage, all containments are associated with the same schema and are not specialised to abide by a specific schema induced by a matching specification. This allows us to easily cache PhiTable^κ containments (Line 30).

Next, we discuss how we specialise the results from the cache according to the schema induced by the variables occurring in each matching $L_i$. This is carried out by renaming generic containing/containment/contained object labels (src/edge/dst) with the variable names in $L_i$ associated with them; if the patterns also contain references to the edge variable ($l_x$), we also retain each ID in ${\varphi }_x(u,L)$ as $l_x$, and $l_x$’s label (Line 17) and we discard such information otherwise (Line 16). If the edge expresses an aggregation from the container to the content (e.g., (src)–[$\forall L$]–(≫ dst)), we nest $l_x$ (if available) and dst from the table obtained at the previous step (Line 18). This makes the major difference with existing graph query languages, as we consider containment identifiers as a separate class from object ones (thus differently from SPARQL) and we also produce nested morphisms according to the query annotations.

Last, we collect the tables while differentiating where those are associated with a required or optional pattern (Lines 35, 39, and 43), acting as the basic building step for defining nested morphisms as in the subsequent section.

6.3.3. Algorithmic Choices for Optimisation

After discussing the procedural semantics of the matching of containments occurring across all $L_i$-s, we describe the algorithmic choices for optimisation purposes. First, to minimize the access to a relational database, we ensure that each ${\mathsf{PhiTable}}^{\kappa }$ is accessed at most once across all the edges by collecting all the labels of interest across table-matched containments in queryCache (Line 5). If some containments have no containment attribute specified, we remember the existence of such containment (Line 3) for which we will then require considering all the ${\mathsf{PhiTable}}^{\kappa }$ records, as a containment for which no label is specified forces to consider all the containments (Line 29). Only after this, we access the physical model to transform each PhiTable^κ per $\kappa \in$ queryCache to a containment table to be then composed into the final nested morphism table, thus ensuring minimal memory access (Line 30).

6.4. Morphism Instantiation and Indexing

Algorithm 7 combines each table produced from the previous phase to generate the morphisms describing the result of matching $L_i$ through the generation of morphisms being recorded within an $MT[L_i,g_i]$ table for each GSM database $g_i$. Similarly to SPARQL’s triple navigation semantics, we generate the morphisms $P_i$ for all GSM databases by natural joining all the tables associated with the mandatory containments (Line 10), while left-joining $P_i$ (the resulting table from the natural join of the required containments) against the optional patterns set and updating $P_i$ with such a result (Line 13).

Algorithm 7 Morphism instantiation and indexing

1: procedure InstantiateMorphisms(gg, $G=\{g_1,\dots ,g_n\}$)   ▹global$MT$ 2:     for all $p_i=L_i{\to }_{\Theta }{R}_i\in gg$ do 3:         global reqi, opti, hooki            ▹ Algorithm 6 4:         $\overline{e}:=L.\mathrm{entrypoint}$ 5:         if $|\mathrm{r}\mathrm{e}{\mathrm{q}}_i|=0$ then  continue 6:         sort each t in reqi by $\left|t\right|$ in ascending order 7:         $P_i:=\mathrm{r}\mathrm{e}{\mathrm{q}}_i\left(0\right)$ 8:         for $j=1$ to $|\mathrm{r}\mathrm{e}{\mathrm{q}}_i|-1$ do 9:            if  $|P_i|=0$ then  break 10:            $P_i:={\mathrm{N}\mathrm{ESTED}\mathrm{N}\mathrm{ATURAL}\mathrm{E}\mathrm{QUIJOIN}}_{\mathbf{false}}(P_i,\mathrm{r}\mathrm{e}{\mathrm{q}}_i\left(j\right))$ 11:         end for 12:         if  $|P_i|=0$ then  continue 13:         $P_i:=\Lambda ({\mathrm{N}\mathrm{ESTED}\mathrm{N}\mathrm{ATURAL}\mathrm{E}\mathrm{QUIJOIN}}_{\mathbf{true}},P_i,op{t}_i)$ 14:         if L.entrypoint = $(\gg z)$ and $\exists \mathtt{x},\mathtt{obj}.<-[\forall \mathtt{x}:\dots ]--\mathtt{obj}\in \mathtt{cont}$ then 15:            $\overline{e}:=\mathtt{obj}$ 16:            $P_i:={\nu }_{S\left(P_i\right)\setminus \{\mathtt{dbid},\mathtt{x},\mathtt{x}\_\mathtt{label}\}\to \star }\left(P_i\right)$ 17:            hook$:=$Trans(Symm(Refl(hooki))) 18:            $\Re :=\left\{{\Re }_i\right|g_i\in GF\wedge t_{{\Re }_i}.s\iff (i,t\left(z\right),s\left(z\right))\in \mathtt{hook}\left\}\right\}$ 19:            for all $\mathsf{\Gamma }\in P_i$ and ${\gamma }_i\in {\displaystyle \raisebox{1ex}{$\mathsf{\Gamma }(\star )$}\!\left/ \!\raisebox{-1ex}{${\Re }_{\mathsf{\Gamma }\left(\mathtt{dbid}\right)}$}\right.}$ do 20:                $MT[L_i,\mathsf{\Gamma }\left(\mathtt{graph}\right)]$.add(${\mathsf{\Gamma }|}_{\{\mathtt{graph},\mathtt{x},\mathtt{x}\_\mathtt{label}\}}\oplus \left[(\star ,{\gamma }_i)\right]$) 21:            end for 22:         else 23:            for all  $\mathsf{\Gamma }\in P_i$do  $MT[L_i,\mathsf{\Gamma }\left(\mathtt{graph}\right)].\mathtt{add}\left(\mathsf{\Gamma }\right)$ 24:         end if 25:         for all $g_j\in G$ do 26:            sort each $\mathsf{\Gamma }$ in $MT[L_i,g_j]$ by $O_{\mathsf{rtopo}}\left(\mathsf{\Gamma }\left(\overline{e}\right)\right))$ in ascending order 27:         end for 28:     end for 29: end procedure

We further nest the morphism if and only if the entry-point is aggregated via a single containment object obj (Line 14), for which we then nest in a fresh attribute ⋆ all the attributes except the database where obj is contained, obj itself, and optionally the edge labels for the containment if the pattern exhibits its variable (Line 16).

Hooks derive an equivalence relationship ${\Re }_i$ per GSM database $g_i$ having a ⋆-nested morphism through which to optionally split the morphisms. We retain only the container and containment relationship and their containing database ID (Line 32 from Algorithm 6), for then obtaining a suitable equivalence relationship ${\Re }_i$ by computing the reflextive, symmetric, and transitive closure of that relationship (Line 17). Then, we potentially split the table nested in ⋆according to the equivalence classes associated with each equivalence relationship ${\Re }_i$ obtained from hooks (Line 19) and update the morphism table accordingly.

Concerning the composition of cached tables, to reduce the equi-join time we first sort the tables by increasing size (Line 6) for then stopping the joins as soon as we find or compute an empty morphism, thus entailing that no collection of objects across all dbs can match $L_i$ (Lines 5 and 9). As a last optimisation, we populate $MT$ collecting the morphisms by database ID and rule ID (Lines 20 and 23). Last, we sort each morphism in $MT[L_i,g_j]$ by entry-point (Line 4) reverse topological order (Line 26) or, if these were nested in ⋆, by  their container object (Line 15). This induces a primary block indexing mapping each elected vertex $\overline{e}$ to a set of morphisms containing it.

6.5. Graph Rewriting Operations (op from $R_i$)

Finally, we apply the transformation operations required by the rewriting side of the rule for each instantiated morphism in $MT$ across all GSM databases. This works by keeping track of the desired changes within a GSM view per loaded GSM database.

We now discuss Algorithm 8. For updating GSM views, we apply the rewriting query for each database $g_j$ as described by the rewriting patterns $R_i$ in gg (Line 2): we visit per GSM database its objects according to the reverse topological order from $O_{\mathsf{rtopo}}\left(g_i\right)$ (Line 4) while retaining the objects v appearing in the aforementioned primary block index of a non-empty morphism table $M[L_i,g_j]$ for each production rule $p_i=L_i{\to }_{\Theta }{R}_i\in \mathtt{gg}$ (Line 5): we skip the morphisms $\mathsf{\Gamma }$ associated with v if either a previously matched vertex was deleted and not replaced with a new one (Line 6), or if the current morphism $\mathsf{\Gamma }$ does not satisfy a possible WHERE condition $\Theta$ associated with $L_{\Theta }$ (Line 8). For the remaining morphisms, we run the operations listed in $R_i$ in order of appearance (Line 9).

Algorithm 8 Rewriting phase

1: function GenerateGraphViews(gg, $G=g_1,\dots ,g_n$) 2:     for all $g_i\in G$ do 3:         $\Delta \left(g_i\right):=$new GraphView($\left|V\right(g_i\left)\right|$) 4:         for all $v\in O_{\mathsf{rtopo}}\left(g_i\right)$ s.t. $v\notin O_i^{-}$do               ▹ Section 4.1 5:            for all $p_i=L_i{\to }_{\Theta }{R}_i\in \mathtt{gg}$ s.t. $MT[L,g_i]\ne \varnothing$ do 6:                for all $\mathsf{\Gamma }\in MT[L,g_i]$ s.t. $\forall \mathtt{col}.\neg {\mathsf{Optional}}_L\left(\mathtt{col}\right)\Rightarrow \mathsf{\Gamma }\left(\mathtt{col}\right)\notin O_i^{-}$ do 7:                    $\Delta \left(g_i\right):={\mathrm{S}\mathrm{TART}}_{\Delta \left(g_i\right)}\left(\mathsf{\Gamma }\right)$                 ▹ Equation (9) 8:                    if $\Theta \ne \mathbf{true}$ and $\left|{\left[[\Theta ]\right]}_{\mathsf{\Gamma },g_i}^{1,MT}\right|=0$ then continue              ▹Figure A2 9:                    ${“}^{”},T,p,\Delta \left(g_i\right),MT:=\nu (R,T,p,\Delta \left(g_i\right),MT)$               ▹  Figure 8 10:                end for 11:            end for 12:         end for 13:         yield $\Delta \left(g_i\right)$ 14:     end for 15: end function

We now discuss the definition of $\nu$ through SOS semantics enclosed within the evaluation of Line 9 in detail. Figure 8 describes the interpretation of all rewriting rules $R_j$ updating the GSM view $\Delta \left(g_i\right)$, where the first three updates and exploit the functions from Section 4.3. All the y-s are interpreted as evaluated expressions without intermediate assignments. Rule NewObject creates a new object and refers it to the variable j. Rule DelObject deletes a pre-existing or a newly-created object, and Rule DelObject deletes a single container-containment relationship that was defined at loading time. We can easily distinguish between variables referring to objects or containments by the simple type associated with the attribute. For now, we do not allow the explicit removal of containments at run-time unless the containment is explicitly specified via containment update.

We discuss the set update for the vertices’ label values; we distinguish the following cases: if both the number of variable and values are in the same number, we assign for each i-th variable the u-th occurring resolved value (labelZip); otherwise, we assign to each object associated with the resolved variable the collapsed string values (LabelValFlat). We can obtain similar rules for $\xi$ which are omitted here for conciseness, but that can be retrieved in the appendix (Figure A4).

Figure 8. Graph Rewriting SOS for view update.

Figure 8. Graph Rewriting SOS for view update.

We treat the property $\pi$ and the containment $\varphi$ updates differently, as they deal with the resolution of three variables. We are also interested in whether different resolved variables belong to the same nested table within the morphism or not, with the rationale being that we can freely associate each value within the same nesting row-by-row (P2Zip, P2’Zip, and P2″Zip), while we need to compute the cross-product between the assignments if the value belongs to distinct nestings (Clearly in P3Zip). This is determined via the second parameter of expression evaluation ${\to }_E$ (Appendix A.3) by transferring the attribute information originated by the variable resolution ${\to }_{\rho }$ (Appendix A.1). In all the remaining occasions, we arbitrarily decide to flatten the associated expressions. Please observe that, if the querying user wants more control over the precise value to be associated, they can always refer to SCRIPT expressions, thus breaking the declarative assumptions for a more controlled output.

Even in this case, we can formulate the rules for setting the $\varphi$-s similarly to our previous discussion for the $\pi$-s. Therefore, we defer to Figure A5 provided in the Appendix A.4.

We conclude by analysing the semantics associated with the replacement via $R_i$’s return statement, the last and mandatory operation for declared rewriting operations. We apply no rewriting if the returned variable is the variable entry-point (NoRewr). Otherwise, if the entry-point variable is not aggregated, we resolve the replacement and entry-point (Repl and Orig, respectively) and we replace any object in Orig associated with the entry-point variable $p^{\prime }$ with an object in Repl associated with the replacing variable $p^{\prime }$ (NoAggrRewr). Otherwise (AggrRewr), the rewriting occurs by replacing the objects in Orig, associated with the entry-point’s container and the objects in Repl, associated with the returned variable p′. Furthermore, given C the containment labels for which the entry-point is contained by its aggregating object in cont, we also update the containing for the cont objects to also contain via C the replacing objects in Repl. As this provides the final update, we then consider this last resulting GSM view of the resulting view for our rewriting step.

As no SOS rule matches the empty string, no further operation is conducted, and the rewriting program terminates after considering the final rewriting statement.

7. Language Properties

Given the previous language description, we want to characterise its properties by juxtaposing them with Cypher’s. Full proofs are provided in Appendix B.3. We start by showing that, unlike current graph query languages, we propose a rewriting language framed as generalised graph grammars: we relate our proposed language to the graph grammars as, similarly to these, the absence of a matched pattern leads to no view updates. Still, we claim that such language provides a generalisation of the former by supporting explicit data-aware update operations over the objects and containments, while also defining explicit semantics determining the order of the application of such rules, both across rules and within each GSM database.

Lemma 6. 

If either we query all the GSM databases with no rules, or all the rules have no rewritings, or none of the matches returned a morphism, or none of the ones being matched pass the associated Θ condition, then we return the same GSM databases as the ones being originally loaded.

Next, we ensure that the rules are applied in reverse topological order, thus minimising the restructuring cost of the GSM database while achieving declarativeness for rule application, as the user does not specify this within the query formulation, as no matched pattern leads to no view updates.

Property 1. 

The rules are applied in (reversed) topological order while visiting each GSM.

On the other hand, we can show that Cypher forces the user to specify in which order the updates shall be applied, thus breaking the declarative assumption for a good query language.

Lemma 7. 

The application of the rewriting in Cypher in lexicographical order requires explicitly determining the order of the morphisms’ application and the order of the graph’s visit.

Next, we state the usefulness of an explicit return statement within the interpretation of a rule as it allows us to propagate the updates on the subsequently evaluated morphisms.

Lemma 8. 

If an entry-point match is deleted and a new object is re-created inheriting all of its properties, this new object will not be connected to the entry point’s containers unless the newly-returned object was applied.

To a minor extent, we also show a greater amount of declarativeness if compared to current graph query languages by automatically generating a new object if an update operation occurs with reference to an optionally matched variable that was not matched to an existing object.

Lemma 9. 

The setting of properties to variables not associated with a newly-created object variable and not associated with an actual GSM object due to an optional match reduces to the creation of a new object associated with the variable, which then always receives this and any following update associated with the same variable.

At this point, it could be argued that, although our proposed rewriting language performs queries that cannot be expressed in other graph query languages, this does not return the matched subgraphs as in such other languages, similar to Cypher’s return statement due to the considerations from Lemma 6. The following Lemma shows otherwise. Thanks to this, this language is considered more expressive than Cypher.

Lemma 10. 

The proposed graph grammar query language can express traversal queries retaining only the objects and containments being matched and traversed.

Corollary 1. 

The proposed graph query language is more expressive than current graph query languages.

8. Time Complexity

We now study the computational complexity associated with the algorithms discussed in the previous section and infer this from the implementation details discussed while reasoning on the SOS discussion. Proofs are postponed to Appendix B.4. Please observe that, as previously noted from previous graph query language literature (Section 3.1.2), the following results do not intend to prove P vs NP, as we are deliberately expressing a sub-problem of the more generic subgraph isomorphism problem that can be easily captured through algebraic operations.

Lemma 11. 

The time complexity of sorting the rules within the query is quadratic over the number of query rules.

Lemma 12. 

The intermediate edge result caching time complexity has a polynomial cost being linear in both the loaded databases and the number of available objects.

Corollary 2. 

The cost for generating the nested morphisms is polynomial with the size of the entire data loaded within the physical model.

Lemma 13. 

The rewriting cost is polynomial and linear with the number of rewriting operations and the number of the morphisms.

Corollary 3. 

The time complexity of the whole Generalised Graph Grammars is polynomial with the size of the loaded physical model.

9. Empirical Evaluation

For our empirical evaluation, we study the use case of graph grammar in the context of rewriting graphs representing the grammatical structure of a natural-language sentence. Universal dependencies [53] capture these syntactical features across languages by exploiting a shared annotation scheme. In this context, the usual approach to graph rewriting boils down to rewriting a PROLOG-like logical program by applying declarative rewriting rules (https://github.com/opencog/relex accessed on 22 April 2024) via a unification algorithm [54], where compound terms are equivalently expressing binary relationship and properties associated with specific vertices. Given the general interest for such an approach within the domain of Natural Language Processing (NLP), the present paper is going to specifically focus on use case scenarios within such domain. This will also give us the opportunity to re-use freely available datasets for sentences for our experiments (https://osf.io/btjqw/?view_only=f31eda86e7b04ac886734a26cd2ce43d and https://osf.io/rpu37/, accessed on 21 April 2024), which can be then deemed as repeatable.

Notwithstanding the previous approaches, we want to achieve a more data-driven approach to sentence rewriting, where atoms can also be associated with properties and labels, thus motivating the definition of the proposed query language. Furthermore, the extension of the graph grammar language with a script can be used to compose data and define boolean conditions allowing us to break the declarativeness assumption only when the user wants more control over how data are processed. Thus, we postulate that our proposed query language extends the current literature in several aspects way beyond graph database literature while postulating the possibility of applying concurrently multiple rewriting rules over disparate sentences via a sole declarative query. The proposed approach shares some similarities with programming language research where, after representing a program in terms of its operational semantics, we can apply graph rewriting rules over abstract semantic graphs [55], which are usually represented as trees, for which similar considerations like the former can be applied.

We test the implementation of our physical model and associated query language as implemented in our novel object-oriented database, named DatagramDB, which source code associated with the current paper is freely available online (https://github.com/datagram-db/datagram-db/releases/tag/v2.0, accessed on the 22 April 2024). We conducted all our benchmarks on a Dell Precision mobile workstation 5760 running Ubuntu 22.04 LTS. The specifications of the machine include an Intel^® Xeon(R) W-11955M CPU @ 2.60 GHz x16, 64 GB DDR4 3200 MHz RAM.

9.1. Comparing Cypher and Neo4j with Our Proposed Implementation

Given the problems being evidenced by the Cypher query language from Lemma 7, we cannot automate the benchmarking of Cypher for all the possible sentences coming from an online available dataset. By recalling the results of this lemma, we observe that, when the query is not able to capture a pattern albeit optionally, this will have a cascade effect on the entire query for which none of the following rewriting operations will be applied. Given this, the same query might not necessarily provide the same output across different sentences having a different sentence structure. Thus, we cannot use one single query for dealing with unpredictable sentence structure that, in the worst-case scenario, would require us to write one single query per input sentence. We then preferred to limit our comparison to two sentences, for which we designed the minimal Cypher query exactly capturing the syntactical features expressed by these sentences while using the same query for DatagramDB across all the sentences.

We considered two distinct dependency graphs: “Alice and Bob play cricket”, the one in Figure 3a, and the one resulting from the dependency parsing of the “Matt and Tray...” sentence from Figure 6a. We loaded them in both Neo4j v5.20 and our proposed GSM database. In Cypher, we then run the query as formulated in the previous section, while we construct a fully declarative query in our proposed graph query language syntax directly representing an extension of the patterns in  Figure 2. From now on, when referring to Neo4j, we will always refer to version 5.20.

Examining

Table 1. Table displaying results from rewriting the aforementioned sentences.

Data Model		Loading/Indexing (avg. ms)	Querying (avg. ms)	Materialisation (avg. ms)	Total (ms)
Neo4j {	Simple	$1.83\times {10}^0$	$7.03\times {10}^0$	N/A	$8.86\times {10}^0$
	Complex	$9.32\times {10}^0$	$1.93\times {10}^2$	N/A	$2.02\times {10}^2$
GSM {	Simple	$9.63\times {10}^{-2}$	$4.82\times {10}^{-1}$	$2.40\times {10}^{-2}$	$6.02\times {10}^{-1}$
	Complex	$6.91\times {10}^{-1}$	$9.00\times {10}^{-1}$	$6.67\times {10}^{-1}$	$2.26\times {10}^0$

, we can see our solution consistently outperforms the Neo4j solution by two orders of magnitude. Furthermore, the data materialisation phase does not significantly impact the overall running time, as its running times are always negligible compared to the other ones. Additionally, Neo4j does not consider a materialisation phase, as the graph resulting from the graph rewriting pattern is immediately returned and stored as a distinct connected component of the previously loaded graph. This then clearly remarks the benefit of the proposed approach for rewriting complex sentences into a more compact machine representation of the dependency graphs.

9.2. Scalability for the Proposed Implementation

For testing the scalability of our implemented system, we used a corpora of sentences used for natural-language common-sense question answering [56] which we rewrote into dependency graphs using Stanford NLP [57]. As its output is failing systematically at correctly recognising verbs in passive form when at the present time and at recognising negations due to its training-based nature [58], we provide a piece of software amending its output so that all the syntactic and the semantic information retained within the sentence could pertain in a graph structure. This server also transforms the internal Stanford NLP dependency graph into a collection of GSM databases serialised in textual format. The resulting server is available online (https://github.com/datagram-db/stanfordnlp_dg_server accessed on 19 April 2024).

Given the resulting GSM representation of the two sentences, we provide two distinct scalability tests: in the first one, we sample the dataset into sentences to determine the algorithm’s scalability in terms of both the number of GSM databases and the number of vertices, while in the second we will only consider scalability regarding the sole number of GSM databases while maintaining the sample distribution of the sentence’s lengths, thus reflecting the number of GSM objects within the database.

Concerning the first scenario, we choose the sentences containing $|O_i|\in \{5,10,15,18\}$ words, and for each of them we choose 300 sentences each, thus obtaining sample sets $S_{300}^{|O_i|}$. Then, we further sample $S_4^{|O_i|}$ into three distinct subsets $S_i^{|O_i|}$ having cardinality of $S_i^{|O_i|}=75·i$ for which $S_i^{|O_i|}\subset S_{i+1}^{|O_i|}$ for $n>0$ and $1\le i<i+n\le 4$. This will be useful to then plot the rewriting running times using for the x-axis either the number of sentences (or GSM databases) or the sequence length, to better analyze the overall time complexity. The results for these experiments are reported in Figure 9.

From these plots, we can clearly remark that querying and materialisation times are clearly linear over the size of objects being loaded or GSM databases being matched and rewritten, thus remarking the efficiency for the overall envisioned approach: please observe that we cannot achieve a better time complexity that a linear scan without additional heuristics, as we still have to perform the visit over each GSM database by also performing a linear scan of the database objects in reverse topological (layered) order. We can also motivate these results by having graphs in which the branching factor is relatively small compared to the overall number of available vertices, thus $\beta \ll |O_i|$ for each GSM database $g_i$. We also observe that, for these smaller datasets, the resulting materialisation time is almost negligible compared to the query time, which, across the board, dominates the loading and indexing time.

By comparing such running times with the ones from Neo4j, we can easily observe that, while we were able to process 300 GSM databases in 100 milliseconds, Neo4j could rewrite just one single graph in double time. Given this, our approach has a throughput of almost 600 times over Neo4j. This further remarks the impracticality of using the competing solution for analysing more sentences in the future, e.g., while considering sentences crawled from the web.

While it might initially seem that all phases (loading, querying, and materialisation) exhibit linear time complexity, we will try to consider a larger set of data to better outline the time complexity associated with our implementation.

Concerning the second scenario, we decided to sample the internet dataset in a subset of sentences $S_1,\dots ,S_4,S$ where $|S_i|={10}^i$. S represents the entire dataset while ensuring that each dataset of a lesser size is always contained in the larger dataset. Furthermore, we ensure that the number of words, and therefore, of objects on each sampled database reflects a similar frequency distribution of the number of objects per resulting GSM database (Figure 10). By doing so, for our final scalability tests in which we consider more data, we make up for the lack of long sentences with the number of sentences reflected in the number of the GSM databases to be processed.

Figure 11 provides the benchmarks for these experiments: a non-linear but polynomial loading time might be possibly related to the data parsing time and the time to store such data in primary memory, while the remaining running times keep a linear time complexity concerning the increase in the number of the GSM databases to be rewritten, similarly to the previous experiments. Querying time always dominates in indexing time by at least one order of magnitude, thus showing that most of the significant computations occur while matching and rewriting. Materialisation times are on the same order of magnitude as indexing time, thus also showing that this cost does not exceed the actual querying phase. Overall, the efficiency of our system is also reflected by a linear querying time for the datasets being considered.

10. Conclusions and Future Works

This paper offers the definition of a matching and rewriting mechanism similar to the one provided by graph grammar implemented over object-oriented databases. As our definition supports both data matches and complex data update operations over the objects of interest, whose features were not considered in previous graph grammar formulations, we name our proposed language Generalised Graph Grammars. Our theoretical results prove the impossibility of expressing the same query with the same degree of generality of Cypher, which requires specifying a different query for any potential graph to be queried, thus posing a major limitation to automating rewriting operations over graphs. Empirical results prove that our query language offers an implementation faster than the ad-hoc query formalised in Cypher and run over Neo4j v5.20, in terms of both running time and throughput expressed in the number of queries runnable per comparable amount of time. These results aim to observe the inadequacy of graph-centric implementations of data representations since a large amount of literature now agrees in stating that more traditional and relational representations often offer better performances with respect to queries both natively supported by graph languages [59] and in representing new operations on graphs that require their rewriting [6,7].

At this stage, we considered nested morphisms of at most depth of 1, thus requiring that each cell of a morphism table should contain at most one non-nested table. Future works will investigate whether there might be any benefit for further generalising this nesting to arbitrary depth, thus requiring further extending the definition of the Nested Natural Equi-Join operator to arbitrary depths.

Notwithstanding the possibility of the current model expressing uncertainty within the data, the rewriting operations always assume to deal with perfect information, thus generating objects or containments containing no uncertainty. Future works will address this gap by further extending the SOS semantics of these rewriting steps while considering provenance information [44], thus relieving the user from explicitly defining the uncertainty of the generated data by adding further declarativeness to the query language here proposed.

Although Lemma 10 showed that the proposed graph query language is also able to remove the unmatched objects and contents, our current algorithm is not tailored for effectively matching this case, as the removing pattern will be forced to return all the objects and containments for then removing them. Future works will extend this by optimising testing conditions for our general language while matching the objects and containments. As a direct consequence of this, our returned morphisms are not pruned after testing the $\Theta$ condition, which is just evaluated in the rewriting phase due to the fact that any updates to the GSM views will also alter the outcome of $\Theta$. Future works will use static analysis approaches to determine when $\Theta$ can be effectively used for pruning morphisms before being returned in the matching phase, and condition rewriting strategies to push condition evaluations towards the generation of the morphism as discussed in Section 6.3 and Section 6.4.

Although the current language supports the update of objects and containments within GSM objects, the provided query semantics do not consider the possibility that such updates can be still matched by the query, thus triggering additional rewriting operations. Future works will also consider further generalising the database matching and rewriting approach by considering the fix-point over the loaded database until convergence is met, thus meeting the former desiderata. We will also consider extending our containments with property-values associations similarly to the property graph model, and considering updating the objects’ and containments’ costs while performing the rewriting operations.

Last, preliminary experiments [34] conducted on a physical model being the direct mapping of the logical model in memory provide promising results showcasing the possibility of expressing not only JSON files but also representing indexing data structures in GSM that eventually lead to scalable query processing for JSON data. Future works will also compare the efficiency of DatagramDB if compared to other databases supporting object-oriented representations such as MongoDB or MySQL [60].