Patch Graph Rewriting

Abstract

The basic principle of graph rewriting is the stepwise replacement of subgraphs inside a host graph. A challenge in such replacement steps is the treatment of the patch graph, consisting of those edges of the host graph that touch the subgraph, but are not part of it.

We introduce patch graph rewriting, a visual graph rewriting language with precise formal semantics. The language has rich expressive power in two ways. First, rewrite rules can flexibly constrain the permitted shapes of patches touching matching subgraphs. Second, rules can freely transform patches. We highlight the framework’s distinguishing features by comparing it against existing approaches.

Introduction

When matching a graph pattern P inside a host graph G, G can be partitioned into (i) a match M, a subgraph of G isomorphic to the pattern P; (ii) a context C, the largest subgraph of G disjoint from M; and (iii) a patch J, the graph consisting of the edges that are neither in M nor in C. So the patch consists of edges that are either (a) between M and C, in either direction, or (b) between vertices of M not captured by the pattern P. For example, if P and G are respectively then the thick green subgraph is the (only) match M of P in G. The black subgraph of G is the context C, and the dotted red subgraph is the patch J. Metaphorically, patch J patches match M and context C together.

In graph rewriting, subgraphs of some host graph are stepwise replaced by other subgraphs. A requirement for such replacements is that they are properly re-embedded in the host graph. We contend that the patch is the most distinctive and interesting aspect of graph rewriting. This is because its shape is generally unpredictable, making it challenging to specify what constitutes a proper re-embedding of a subgraph replacement. This contrasts strongly with the situation for string and term rewriting, in which the embeddings of substrings and subterms are highly regular.

Most existing approaches to graph rewriting are rather uniform and coarse-grained in their treatment of the patch. For instance, suppose that we wish to delete the match M from G. What should happen to the edges of patch J, which would be left “dangling” by such a removal? The popular double-pushout (DPO) [9] approach to graph rewriting conservatively dictates that the application is not allowed in the first place: nodes connected to the patch must be preserved by the rewrite step, and the patch shall remain connected as before. The single-pushout (SPO) [18] variant, by contrast, permissively answers that such a deletion is always possible. As a side-effect, however, any resulting dangling patch edges are discarded.

In this paper, we introduce the patch graph rewriting (PGR) language. It has the following features:

• Pluriform, fine-grained control over patches. Rules themselves encode which kinds of patches are allowed around matches, as well as how they should be transformed for the re-embedding, using a unified notation. Thus, these policies are distinctly not decided on the level of the framework.

• An intuitive visual language. Despite their expressive power and formal semantics, patch rewrite rules admit a visual representation that we believe to be highly intuitive.

• Lightweight formal semantics. The formal details of PGR are based on elementary set and graph theory, and therefore accessible to a wide audience. In particular, an understanding of category theory is not required to understand these details, unlike for many dominant approaches in graph rewriting.

The remainder of our paper is structured as follows. To fix ideas and emphasize the visual language of PGR, we first provide an intuitive exposition in Sect. 2, and then follow with a formal introduction in Sect. 3. We show the usefulness of PGR by modeling wait-for graphs and deadlock detection in Sect. 4. We compare PGR to other approaches in Sect. 5. In Sect. 6, finally, we mention some future research directions for PGR.

Intuitive Semantics

We start with an intuitive introduction of PGR, to be made formally precise in Sect. 3. The graph G in Fig. 1 will serve as our leading example.

Fig. 1.

Graph G.

We begin by considering the rewrite rule in Fig. 2. Figure 3 contains a depiction of G in which the match, context and patch are highlighted: the thick green subgraph is the match for the left-hand side of the rule, the solid black subgraph is the context for this rule application, and the red dotted edges form the patch. In PGR, the rewrite rule in Fig. 2 cannot yet be applied in G. This is because without further annotations, the rule may only be applied if the patch is empty, that is, if the node with the a-loop has no additional edges. In effect, this rule only allows replacing an isolated node with an a-loop by two isolated nodes, one of which has a b-loop.

Fig. 2.

A simple rule.

Fig. 3.

Match, context and patch.

The rule in Fig. 2 can be generalized to allow for patch edges from and to the context by annotating the left-hand side of the rule as shown in Fig. 4. We call such annotations patch type edges. They can be thought of as placeholders for sets of patch edges:

• (i)The dotted arrow with source is a placeholder for an arbitrary number of edges from the context to the node with the a-loop.
• (ii)Likewise, the outgoing dotted arrow with target is a placeholder for an arbitrary number of edges going into the context.

Fig. 4.

An annotated rule.

The rule is now applicable to all nodes that have an a-loop and no other loop, allowing the node to be connected to the context through an arbitrary number of edges. In particular, then, the rule is applicable to the match highlighted in Fig. 3, and it gives rise to the step shown in Fig. 5.

Fig. 5.

Applying the rule on the left.

Although we see how patch type edge annotations on the left-hand side can be used to constrain the set of permitted patches around a match, it does not tell us what to do with patch edges if a match is found. To indicate such transformations, the solution is simply to reuse the patch type edges in the right-hand side of the rule. The rule shown in Fig. 4 does not reuse any of the patch type edges, explaining why the corresponding patch edges are deleted in Fig. 5.

One way to preserve the incoming edges bound to and the outgoing edges bound to is shown in Fig. 6. As the visual representation suggests, the incoming edges bound to get redirected to target the upper node of the right-hand side, and the sources of the outgoing edges bound to are redirected to the lower node. The respective sources and targets of the edges are defined to remain unchanged. Applying the rule in G results in the rewrite step depicted in Fig. 7.

Fig. 6.

Redirecting patch edges.

Fig. 7.

Applying the rule on the left.

Using this visual language, it is easy to duplicate, remove, and redirect edges in the patch. The rule displayed in Fig. 8 removes the incoming patch edges bound to , and duplicates the patch edges bound to : one copy for the upper node of the right-hand side, and two copies for the lower node. The resulting rewrite step is shown in Fig. 9.

Fig. 8.

Duplicating patch edges.

Fig. 9.

Applying the rule on the left.

Patch graph rewriting also allows for some more exotic transformations, such as inverting patch edges or pulling edges from the context into the pattern. The rule in Fig. 10 reverses the direction of and pulls into the pattern, giving rise to the step in Fig. 11.

Fig. 10.

Complex transformation.

Fig. 11.

Applying the rule on the left.

All of the above rules are only applicable to nodes that have an a-loop and no other loop. If we want the rule to be applicable to nodes that have additional loops, this can be expressed as in Fig. 12. This rule is now applicable to any node with an a-loop. It makes a copy of the node, as well as all edges incident to it (except for the a-loop, which is removed). If we slightly modify G to include an f-loop on the middle node, the rule gives rise to the rewrite step in Fig. 13.

Fig. 12.

Node duplication.

Fig. 13.

Applying the rule on the left.

In this brief visual introduction, we have focused on the transformation of the patch. The left-hand sides of the rules has each time been a single node with an a-loop. Its generalization to other patterns is largely obvious, but some edge cases arise. For instance, what could be the semantics of the rule which redirects patch edges between nodes of the pattern into the context? We now turn to the formal semantics of path rewriting, which makes all preceding transformations precise and excludes such edge cases.

Formal Semantics

Notation 1

(Preliminaries). For functions and with disjoint domains (but possibly overlapping codomains), we write for the function given by the union of f and g’s underlying graphs. If typing permits, we generalize functions f to tuples (x, y) and sets S in the obvious way, i.e., and .

We define directed, edge-labeled multigraphs in the standard way.

Definition 2

(Graph). A graph with edge labels from L consists of a finite set of vertices (or nodes) V, a finite set of edges E, a source map , a target map , and a labeling . For , we say that , and are the source, target and label of e, respectively.

For convenience, we will write to denote an edge such that , and .

Definition 3

(Basic Graph Notions). We define the following basic graph notions:

• (i)An unlabeled graph is a graph over a singleton label set. In this case we suppress the edge labels.
• (ii)A graph is simple if for all , , and together imply .
• (iii)We say that graphs G and H are disjoint if .
• (iv)
  For disjoint edge sets , we define the graph union as follows:

  

To rename vertices and edges of a graph, we introduce “graph renamings”. A renaming is a graph isomorphism, where the domain of the renaming is allowed to be a superset of the set of vertices/edges of the graph. In this way, the same renaming can be applied to various graphs with different vertex and edge sets.

Definition 4

(Graph Renaming). A graph renaming for a graph G consists of two bijective functions and such that and .

The -renaming of G, denoted , is the graph defined by

for every .

Definition 5

(Graph Isomorphism). Graphs G and H are isomorphic, denoted , if there is a graph renaming such that .

Let L be a finite nonempty set of labels. In the sequel, we tacitly assume that all graphs have labels from L.

As motivated by the preceding sections, we allow to compose a context graph C and a match graph M by a “patch” J that may add edges between the nodes of C and M, as well as between the nodes of M.

Definition 6

(Patch). Let C and M be disjoint graphs. A patch for C and M is a graph J such that and , and

for every edge . In this relation mediated by J, we call C the context graph and M the match graph.

Definition 7

(Patch Composition). Let J be a patch for a context graph C and a match graph M. The patch composition of C and M through patch J, denoted by , is the graph union .

Example 8

Consider the following graphs C, M and G, respectively: The composition of C and M through patch is G, in which C functions as the context graph and M functions as the match graph (w.r.t. J).

Before we consider the formal definition of rewriting, let us discuss the basic principle and motivate some of the design choices. As a first approximation, a graph rewrite rule is a pair of graphs that behave like patterns. Since the edge and vertex identities in such rules are arbitrary (not to be confused with the edge labeling), we close the rule under isomorphism. The rule should also be applicable in contexts in which a patch connects a context and the pattern of the rule. The rule thus give rise to rewrite steps of the form for graphs C, valid patches and graphs and .

Additionally, we would like to exert control over the shape of patches in two ways. A graph rewriting rule should enable one to (a) constrain the choices for the patch J, and (b) define the patch in terms of J. For these purposes, we introduce the concepts of a patch type and a scheme.

Definition 9

(Patch Type). A patch type T for a graph G is an unlabeled patch for G and the trivial graph with node set . Here, the trivial graph functions as the context graph.

Let J be a patch for a context graph C and match graph M, and T a patch type for M. A patch edge ( any label) adheres to a patch type edge if the following conditions hold:

The patch J adheres to patch type T if there exists an adherence map from J to T, i.e., a function such that e adheres to f(e) for every .

The restriction to unlabeled patch type edges is motivated purely by simplicity. We intend to relax the definition in future work.

Proposition 10

(Unique Adherences). Let the patch type T be a simple graph. If a patch J adheres to T, then the witnessing adherence map is unique.

Intuitively, we use patch types to annotate the patterns of a rewrite rule. The result we call a scheme.

Definition 11

(Scheme). A scheme is a pair (P, T) consisting of a graph P, called a pattern, and a patch type T for P.

Example 12

(Depicting Schemes). We extend the representation for graphs to schemes (P, T) as shown on the right. The pattern P consists of the solid labeled arrows, and the patch type T consists of the dotted arrows. For dotted arrows without a source (or target), the source (or target) is implicitly the context graph node . So T consists of the edges .

We are now ready to define a graph rewrite rule as a relation between schemes and . We equip the rewrite rule with a “trace function” that relates edges in back to edges in , allowing us to interpret as a transformation of , in which patch edges may be freely moved, deleted, duplicated and inverted. For this we require the following constraint: if a patch type edge connects to the context, the corresponding edge must also connect to the context. Without this constraint, it would not be clear how to interpret e’s connection to the context.

Definition 13

(Quasi Patch Graph Rewrite Rule). A quasi patch graph rewrite rule is a pair of schemes and , equipped with a trace function that satisfies for all .

We normally require the left patch type to be simple, so that the edges of -adherent patches J adhere to a single edge in  (Proposition 10). As we shall see, this allows us to define a graph rewrite relation in which matches of a rule produce a unique result (modulo ).

Definition 14

(Patch Graph Rewrite Rule). A patch graph rewrite rule is a quasi patch graph rewrite rule in which is simple.

Since we restrict attention to unlabeled patch type graphs in this paper, we will use the opportunity to visualize the trace function by means of labels on patch type edges.

Example 15

(Depicting Rules). A depiction of a valid rewrite rule is: The trace function is visualized by means of labels on the type edges: maps type edges with label n on the right-hand side to the type edge with label n on the left-hand side. Throughout the paper, colors are merely used as a supplementary visual aid. (An application example will be given in Example 19.)

Definition 16

(Rule Isomorphism). (Quasi) rewrite rules and are isomorphic, denoted , if there exists a graph renaming such that , , and .

Definition 17

(Patch Graph Rewrite System). A (quasi) patch graph rewrite system (PGR) is a set of (quasi) rewrite rules. For we define the isomorphism closure class .

For a patch J, patch type T and adherence map , we define

for every . So contains the context node involved in the edge e, or is if the edge does not involve the context.

Definition 18

(Patch Graph Rewriting). A (quasi) patch graph rewrite system induces a rewrite relation  on the set of graphs as follows:

if

• (i),
• (ii) is an adherence map from patch J to patch type ,
• (iii) is an adherence map from patch to patch type , and
• (iv)for every there exists a bijection such that and for every .

For such a rewrite step, we say that the graph contains the redex .

Example 19

(Application Example). The rule given in Example 15 gives rise to the following rewrite step: In the graph on the left we have highlighted the match (thick green) and the patch (dotted). We have additionally indicated the adherence map of the patch edges by reusing the colors of the rule definition.

We refer to Sect. 2 for many examples of simple rewrite rules and rewrite steps. A graph rewrite system modeling wait-for-graphs will be given in Sect. 4.

Remark 20

(Finding Redexes). Checking for the presence of a redex is simple. A graph G contains a redex with respect to rule if and only if

1. there exists a subgraph M of G isomorphic to , and

2. every edge incident to a adheres to an edge in .

Definition 18 can be understood in more operational terms as follows.

Lemma 21

(Constructing ). If conditions (i) and (ii) of Definition 18 are satisfied (fixing some adherence map ), the patch and adherence map that satisfy conditions (iii) and (iv) are uniquely determined up to isomorphism. The patch can be constructed using the following procedure.

For every type edge , consider every patch edge for which . There are five exclusive cases:

1. If , add a new edge to .

2. If , add a new edge to .

3. If , add a new edge to .

4. If , add a new edge to .

5. If , add a new edge to .

Here, the “new” edge is an edge not in C, or the intermediate construction of . The adherence map is defined such that for each of the considered and t.

Non-quasi rules have the following desirable property.

Proposition 22

(Rule Determinism). Let . If a rule derives both and , then .

Proof

This is a direct consequence of Proposition 10 and Lemma 21.    

In contrast to (non-quasi) graph rewrite rules, quasi rules are not generally deterministic. For instance, consider the quasi rewrite rule which can match any graph G consisting of two nodes x and y and n edges from x to y. For each , the left adherence map can either map e to the patch type edge labeled with 1, or to the type edge labeled with 2. Thus, choices for are possible, and each choice causes a different subset of J to be deleted in a single rewrite step.

Notation 23

(Shorthand Notation). Given a pattern P, we often want to allow for any patch edges between the nodes of a subset as well as the context node . In the notation we have discussed so far, we would then need to draw the complete patch type graph induced by (minus the loop on ), which consists of patch type edges.

To avoid spaghetti-like figures, we extend the visual presentation of schemes by allowing each node to be annotated with a set of names (written without set brackets). We say that a node has name x if x is in the set of names of this node. So a node can have 0 or more names. The name annotations are then shorthand for the following patch type edges:

• (i)For every node n and name x of n, the node n has the two patch type edges from and to the context.
• (ii)For every pair of nodes n, m and every name x of n and y of m, there is implicitly the patch type edge from n to m. Here n and m can be the same node, and x can be equal to y.

Observe that rules are non-quasi iff every node in the left-hand side has at most one name. We therefore require that distinct nodes do not share names.

As an example, a rule for merging two nodes can be written as

1

which is shorthand for

Modeling Wait-for Graphs and Deadlock Detection

We now give a more extensive and more realistic modeling example that showcases the expressive power of PGR.

A wait-for graph [14] is a hypergraph in which nodes represent processes, and hyperedges represent requests for resources. A hyperedge has a single source p, representing the process requesting the resources, and targets distinct from p, representing the processes from which a resource is requested. The process p requires of these resources. Thus, for a fixed M, there are multiple types of hyperedges, each representing a particular N-out-of-M request. Processes can have at most one outgoing N-out-of-M request.

The following distributed system behavior is associated with wait-for graphs. A process without an outgoing request is said to be unblocked. An unblocked process can grant an incoming request, deleting the edge, or create a new N-out-of-M request. A process becomes unblocked when its pending N-out-of-M request is resolved, i.e., when N targeted processes have granted the request.

In order to better illustrate some of PGR’s transformational power, we introduce one additional, noncanonical behavior. We consider a process p overloaded when it has incoming requests. When p is overloaded, a clone of p, c(p), may be created which takes over of p’s incoming requests. Because we assume that any outgoing request must be resolved before any incoming requests can be resolved, c(p) replicates p’s outgoing request, if p has one.

We first define a graph grammar that defines the class of valid wait-for graphs. Then, we will show how to augment the rule set in order to model the distributed system behavior. Finally, we explain how deadlocks can be detected. Throughout, we encode hypergraphs as multigraphs. Note that in this encoding, vertices representing processes are always free of loops, while vertices representing hyperedges always have loops. Hence, the given rules can appropriately discriminate between the two types of vertices.

Wait-for Graph Grammar

The starting graph of the grammar is the empty graph, denoted by . Rule

models process creation, and rule

allows constructing a valid 1-out-of-1 request between nodes. Labels z and s should be interpreted as 0 and the successor function, respectively, so that n s-loops encode that n requests are yet to be granted.

In the grammar, any N-out-of-M request can be extended to a valid N-out-of- request using rule

and to a valid -out-of- request using rule

These four rules suffice for generating any valid wait-for graph.

System Modeling

To model a distributed system, we need rule CREATE for process creation, as well as its inverse, destroy, for process destruction. Note that destroy constrains the process selected for destruction to be isolated in our framework (i.e., it is not associated with any pending requests), as desired.

Any N-out-of-M request is understood to be an atomic action. So for, e.g., modeling 2-out-of-2 requests, we need the rule

Such rules can be easily simulated by a contiguous sequence of rewrite steps 1-OF-1 EXT-0 EXT-1, in which the node making the request remains fixed. We omit the details.

A grant request may be modeled by

and a request resolution by

This leaves only the cloning behavior for an overloaded process p. This requires two rules: one for the case in which p is unblocked, and one for the case in which p is blocked. We use the shorthand notation introduced in Notation 23, so that named nodes induce type edges among themselves and from and into the context.1

The case in which p is unblocked is modeled by rule

and the case in which p is blocked is modeled by rule

Cloning would be easier to express if PGR were to be extended with support for hyperedges and cardinality constrained type edges. We envision a rule like

to capture the same cases as rules CLONE-1 and CLONE-2 combined. We leave such an extension to future work. In particular, the precise semantics of hyperedge transformation would have to be determined.

Deadlock Detection

Deadlock detection on some valid wait-for graph G can be performed by restricting the rewrite system to rules GRANT, RESOLVE and destroy, yielding a terminating rewrite system. Then the network represented by G contains a deadlock if and only if the (unique) normal form of G is the empty graph .

Comparison

We compare PGR to several other rewriting frameworks. We have selected these frameworks because of their popularity and/or because they bear certain similarities to our approach.

Double-Pushout (DPO). Ehrig et al.’s double-pushout approach (DPO) [9] is one of the most prominent approaches in graph rewriting.

A rewrite rule in the DPO approach is of the form , where L is the subgraph to be replaced by subgraph R. The graph K is an “interface”, used to identify a part of L with a part of R, and it can be thought of as describing which part of L is preserved by the rule. The identification is formally established through the inclusion and the graph morphism . The morphism may be non-injective, allowing it to merge nodes that are in the interface.

A DPO rewrite rule is applied inside a graph G as follows [7, 8]. Let be a graph morphism, which we may assume to be injective [16]. The graph is said to be a match for L. The arising rewrite step replaces m(L) of G by a fresh copy c(R) of R, redirecting edges left dangling by the removal of a to node . For the redirection of edges to work, nodes that leave dangling ends need to be part of the interface, that is, in . This is known as the “gluing condition”.2 If the gluing condition is not met, the rewrite step is not permitted.

Using Notation 23, it is easy to see that PGR at least as expressive as DPO with respect to the generated rewrite relation. A DPO rule can be directly simulated by a PGR rule in which the nodes are annotated with their (set of) names in the interface: is annotated with the names , and is annotated with the names .

However, DPO is stronger in one respect: a DPO rewrite step preserves the subgraph specified in K, whereas a PGR rewrite can be thought of as destroying and replacing the left-hand side of the rule. The consequences for metaproperties relating to parallelism and concurrency will have to be investigated.

Generalized DPO. In some variants of DPO, the inclusion is generalized to a (possibly non-injective) morphism . Intuitively, this allows a node v of L to be “split apart” in the interface K. Applying the DPO method to a host graph ensures that the patch graph edges incident to v will be incident to one of v’s split copies. It does not dictate how these edges should be distributed. Thus, such rewrite steps are non-deterministic.

Generalized DPO rules can be translated to PGR rules in the same way as discussed for DPO. Since is no longer required to be injective, nodes can be annotated with multiple names , thereby leading to (non-deterministic) quasi rules (Definition 13).

Single-Pushout (SPO). The single-pushout (SPO) approach by Löwe [18] is the destructive sibling of DPO. It is operationally like DPO, but it drops the gluing condition. Any edges that would become dangling in the host graph are instead removed.

An SPO rule can be simulated by a PGR rule with annotations as discussed above for DPO, except that each node , for which is empty, is now annotated by a fresh name. The rewrite step will then delete all patch edges connected to such a node.

DPO Rewriting in Context (DPO-C). The DPO Rewriting in Context (DPO-C) approach by Löwe [19, 20] addresses the issue of non-determinism in generalized variants of DPO, using ingoing and outgoing arrow annotations to dictate how these edges should be distributed over split copies. The visual representation of DPO-C therefore bears some similarity to that of PGR. In addition, absence of arrow annotations also define negative application conditions like in PGR. However, the patch cannot be transformed as freely as in PGR. For instance, see rule (2) below.

AGREE. AGREE [3] and PBPO [4] by Corradini et al. extend DPO with the ability to erase and clone nodes, while also being able to specify how patch edges are distributed among the copies. For this purpose, a “filter” for the edges determines what kind of patch edges are to be dropped. This filter can distinguish different types of edges based on their source, target and label. Thereby AGREE and PBPO subsume mildly restricted versions of DPO, SPO, and other formalisms.

PGR has some features that are not present in AGREE and PBPO. First, in PGR rule applicability can be restricted by conditions on the permitted shape of the patch. Second, PGR allows (almost) arbitrary redirecting, moving and copying of patch edges outside the scope of AGREE and PBPO. For instance,

2

cannot be expressed in the latter frameworks. Also inverting the direction of patch edges, or moving patch edges between nodes of the pattern is not possible in AGREE and PBPO.

On the other hand, AGREE and PBPO capture some transformations that cannot be expressed in PGR. First, AGREE and PBPO can express some global transformations, unlike PGR. Second, the “patch edge filter” in AGREE and PBPO can distinguish patch edges depending on their label and the “type” of the source/target in the context (here the type is given by some type graph). Both features are not present in PGR as presented in this paper. However, PGR can be extended with constraints on the patch type edges. We leave the investigation of a suitable constraint language to future work.

Nagl’s Approach. Nagl [21] has defined a very powerful graph transformation approach. Rather than identifying “gluing points” for the replacement of L by R in a host graph G (as in the previous approaches), rules are equipped with expressions that describe how R is to be embedded into the remainder graph . An expression can, e.g., specify that an edge must be created from to if there existed a path (of certain length and containing certain labels) from u to a . Thus, the embedding context may no longer even be local.

While not all of these transformations are supported by PGR, the expressions are arguably much less intuitive than our representation, in which both application conditions and transformations are visualized in a unified manner.

Habel et al.’s Approach. Habel et al. [15] have introduced graph grammars with rule-dependent application conditions that also admit a very intuitive visual representation. These conditions are more powerful than PGR’s application conditions, since they can extend arbitrarily far into the context graph. However, transformations are not included in the approach, unlike in PGR, in which the notations for application conditions and transformations are unified.

Drags. To generalize term rewriting techniques to the domain of graphs, Dershowitz and Jouannaud [6] have recently defined the drag data structure and framework. A drag is a multigraph in which nodes are labeled by symbols that have an arity equal to the node’s outdegree. Nodes labeled with nullary variable symbols are called sprouts, and resemble output ports. In addition, the drag comes equipped with a finite number of roots, which resemble input ports.

A composition operation for drags, parameterized by a two-way switchboard  identifying sprouts with roots, gives rise to a rewrite relation . For this rewrite relation to be well-defined, it is required, among others, that L and R have the same number of roots and the same multisets of variables.

Since drag rewriting imposes arity restrictions on nodes, it is more restrictive than patch rewriting concerning the shapes of the graphs that can be rewritten. As drag rewrite steps are local, we believe that PGR can simulate them, but we leave this investigation to future work.

Conclusion

We have introduced patch graph rewriting, a framework for graph rewriting that enriches the rewrite rules with a simple, yet powerful language for constraining and transforming the local embedding—or patch.

For future work, we plan to investigate various meta-properties central in graph rewriting [8], in particular confluence [12, 17, 22], termination [2, 5], the concurrency theorem [10], decomposability and reversibility of rules. We intend to study these properties both globally, for all graphs, as well as locally [11, 13], for a given language of graphs [23]. Furthermore, we are interested in extending the framework with constraint labels on patch type edges, and in allowing label transformations. We believe this could be useful for modeling a larger class of distributed algorithms [14]. Another interesting direction of research is an equational perspective on patch rewriting, as similarly investigated by Ariola and Klop for term graph rewriting [1].