Keywords

1 Introduction

Digitalisation efforts under the European digital transition paradigm in the engineering and materials development domains are today introducing new methods for digital collaboration and open innovation, like the one proposed in VIPCOATFootnote 1: the EU funded Research and Innovation Action implementing digitalisation approaches offer a multi-sided platform to create a collaborative environment to connect modellers (software owners, academia), and translators [21], manufacturers, governmental bodies and society to initiate and implement innovation projects (Fig. 1). The demonstration focus of VIPCOAT is the development and manufacturing of active protective coatings. However, the approach is applicable to any other industrial case. To assist industrial end-users in making optimal decisions about materials and process design and manufacturing based on predictive modelling, it is increasingly necessary to examine innovation through a quadruple helix approach, which addresses the need for a Digital Single Market strategy for Open Innovation 2.0 [5]. In parallel, an enormous amount of materials, manufacturing and processing data are currently generated by high throughput experiments and computations (e.g., [35, 36], possessing a significant challenge in terms of data integration, sharing and interoperability.

Given that a product or a material system is defined by a combination of its physical, chemical and other technical properties, as well as other business-related aspects, such as cost, environmental footprint, and other information relevant to industry, academia, administration and the society at large, such integration has the advantage of enhancing significantly mutual understanding of human stakeholders and their respective domain-specific digital tools. As an example, considering in VIPCOAT, the physical and chemical properties of a protective coating can have a significant impact on production time, resource utilisation, manufacturing cost, sustainability, and toxicity. Hence, comprehending the properties of materials is critical to streamlining the manufacturing process, identifying appropriate machinery and equipment, and estimating relevant business indicators for informed decision-making [2]. This integration is particularly important in the context of Open Innovation, where companies collaborate to develop new products and services [24].

Fig. 1.
figure 1

Quadruple-Helix Virtual Open Innovation Framework: Industry, Society, Academia, and Governments

Full size image

Although the existing literature (reviewed in Sect. 2) demonstrates a growing recognition of the need for integration between business processes, materials science, and engineering workflows, the integration of BPMN with EMMO does not exist yet and is crucial step forward to support inter-domains mutual understanding. A common ontology is mandatory to lay the foundation for unlocking a huge innovation potential by enabling semantic interoperability of models, experiments, software and data, which is vital for using rational development design principles and testing and manufacturing of materials in general. The aim of this work is consequently to contribute to the current efforts by the European Materials Modelling Council (EMMC)Footnote 2 on establishing common standards for materials modelling through the Elementary Multi-perspective Material Ontology (EMMO), e.g. [15]. The basic idea is to merge Business Decision Support Systems (BDSS), implemented in terms of the Business Process Model and Notation (BPMN) and Decision Model and Notation (DMN) standards, with materials modelling workflows by using ontologies as a glue between these hitherto distinct worlds.

BPMN is an efficient tool for Open Innovation processes [34]. BPMN enables organisations to visually depict their business processes and workflows in a standardised format, which fosters more effective communication and collaboration with external stakeholders such as customers, suppliers, and partners. Further more, the tool ensure an automatic implementation of some processes between involved in the collaboration (business) players. The standardised representation of business processes using BPMN allows for the identification of inefficiencies, redundancies, and bottlenecks in the workflow, leading to streamlined operations and increased efficiency [19]. Moreover, the use of BPMN provides a common language for discussing business processes, making it easier to share ideas and identify opportunities for improvement [24]. As a result, the ontology facilitates collaboration, accelerates innovation, and promotes the sharing knowledge and best practices between organisations and business partners.

The EMMO, see [14], is a currently very intensive developing comprehensive and versatile ontology for materials science that aims to provide a common language for describing materials and their properties. The EMMO was developed by a group of European researchers as a part of an EMMC activity, which recognised the need for a unified approach to materials modelling and data sharing interoperability. The main ideas of the EMMO is to be designed as a universal tool, that can be applicable to all levels of granularity, from atoms and molecules to macro-scale materials. Thus, the developed ontology aims to cover all aspects of materials science, including properties, structures, processes, and applications. The EMMO is based on a multi-perspective approach, which means it considers different perspectives and scales when describing materials. It provides a hierarchical structure that allows for the description of complex systems and a comprehensive set of classes and relationships for describing materials properties, including chemical composition, crystal structure, thermodynamic and mechanical properties, and more. The EMMO is also designed to be extensible. Thus, it can be customised to meet the specific needs of different domains and applications. One of the key objectives of the EMMO is to promote interoperability between different materials modelling approaches and software tools. By providing a common language for describing materials and their properties, the EMMO can facilitate the integration of models and data from different sources and the development of open standards and interfaces for materials modelling. This, in turn, this ontological approach can accelerate the development of new materials and improve the efficiency of materials design and testing.

The integration of BPMN and EMMO can facilitate communication and collaboration among stakeholders, ultimately leading to the development of new materials and products. The integration of ontologies can lead to faster and more cost-effective research and development and the creation of innovative solutions to address complex material challenges. This paper aims to answer the research question of how BPMN can be connected with EMMO or vice versa, and proposes MBCO: the Materials-based Business Case Ontology. Therefore, we put forward a concrete approach for integrating ontologies, consisting of conceptual alignments, concept mapping, concept integration, and validation.

The proposed schema is applied to a preliminary analysis of integrating BPMN into the EMMO. Section 2 provides an overview of the ontologies, extension mechanisms, and related works, while Sect. 3 describes the process of developing and validating MBCO, the integrated ontology. The paper concludes in Sect. 4 presenting the final conclusions.

2 Background

This section introduces BPMN and EMMO ontologies, reminds the different ontology extension mechanisms at our disposal, and presents the main related works.

2.1 BPMN

BPMN stands for Business Process Model and Notation [27]. It is a graphical representation for specifying business processes in a standardised way. BPMN was created by the Business Process Management Initiative (BPMI) and is now maintained by the Object Management Group (OMG)Footnote 3. The primary purpose of BPMN is to provide a standardised notation that is readily understandable by all business stakeholders, including technical and non-technical users. This notation enables clear communication and collaboration between business and technical teams while modelling and analysing processes and supporting the execution of processes in a technology-agnostic manner. To this end, BPMN provides a set of graphical elements, such as processes, tasks, gateways, and events, that can be used to model various types of business processes. The notation also supports the modelling of more complex process flows, such as parallel and sequential execution, exception handling, and compensation. BPMN is a widely adopted standard that helps organisations to model, to analyse, and to improve their business processes, leading to increased efficiency and effectiveness.

2.2 EMMO

The Elementary Multi-perspective Material Ontology (EMMO) is an ontology that focuses to provide a standardised and structured representation of the domain of materials science and engineering [13]. An ontology is a type of knowledge representation that defines a common vocabulary and formal model for describing concepts and relationships in a specific domain.

The EMMO provides a comprehensive, hierarchical, and interlinked view of the concepts, classes, and relationships that are commonly used in materials science and engineering. It covers a wide range of topics, including material properties, processing techniques, and the relationships between materials and their components. The EMMO aims to support a shared understanding of the concepts and terms used in the field, making it easier for researchers, engineers, and data scientists to collaborate and exchange information.

The EMMO is designed to be used as a resource for a variety of applications, including knowledge management, semantic search, and data integration in materials science and engineering. It can also help to integrate diverse data sources and support interdisciplinary research by providing a common vocabulary and conceptual framework. In this paper, we use EMMO version 1.0.0.beta5 from github.Footnote 4

2.3 Ontology Extension Mechanism

According to [37], the integration of two models (meta-models [6] or ontologies [11]) requires resolving three types of heterogeneity: syntactic, semantic and structural. For our integration, only the semantic and structural heterogeneity have been addressed. Indeed, the syntactic heterogeneity aims at analysing the difference between the serialisations of meta-model and, as explained by [31], addresses technical heterogeneity like hardware platforms and operating systems, or access methods, or it addresses the interface heterogeneity like the one which exists if different components are accessible through different access languages [9, 10]. Hence, it is not relevant in the case of this ontological integration.

Structural heterogeneity exists when the same meta-model concepts are modelled differently by each meta-model primitive. This structural heterogeneity has been addressed together with the analysis of the conceptual mapping and the definition of the integration rules. Finally, the semantic heterogeneity represents differences in the meaning of the considered meta-model’s elements and must be addressed through elements mapping and integration rules. Regarding the mappings, three situations are possible: no mapping, a mapping of type 1:1, and a mapping of a type n:m (n concepts from one meta-model are mapped with m concepts from the other).

After analysing the heterogeneities, ontology extension mechanisms are applied. Ontology extension mechanisms refer to the ways in which an existing ontology can be expanded or modified to better suit the needs of a particular application or domain. There are several methods that can be used for ontology extension, including:

  • Inheritance (generalisation): This is a common method of ontology extension in which a new class is defined that inherits properties and characteristics from an existing class. This allows new classes to be defined while reusing existing definitions and knowledge (e.g., in [12], inheritance relationships to extend OWL-S).

  • Restriction (specialisation): This is a method of ontology extension in which the definition of an existing class is restricted to exclude certain individuals or objects. This can be used to refine a class’s definition to better match a particular application’s requirements.

  • Extension (by adding axioms): This is a method of ontology extension in which new axioms or statements and rules are added to the ontology to provide additional information or, a priory, knowledge.

  • Modules and Libraries: This is a method of ontology extension in which ontologies can be packaged as modules or libraries and can be imported or reused in other ontologies.

Each of these methods has its own strengths and limitations, and the appropriate method for a particular extension depends on the application’s requirements and the design of the ontology being extended on a case-by-case basis.

2.4 Related Work

The integration of business process with industrial ontologies is not new. For instance, research conducted by [20] has explored methods for formalizing product and process requirements using a collaborative ontology, employing semantic reasoning techniques for process formation. Or, in the same vein, [23] used BPMN and ontologies to modeling and to integrating production steps with typical IT functionalities. In [2], another approach consists in integrating material modelling with business data and models to develop a Business Decision Support System (BDSS) [34] that assists in the complex decision-making process of selecting and designing polymer-matrix composites. This system combines materials modelling, business tools, and databases into a single workflow, providing a comprehensive solution supporting decision-making.

In [19], the authors suggest utilising the BPMN and DMNFootnote 5 standards [33] to bridge the gap between business processes, materials science, and engineering workflows in the context of composite material modelling, which can potentially open up new horizons for industrial engineering applications. By using these standards ([4, 33]), it is possible to establish a connection between the diverse domains and provide a more integrated approach to the modelling process, which could lead to improve efficiency and effectiveness in engineering applications.

In line with the previous approach, [18] extends the analysis by incorporating technical key performance indicators (KPIs) and financial KPIs, such as part costs, calculated using cost modelling applications. By including financial KPIs in the analysis, a more comprehensive understanding of the overall performance can be achieved, which can assist in the decision-making process related to product design and development starting from very early design decisions.

In [17], the authors discuss the development of an ontology called OSMO, which is an extension of the Model Data (MODA)Footnote 6 legacy metadata standard for simulation workflows used in some European materials modelling projects [16]. While MODA workflow descriptions are interpretable by human experts in modelling of the target application domains only, OSMO adds rigour to MODA by using an unambiguous ontological language. To this end, [17] explains the purpose, design choices, implementation, and applications of OSMO, including its connections to other domain ontologies in computational engineering. OSMO was created as part of the EU funded VIMMP projectFootnote 7 and is connected to the larger effort of ontology engineering by the EMMC. A crosswalk from MODA workflows via OSMO to EMMO has been described in previous work [22], making use of a graph transformation system [29] for the required complex structural alignment. In this way, based upon the integration of EMMO and BPMN into a common ontology like the MBCO, as discussed in the next section, a clear conceptual route to integrating the MODA workflows documented in a series of European projects into formal enterprise architectures will be available.

3 MBCO Development by EMMO/BPMN Integration

The development of MBCO involves the integration of EMMO and BPMN into a single ontology that reflects the combined knowledge represented by both initial ontologies [25, 26]. The successful integration of ontologies plays a pivotal role in fostering collaborative knowledge representation across domains. Therefore, this section explores a four-step methodology for ontology integration, illustrated in Fig. 2. Each step is carefully designed to ensure a systematic and coherent synthesis of knowledge from distinct ontologies. The motivation behind this methodology lies in achieving a unified ontology, which amalgamates the strengths of the original ontologies. The method that we propose includes the following four steps:

  • Alignment: This involves identifying and matching the concepts, classes, and relationships in the two ontologies that correspond to each other. This step requires a careful examination of the structure, content, and meaning of the concepts and relationships in both ontologies. The condition for progressing to the mapping step is a thorough understanding of the structure, content, and meaning of concepts and relationships is essential.

  • Mapping: This involves creating a mapping between the concepts and relationships in the two ontologies based on the results of the alignment step. This mapping defines how the concepts and relationships in the two ontologies correspond to each other. The condition for progressing to the integration step is a successful completion of the alignment step provides the groundwork for creating an accurate and comprehensive mapping.

  • Integration: This involves combining the two ontologies into a single ontology (MBCO), using the mapping as a guide. The resulting merged ontology should reflect the combined knowledge represented by both original ontologies. The condition for progressing to the validation step is a well-defined mapping, created in the previous step, acts as a guide for the seamless combination of the ontologies into the integrated MBCO.

  • Validation by Incoherence Solving: This involves checking the merged ontology to ensure that it is logically consistent and coherent and that it correctly represents the combined knowledge from both original ontologies. The condition for a successful validation is that the integration in the previous steps forms the basis for validating the MBCO, addressing any inconsistencies or incoherence discovered during this critical evaluation.

Fig. 2.
figure 2

Four steps of the method used to integrate BPMN into EMMO: Alignment, Mapping, Integration and Validation

Full size image

3.1 Alignment

Conceptual alignment, as explained in [7], is the process of identifying and establishing the syntactic and structural correspondences between concepts or entities from two or more different sources or domains, should it be at the definition or at the association with other concepts level. To achieve this alignment, we listed all BPMN concepts, including their definition and association, and then we looked for correspondence with the EMMO concepts [13].

After a review of all BPMN [4] concepts, we observed that eight concepts from BPMN may be aligned with nine concepts from the EMMO. This alignment is possible based on analysing the concepts’ names and definitions (syntactic alignment) and their associations with the other concepts (structural alignment). The alignment result is the following:

  • Process vs. IntentionalProcess.

    • The definition of Process from BPMN is a Process describes a sequence or flow of Activities in an organisation with the objective of carrying out work [4].

    • In the EMMO, the Process is defined by A whole that is identified according to criteria based on its temporal evolution that is satisfied throughout its time extension and the IntentionalProcess extends the definition with occurring with the active participation of an agent that drives the process according to a specific objective (intention) [13]. Both the Process and the IntentionalProcess are respectively part of and subClass of Process and are associated with the Participant.

  • Participant (BPMN) vs. Participant (EMMO).

    • In BPMN, a Participant represents a specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are Participants in a Collaboration. A Participant is often responsible for the execution of the Process enclosed in a Pool [4].

    • In the EMMO, this is an object which is a holistic spatial part of a process. If plays an active role in the process, this is an Agent [13]. Both are linked to the concept of BPMN and EMMO’s Process.

  • Activity vs. Elaboration.

    • BPMN defines the Activity as a work that is performed within a Business Process [4]. An Activity can be atomic or non-atomic (compound).

    • From the side of the EMMO, an Elaboration is the process in which an agent works with some entities according to some operative rules [13]. Elaboration is a subClass of IntentionalProcess, and Activity is a component of Process (although not represented in BPMN meta-model from [4]). Both also have subClasses ElementaryWork, Computation, Workflow for Activity and, similarly, CallActivity, Task, SubProcess for Elaboration.

  • Task vs. ElementaryWork

    • The definition of Task in BPMN is an atomic Activity within a Process flow. A Task is used when the work in the Process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the Task when it is executed [4].

    • In the EMMO, a ElementyraWork is an elaboration that has no elaboration proper parts, according to a specific type [13], which means that an ElementaryWork does not break down into smaller pieces of work. Task and ElementaryWork are respectively subClasses of Activity and Elaboration.

  • ThrowEvent vs. Status

    • Throwing events, following BPMN, are triggers for catching events and are triggered by the process, which result in ThrowEvent [4].

    • Status, following the EMMO, consists in an object which is a holistic temporal part of a process [13]. Both concepts have no similar association with other modelling concepts.

  • InteractionNode vs. SubProcess and Stage

    • The alignment between both concepts from both meta-models is more arduous to establish but is real. In BPMN, the InteractionNode is a type of flow object that represents a point in a process where participants interact with each other to exchange information or perform some action [4].

    • In the EMMO, the SubProcess is a process which is a holistic spatial part of a process, and the Stage is a process which is a holistic temporal part of a process [13]. The semantic analysis of these three definitions does not make it possible to establish an indisputable alignment between the concepts. However, the analysis of associations clearly shows the similarities. Indeed, the InteractionNode is a subClass of Activity and FlowElementaryContainer, and is composed of Artifact and similarly, (1) the SubProcess has SubProcess and is SubClass of Process and (2), the stage has Stage and is SubClass of Process.

  • SequenceFlow and WorkFlow

    • According to BPMN, the SequenceFlow is used to show the order of Flow Elements in a Process or a Choreography. Each Sequence Flow has only one source and only one target [4].

    • For EMMO, the Workflow isan elaboration that has at least two elaborations as proper parts [13]. At the association level, the SequenceFlow is a subClass of FlowElement (abstract superclass for all elements that can appear in a Process flow), and the WorkFlow is a SubClass of Elaboration.

  • ItemAwareElement and EncodeData

    • The ItemAwareElement in BPMN refers to several elements that are subject to store or convey items during process execution [4].

    • The EncodedData are in EMMO causal object whose properties variation are encoded by an agent and that can be decoded by another agent according to a specific rule [13]. The ItemAwareElement concept has type DataObject, DataSTore, DataInput and DataOutput, which are type of information, and the EncodedData is a subClass of Data and has subClass Information.

3.2 Mapping

In order to integrate BPMN concepts and relationships within the EMMO, it is necessary to analyse and select the best ontology extension mechanism (detailed in Sect. 2.3) for each conceptual mapping achieved in Sect. 3.1: Inheritance, Restriction, Extension, or Modules and Libraries – knowing that the last method is inappropriate to the purpose of our work. The result of the mapping is:

  • IntentionalProcess: The analysis of the definitions provided in Sect. 3.1 demonstrates that both meta-models define the IntentionalProcess/Process based on the same arguments to know: that a process is structured following a sequence of activities and that it aims to reach an objective. BPMN’s semantics is richer than the EMMO’s semantics in that it associates the process to an organisation. Therefore, the preferred extension mechanism is the restriction (EMMO restricts BPMN conceptual semantics).

  • Participant: The EMMO’s definition of Participant is more generic than the definition from BPMN, which considers that the participant is a human, or an organisation, that is often responsible for the execution of a process [8]. This is more specific than the EMMO’s point of view, which considers that an object demonstrating a holistic spatial part of the process is a participant. Accordingly, the extension mechanism that fits this alignment is inheritance. First, the BPMN’s participant inherits the characteristics of EMMO’s participant, and second, the EMMO’s participant is extended with two possible statements: the participant is either a human or an organisation.

  • Elaboration: The EMMO’s definition of Elaboration is semantically a bit different than BPMN’s definition of Activity. On one side, BPMN explains that the Activity may be atomic or compound, and on the other side, the EMMO stresses the importance of the Elaboration to work following some operative rules. As a result, the most appropriate extension mechanism is inheritance, and the EMMO Elaboration is extended with a composition link from/to the EMMO Elaboration concept.

  • ElementaryWork: Task and ElementaryWork have the same semantics, and both refer to the smallest and indivisible piece of work composing a process. The definition of the Task from BPMN (Sect. 3.1) is semantically richer in that it stresses the importance of being within a traffic flow and being performed by an end-user or an application. In this case, the ontology extension mechanism used is the extension (BPMN extends EMMO conceptual semantics).

  • Status: The definition of Status in the EMMO highlights that this concept stands for an object that reflects a temporal part of a process, whereas BPMN defines ThrowEvent as a trigger for catching events by the process. Although not explicitly embedded in the definition, the Status associated with a process often triggers other events in practice. Therefore, we consider that this Status may be a type of trigger and, by extension, a ThrowEvent. Therefore, the mapping between both concepts is achieved using the restriction mechanism given that EMMO restricts ThrowEvent to Status.

  • SubProcess and Stage: Both concepts represent part of the process (spatial or temporal), such as the InteractionNode from BPMN, which is described as a point in a process. The semantic heterogeneity between both BPMN and EMMO meanings is that the first specialises the finality of the concept to a place (or moment) where participants get together to achieve something or to exchange information. The description of the InteractionNode is consequently semantically more expressive, although both SubProcess and Stage refer to a spatial or a temporal dimension. As a result, the extension mechanism is the restriction since both EMMO’s concepts restrict BPMN one. This situation is quite similar to the case of the IntentionalProcess, but because two concepts of EMMO are mapped to one concept of BPMN, it is not necessary to extend the concepts with a dedicated extension mechanism.

  • WorkFlow: Analysing the definitions of the WorkFlow and of the SequenceFlow, we conclude that the equivalence between both concepts is thin and limited. Both concepts are direct or indirect elements of the process that are associated with at least two flowing elements. The SequenceFlow adds a supplementary characteristic which is the existing sequence between the happening of the flowing elements. The extension mechanism preferred is, by the way, the restriction as WorkFlow restricts the SequenceFlow meaning.

  • EncodedData: The ItemAwareElement concept in BPMN represents an abstract concept that may be specialised in many types like DataObject, DataStore, DataInput and DataOutput although the EncodedData concept is well defined and refers to properties variation of an object. This definition restricts by the way the definition of the ItemAwareElement and, as a consequence, the restriction extension mechanism is the one naturally designated.

3.3 Integration

In the approach used in this work, all concepts from BPMN without EMMO equivalence have been introduced in the Materials-based Business Case Ontology. The main concepts are: Gateway, Events, Artifact, InteractionNode, FlowElementContainer, FlowElement, MessageFlow, DataAssociation, DataOutputAssociation, DataInputAssociation, DataObject, DataOutput, DataInput, CallableElement. Further explanations of those concepts are available in BPMN 2.0 specifications [27].

The integration of BPMN concepts with EMMO equivalence is achieved based on the mapping performed in Sect. 3.2 and taking in hand the resolution of potential associations-related issues. For each concept, the analysis is the following:

  • IntentionalProcess: The BPMN process being semantically richer than the IntentionalProcess, we may consider that the IntentionalProcess is a subClass of the BPMN Process concept, which is represented as a type of relation in UML. In the Materials-based Business Case Ontology, the IntentionalProcess is preserved. Concerning the relationships, two associations which did not exist for the EMMO concept have been added in MBCO. It consists of (1) the IntentionalProcess that relates to Collaboration and (2) the IntentionalProcess is composed of Artefact.

  • Participant: The EMMO’s definition of Participant being more generic, we have maintained the EMMO’s Participant concept in the integrated ontology, and we have extended it with an attribute inherited from BPMN, to know: the Participant is an individual or an organisation that is often responsible for the execution of the Process. Regarding the relationships, two associations which did not exist for the EMMO concept have been added in the integrated version: (1) the Participant composes the Collaboration (2) the Participant is a type of InteractionNode.

  • Elaboration: Given the small hetoregenities existing between Elaboration and Activity and the decision to consider the inheritance extension mechanism, we have maintained the EMMO’s Participant concept in MBCO, and we have extended it with a composition link, as explained in Sect. 3.2, such as an Elaboration composes an Elaboration. In parallel, three additional Activity related associations from BPMN have also been included in EMMO Elaboration: (1) an Elaboration is composed of DataInputAssociation, (2) an Elaboration is composed of DataOutputAssociation, and (3) an Elaboration is a type of FlowNode.

  • ElementaryWork: Alike the IntentionalProcess, the ElementaryWork is less rich than the Task semantic from BPMN, and for the same reason, the extension mechanism elected during the mapping step was the extension mechanism. Accordingly, we keep the ElementaryWork in EMMO extended ontology. Concerning the associated relationships, we complete the existing ones with (1) the ElementaryWork is a type of InteractionNode, and (2) the ElementaryWork has type various kinds of tasks (i.e., ScriptTask, ServiceTask, BusinessRuleTask, ManualTask, SendTask, ReceiveTask and UserTask)

  • Status: The EMMO’s definition of Status restricts BPMN’s definition of ThrowEvent to a state of a temporal part of a process, and as a result, that a Status is a type of ThrowEvent. Accordingly, the Status process is preserved in the EMMO ontology. Concerning the relationships, four associations which previously did not exist in the EMMO have been added in MBCO. It consists of (1) Status is a type of Event, (2, 3 and 4) Status has type EndEvent, ImplicitThrowEvent and IntermediateThrowEvent.

  • SubProcess and Stage: SubProcess and Stage’s definitions, as reviewed in Sect. 3.2, restrict the definition of InteractionNode. They are both preserved in the EMMO ontology. Moreover, to express that these concepts may correspond to points where participants get together to achieve something or to exchange information, new associations are defined between them and the participants.

  • WorkFlow: Provided the tight analogy between Workflow from the EMMO ontology and the SequenceFlow from BPMN, our strategy was to use the restriction extension mechanism and, consequently, to preserve the concept of WorkFlow in the Materials-based Business Case Ontology. Two associations are needed to complete the ontology integration with some workflow-related semantics coming from BPMN: (1) the WorkFlow is the source of and targets FlowNode and (2) the WorkFlow is a type of FlowElement.

  • EncodedData: EncodedData from the EMMO has a precise meaning compared to ItemAwareElement from BPMN, which has more for the purpose of specifying a collection of data. On the opposite, the ItemAwareElement may be of various types described in [4]: DataObject, DataStore, DataOutput and DataInput. Hence, EncodedData will remain in the Materials-based Business Case Ontology. Finally, one additional association must be integrated: EncodedData is source and is target of DataAssociation.

Fig. 3.
figure 3

Materials-based Business Case Ontology (MBCO). The concepts from the EMMO ontology are represented in orange, and the concepts from BPMN in green. (Color figure online)

Full size image

3.4 Validation by Incoherence Solving

In general, validating a single ontology involves checking whether the ontology adheres to certain principles and standards [3]. Here are the types of validations that can be encountered and applied:

  • syntax validation (Does the ontology follows the correct syntax and format of the ontology language?),

  • consistency validation (Is the ontology internally consistent?),

  • completeness validation (Does the ontology cover all the necessary concepts and relationships in the domain?),

  • coherence validation (Is the ontology coherent with other ontologies and standards in the same domain?),

  • usability validation (Is the ontology easy to use and understand?),

but also the validation of specific ontology criteria such as accuracy, coverage, scalability, and maintainability. Concerning the validation of an integrated ontology, such as BMPN with EMMO, we assume that the above validation types have been achieved during the design of each specific ontology and that the item left to be validated is the merging part itself, which involves Checking for inconsistencies between the ontologies.

In paper [7], the integration of BPMN within EMMO (Fig. 3) was validated through a manual incoherence discovery process, which revealed several inconsistencies upon our manual checks. As a reminder, the main type of incoherency discovered through the manual validation of the Materials-based Business Case Ontology was the identification of a cyclic hierarchy introduced between the concepts of ElementaryWork from EMMO and InteractionNode from BPMN. Solving this incoherency required a deeper analysis of both source ontologies. Therefore, by analysing EMMO and BPMN, we argued that an ElementaryWork can be considered a type of InteractionNode because an elementary work is a basic process that involves the transformation of materials, energy, or information, often through the application of energy such as heat or mechanical work. This transformation typically involves some kind of interaction between two or more entities, such as a chemical, an electrical or even a nuclear reaction or a physical change in state. Moreover, an InteractionNode is a node representing any type of interaction between two or more entities in a business process model. This can include tasks, events, and gateways, which are used to model different types of interactions. Therefore, it can be argued that an elementary work, which represents a basic process that transforms materials, energy, or information, can also be considered an InteractionNode because it involves an interaction between two or more entities, even if it is a more fundamental type of interaction compared to other types of nodes. Hence, both ElementaryWork and InteractionNode represent different types of nodes in a business process model, but an ElementaryWork can be seen as a more fundamental type of interaction that involves the transformation of materials, energy, or information, making it a type of InteractionNode in a broader sense. As a consequence, the decision was made during the manual Validation by Incoherence Solving step to keep the link “ElementaryWork is a type of InteractionNode” in the integrated model while removing the link “InteractionNode is a type of ElementaryWork.

In this paper, we use the Pellet reasoner [30] to detect and address any inconsistencies within the Materials-based Business Case Ontology. In the context of this automatic validation, a three-step process is undertaken. Initially, we implement the integrated MBCO ontology into Protégé [32]. Following this, a specific scenario is conceptualised, wherein a reasoner is employed to compute inferences. Finally, the results of these inferences are subjected to an analysis. This approach not only streamlines the validation process but also enhances the precision of identifying and resolving any inconsistencies within the ontology.

  1. 1.

    Implementation in Protégé.

    As a basis for this step, we employed one of the pre-existing ontologisations of BPMN [28]. Upon an examination and comparison with the BPMN notation standard proposed by the Object Management Group (OMG) [27], we identified certain classes that were absent from this particular ontologisation of BPMN, and appended these missing classes. For instance, additions to the ontology included “collaboration” and “elaboration”. Finally, the integrated ontology MBCO has been constructed by applying the following steps for each of the following classes:

    • IntentionalProcess: (1) the process class of the BPMN ontology has been defined as a subclass of IntentionalProcess, (2) the class of collaboration has been created in the integrated ontology, (3) two news Object properties have been created: “IntentionalProcess is composed of Artefact” that has intentionalProcess as domain and Artefact as range, and “IntentionalProcess is linked to Collaboration” that also has intentionalProcess as domain and Collaboration as range.

    • Participant: (1) A new object property has been created, “Organisation is responsible for the execution of a Process”, and this object property has for domain Organisation and for range Process, (2) another object property has also been created “Collaboration is composed of Participant”, and this object property has for domain collaboration and for range Participant, (3) the interactionNode class as been imported from the BPMN ontology, with a lowercase i, and (3) Participant has been defined as a subclass of interactionNode.

    • Elaboration: (1) The class Elaboration is defined as a subClass of itself, (2) three BPMN classes have been created in the integrated ontology: flownode, dataInputAssociation, and dataOutputAssociation, and the flownode class is a subClass of Elaboration, and (3) two news Object properties have been created: “Elaboration is composed of dataInputAssociation” that has Elaboration as domain and dataInputAssociation as range, and “Elaboration is composed of dataOutputAssociation” that has Elaboration as domain and dataOutputAssociation as the range.

    • ElementaryWork: (1) ElementaryWork has been defined as a subclass of InteractionNode and (2) scriptTask, servcieTask, businessRuleTask, manualTask, sendTask, receiveTask and userTask have been created in the integrated ontology, and they have all been defined as subClasses of ElementaryWork.

    • Status: (1) event, endEvent, implicitThrowEvent and intermediateThrowEvent have been created in the integrated ontology, (2) Status has been defined as subClasses of events, and (3) endEvent, implicitThrowEvent and intermediateThrowEvent have been defined as subClasses of Status.

    • SubProcess and Stage: Two news Object properties have been created: “Particiants get together in Stage” that has Participant as domain and Stage as range, and “Particiants get together in SubProcess” that has Participant as domain and SubProcess as range.

    • WorkFlow: (1) a flowElement class of the BPMN ontology has been integrated, (2) Workflow is defined as a subClass of the flowElement, and (3) two news Object properties have been created: “WorkFlow is source of flowNode” and “WorkFlow targets flowNode” that have both Workflow as domain and flowNode as the range.

    • EncodedData: (1) a dataAssociation class of the BPMN ontology has been integrated, (2) two news Object properties have been created: “EncodedData is the source of dataAssociation” and “EncodedData is target of dataAssociation” that have both EncodedData as domain and dataAssociation as range.

    In the context of implementing specific elements in Protégé, such as a relationship between two classes, it is necessary to address certain requirements or considerations. For instance, the relations between classes must be defined as object properties. As illustrated on Fig. 4, the association name “Participants get together in SubProcess” that associates the class “Participant” and the class “SubProcess” is the property named “get together in/gather” and this property has for Domains Participant and for Ranges SubProcess. Given that all associations with the same name (e.g., “get together in/gather”) have different Domains and Ranges, we must create as many associations as there exist cases.

  2. 2.

    Application of the ontology to a specific process – Creation of individuals

    To validate the ontology and to illustrate how it is possible to use it to infer new knowledge, we have exploited the anticorrosive pigment test management processFootnote 8 presented on Fig. 5, extracted from [24].

    Following this process, the creation of a new individual consists in defining a new direct instance of a class. For instance, based on Fig. 5, we created the following class’ instances of the Materials-based Business Case Ontology:

    • Anticorrosive Pigment is an instance of EMMO’s Process class,

    • Customer needs is an instance of BPMN’s Event class,

    • Define technical requirements, Define the process, Prepare data for lab trial, Evaluate properties, Model coating tests, Perform corrosion tests, Prepare technical report, Evaluate KPIs, Perform final analysis, and Request prototype production are instances of EMMO’s instances of SubProcess class,

    • Feasible?, Right properties?, Is applicable?, Standards fulfilled?, Move on? are instances of BPMN’s InteractionNode class. They may also be considered as instances of EMMO’s ElementaryWorks class, itself being a subClass of the BPMN’s FlowElementContainer class,

    • Business manager, Technical expert, and Laboratory/Modelling are instances of EMMO’s Participant class.

    • StartEvent, EndEvent and Inclusive/exclusive gateways are instances of respective BPMN’s classes.

  3. 3.

    Elaboration of a validation rule. In the paper [7], a critical inconsistency emerged during the manual validation of the Materials-based Business Case Ontology. This discrepancy specifically involved the creation of a cyclic hierarchy between the concepts of ElementaryWork from EMMO and InteractionNode from BPMN. Consequently, a validation rule is necessitated to detect cyclic relationships among ontology classes. This rule aims to identify scenarios where Class 1 is defined as a subclass of Class 2 while simultaneously Class 2 is regarded as a subclass of Class 1. The primary objective of this validation rule is to uncover and correct circular dependencies within the structure of the ontology’s classes. This rule will, thus, for any class within the ontology, examine its direct connections with other classes and verify that the target class does not have a direct link with the source class.

    figure a

    The validation rule is formulated using the Semantic Web Rule LanguageFootnote 9 (SWRL), an extension of the Web Ontology Language (OWL) that combines predicate logic from OWL with rule capabilities, facilitating the expression of complex knowledge in semantic web applications. This SWRL rule detects and records circular incoherence between classes in an ontology, creating a new class CircularIncoherence when two classes (?x and ?y) are found to have bidirectional hasSubClass relationships, referencing the ontology classes involved.

  4. 4.

    Inference of new knowledge by applying the validation rule

    To execute SWRL rules in Protégé, various reasoners are compatible with SWRL, including HermiT and Pellet [1]. HermiT is a high-performance DL (Description Logic) reasoner well-suited for SWRL, commonly used for inference in OWL ontologies. Pellet, another robust reasoner, supports SWRL within Protege. Known for its efficiency in reasoning over large ontologies and its optimised algorithms for processing OWL semantics and SWRL rules, this is the reason we have selected Pellet. Pellet’s efficiency in handling complex ontologies, its ability to efficiently process SWRL rules, and its active support for SWRL within Protege made it the optimal choice for our purposes. These factors, along with its compatibility and established performance, prompted our selection of Pellet for our CircularIncoherence rule execution within our merged ontology.

  5. 5.

    Analysis of the results During the reasoning process, Pellet automatically identifies new inferences and adds new individuals corresponding to the identified inferences to the existing knowledge base. For example, upon analysing the subclass relationship between ?X, representing ElementaryWork from EMMO, and ?Y, representing InteractionNode from BPMN, Pellet detected a CircularIncoherence. This inference signifies a cyclic hierarchy introduced between the concepts of ElementaryWork and InteractionNode. Pellet’s reasoning capabilities facilitated the identification and subsequent creation of individual instances of CircularIncoherence, highlighting the cyclic inconsistency within the ontology’s subclass structure. In fine, addressing this modelling conflict seeks to prevent cyclic relationships among specific individuals (e.g., Feasible? and Move on? within the process illustrated in Fig. 5), and improves the process description consistency.

Fig. 4.
figure 4

Example of relation between classes implementation in protégé – Participants get together in SubProcess

Full size image
Fig. 5.
figure 5

adapted from [24].

Anti-Corrosive Pigment Test Management Process,

Full size image

4 Conclusion

The present work integrates a pre-ontologised subset of BPMN with the EMMO into MBCO, the Materials-based Business Case Ontology. Specifically, we utilise the BPMN ontology to support the open innovation process and the EMMO ontology to describe materials and processes. In this way, we construct a more comprehensive framework that can facilitate collaboration and innovation in the materials industry. This integration aims to streamline workflows, improve communication, and enhance the understanding of materials, leading to more effective and innovative solutions. Our approach consists of four key steps: Alignment, Mapping, Integration, and Validation by Incoherence Solving. While alignment and mapping are relatively straightforward, the integration step requires more careful consideration. For instance, when the extension mechanism is an inheritance, the EMMO concept is extended with the attributes inherited from BPMN. Accordingly, for the present work, it was the key objective to enhance the validation of the MBCO through formal reasoning. To accomplish this, we have deployed the MBCO in Protégé. Our objective revolves around the establishment of rules for generating inference when cyclic incoherencies among classes are discovered. This approach, complementing that from our recent previous work [7], allows identifying a cyclic association between ElementaryWork and InteractionNode in an automatic way. The validation based on inference rules ensures the absence of inconsistencies. Therefore, we are confident that our ongoing efforts to validate the merged ontology will lead to a higher level of coherence and reliability in our knowledge system. The integration of BPMN and EMMO into MBCO in this paper holds significant research implications by offering a standardized framework for collaborative materials research, enhancing communication, and fostering efficiency in materials science. However, limitations may arise in terms of the practical adaptability of MBCO across diverse organizational settings, potentially encountering resistance to adopting a new ontology framework. Future research avenues should focus on the real-world implementation and acceptance of MBCO, addressing identified limitations, and exploring the scalability and adaptability of the proposed ontology in different research contexts to ensure its widespread applicability.