Towards an Ontological Process Modeling Approach Lucinéia Heloisa Thom, José Palazzo Moreira de Oliveira, Jonas Bulegon Gassen, Mara Abel Departament of Informatics Federal University of Rio Grande do Sul Porto Alegre, Brazil 91501-970 Email: lucineia/palazzo/jbgassen/marabel@inf.ufrgs.br Abstract. Process design requires a well understanding of the application do- main. In practice, business analysts interview the domain experts and trans- late their understanding to process models. Often, the vocabulary used by the domain expert is very specific and difficult to understand by process analysts. Therefore, the process model elements can be named with inappropriate terms. Moreover, the lack of domain understanding by business analysts increases the probability of errors in the process model definition. Considering these aspects, this paper proposes an ontology process modeling approach. We expect that our approach helps to reduce the misunderstandings between the business analyst and the domain expert and at the same time it reduces the complexity and effort to build ontology and processes motivating the reuse of them. We have tested our approach in a case study regarding the Alzheimer domain. 1. Introduction The designing of particular processes from domains such as healthcare is very complex, not only because of their variety and need for flexibility, but also because they require the knowledge of very specific domain terms which can lead to interpretation problems, ambiguities and misunderstandings between the process analysts and the domain expert [Thom et al. 2006]. The medical knowledge management is a very acute concept, needed in different ways: to improve the patient care by a better know-how, to improve public health, to analyze comparative care process, to compare prescriptions. Related to these numerous needs, gathering medical information through ontologies for knowledge man- agement can be very different as numerical documents make it easy. Research on process design and ontologies have increased in recent years. One of the reasons is that ontologies and structured vocabularies in different domains help to make data understandable by machines. However, most of the existent approaches fo- cus on building ontologies for the business process management domain as well as in the use of ontologies to add more semantics for the existent process model notations and execution languages. For example Haller and others [Haller et al. 2006] present an on- tology that unifies both internal and external business processes, based on various ex- isting reference models and languages from the workflow and choreography domain. The SUPER Project has developed the Business Process modeling Ontology (BPMO) [Norton et al. 2009]. Finally, the Unified Foundation Ontology was used to provide a common ontological foundation for goals, agents and business processes aiming to bridge the gap between these concepts [Guizzardi et al. 2010]. All these approaches use ontolo- gies as a way to facilitate the understanding of the process domain. However, it remains a 242 need for more interdisciplinary approaches in the practice of process design and execution supported by ontology. This paper proposes a methodology which altogether allows building the first no- tions towards an preliminary ontology using information from process models. We call it preliminary ontology because it must be completed with terms, attributes and relation- ships by a domain expert. Afterwards, this ontology can be used to support the design of new or to adapt existent process models to be reused. We expect that our approach reduces the misunderstandings between the business analyst and the domain expert facilitating the process design. The remainder of this paper is organized as follows: Section 2 presents the core concepts about ontology used in this paper. Section 3 describes our proposed method- ology to ontology building based on process models as well as to support the design of new process models. This Section also describes a case study we performed with students from the Ontology Course of a Public Brazilian University. We conclude with a summary and outlook in Section 4. 2. Background An ontology defines a common vocabulary for researchers and other professionals who need to share information in a domain. It is a formal explicit description of concepts in a domain of discourse [Borst 1997]. Currently, there is no unique methodology to build an ontology. However, there exists a set of steps to ontology built described as follows: 1) determine the domain and scope of the ontology; 2) consider reusing existent ontologies; 3) enumerate important terms in the ontology; 4) define the classes, i.e. the representation of universal terms used to denote what is general in reality and the class hierarchy; 5) define the properties of the classes-slots (e.g. the class (concept), such as the agitation term in Fig. 2 can have the slot (property) such as agitation level); define the facets (values) of the slots (e.g. hight/intermediate/down level of agitation); create instances, that is to create instances of classes in the hierarchy. Ontologies can be classified according to their level of generality [Guarino 1998]. Top-level ontologies describe very general concepts like space, object, event and action, which are independent of a particular domain; Domain ontologies and task ontologies describe, respectively, the vocabulary related to a generic domain (e.g. medicine) or a generic task or activity (e.g. diagnosing), by specializing the terms introduced in the top- level ontology; Application ontologies refers to a specific use or application focus, which the scope is specified through testable use cases. In particular, our case study presented in Section 4 refers to application ontology. We expect to (semi-)automatically merge several selected application ontologies to build a corresponding domain ontology. But it is a more complex task that we consider as future work. 3. PROCESS DESIGN SUPPORTED BY ONTOLOGY In this section we propose a methodology which helps both process design and ontology building focusing on the alignment of both things. The methodology is composed of 5 basic steps (see Figure 1) i) understanding the purpose and domain of the process to be designed or reused; ii) designing a new process model from scratch or to adapt an existent one to be reused; iii) identifying basic terms from this process model in order to use these 243 Figure 1. Metodology to process design using ontology. terms as basic terms to build a new ontology or reuse an existent one; iv) building from scratch or to adapt an existent ontology to be reused and; v) improving a process model with information from the ontology. Altogether, the methodology allows: i) designing a process model from scratch and a corresponding ontology; ii) reusing an ontology to support the design of a new process model and; (iii) to use an existent process model to support the building of a corresponding ontology. The steps of our methodology are described here and can be seen in Fig. 1 which must be read according to the Business Process Modeling Notation (BPMN). In order to test the main steps of our methodology we developed a case study with students from the Ontology course of a public Brazilian University. The students were requested to design an agitation behavior state of a patient with the Alzheimer Disease and to build a preliminary ontology using our methodology. 1 - Understanding the process purpose and domain. In this phase the process analyst studies the application domain related to the business processes. To do that the analyst reads documents available in the organization and in the litera- ture focusing in relevant information related to the process to be designed, i.e., trying to identify process fragments as well as activity roles. The idea is to re- duce the number of interactions with the domain experts and use the interviews with them to complete the study and validate the initial findings. Based on the collected information, a query in the process repository is performed in order to verify whether there exist similar process models or fragments of them that can be reused, see Fig. 1, step 1). During the case study, the students performed an extensive study on the Alzeihmer Diseases. They had selected several health sit- uations of an elderly suffering of Alzheimer and investigated how these situations could be described as process models. 2 - Process design. Based on the study performed in step 1 the business analyst can design a process model from scratch or simply adapt a process model obtained from the process repository. (cf. Fig.1, step 2). The design is generally completed with interviews with domain experts. If the query results in a process model, the process analyst decides whether the process: i) can be used without changes; ii) after it has been changed it will be saved in the process repository without be duplicated or; iii) after it has been changed it will be duplicated in the database. Otherwise, the process will be designed from scratch. In the case of option ii) or iii) be selected the repository will be updated. The agitation behavior process describes an elderly presenting disorientation, mood and behavior changes. Note 244 Figure 2. Agitation behavior process of a patient with Alzheimer Disease. that this process is illustrative, which the students designed based on the literature and discussions we had during the ontology course (cf. Fig. 2). In real life, this process can present different behavior. As a result of this step, the students reported that they considered interesting to design situations which they thought could not be represented as process models. They learned how to focus on the core partial order of activities comprised by the studied scenarios. 3 - Identification of basic terms of the ontology. In this phase, the ontology de- signer or the process analyst will manually analyse the process and extract key terms considering the process elements such as the names of the activity labels and process participants. Based on selected key terms a query will be performed in the ontology repository to verify whether there exists a matching ontology. We are already investigating in the literature how to provide computational support for this task. Having the agitation process designed, the key terms related to the activ- ities/roles of these processes as well as further co-related terms were identified and used to build the corresponding ontology. The extracted terms are underlined as shown in Fig. 3. This step was particulary interesting because the terms extracted from the process could be used as a reference to design the ontology. Therefore, the ontology includes the concepts that are relevant to the process model defini- tion. 4 - Preliminary Ontology design. In this step, an ontology will be adapted or built from scratch (cf. Fig. 1, step 4). If there exists a matching ontology, the ontology designer decides: i) if the ontology can be reused without changes; ii) if the on- tology will be adapted according with the process model or; iii) if a new ontology will be created from scratch. In case of adapting or creating a new ontology step 4 of our methodology will be performed, and the ontology repository must be up- dated. Otherwise, step 5 will be performed based on the ontology resulted from the query. When a new ontology is created, the terms extracted from the process are the initial step to build the ontology. These terms are the key terms of the preliminary ontology and of some relationships between the terms. The ontology designer will complete this ontology adding further terms, relationships, attributes and constrains. If necessary, inference rules will also be defined. In the case study, having the basic terms identified from the process models, the preliminary ontol- ogy was built. For that, additional terms not present in the process models but 245 Figure 3. Alzheimer diseases ontology hierarchy. related to the application domain were added, so that the ontology could be more complete. Moreover, some of the terms identified from the process were sup- pressed because they were not relevant for the ontology. The most relevant terms were the subject presented in the activity labels because they could be mapped to ontology classes. The next step was to build the classes of the ontology and for this task we have used the OWL (Web Ontology Language). As a result of this step the students reported that they considered easier to design the ontology using the process terms as first reference. They tried to understand the meaning of each terms and when necessary to relate further concepts from the domain. 5 - Process model improvement. The process model obtained from step 2 of our methodology can be reviewed with the assistance of the corresponding ontology. The process has then more suitable activity labels and names of participants using the improved ontology from step 4. So, the terms presented in the process includ- ing activity labels and activity participants can be reviewed. Moreover, we expect to integrate the ontologies with the process execution. In this work we have not really tested this part of our methodology because we are still working on that. 4. SUMMARY AND OUTLOOK This paper showed that it appears to be suitable to use knowledge obtained from process models, at least as a starting point, to build the ontology and then to use the ontologies to support the design and execution of new process models within the same application domain. Main advantages of our work can be summarized as follows: i) we propose a methodology to use information from process models to build a corresponding ontology and afterwards to use the ontology that must be completed by domain expertises to sup- port the design of new similar process models. As a result, the ontology is more focused on information that are really used in the operational level of an organization (i.e., the process level); ii) we have tested the use of our methodology in a case study from the healthcare domain. The case study showed that the use of our methodology can reduce 246 the effort to understand the application domain at least regarding two scenario we have investigated; iii) based on several application ontologies we expected to develop a mech- anism to (semi-)automatically obtain domain ontologies; iv) the ontology can be used to improve the process with more suitable terms concerning its domain. Currently, we are applying our methodology in a very interesting project regarding industrial robotic ontology. Our impressions lead to the conclusion that the robotic processes include com- ponents that will generate terms in the ontology that would not appear if the ontology would be directly build. Altogether, our approach covers several different situations that can occur: if we don’t have neither the process model nor the ontology; if the process model does not exists yet, but we have the ontology to help creating it and; if we have an existent process model and want to extract an initial ontology. As future work we intend to: i) perform additional case studies including ap- plications from different domains; ii) develop a mechanism which allows to (semi-)- automatically extract the key process terms used to build the ontology specially when dealing with large process models; iii) to investigate criteria to query the process and ontology repositories, including metrics to select the most suitable process and ontology resulted from a query; iv) to explore techniques to deal with the storing of processes and ontologies in the corresponding repositories (e.g., process and ontology similarities and the decision for replacement or duplication) and; vi) to develop mechanisms to (semi-)- automatically build domain ontologies from application ontologies. Acknowledgment This research was partially supported by CNPq and CAPES, the first author works under a grant of the ”Programa Nacional de Pós-Doutorado” (CAPES/PNPD). References Borst, W. N. (1997). Construction of Engineering Ontologies for Knowledge Sharing and Reuse. PhD thesis, Enschede. Guarino, N. (1998). Formal ontology and information systems. pages 3–15. IOS Press. Guizzardi, R., Guizzardi, G., Almeida, J. P. A., and Cardoso, E. C. S. (2010). Bridg- ing the gap between goals, agents and business processes. In Proceedings of the IV International i* Workshop (ISTAR 2010), pages 46–51, Hammamet, TunÃsia. 22nd International Conference on Advanced Information Systems Engineering, CEUR. Haller, A., Oren, E., and Oren, A. H. E. (2006). A process ontology to represent se- mantics of different process and choreography meta-models. Technical report, Digital Enterprise Research Institute (DERI). Norton, B., Cabral, L., and Nitzsche, J. (2009). Ontology-based translation of business process models. In Proceedings of the 2009 Fourth International Conference on Inter- net and Web Applications and Services, pages 481–486, Washington, DC, USA. IEEE Computer Society. Thom, L. H., Reichert, M., Iochpe, C., and Moreira, J. P. (2006). Why rigid process management technology hampers computerized support of healthcare processes? In Proceedings of the X Workshop on Medical Informatics, pages 1522–1531, Belo Hori- zonte, Brazil. Computer Brazilian Society. 247