=Paper= {{Paper |id=None |storemode=property |title=Towards an Ontological Process Modeling Approach |pdfUrl=https://ceur-ws.org/Vol-938/ontobras-most2012_paper26.pdf |volume=Vol-938 |dblpUrl=https://dblp.org/rec/conf/ontobras/ThomOGA12 }} ==Towards an Ontological Process Modeling Approach== https://ceur-ws.org/Vol-938/ontobras-most2012_paper26.pdf
       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