Keywords

1 Introduction

Modern textual definitions of business processes such as [30] go beyond the classical control-flow dimensions, by taking into account also other important perspectives related to organisational, data, and goal-oriented aspects. The increased attention towards other dimensions than the behavioural one, has recently brought to a rapid growth of approaches and tools in the stream of multi-perspective business process modeling and mining [15], where other perspectives such as resources, data, time, and so on are exploited to augment the basic control-flow one. Such a hype on multiple aspects of business processes shows that the time is now ripe to focus on an investigation of multi-perspective process constructs and relations also at the conceptual level. A commonly agreed broad view on business processes, with clear and shared definitions of business process entities such as resources, data needed and produced by activities, different types of events, an so on, already at the conceptual level, would be crucial for instance to foster the communication and the data compatibility among information system procedures and data structures designed and described using different modeling paradigms and notations.

By looking at the business process meta-model literature, a number of different meta-models have been proposed. These meta-models vary greatly ranging from very general ones to meta-models tailored to a specific business process modeling language and, as such, characterised by the language specificities. Despite the differences and the disalignments between these meta-models, such a literature can be leveraged in order to investigate commonalities, differences and especially criticalities emerging from them.

In this paper we start from such an existing literature on business process meta-models and we analyse it through a systematic literature review in order to discover the business process elements and relations most investigated in state-of-the-art business process meta-models (Sect. 2). We then combine the discovered elements and relations in a literature-based meta-model of business processes (Sect. 3), which is on purpose built by simply joining discovered elements and relations, so as to disclose problems and inconsistencies. A number of criticalities arise from the analysis of the meta-model (Sect. 4): besides the under-investigation and under-specification of some of the relevant business process elements (e.g., the goal of a process), unclear relations and recursive subsumption cycles have been identified in the organisational and data components of the emerging meta-model. In order to deal with such criticalities, an ontological analysis has been carried out and possible solutions for the identified issues proposed in Sect. 5. Finally, related and future works are presented (Sect. 6 and 7).

2 Discovering Meta-model Components from the Literature

In this section we describe the elements and relations extracted through a Systematic Literature Review (SLR) on business process meta-models reported in [4]. First we provide few details about the SLR; in Sect. 2.1 we summarise the analysis of the elements reported in the SLR [4]; and in Sect. 2.2 we focus on a novel part related to the analysis of relations among elements emerged from the SLR.

Systematic Literature Review Setting.

In the SLR we collected papers (up to 2018) from three paper repositories - DBLP, Scopus, and Web of Science (WoS) - and two reference conference venues, i.e., the Business Process Management (BPM) conference series and the Conference on Advanced Information Systems Engineering (CAiSE) series. We retrieved 1306 papers from the three repositories (without considering collections) using the following query:

(1)

The conference venues were manually searched and we selected 452 works from BPM proceedings and 1065 from CAiSE proceedings for a total of 2463 papers (without duplicates). We identified and applied 3 inclusion criteria and 8 exclusion criteria, as well as four quality assessment criteria in order to filter the extracted papers, and we reduced the 2463 works to 36 papers that constitued our primary studies.

2.1 Literature-Based Elements

From the meta-models contained in the 36 primary studies we identified the recurrent business process (modelling) elements. Specifically, we extracted 374 single elementsFootnote 1 grouped in 12 macro elements: activity, event, state, sequence flow, time, data flow, data object, actor, resource, value, goal, context. Out of the 374 single elements we kept only the ones appearing in at least two meta-models, thus reducing the number to 91.

Table 1. Recurring elements in meta-models.

Table 1 reports the 91 elements, organised according to the 12 macro-elements. The table also reports the number of meta-models in which the element occurred (reported in round brackets). For instance, the element time point occurred in (2) meta-models. Elements with the same (very similar) meaning but with different names, i.e., syntactic variables, have been all classified under a single name. The table also reports in round brackets, for each macro-element, the number of elements per category together with the total number of occurrences of macro-category elements. For example, the macro-element state includes 5 different elements for a total of 27 occurrences of those elements. Elements labelled as events have been classified either as events with a BPMN-like semantics, i.e., “something that happens during the course of a process” [21] (event-BPMN) or as events \(\grave{a}\)-la EPC, i.e., in terms of pre-postconditions (event-EPC).

From the analysis we identified four main groups of macro-elements: activity, sequence flow, data object, and actor. The sequence flow macro-element is the most articulated one with its 18 elements and 91 occurrences. An interesting group is the one of data object, showing different types of knowledge (17 in total) that can appear in business process model elements, even though their appearance is not as common as the one of the other three groups. The second largest group is activity with its 64 occurrences. Also this group is very diversified including many kinds of “activities” and especially the most recurrent element in the meta-models, i.e., activity (27). Another key area of business processes is the actor/organisational aspect. Indeed, also in the meta-models, we found several occurrences of organisational-related elements (72). We also surprisingly found that other groups of elements appearing in existing business definitions, as for instance goal and value, do not occur in the meta-models. In particular goal is considered as central in one of the more recent business process definition proposed by Weske in [30], however the element goal appears only few times in the meta-models. Yet, also some time-related elements are not very represented. For instance only five elements are considered in the macro-element state and also the element state itself appears in only 4 meta-models. We also observed that five elements are considered as members of more than one group, such as information, position, role, application, and process participant. In this sense, the macro-element resource is the most interconnected having elements in common with the group actor and data object. This aspect is mainly due to the fact that some elements could play several roles in a business process (model). For instance information could be conceived as a resource but also as a data object.

Overall, only 14 elements of the extracted ones occurred in at least the 25% of the meta-models. These elements are reported in bold in Table 1. The only element that appeared in more than half of the meta-models is activity.

2.2 Literature-Based Relations

For the identification of the relations among meta-model elements, we decided to focus on the elements that: (i) either occurred in at least the 25% of the primary studies (i.e., the ones in bold in Table 1)Footnote 2; or (ii) occurred at least 6 times in the macro-categories without any representative element (i.e., goal). These criteria guarantee that most of the macro-elements include their most recurrent components. In total 15 elements were considered: activity, atomic activity, compound activity, event-BPMN, event-EPC, gateway, parallel gateway (AND), inclusive gateway (OR), exclusive gateway (XOR), precondition, artifact, actor, role, resource and goal.

Among these elements, we identified 89 relations, which were reduced to 57 after merging the ones with similar semantics, and removing others that were scarcely significant (e.g., ), unless they were the only representative relation between a pair of elements. Table 2 reports the resulting 57 relations among pairs of elements and the number of meta-models in which the relation occurred (among round brackets)Footnote 3. Specifically, in Table 2, we grouped business process modelling elements acting as domain and codomain of the relations into the three basic business process modeling language categories (behavioural, organisational and data) and a fourth goal category characterizing the elements related to the goal of the process. Relations are organized such that each block collects the list of relations having as domain an element belonging to the catetgory in the row and as codomain an element belonging to the category in the columnFootnote 4. For instance, the relation between activity and actor lies at the cross between the behavioural row (as activity is a behavioural element) and the organisational column (as actor is an organisational element).

The analysis of Table 2 shows that relations among elements in existing meta-models are relatively few considering the number of the retrieved elements. Most of the relations appear in only one meta-model, as for instance the relation between resource and activity. In contrast, a very small collection of relations occur in more than one meta-model, as for instance the relation between atomic activity and activity as well as compound activity and activity.

Table 2. Recurring relations in meta-models.

By looking at the table, we can observe that the behavioural elements are mostly disjoint from the organisational/data and goal categories. We can indeed identify two main clusters of relations: the one having domain and codomain elements in the behavioural category (top left cell of Table 2); and the one with domain and codomain elements in the organisational\(\backslash \) data categories (central cells in Table 2). Besides these two main clusters, we can identify few relations at the cross between the behavioural and organisational/data categories and very few relations involving the goal category (and corresponding goal element).

Focusing on the elements, we can also observe that some of them are scarcely connected through relations. For instance, the element goal acts as the domain of only one reflexive relation (goal goal) and as codomain of only two further relations ( and ). Elements such as artifact, AND, XOR, OR and event-BPMN,EPC are other examples of elements that are poorly connected to other elements. In contrast activity is shown to be the most interconnected element: it is the domain of 17 types of relations and the codomain of 19 types of relations. In the group of organisational elements, the element acting as domain for most of the relations is instead actor, having as codomain mainly organisational and data elements. By looking at the number of different relations between pairs of elements, we can observe that, also in this case, while most of the pairs of elements have at most one relation, the highest number of different relations can be found between activity and event-EPC and event-BPMN as well as between role and activity. Finally, a handful of elements display a finer level of granularity being composed of simpler entities, e.g., activity, compound activity and goal.

Summing up, more than 10% of the types relations occurred more than once in state-of-the-art meta-models: the relation between atomic activity and activity, between compound activity and activity, between AND and gateway as well as between OR, XOR and gateway; and the relation between actor and activity. Slightly more than 63% of the relations included the element activity either as domain or codomain. Around 42% of the relations have both domain and codomain in the behavioural elements, more than 17% involve organisational/data domains and codomains, while out of the remaining of the relations, 35% is at the intersection of the two and roughly 5% of the relations deals with the goal elements.

Limitations of the SRL. The limitations of the SRL may mainly concern flaws in selection of the papers, imprecisions introduced in the extraction of data from the selected works, and potential inaccuracies due to the subjectivity of the analysis carried out. To mitigate them we did follow the guidelines reported in [13]. A further limitation of this study lies in the facts that only one researcher selected the candidate primary studies, and one researcher worked on the data extraction. Both aspects have been mitigated by the fact that another researcher checked the inclusion and the exclusion of the studies, and another researcher checked the data extraction, as suggested in [6].

Fig. 1.
figure 1

Literature-based meta-model

3 The Literature-Based Meta-model

The extraction of the elements and the relations allows us to outline those characteristics of business processes (models) deemed most important by the number of scholars who have proposed business process meta-models in the literature. In this section we combine the extracted elements and relations, by merging all of them in a unique meta-model, the so called literature-based business process meta-model (LB meta-model).

We are aware of the problems arising from a study in which the information from different sources is blindly brought together. However, as a provocation, in order to better investigate the criticalities that can arise, we build such as LB meta-model, which allows us to see how business process model views can be rich but also conflicting. Having said so, a further problem we had to overcome in creating the meta-model was the establishment of the semantics of its components (i.e., the labels’ semantics) or, at the very least, the clarification of their intended meaning. In fact, only few authors did include explicit semantics, while for most of the cases it was either lacking or provided in terms of commonsense descriptions. Since our overarching meta-model is generated from the ones present in the surveyed papers, in order to avoid bias, we also opted to use a commonsense semantics of business process (modelling) elements.

Figure 1 depicts the literature-based meta-model in UML. In the meta-model gray is used for the behavioural elements, pink for organisational elements, yellow for the data elements and red box for the unique goal element. Finally, the resource element, which is shared by the organisational and data components, is depicted in white.

Observing Fig. 1, it is immediately clear that activity is the most important element. It is directly connected with almost all other elements, that is reasonable given its centrality for business processes. Moreover, most of the elements of the behavioural component (e.g., atomic activity, compound activity, gateway) are related through relations to activity. In contrast to activity, more than half of the behavioural elements (e.g., event-BPMN, event-EPC, gateway, AND, OR and XOR) are almost disconnected from the other categories. This lack of connection with other components is particularly surprising for gateways that we would have expected to be connected not only with behavioural but also with data elements, considering the fact that they deal with control and decision flow.

Looking at the data and organisational elements, we can also notice that, despite the importance of data and organisational aspects in business processes, a unique data element - artifact - and two organisational elements - actor and role - appear in the meta-model, besides the shared resource element. The artifact, which has several relations with the activity (and its sub-classes) and an relation with resource, is only indirectly related to the other elements. For instance, it is indirectly connected to the actor, through the activity element: the actor an activity, which, in turn an artifact. An actor, besides activities, has also other agentive capabilities, e.g., it resources, as well as goals. The resource element also presents a number of relations, many of which are relationships. Lying at the cross between the data and organisational boundaries, indeed, it has been classified in different terms, e.g, as a , as an and as a .

Last but not least, the meta-model in Fig. 1 reveals the marginal role of the goal category and of the goal element, which appears as an auxiliary element that other goals, activities and is achieved by actors.

To conclude this section we provide a brief description of the taxonomy of the LB meta-model (Fig. 1a). Looking at the behavioural component, we can observe two main subsumption blocks, where an element is specialised into elements with a finer level of granularity: atomic and compound activity are sub-classes of activity, and parallel (AND) inclusive (OR) and exclusive (XOR) gateways are sub-classes of gateway. Instead, event-BPMN,EPC are floating within the taxonomy. Moreover, besides reconfirming the centrality of the activity, we can also notice that all the behavioural elements - except for the event-BPMN,EPC and precondition - are subsumed directly or indirectly from the activity element. Here we expected that al least the event-BPMN element could also be classified as a “dynamic” (with a duration) entity.

Considering the organisational and data components, these are not integrated with the behavioural part. The relations are intricately articulated: resource sub-class of role, artifact and precondition; moreover role is an actor and viceversa. As a consequence, a resource is a sub-class of actor. Finally, looking at the goal component, the goal element is completely disconnected from any other element in the taxonomy.

4 Discussion

The analysis carried out in the previous section reveals that the extracted meta-model is not very well balanced: some parts and elements have richer descriptions, while others are only roughly specified. The elements and relations extracted from the primary studies reveal a good level of maturity in the behavioural component both in terms of elements and relations among elements. Also some of the organisational and data elements, such as actor, resource and artifact, are quite well investigated although their semantics and relations are still quite unclear. The goal component, instead, is under-investigated and represented both in terms of elements and relations. The relations between elements across different categories are also rather limited, thus leaving the behavioural, the data/organisational and the goal components poorly connected the one to the other. Also within the same category, we can find a disproportion among elements: for instance, in the behavioural category, activity has been largely studied and is well connected to almost all the other elements, while elements as event-BPMN and event-EPC are less investigated and connected to the other elements.

The imbalance among elements and categories in the LB meta-model is even more critical when taking into account their importance in business processes. For instance, according to Weske, a business process is “a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal.” [30]. By looking at the LB meta-model and at its taxonomy, however, we can clearly notice that the goal element, besides being under-investigated in the literature, is also scarcely connected. This can be due to the lack of a graphical element for representing goals in most of the business process modelling graphical notations. Indeed, only few notations include an explicit symbol for the representation of goals as described in [1]. Similarly, value, which appears in several business process definitions, does not appear at all in the LB meta-model.

A second criticality that we can observe in the LB meta-model revolves around event (and its two semantics) and precondition. The same label, indeed, is used in the literature for denoting two different concepts. The event-BPMN is commonly understood as “something that happens during the course of a process” [21], that is, as an exogenous activity. The EPC-event is intended instead as “describing preconditions and postconditions of functions” [19], that is, in terms of state. This overloading of the same label for different semantics, as well as the lack of a clear relation between event-EPC and precondition reveals an imprecise and non-agreed understanding of these concepts and of their relations within the community. This criticality is further confirmed when looking at the relations between the two notions of event and activity. While the causality essence of the relation between activity and event-BPMN reflects the active nature of the event-BPMN, the and relations between activity and event-EPC confirms their temporal characterisation, the relation between activity and event-EPC is tricky. A state, indeed, is a passive element, that cannot activate or cause anything by itself. The relation, however, refers to the complex notion of ARIS EPC event, which combines the two notions of event-EPC and event-BPMN.

Another issue emerging from the taxonomy extracted from the LB meta-model is related to the organisational/data components. Indeed, the model reveals subsumption cycles between actor, role and resource, thus resulting in the equivalence of the three elements. These sumbsumption cycles and the consequent equivalence relation, due to the way in which elements and relations extracted from the literature have been composed in the LB meta-model, reveals that the community does not completely agree yet on the semantics of some organisational/data elements and on the relations among them. This is especially true for the resource element that in the taxonomy of the LB meta-model shows a hybrid nature. Indeed, besides its organisational (a resource role) and data nature (resource ), the resource element has also a behavioural nature (resource precondition).

Finally, the LB meta-model captures mostly “standard” aspects of business processes and ignores elements related other dimensions of business processes such as, the decision rules and collaboration aspects underlying process models.

Fig. 2.
figure 2

Meta-model of events, activity, and pre-postcondition.

5 Towards an Ontologically Grounded Meta-model Refinement

In this section we address the critical aspects identified at the end of Sect. 4 trying to propose ontologically grounded solutions. In particular we focus here on the notions of state and event, and the notion of resource. For what concerns the scarce presence of important notions, in particular goal and value, we only note here that these absences should be filled, and that we plan to do it in the future starting from works such as [1, 28] and [23], respectively.

Events, Activities, and States. As already noted in Sect. 4, the different meta-models analysed associate, at type (i.e., conceptual) level, two different semantics to the term “event”, which we resolved by explicitly renaming this element into event-BPMN and event-EPC. This overloading would become even more complex if we would take into account also the token (i.e., execution) level (mentioned for instance in [27]), where the term event is used to denote specific executions of activities and is close to the meaning of event as used in an “event log”. This semantic overloading is somehow not a surprise for the BPM community, where the term “event” is used to denote elements that can pertain the type level, the token level, something that happens in time, a trigger that has causal power, and pre-postconditions.Footnote 5

In this paper we concentrate our analysis mainly on the way “event” is used, in the different meta-models at type level. Nonetheless, it is easy to notice that, from an ontological point of view, events are often understood as elements happening at token level, that is, specific occurrences in time (see e.g., [8]). Then, what are event-BPMN and event-EPC? By looking at the language specification of BPMN, event-BPMN can be explained in terms of “a pattern of behaviour”, that is, an activity type, which is an abstract entity [8].Footnote 6 Indeed event-BPMN, similarly to activities in that language, can be realised at token level by event occurrences (they happen in time), and can be repeated again and again in several process executions. What seems to differentiate the two notions in BPMN is more the fact that events “happen” in the world while activities denote pieces of works that a company (or a process owner more in general) should perform. Our proposal, therefore, is to borrow some concepts from the domain of statistics and conceive them as a sort of exogenous activity type, in contrast to the activities that happen within the process owner boundaries, that we rename endogenous activity type. This is a first analysis that may be further refined as these boundaries in BPMN are not always clear and events in BPMN are used to denote both elements with an “active” flavour (e.g., sending a message) as well as elements with a more “passive” flavour (e.g., exceptions or timers), whose differences should be accounted for. Nonetheless, we consider event-BPMN as an activity type as all these elements would be considered as “a pattern of behaviour” at type level according to [8] and not elements happening at token level.

If we move to ARIS EPCs, the analysis is slightly more complex. On the one hand, event-EPC is used as pre-postconditions which seem to be conceived as states. On the other hand, event-EPC is also described as an activator of activities. These two views are, from an ontological point of view, incompatible, as states cannot have causal power characteristics. Indeed, although states can be involved in causal relations, they cannot cause anything per-se [9]. Consider in a loan application process, “To have the credit history” is a state which acts as precondition for the “assess eligibility” activity, but that precondition alone cannot cause the assessment of eligibility. In this respect, the relation precondition activity found in the LB meta-modelFootnote 7 appears to be more adequate than the one of event-EPC activity. Inspired by the analyses in [3] and [9], in this paper we propose to solve this inconsistency by viewing event-EPC as a specific pre-postcondition, and thus removing it, together with the relation from the diagram. Nonetheless, we strongly believe that this causal notion involving activities should be further investigated. Indeed, this double view of the notion of event-EPC, together with the higher presence of the notion of precondition w.r.t. the one of postcondition in the analysed meta-models, seem to suggest a need to incorporate some notion of “trigger” (distinct from a notion of state) that can explain (cause) the activation of activities within a business process. Instead, when discussing causal relations we can note that, although activities cannot cause directly anything (e.g., create) at type level, they have a sort of causal power, as they can explain why a certain activity type can cause something else, such as a state or other activities. Figure 2 summarises the refactoring of the two notions of event-BPMN and event-EPC explained above. Filled boxes represent newly added entities, and boldface has been used to denote newly added relations. Note, that we have included also postconditions to the diagram, and the relations that pertain this entity. Also, we have transferred the relations between event-EPC and activity to the appropriate relations between pre-postconditions and activity.

Fig. 3.
figure 3

Meta-model of resources.

The Organisational/Data Component. To start disambiguating the organisational/data component, let us start by analysing the notion of resource. Similarly to what happened with the term event, also resources are defined, in the BPM community, in many different ways such as “[...] items necessary for a team to understand a problem and implement solutions [...]”, “Agent used to perform activities [...]”, “People, equipment, or materials required or used to accomplish an activity. [...]”, and “Assets that is consumed in the operations [...]”Footnote 8. All of these views upon resource are somehow included in Fig. 1, however in an overly rich and redundant manner that overlaps also with other elements such as artifact and actor.

State-of-the-art ontological analysis in the context of Enterprise Modelling and manufacturing has classified resources in terms of roles that entities play within the context of an activity [5, 7, 24]. While an in-depth analysis of the notion of role is beyond the scope of this paper we can rely on the ones that have already been undertaken in literature, such as [17, 18]). What we can retain here is the assumption that roles are dependent upon other entities for their existence and can be played, in context and time, by agentive (e.g., a person) and non-agentive (e.g., a data object) participants. Thus, roles can be conceived of variously including as social concepts that describe what that role is and in terms of relations [17, 18].

In Fig. 3 a refactoring of the organisational/data component based on the notion of “resource in terms of role it plays” is depicted. For the sake of clarity, the filled boxes denote reference concepts in the upper ontology DOLCE [16] in its extension for roles as social concepts [18] and in the analysis of business process participants [2]. In this diagram a business process resource role when it is (endogenous) activitiesFootnote 9. Note that we used association classes to reify the relation, to denote that the object denoting a resource playing a role is assigned to an activity. An actor is an agentive business process participant and an artifact is a non-agentive participant, and both can have physical and/or non-physical characteristics. Note that the association between the resource and the role occurs within the boundaries of activity, which somehow plays here the role of context in the definition of something as a resource [5, 24].

A final comment is devoted to the resource precondition relation found in the LB meta-model. While this relation must be deemed wrong, as a resource is not usually seen as a state, it is nonetheless true that the existence of resources with certain characteristics and capabilities can act as preconditions to the execution of certain activities. As such this relation should be further investigated.

6 Related Works

To the best of our knowledge, no work has been carried out so far specifically investigating and analysing the existing literature related to business process meta-models. However, a variety of sources exist that attempt to bring clarity to certain aspects of business process and modelling. Some of these papers are focused on the creation of business process meta-models and are indeed included in the list of the primary studies. For example, in both List et al. [14] and Söderström et al. [27] conceptual frameworks of business process are proposed in order to evaluate or compare and translate modelling notations. In the work of Heidari et al. [12], a general meta-model is developed starting from the elements of seven business process modelling languages. The language independent meta-model is finally compared and analysed with an ontology.

Several papers have been focusing on the ontological analysis of business process modelling and related fields. The works in [2, 3, 5, 7, 24] have been already discussed in reference to our work in Sect. 5 and are not described here for lack of space. In Sanfilippo et al. [25] an ontological analysis of event and activity constructs in BPMN is presented. In [26], Santos Jr. et al. presented an ontological analysis of ARIS EPCs using the UFO ontology [10] for the semantic interpretation of the elements. In particular, they focused on the analysis of function, event and rule. Focusing on works independent from specific modelling languages, in [11] Guizzardi et al. propose an ontological analysis of events. The analysis is performed considering the UFO ontology and, although the paper is not committed with the specific representation of events in business process modelling, the research analyses conceptual models, reference frameworks and domain ontologies also in the area of business process modelling. Other works (e.g., [22]) analise business process modelling using the Bunge Wand and Weber ontology [29] as reference framework. Concerning goals, the work in [1] provides a classification of business process goals from the point of view of participants, while the work in [28] analyses and integrates notion of goal and soft-goal in business process modelling. A careful evaluation of how to complement our work with the ones listed here is left for future works.

7 Conclusion

In this work a business process meta-model extracted from state-of-the-art proposals through a systematic literature review is presented, together with a preliminary ontological analysis of notions such as events, preconditions and resources. Although the single meta-models proposed in literature were individually consistent, combining them into a unique LB meta-model, allowed us to identify criticalities, to carry on a first analysis of these criticalities, and to propose possible solutions. This analysis gave us the opportunity to clarify, from an ontological perspective, well-known issues concerning the use of labels as event and resource and to investigate these interpretations within and outside the BPM community.

In the future we plan to further extend this work by addressing unsolved issues highlighted in Sect. 5. For instance, we would like to investigate the notion of “trigger” in relation to activities, as well as to analyse business process elements neglected in the individual meta-models, such as goal and value.

These investigations can provide a first step in the direction of a well-thought and agreed view on multi-perspective business process components at the conceptual level. This view would be beneficial not only for the development of new notations and systems, but also for improving the interoperability of existing notations and information systems.