Mariane El Kassis

François Trousset

Gregory Zacharewicz

Nicolas Daclin

INCREMENTAL TRANSFORMATION OF BPSIM-ENRICHED BPMN MODELS INTO DEVS

This paper introduces a novel methodology for business process simulation, focusing on the incremental transformation of Business Process Modeling and Notation (BPMN) models enriched with Business Process Simulation Interchange Standard (BPSIM) elements into the Discrete Event System Specification (DEVS) formalism. The proposed method enhances the precision and consistency of simulations by systematically converting BPMN components and BPSIM characteristics into DEVS representations, using adaptable rules and templates. A major contribution of this work is the introduction of the Interaction Intermediate Model (I2M), a model that provides a visually lucid representation with significant semantics, effectively encapsulating BPMN and BPSIM simulation aspects. The resulting DEVS model ensures accurate, reliable, and interoperable simulations. We provide a thorough analysis of this methodology, emphasize its advantages, and validate its efficiency through a case study. This method, applicable across various sectors, equips stakeholders with the ability to make informed decisions based on accurate simulation insights, effectively bridging the gap between conceptual modeling and simulation methodologies.

INTRODUCTION

Business Processes (BPs) are a sequence of interrelated actions performed by different organizational components to achieve objectives and build workflow [START_REF] Omg | Business Process Model and Notation[END_REF]. They form the cornerstone of any organization, providing the structure and guidance necessary for efficient and effective task execution. By improving and optimizing BPs, business process management helps companies achieve their goals and provide value to stakeholders.

Continuous development and optimization of these processes are vital in today's rapidly evolving and unpredictable business landscape. Modeling and simulation (M&S) have emerged as potent instruments for examining and enhancing business processes. Simulations enable testing diverse scenarios and strategies without disrupting the actual process, fostering informed decision-making. The application of M&S to business processes has gained traction in the context of digital transformation and Industry 4.0 [START_REF] Steiner | Industry 4.0 and Business Process Management[END_REF], and across industries such as aeronautics, manufacturing, healthcare, banking, and logistics [START_REF] Jahangirian | Simulation in Manufacturing and Business: A Review[END_REF].

In this paper, we present an innovative methodology for simulating business processes using a two-stage transformation process. Specifically, we propose to use the BPMN 2.0 (Business Process Modeling and Notation) model enriched with BPSIM 2.0 (Business Process Simulation Interchange Standard) to capture essential simulation elements, and transform it into the DEVS (Discrete Event System Specification) model. We demonstrate the effectiveness of our methodology by presenting detailed examples.

The remainder of this paper is organized as follows: Section 1 provides an introduction and the motivation for our research. Section 2 presents an overview of the current state of business process simulation, including the standardization efforts in this field and the integration challenges of business process modeling and simulation. In Section 3, we introduce our novel methodology for business process simulation, which includes a two-stage transformation process and the Interaction Intermediate Model (I2M). Section 4 illustrates the practical application of our approach with a detailed case study. Finally, in Section 5, we conclude the paper by discussing prospective future research directions and summarizing the significant contributions of our research.

STATE OF THE ART

Background

Business process simulation plays an indispensable role in understanding complex system dynamics and identifying areas that require improvement. A crucial aspect of this process is conceptual modeling, which translates real-world complexities or systems into abstract, comprehensible representations, preparing them for thorough exploration through simulation studies [START_REF] Robinson | Conceptual Modeling for Discrete-Event Simulation[END_REF]. In particular, Discrete Event Simulation (DES) applies conceptual modeling as a comprehensive and intelligible tool to represent discrete events.

The standardization of business processes plays a crucial role in enhancing their understandability and manageability. Various business process management tools aim to achieve this objective by harmonizing graphical notation and software [START_REF] Mens | A Taxonomy of Model Transformation[END_REF]. However, these technologies often have limitations in their simulation capabilities. Many free and open-source business process management software only offer partial support for model simulation [START_REF] Pufahl | Design of an Extensible BPMN Process Simulator[END_REF], and the integration of modeling and simulation elements remains deficient. This gap requires model extensions to incorporate essential simulation elements such as scenario parameters, resources, and time. Consequently, effective utilization of these tools becomes limited to individuals with profound simulation expertise.

After simulation, analysts can scrutinize the results, identify areas of interest, and strategize for process improvement. Despite the potential advantages of this process, the current state of simulation technologies presents challenges in seamlessly integrating business process modeling and simulation. This scenario emphasizes the urgent need for further exploration and advancements in this field.

BPMN and its Extension

The Business Process Model and Notation (BPMN) provides a comprehensive platform for specifying business processes (OMG 2013). However, in its standard format, certain simulation-specific details of a business domain might not be captured entirely. This observation has led to the development of various simulation-oriented extensions that aim to enhance the BPMN's modeling capabilities. These extensions cater to different facets such as temporal dynamics [START_REF] Gagne | Time-BPMN[END_REF], interoperability [START_REF] Mallek | The Application of Interoperability Requirement Specification and Verification to Collaborative Processes in Industry[END_REF], resource performance [START_REF] Lodhi | An Extension of BPMN Meta-model for Evaluation of Business Processes[END_REF] [START_REF] Bocciarelli | A BPMN Extension for Modeling Non-Functional Properties of Business Processes[END_REF], as well as constraints on resource allocation [START_REF] Awad | Enabling Resource Assignment Constraints in BPMN[END_REF]) and time [START_REF] Cheikhrouhou | Toward a Time-Centric Modeling of Business Processes in BPMN 2.0[END_REF][START_REF] Pichler | Modelling Processes with Time-Dependent Control Structures[END_REF].

In particular, the Workflow Management Coalition (WFMC) has introduced the Business Process Simulation (BPSIM) specification as a standard extension. BPSIM brings a wide array of parameters to the table, which serve as additional elements for enriching a BPMN model before the simulation process.

This study utilizes BPSIM framework to extend BPMN, thereby enabling the models to incorporate additional attributes pertinent to simulation, such as time parameters, cost parameters, resource parameters, and priority parameters. The integration of BPMN and BPSIM thus equips the models with a more detailed representation of the business processes, enhancing their applicability in identifying bottlenecks, optimizing resources, and facilitating more informed decision-making processes.

El Kassis,Trousset,Zacharewicz,and Daclin 2.3 BPSIM BPSIM 2.0 specification, a comprehensive open-source framework, serves as a bridge to integrate BPSIM semantics and properties into BPMN models. This framework is the foundation of the methodology presented in this study. Our objective is to enrich BPMN elements with pertinent parameters and logic sourced from BPSIM, thereby enhancing the conceptual model's intricacy and expressiveness.

BPSIM parameters are chiefly classified into five categories (WFMC 2016):

• Time Parameters: These delineate time intervals as perceived from an external viewpoint. These parameters can influence the scheduling and execution of BPMN events and tasks, and are essential for representing temporal dynamics in the process model. • Control Parameters: These specify the resources utilized by a business process element. Control parameters are crucial for modeling resource constraints and allocation policies, which can significantly impact process performance and outcomes. • Cost Parameters: These encapsulate all costs affiliated with an activity, whether they involve human or non-human resources. This allows for the comprehensive economic analysis of business processes. • Property Parameters: These designate simulation values for data instances utilized by the business process, thereby enabling the modeling of data-driven behaviors and dependencies. • Priority Parameters: These regulate the priority of the associated BPMN element, influencing the order of execution when resources are scarce or tasks are competing for execution.

The BPSIM 2.0 specification by the Workflow Management Coalition (WFMC 2016) explicitly outlines which BPSIM parameter can be associated with each BPMN element. Consequently, BPSIM enhances BPMN by introducing a variety of capabilities such as probabilistic distribution, concurrent simulations, task-specific resource allocation, probabilistic duration, conditional results probabilities, resource priorities, and calendar availability, among others.

BPMN Transformation

The simulation of a business process model typically involves a two-step process: the enrichment of the model with pertinent simulation parameters, followed by its transformation into a low-level simulation model [START_REF] Wagner | Tutorial: Information and Process Modeling for Simulation[END_REF].

Model-Driven Engineering (MDE) is an approach to software engineering that emphasizes the use of models at various levels of abstraction, thereby shifting the development focus from coding to modeling. MDE hinges on two primary principles: model usage and model transformation. The concept of model transformation includes elements such as mappings and transformation rules, while the model usage principle is centered around concepts like meta-models and conformity [START_REF] Mens | A Taxonomy of Model Transformation[END_REF].

The subject of BPMN simulation has been an area of active research, with several researchers exploring the transformation of BPMN models into low-level simulation models.

Among these investigations, several researchers have applied DEVS (Discrete Event System Specification) to the simulation of BPMN models [START_REF] Cetinkaya | MDD4MS: A Model Driven Development Framework for Modeling and Simulation[END_REF][START_REF] Bocciarelli | A BPMN Extension for Modeling Non-Functional Properties of Business Processes[END_REF][START_REF] Bazoun | Business Process Simulation: Transformation of BPMN 2.0 to DEVS Models[END_REF][START_REF] Boukelkoul | Optimal model transformation of BPMN to DEVS[END_REF]. DEVS is a well-structured formalism for discrete event modeling and simulation, offering a hierarchical and modular approach, which enhances the comprehensibility and maintainability of models [START_REF] Zeigler | Theory of Modeling and Simulation[END_REF].

On the other hand, Petri nets have also been extensively used for the simulation of BPMN models [START_REF] Dijkman | Formal Semantics and Analysis of BPMN Process Models Using Petri Nets[END_REF][START_REF] Ou-Yang | BPMN-based business process model feasibility analysis: a petri net approach[END_REF]. Petri nets are a popular mathematical modeling tool that is particularly useful for the description and analysis of systems that are characterized by concurrency, synchronization, and resource sharing.

In the state of the art, both DEVS and Petri Nets have been used for the simulation of BPMN models. DEVS is appreciated for its expressiveness, modularity, support for hierarchical modeling, and simplicity, El Kassis, Trousset, Zacharewicz, and Daclin and is widely supported by various simulation tools. On the other hand, Petri Nets, while also a powerful tool, lack certain features such as modularity and hierarchical modeling.

METHODOLOGY

In this paper, we present an innovative methodology for simulating business processes, aiming to bridge the gap in simulation expertise and empower BPMN end-users to make informed decisions based on accurate representations of their processes. Our methodology leverages BPMN and BPSIM, industry-accepted standards for modeling and simulating business processes. BPMN provides a universally understood language that effectively models our processes, while BPSIM's specific features facilitate meaningful simulation. For our simulation model, we have chosen DEVS due to its hierarchical and modular nature, making it suitable for modeling complex systems.

The advantages of DEVS lie in its ability to capture system dynamics effectively. Additionally, DEVS is widely implemented across various simulation tools, enhancing its practicality for simulating business processes. In the practical implementation of DEVS, we have selected DEVS-Suite as our simulator, influenced by its prior application in model-driven engineering research [START_REF] Sarjoughian | EMF-DEVS modeling[END_REF]. DEVS-Suite's suitability aligns with our methodology, ensuring a seamless integration of DEVSbased simulation.

To address the oversight of simulation parameters and interaction in previous works, we propose the Intermediate Interaction Model (I2M). This separate modeling approach enables explicit modeling of interactions and ensures comprehensive transformation rules. Our methodology prioritizes incrementality, flexibility, and accuracy, allowing modifications to transformation rules at any stage while accurately representing crucial aspects in simulation. The I2M serves as a comprehensive solution that empowers users to bridge the gap in simulation expertise, enabling them to understand and review simulation results and make informed decisions based on accurate representations of their business processes.

Intermediate Interaction Model (I2M)

In our endeavor to convert a BPMN-based business process enriched with BPSIM into DEVS, we conducted a comprehensive exploration of potential combinations. Our objective was to identify and implement necessary transformations while preserving vital functionalities. However, the extensive range of allowed combinations between BPMN and BPSIM posed a significant challenge. To address this, we developed the Intermediate Interaction Model (I2M), which consists of two types of elements: I2M simple elements and I2M composite elements. The I2M model serves as a bridge, simplifying the transformation process and allowing for an intuitive representation of simulation functionalities.

The I2M simple elements are derived from an in-depth analysis of BPMN and BPSIM, encapsulating essential simulation functionalities and presented in a BPMN-like manner. For instance, time-related elements in BPMN and BPSIM are represented as I2M timers, visually resembling BPMN timers but with enhanced semantics adapted to our needs. Notably, while I2M elements bear visual similarities to BPMN components, their functionality is adapted, and they can interact in ways that BPMN elements cannot. For example, an I2M timer can be connected to another element with a message flow, an operation not possible with BPMN timers. To visually distinguish I2M elements from BPMN components, we have given them a blue border. This demarcation underscores the distinctive role and operation of I2M elements within our methodology, emphasizing their unique semantics while maintaining a familiar visual form.

However, certain elements in BPMN and BPSIM encompassed multiple simulation functionalities of interest. To accommodate these complexities, we introduced I2M composite elements. An I2M composite element represents an assembly composed of interconnected I2M simple elements. These connections are governed by a pre-established Generic Interaction Model (GIM), configured by an I2M engineer. This composition embodies a higher level of abstraction, facilitating the simulation of complex systems by orchestrating simpler elements in a structured and organized fashion. This differentiation between a list of intermediate interaction elements and the interconnected equivalent model enabled us to create a streamlined transformation to DEVS. Our approach followed an incremental methodology that empowered users to define the interconnections between the simple elements based on their simulation requirements. By adopting this approach, we successfully shifted the complexity away from the implementation in DEVS, simplifying the overall transformation process.

By introducing the I2M model, we have effectively separated functionality from interaction, greatly simplifying the transformation to DEVS. This separation means that the complexity of the process is now primarily focused on the coupling of these elements, rather than on the implementation of complex DEVS models themselves. Consequently, the translation into DEVS is facilitated, as we are primarily dealing with simple I2M elements whose interaction patterns dictate the structure of the DEVS models. Thus, the intricacy is now centered on how these elements are interconnected, which is a far more manageable challenge.

Our methodology revolves around the use of an Intermediate Interaction Model as a bridge between BPMN+BPSIM and DEVS. The I2M serves as a transitional space, capturing every element from the BPMN+BPSIM model and providing an equivalent representation that mirrors the structure of BPMN while centralizing interactions. A key aspect of our methodology is the Generic Interaction Model (GIM), which comprehensively illustrates potential interactions between I2M elements. Incremental development and adaptability are emphasized, enabling enhancement of the method without extensive code modifications.

I2M Simple and Composite

The metamodel for the I2M is a critical component of our methodology, providing a structured representation of the I2M. It bears a resemblance to the BPMN model, both being visual representations with meaningful semantics. However, the I2M goes a step further by effectively illustrating BPSIM simulation aspects, making the simulation process and its impact on the overall model easier to comprehend. Our metamodel consists of two main elements: the simple I2M elements and the composite elements, which may include simple and composite I2M elements.

Simple I2M Elements: These elements represent individual functionalities, which could correspond to a BPMN or BPSIM element and which are important for the simulation. The simple I2M elements include i2m:Start(), i2m:Stop(), i2m:Timer(), i2m:Send(), i2m:Receive(), i2m:Container(), i2m:MessageFlow(), i2m:SequenceFlow(), i2m:Pool(), i2m:Join(), I2M:Task(). To reflect resource allocation, we have also defined i2m:Broker(), i2m:Allocate(), and i2m:UnAllocate(). To express stochastic behavior, we have created the i2m:RandomNumberGenerator().

Composite I2M Elements: A composite I2M element is a set of simple I2M elements interconnected by preconfigured rules. This set of I2M elements is housed within an i2m:Container() element. The final transformation of these composite elements will follow a simplification rule based on the I2M elements contained in the set according to the GIM associated with these composite elements.

Transformation

Inspired by Model Driven Architecture (MDA), we propose in Figure 1 a transformation methodology facilitated by an Intermediate Interaction Model (I2M).

The first step in our approach involves a model-to-model transformation where we transform BPMN+BPSIM model into the I2M model. This transformation is executed using the Atlas Transformation Language (ATL), a tool that allows us to describe complex transformations in a maintainable, readable, and declarative way [START_REF] Jouault | ATL: A model transformation tool[END_REF].

I2M plays the role of a pivot in our methodology, serving as a bridge model that captures all essential interaction aspects. It acts as a common intermediary, enabling a smooth transformation process from BPMN+BPSIM to DEVS. Once the BPMN+BPSIM model is transformed into the I2M, the subsequent transformation step involves the conversion of the I2M into a DEVS model which is carried out using Model to Model transformation. Finally, DEVS-Suite code is generated using Model to Text (JAVA Code) transformation similar to the one performed in [START_REF] Robati | Simulation-Based Verification of Avionic Systems Deployed on IMA Architectures[END_REF]. The generated code can then be executed in the DEVS-Suite simulator [START_REF] Sarjoughian | EMF-DEVS modeling[END_REF]. This final step completes the transformation process, allowing for the study of the behavior and performance of the business process expressed in BPMN+BPSIM. By adhering to this methodology, we provide an efficient and flexible approach to transforming BPMN models, enriched with BPSIM parameters, into a simulation-ready format. This approach is advantageous not only for its accuracy in capturing the dynamic nature of business processes but also for its adaptability, allowing for incremental changes and updates without the need for extensive code revisions.

To implement our two-phase transformation process, we require the following:

• A metamodel for BPMN (OMG 2013) and a metamodel for BPSIM BPSIM (WFMC 2016)

• A metamodel for I2M, a contribution of the present paper • A metamodel for DEVS, EMF-DEVS metamodel designed for EMF development and used along with the DEVS-Suite simulator (Sarjoughian and Mahmoodi Markid 2012) • Mapping rules for the transformation from BPMN+BPSIM to I2M • Mapping rules for the transformation from I2M to DEVS These components ensure that the transformation process is systematic, consistent, and accurate, resulting in DEVS models that faithfully represent the original BPMN+BPSIM models, ready for effective simulation.

BPMN + BPSIM to I2M

In this section, we elucidate the transformation process from BPMN+BPSIM elements into I2M counterparts. This transformation serves as a cornerstone in our approach to facilitating the seamless transition from business process models into simulation-ready constructs. The mapping presented herein is not arbitrary but is grounded in the functional equivalence of BPMN+BPSIM elements to I2M primitives. This equivalency ensures that the behavior and semantics of the original business process model are preserved in the transformed model, thereby enhancing the validity and credibility of any ensuing simulation studies.

Table 1 illustrates some of these mappings and provides a concise explanation for each. This mapping, while not exhaustive, covers a wide range of typical BPMN+BPSIM constructs, offering a substantial foundation for the transformation of more complex business processes. Table 2 presents an assortment of mappings that involve composite I2M elements. These mappings do not explicitly denote the interconnections between the corresponding I2M elements but rather provide an illustrative catalog of the component elements contained within each composite element. Certain I2M elements, notably i2m:Broker() and i2m:RandomNumberGenerator(), are unique per process flow. Their uniqueness plays a critical role in ensuring the reproducibility of simulations, which is a cornerstone of credible simulation studies.

The i2m:Broker() guarantees consistency in resource allocation across multiple simulations, while i2m:RandomNumberGenerator() ensures the generation of reproducible stochastic behaviors. This approach upholds the reliability of our simulation results, enhancing their value in facilitating informed decisionmaking in business process management.

The composite elements listed in Table 2 are either directly linked with an i2m:SequenceFlow() or contained in an i2m:Container(). These elements are interconnected based on a preconfigured GIM for that El Kassis, Trousset, Zacharewicz, and Daclin particular type, such as a task. By simplifying the GIM using mapping rules, we determine the relevant interconnections for the transformed composite, ensuring it accurately represents the relationships and dependencies specific to the task's BPMN+BPSIM functionalities.

I2M to DEVS

In the process of our transformation from I2M to DEVS, we meticulously identify corresponding atomic and coupled DEVS components for each component in the i2m model. For instance, an i2m:Allocate() aligns with a DEVS Allocate element, and an i2m:SimpleTask() maps seamlessly to a DEVS SimpleTask element, amongst other direct correspondences.

As a consequence, the final DEVS model we generate is a precise reflection of the initial I2M model. This model can then be simulated using DEVS Suite, providing users with valuable insights into the behavior and performance of the represented business process.

To illustrate our methodology, we examine a specific BPMN Receive Task that is enriched with resources and time parameters from BPSIM. The interaction intermediate model (I2M) representation derived from these functionalities is: i2m:Container{i2m:Start(), i2m:Timer(), i2m:Receive(), i2m:Stop(), i2m:Allocate(), i2m:Unallocate(), i2m:Broker()}

As a part of our methodology, we simplify this interconnected I2M model. Accordingly, we initiate this process with the GIM of a task, depicted in Figure 2. Here, the objective is to selectively eliminate any redundant elements and connections that are not required for the specific integration of the Receive Task with resources and time.

The outcome of this simplification process is a more streamlined I2M model, represented in Figure 3. For clarity, we have marked the elements to be removed in red.

Transitioning from the I2M model to the DEVS framework is notably seamless. We've already developed all basic I2M elements within the DEVS Suite; the final transformation phase concentrates on their coupling to create the comprehensive DEVS model.

Each I2M element undergoes a one-to-one transformation into a DEVS representation, preserving original behavior and semantics without loss of information. This process is simplified due to the DEVS elements being purpose-built to reflect the functionality of their I2M counterparts.

However, the transformation of the Receive Task posed a challenge due to its three-branched join element in the I2M model. As our DEVS Suite includes a two-branched join element, we devised a unique

APPLICATION CASE

In this section of the paper, we present a practical demonstration of a BPMN+BPSIM process to emphasize the effectiveness of our proposed transformation approach. We've selected an example that includes tasks using shared resources and allocated specific durations, with resource assignments and temporal parameters outlined in BPSIM.

Figure 5 displays a graphical representation of the process. It depicts the consecutive execution of Tasks 1 and 2, followed by the concurrent execution of Tasks 3 and 4, highlighting the intertwined resource dependencies and timeframes associated with each task.

Initiating the transformation journey, we convert this BPMN+BPSIM process into its equivalent I2M representation. Subsequently, we move on to the final transformation phase, where we turn it into a DEVS model. This practical example confirms the utility of our methodology in accurately capturing resource assignments, temporal parameters, and task interdependencies, enabling the construction of a comprehensive and reliable DEVS simulation model. 2, allows for an in-depth exploration of the transformed elements and their interrelationships. Progressing with the transformation, the I2M model is translated into a DEVS model, integrating a high degree of detail and accuracy. This model is distinguished by its unique structural hierarchy, reflecting the intricate choreography between different tasks and resources within the process.

As displayed in Figure 7, the DEVS model is meticulously organized and interconnected, forming a sophisticated network of coupled DEVS elements. This coupling accentuates the intrinsic complexity of the process while also offering a detailed blueprint for task execution and management.

This dual-phase transformation, from BPMN+BPsim to I2M, and subsequently, to DEVS, delivers an exhaustive and detailed perspective of the process, fostering a deeper grasp of its architecture and dynamics. This profound comprehension sets the stage for future enhancements and refinements, driving the process toward heightened efficiency and effectiveness.

CONCLUSION

This paper presents a pioneering methodology for simulating business processes, introducing the concept of the Intermediate Interaction Model (I2M) as a crucial component. Anchored in industry standards and guided by Model-Driven Architecture principles, our methodology simplifies the transformation process and bridges the gap between business process modeling and discrete event simulations.

The I2M model, introduced as a significant contribution in this study, plays a pivotal role by translating BPMN+BPSIM elements into equivalent DEVS components, effectively linking the two domains. This innovative approach addresses a long-standing challenge in the field, enhancing the interplay between business process modeling and simulation.

Our methodology involves the meticulous mapping of BPMN and BPSIM components onto the I2M model, followed by their transformation into atomic DEVS models. By leveraging the control flow logic of the process, these atomic models are coupled to produce the final DEVS coupled model. This dual-stage transformation process, facilitated by the I2M model, effectively encapsulates the complexity while ensuring simplicity, modularity, flexibility, and enhanced simulation capabilities.

Moving forward, our future research will focus on advancing the capabilities of the I2M model and developing additional transformation rules to further refine and expand the potential of our methodology.

In conclusion, this study highlights our significant contribution in introducing the I2M within the proposed methodology. By simplifying the transformation process, our methodology establishes a solid foundation for the development of open-source, community-driven tools in the field. It also encourages further research and advancements in the integration of business process modeling and simulation, making a valuable contribution to the broader academic and industrial communities.

Figure 1 :

 1 Figure 1: Dual transformation architecture.

Figure 2 :

 2 Figure 2: GIM (Generic Interaction Model) for Tasks.

Figure 3 :

 3 Figure 3: Simplified I2M Composite of BPMN+BPSIM Receive Task.

Figure 4 :

 4 Figure 4: DEVS representation of a receive task Container with Resource and time.

Figure 5 :

 5 Figure 5: Application case in BPMN + BPSIM.

Figure 6

 6 Figure 6 unveils the completely transformed I2M model. This model, developed in accordance with the GIM model of a Task as referenced in Figure 2 and guided by the mappings delineated in Table2, allows for an in-depth exploration of the transformed elements and their interrelationships.

Figure 6 :

 6 Figure 6: I2M resulting model.

Figure 7 :

 7 Figure 7: Final DEVS target model.

Table 1 :

 1 Selected Mapping of BPMN+BPSIM Elements to I2M Simple Elements.

	BPMN + BPSIM	I2M		Explanation
	Start event	i2m:Start()		Triggers the start of a process
	End event	i2m:Stop()		Signifies the end of a process
	Timed event/Delay	i2m:Timer()		Captures time constraints or dura-
				tions
	Sending events	i2m:Send()		Captures sending interaction of a
				message i2m:Send(message) or a
				signal i2m:Send(signal)
	Receiving events	i2m:Receive()		Captures receiving interaction of a
				message i2m:Receive(message) or
				a signal i2m:Receive(signal)
	Sequence flow	i2m:SequenceFlow()		Represents the order of activities
	Message flow	i2m:MessageFlow()		Represents the exchange of mes-
				sages
	Sub-process	i2m:Container()		Represents a logical grouping or
				encapsulation of activities used to
				house a set of interconnected i2m
				elements
	Parallel Join	i2m:Join()		Represents the synchronization of
				concurrent activities
	Parallel Fork	i2m:Fork()		Represents the splitting of control
				flow into concurrent activities
	Simple task	i2m:SimpleTask()		Represents a unit of work that is
				not further decomposed
	Resource allocation	i2m:Broker(),	i2m:Allocate(),	Models resource allocation and
		i2m:Unallocate()		deallocation
	Stochastic behaviors	i2m:RandomNumberGenerator()	Captures variability and random-
				ness

Table 2 :

 2 Transformation of BPMN+BPSIM into Composite I2M elements.

	BPMN+BPSIM	Specific Element	Composite I2M Element
	Element Type
	Start Events	Timed start event	i2m:Start() -→ i2m:Timer()
		Message start event	i2m:Start() -→ i2m:Send(message)
		Signal start event	i2m:Start() -→ i2m:Send(signal)
	End Events	Message end event	i2m:Send(message) -→ i2m:Stop()
		Signal end event	i2m:Send(signal) -→ i2m:Stop()
	Tasks	Send Task	i2m:Container{ı2m:Start(), i2m:SimpleTask(), i2m:Send(message), i2m:Stop()}
		Receive Task	i2m:Container{ı2m:Start(), i2m:SimpleTask(), i2m:Receive(message), i2m:Stop()}
	Resources	Resource allocation	i2m:Container{i2m:Broker(), i2m:Start(), i2m:Allocate(), i2m:Unallocate(), i2m:Stop()}

AUTHOR BIOGRAPHIES

MARIANE EL KASSIS is a Ph.D. candidate at IMT Mines Alès, France, specializing in business process simulation and distributed simulations. She is currently focused on creating a web-based platform for M&S business processes, aiming to enhance the understanding and optimization of operational workflows. Her email address is mariane.el-kassis@mines-ales.fr.

FRANÇOIS TROUSSET is an Associate Professor at IMT Mines Alès. He received his Ph.D. from the University of Besançon in 1992, on modeling software process and performing model verification. He worked as a system and network engineer for about 20 years before returning to research activities. His research interests focuses on Artificial Intelligence, Decision Making, Modeling and Simulation. His email address is francois.trousset@mines-ales.fr.

GREGORY ZACHAREWICZ is a Full Professor at IMT Mines Alès. He received his Ph.D. from Aix-Marseille University in 2006, and his Habilitation to lead Research from the University of Bordeaux in 2014. His research focuses more generally on distributed DES M&S, DEVS, ERP, BPMN and workflow. His email address is gregory.zacharewicz@mines-ales.fr.

NICOLAS DACLIN is an Associate Professor at IMT Mines Alès, His research interests focuses on process-centric ecosystems for process management, orchestration, and M&S. He received his Ph.D. from the University of Bordeaux in 2007 and his Habilitation to lead Research from the University of Montpellier II in 2017. His email address is nicolas.daclin@mines-ales.fr.


Leila Amgoud
email: leila.amgoud@irit.fr

Victor David
email: victor.david@irit.fr

Similarity Measures based on Compiled Arguments

Argumentation is a prominent approach for reasoning with inconsistent information. It is based on the justification of formulas by arguments generated from propositional knowledge bases. It has recently been shown that similarity between arguments should be taken into account when evaluating arguments. Consequently, different similarity measures have been proposed in the literature. Although these measures satisfy desirable properties, they suffer from the side effects of being syntax-dependent. Indeed, they may miss redundant information, leading to undervalued similarity. This paper overcomes this shortcoming by compiling arguments, which amounts to transforming their formulas into clauses, and using the latter for extending existing measures and principles. We show that the new measures deal properly with the critical cases.

Introduction

Argumentation is a reasoning process based on the justification of claims by arguments, i.e., reasons for accepting claims. It has been extensively developed in Artificial Intelligence. Indeed, it was used for different purposes including decision making (eg. [START_REF] Amgoud | Using arguments for making and explaining decisions[END_REF][START_REF] Zhong | An explainable multi-attribute decision model based on argumentation[END_REF]), defeasible reasoning (eg. [START_REF] Governatori | Argumentation semantics for defeasible logic[END_REF][START_REF] García | Defeasible logic programming: an argumentative approach[END_REF]), and negotiation [START_REF] Sycara | Persuasive argumentation in negotiation[END_REF][START_REF] Hadidi | Argumentative alternating offers[END_REF].

Argumentation is also used as an alternative approach for handling inconsistency in knowledge bases [START_REF] Besnard | A logic-based theory of deductive arguments[END_REF][START_REF] Amgoud | Logical limits of abstract argumentation frameworks[END_REF][START_REF] Vesic | Identifying the class of maxi-consistent operators in argumentation[END_REF]. Starting from a knowledge base encoded in propositional logic, arguments are built using the consequence operator of the logic. An argument is a pair made of a set of formulas (called support) and a single formula (called conclusion). The conclusion follows logically from the support. Examples of arguments are A = {p ∧ q ∧ r}, p ∧ q , B = {p ∧ q}, p ∧ q and C = {p, q}, p ∧ q . Once arguments are defined, attacks between them are identified and a semantics is used for evaluating the arguments, finally formulas supported by strong arguments are inferred from the base. Some semantics, like h-Categorizer [START_REF] Besnard | A logic-based theory of deductive arguments[END_REF], satisfy the Counting (or Strict Monotony) principle defined in [START_REF] Amgoud | Axiomatic foundations of acceptability semantics[END_REF]. This principle states that each attacker of an argument contributes to weakening the argument. For instance, if the argument D = {¬p∨¬q}, ¬p∨ ¬q is attacked by A, B, C, then each of the three arguments will decrease the strength of D. However, the three attackers are somehow similar, thus D will lose more than necessary. Consequently, the authors in [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] have motivated the need for investigating the notion of similarity between pairs of such logical arguments. They introduced a set of principles that a reasonable similarity measure should satisfy, and provided several measures that satisfy them. In [START_REF] Amgoud | Gradual semantics accounting for similarity between arguments[END_REF][START_REF] Amgoud | An adjustment function for dealing with similarities[END_REF][START_REF] Amgoud | A General Setting for Gradual Semantics Dealing with Similarity[END_REF] several extensions of h-Categorizer that take into account similarities between arguments have been proposed.

While the measures from [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] return reasonable results in most cases, it was shown in [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF], that they may lead to inaccurate assessments if arguments are not concise. An arguments is concise if its support contains only information that is useful for inferring its conclusion. For instance, the argument A is not concise since its support {p ∧ q ∧ r} contains r, which is useless for the conclusion p ∧ q. The similarity measures from [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] declare the two arguments A and B as not fully similar while they support the same conclusion on the same grounds (p ∧ q). Consequently, both A and B will have an impact on D using h-Categorizer. In [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF], such arguments are cleaned up from any useless information by generating the concise versions of each argument, the measures from [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] are applied on concise arguments. However, these works fail to detect the full similarity between the two concise arguments B and C. In this paper, we solve the above issue by compiling arguments. The idea is to transform every formula in an argument's support into clauses. We extend the Jaccard-based similarity measures from [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] and show that new versions improve accuracy of similarity.

The article is organised as follows: Section 2 recalls the notions of logical argument and similarity measure. Section 3 introduces compilation of arguments. Section 4 extends some measures of similarity. Section 5 extends and propose new principles for similarity measures, and the last Section 6 concludes.

Background

Logical Concepts

Throughout the paper, we consider classical propositional logic (L, ), where L is a propositional language built up from a finite set P of variables, the two Boolean constants (true) and ⊥ (false), and the usual connectives (¬, ∨, ∧, →, ↔), and is the consequence relation of the logic. A literal is either a variable or the negation of a variable of P, the set of all literals is denoted P ± . Two formulas φ, ψ ∈ L are logically equivalent, denoted by φ ≡ ψ, iff φ ψ and ψ φ.

A formula φ is in negation normal form (NNF) if and only if it does not contain implication or equivalence symbols, and every negation symbol occurs directly in front of an atom. Following [START_REF] Lang | Propositional independence-formula-variable independence and forgetting[END_REF], we slightly abuse words and denote by NNF(φ) the formula in NNF obtained from φ by "pushing down" every occurence of ¬ (using De Morgan's law) and eliminating double negations. For instance, NNF(¬((p → q)∨¬t)) = p∧¬q∧t.

Let φ ∈ L, φ is in a conjunctive normal form (CNF) if is a conjunction of clauses i c i where each clause c i is a disjunction of literals j l j . For instance p ∧ (q ∨ t) is in a CNF while (p ∧ q) ∨ t is not.

We denote by Lit(φ) the set of literals occurring in NNF(φ), hence Lit(¬((p → q) ∨ ¬t)) = {p, ¬q, t}. The function Var(φ) returns all the variables occurring in the formula φ (e.g., Var(p ∧ ¬q ∧ t) = {p, q, t}).

A finite subset Φ of L, denoted by Φ ⊆ f L, is consistent iff Φ ⊥, it is inconsistent otherwise. Let us now define when two finite sets Φ and Ψ of formulas are equivalent. A natural definition is when the two sets have the same logical consequences, i.e., {φ ∈ L |Φ φ} = {ψ ∈ L |Ψ ψ}. Thus, the three sets {p, q}, {p ∧ p, ¬¬q}, and {p ∧ q} are pairwise equivalent. This definition is strong since it considers any inconsistent sets as equivalent. For instance, {p, ¬p} and {q, ¬q} are equivalent even if the contents (i.e. meaning of variables and formulas) of the two sets are unrelated (assume that p and q stand respectively for "bird" and "fly"). Furthermore, it considers the two sets {p, p → q} and {q, q → p} as equivalent while their contents are different as well. Clearly, the two rules "birds fly" and "everything that flies is a bird" express different information. Thus, the two sets {p, p → q} and {q, q → p} should be considered as different. Thus, in what follows we consider the following definition borrowed from [START_REF] Amgoud | Equivalence in logic-based argumentation[END_REF]. It compares formulas contained in sets instead of logical consequences of the sets.

Definition 1 (Equivalent Sets of Formulas). Two sets of formulas Φ, Ψ ⊆ f L are equivalent, denoted by Φ ∼ = Ψ , iff there is a bijection

f : Φ → Ψ s.t. ∀φ ∈ Φ, φ ≡ f (φ). Example 1. {p, p → q} ∼ = {q, q → p}, {p, ¬p} ∼ = {q, ¬q}, {p, q} ∼ = {p ∧ q} while {p, q} ∼ = {p ∧ p, ¬¬q}.
Let us define the notion of argument as in [START_REF] Besnard | A logic-based theory of deductive arguments[END_REF].

Definition 2 (Argument). An argument built under the logic (L, ) is a pair Φ, φ , where Φ ⊆ f L and φ ∈ L, such that:

-Φ is consistent, (Consistency) -Φ φ, (Validity) -Φ ⊂ Φ such that Φ φ. (Minimality)
An argument Φ, φ is trivial iff Φ = ∅ and φ ≡ .

Example 2. The three pairs A = {p ∧ q ∧ r}, p ∧ q , B = {p ∧ q}, p ∧ q and C = {p, q}, p ∧ q are arguments.

Notations: Arg(L) denotes the set of all arguments that can be built in (L, ). For any A = Φ, φ ∈ Arg(L), the functions Supp and Conc return respectively the support (Supp(A) = Φ) and the conclusion (Conc(A) = φ) of A.

Note that the argument A in the above example is not concise since r is irrelevant for the argument's conclusion. In [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF], the concise versions of arguments are computed using the following technique of refinement.

Definition 3 (Refinement). Let A, B ∈ Arg(L) s.t. A = {φ 1 , . . . , φ n }, φ , B = {φ 1 , . . . , φ n }, φ . B is a refinement of A iff: 1. φ = φ , 2.
There exists a permutation ρ of the set {1, . . . , n} such that ∀k ∈ {1, . . . , n},

φ k φ ρ(k) and Lit(φ ρ(k) ) ⊆ Lit(φ k ).
Let Ref be a function that returns the set of all refinements of a given argument.

Compared to the definition in [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF], we extended the second constraint so that literals of φ ρ(k) are also literals of φ k . The reason is that we would like the arguments {p ∧ (p ∨ q)}, p ∨ q and {(p ∨ ¬q) ∧ (p ∨ q)}, p ∨ q can be refined into {p ∨ q}, p ∨ q while this was not possible in the original definition.

It is worth mentioning that an argument may have several refinements as shown in the following example.

Example 2 (Continued). The following sets are subset of refinement of these arguments.

-{ {p ∧ q ∧ r}, p ∧ q , {p ∧ q ∧ (p ∨ q)}, p ∧ q , {p ∧ q}, p ∧ q } ⊆ Ref(A) -{ {p ∧ q}, p ∧ q , {p ∧ ¬¬q}, p ∧ q } ⊆ Ref(B) -{ {p, q}, p ∧ q , {(p ∨ p) ∧ q}, p ∧ q } ⊆ Ref(C)
Every argument is a refinement of itself.

Proposition 1. For any argument

A ∈ Arg(L), A ∈ Ref(A).

Similarity Measures

In [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF], various measures have been proposed for assessing similarity between pairs of logical arguments. They extended existing measures which compare sets of objects including Jaccard measure [START_REF] Jaccard | Nouvelles recherches sur la distributions florale[END_REF]. Due to space limitation, in this paper we will focus only on the latter. Definition 4 (Jaccard Measure). Let X, Y be arbitrary sets of objects. if

X = ∅ or Y = ∅, then s jac (X, Y ) = |X ∩ Y | |X ∪ Y | 3 If X = Y = ∅, then s jac (X, Y ) = 1.
We recall below how the above measure is used in [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] for logical arguments.

Definition 5 (Jaccard Similarity Measure). Let 0 < σ < 1. We define sim σ jac as a function assigning to any pair

(A, B) ∈ Arg(L) × Arg(L) a value sim σ jac (A, B) = σ.s jac (Supp(A), Supp(B)) + (1 -σ)s jac ({Conc(A)}, {Conc(B)}). Example 2 (Continued). sim 0.5 jac (A, B) = sim 0.5 jac (A, C) = sim 0.5 jac (B, C) = 0.5 • 0 + 0.5 • 1 = 0.5.

Compilation of arguments

Recall that {p, q} ∼ = {p ∧ q} while the two sets contain the same information. For getting them equivalent, we transform every formula into a CNF, then we split it into a set containing its clauses. Note that it is well known (eg. [START_REF] Russell | Artificial intelligence: A modern appraoch[END_REF]) that any formula can be transformed into equivalent CNFs using the same literals. In our approach, we consider one CNF per formula. For that purpose, we will use a finite sub-language F that contains one formula per equivalent class and the formula should be in a CNF. Definition 6 (Finite CNF language F). Let F ⊂ f L such that ∀φ ∈ L, there exists a unique ψ ∈ F such that:

-φ ≡ ψ, -Lit(φ) = Lit(ψ), -ψ is in a CNF. Let CNF(φ) = ψ.
While we do not specify the elements of F, we use concrete formulas in the examples, and they are assumed to belong to F.

Notation: For Φ ⊆ f L, UC(Φ) = φ∈CNF(Φ) δ clause ∈φ δ.
Let us now introduce the notion of compiled argument.

Definition 7 (Compiled Argument). The compilation of A ∈ Arg(L) is A * = UC(Supp(A)), Conc(A) .
Example 2 (Continued). The compilations of the three arguments A, B, C are:

-A * = {p, q, r}, p ∧ q , -B * = {p, q}, p ∧ q , -C * = {p, q}, p ∧ q .
Note that the compilation of an argument is not necessarily an element of Arg(L) as it may violate the minimality condition. For instance, we can see that A * / ∈ Arg(L) since the set {p, q, r} is not minimal.

To solve this problem of non-minimal compiled arguments, we will extend the notion of concise argument (from [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF]) while fixing the syntax-dependency issue. To define what a concise argument is, we first need to introduce what equivalent arguments are.

Thanks to the use of the language F in the compiled arguments, any equivalent formulas using the same literals have an identical syntax. Using this feature, we define that arguments are equivalent when they have identical compiled supports and conclusions. Note that arguments having the same compilation of their supports may not be equivalent. This is for instance the case of the two arguments D and E such that

D = {(p ∨ q) ∧ (p ∨ ¬q)}, (p ∨ q) ∧ (p ∨ ¬q) and E = {(p ∨ q) ∧ (p ∨ ¬q)}, p . Clearly, D ≈ E.
We show that trivial arguments are not equivalent. For instance ∅, p∨¬p ≈ ∅, q ∨ ¬q because {p ∨ ¬p} = {q ∨ ¬q}.

Proposition 2. Trivial arguments are pairwise non equivalent.

The objective of the notion of concise arguments is to produce the set of compiled arguments that satisfy the Definition 2. To do this, we observed that any non-equivalent refined argument A , of a compiled argument A * ∈ Arg(L), produces a new clause by inference between several clauses of the same formula.

Proposition 3. Let A ∈ Arg(L). If A ∈ Ref(A), A ≈ A and A * ∈ Arg(L) then ∃δ ∈ UC(Supp(A )) such that ∀δ ∈ UC(Supp(A)), δ = δ .
Let us define a concise argument. The first constraint ensures that argument A does not have unnecessary information (clause) to infer its conclusion. The second constraint prevents argument A from being compared with arguments that have created new information (clause) in their support.

Example 2 (Continued). The following sets are subset of concise refinements of the arguments A, B, C:

-{ {p ∧ q}, p ∧ q , {p ∧ p ∧ q}, p ∧ q } ⊂ CR(A) -{ {p ∧ q}, p ∧ q , {p ∧ q ∧ q}, p ∧ q } ⊂ CR(B) -{ {p, q}, p ∧ q , {p ∧ p, q ∧ q}, p ∧ q } ⊂ CR(C)
The non trivial argument have an infinite set of concise refinements. We show in the following theorem that the notion of a concise argument is equivalent to that of a compiled argument satisfying the conditions of the Definition 2.

Theorem 1. For any A ∈ Arg(L), A is concise iff A * ∈ Arg(L).

When two arguments are equivalent they have equivalent concise refinements. In the same way that we define a set of equivalent formulae (Definition 1), we may define a set of equivalent arguments.

Definition 10 (Equivalent sets of Arguments). Two sets of arguments Ω

A , Ω B ⊆ f Arg(L), are equivalent, denoted by Ω A ∼ =arg Ω B , iff there is a bijection f : Ω A → Ω B s.t. ∀A ∈ Ω A , A ≈ f (A ).
Otherwise Ω A and Ω B are not equivalent, denoted by

Ω A ∼ =arg Ω B .
Equivalent arguments have equivalent concise refinements.

Proposition 6. Let A, B ∈ Arg(L), if A ≈ B then CR(A) ∼ =arg CR(B).

Example 2 (Continued). B ≈ C and CR(B) ∼ =arg CR(C).

We can also see in this example that there are non-equivalent arguments with equivalent concise refinements: A ≈ B and CR(A) ∼ =arg CR(B). This is because the equivalent arguments take into account irrelevant information.

Finally, note that when a compiled argument is not minimal, this may be due to the presence of unnecessary literals in the support which will be removed in the concise arguments; or because the argument is complex, i.e. it has different reasonings to conclude, which will produce different concise arguments.

Example 2 (Continued). Let A = {p ∧ q ∧ r}, p ∧ q , F = {p ∧ q, (p → r) ∧ (q → r)}, r ∈ Arg(L). The compiled argument of A and F are:

-A * = {p, q, r}, p ∧ q , and -F * = {p, q, p → r, q → r}, r .

Clearly, r is irrelevant in A * and F * may infer r according to p or q. We may see in the concise versions of the arguments A and F that unnecessary information is removed and complex information is separated to have minimal arguments:

-{ {p ∧ q}, p ∧ q } ⊂ CR(A), and -{ {p, p → r}, r , {q, q → r}, r } ⊂ CR(F ).

Extended Similarity Measures

We are ready now to introduce the new extended similarity measures.

First, we propose to apply similarity measure between set of objects on compiled supports and conclusions. Example 2 (Continued).

-sim 0.5 jac * (A, B) = sim 0.5 jac * (A, C) = 0.5 • 2 3 + 0.5 • 1 = 5 6 = 0.833. -sim 0.5 jac * (B, C) = 0.5 • 1 + 0.5 • 1 = 1.
As we can see, working only with the compilation of arguments is not sufficient to assess degrees of similarity. It is also necessary to eliminate irrelevant information.

In the following we propose to extend the two family from [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF] dealing with concise refinements of an argument.

Definition 12 (Finite Conciseness). Let A ∈ Arg(L). We define the set

CR(A) = {B ∈ CR(A) | Supp(B) ⊂ F}.
In this way, we obtain a finite set of non-equivalent concise refinements. Proposition 7. For every A ∈ Arg(L), the set CR(A) is finite.

We may now extend the two families of similarity measures (from [START_REF] Amgoud | Similarity measures between arguments revisited[END_REF]), to add a syntax independent treatment. The value of A-CR Jaccard Similarity Measure always belongs to the unit interval.

Proposition 8. Let A, B ∈ Arg(L), sim σ jac * and σ ∈ ]0, 1[. Then sim A CR (A, B, sim σ jac * ) ∈ [0, 1].
Now we define our second family of similarity measures, which is based on comparison of sets obtained by merging supports of concise refinements of arguments. For an argument A ∈ Arg(L), we denote that set by

US(A) = A ∈CR(A)

UC(Supp(A )).

Definition 14 (U-CR Jaccard Similarity Measure). Let A, B ∈ Arg(L), 0 < σ < 1, and s jac . We define U-CR Jaccard Similarity Measure5 by sim

U CR (A, B, s jac , σ) = σ • s jac (US(A), US(B)) + (1 -σ) • s jac (UC(Conc(A)), UC(Conc(B))).
More generally, using the compilations allows to be more accurate even in the supports. Given that each clause are a formula the similarity degree can increase or decrease.

Example 3. Let

A = {p ∧ q, t}, p ∧ q ∧ t , B = {p ∧ q, r}, p ∧ q ∧ r , C = {p ∧ q, r}, p ∧ q ∧ r , D = {s ∧ t ∧ u ∧ v, r}, s ∧ t ∧ u ∧ v ∧ r ∈ Arg(L) and σ = 0.5. -sim 0.5 jac (A, B) = 0.5 • 1 3 + 0.5 • 0 = 1 6 = 0.167. -sim 0.5 jac * (A, B) = 0.5 • 2 4 + 0.5 • 2 4 = 1 2 = 0.5. -sim 0.5 jac (C, D) = 0.5 • 1 3 + 0.5 • 0 = 1 6 = 0.167. -sim 0.5 jac * (C, D) = 0.5 • 1 7 + 0.5 • 1 7 = 1 7 = 0.
143. Therefore sim 0.5 jac (A, B) ≤ sim 0.5 jac * (A, B) and sim 0.5 jac (C, D) ≥ sim 0.5 jac * (C, D). Returning to our running example (from the introduction), we see that the three arguments A, B, C are now identified as being completely similar. That is, we have dealt with both the irrelevant information problem and the syntax-dependency problem.

Example 2 (Continued). For any σ ∈ ]0, 1[:

-sim A CR (A, B, sim σ jac * ) = sim A CR (A, C, sim σ jac * ) = sim A CR (B, C, sim σ jac * ) = 1. -sim U CR (A, B, s jac , σ) = sim U CR (A, C, s jac , σ) = sim U CR (B, C, s jac , σ) = 1.
The next Theorem ensure that the two family of similarity measures (A-CR and U-CR) give the maximal degree of similarity between arguments only on arguments having equivalent concise refinements.

Theorem 2. Let A, B ∈ Arg(L), for any σ ∈ ]0, 1[, sim A CR (A, B, sim σ jac * ) = sim U CR (A, B, s jac , σ) = 1 iff CR(A) ∼ =arg CR(B).
From Proposition 6, we know that if A ≈ B then CR(A) ∼ =arg CR(B), then we can deduce the following corollary.

Corollary 1. Let A, B ∈ Arg(L), for any σ ∈ ]0, 1[, if A ≈ B then sim A CR (A, B, sim σ jac * ) = sim U CR (A, B, s jac , σ) = 1.

Extended Principles

The issue of syntax-dependence also exists in some principles. We propose here new principles for similarity measure between pairs of logical arguments and we extend some principles from [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF].

The first new principle, called Minimality, ensures that similarity depends on the content of arguments. It states that if two arguments do not share any variables, then they are completely different. An example of such arguments are {p}, p ∨ q and {t}, t . The second new principle consider that when two concise arguments have common information in their supports or conclusions hence they own some similarity between them.

Principle 2 (Non-Zero) A similarity measure sim satisfies Non-Zero iff for all A, B, A * , B * ∈ Arg(L), if

-UC(Supp(A)) ∩ UC(Supp(B)) = ∅, or -UC(Conc(A)) ∩ UC(Conc(B)) = ∅, then sim(A, B) > 0.
Example 5. Let A = {p, q}, p ∧ q , B = {p}, p ∈ Arg(L). A similarity measure sim satisfying Non-Zero ensure that sim(A, B) > 0.

The Maximality, Symmetry, Substitution, Syntax Independence principles defined in [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF] do not need to be extend while (Strict) Monotony and (Strict) Dominance have to because they are dependent of the content.

Monotony states that similarity between two arguments is all the greater when the supports of the arguments share more formulas. This extended monotony principle works only on concise arguments (i.e. using only relevant clauses). Indeed, when an argument has irrelevant information (e.g. {p ∧ q ∧ r}, p ∧ q , r is irrelevant), this distorts the measurement. In addition, constraints 2 and 3 are more precise than the original one. By making this compilation of supports we can go deeper into the formulas for a better evaluation. Example 6. Let A = {p ∧ q, r}, p ∧ q ∧ r , B = {p, q, s}, p ∧ q ∧ s , C = {p, s, (p ∧ s) → t}, t ∈ Arg(L). Their compiled arguments are:

-A * = {p, q, r}, p ∧ q ∧ r , -B * = {p, q, s}, p ∧ q ∧ s , and -C * = {p, s, ¬p ∨ ¬s ∨ t}, t .

Thanks to the compilation of arguments, a similarity measure sim which satisfies the new principle of Strict Monotony, ensures that sim(A, B) > sim(A, C).

Let us present the last principle dealing with the conclusions.

∈ Arg(L), if 1. UC(Supp(B)) = UC(Supp(C)), 2. UC(Conc(A)) ∩ UC(Conc(C)) ⊆ UC(Conc(A)) ∩ UC(Conc(B)), 3. UC(Conc(B)) \ UC(Conc(A)) ⊆ UC(Conc(C)) \ UC(Conc(A)),
then the following hold:

-sim(A, B) ≥ sim(A, C). (Dominance) -If the inclusion in condition 2 is strict or, UC(Conc(A)) ∩ UC(Conc(C)) = ∅ and condition 3 is strict, then sim(A, B) > sim(A, C). (Strict Dominance) Example 7. Let A = {p ∧ q, r}, p ∧ q ∧ r , B = {p, p → q}, p ∧ q , C = {p ∧ p → q}, q ∈ Arg(L).
Their compiled arguments are:

-A * = {p, q, r}, p ∧ q ∧ r , -B * = {p, ¬p ∨ q}, p ∧ q , and -C * = {p, ¬p ∨ q}, q .

Thanks to the compilation of arguments, a similarity measure sim which satisfies the new principle of Strict Dominance, ensures that sim(A, B) > sim(A, C).

Theorem 3. The three novel extended jaccard similarity measures satisfy all the principles.

sim σ jac sim σ jac * sim A CR sim U CR Minimality • • • • Non-Zero • • • • Monotony • • • • Strict Monotony • • • • Dominance • • • • Strict Dominance • • • • .
. The symbol • (resp. •) means the measure satisfies (resp. violates) the principle.

Table 1: Satisfaction of the principles of similarity measures Note that the use of compilation in conclusions provides more accurate syntactic measures than in [START_REF] Amgoud | Measuring similarity between logical arguments[END_REF], as seen with the satisfaction of Strict Dominance.

Clearly, the original Jaccard measure is syntax-dependent and violates all the principles except Minimality (because without common literals, the syntax of the content does not matter).

Finally, we may also remark that the measure (Finally, we may also remark that the measure (sim σ j * ) not taking into account concise arguments satisfies all the principles. This is due to the fact that the compiled arguments belong to the universe of possible arguments. We made this choice because a principle is a mandatory property. Thanks to this condition we keep the application of the principles general, by basing them on sim σ j * ) not taking into account concise arguments satisfies all the principles. This is due to the fact that the compiled arguments belong to the universe of possible arguments. We made this choice because a principle is a mandatory property. Thanks to this condition we keep the application of the principles general, by basing them on simple cases.

Conclusion

The paper further investigates the similarity between logical arguments. Based on the observation that existing similarity measures are syntax-dependent, they may provide inaccurate evaluations. We propose to compile the arguments in order to make the existing principles and similarity measures syntax-independent. This work may be extended in several ways. The first is to identify a principle, or formal property, for distinguishing families of measures on concise arguments. The second is to use the new measures to refine argumentation systems that deal with inconsistent information. The third is to study the notion of similarity for other types of arguments, such as analogical arguments. The fourth is to study the usefulness of compiled arguments to produce simple and accurate explanations. Finally, we plan to study the notion of compiled arguments between other types of argument relations such as attacks and supports.

Definition 8 (

 8 Equivalent Arguments). Two arguments A, B ∈ Arg(L) are equivalent, denoted by A ≈ B, iff UC(Supp(A)) = UC(Supp(B)) and UC({Conc(A)}) = UC({Conc(B)}). We denote by A ≈ B when A and B are not equivalent. Example 2 (Continued). B ≈ C while A ≈ B and A ≈ C.

Definition 9 (

 9 Conciseness). An argument A ∈ Arg(L) is concise iff for all B ∈ Ref(A) such that: -B * ∈ Arg(L) and, -∀δ ∈ UC(B), ∃δ ∈ UC(A) s.t. δ = δ , we have A ≈ B.Let CR(A) denote the set of all A concise refinements of A such that UC(Supp(A )) ⊆ UC(Supp(A)).

Proposition 4 .Proposition 5 .

 45 Let A ∈ Arg(L), if A is not trivial then |CR(A)| = ∞.A trivial argument have only one concise refinement, itself. Let a trivial argument A ∈ Arg(L), CR(A) = {A}.

Definition 11 (

 11 Extended Jaccard Similarity Measure). Let 0 < σ < 1. We define sim σ jac * as a function assigning to any pair (A, B) ∈ Arg(L) × Arg(L) a value sim σ jac * (A, B) = σ.s jac (UC(Supp(A)), UC(Supp(B))) + (1 -σ)s jac (UC(Conc(A)), UC(Conc(B))).

Definition 13 (

 13 A-CR Jaccard Similarity Measure). Let A, B ∈ Arg(L), and let sim σ jac * and σ ∈]0, 1[. We define A-CR Jaccard Similarity Measure 4 by sim A CR (A, B, sim σ jac * ) = Ai∈CR(A) Max(A i , CR(B), sim σ jac * ) + Bj ∈CR(B) Max(B j , CR(A), sim σ jac * ) |CR(A)| + |CR(B)| .

Principle 1 (

 1 Minimality) A similarity measure sim satisfies Minimality iff for all A, B ∈ Arg(L), if -φi∈Supp(A) Var(φ i ) ∩ φj ∈Supp(B) Var(φ j ) = ∅ and -Var(Conc(A)) ∩ Var(Conc(B)) = ∅, then sim(A, B) = 0. Example 4. Let A = {p, q}, p ∧ q , B = {r}, r ∈ Arg(L). A similarity measure sim satisfying Minimality ensure that sim(A, B) = 0.

Principle 3 (

 3 Monotony -Strict Monotony) A similarity measure sim satisfies Monotony iff for all A, B, C, A * , B * , C * ∈ Arg(L), if1. UC(Conc(A)) = UC(Conc(B)) or Var(UC(Conc(A))) ∩ Var(UC(Conc(C))) = ∅, 2. UC(Supp(A)) ∩ UC(Supp(C)) ⊆ UC(Supp(A)) ∩ UC(Supp(B)), 3. UC(Supp(B)) \ UC(Supp(A)) ⊆ UC(Supp(C)) \ UC(Supp(A)),then the following hold:sim(A, B) ≥ sim(A, C)(Monotony) -If the inclusion in condition 2 is strict or, UC(Supp(A)) ∩ UC(Supp(C)) = ∅ and condition 3 is strict, then sim(A, B) > sim(A, C). (Strict Monotony)

Principle 4 [

 4 Dominance -Strict Dominance] A similarity measure sim satisfies Dominance iff for all A, B, C, A * , B * , C *

|| stands for the cardinality of a set.

The letter A in A-CR stands for "average".

U in U-CR stands for "union".