Process Model Representations

• Process Model Representations (PMRs) are formal or semi-formal methods that encode process knowledge using notations, schemas, and graphs.
• They support process specification, analysis, communication, and machine learning-driven generation, offering varied levels of abstraction.
• PMRs integrate meta-models, event logs, and vector embeddings to facilitate tasks such as mining, alignment, visualization, and evolution management.

Searching arXiv for recent and foundational papers on process model representations and closely related formulations. Process model representations (PMRs) are formal or semi-formal means of expressing process knowledge, and the literature treats them at multiple levels: as notations for encoding a process model, as schema-grounded graphs of entities and relations, as event-log and visualization formats for the process of process modeling, as abstract representations for stream-based discovery, as RDF comparison models for alignment and evolution, and as vector embeddings for similarity, clustering, and retrieval (Brissard et al., 15 Jul 2025). Rather than denoting a single canonical artifact, PMRs designate a family of representational regimes that differ in ontology, granularity, computational properties, and intended use; taken together, the surveyed work presents PMRs as the representational infrastructure through which processes are specified, analyzed, maintained, communicated, and increasingly generated by machine learning systems.

1. Conceptual scope and terminological plurality

A useful baseline distinction separates the process model, the process model representation, and the PMR model. In the comparative analysis of PMRs for large-language-model-based process modeling, a process model is an abstract model of a business process independent of notation, a PMR is the notation or language used to express that model, and a PMR model is a concrete process model encoded in that representation (Brissard et al., 15 Jul 2025). This view aligns with meta-model-based BPM research, where a business process meta-model makes explicit the constructs and rules by which process models are built, thereby functioning as an explicit conceptual PMR (Adamo et al., 2020).

In process-engineering settings, PMRs are often not defined as a standalone term, but are embodied in the way process standards and derived process models are represented, versioned, and compared. In the V-Modell XT case, the representation is a graph of typed entities with persistent identifiers, attributes, and typed relations, stored in XML and normalized to RDF for comparison and alignment tasks (Soto et al., 2014). In process mining, the same broad idea appears under “abstract representations”: directly-follows graphs, prefix-closures, and transition systems are intermediate process representations maintained from event streams and then mapped to discovered models (Zelst et al., 2017).

This plurality extends beyond static process descriptions. PPMCharts represent the process of process modeling rather than the modeled business process: one modeling session becomes an event log, each model element corresponds to a trace, and the resulting chart encodes the temporal sequence of create, move, delete, and rename operations (Claes et al., 2015). Event- and scenario-centric frameworks likewise distinguish abstract scenarios from concrete processes, treating a scenario as a Seq-Set of appearances or connected appearances and a process as a Seq-Set of events, coincidences, or connected coincidences (Kolonin, 2018).

A terminological caveat is necessary because the acronym PMR is overloaded. In graph database research, PMR denotes Path Multiset Representation, a compact representation of multisets of graph paths rather than a process model representation in the BPM sense (Yang et al., 2022). This does not invalidate the BPM usage, but it does show that the acronym is context-sensitive.

Representational family	Core structure	Exemplary source
Meta-model / notation PMR	Language constructs and rules for process models	(Adamo et al., 2020)
Typed graph PMR	Entities, attributes, relations, stable identifiers	(Soto et al., 2014)
Event-log / PPM visualization PMR	Traces and time-stamped modeling operations	(Claes et al., 2015)
Stream discovery PMR	Directly-follows, prefix-closure, transition system	(Zelst et al., 2017)
Scenario / event PMR	Appearances, situations, scenarios, processes	(Kolonin, 2018)
Embedding PMR	Dense vectors for Petri nets and tasks	(Colonna et al., 2024)
DSML / profile PMR	SysML stereotypes, OCL constraints, XML serialization	(Beers et al., 2024)

2. Structural foundations: meta-models, graphs, and schemas

The most established PMR tradition is meta-model-based and graph-structured. The systematic literature review of business process meta-models identifies 65 primary studies and reports 682 distinct meta-model elements, grouped into 15 macro-elements, with 154 elements recurring in at least two meta-models (Adamo et al., 2020). The dominant representational style is procedural and activity-centric: 50 of the 65 studies are procedural, 11 declarative, 3 hybrid, 60 activity-centric, and 4 artefact-centric. The same review reports that only activity appears in more than 50% of the meta-models, while 21 elements appear in at least 15% of them; recurring constructs include activities, gateways, sequence flows, preconditions, artifacts, actors, organisation units, roles, and goals. This pattern indicates a strong consensus around control-flow and a weaker one around data, organization, value, context, and goals.

The graph-based character of PMRs becomes fully explicit in large industrial process standards. V-Modell XT version 1.2 contains about 2100 entities, more than 5000 attributes, and about 4100 relations under a schema with 38 classes and 43 relation types (Soto et al., 2014). Entities are instances of schema classes such as process module, role, activity, product, tailoring dependency, and structural dependency; each has a universal unique identifier assigned at creation time and preserved across versions. Relations include containment (vmxt:enthält), based-on links, structural dependencies, tailoring dependencies, and references to roles, products, and tools. The representation is explicitly described as an arbitrary graph structure rather than a pure tree, even though it supports hierarchical decomposition through containment.

A central lesson of this literature is that PMRs are not reducible to their serialization formats. In V-Modell XT, instances are stored as XML files and documentation is generated automatically from the model structure, but XML is only a serialization, not the conceptual representation (Soto et al., 2014). The same distinction appears in BPM meta-model work more broadly: what matters is the schema of classes, relations, and constraints that define what a valid process model can contain (Adamo et al., 2020).

This graph-and-schema view also explains why PMR design decisions have long-term effects. Stable identifiers, explicit relation types, and a shared metamodel make identity-based comparison, schema-specific querying, and fine-grained change analysis tractable (Soto et al., 2014). A plausible implication is that PMRs designed primarily for human-readable documents, without stable typed entities and explicit edges, forfeit much of the analytical leverage later required for maintenance, mining, and automated support.

3. Event, behavior, and process-centric representations

A second major line of work shifts attention from the static process artifact to behavior, event structure, and the modeling process itself. In PPM research, the relevant process is the process of process modeling. Here, the resulting BPMN-like model is only the end product; the PMR of interest is the event log of modeling operations and its visualization as a PPMChart (Claes et al., 2015). The log follows a ProM/xES-style structure in which a process corresponds to one modeling session, a trace bundles all operations on one model element, and each event stores at least concept:name, time:timestamp, and an element identifier. The PPMChart maps each model element to one horizontal line, places operation events as dots along a one-hour time axis aligned to the right, and uses a fixed global color mapping: green variants for create operations, blue for move, red for delete, and pink/purple for reconnect or rename.

Because the PPMChart is a PMR of modeling behavior, not of domain behavior, it reveals phenomena that static notations suppress. The literature reports patterns such as immediate tidy-up versus late layouting, chunked process modeling separated by visible pauses, different orders for creating nodes and edges, and different strategies for constructing blocks of alternative or parallel behavior (Claes et al., 2015). The extended visual analysis shows that this representation helps distinguish structured from chaotic modeling behavior, highlights deletions and rework, and supports hypothesis generation about links between modeling style and resulting model quality (Claes et al., 2015).

Event-centric PMRs also underpin process discovery from streams. In the S-BAR architecture, a stream is simplified to case–activity pairs and defined as

$S \in (C \times A)^*$

with update and abstraction functions that maintain a finite-memory data structure and derive an abstract representation for process discovery (Zelst et al., 2017). The core functions are

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$

$\alpha_D^T \colon U_{D^T} \to U_{A^T},$

and

$\gamma^T \colon U_{A^T} \to U_M.$

Here the PMR is the maintained abstract representation of type $T$: directly-follows relations, prefix-closures, or transition systems. This formulation makes explicit that many discovery algorithms do not operate on raw event streams or logs directly; they operate on incrementally maintained PMRs.

Other behavioral PMRs make the distinction between abstract and concrete levels explicit. In the scenario framework for process evolution management, roles, appearances, situations, and scenarios form the abstract level, while actors, events, coincidences, and processes form the concrete level (Kolonin, 2018). A scenario is a Seq-Set of appearances or connected appearances, whereas a process is a Seq-Set of events, coincidences, or connected coincidences. The framework provides functional mappings between abstract and concrete constructs, supporting causal analysis, situational fork detection, and situational trigger differentiation. This suggests a PMR architecture in which process models are explicitly connected to runtime traces through typed abstraction relations, rather than only informally associated.

A related but distinct event-centered formulation is the Flowthing Machine language, which separates description, behavior, and control (Al-Fedaghi et al., 2017). Its primitive notion is a thing flowing through a machine with mutually exclusive stages—Arrive, Accept, Receive, Process, Create, Release, and Transfer—and behavior is obtained by “eventizing” a static script into temporally ordered events. Control is then expressed by event-sequence specifications such as

$$\text{Process: Event 1, Event 2, Event 3, if Event 4 then repeat Process.}$$

In representational terms, this is a PMR that insists on an explicit distinction between structural script, dynamic events, and control constraints.

4. Analytical, comparative, and learned representations

PMRs also function as computational substrates for comparison, querying, and learning. In the DeltaProcess approach, XML-based process models are converted to a normalized triple-based notation, namely RDF, and comparison is performed over a merged comparison model whose statements are annotated by version membership through RDF reification (Soto et al., 2014). A triple such as e1 vmxt:Name "Design" is reified so that assertions can be made about which model version contains it. Change types—attribute changes, additions, deletions, moves, and relation changes—are then specified as SPARQL patterns over these reified statements. In this formulation, the PMR is not only the original model graph but also the comparison graph that explicitly represents inter-version differences.

The same representational strategy underlies longitudinal evolution analysis. The Evolyzer study of V-Modell XT imported 604 versions over a little more than two years; four versions were skipped because they were syntactically invalid XML (Soto et al., 2014). Each version was converted to RDF without adding or removing information, and comparison models were queried to analyze changes over time. The study reports growth from about 850 to over 1000 entities in the process modules across the analyzed versions, uneven change distribution across modules, and clustering of change activity around releases. Here the PMR is simultaneously the authoring structure, the RDF analysis graph, and the temporal series of its revisions.

A more recent line of work maps symbolic process models into vector spaces. PetriNet2Vec treats Petri nets as symbolic PMRs and learns model-level and task-level embeddings by analogy to Doc2Vec (Colonna et al., 2024). The process model $M_j$ and task vocabulary $\mathbb{T}$ are mapped into vectors $\mathbf{x}_j \in \mathbb{R}^d$ and $\mathbf{t}_i \in \mathbb{R}^d$, learned from directly-follows pairs extracted from a DFG transformation of the Petri net. The stated objective is

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$0

In the reported evaluation on 96 PDC Petri nets, the best configuration used $$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$1, HDBSCAN minimum cluster size 4, and the “single None token” handling of silent transitions, yielding a silhouette of approximately 0.73 and 9 discovered clusters (Colonna et al., 2024). These embeddings supported clustering, process classification, and retrieval via cosine similarity. The representational shift is substantial: exact symbolic structure is compressed into dense latent vectors that preserve enough structural signal for downstream tasks but no longer provide directly interpretable dimensions.

This movement from XML and RDF graphs to embeddings does not replace earlier PMRs; it adds another layer. A plausible reading of the literature is that contemporary process-analysis pipelines increasingly stack PMRs: a symbolic process graph may be normalized into triples for querying, then further projected into vectors for clustering or retrieval. Each layer privileges different operations—semantic precision, flexible comparison, or statistical learning.

5. Comprehensibility, quality, and evolution management

PMRs are not evaluated only by expressiveness or computational convenience; they are also assessed by how well humans can create and understand them. The Process Model Comprehension Framework (PMCF) treats the process model as a communication artifact between process modeler and process reader and operationalizes comprehension through an Evaluation Theory Tree with two roots, one for each perspective (Winter et al., 2021). PMCF considers 96 quality metrics, organized into criteria such as Process Modeling Language, Process Modeling Tool, Information, Errors, Person, Process Modeling Guidelines, Medium, Level of Detail, Representation Factors, and Comprehension Questions. The metric weights were calibrated in a survey with 131 participants using the weighted arithmetic mean

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$2

with DNLog weighting

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$3

PMCF also formalizes a language-complexity metric. For a modeling language $$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$4,

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$5

captures the number of elements, characteristics per element, and relationships per element, and its raw complexity is

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$6

Workflow pattern support is represented as

$$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$7

where $$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$8, $$\delta \colon U_{D^T} \times C \times A \to U_{D^T},$$9, and $\alpha_D^T \colon U_{D^T} \to U_{A^T},$0 count fully and partially supported control-flow, data, and resource patterns (Winter et al., 2021). In a practical case study with 33 participants, explicit representations of start events, end events, loops, parallelism, and decomposition consistently produced higher comprehension-question scores than implicit variants. PMCF therefore frames representational choices—explicit versus implicit control-flow, level of detail, structural factors—not as stylistic preferences but as measurable comprehension determinants.

A complementary quality dimension is maintainability under change. The alignment study of a heavily tailored V-Modell XT derivative asked whether a strongly tailored model could still be aligned with its evolving parent standard (Soto et al., 2014). More than half of the original entities had been deleted during tailoring, yet about 64% of the tailored model’s entities were still shared with the standard. Between standard versions 1.1 and 1.2, 536 entities changed; among the changed entities still present in the tailored model, 96 had changed without conflict and 180 had conflicting attributes, yielding 276 changed entities needing alignment consideration. The study also reports 286 new entities in the standard, with the analysis suggesting that 40–50% of them could likely be ignored because they had no relations to entities surviving in the tailored model. No entity deleted from the standard was still present in the tailored model, and among 86 moved entities, 14 were moved by the standard but not by the tailored model, with no conflicting moves (Soto et al., 2014).

Longitudinal evolution analysis reinforces this view of PMRs as living artifacts. The complete history of V-Modell XT showed concentrated change activity around releases and repeated changes to the same entities, supporting the conclusion that process model change management is not simpler or less risky than software change management (Soto et al., 2014). Taken together, these studies imply that PMRs should be designed for evolution from the outset: stable identifiers, explicit structure, modularity, and analyzable comparison formats are not ancillary conveniences but preconditions for disciplined maintenance.

6. Standardization, interoperability, and contemporary comparative results

A major recent direction is the standardization and interoperation of PMRs across engineering environments. The SysML profile for the VDI/VDE 3682 Formalised Process Description embeds a domain-specific process language into SysML as a lightweight DSML (Beers et al., 2024). In this profile, a Process is a stereotype on Activity, a Process Operator on CallBehaviorAction, Technical Resource on Class, and state-describing elements such as Product, Energy, and Information are mapped to ActivityParameterNode or ObjectNode depending on whether they lie on the system boundary or are intermediate states. OCL constraints encode core well-formedness conditions, including the prohibition of direct state-to-state flows. One explicit invariant given for Flow forbids source and target both being state elements, thereby enforcing the standard’s requirement that every state be associated with a process operator (Beers et al., 2024). The profile also supports automatic XML serialization through Velocity Template Language, allowing FPD models to be used outside MBSE environments.

This profile-based work shows a specific form of PMR consolidation: standard semantics, tool-level constraints, and an interchange format are all aligned. The authors validated the approach on an aircraft-assembly collar-screwing use case, where a process operator transformed inputs such as Collar, Rivet Position, and Electrical Energy into outputs such as Screwed Collar and Thermal Energy (Beers et al., 2024). In representational terms, the PMR is simultaneously a diagrammatic notation, a metamodel extension, a constraint system, and a serialization schema.

A different contemporary issue concerns PMRs as target languages for LLMs. The comparative analysis of nine PMRs for process modeling with LLMs introduced the PMo Dataset with 55 process descriptions paired with models in nine different PMRs: BPMN, BPMN process, Graphviz, Mermaid, PME, Simplified XML, POWL code, BPMN text, and JSON branches (Brissard et al., 15 Jul 2025). The study evaluated PMRs along six PMo criteria—token compactness, expressivity, human readability, visualization capabilities, usability, and extensibility—and also assessed process-model-generation performance. Mermaid achieved the highest overall score across the six PMo criteria, whereas BPMN text delivered the best PMG results in terms of process element similarity (Brissard et al., 15 Jul 2025).

The empirical trade-offs are explicit. Mermaid showed the largest reductions relative to BPMN—about 91% fewer lines and about 93% fewer tokens and words—while BPMN process reduced token count by about 70% (Brissard et al., 15 Jul 2025). PME and Simplified XML preserved full element coverage in the dataset, while branch-based formats such as BPMN text and JSON branches were more limited in expressivity but performed better as generation targets. This indicates that the “best” PMR depends on the task: compact, visual, and human-readable representations suit interactive modeling and explanation; branch-oriented or schema-constrained textual representations can be superior for generation fidelity.

Across the literature, no single PMR emerges as universally optimal. Instead, PMRs form a layered design space spanning typed graphs, meta-models, event logs, transition systems, causal scenario structures, constrained DSMLs, RDF comparison models, and vector embeddings. The accumulated evidence suggests that the central design variables are explicitness of semantics, stability of identity, structural analyzability, cognitive fit for human users, and compatibility with downstream computation—whether the downstream task is alignment, mining, visualization, formal verification, retrieval, or generation (Adamo et al., 2020).