Wenxin Mu
email: wxmu@bjtu.edu.cn

Frédérick Bénaben

Hervé Pingaud

Collaborative process cartography deduction based on collaborative ontology and model transformation

Keywords:

Collaborative process cartography deduction based on collaborative ontology and model transformation

Wenxin Mu, Frederick Benaben, Hervé

Introduction

The ability of organizations (enterprises or institutions) to operate in collaboration is a key indicator of their level of competitiveness. However, organizations, whether recent or well established, rarely take considerable interest in their collaborative capacities (which are mainly empirical abilities that are informally built and used as needed). We propose to study the specificities and requirements of organizational collaboration from an IS (Information Systems) point of view and to define an engineering approach dedicated to facilitating the deployment of these emerging collaborative networks.

Enterprise interoperability can be seen as the capacity of enterprises or organizations to structure, formalize, and present their knowledge and to exchange or share it. Guedria et al. [START_REF] Guedria | Maturity model for enterprise interoperability[END_REF] introduce numerous methods, tools and languages, which have been developed to enhance enterprise interoperability. In Nicolle et al. [START_REF] Nicolle | Interoperability of information systems[END_REF], various architectures for the interoperation of information systems are introduced and compared, including the Peer-to-Peer [START_REF] Milojicic | Peer-to-peer computing[END_REF][START_REF] Zhang | Self-organized P2P approach to manufacturing service discovery for cross-enterprise collaboration[END_REF], Standardization 1 , Federation 2 , Multi-base 3 , Ontology [START_REF] Guarino | Ontologies and Knowledge bases -towards a terminological clarification[END_REF][START_REF] Hoang | Ontology-based approaches for cross-enterprise collaboration: a literature review on semantic business process management[END_REF] and Mediation [START_REF] Wiederhold | Mediators in the architecture of future information systems[END_REF] methods. Considering the difficulty in building common standards and initializing a collaborative environment, the combination of ontology and mediation is the most suitable way to solve interoperability problems. Achieving sustainable interoperability among organizations in a networked environment is a crucial factor for successfully managing collaborations at all levels: abstract (business) and concrete (technology) [START_REF] Jardim-Goncalves | Collaborative negotiation for ontology-driven enterprise businesses[END_REF]. In the field of IS (Information Systems) interoperability, the research topics and results are focused on either the business process or the technical workflow. This has led to the development of a huge gap between the business level and the technical level. Therefore, our research is focused on filling this gap by transferring business knowledge to a collaborative process.

To address the difficult task of constructing an automatically collaborative business process, our lab launched the Mediation Information System Engineering (MISE) project (2003)(2004)(2005)(2006)(2007)(2008)(2009)(2010)(2011)(2012)(2013)(2014). Rajsiri et al. [START_REF] Rajsiri | Knowledge-based system for collaborative process specification[END_REF] defined the business level of MISE 1.0 (Mediation Information System Engineering version 1.0) by using the Model-driven Architecture (MDA) [START_REF] Miller | MDA Guide Version 1.0. 1[END_REF] and the Service Oriented Architecture (SOA) [START_REF] Krafzig | Enterprise SOA: service-oriented architecture best practices[END_REF][START_REF] Vernadat | Interoperable enterprise systems: principles, concepts, and methods[END_REF]. They defined collaborative ontology for gathering collaborative information and transferred this information to a collaborative business process. However, according to ISO 9000 [START_REF]ISO 9000 Quality management[END_REF], the business process is classified as a strategy, operation and support process. One single but complex collaborative process in MISE 1.0 leads to a problem: the collaborative process is difficult for partners to understand in different roles, e.g., managers, workers, and operators.

To solve this problem, a cartography of collaborative processes is required to classify the entire collaborative process into strategy, operation or support collaborative processes (as shown in Fig. 1). In 2009, our lab launched MISE 2.0 to generate the cartography of collaborative processes automatically. Fig. 1 shows an example of collaborative process cartography, which is based on BPMN (Business Process Modeling Notation) [START_REF]OMG, Business Process Model And Notation (BPMN) Version 2.0[END_REF][START_REF] Ouyang | From BPMN process models to BPEL web services[END_REF][START_REF] Pillat | BPMNt: a BPMN extension for specifying software process tailoring[END_REF]. The collaborative process cartography first defined the collaborative process by its main functions, which are positioned in different pools (strategy, operation, support and general). Each main function is specified by another collaborative process cartography or a collaborative process, which depends on the complexity of the main function.

To deduce the collaborative process cartography, the following research questions should be answered:

• How should a collaborative ontology be defined? In ontology, all concepts involved in the collaborative situation, collaborative process, and process cartography should be included. • What is the best way to search or transfer the useful process entities to fill the collaborative ontology?

• How should the deduction rules to be used to obtain the collaborative process cartography that will be defined?

In this paper, Section 2 gives the introduction of related works. Section 3 presents the global view of this research work and our working definition of collaborative ontology. Section 4 provides the transformation rules from gathered knowledge to deduced knowledge in the collaborative ontology. Section 5 presents the deduction rules used to deduce the cartography of collaborative processes from collaborative ontology. Section 6 is a sketch of the knowledge transforming results and the implementation of software tools, and it includes a case study. Section 7 gives the evaluation results. Section 8 provides the comparisons with related works.

Related works

A BPM (Business Process Management) life cycle includes six steps: design, modeling, execution, monitoring, optimization and re-engineering [START_REF] Ter Hofstede | Business process management: a survey[END_REF]. Patig et al. [START_REF] Patig | IT Requirements of business process management in practice -an empirical study[END_REF] have conducted a worldwide survey of major public companies to elicit the requirements, which are grounded in the nature of the processes and the software usage. The analysis of 127 responses indicates that BPMs with software integration capabilities are the most urgently required. Our work is focused on "modeling", but with a special word ("automatic deduction") for solving the gap between process modeling and software integration capabilities, we are interested in determining how the software should be used to deduct the cartography of collaborative business processes.

To analyze the related works, we searched the web of science with the key words "business process" and "collaboration". We found 312 articles from 2013 to 2015. We narrowed these down to 14 strongly related articles, which were mainly published by journals under the information systems category, e.g., "Information Sciences", "Information Systems", "Enterprise Information Systems" and "IEEE Transactions on Systems Man Cybernetics-Systems".

Comuzzi et al. [START_REF] Comuzzi | Optimized cross-organizational business process monitoring: design and enactment[END_REF] propose an approach to flexibly design and enact cross-organizational business process monitoring based on a Product-Based Workflow Design. Antonia Martinez-Carreras et al. [START_REF] Pingaud | Building and evaluating context-aware collaborative working environments[END_REF] describe the building of a context-aware application integrated in a Collaborative Working Environment (CWE) architecture, and they compared this new augmented application to existing applications. Bae et al. [START_REF] Bae | Planning of business process execution in business process management environments[END_REF] introduce a methodology for incorporating business process semantics and alternative paths in the Business Process Management structure. Nie et al. [START_REF] Nie | Supporting BPMN choreography with system integration artefacts for enterprise process collaboration[END_REF] base their work on exchanged messages among processes. They consider behavior mismatch scenarios as the main feature of the message to identify occurrences in the mismatch patterns, leading to a corresponding process. Bianchini et al. [START_REF] Bianchini | Service identification in interorganizational process design[END_REF] provide a detailed description of process-to-service, which is a computeraided methodology used to enable the identification of services that create a collaborative business process. Norta et al. [START_REF] Norta | A reference architecture for managing dynamic inter-organizational business processes[END_REF] define the reference architecture as a division of the functionality, with the exchanged data flow mapped onto the software elements that implement the required functionality for a specific context and the business goals of the stakeholders. Hoisl et al. [START_REF] Hoisl | Modeling and enforcing secure object flows in process-driven SOAs: an integrated model-driven approach[END_REF] present an integrated model-driven approach for the specification and the enforcement of secure object flows in processdriven service-oriented architectures (SOA). A secure object flow ensures the confidentiality and integrity of important objects that are passed between difference participants in a SOA-based business process. Liptchinsky et al. [START_REF] Liptchinsky | On modeling context-aware social collaboration processes[END_REF] consider a collaboration process as the evolution of a network of collaborative documents along with a social network of collaborators. Yongchareon et al. [START_REF] Yongchareon | A view framework for modeling and change validation of artifact-centric inter-organizational business processes[END_REF] present a framework for modeling inter-organizational business processes and validating the changes to them. They develop algorithms to find the minimal public view for a given inter-organizational business process. Zeng et al. [START_REF] Zeng | Modeling and verification for cross-department collaborative business processes using extended petri nets[END_REF] built a Petri-net based RM_MF_Net model to provide systematic modeling and verification for the cross-department processes when considering different types of coordination patterns among different departments. Cortes-Cornax et al. [START_REF] Cortes-Cornax | Using intentional fragments to bridge the gap between organizational and intentional levels[END_REF] link the local and global perspectives of the inter-organizational business processes defined in BPMN2.0. They maintain a separation of concerns between the intentional level captured by the goal model and the organizational level captured by the process model. Rico et al. [START_REF] Rico | An approach to define semantics for BPM systems interoperability[END_REF] propose to define the semantics for Business Process Management systems interoperability through the ontology of Electronic Business Documents (EBD) used to interchange the information required to perform cross-organizational processes. Li et al. [START_REF] Li | Process and data fragmentation-oriented enterprise network integration with collaboration modelling and collaboration agents[END_REF] use SOA-based collaborative models and collaborative agents to solve problems with collaborative management for service convergence under the condition of process and data fragmentation. Meyer et al. [START_REF] Meyer | Automating data exchange in process choreographies[END_REF] describe an entirely model-driven approach for BPMN by introducing a few concepts that model data retrieval, data transformation, message exchange, which are the four aspects of data exchange.

First, as shown in Table 1, the research topics all involve modeling or execution, but none of the papers combine both. Second, the research works design the methods from either message or function. Only one work exists that focuses on collaborative networks. Third, the future works can be summarized as follows: concept expansion, process abstraction, research method improvement and process verification.

To summarize, the research work in this paper helps to:

• Fill the gap between the business process and the technical workflow in the research field of IS interoperability by building a bridge from process modeling to workflow execution. • Expand the collaborative concepts from a collaborative network viewpoint, including a Mediator, Partner, and Objective.

• Develop SaaS-based software tools to enhance the software integration capabilities of process modeling.

• The research results presented in the following sections provide the field of management and software engineering with relevant contributions in terms of mediation information system engineering.

Preliminaries

The main framework of the method presented in this article is shown in Fig. 2. This method is entirely based on collaborative ontology (Fig. 3).

The ontology is separated into three parts: the initial condition, function and message, and mediator concepts. The knowledge from the initial condition is gathered using the collaborative network model. The "function and message" portion of this process was derived from the MIT process handbook [START_REF] Malone | Organizing business knowledge: the MIT process handbook[END_REF]. Both steps involve gathering knowledge. The transformation rules were defined to transfer the gathered knowledge to mediator concepts (transferred knowledge). Finally, by using the sum of the knowledge from the collaborative ontology, a model called collaborative process cartography is extracted and presented to the user.

Collaborative ontology -initial condition

From a collaborative business view, a collaborative situation is structured into five parts: the initial conditions; environmental factors; process, structure and governance; contingencies and constraints; and outcomes and accountabilities [START_REF] Bryson | The design and implementation of cross-sector collaborations: propositions from the literature[END_REF]. For the concept definition of the collaborative situation, the most important parts were the initial conditions and the process. According to our experiment with the research projects (ISTA34 , IsyCri5 , and OpenPaas6 for the initial conditions), the key concepts for modeling include the objective, the collaborative network, and the partner. To demonstrate this idea, we assessed the state of art processes in the field of collaborative business and collaborative organization modeling.

As Dormady [START_REF] Dormady | The political economy of collaborative organization[END_REF] mentioned, "organizations and firms in all sectors have long used partnerships, subsidiary corporations, divisions, or departments to adapt to the organizational environment in a manner consistent with the goals and objectives of the organization". Bouslimi et al. [START_REF] Bouslimi | An agent-based organizational model for cooperative information gathering[END_REF] define the collaborative network according to three levels of abstraction: the role model, organizational structures and concrete organizations. Rajsiri et al. [START_REF] Rajsiri | Knowledge-based system for collaborative process specification[END_REF] define the collaborative situation with the following concepts: network, participant, abstract service, topology, role and common goal. Jiang et al. [START_REF] Jiang | A context-aware inter-organizational collaboration model applied to international trade[END_REF] define an inter-organizational collaborative model with only two fundamental concepts: Role and Organization, which consider the role that encompasses a set of objectives.

For the above work, the objective and network are key concepts that are modeled on the same surface, which means that one objective is completed by one network, and thus, one network achieves several objectives. However, from our viewpoint, the relationship between the objective and network is stereoscopic, as shown in Fig. 4. In level 0, all partners are considered as the whole collaborative network. Then, they are defined as the objective of the whole network. In level 1, each objective in level 0 is expanded by a sub-network or by partners within the collaborative objectives. In level 2, the objective is expanded again by a sub-sub network with partners and their own objectives. The whole network is separated into groups (sub-networks) by collaborative objectives. This type of decomposition can continue to level n until the partners are the leaves of the tree.

In the collaborative ontology, the initial condition (Fig. 4) of the collaborative ontology is defined by the network, objective, subnetwork, partner and partner relationship. A network can have several objectives (strategy, operation or support). An objective can be obtained from the sub-network. A sub-network contains several partners. Among the partners, there are partner relationships.

Collaborative ontology -function and message

The very first study to specifically assess the Process Handbook project began in 1991 [START_REF] Malone | Organizing business knowledge: the MIT process handbook[END_REF]. The project has been one of the primary projects of the MIT Center for Coordination Science. According to Bernstein et al. [START_REF] Bernstein | Software tools for a process handbook[END_REF], the project includes: (i) collecting examples of how different organizations perform similar processes and (ii) representing these examples in an on-line "Process Handbook" that includes the relative advantages of the alternatives. To represent the large number of processes, the MIT process handbook ontology is defined. The Process Handbook ontology provides a specialized hierarchy of the processes and their interrelationships in the form of properties. All major parts of the Process Handbook, such as the Process, Bundle, Goal, Exception, Resource, Dependency, and Trade-offs, are represented as OWL classes. Rajsiri [START_REF] Rajsiri | Knowledge-based system for collaborative process specification[END_REF] analyzes the hierarchy of the processes in the ontology of process handbook to build the "function and message" part of the collaborative ontology of MISE 1.0. Here, we re-use her work to build our part of "function and message".

Collaborative ontology -process

This part is completely new for the collaborative ontology. It is different from the collaborative ontology presented in MISE 1.0, and the major difference is the introduction of the Mediator role.

• The Mediator is a participant in the collaboration and is a type of Partner. Both are actors in the collaboration, but the Mediator manages and orchestrates the collaborative process. From the viewpoint of the actors, the Mediator is at the center of all of the Partners. • The Mediator Relationship defines the relationships among the Mediators. These include the objective, feedback and mean messages, which are transferred among different types of collaborative processes. Each collaborative process has one Mediator. Thus, the relationships among the Mediators are classified according to their Order, Feedback and Mean. • The Generated Mediator Function is the function or business service of the Mediator because the Mediator orchestrates the functions of the partners. The functions of the Mediator can be generated from the functions of the partners. Thus, the functions of the Mediator are called Generated Mediator Function.

Transformation rules

The transformation rules of the collaborative ontology are defined in the first-order logic [START_REF] Smullyan | First-order logic[END_REF]. The transformation rules of collaborative ontology are specified in five groups (Table 2). These transformation rules aim to transfer the "initial condition" and "function and message" to "mediator" concepts.

Due to the particularity of the transformation rules, the first-order logic should still be expanded as follows:

• Class: X is instance of a collaborative network → collaborative network(X)

• Association: Y is an instance of an association implement that is between the collaborative network X1 and objective X2 → implement(Y) (collaborative network(X1), objective(X2))

• A set of instances: from X1, X2, X3 to Xn → X1 … Xn
The five groups of transformation rules address the deduction of the mediation concepts. Group 1, 2 and 3 create the Mediator, Mediator Relationship and Generated Mediator Function. Group 4 creates the relation hasGeneratedFunction to link the Mediator with the deduced Generated Mediator Function. Group 5 transfers the Mediator Relationship to the Event. With the Event, group 5 can recognize the Inter Mediator Function from the Generated Mediator Function. ∀Sub Network (X) (∀hasPartner (Sub Network (X)Partner (X 1 ) ∧ (∀hasPartner (Sub Network (X), Partner (X 2 ))∧…∧

(∀hasPartner (Sub Network (X), Partner (X n ))) Rule (1)
-> ∃Mediator (X) ∧∃hasMediator (Sub Network (X), Mediator (X))

Table 4

Group 2: Creating the mediator relationship.

∀Strategy Objective (X 1 ) (∀generates (Strategy Objective (X 1 ), Main Function (X 1 ))) ∧

Rule (2) ∀Operation/Support Objective (X 2 ) (∀generates (Operation/Support Objective (X 2 ), Main Function (X 2 ))) ∀Main Function (X 1 ) (∀out (Main Function(X 1 ), Business Message (m))) ∧ ∀Main Function (X 2 ) (∀in (Main Function(X 2 ), Business Message (m))) -> ∃ Order (m)(hasMediatorRelationship (Mediator (X 1 ), Order (m))) ∧ ∃ Order (m)(hasMediatorRelationship (Mediator (X 2 ), Order (m)))
∀Operation

Group 1: creating the mediator

Group 1 addresses the creation of instances of the Mediator. From a business perspective, the mediator orchestrates the collaborative process. The mediator has an important role in the collaborative network. The mediator manages the collaborative network to achieve the collaborative objective.

If one Sub Network contains several Partners, then for the Sub Network, there is one Mediator to manage the collaboration of the Sub Network (Rule 1, shown in Table 3). This group of transformation rules contains one equation. Table 3 presents rule (1) in extended first-order logic. The rule states that if there is an instance X of Sub Network and X links to several instances of Partner (X 1 , X 2 … X n ) by the relation hasPartner, then there is an instance X of Mediator that links to the instance of Sub Network by the relation hasMediator.

Creating the mediator relationship

This group concerns the deduction of instances of Mediator Relationships by recognizing the in/out of the business message of the main function. From the business perspective, in one collaborative situation, there may be several mediators that manage different collaborative processes and achieve different collaborative objectives. However, among different collaborative processes, there are communications. Mediator Relationships aim to communicate between the mediators.

Group 2 has three rules (rules 2, 3 and 4 in Table 4). In the collaborative ontology, the Mediator Relationship is defined to represent the communications among the collaborative processes. There are three types of Mediator Relationships. First, Order represents the objective information. Feedback represents the feedback information. Mean represents the mean information. ∀Function (X) (∀In (Function (X), Business Message (m))) Rule ( 5) -> ∃ Generated Mediator Function (X) (Out (Generated Mediator Function (X), Business Message (m))) ∧ ∃ Generated Mediator Function (X) (generatedFrom (Function (X), Generated Mediator Function (X))) ∀Function (X) (∀In (Function (X), Business Message (m))) Rule ( 6) -> ∃ Generated Mediator Function (X) (Out (Generated Mediator Function (X), Business Message (m))) ∧ ∃ Generated Mediator Function (X) (generatedFrom (Function (X), Generated Mediator Function (X)))

Table 6

Group 4: Linking the generated mediator function to the mediator.

∀Main Function (X) (∀owns (Main Function (X), Function (X 1 ))) Rule [START_REF] Bryson | The design and implementation of cross-sector collaborations: propositions from the literature[END_REF] -> ∃ Mediator (X) (∀hasGeneratedFunction (Mediator (X), Generated Mediator Function (X 1 )))

Rule ( 2) addresses the deduction of the Order. Rule (3) addresses the deduction of the Feedback. Rule (4) addresses the deduction of the Mean.

Rule (2) starts from the Strategy and Operation Objective. If an instance X 1 of the Main Function is transferred from an instance of the Strategy Objective, if an instance X 2 of the Main Function is transferred from an instance of the Operation Objective, and if an instance m of Business Message exists such that m is the output of X 1 and m is also the input of X 2 , then an instance m of the Order is deduced and the relationship hasMediatorRelationship with Mediator (X 1 ) (this is the instance of Mediator that was generated from the Sub Network to achieve the Main Function (X 1 )) and Mediator (X 2 ) (this is the instance of the Mediator that was generated from the Sub Network to achieve the Main Function (X 2 )) is deduced. Rule [START_REF] Bianchini | Service identification in interorganizational process design[END_REF] creates Order between the Mediators, which are transferred from the Strategy and Support Objective. Rule [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] creates Feedback between the Mediators, which are transferred from the Operation and the Strategy Objective. Rule [START_REF] Bernstein | Software tools for a process handbook[END_REF] creates Feedback between the Mediators, which are transferred from the Operation and Support Objective. Rule (4) creates the Mean between the Mediators, which are transferred from the Support and Strategy Objective. Rule [START_REF] Castela | Collaborative method to maintain business process models updated[END_REF] creates the Mean between the Mediators, which are transferred from the Support and Operation Objective.

Group 3: creating the generated mediator function

The rules in this group are designed to deduce the instances of the Generated Mediator Function and input/output relations. The mediator needs the mediator functions to invoke the partner functions. The input and output messages between the mediator functions and the partner functions must be added.

This group contains two rules (Rules 5 and 6 in Table 5). Rule (5) defines how the Generated Mediator Function and Out relationship are created. Rule (6) defines how the Generated Mediator Function and the In relationship are created.

For rule [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF], if Function (X) has the input Business Message (m), then the Generated Mediator Function (X) and the relationship generatedFrom between Function (X) and Generated Mediator Function (X) are created, and the Generated Mediator Function (X) has the output Business Message (m). For rule [START_REF] Bouslimi | An agent-based organizational model for cooperative information gathering[END_REF], if Function (X) has the output Business Message (m), then the Generated Mediator Function (X) and relationship generatedFrom between Function (X) and Generated Mediator Function (X) are created. The Generated Mediator Function (X) has the input Business Message (m).

Group 4: linking the generated mediator function to mediator

This group is dedicated to deducing the instances of the relation: hasGeneratedFunction between the Generated Mediator Function (already transferred by group 3) and the Mediator. To deduce the collaborative process, we must know that the mediator functions belong to the mediator. The mediator can use its functions to invoke partner functions.

Rule [START_REF] Bryson | The design and implementation of cross-sector collaborations: propositions from the literature[END_REF] in Table 6 defines the deduction method. If Main Function (X) has Function (X 1 ), then the Mediator (X), which manages the Sub Network of Main Function (X), has the Generated Mediator Function (X 1 ), which is generated from Function (X 1 ).

Group 5: creating the inter mediator function

This fifth group concerns the deductions of the instances of the Inter Mediator Function. As explained for group 2, one collaborative situation may have several mediators. There are communications among the mediators. This group helps to identify the specific mediator function, which is communicated with the other mediators. (Table 7)

If the Generated Mediator Function (X) of Mediator (Y) has the Business Message (m) that generates Mediator Relationship (m) of Mediator (Y) by rule (2) of group 2, then the Event (m) is created to achieve the Mediator Relationship (m). The Generated Mediator

Function (X) is also an Inter Mediator Function (X).

If the Business Message (m) is the input message of the Generated Mediator Function (X), then the Event (m) is also the input of the Inter Mediator Function (X). If the Business Message (m) is the output message of the Generated Mediator Function (X), then the Event (m) is also the output of the Inter Mediator Function (X).

Deduction rules

The deduction rules of the collaborative process have been separated into four groups of rules. These four groups of rules are summarized in Table 8.

Part 1: deduction of the process cartography

The deduction of the process cartography demonstrates how the collaborative process cartography is extracted from the collaborative ontology. Fig. 5 shows an example of the deduction of the process of cartography. There are four rules in this part of the deduction.

Part 2: deduction of the collaborative process

Part 2 defines the rules of deduction for the collaborative process. In the process cartography deduced as explained in Part 1, there are main tasks. For each task, there is a collaborative process. Part 2 shows how the sub-collaborative process is transferred. Fig. 6 shows an example of the deduction for the collaborative process. There are three rules in this part of the deduction.

• No.2-1: Main Function → Collaborative process. If there is a Main Function that has been transferred to task in the strategy/operation/support pool, then there is a detailed collaborative process. However, there is a special case if there is a Main Function that has been transferred to a task in the general pool. Then, there is a detailed cartography of the collaborative process, and the deduction goes back to part 1.

Part 3: deduction of the partner pool

Rule No.2-2 identifies the partner pools of the collaborative process. However, there is no task in these pools. Part 3 of the deduction rules is thus dedicated to filling the partner pools with tasks and message flows. Fig. 7 shows an example of the deduction of the tasks. There are two rules in this part of the deduction.

Part 4: deduction of the mediator pool

Rule No.2-3 determines the mediator pool. Part 4 fills the mediator pool with mediator tasks, message flows and events. Fig. 8 shows an example of the deduction of the mediator tasks, message flows and events. There are three rules in this part of the deduction.

• No.4-1: Generated Mediator Function → Task in the mediator pool. This rule transfers all of the functions of the mediator that are defined to achieve the collaborative objective. If the Mediator of the collaborative process has the Generated Mediator Function, then the Generated Mediator Function is transferred to the tasks in the mediator pool.

Results

To support the model definition and model transformation, Mediator modeling 2ool was developed. The developed method is based on SaaS [START_REF] Mäkilä | How to define software-as-a-service -an empirical study of finnish saas providers[END_REF]. The developed tools include GWT 7 , GWT-EXT 8 , Java, PetalsLink Geasy modeling API 9 , PetalsLink Easy BPMN 10and Protégé 11 . The main functions of Mediator modeling 2ool are (i) to define the collaborative network model, (ii) to link the objectives with ontology, (iii) to transfer the defined model to the cartography of the collaborative process and (vi) to update the collaborative ontology. The structure of the software is shown in Fig. 9.

The software has a server side and a client side. Between the server and the client, there are graphic, ontology and process interfaces to manage the communications. On the client side, the "modeling graphic module" is developed by using the PetalsLink Geasy graphic API, which defines the collaborative network model and sends the model to the server side through the "graphic inter". "Graphic<->XML exchanging engine" receives the graphic model through the "graphic inter" and then changes the model to an XML file containing all of the necessary information. The "Collaborative ontology engine" receives the XML file and updates the collaborative ontology. The "Deduction engine" reads the updated collaborative ontology and deduces the cartography of the collaborative processes in .BPM files. The .BPM files are sent to a BPMN modeling tool through the "process inter".

Implementation results

Table 9 shows the knowledge transfer results from the MIT process handbook to the collaborative ontology. We use Protégé to define the collaborative ontology. Jena, a tool inside Protégé, implements the transformation rules, which are defined in Section 4.

Fig. 10 shows the client interface of Mediator Modeling 2ool. It also shows the "Ontology" panel. The "Ontology" panel loads the collaborative ontology from the .owl file through the "Ontology inter" (Fig. 9).

Case study

A case study of the transformation result of the collaborative process cartography was designed for two types of cases: a small case and a complex case.

Collaborative Situation -Collaborative network model

Both cases are based on the same collaborative objectives (Fig. 11): the Strategy objective, which is for the design offer strategy, the Operation objective, which is for the design product, and the General (Operation and support) objective, which sells the product.

Transformation results of the collaborative process cartography

Fig. 12 compares the ideal results and the transformation results: (i) the pools and functions are transformed without mistakes, (ii) the lanes are added automatically with the BPMN tool; and iii) all of the message events are replaced with message flows.

Transformation results of the collaborative process "Design offer strategy" Fig. 13 compares the ideal results and the transformation results: (i) the pools and functions are transformed without mistakes, (ii) the lanes are added automatically because of the BPMN tool, and (iii) the message event at the end of the process is missing due to the BPMN tool. Several Partners are involved in the "Design offer strategy" Fig. 14 shows the transformation results for a complex case with several partners involved.

Evaluation

Castela et al. [START_REF] Castela | Collaborative method to maintain business process models updated[END_REF] analyze their collaborative business process by developing case studies and calculating the numbers and percentages of the key elements, e.g., the number of processes, the number of annotated processes, and the percentage of annotated processes. Based on the numbers calculated, they completed an analysis with different functional or non-functional requirements. However, the requirements are defined when the maintenance of a collaborative business process does not fit our needs. Another paper [START_REF] Ter Hofstede | Business process management: a survey[END_REF] presents non-functional requirements: modifiability, integrality, interoperability, security, automation, flexibility, and usability. Because the cartography of the collaborative process is deduced by a computer and is not defined by humans, the modifiability is deleted. The final goal of the cartography of the collaborative process is to address any interoperability problems in the information systems; for this reason, we selected interoperability and removed integrality. In addition, no security problem was involved, and the security requirement was deleted. The flexibility is managed through the run time rather than the design time of the collaborative process (ongoing MISE 3.0), so we replaced the flexibility with complexity. Finally, we chose interoperability, automation, complexity and usability as the factors for evaluation.

Three cases were built to calculate the number of functions, message flows, sequence flows, gateways and events. "No mediator" means that the collaborative process goes from one partner to another, without any mediator to manage the process. The "Simple case" means that there is a mediator but only a simple mathematic calculation. For example, one partner function is invoked by one mediator function, and the number of partner functions and mediator functions should be equal. If we consider only the mathematics, the number of total functions is simply doubled. The "Complex case" is the real result of the deduction method presented in this paper.

As shown in Fig. 15, the number of functions can be calculated for the three cases. For the "complex case", by the increase in partners, the number of functions can be decreased and is infinitely close to the "no mediator" case. The cartography of the collaborative process shows the strong advantage of addressing a complex collaborative situation. The reasons for this are as follows (i) the cartography separates the collaborative process by sub-processes, (ii) the "Mediator" combines the same partners' functions as one invoking function (for example, the "Invoke Manage offering life cycle" function in Fig. 14), and (iii) the "Mediator" provides one function to merge message flows from different partners and help in decision-making (for example, the "Merge information" function with the "Mediator" tag in Fig. 14). We can trace back to the collaborative process modeling because we consider the workflow changeable in the design phase.

The left part of Fig. 16 shows the number of message flows for the three cases. Compared to the "no mediator" and "simple case", the degree of change for the "complex case" decreases slightly when the number of partners is two or four. This keeps the same degree of change as the other two when there are more than six partners. This shows that the cartography of the collaborative process does not strongly influence the number of message flows. The reason is that only the message-flow merging functions can affect the number of message flows. However, the merging functions are set up when the number of partners is low. These do not change as the number of partners increase. The right part of Fig. 16 shows the number of sequence flows. The degree of change for the "complex case" shows the opposite pattern as the number of message flows. The "Mediator" combines the same functions of partners into one invoking function. For the simple case, more partners lead to more sequence flows. For the complex case, with the invoking function, more partners lead to more sequence flows being saved. With the merging and invoking functions, the complexity of the collaborative process decreases.

Fig. 17 shows the number of events and gateways. On the left, the number of events is noticeably decreasing. In the "no mediator" case, one pool needs at least one start event, one end event and several intermediate events. For the "complex case" and the "simple case", only the mediator pool has one start event, one end event and several intermediate events. On the right, the number of gateways for the "complex case" and the "simple case" are less than those for the "no mediator" case. The reason is that only the mediator pool has gateways. However, for the "complex case", this keeps increasing. For the "simple case", it stays at the same level. This is because more gateways are needed to manage the invoking function compared to the "simple case". Fig. 18 shows the analysis results with no mediator using the MISE 1.0 deducing method and the MISE 2.0 deducing method (this paper). To summarize: • The methodology considers the workflow changeable to fill the gap between the business process and the technical workflow.

It also leads to an unanticipated result: the decreasing complexity of the collaborative process. • This methodology considers the software to be integrated. All of the transformations are implemented by the software tool.

The tool leaves the ontology interface and the modeling interface. They help in the expansion of additional concepts and workflow transformation.

Comparison

Collaborative process modeling is a specific domain of business process modeling. To complete the comparison section, we did a survey on business process modeling to search for comparison elements.

Haddar et al. [START_REF] Haddar | Literature review of reuse in business process modeling[END_REF] compare business processes by domain dependency, covered business process perspectives, business specificities, modeling language and modeling context. Because all papers mentioned in this paper are general methods or approaches, domain dependency and business specificities are removed from the list.

In Haddar et al. [START_REF] Haddar | Literature review of reuse in business process modeling[END_REF], the covered business process perspectives are functional, behavioral, informational and organizational perspectives. de Oca et al. [START_REF] De Oca | A systematic literature review of studies on business process modeling quality[END_REF] mentioned that "business process models are required as a basis for knowledge transfer between internal and external collaborative partners and documentation in general. It allows us capture the organizational dimension in terms of actors, activities and workflows." We combine these two viewpoints and replace the covered business process perspectives with knowledge modeled. Considering the Specific characteristics of the collaborative process, the knowledge modeled is classified as network (both actor and organizational perspective), objective (both actor and behavioral perspective), function (both activities and functional perspective), message (informational perspective), and process (workflow).

The modeling language is an important element to compare. Kocbek et al. [START_REF] Kocbek | Business process model and notation: the current state of affairs[END_REF] say that "Choosing an appropriate language requires consideration because every modeling language is not suitable for all aspects of the process. This created the necessity for a standardization of modeling languages, which should satisfy the requirements of a high level of expressiveness and formality."

In the work of Haddar et al. [START_REF] Haddar | Literature review of reuse in business process modeling[END_REF], the modeling context means whether the artifact type is used in a design or redesign context in a collaborative way. Because all related works are collaborative business process modeling, the modeling context is removed.

As shown in • Advantages: (i) the research topic is specific and focused; and ii) the patterns of function or message are deeply analyzed and well developed. • Disadvantages: (i) the network and objective knowledge is not or is slightly modeled; (ii) their result is one collaborative process on an operational level, which is hard to understand and difficult to transfer to BPEL (Business Process Execution Language) [START_REF] Ouyang | From BPMN process models to BPEL web services[END_REF][START_REF] White | Using BPMN to model a BPEL process[END_REF]. • For paper nos. 6 and 7, their common points are: (i) main modeled knowledge is function and message; and (ii) the supporting tool is well developed. Compare to Paper No. 15: • Advantages: (i) the research topic is specific and focused; (ii) the patterns of function and message are deeply analyzed and well developed; and (iii) the deduction of the collaborative process is automatic and executable. • Disadvantages: (i) the network and objective knowledge are not modeled; ii) their result is one collaborative process on an operational level, which is hard to understand.

For paper nos. 8, 9 and 12, their common points are: (i) nearly every modeling element is involved; and (ii) the knowledge modeled is additional semantic notation or classification tag. Compare to Paper No. 15:

• Advantages: (i) the modeling method can be combined with other methods to enrich collaborative knowledge and increase the automation of process deduction. • Disadvantages: (i) the modeling of function and message is too simple; without combination with the other method, the result is not notable; and ii) their result is a UML based collaborative process and is hard to read.

For paper nos. 11, 13 and 14, their common points are: (i) two of the modeling elements are well modeled and related; and (ii) the sub-processes are considered. Compare to Paper No. 15:

• Advantages: (i) by collecting the relations between two key elements, the deduced collaborative process is separated into sub-processes. • Disadvantages: (i) their result is a collaborative process and sub-processes on the operational level; no strategy and support are involved.

To summarize, Fig. 19. shows all related works that are located in a coordinate system with axes Automation and Knowledge. Compared to Paper nos.1-5 and 10, the detailed modeling of function or message in this paper (Paper No. 15) is not specific enough. This work may be improved by merging the methodologies presented in nos. 8, 9 and 12 to enrich collaborative knowledge. However, it collects almost all types of knowledge in a collaborative situation. It deduces a cartography of collaborative processes, which classify the collaborative processes into strategy, operation and support and separates the collaborative process into sub-processes. This paper shows higher automation than paper nos. 11, 13, and 14; the results are more readable and less complex than paper nos. 6 and 7.

Conclusion

In a collaborative situation, all partners have both collaborative objectives and individual objectives to achieve and business services to share. They expect to combine their own business services with suitable services from other partners to work toward their common objectives. In addition, the collaborative business process is a combination of business functions, which are interlinked and filled with sequences and orders. With these needs, the selection of the business service, which is objective-oriented, and the creation of the business process are absolutely essential in the collaboration world. Considering the self-updating and re-building of the collaborative business process, we have designed an automatic way to address service selection and process creation at the design level. Furthermore, from the implementation viewpoint, the supporting software tool first addresses a collaborative situation, such that all of the partners may use the software at the same time or individually. Additionally, to interact with the other software tools, the software should be invoked. The results of this paper are reused by Boissel-Dallier et al. [START_REF] Boissel-Dallier | Mediation information system engineering based on hybrid service composition mechanism[END_REF] as an input model. They transfer the collaborative process into an executable collaborative workflow by using semantic web ontologies.

The future works are as follows:

• Characterization with the real-time detection of events; for the whole design-time and run-time, the events can be detected and handled immediately. • Performance indicator deduction: The indicators measure the performances of the business function and web services. For each collaborative function or web service, the indicator is added to the measure; for example, the launching time, the responding time, and the correction of the output message. • Workflow monitoring: From both a functional and non-functional view, the user could observe the step in which the workflow is being executed. • Cloud deploying: All MISE tools and the deployed MIS tools are integrated into the cloud platform. The MISE tools can be uploaded to the cloud in a PaaS (Platform as a Service) as a SaaS. • Detection by performance monitoring: Using indicators of performance, the detection of agility management can be improved. The indicators can directly launch the detection by identifying the feedback of performance. • Decision-making transition: For each step of the model transformation, a decision-making mechanism is added. This module suggests the best solution for the choice of functions, processes, and web services.

Fig. 1 .

 1 Fig. 1. An example of collaborative process cartography.

Fig. 2 .

 2 Fig. 2. Knowledge in/out of collaborative ontology.

Fig. 3 .

 3 Fig. 3. Collaborative ontology of MISE 2.0.

Fig. 4 .

 4 Fig. 4. Our vision of the collaborative networks and objectives.

  Objective (X1) (∀generates (Operation Objective(X1), Main Function(X1))) ∧ Rule (3) ∀Strategy/Support Objective (X2) (∀generates (Strategy/Support Objective(X2), Main Function(X2))) ∀Main Function (X1) (∀out (Main Function(X1), Business Message (m))) ∧ ∀Main Function (X2) (∀in (Main Function(X2), Business Message (m))) -> ∃ Feedback (m)(hasMediatorRelationship (Mediator (X1), Feedback (m))) ∧ ∃ Feedback (m)(hasMediatorRelationship (Mediator (X2), Feedback (m))) ∀Support Objective (X1) (∀generates (Support Objective(X1), Main Function(X1))) ∧ Rule (4) ∀Strategy/Operation Objective (X2) (∀generates (Strategy/Operation Objective(X2), Main Function(X2))) ∀Main Function (X1) (∀out (Main Function(X1), Business Message (m))) ∧ ∀Main Function (X2) (∀in (Main Function(X2), Business Message (m))) -> ∃Mean (m)(hasMediatorRelationship (Mediator (X1), Mean (m))) ∧ ∃ Mean (m)(hasMediatorRelationship (Mediator (X2), Mean (m)))

∀GeneratedFig. 5 .

 5 Fig. 5. Deduction of the collaborative process cartography.

• No. 1 - 1 :

 11 Network/Sub Network → Collaborative process cartography. If the Network or Sub Network has collaborative objectives, then a correspondence collaborative cartography exists for the Network or Sub Network. • No.1-2: Objective → Strategy/Operation/Support/General pool. Based on rule No.1-1, rule No.1-2 fills the collaborative process cartography with different types of pools (strategy, operation, support and general). If the Network has a strategy objective, then there is one strategy pool. If the Network has an operation objective, then there is one operation pool. If the Network has a support objective, then there is one support pool. If the Network has an objective, then there is one general pool. • No.1-3: Main Function → Task • No.1-4: Business Message → Message flow

Fig. 6 .

 6 Fig. 6. Deduction of the collaborative process.

Fig. 7 .

 7 Fig. 7. Deduction of the partner pool.

  • No.2-2: Partner → Partner pool. Based on rule No.2-1, rule No.2-2 fills the collaborative process with partner pools. If the Main Function is generated from one Objective, which is achieved by Sub Network, the Partners of the Sub Network are transferred as partner pools in the collaborative process. • No.2-3: Mediator → Mediator pool. If the Sub Network has one Mediator, then the Mediator is transferred into the mediator pool in the collaborative process.

•

  No.3-1: Function → The task in the partner pool. If there is one Function that is shared by one Partner, then the Function is transferred to the task of the partner pool. • No.3-2: Business Message → Message flow. Based on rule No.3-1, rule No.3-2 adds message flows to the tasks. If one Function has the input/output Business Message, then the Business Message is transferred to the input/output message flows of the task, which is then transferred from the Function.

Fig. 8 .

 8 Fig. 8. Deduction of the mediator pool.

Fig. 9 .

 9 Fig. 9. Structure of the supporting tools.

Fig. 10 .

 10 Fig. 10. Main interface (file and ontology).

Fig. 11 .

 11 Fig. 11. Collaborative network model.

Fig. 12 .

 12 Fig. 12. Ideal results and transformation results of the process cartography.

Fig. 13 .

 13 Fig. 13. Ideal results and transformation results of the collaborative process.

Fig. 14 .

 14 Fig. 14. Results of a complex case.

Fig. 15 .

 15 Fig. 15. Number of functions.

Fig. 16 .

 16 Fig. 16. Number of message flows and sequence flows.

Fig. 17 .

 17 Fig. 17. Numbers of events and gateways.

Fig. 18 .

 18 Fig. 18. analysis results.

Note 1 :

 1 N = network, O = objective, F = function, M = message, P = process Note 2: √ = with tool support, √√ = well developed, √√√ = full automation Note 3: √ = mentioned, √√ = modeled, √√√ = modeled well Note 4: Ex = Extension

Fig. 19 .

 19 Fig. 19. Summary of comparison.

Table 1

 1 Summaries of related works.

	Reference	Topic	Focus	Methods	Tool		Future work
	Comuzzi et al. [9]	E	F *	Ant-colony optimization	ProM 5.2	Extend the type of monitoring
							functions
	Antonia et al. [1]	M *	F *	Ontology * First order logic *	Protégé * , COCOS	Expand ontology with agent
	Bae et al. [2]	E	F *	Genetic algorithm	-		Develop hybrid genetic algorithms
	Nie et al. [32]	M *	M	Behavior mismatch patterns	BPMN *	Message semantics
	Bianchinii et al. [4]	M *	F *	Service identification metrics	BPMN	*	Business process abstraction
	Norta et al. [33]	M *	M	E -s o u r c i n gr e f e r e n c ea r c h i t e c t u r e	E x t e r n a l -i n t e r n a lm o d e l i n g *	Collaboration concepts of trust
							management
	Hoisl et al. [2014]	E	M	E n f o r c i n gs e c u r eo b j e c tfl o w s ,M D A *	SoaML, BPMN * , UML	Extend business activities
							framework
	Liptchinsky et al. [24]	M *	N *	Context dependency First order	Petri net	Extend with the notion of group
				logic *
	Yongchareon et al. [45]	M *	F *	Artifact-centric meta-model	Petri net	Web services specification and
							abstraction
	Zeng et al. [46]	M *	F *	RM_WF_NET modeling,	Petri net	Verification of the entire
				cross-department coordination			cross-department medical
				patterns			process
	Cortes-Cornax et al. [10]	M *	F *	Intentional fragments	BPMN *	Develop automated support for
							verifying completeness
	Rico et al. [40]	M *	F *	Method for ontology learning	Ontology of Electronic	-
				techniques	Business Documents *
	Li et al. [25]	E	F * , N *	Collaboration agents	ENI-P		Multi-cloud integration
	Meyer et al. [28]	M *	M	B P M Na n dm o d e l -d r i v e nd a t a	BPMN and UML based data	Formal verification technique in
				dependency enactment approach	model	process orchestrations and
							choreographies
	Topic E: execution, M: modelling.

Focus F: function, M: message, N: network. * related or similar part to this paper.

  • The Inter Mediator Function is a special type of Generated Mediator Function. If one Generated Mediator Function sends or receives Objective, Feedback or Mean messages, the Generated Mediator Function is an Inter Mediator Function. • The Event respects the Mediator Relationship. If the Mediator Relationship is in the abstract level of ontology, then the Event is in the concrete level of the ontology.

Table 2

 2 Transformation rules.

	Group no.	Group name	Description	Rule	Total No.
	1	Create Mediator	Deduce Mediator from Sub Network	(1)	1
	2	Create Mediator Relationship	Deduce Mediator Relationship through Sub Network, Objective,	(2), (3) and (4)	3
			Main Function and Business Messages
	3	Create generated Mediator Function	Deduce Generated Mediator Function and In/out relation	(5) and (6)	2
			through Function
	4	L ink generated Mediator Function to mediator	Deduce the relation: hasGeneratedFunction through Mediator,	(7)	1
			Objective, Main Function and Function. This group is based
			on the following relation: owns exists.
	5	Create inter Mediator Function	Deduce Event from Mediator Relationship, Separate Inter	(8)	1
			Mediator Function from Generated Mediator Function and
			link it to Event

Table 3

 3 Group 1: creating the mediator.

Table 5

 5 Group 3: Creating the generated mediator function.

Table 7

 7 Group 5: creating the inter mediator function.

Table 9

 9 Results of the knowledge filling from the MIT process handbook. Event → Start/Intermediate/End message event. If there is one Event that is the input or output of one Inter Mediator Function, then that Event is transferred to the start/intermediate/end message event before or after the task, which is then transferred from the Inter Mediator Function.

	Concepts of MIT PH	Instances	Concepts of collaborative ontology	Instances
	Cartography	9	O b j e c t i v e	131
	Function	195	Function	195
	Message	75	Message	75
			Main function	156
			Generated mediator function	195
			Inter mediator function	124
			Event	34
	Total	279	Total	910

• No.4-2: Business Message → Message flow. Based on rule No.4-1, rule No.4-2 adds the message flows to the mediator functions. If one Business Message is the input/output of the Generated Mediator Function, then the Business Message is transferred to the input/output message flow of the mediator task, which is transferred from the Generated Mediator Function. • No.4-3:

Table 10 ,

 10 all related works mentioned in Section 2 (No. 1 to No. 14 in Table10) are analyzed and compared with this paper (No. 15 in Table10) by driving method, tool support, modeling language and knowledge involved. The knowledge involved is classified as network, objective, function, message, and process.For paper nos. 1-5 and 10, their common points are as follows: (i) main modeled knowledge is function or message; ii) the supporting tool is medium automatic. Compare to Paper No. 15:

	√	√	√	√

https://research.linagora.com/display/ista3/ISTA3+Overview.

http://www.irit.fr/isycri/eng/.

http://www.open-paas.org/.

http://www.gwtproject.org/.

http://gwt-ext.com/.

https://research.linagora.com/display/geasytools/GEasyTools+Overview.

http://bpmneditor.petalslink.com/.

http://protege.stanford.edu/.

Acknowledgment

This study was supported by the Acteur de l'innovation par la recherche partenariale (ARMINES), National Natural Science Foundation of China (51278030), National Higher-education Institution General Research and Development Funding of China (B15JB00340), and the Scientific Research Foundation for the Returned Overseas Chinese Scholars, State Education Ministry of China (B15C300020).