A Lightweight Formalism for the Integration of BPMN Models with Domain Ontologies Giuseppe Della Penna1 , Roberto Del Sordo3 , Benedetto Intrigila2 , Nicoló Mezzopera3 , and Maria Teresa Pazienza2 1 Dept. of Engineering, Computer Science and Mathematics, University of L’Aquila, L’Aquila, Italy 2 Dept. of Enterprise Engineering, University of Rome Tor Vergata, Rome, Italy 3 SinergieIT srl, Rome, Italy Abstract. The widespread use of BPMN to describe business processes is highlighting the need to integrate the description of the operational flow with domain specific information. In most cases the domain knowl- edge is already represented in domain ontologies or can be derived from the existing documentation. To preserve the simplicity of the original BPMN model specifications our approach is to integrate the seman- tic and BPMN information through a separate view that can be semi- automatically built relying on the capabilities of the SyBeL modeling language. This unified view can be used to produce different artifacts to support the implementation phases of the executable process, while keeping track of the formal specifications. Keywords: Ontology; BPMN; Modeling Formal Language 1 Introduction The Business Process Modeling Notation (BPMN) is the new standard to model business process flows and web services [8]. Created by the Business Process Management Initiative (BPMI), the first goal of BPMN is to provide a notation that is readily understandable by all business users. In particular, the business analysts can directly operate with the BPMN to create the initial drafts of the new processes to be realized. Therefore their ideas can easily and precisely conveyed to the technical developers responsible for implementing the technology that will perform those processes. It is the mentioned combination of easiness of use with the precision of a formally well defined notation system which is responsible for the enormous success of BPMN. [2] Being a formalism for the modelization of processes, BPMN gives a limited support to the modelization of data. This is not an issue when the data models needed to implement the processes can be routinely constructed from a direct analysis of the business components involved. Here we focus on software projects that require a deeper semantic understanding of complex aspects of the domain. In many cases, the required semantic information can be obtained from pre- viously defined ontologies (see, e.g., [11]). In other cases, one has to rely on documents. However existing tools, such as Semantic Turkey [9], are making easier and easier the task of formalizing into ontologies the knowledge dispersed in the documents. Semantic Turkey is a free open-source platform for Semantic Bookmarking and Ontology Development. Users can adopt Semantic Turkey to keep track of relevant information from textual documents and organize collected content according to imported/per- sonally edited ontologies. Domain experts and ontology developers can build ontologies starting from the very raw source of information which they find on the web, without any need of interconnecting different heterogeneous tools and applications. Therefore it is reasonable to have a formal ontology as a source of the needed knowledge about the domain. Now the problem arises on how to combine the information formalized by means of ontological descriptions with the BPMN graphical models. To this aim several approaches are possible. The most direct one is to extend the BPMN formalism to allow semantic annotations [10, 1]. This solution has the advantage of a more complete modelization at the cost of the complexity of building up a unique comprehensive model. Here we want to explore a different approach, which is directed towards the implementation layer. We use the SyBeL formalism [3] to suitably merge the process and ontological information in a single, integrated view. With this approach, we do not modify or substitute any of the source formalisms (i.e., ontologies and BPMN descriptions), but only create an intermediate view which is useful to drive the implementation without loosing traceability with respect to the original specifications. Indeed, SyBeL has been devised to support the modelization of software sys- tems with a strong focus on the behavioural aspects and a limited but completely formal support for the modelization of data. These characteristics (that we syn- thetically expose in the next section) allow, on one hand, a direct translation of the BPMN models and, on the other, the extraction of limited data models from the ontology level. In our opinion, such a compromise is suitable when the implementation does not require a relevant modelization effort but there is still the need of a good documentation of the system for an appropriate maintenance of the system itself. 2 The SyBeL Modeling Language SyBeL is an XML based language to specify the overall behaviour of a soft- ware system. Thanks to underlying XML technologies, SyBeL can be read and written by humans, but it also represents a formal, unambiguous specification that can be easily manipulated by a machine. In this way, SyBeL tries to be a good compromise between natural language descriptions and formal, compilable specifications, i.e., it preserves the advantages provided by a natural language description, while it is also formal enough to avoid ambiguity and allow a sys- tematic reuse of the specifications throughout different phases of the software development process. In particular, SyBeL includes a behaviour description language, which allows to encode dynamic processes as flows of user-triggered and system-generated events called interactions and happenings, respectively. Each event is defined in terms of an action executed on a particular entity, and variables can be used to capture action results and reuse them later, or to declare flow parameters. Finally, flows can contain conditional branches (flow alternatives) and uncondi- tioned jump instructions to resume the execution from an arbitrary step of the flow. Therefore, it is clear that SyBeL behaviours can easily encode any BPMN- defined process. The BPMN-to-SyBeL translation is very straightforward and can be performed without loss of information, thus SyBeL behaviours can be also used to regenerate the corresponding BPMN process description. SyBeL also allows to declare data structures and types using the SyBeL do- main description language. The language defines five basic simple types (string, number, boolean, binary and any) and two type constructors, i.e., collections, which represent lists of recursively typed objects, and entity types, that are sets of recursively typed properties and (possibly parametric) actions. Entity types can be also derived from other entity types in a object-oriented fashion. These features together create a quite complete but still abstract type system, allowing to declare types and data structures which can be easily translated in a variety of object-oriented languages. However the SyBeL type system, especially entity types, was also designed with semantics in mind. Indeed, SyBeL entities can be seen as a simplified, programmer-friendly view of ontologies, whose attributes and relations are encoded using properties, actions and type derivations. This semantic connection is made explicit by the modelReference attribute, which can be used to annotate entity types as well as single properties and actions with resource identifiers referencing elements of a semantic model. Therefore, we can use the SyBeL domain language to extract suitable “views” from the information given by the ontologies, generating data structures with semantic annotations which encode the aspects most relevant to the implementa- tion and are then used to give a type to any element (entity, variable, parameter, etc) referenced in the process description. Putting all together, SyBeL can be used to fill the gap between BPMN- specified business processes, which describe the dynamic evolution of a system without data types, and ontologies, which in turn are well suited to describe data structures, but only statically. Moreover, by maintaining references to the original BPMN and ontologic sources, SyBeL does not try to substitute such formalisms, but only to offer an unified view which is useful both for documen- tation purposes and, most notably, to drive the implementation without loosing traceability with respect to the formal specifications. 3 Case Study To explain our approach, we consider a case study which is of relevant interest in its own right, the Alternative Dispute Resolution (ADR) system, also called Mediation. Mediation is a system of resolution of disputes under civil and com- mercial law which is increasingly adopted to facilitate access to justice: here we refer to European and Italian legal systems ([7] and, respectively, [4]). In the mediation a third party, called the mediator, assists the parties to negotiate a settlement. Mediation process is applicable to disputes in a variety of domains, such as commercial, legal, workplace, community and family matters. Mediation can also be seen as a powerful mechanism of eGovernment as a large part of the mediation process can be performed on the Web. It is clear that the software implementation of such an important system is critical with respect to several aspects, e.g., security, availability and reliability. For space reasons, we consider here only the case of condominium disputes. It is nevertheless a very important category, in particular in Nova Scotia (Canada) there exists a specific ADR system for such kind of disputes [5] and in Italy there is an estimated number of one million condominium disputes [6]. Also for space reasons, we limit ourselves to consider the subprocess of the initial phase of the mediation request. The main actors involved in the subprocess are the following: – Proposer: the specific party, between the parties involved in the legal dispute, that requires the mediation. – Mediator: any third person who is asked to conduct a mediation in an effec- tive, impartial and competent way. – Coordinator: in the Italian mediation system the person who assesses the mediation request and assigns it to a mediator. The BPMN diagram of the subprocess is illustrated in Figure 1. 3.1 Ontological Aspects A simple analysis of the starting subprocess shows that the only critical aspect is the description of the object of the dispute. Indeed, in an eGovernment ap- proach, we cannot assume that the parties are legal experts so that they are able to insert an appropriate description and - what is more relevant - an appropriate documentation. The risk is that the mediation request is poorly formulated so that a lengthly and costly process of revision is needed to arrive to a decision. Therefore, a valid system support is needed to ensure that the correct docu- mentation is enclosed to the request. It is natural to base such support on an ontological description of the condominium disputes able to relate the differ- ent types of disputes with the appropriate evidence required for the mediator decision. A suitably simplified version of such an ontology, inspired by [6], is sketched in Figure 2. So, for instance, an aesthetic dispute needs photographic evidence. Further information can also make clear that the author of the pho- tographs should be the condominium administrator or a person appointed by re KO so Insert application po rP Insert/complete dispute Automatic formal New anagraphical data information control Validation OK? application OK Complex dispute Assign dispute management to pool of mediators Application ort evaluation Coordinator an evaluation Not applicable id ro No proceedings oC Simple dispute Assign dispute Incorrect/Incomplete data management to single mediator Fig. 1. BPMN of the subprocess User Is_a Is_a Is_a Proposer Opponent Mediator opposes proposes mediates Application Written Is_a Evidence documents Dispute evidences Evidence Recording Is_a Evidence Is_a Is_a Is_a Is_a Is_a Is_a Is_a Pets Shared Balcony Aesthetic Spaces Irrigation Is_a Photographic Dispute Dispute Dispute Dispute evidences Evidence Noises Arrearage Odors Dispute Dispute Dispute Fig. 2. Ontology describing the data used in the subprocess the administrator. It is clear that with such support we make a step towards the basic aim of mediation, to ensure a facilitated access to justice. 3.2 SyBeL modeling By integrating the information given by the ontology with the BPMN process description, we build SyBeL domain describing the data model needed to support the process.

s t r i n g

EvidenceType

any

s t r i n g

s t r i n g

P h o t o g r a p h i c E v i d e n c e T y p e

b i n a r y Fig. 3. A fragment of the SyBeL data model An excerpt of the domain XML definition is shown in Figure 3, where the DisputeType, EvidenceType, AesteticDisputeType and PhotographicEvidenceType entities are declared through the entityType construct. Note that the hierarchy defined at ontological level by the “is a” relations is transformed in a set of suitable entity derivations using the specializations and base attributes. Other semantic relations are transformed to properties referencing the corresponding entities: as an example, the evidences relation between the dispute and the evi- dence becomes the evidences property of the DisputeType entity, which is defined as a collection of EvidenceType entities. Finally, all the relevant elements are an- notated with the modelReference attribute which connects the SyBeL constructs with the corresponding concepts of the semantic model. User name Evidence PhotographicEvidence surname author userName date photo password email mediator proposer evidences (1,n) Application Dispute evidences (1,n) Identifier documentation request openDate evidenceValidation classification NoiseDispute PetDispute AestheticDispute Fig. 4. Graphical view of the SyBeL data model A graphical representation of the SyBeL model is shown in Figure 4, which can be easily compared with the ontology shown in Figure 2. Moreover, thanks to the tools provided by SyBeL, it is possible, e.g., to automatically generate useful artifacts from the domain description, which can be directly used to drive the data model implementation. As an example, Figure 5 shows the Java declarations generated from the domain fragment of Figure 3. Now we are ready to generate a SyBeL behaviour from the BPMN process, using the domain entities to type the involved objects. Figure 6 shows a fragment of this file, in particular some parts of the main execution flow. Here, the BPMN steps are transformed in corresponding actions executed on the domain entities and encapsulated in interaction or happening events. Actions may have parame- ters (such as details) and return values (such as applicationValidation), which are also typed using the domain definitions. BPMN process branches are encoded in alternative flows (such as applicationNotValid ), which contain the corresponding guard condition. Note that each event can be also textually described, to better link it to the corresponding BPMN step. Also in this case, the SyBeL tools provide an automatic way of generating useful derived artifacts from the behaviour description. As an example, Figure 7 shows the HTML documentation of the process, which can be easily read and interpreted both by domain experts, which may use it to further validate the pro- cess, and programmers, which may take advantage from this typed, procedural view to drive the process implementation. // Semantic r e f e r e n c e : cc : d i s p u t e // S u b c l a s s e s : A e s t e t i c D i s p u t e T y p e NoiseDisputeType PetDisputeType c l a s s DisputeType { public S t r i n g r e q u e s t ; // Semantic r e f e r e n c e : cc : d i s p u t e / cc : e v i d e n c e s public C o l l e c t i o n e v i d e n c e s ; // Semantic r e f e r e n c e : cc : d i s p u t e / cc : e v i d e n c e v a l i d a t i o n public O b j e c t e v i d e n c e V a l i d a t i o n ; }; // Semantic r e f e r e n c e : cc : e v i d e n c e // S u b c l a s s e s : PhotographicEvidenceType c l a s s EvidenceType { // Semantic r e f e r e n c e : cc : e v i d e n c e / cc : a u t h o r public S t r i n g a u t h o r ; // Semantic r e f e r e n c e : cc : e v i d e n c e / cc : d a t e public S t r i n g d a t e ; }; // Semantic r e f e r e n c e : cc : a e s t h e t i c d i s p u t e // Base c l a s s : DisputeType c l a s s A e s t e t i c D i s p u t e T y p e extends DisputeType { // Semantic r e f e r e n c e : cc : d i s p u t e / cc : e v i d e n c e s public C o l l e c t i o n

e v i d e n c e s ; }; // Semantic r e f e r e n c e : cc : p h o t o g r a p h i c e v i d e n c e // Base c l a s s : EvidenceType c l a s s P h o t o g r a p h i c E v i d e n c e T y p e extends EvidenceType { // Semantic r e f e r e n c e : cc : p h o t o g r a p h i c e v i d e n c e / cc : p h o t o public byte [ ] photo ; }; Fig. 5. Java code generated from the SyBeL data model 4 Conclusions In this paper we have presented our approach to integrate the description capa- bilities of the BPMN with semantic information based on ontologies. The consideration we started with is that, in most cases, it is necessary to add to the process description some semantic information useful to define the domain in which the process will operate, and that we can assume such semantic information always codified by ontologies, preexisting or suitably generated by tools such as Semantic Turkey. Instead of directly integrating the BPMN model with semantic information, which could overcharge the model making it more difficult to read by business executives, we use the features of the lightweight SyBeL modeling language to merge the process information provided by the BPMN with the information de- rived from domain ontologies in an integrated view, which preserves the original specifications. Then, thanks to the tools provided in SyBeL, it is possible to produce a variety of artifacts and documents that can facilitate the subsequent implementation steps of the executable process. Acknowledgments. Authors would like to thank Andrea Palazzo for his con- tribution to the analysis of the case study. < i n t e r a c t i o n stepName=” s t a r t ”> < d e s c r i p t i o n>I n p u t u s e r d e t a i l s User P A ... < d e s c r i p t i o n>Perform f o r m a l v a l i d a t i o n o f t h e a p p l i c a t i o n System P < a l t e r n a t i v e f l o w=” a p p l i c a t i o n N o t V a l i d ”> a p p l i c a t i o n V a l i d a t i o n t r u e ... < i n t e r a c t i o n> C o o r d i n a t o r P M Fig. 6. A fragment of the SyBeL behaviour References 1. Born, M., Drr, F., Weber, I.: User-friendly semantic annotation in business process modeling. In: Springer (ed.) Web Information Systems Engineering WISE 2007 Workshops. Lecture Notes in Computer Science, vol. 4832, pp. 260–271 (2007) 2. Business Process Trends: Case studies and success stories, http://www.bptrends.com/ resources publications.cfm? publicationtypeID= DFFB84D1-1031-D522-339E8B42679D513F 3. Della Penna, G., Intrigila, B., Magazzeni, D., Orefice, S., Del Sordo, R., Cardinale Ciccotti, G.: SyBeL: a system modelling language enhancing automatic support in the software development process. International Journal of Software Engineering and Knowledge Engineering 23(2), 223–257 (3 2013) 4. Gazzetta Ufficiale della Repubblica Italiana: Legislative decree 4/3/2010, n. 28: mediation in civil and commercial matters, http://www.gazzettaufficiale.it/eli/id/2010/03/05/010G0050/sg 5. Government of Nova Scotia: Condominium disputes applying for dis- pute resolution, http://www.gov.ns.ca/snsmr/access/individuals/consumer- awareness/condominiums/applying-for-dispute-resolution.asp 6. Istituto Nazionale per la Mediazione e L’Arbitrato: Il mediatore condominiale, http://www.inmediar.it/il-mediatore-condominiale/ Open Application Attributes A registered user opens an application about an aesthetic dispute. The application is automatically validated, Description then approved by a coordinator who assigns it to a mediator Author Giuseppe Della Penna Stakeholder Goal The application is filled, checked and assigned to a mediator Date 2013-09-20 Revision 0 Parameters Name Type Description P ENTITY of type ApplicationType The application to be opened COLLECTION of ENTITY of type A The user details PersonalDetailsType T ENTITY of type AestheticDisputeType The documents attached to the application M ENTITY of type UserType The mediator Trigger User performs action Open on P Event Flows ApplicationOpen (main flow) Input user details start User performs action insertUserDetails on P with details=A Input application documentation User performs action insertDocumentation on P with documents=T Perform formal validation of the application System invokes action executeFormalValidation of P and assigns the result to applicationValidation if applicationValidation is not equal to true continue with flow applicationNotValid The coordinator approves the application and assigns it to a mediator Coordinator performs action evaluate on P if Coordinator performs action changeApprovalStatus on P with status=false continue with flow applicationNotApproved Coordinator performs action changeApprovalStatus on P with status=true Coordinator performs action setMediator on P with mediator=M success applicationNotValid continue with flow ApplicationOpen from step start applicationNotApproved continue with flow ApplicationOpen from step start Fig. 7. HTML documentation generated from the SyBeL behaviour 7. Official Journal of the European Union: European directove 2008/52/ec: on certain aspects of mediation in civil and commercial matters, http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:136:0003:0008:En:PDF 8. OMG: Business process model and notation (bpmn), http://www.bpmn.org/ 9. Pazienza, M.T., Scarpato, N., Stellato, A., Turbati, A.: Semantic turkey: A browser-integrated environment for knowledge acquisition and management. Se- mantic Web Journal 3(2) (2012) 10. Seitz, C.: Patterns for semantic business process modeling. Tech. Rep. 2008-07, Institut fr Informatik, University of Augsburg (2008) 11. W3C: Ontology driven architectures and potential uses of the semantic web in systems and software engineering, http://www.w3.org/2001/sw/BestPractices/SE/ODA/