GOProQ: A Graphical Query Language for Object-Centric Process Analysis

Gyunam Park, Jan Niklas Adams, Daniel Schuster
January, 2026
PDF Cite DOI

Abstract

Service-oriented architectures facilitate distributed business processes where multiple services collaborate to achieve business goals. However, traditional process mining approaches rely on single-case event logs that fail to capture the complex interactions between services and their associated data objects. Object-Centric Event Logs (OCELs) address this challenge by modeling service processes as graphs of interconnected events and objects, providing a foundation for comprehensive service analysis. While existing querying approaches offer capabilities for traditional event data, they lack the expressiveness needed for analyzing object-centric service interactions. This paper introduces GOProQ, a graphical query language specifically designed for querying object-centric service processes. We identify key requirements for service-oriented process querying, define a formal language that addresses these requirements, and implement an interactive tool for service analysts. Our evaluation across multiple real-world service datasets demonstrates GOProQ’s expressiveness and performance for service monitoring in complex service-oriented environments.

Type
Conference paper
Publication
Service-Oriented Computing - 23rd International Conference, ICSOC 2025, Shenzhen, China, December 1-4, 2025, Proceedings, Part II

Practical problem

Service analysts monitoring distributed processes need to ask questions that span several interacting objects at once, such as orders whose items come from multiple suppliers and whose payment arrived before all deliveries completed. Object-centric event logs (OCELs) record such executions as graphs of events connected through shared objects, but the available query languages were built for single-case logs or for general graph databases. Compliance rule graphs, DCR graphs and process-instance query languages assume one case per event, and general-purpose languages such as Cypher become hard to write and slow for multi-object patterns. Analysts therefore lack a way to express and run cross-service queries, for example for service-level agreement monitoring, without hand-written code.

Research questions

  1. Which querying dimensions and expressiveness requirements does a query language for object-centric service process executions have to cover?
  2. How can a graphical query language be defined, with formal syntax and semantics, that covers nodes and edges labelled by both activities and object types, including cardinality, directly- and eventually-follows relations and logical composition?
  3. Is such a language feasible in practice on real-world OCELs in terms of computation time, and how much does query reordering help?

Contributions

  • A two-dimensional requirements framework for querying service process executions: structural elements (event nodes, precedence edges) crossed with label types (activities, object types), plus four expressiveness and three performance requirements.
  • GOProQ, a graphical query language with formal syntax and semantics over service process executions derived from OCELs, covering object-type queries, activity presence/start/end queries, directly-follows and eventually-follows queries with cardinality constraints, and AND/OR/NOT composition.
  • A query-reordering evaluation strategy that runs cheap object-type and activity queries before control-flow queries and NOT before AND before OR, to prune non-matching executions early.
  • An interactive tool to import OCELs, compose queries graphically, execute them and visualize matching executions, released with a user manual on GitHub (gyunamister/GOProQ).
  • An evaluation on six public OCELs (two loan-application logs, recruiting, travel reimbursement, procure-to-payment, order-to-cash; up to 392,018 events and 31,305 executions).

Key findings

  • The tool covers every cell of the requirements matrix, including cardinality constraints, the directly- versus eventually-follows distinction and logical composition, so the expressiveness requirements are met by construction.
  • Object-type queries are the cheapest (0.0009 s to 0.2261 s per dataset), activity queries cost more (up to 12.6 s on the large loan log) and eventually-follows queries are the most expensive (20.7 s on the large loan log).
  • Eventually-follows queries could not be completed in reasonable time on the travel-reimbursement and procure-to-payment logs, whose executions contain thousands of nodes (8,481 nodes and 8,611 edges in one travel-reimbursement execution).
  • The reordering strategy lowers computation time on every dataset against random query order; on the recruiting log the median time drops by 57.1%, and with reordering all datasets except the large loan log answer queries in under 3 seconds.
  • Limitations: direct object-to-object relations not mediated by activities are not queryable, large executions still exceed interactive response times, and deeply nested graphical queries become cognitively demanding.