Towards Representing Processes and Reasoning with Process Descriptions on the Web

Upper ontologies aim to describe general concepts in modelling such that domain ontologies built using these upper ontologies follow a principled approach and do not conflate (metaphysical) categories. Often, upper ontologies distinguish between continuants (endurants) and occurrents (perdurants). Continuants are “three-dimensional”, i.e, exist in space only, while occurrents are “four-dimensional”, i.e, can exist in space and time.

The notion of a process appears in domain-independent and upper ontologies. While in the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) [15] itself does not specifically consider processes, other works use DOLCE to talk about processes and plans, e.g, [83]. The Basic Formal Ontology (BFO) [84] contains a term for Process¹¹1http://purl.obolibrary.org/obo/BFO_0000015, and [97] details how to represent continuants (covering space) and occurrents (covering space and time). In the Unified Foundational Ontology part B (UFO-B), or UFO’s incarnation OntoUML, events are considered [4], where an event is something that has a beginning and an end in time and where other things (specifically endurants) may participate. One could compare an event in UFO-B to an activity or process in the terminology of the other surveyed fields. Then, the participants in an event could be regarded as the resource dimension. In addition, the mereological (i.e, part-of) and historical relations between events could be regarded as the control dimension, albeit with only very few language constructs.

In Schema.org [52], there are no terms to model processes. However, special kinds of processes can be modelled, such as a how-to description or a (cooking) recipe²²2http://schema.org/Recipe, which, at least in the JSON representation, can consider sequential flow. However, in the translation to RDF, the ordering gets lost, but there is an ongoing discussion to change that³³3https://github.com/schemaorg/schemaorg/issues/1910.

Works in Scientific Workflows and Provenance are mainly concerned with modelling entities, activities that transformed them and agents who carry out the activities. Those works were developed first for the recording of the activity of scientific labs that process samples, e.g, in biology.

The Open Provenance Model for Workflows (OPMW) is an ontology to describe the workflow traces and their templates of scientific processes [45]. Part of the OPMW work is the Provenance and Plans ontology [46] (P-Plan⁴⁴4http://purl.org/net/p-plan), which extends the Provenance Ontology [59] (PROV-O⁵⁵5https://www.w3.org/TR/prov-o/) with terminology to describe the plans (that is, the control flow) that govern the execution of scientific processes. P-Plan can be used to describe plans and establish a relationship between such plans and the provenance records in PROV-O that provide details with a focus on the entities and steps of past executions of scientific workflows. However, P-Plan does not capture elaborate control-flow constructs that are used in other types of workflows. A more recent approach is ProvONE⁶⁶6http://purl.org/provone for the publication of scientific workflows [47]. ProvONE provides constructs to model workflow specifications and workflow execution provenance. The OPMW and ProvONE capture traces of workflow executions. They aim to provide detailed records of how each step is performed, which aligns with the trace dimension. ProvONE+ is an extension of ProvONE that specifically addresses the requirements for capturing the provenance of control-flow-driven workflows [18], including sequence, parallel split and synchronisation in the control category. ProONE and ProvONE+, address aspects of the data dimension in terms of how data is managed and utilised in control-flow-driven workflows. Outside the domain of scientific lab work, the Publishing Workflow Ontology (PWO) is an ontology for the description of workflows in scientific publishing [44]. They use ontology design patterns to address modelling requirements of workflows. PWO includes sequence, parallel split, synchronisation, exclusive choice and simple merge.

Various systems have been proposed to provide the environment for specifying and enacting workflows such as Taverna and Kepler but each of them partially provides all the patterns in the control-flow category. Taverna [101] uses SCUFL (the simple conceptual unified flow language, a data-flow language) to specify control constraints for execution ordering and conditional constructs, which can encompass various control flow patterns such as if/else or case structures. Kepler [5] provides support for branching and synchronisation. Wings for Pegasus [50] is a workflow system that uses semantic representations to describe the constraints of the data and computational steps in the workflow. These works aim to fulfil various requirements related to representing workflows, capturing provenance information, describing plans and steps, creating workflow templates, accommodating domain-specific extensions and managing control flow. In provenance execution, the focus is on capturing the detailed record of the actual execution steps. However, some of these models have limitations in accurately and fully specifying control-flow patterns for scientific workflows. This limitation primarily impacts the prospective provenance, which includes the structure and static context of a workflow. However, their primary focus is not on representing data or instances of processes but on control and provenance aspects. Moreover, they do not consider the representation of resources like human resources, computational resources, or roles in the workflow.

Works in Semantic Web Services aim to annotate Web Services in order to facilitate automated discovery, composition (e.g, into a process), invocation and re-use of such services. Their work builds on the works in Web Services that typically come without such annotations.

When business processes (e.g, BPMN) are used to describe choreographies and orchestrations of electronic business activities, even beyond organisational boundaries [79], their execution requires interoperability between the electronic interfaces. Interoperability standards emerged from these needs, which in the context of process integration led to the creation of Web Services. Web Services⁷⁷7https://www.w3.org/2002/ws/ allow for invoking operations tunnelled through HTTP POST requests. There is an entire family of standards, called ‘WS-*’, in the area of Web Services, which allow for, e.g, service description or service discovery. To allow for the composition of Web Services, compositions via an orchestrator can be achieved using process languages such as BPEL⁸⁸8http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html (also known as BPEL4WS or WS-BPEL). [79] discusses that the life cycle of process instances and data items can be regarded as state machines.

Beyond these functionalities, Semantic Web Services aim at describing services through machine understandable representations, allowing the automated discovery, composition, invocation and reuse of services on the Web. Different alternatives have been proposed for representing Semantic Web services most prominently: OWL-S (Web Ontology Language for Web Services)⁹⁹9http://www.w3.org/Submission/OWL-S/ and WSMO (Web Service Modelling Ontology)¹⁰¹⁰10http://www.w3.org/Submission/WSMO/. OWL-S (previously called DAML-S [8] – DARPA (Defense Advanced Research Projects Agency) Agent Markup Language for Services – consist of three main parts: an ontology describing what a service does; an ontology to describe the service process and an ontology to specify how to interact with the service. OWL-S contains terminology to describe (hierarchical) process models with the following control flow elements: Sequence, Split, Split-Join, Any-Order, Choice. The ‘service grounding’ aspect of OWL-S could be argued to hint at the resource aspect of processes. The input, output, precondition, effect of OWL-S’s ‘service profiles’ loosely relate to the data aspect. WSMO [94] proposes a conceptual model for describing Web services, separating the goals or expectations of service requesters from the actual descriptions of the service features, capabilities and interfaces. WSMO also introduces the concept of mediators allowing the conciliation of potential discrepancies between services. Execution in the context of WSMO, WSMX (Web Service Execution Environment) [55], is event-based. The ‘interface’ aspect of WSMO could be argued to hint at the resource aspect of processes. The input, output, precondition, effect of WSMO’s ‘capability’ loosely relate to the data aspect. Another approach from Semantic Web Services [1] contains a process language with formal semantics based on the $\pi$ calculus. This language can express sequential, parallel (‘composition’) and conditional (‘summation’) control flow. The approach can model agents and services (corresponding to the resource aspect) next to involved ontologies (corresponding to the data aspect).

Stream processing addresses the problem of efficient managing and querying rapidly changing flows of data and events, typically augmented with time annotations. Hereby, time is a fundamental element for representing concepts such as order, simultaneity or concurrence of a given process. Systems, processing frameworks and query languages have been developed over the years, targeting the increasing demands of high-velocity data consumers, in multiple domains like healthcare monitoring, security surveillance, environmental sensing and the industrial Internet of Things.

Nevertheless, traditional stream processing often faces the challenge of handling heterogeneous data sources and thus different models, which are hard to integrate and reason upon. RDF stream processing, stream reasoning and complex event processors have been presented in the literature, addressing this challenge form different perspectives [34].

RDF stream modelling has been presented as an approach to extend RDF with explicit temporal annotations, in order to enable continuous query processing over events or stream items [34]. Following a graph-based representation with explicit semantics provides a richer modelling approach for data streams, also offering ways of overcoming semantic heterogeneity through streaming data integration, e.g, through methods like ontology-based data access [21]. Existing modelling approaches like RDF Stream Processing in SPARQL (RSP-QL) [33], use point-in-time or interval semantics to represent time, defined at either the triple or graph level. Compatible implementations of continuous query processors for RDF streams include Continuous SPARQL (C-SPARQL) [13], Continuous Query Evaluation over Linked Streams (CQELS) [89], or SPARQLStream [20]. Processes in these RDF stream systems are often represented as states that may change over time (e.g, sensor observations denoting the state of a monitored subject) and the queries are used to formalise specific types of instances or patterns – thus reflecting the control flow. A first attempt to formalise the description of RDF stream resources and endpoints is the Vocabulary and Catalog of Linked Streams (VoCaLS) [100], although it does not explicitly include the specification of streaming processes.

Stream reasoning has taken a step beyond continuous queries, exploring the possibility of exploiting the semantic relationships among events through reasoning tasks [34]. This sub-field has studied different approaches, many of which implement variations of incremental reasoning. View maintenance-inspired approaches include systems like the system by Volz et al. [106], which is based on the delete and re-derive (DReD) algorithm and in which axioms are added and removed according to the entailment rules. In these stream reasoners, processes and activities are not explicitly modelled, but such reasoners allow for reasoning tasks that involve the temporal structure. Such tasks typically allow for deriving new knowledge (e.g, new events) as a result stream, thus generating new occurrences. Benchmarking and evaluation of different stream reasoning approaches is still an area under active exploration [51], given the heterogeneity of existing reasoning approaches and underlying temporal logics.

Semantic complex event processing (CEP) has studied the modelling and querying of streaming events, allowing the continuous querying of complex patterns. These patterns include, for example, finding sequences of events (i.e, when an event $e_1$ is followed by another event $e_2$); or two evaluate if two events happen simultaneously [7]. CEP query languages like Event Processing SPARQL (EP-SPARQL) [6] allow using RDF triples to represent these events and add query language extensions that allow to express these temporal order and simultaneousness patterns, which represent the control flow among events. The language includes the SEQ operator to find sequences of triple patterns according to a time-based order. Similarly, the simultaneous presence of triple patterns can be detected using the EQUALS operator. Later on, these CEP operators were formalised and incorporated into the RSEP-QL model that combines both CEP and RSP query models [32]. In these CEP implementations, the activities and processes are reflected in the queries, where the expected order of sequences, patterns and other conditions are specified. While this is convenient for monitoring tasks and summarisation, the definition of explicitly defined processes could potentially facilitate and optimise the execution of CEP and reasoning query patterns in streaming environments.

Formal methods are formal techniques to model and analyse the behaviour of systems. Those techniques are concerned with modelling a general notion of process, i.e, describing any sequence of state changes and the nature of these state changes. They can be applied to system designs or specifications as they can be found in engineered systems, e.g, railway systems [42]. They can also be applied to more abstract systems, such as programs, where they form the basis to describe both program semantics [108] and program correctness [54], or indeed any kind of system that inhibits behaviour, including natural and sociological ones. As such, formal methods, in particular those targeting programs and program development, are closely related to process modelling, because both are concerned with describing possible and allowed sequences of states and events. Therefore, we believe that the rich toolkit of languages and tools from formal methods can successfully be applied in process modelling.

As we are eventually looking for a formal grounding for a core process ontology, which shall allow for reasoning about control flow and data as prescribed by a process, we also summarise related work that connects ontologies with formal methods to describe programs.

Programs are similarly concerned with describing control flow and data, but even though programs focus on generating traces, the ontologies describing programs and traces formalise similar ideas as process ontologies and can be a valuable source of inspiration, in particular for domain-aware simulation.

We subdivide our discussion of ontologies and programs into three groups, depending on their task: ontologies that describe programs and their output, ontologies that enable data access from a running program and approaches that tightly couple programs and ontologies that interact during program execution.

The field of Business Process Management is concerned with the modelling of processes in businesses with the aims of this modelling ranging from communicating how (i.e, according to which process) things should get done in a business to automating the process using information systems.

Business Process Model and Notation (BPMN) is a visual language to represent processes¹¹¹¹11http://www.omg.org/spec/BPMN/2.0/. The BPMN ontology provides a formal representation of the visual concepts defined in BPMN, such as steps, events, gateways and sequence flows [95]. The ontology in [95], as a representation of BPMN, covers the corresponding wide range of control flow patterns and allows for the specification of data requirements, such as input and output data and the assignment of roles or agents responsible for specific steps. The aim of the ontology was to faithfully represent the constraints of the visual modelling language, thus the necessary semantics for workflow execution is out of scope. The BPMN ontology has only limited support for modelling organisational or resource-related aspects of business processes.

The business process modelling ontology (BPMO) [19] has been developed to represent high-level business process workflow models, abstracting from existing notations and languages such as BPMN and BPEL (short for Business Process Execution Language¹²¹²12http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html). BPMO focuses on the representation of process specification and includes various workflow elements such as tasks, events, block patterns (inspired by BPEL) and graph patterns (inspired by BPMN 1.0). These block and graph patterns serve as control flows, representing decision points within the workflow.

The work in [14] builds on [95] and also allows for modelling the data coming from process executions to enable querying and reasoning over the representations. The representations contain especially traces of past process executions next to the involved resources and data items. The authors use OWL reasoning (RDFS and OWL 2 RL) or SPARQL queries (with entailment regimes) to query processes, data and traces. The inferencing they consider is concerned with the resources that have been involved in specific traces.

Other works study the representation of Petri Nets using semantic technologies [69, 48]. Petri Nets are directed graphs consisting of places and transitions representing states and events/activities respectively. These works aim to enable the sharing of Petri nets in RDF or OWL. While the foundations of Petri Nets representations allow capturing different workflow patterns (e.g, AND-Split, OR-Split, Loops, etc.), they are limited in their expressivity to the basic Petri Net language elements lacking consideration for extensions.

Another graphical modelling notation for business processes is the so-called event-driven process chain (EPC). EPC can be used to represent process models. Core language elements in EPC are functions (activities), events, control flow transitions, logical connectors (OR, AND, XOR) and resources. The authors of [99] investigate the semantic annotation of EPC process models.

Two approaches, WiLD (Workflows in Linked Data) and GSM4LD (Guard-Stage-Milestone for Linked Data), are designed to describe and execute workflows in Linked Data environments. WiLD [61] is a hierarchical process model [104], which allows for specifying sequential, parallel and conditional control flow. WiLD can also model process instances and together with its operational semantics in ASM4LD [60], workflows in WiLD can be executed. Correspondingly, the approach needs a notion of the data on which conditions are evaluated. A similar approach is taken in GSM4LD [63], which brings the Guard-Stage-Milestone (GSM) approach [57] (later standardised as CMMN – Case Management Model and Notation¹³¹³13https://www.omg.org/spec/CMMN/1.1/) to Linked Data. Control in GSM is entirely determined data-driven, that is, via conditions evaluated on the environment and process-relevant milestones. Again, the operational semantics are given in ASM4LD. In contrast to GSM4LD, an execution of a WiLD workflow can give a light-weight process trace, by assigning finishing timestamps to finished activities, without additional modelling effort in the operational semantics. GSM4LD however supports cycles, thus to produce a complete trace would need extra data structures.

The Manufacturing process documentation use case involves the maintenance and adjustment of gear head lathe machinery¹⁴¹⁴14 This machinery features a gear-driven mechanism, crucial for various metalworking tasks commonly used in metalworking industries such as turning and threading. as described in a maintenance manual. The process consists of a sequence of steps that must be completed in a sequential order to address maintenance tasks and ensure optimal machine performance. It is crucial to record the order in which these steps are carried out. The initial step in the sequence involves a safety check of the machinery. Upon completion of the preceding step, the process enables the following steps, including instructions for adjusting the tension of motor belts, tailstock alignment, and spindle alignment. The spindle alignment step involves several sub-steps, including loosening the bearing lock nut, tightening the bearing adjustment nut, testing the spindle by rotating it, and finally re-tightening the bearing locking nut, all contributing to the overall spindle alignment step. The process of maintaining and adjusting gear head lathe machinery involves a series of steps (such as safety checks, adjustments, and alignments) that transition the machinery between different states (such as operational, under maintenance, and calibrated).

The Manufacturing data spaces use case involves the cataloguing of data in manufacturing settings, where the goal is to catalogue the data sets collected during manufacturing, in order for data scientists to access the appropriate data for downstream data analytics. In this use case, the position in the manufacturing process must be part of the metadata of the data sets to consider this context during searches. The manufacturing process follows a stamp-forming flow, involving steps like heating, pre-forming, stamping, cooling, de-moulding, and reworking, with potential variations and additional pre- and post-processing steps. The data dimension encompasses the representation of specific data sets collected during manufacturing. As goods are manufactured, data is generated, and specific traces and data are recorded.

The Healthcare and tele-rehabilitation use case involves modelling patient states following physical rehabilitation treatments, such as post-operative recovery, home-based reeducation or post-stroke physiotherapy. Traditional rehabilitation requires intensive intervention by healthcare professionals and may not adequately adapt to individual patient characteristics, context, or motivation. Digital rehabilitation addresses these challenges by offering personalised therapies – such as rehabilitation exercises – using sensors to monitor exercise performance and physiological markers. The patient’s process is modelled as a set of states, with transitions triggered by their own decisions and influenced by a digital assistant’s suggestions. Data gathered from wearable and environmental devices guide recommendations, such as resting, adjusting exercise intensity, or modifying the overall treatment based on the patient’s characteristics, motivation, and emotional status.

In the Domain-aware simulation use case, simulators must schedule and execute tasks in an initially unknown order to transform an initial state into a result state. To access this simulation result, they must also provide a means to query the result state and the sequence of executed tasks leading to it. A simulation task is modelling a state change according to some process in the domain of the simulation. Thus, they are inherently domain-specific and must have precisely described conditions for process initiation. These tasks can be modelled ontologically to allow the simulator to understand both their ontological description (conditions for process initiation) and computational description (changes needed to transform the current state).

While the domain modelling is often implicit in the simulation software, it can be made explicit. The simulator queries its state for possible steps at each simulation step, executes them in parallel for all parts, and analyses whether their changes trigger further tasks in the same simulation step. This can be done either by querying for newly enabled processes based on the state or by modelling dependencies between processes.

The geological simulator of Qu et al. [92], which simulates geological processes such as deposition of material and subsequent chemical process related to hydrocarbon generation, is an example where the domain modelling is made explicit: Such a domain-aware simulator relates its (internal) state to (external) geological descriptions, such as composition of geological layers, and its tasks to geological processes, such as deposition.

The Aircraft cockpit design use case focuses on ergonomic analyses of aircraft cockpits in virtual reality. Aircraft cockpits must be designed for the safe execution of pilot workflows. To support ergonomic analyses of aircraft cockpits during the early design phase when only CAD models are available, a workflow-aware analysis tool has been developed [62]. The tool enables the analysis and visualisation of pilot workflows in aircraft cockpits within a virtual reality environment. Hierarchical process models are employed to break down the processes pilots perform in aircraft cockpits. For example, take-off phases (e.g, taxi, climb) are at a higher level, while physical pilot activities (e.g, moving throttle, engaging autopilot) are at the leaf level. Data includes information related to aircraft cockpit design specifications, such as data structures in Virtual Reality derived from CAD models. During ergonomic analyses of aircraft cockpits, occurrences are generated to gain insights into the progress of pilot workflows and cockpit interactions.

In addition to representing processes and related concepts to informally specify processes, as done for example in the various graphical notations, many scenarios require means to carry out tasks over the process descriptions. Thus, a formal representation of processes and related concepts is mandatory.

Table 3 gives an overview of the workflow patterns present in each scenario, providing a quick reference to understand how these patterns are distributed across the scenarios. Starting from the scenario Manufacturing process documentation, which covers only two workflow patterns, it is evident that the level of difficulty of each subsequent scenario increases. Therefore, as we progress to scenario Domain-aware simulation, a more complex use case, we can anticipate that it will have a broader coverage of workflow patterns. This incremental approach allows for a systematic exploration of workflow patterns, gradually building up complexity and understanding as we advance through the scenarios. Both control and data patterns are essential for designing comprehensive workflow models. They provide a structured way to represent the control logic and data interactions within a workflow.

All scenarios assume that information about processes and related concepts are represented as graphs. The requirements of the previous scenarios regarding querying and reasoning can be grouped according to the five dimensions. Please note that the representation influences the kind of operations that can be applied on the representation (and vice versa). In the following, we thus outline and summarise typical operations that can be carried out over the state component, i.e, mainly the data and resource dimensions in our classification, and typical operations that can be done on the temporal component, i.e, mainly the control, trace and online dimensions.

If we only operate on the graph structure of the process descriptions, we can use standard graph-based data models (such as RDF) as basis for querying using SPARQL, possibly in conjunction with ontologies (RDFS or OWL). The requirements from the various scenarios regarding querying and reasoning are summarised and generalised in Table 4. In Table 4, we aim to simplify the presentation by concentrating on the requirements that directly align with the primary objectives addressed by the use case scenarios. Requirements can be further combined, particularly concerning the combination of process, data and online.

Next to performing reasoning on just the graph representation (e.g, using RDF or RDFS semantics, using rules, using OWL DL (direct) semantics), some scenarios also require a way to perform reasoning on and with the temporal structure. Many graph query languages have means to deal with sequences, so basic retrieval and query tasks should be possible, including reachability. When applying reasoning, additional queries can be supported, for example for declaring a property transitive (e.g, the next property) or declare two properties the inverse of each other (e.g, next and previous).

More elaborate operations on temporal structure are better supported with dedicated languages of temporal logics. However, only the Healthcare and tele-rehabilitation and the Domain-aware simulation scenarios require query and reasoning tasks beyond the standard tasks on graph-structure representations. The scenario Healthcare and tele-rehabilitation is special concerning the representation of time. While the other scenarios only require a linear ordering, the querying and reasoning tasks in the Healthcare and tele-rehabilitation scenario require temporal queries with an operator defined over moving windows (i.e, different time periods). The need for temporal logic specifications is the most clear in the scenario Domain-aware simulation. The query and reasoning tasks for one trace alone must be able to reason about safety and liveness properties, while comparing two traces is a natural setting for temporal logics.

A core process vocabulary should be broadly applicable to describe processes and represent a consensus from different fields on the abstractions and concepts as well as the terminology. All our use cases take a discrete-time perspective, which we can take as a fundamental assumption going forward. We have already illustrated why we need support for both state-centric and activity-centric perspectives. Similarly, all of our scenarios benefit from a representation based on graphs. We have started to work out required concepts from first principles and distil commonalities between different fields based on the five dimensions, which we will discuss further in the remainder of the section. Still, to arrive at a fixed set of vocabulary terms requires a deeper alignment of concepts and more study of the representations of processes in related fields.

In a process core vocabulary, we have to decide which terms to include and which terms to possibly relegate to extensions. That is, a process core vocabulary should be layered, where additional tasks can be supported if the underlying representation is gradually extended. In the control dimension, the question is what patterns to support next to the sequence pattern (WCP1) expressing temporal order. More patterns might be useful for a core vocabulary. Especially the any order pattern (WCP40) could be rather directly supported, as well as the exclusive choice pattern (WCP4), given that both patterns relate to choice and do not require parallelism. Parallelism (WCP2 and WCP3) might be a worthwhile pattern to support, especially when the core vocabulary should include support for multiple roles (see the resources dimension). A process core could support hierarchical modelling (the “H” pattern in Table 3) to be able to modularise the process representations and thus help to keep an overview in large and complex processes and provide a mechanism for iterative modelling. How to provide useful primitives for specialisation or generalisation is an open question.

Representing occurrences and traces of processes is also a rather fundamental pattern, so fundamental in fact that the business process community just silently assumes such a primitive without explicitly identifying the pattern. We think that the particular/universal distinction in the context of processes is important, mirroring the type/instance distinction in ontology languages. Thus, a core vocabulary should make the particular/universal distinction for events and processes as well. What effects the particular/universal distinction on the side of events and processes should have on the modelling of data items (and vice versa) is another open question.

Regarding the data dimension, the representation with graphs as syntax allows for more flexibility compared to a dedicated language with a grammar of its own. In particular, a graph representation allows for freely extending the graphs with additional data, such as annotations on the level of the process descriptions, and enables the possibility of querying and deductive reasoning. Thus, a core vocabulary should include support for data, in particular environment data (WDP8), and integration with graph-structured data to be able to support data integration. For example, mappings to other vocabularies (e.g, PROV-O) could be provided.

The representation of agents or roles involved in the process is required. Whether it is enough to have the flexibility of graphs to allow for such descriptions, or whether we need dedicated terms as part of a process vocabulary remains to be seen.

Representing processes as graphs using a shared vocabulary provides already some benefits, such as performing query evaluation and certain reasoning tasks on the graph representation. The scenarios identified various possible querying and reasoning tasks. Overall, the challenge is that the different querying and reasoning tasks should be possible to perform on a unified representation. In particular, a major challenge is to combine the purely graph-structured process representations with specifications of temporal properties for querying and reasoning. To support querying and reasoning tasks that go beyond checking satisfiability on the graph representation, we require means to encode queries and logical formulas pertaining to temporal properties.

If we assume a framework of time based on temporal ordering (“happened-before”), we could use temporal logics that operate over the linear order for specification of temporal properties to encode restrictions on temporal order. In particular, Linear-time Temporal Logic (LTL) or Computational Tree Logic (CTL) are temporal logics that can operate over linear time (LTL) or branching time (CTL). A challenge is that formulas written in temporal logics directly can be difficult to understand. Thus, a core process vocabulary could use higher-level abstractions for temporal specification patterns, such as precedence and cause and effect [39]. Using such high-level specifications presents an opportunity to increase the flexibility when modelling processes or temporal properties of traces. For example, instead of directly representing processes (e.g, first A, then directly followed by B), users could use (weaker) temporal properties to give a higher-level representation of temporal structure (e.g, A precedes B). More research is required to investigate the trade-offs regarding modelling flexibility and computational complexity. An additional challenge using the formalisms of temporal logics is how to bring together the state perspective and event perspective, as temporal logic formalisms often prefer to specify properties on sequences of states (and not events) [23].

Another question for a core process vocabulary is whether we should go beyond the simple “happened-before” relation and assume a richer framework for time. For example, Allen’s interval algebra [3] supports time points but also intervals and defines relations between time points and intervals. Similarly, stream reasoning assumes time stamps that can be used within window operators akin to intervals. An underlying temporal logic to capture such constructs could be Metric Temporal Logic (MTL). Again, the challenge is to decide on whether the increased expressive power is required and worth the computational cost.

In general, representation and reasoning will involve trade-offs depending on the underlying logics used: while some constructs could be written down using a process core vocabulary, performing operations (with a desired semantics) over such constructs might be computationally expensive or even infeasible. Ideally, we would like to find a representation that can in principle support a broad variety of tasks, with fragments or profiles for specific tasks, such as temporal querying, planning and synthesis, formal verification or process mining.

The range of operations for reasoning with process descriptions and formulas span from relatively basic queries on the graph structure to more intricate queries concerning the temporal structure of process representations. These advanced queries essentially encompass operations akin to model checking and formal verification.

Regarding operations on the graph structure, there are two overarching objectives: query answering, that is, acquiring solutions to queries, and reasoning, involving the inference of new formulas when given a set of formulas or a graph. RDF, RDFS, and various OWL profiles in conjunction with SPARQL support querying and lightweight reasoning on the graph representation of objects and their associated properties, in particular those in the data and resource dimension. These operations rely on standard semantics all underpinned by the formal notion of satisfiability. A possible avenue for further research is to identify whether and to which extent reasoning on the graph structure might yield simple inferences on the temporal structure, although the specifics of this interaction remain a topic of exploration.

Of particular interest is the provision of support for operations on the temporal structure. A fundamental operation relates to checking the satisfiability of temporal specifications, which can be performed on process descriptions or traces. In addition, other operations are conceivable, such as finding processes that satisfy temporal specifications, akin to planning or synthesis. Conversely, another operation would be process mining, i.e, identifying a process that can generate a given set of occurrences.

As part of a specification of the semantics of a core process vocabulary, generic logic formulas could be introduced that operate on the temporal structure independently of the domain-specific elements. These formulas can capture intricate concepts like “happened-before” or the temporal ordering of events and occurrences. Furthermore, domain-specific formulas can encode restrictions specific to a given domain, such as the requirement that an order can only be shipped once the payment has been completed.

Another open challenge involves the interplay between the semantics of objects and data items and the semantics of the temporal structure. Related is the connection between particulars, representing instances and occurrences, and universals, embodying classes and events. Combining state and event perspectives, both on the levels of particulars and universals, presents a challenge for the development of a semantics, which requires the integration of state descriptions, represented as objects and their properties in graph form, with event descriptions that influence these states. Given an occurrence of a process in a specific state and a sequence of events, one should be able to derive the states of the related objects and data items. Conversely, it should be possible to work backward: starting with a sequence of states for the data items, one should be able to deduce the sequence of events that led the data items to those states. Moreover, the possible triggering of events needs to be evaluated over the state, with the introduction of a condition language to express “guards”.

A graph-structured representation is advantageous for its flexibility in describing process-related knowledge. However, different use cases may require different semantic approaches. For instance, a data integration scenario could benefit from an open-world semantics, allowing partial process descriptions from multiple sources to be seamlessly combined. In contrast, a process execution use case may require a closed-world semantics, particularly because it necessitates making assumptions about the initiation and completion of processes and the comprehensiveness of each step within a process. Decisions surrounding whether to open or close the world depend on the specific tasks at hand.

A final open question relates to specialisation of processes involving hierarchy. In such cases, a closed-world assumption could become useful. A closed-world assumption would be equally applicable when working with prototypes [25], as opposed to the classic class-instance distinction based on sets. Prototypes could also support partial process descriptions that can later be amalgamated or refined. Issues may arise when one considers formalisms with open world and closed world side by side and interacting, both on the graph representation and with the temporal component.

A process core vocabulary which supports all conceivable tasks is likely to be too expressive and thus prohibitively expensive in terms of computational complexity. Thus, we probably want to end up with a semantics for the entire vocabulary and define profiles of the vocabulary of different expressive power suitable for the intended task. One challenge then relates to the identification and investigation of profiles, i.e, subsets of the vocabulary, that support relevant reasoning tasks, while avoiding that parts of the vocabulary that have different meaning depending on the context.