Antonio De Nicola
email: denicola@iasi.cnr.it

Mario Lezoche
email: lezoche@iasi.cnr.it

Michele Missikoff
email: missikoff@iasi.cnr.it

An Ontological Approach to Business Process Modeling

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

This paper illustrates a method aimed at an effective involvement of business people in the development of software applications. This is achieved by providing a framework that allows the semantic enrichment of process models produced by business experts. Semantic enrichment is obtained by the semantic annotation of the business models based on a core business process ontology (CBO).

Today there is a renewed interest in business processes (BP), especially from a technological point of view. After a long time since the notion of a business process or a workflow was introduced [START_REF]Workflow Management Coalition[END_REF], the recent advent of Service Oriented Architectures [START_REF]Reference Model for Service Oriented Architecture 1[END_REF] gave a new momentum to this modelling practice. However, there is still a great difference between what is seen as BP modelling in the business world and in the IT world. In the former, processes are described mainly for human-tohuman communication, for decision making in production processes, administrative processes, to understand their impact on the enterprise organization. In the IT world, processes are seen as a form of high level programming language (see for instance BPEL [START_REF] Khalaf | The Business Process Execution Language for Web Services[END_REF] [START_REF]The Business Process Execution Language for Web Services, version 1.1[END_REF]), conceived to achieve a better use of web services (and, more generally, e-services), i.e., they represent an executable form of the application logics, as part of a complex software artefact.

While the IT view of a BP is based on a prescriptive, executable form, aiming at a running software application (based on the service-oriented paradigm), the business view of a BP remains at an intuitive level, with models independent from the underlying technology. For its deep nature, a business model is highly intuitive, easy to be read and understood by humans, but at the same time exhibits a degree of ambiguity, incompleteness, bearing often internal contradictions. The dichotomy between business and IT approaches, that represents a serious problem in enterprise automation, has been addressed by the Model-Driven Architecture (MDA) approach proposed by the OMG. The MDA approach is structured in three main levels, with a progression of modelling activities that go from a business perspective (CIM: Computational Independent Modeling) to an application design perspective (PIM: Platform Independent Modeling) and, finally, reaches the implementation perspective (PSM: Platform Specific Modeling.) The MDA appears today as one of the most relevant proposals aimed at bridging the business world with the IT world. With its progressive modeling framework, it addresses one key problem laying in the different nature of business models and IT models. However, MDA is still in an early stage and currently it mainly represents a general reference framework with a limited actual impact. In parallel, there are intense research activities aimed at producing specific methods and tools, capable of providing a smooth and coherent evolution of models from the business perspective to the technical one.

To improve the picture, one idea is to move upstream the moment where formal methods are introduced. However, it is difficult to impose new, formal languages to business people. Therefore, the solution is to "inject" formal semantics in existing business modelling methods. In this way, business people continue to use their modelling methods, having in parallel a formal support to such established solutions.

Semantic annotations make use of ontologies (see OPAL [START_REF] D'antonio | Formalizing the OPAL eBusiness ontology design patterns with OWL[END_REF].) However, current semantic technologies [START_REF] Antoniou | Web ontology language: Owl[END_REF] are particularly suited to model static structures, e.g., the information part of a business model. The semantic enrichment of the behavioural part is still an open research issue, despite existing encouraging results [START_REF]OWL-S: Semantic Markup for Web Services[END_REF], [START_REF] Rajasekaran | Enhancing Web Services Description and Discovery to Facilitate Composition[END_REF], [START_REF] Roman | Web Service Modeling Ontology[END_REF].

In the literature, several languages for BP have been proposed. Such languages can be sketchily gathered in three large groups.

• Descriptive languages. They have been conceived within the business culture, but they lack of a systematic formalization necessary to be processed by an inference engine. In this group we find diagrammatic languages, such as EPC [START_REF] Scheer | Process Modeling Using Event-Driven Process Chains[END_REF], IDEF [START_REF]IDEF Function Modeling Method[END_REF] [6] UML-Activity Diagram [START_REF]Unified Modeling Language: Superstructure version 2.1.1[END_REF], and BPMN [7] [8]. Also UML-Activity Diagram can be listed here, even if originally conceived for other purposes. The BP defined with these languages are mainly conceived for inter-human communication and are not directly executable by a computer. • Procedural languages. They are fully executable by a computer but are not intuitive enough for being used by humans, and lack of a declarative semantics, necessary to be processed by a reasoning engine. Example of these languages are BPEL [START_REF] Khalaf | The Business Process Execution Language for Web Services[END_REF] and XPDL [8] [11].

• Formal languages. They are based on rigorous mathematical foundations, but are difficult to be understood and are generally not accepted by business people. In this group we find languages such as PSL [START_REF] Bock | PSL: A Semantic Domain for Flow Models[END_REF] [20], Pi-Calculus [START_REF] Milner | Communicating and Mobile Systems: the Pi-Calculus[END_REF], Petri-Nets [START_REF] Peterson | Petri Nets[END_REF]. Finally, there are the ontology-based process languages, such as OWL-S [START_REF]OWL-S: Semantic Markup for Web Services[END_REF], WSDL-S [START_REF]W3C. Web Service Semantics -WSDL-S[END_REF], WISMO [START_REF] Roman | Web Service Modeling Ontology[END_REF], and Meteor-S [START_REF] Rajasekaran | Enhancing Web Services Description and Discovery to Facilitate Composition[END_REF]. This group of languages have a wider scope, aiming at modeling semantically rich processes in an ontological context, and have been conceived not directly connected to the business world. They are hence not considered here.

In this paper we analyse the three above categories of languages, with the intent of proposing a solution that combines the key advantages of the three above groups: intuititivity and ease of use, rigorous mathematical basis, and possibility of execution. Below, we illustrate a first version of a proposal aimed at defining the key modelling notions of a Process Ontology, referred to as BPAL: Business Process Abstract Language. It has been conceived to support the formal definition of a BP, having in mind the modelling notation proposed by OMG, mainly directed to business people: Business Process Modeling Notation (BPMN.) Furthermore, in the proposed representation method we include, inherently, modelling facilities to support a stepwise development of a BP.

Summarising, we propose BPAL, as a Core BP ontology to support the use of BPMN (but it is general enough to be used in conjunction with any other BP modelling method), characterised by the following properties:

• key constructs corresponding to concepts and modelling notions drawn from the business community; • formal grounding, with the possibility of translating it to a formal language such as KIF [START_REF]Knowledge Interchange Format, Version 3.0 Reference Manual[END_REF]; • axiomatization to allow inference mechanisms to be applied; • possibility of execution, by mapping BPAL to the popular BPEL. The rest of the paper is organised as follows. Section 2 presents the related work, organised in the three mentioned groups. Section 3 introduces the main BPMN constructs while Section 4 is the central part that introduces BPAL. Section 5 provides a mapping between BPMN, PSL and BPAL, followed by Section 6 with the conclusions.

Related Work

In this section we briefly present the major BP modelling methods and languages, organised according to the three groups identified in the previous section.

Descriptive methods

As anticipated, this group gathers the BP modelling methods that are mainly conceived for inter-humans communications. Here, among the most renewed methods, we have: UML, EPC, IDEF, and BPMN.

The Unified Modeling Language1 (UML) is an OMG2 standard providing the specification for a graphical, general purpose, object-oriented modeling language. It defines 13 types of diagram, classified as structural, behavioural, and interaction oriented, according to what aspects of a system or a scenario they describe. These diagram types adopt a common meta-model, MOF3 , defining their abstract syntax. UML has just an informal semantics associated and therefore it presents a high risk of ambiguities and contradictions in its models. Here there is not an explicit notion of a BP, however, the behavioural diagrams, and in particular the activity diagram and the sequence diagram, can be used to model a BP.

Another important method is EPC: Event-driven Process Chains, a modeling technique for business processes modeling developed in the 1990's. The basic elements of EPC are: functions, corresponding to activities to be executed; events, describing the situation before and/or after a function execution; and logical connectors (and, or, xor) used when events determine the branching of the control flow. EPC has been proposed to model BP in the context of SAP R/3 application platform, then it has spread and there are popular modelling tools, such as Visio and ARIS, that support it (the latter is based on an extensions, eEPC, that integrate also the modelling of the enterprise data and organization.) EPC is very limited in term of its modelling scope, but at the same time it is simple and therefore its learning curve is rather steep. However, since neither the syntax nor the semantics are well defined, it is not possible to formally check the model for consistency and completeness. Furthermore the lack of a formal representation can generate ambiguities, in particular, when models are exchanged between different tools. To solve this problem there are a number of proposals for a formalization, e.g., by using Petri Nets [START_REF] Van Dongen | Verification of EPCs: Using Reduction Rules and Petri Nets[END_REF].

The ICAM Definition method (IDEF) is a set of standardized modeling techniques, initially proposed by an initiative of the United States Air Force. Among these techniques we mention IDEF0, the function modeling method, and IDEF3, the process description capture method. IDEF0 is a method designed to model the decisions, actions, and activities of an organization or a system. It allows activities and important relations between them to be represented in a non-temporal fashion. It does not support the complete specification of a process. The IDEF3 provides a mechanism for collecting and documenting processes, by capturing precedence and causality relations between situations and events. There are two IDEF3 description modes, process flow, capturing knowledge of "how things work" in an organization, and object-state transition network, summarizing allowable transitions an object may undergo throughout a particular process. Here we have a limited scope (e.g., actors are not modeled) and a fragmentation due to the need to use more than one diagram for the same BP.

The Business Process Modeling Notation (BPMN) is the most recent standard notation proposed by OMG to design business processes. The main goal of this graphical notation is to be readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementation to the business people who will manage and monitor those processes. Since we selected BPMN as the candidate BP modelling method, we will specifically elaborate on it in the next Section 3.

Procedural methods

This second group gathers the BP models endowed with a precise operational semantics, having therefore an associated execution engine (i.e., an interpreter.)

The Business Process Execution Language for Web Services (BPEL4WS, or BPEL for short) is a de-facto standard for implementing processes based on web services. According to BPEL, processes can be described as executable processes, modeling the behavior of a participant in a business interaction, or as abstract processes, specifying the mutually visible message exchange among the parties involved in the protocol, without revealing their internal behavior. To obtain an executable BPEL process, modelers need to specify primitive and structured activities, execution ordering, messages exchanged, and fault and exception handling. Furthermore, a recent proposal, BPEL4People [START_REF] Ibm | WS-BPEL Extension for People-BPEL4People[END_REF], extends BPEL4WS specification to describe scenarios where users are involved in business processes. BPEL is a powerful and a widely adopted standard. Among its major drawbacks there are its inherent complexity, the verbosity of the XML encoding and the lack of a specific graphical representation. Such characteristics make it scarcely accepted by business people.

The XML Process Definition Language (XPDL) is a WfMC standard for interchanging process models among process definition tools and workflow management systems. It provides the modeling constructs of BPMN and allows a BPMN process to be specified as an XML document. XPDL process models can be run on compliant execution engines, even if has been originally conceived as a process design and interchange format specifically for BPMN. It represents the linear form of the process definition based on BPMN graphics.

Formal methods

In this section we present three formal methods conceived to model a business process in formal terms.

Process Specification Language (PSL) is a general process ontology developed at the National Institute of Standards and Technology (NIST) for the description of basic manufacturing, engineering and business processes. In the manufacturing domain, PSL's objective is to serve as an interlingua for integrating several process-related applications (including production planning, process planning, workflow management and project management) throughout the manufacturing process life cycle [START_REF] Michael | Process Specification Language (PSL): results of the first pilot implementation[END_REF]. In view of our objective of associating a formal semantics to BPMN, PSL is a good candidate, hence we will present it in more details, after the description of the Petri Nets and Pi calculus, below.

Petri Nets (also known as place/transition nets) is one of several mathematical representations of discrete distributed systems [START_REF] Peterson | Petri Nets[END_REF]. As a modeling language, it graphically depicts the structure of a distributed system as a directed bipartite graph with annotations. A Petri net consists of places, transitions, and directed arcs. Arcs run between places and transitions. Places may contain any number of tokens. Transitions act on input tokens by a process known as firing. Execution of Petri nets is nondeterministic. This means two things: multiple transitions can be enabled at the same time, any one of which can fire, none are required to fire -they fire at will, between time 0 and infinity, or not at all. Since firing is nondeterministic, Petri nets are well suited for modeling the concurrent behavior of distributed systems [START_REF] Peterson | Petri Net Theory and the Modeling of Systems[END_REF].

In theoretical computer science, the Pi-Calculus (π-calculus) is a process calculus originally developed by Robin Milner, Joachim Parrow and David Walker as a continuation of the body of work on the process calculus CCS (Calculus of Communicating Systems). The aim of the π-calculus is to be able to describe concurrent computations whose configuration may change during the computation.

The π-calculus belongs to the family of process calculi, mathematical formalisms for describing and analyzing properties of concurrent computation [START_REF] Milner | The Polyadic π-Calculus: A Tutorial[END_REF]. In fact, the πcalculus, like the λ-calculus, is so minimal that it does not contain primitives such as numbers, booleans, data structures, variables, functions, or even the usual flow control statements (such as if... then...else, while...). Central to the πcalculus is the notion of name. The simplicity of the calculus is due to the fact that names play a dual role as communication channels and variables. The process constructs available in the calculus are the following: concurrency, representing two processes or threads executed concurrently; communication, with input/output prefixing c<y>; replication, when a process creates a new copy. Although the minimality of the π-calculus prevents us from writing programs in the normal sense, it is easy to extend the calculus. In particular, it is easy to define both control structures such as recursion, loops and sequential composition and datatypes such as first-order functions, truth values, lists and integers [START_REF] Sangiorgi | The Pi-calculus: A Theory of Mobile Processes[END_REF].

Formal methods are not suited to be directly released to the end users. They are mainly conceived to study formal properties of certain categories of processes. The objective of our work is to select a formalism suited to be associated to BPMN. For its characteristics, we identified PSL, as a good candidate, therefore it will be presented in more detail in the next subsection.

PSL

The primary component of PSL is an ontology designed to represent the primitive concepts that, according to PSL, are adequate for describing basic manufacturing, engineering, and business processes [START_REF] Michael | Process Specification Language (PSL): results of the first pilot implementation[END_REF]. The challenge is to make the meaning of the terminology in the ontology explicit. Any intuitions that are implicit are a possible source of ambiguity and confusion. The PSL ontology provides a rigorous mathematical characterization of process information as well as precise expression of the basic logical properties of that information in the PSL language [START_REF] Craig | The Process Specification Language (PSL) Overview and Version 1.0 Specification[END_REF]. In providing the ontology the creators specify three notions: language, model theory and proof theory.

The Language A language is a lexicon (a set of symbols) and a grammar (a specification of how these symbols can be combined to make well-formed formulas). The lexicon consists of logical symbols (such as boolean connectives and quantifiers) and nonlogical symbols. For PSL, the nonlogical part of the lexicon consists of expressions (constants, function symbols, and predicates) chosen to represent the basic concepts in the ontology. Notably, these will include the 1-place predicates 'activity', 'activityoccurrence', 'object', and 'timepoint' for the four primary kinds of entity in the basic PSL ontology, the function symbols beginof and endof that return the timepoints at which an activity begins and ends, respectively; there are also the 2-place predicates is-occurring-at, occurrence-of, exists-at, before, and participates-in, which express important relations between various elements of the ontology.

The underlying grammar used for PSL is roughly based on the grammar of KIF [START_REF]Knowledge Interchange Format, Version 3.0 Reference Manual[END_REF] (Knowledge Interchange Format). KIF is a formal language based on first-order logic developed for the exchange of knowledge among different computer programs with disparate representations. KIF provides the level of rigor necessary to unambiguously define concepts in the ontology, a necessary characteristic to exchange manufacturing process information using the PSL Ontology. Like KIF, PSL provides a rigorous BNF (Backus-Naur form) specification [START_REF] Craig | A robust process ontology for manunfacturing system integration[END_REF]. The BNF provides a rigorous and precise recursive definition of the class of grammatically correct expressions of the PSL language. Furthermore, the rigorous specification eases the development of translators between PSL and other, similarly well-defined BP representation languages.

Model Theory

The model theory provides a rigorous, abstract mathematical characterization of the semantics, or meaning, of the language of PSL. This representation is typically a set with some additional structure (e.g., a partial ordering, lattice, or vector space). The model theory then defines meanings for the terminology and a notion of truth for sentences of the language in terms of this model. The objective is to identify each concept in the language with an element of some mathematical structure, such as lattices, linear orderings, and vector spaces.

Given a model theory, the underlying mathematical structures becomes available as a basis for reasoning about the concepts intended by the terms of the PSL language and their logical relationships, so that the set of models constitutes the formal semantics of the ontology.

Proof Theory

The proof theory consists of three components: PSL Core, one or more foundational theories, and PSL extensions.

PSL Core. The purpose of PSL-Core is to axiomatize a set of intuitive semantic primitives that is adequate for describing the fundamental concepts of business processes. Consequently, this characterization of basic processes makes few assumptions about their nature beyond what is needed for describing those processes, and the Core is therefore rather weak in terms of logical expressiveness. In particular, PSL-Core is not strong enough to provide definitions of the many auxiliary notions that become necessary to describe all intuitions about business processes. The PSL Core is a set of axioms written in the basic language of PSL. The PSL Core axioms provide a syntactic representation of the PSL model theory, in that they are sound and complete with regard to the model theory. That is to say, every axiom is true in every model of the language of the theory, and every sentence of the language of PSL that is true in every model of PSL can be derived from the axioms. Because of this tight connection between the Core axioms and the model theory for PSL, the Core itself can be said to provide a semantics for the terms in the PSL language.

Foundational Theories. The purpose of PSL Core is to axiomatize a set of intuitive semantic primitives that is adequate for describing basic processes. Consequently, their characterization does not make many assumptions about their nature, beyond their elementary description. The advantage of this is that the account of processes given in PSL Core is relatively straightforward and uncontroversial. However, a corresponding liability is that the Core is rather weak in terms of pure logical strength. In particular, the theory is not strong enough to provide definitions of the many auxiliary notions that become needed to describe an increasingly broader range of processes in increasingly finer detail. For this reason, PSL includes one or more foundational theories. A foundational theory is a theory whose expressive power is sufficient for giving precise definitions of, or axiomatizations for, the primitive concepts of PSL. Moreover, in a foundational theory, one can define a substantial number of auxiliary terms, and prove important metatheoretical properties of the core and its extensions.

For PSL's purposes, a suitable foundation is a modified and extended variation of the situation calculus. The reason for this is that the situation calculus's own primitives -situation, action, fluent (roughly, proposition) -are already highly compatible with the primitives of PSL. It is very natural to identify PSL primitives with, or define them in terms of, the primitives of the situation calculus. In addition, the situation calculus is also strong enough to define a wide variety of auxiliary notions and, with the addition of some set theory, it can be used as a basis for proving basic metatheoretic results about the Core, and its extensions as well.

Extensions. The third component of PSL are the extensions. A PSL extension provides the resources to express information involving concepts that are not part of PSL Core. Extensions give PSL a clean, modular character. PSL Core is a relatively simple theory that is adequate for expressing a wide range of basic processes. However, more complex processes require expressive resources that exceed those of PSL Core. Rather than clutter PSL Core itself with every conceivable concept that might prove useful in describing one process or another, a variety of separate, modular extensions have been, and continue to be, developed that can be added to PSL Core as needed. In this way a user can tailor PSL precisely to suit his or her expressive needs. To define an extension, new constants and/or predicates are added to the basic PSL language, and, for each new linguistic item, one or more axioms are given that constrain its interpretation. In this way one provides a "semantics" for the new linguistic items. When combined with a foundational theory like the situation calculus, a distinction can be drawn between definitional and nondefinitional extensions. A definitional extension is an extension whose new linguistic items can be completely defined in terms of the foundational theory and PSL Core. Theoretically, then, definitional extensions add no new expressive power to PSL Core + foundational theory, and hence involve no new theoretical overhead. However, because definitions of many subtle notions can be quite involved, definitional extensions can prove extremely useful for describing complex processes in succinct manner. Nondefinitional extensions, called also core theories are extensions that involve at least one notion that cannot be defined in terms of PSL Core and the chosen foundational theory. All extensions within PSL must be consistent extensions of PSL-Core, and may be consistent extensions of other PSL extensions. However, not all extensions within PSL need be mutually consistent [START_REF] Craig | The Process Specification Language (PSL) Overview and Version 1.0 Specification[END_REF].

As anticipated, seen its rich articulation, PSL has been the first candidate to associate a formal semantics to BPMN. Next we illustrate BPMN and then we will return on this issue.

BPMN: an emerging modeling method for business people

As anticipated, among the methods accepted by business people, we select BPMN for a number of reasons. Besides being the most recent one, outcome of several research activities, it allows a BP to be modeled with a single diagram type, avoiding the fragmentation inherent in the UML and IDEF solutions. With respect to EPC it has a wider scope, being capable to capture a good number of business notions, from actors to messages.

The main constructs of BPMN

The main goal of BPMN is to standardize a business process modeling notation in order to provide a simple means of communicating process information among business users, customers, suppliers, and process implementers. It defines a diagrammatic notation and an intuitive semantics for business process modeling. In the following, the basic BPMN constructs are presented with the support of a practical example.

We have categorized the BPMN constructs using four basic conceptual categories (see Table 1): actor, behavior, object, and co-action.

Actor. This category refers to the constructs devoted to model any relevant entity that is able to activate or perform a process. The BPMN elements of this category are pool, and lane, representing more aggregate organization units and more specific ones, respectively. They allow for a partitioning of activities according to the performers.

Behavior. This category refers to the constructs used to model the dynamic aspects of a domain.

An activity is a generic term for work performed within a company. It can be atomic or non-atomic (compound). The types of activity are: task, process, and subprocess. A task is an atomic activity included within a process. Processes are either contained within a pool or unbounded. Sub-processes are composed activities included within a process. There are two types of sub-processes: embedded and independent. The independent are re-usable in different processes.

A gateway is a modeling element used to represent the interaction of different sequence flows, as they diverge and converge within a process. When the sequence flows arrive at a gateway, they can be merged together on input and/or split apart on output. There are different types of gateway according to the types of behavior they define in the sequence flow. Decisions and branching are represented by the following gateways: OR-Split, exclusive-XOR, inclusive-OR, and complex. Merging is represented by the OR-Join gateway. Finally, forking is represented by the AND-Split gateway, and joining by the AND-Join gateway.

Another construct referring to this modeling category is event. An event is something that "happens", like a trigger or a result, during the execution of a business process affecting the flow of the process. Since an event can start, suspend, or end the flow, we can distinguish between start events, intermediate events, and end events 4 .

The last basic construct referring to this category is the sequence flow (modeled with an arrow), used to represent the ordering of activities within a process. Their source and target must be events, activities, and gateways. A sequence flow can not cross the boundaries of a sub-process or a pool (messages are used instead).

Table 1 Categorization of BPMN constructs and corresponding graphical notation

Object. This category refers to the constructs devoted to model passive entities involved in one or more business processes. The main BPMN element of this category is data object. A data object is used to represent how data and documents are used within a process. They can be used to define input and output of activities.

Furthermore, data objects are used to represent the "state" of a document (e.g. request document issued or received) and how this state changes during the process.

Co-action. The last category refers to the constructs devoted to model the interaction between different actors. Message events represent start, intermediate, and end events associated to the sending or receiving of a message. The message flow is to show the flow of messages between two participants of a process. It can be connected to the boundary of a pool, representing a participant in a process, or to an activity within the pool.

An example: Existence Verification of a Company

To better illustrate the BP modeling by using BPMN, below we introduce a simple example (Figure 1), drawn from a case study addressed in the LD-CAST European Project5 : the search for a partner in a cross-border off-shoring. In particular, we address the activities related to the Supply Sub-Contracting, according to a specific EU directive.

Figure 1 An excerpt of the existence verification process

The case study concerns a Polish company that needs to purchase a set of lift components to be locally assembled. To this end, it publishes in the Official EU Gazette a call for proposals. The company receives tenders submitted by a Rumanian company for supplying the cables, by an Italian company for providing the engine, and by a Bulgarian company for the cabin. Having received the tenders, the Polish company needs to perform a number of verifications. In particular, for each proponent company, the following verifications are performed: (i) existence verification, (ii) fiscal verification, and (iii) technical requirements and quality standards verification. Such verifications are performed through the local Chambers of Commerce. The Figure 1 represents the BPMN process concerning point (i), the request for verifying the actual existence of the potential partner. According to the process in the figure, the legal office of a company sends a request message to the marketing department of the local Chamber of Commerce (CoC) to obtain an existence verification of that company. The CoC checks if the requested document should have a legal validity or not. Accordingly, the CoC releases a certificate or a survey, respectively. Finally, the CoC sends the document, the company receives it and the process ends. This example will be represented in formal terms by using BPAL, as reported in the appendix.

BPAL: an ontological framework 6 for BP

In this section we present BPAL, a framework for the management of BP ontologies, in the context of BPMN business process modeling method.

BPAL is structured according to a number of modeling notions defined in accordance with the business culture, corresponding also to the constructs of BPMN. The set of symbols denoting such modeling notions is the lexicon of the BPAL. The corresponding concepts, in the form of atomic formulae (atoms), represent the core BP ontology. BPAL atoms are used to build abstract diagrams that, once validated with respect to the BPAL Axioms, yield to abstract processes. An abstract process is isomorphic to a BPMN 7 process and provides its formal semantics.

BPAL Atoms -represented in the form of predicates. They are the core of the BPAL ontological approach and a specific BP ontology is modeled by instantiating 8 one or more Process Atoms. Atoms represent unary and n-ary business concepts. Furthermore, there are special atoms aimed at supporting the modeling process (see below.) BPAL Axioms -represent the rules and constraints that a BPAL Diagram must respect to be a BPAL Process.

BPAL Diagram -a set of BPAL Atoms represents an abstract diagram. In general, a diagram is an intermediate form assumed by a modeling artifact during the design process. It is not required to satisfy all the axioms. BPAL Process -this is a BPAL Diagram that has been validated with respect to the BPAL Axioms. In the paper, we will refer to it as an abstract process.

BPAL Application Ontology -a collection of BPAL Processes cooperating in a given application. Below we report a list of the BPAL Atoms and then we give a few examples of their use for building abstract diagrams and BPs. Please remember that BPAL is not a diagrammatic notation, for this reason we refer to a BPAL artefact as an abstract 6 The term "framework" is overloaded. Here we mean a language (lexicon and grammar), a set of axioms, an inference mechanism, and a collection of methods, tools, and best practices aimed at producing a valid BP model. Here we illustrate the BPAL framework at a descriptive level, since a formal treatment falls outside of the scope of this paper. 7 For sake of conciseness, here we will refer to a simplified version of BPMN, sufficient to present the BPAL methodology. 8 Please note that this is a second order instantiation, very different from the more usual round instantiation. In fact, BPAL contains meta-concepts used to create a BP ontology.

diagram. Seen it originates from BPMN, the latter is used whenever we need a concrete (displayed) diagram.

BPAL Atoms

The BPAL atoms are predicates where functors represent ontological categories, while arguments are typed variables representing concepts in the Core Business Ontology (CBO). For instance, an activity variable can be instantiated with a process name in the CBO. Variables are characterized by a prefixed underscore and, in building a BP ontology, will be instantiated with concept names of the category indicated by the functor. A process ontology is built by instantiating the following unbound predicates with the constants (i.e., concept names) declared in the CBO 9 .

Unary predicates (upre)

• act(_a) -a business activity, element of an abstract diagram.

• role(_x) -a business actor, involved with a given role in one or more activities.

• dec(_bexp) -a generic decision point. Its argument is a Boolean expression evaluated to {true, false}. It is used in the preliminary design phases when developing a BP with a stepwise refinement approach. In later phases, it will be substituted with one of the specific decision predicates (see below). • adec(_bexp), odec(_bexp) -decision points representing a branching in the sequence flow, where the following paths will be executed in parallel, or in alternative respectively. • cont(_obj) -an information structure. For instance a business document (e.g., purchaseOrder). • cxt(_obj) -a context, represented by a collection of information structures.

Relational predicates

• prec(_act|_dec,_act|_dec) -a precedence relation between activities, decisions, or an activity and a decision. • xdec(_bexp,_ trueAct) -this is a decision where only one successor will receive the control, depending on the value of _bexp. • iter(_startAct,_endAct,_bexp) -a subdiagram, having startAct and endAct as source and sink, respectively. It is repeated until the boolean expression _bexp evaluates to true. • perf(_role,_act) -a relation that indicates which role(s) is dedicated to which activities. • msg(_obj,_sourceNode,_destNode) -a message, characterized, for instance, by a content (_obj), a sending activity (_sourceNode), and a receiving activity (_destNode). 10

Development predicates

The following predicates are used during the BP development process. They are part of the BPAL core ontology, but are not used to categorise business concepts (therefore will not contribute to the generation of the executable image.)

• pof(_upre,_upre) -Part-of relation that applies to any unary predicate. It allows for a top-down decomposition of concepts. • isa(_upre,_upre) -Specialization relation that applies to any unary predicate.

It allows to build a hierarchy of BP concepts, supporting a top-down refinement. Finally, we have two operations acting on a BP abstract diagram:

Assert (BP_Atom). It allows a new atom to be included in the ontology; Retract (BP_Atom). It allows an existing atom to be removed from the ontology. To improve readability, multiple operations of the same sort can be compacted in a single operation on multiple arguments (see the example below.)

BPAL diagrams and processes

By using BPAL atoms it is possible to compose an abstract diagram first and, after its validation, a BPAL process. An abstract diagram is a set of BPAL atoms respecting the (very simple) formation rules.

In Figure 2 we illustrate an abstract diagram; the presentation is supported by a concrete diagram, drawn with a BPMN style. The node labels are concepts in the CBO.

A BPAL Abstract Diagram

Please note that in a BPAL diagram the order of the atoms is ininfluent and, in the punctuation, comma and colon are equivalent, while the full stop ends the abstract diagram.

The BPAL Axioms

The BPAL framework is characterised by a number of axioms that must be satisfied by a BPAL Process. They are conceived starting from the guidelines for building a correct BPMN process. As anticipated, there is neither a formal specification nor a widely accepted view of the formation rules for a BPMN process, therefore we provide a "reasonable" solution, derived from the analysis of a number of publications and practical experiences. In any case, we are ready to update the proposed axiomatization as soon as an official specification will be available. Here we do not intend to present a complete treatement of the BPAL axiomatic theory, we rather wish to achieve a clear description of our proposal, trading completeness with conciseness. BPAL axioms address different features of a BPMN process formalization. Here we will formalize just one axiom, to provide a first insight in the BPAL methodology.

Branching

Each time a node is followed by more than one immediate successor activities, such a node must be a decision. prec(k,c),prec(c,d),prec(b,d),prec(d,e).

Abstract BPAL generic process

Please note that we have now a Generic BPAL abstract process. It is a process since the Axiom1 is no more violated and therefore the Diagram 1 is validated. However, it is Generic, since there is a generic atom dec(k) that need to be substitute with a specific atom (one of: adec, odec, xdec.) Such a substitution, assuming that in the following steps of the BP design we discover that we need an and branching, will be achieved by the following design operations:

assert: adec(k) retract: dec(k)
Further steps of design refinement will involve other BPAL atoms, to specify roles, messages, etc.

Transforming BPAL abstract process in an executable form.

The BPMN tool that we considered as a reference point allows a BPEL executable process to be generated starting from the built diagram. Since there is a tight correspondence between the BPMN and the BPAL constructs, it is easy to adopt an equivalent correspondence between BPAL and BPEL constructs, and then provide the generation of an executable BPEL file starting from a complete BPAL process. A full elaboration of this part falls outside the scope of this paper.

The semantic enrichment of BPMN: a mapping to PSL and BPAL

The initial objective of this paper was to provide a formal account of a BPMN diagram. This can be achieved by building a mapping between the constructs of the latter and a formal language for BP modeling. To this end we considered as a candidate PSL, presented in Section 2. However, we realized that BPMN-PSL mapping is not straight, being PSL a sound and rich BP modeling framework, not primarily conceived having the business modeling needs in mind. Therefore we decided to propose BPAL. In the table 2, we report a sketchy representation of a comparison between the two mappings: BPMN with PSL and BPAL, for an easy checking the better mapping yield by the latter.

A first consideration concerns the fact that PSL Core is far to succinct and it must be considered with some extensions in any concrete case. For a fair comparison we considered the following PSL extensions (the semantics of the constructs is intuitive): From the table it emerges that, with respect to the BPMN modeling paradigm, BPAL shows a better coverage than PSL. Furthermore, BPAL is compact, while PSL is fragmented in different extensions. These considerations justify our work on BPAL.

PSL
The different mappings should not be confused with the respective expressive power (our intuition is that, with its various extensions, PSL is more expressive than BPAL.) Here we prefer to talk about "adequacy", i.e., the affinity between the two modeling methods.

Conclusions and future work

In this paper we presented the main ideas of BPAL, an ontological framework for business process modeling. There are a very large number of BP modeling languages, so the decision to build a new peoposal in this area started from a number of motivations.

-the advent of a new BP modeling method, BPMN, proposed by OMG; -the fact that BPMN does not have a formal grounding, being it specified in an informal way; -BPAL has been initially conceived to develop a formal account of BPMN processes, carefully taking in consideration the business experts needs; -The BPAL approach also considers the BP design process, therefore including primitives that support a stepwise refinement of processes being designed; -BPAL remains at an abstract level, since it relies on BPMN for its concrete diagrammatic representation and on BPEL for its actual execution; -BPAL framework includes an axiom system that allow an automatic validation check to be performed. Since its formal semantics is based on KIF, the inference component is based on a KIF reasoner.

After a careful analysis of the literature we identified PSL as a possible candidate to match the above requirements, but finally we decided that BPAL was more suited to our needs.

The current BPAL version is a preliminary one. We are consolidating it by proceeding along two lines. One is methodological, necessary to strengthen its formal grounding, and another is empirical, necessary to check its value in real business settings. About the latter, we are using BPAL in several pilot applications, the most relevant being the LD-CAST European project, for the Chambers of Commerce, and TOCAI, a national project aiming at an advanced platform for autonomic logistics services.

Figure 2 A

 2 Figure 2 A simple BPMN DiagramHere we have the corresponding BPAL abstract diagram.

Figure 3 A

 3 Figure 3 A Generic BPAL Process

Table 2 Comparison between the BPMN, PSL, and BPAL

 2

	-Core:
	•	Activity
	•	Before
	•	Object
	Outer Core:
	•	SubActivity
	Activity Extension:
	•	Branch
	Actor and Agent theories
	•	Activity performance (under constraction)
	Duration and Ordering Activity
	•	Iterated Activity
	Modeling categories	BPMN constructs	PSL	BPAL
	Actor		Pool, Lane	Activity	role
				performance
	Behavior	Process, Task, Sub-	Activity,	activity, iter,
			process	Subactivity	isa
		Decision	Gateway (Data/Event	Branch	dec, adec,
			based, AND/OR/XOR)		odec, xdec
		Event	Event (Start,		activity
			Intermediate, End)
		Transition	Sequence Flow	Before	precedence
	Object		DataObject	Object	content,
					context
	Coaction	Message Event,	Envelop	message
			MessageFlow

www.uml.org

Object Management Group: www.omg.org

Meta-Object Facility

Despite event is basic modeling construct in BPMN, its semantics is not clear. In fact, when mapped into BPEL, they are considered as atomic activities (e.g., receive, wait, and throw)[START_REF]Business Process Modeling Notation Specification[END_REF].

Local Development Cooperation Actions Enabled By Semantic Technology (LD-CAST) Project: http://www.ldcastproject.com

Here, for sake of simplicity, we refer to the CBO as a sort of catalogue of concepts. Indeed, it is implemented by a reference ontology built according to the OPAL framework[START_REF] D'antonio | Formalizing the OPAL eBusiness ontology design patterns with OWL[END_REF]

Please note that the message flow is not constrained by the control flow, unlike BPMN.14 Antonio De Nicola, Mario Lezoche, Michele Missikoff

Appendix 2. Sampling of BPAL in KIF Primitive Lexicon

The Lexicon is represented by the atoms reported in the Section 4 with a prefix syntax and variables preceded by the question mark, all enclosed in parenthesis. Example: (act ?a), (role ?r), (dec ?d).

KIF atoms

(act ?a) is TRUE in an interpretation of BPAL if and only if ?a is a member of the set of activities in the universe of discourse of the interpretation. Intuitively, activities can be considered to be reusable behaviours within the domain. (role ?r) is TRUE in an interpretation of BPAL if and only if ?r is a member of the set of roles in the universe of discourse of the interpretation. (dec ?d) is TRUE in an interpretation of BPAL if and only if ?d is a member of the set of decisions in the universe of discourse of the interpretation. (cont ?t) is TRUE in an interpretation of BPAL if and only if ?t is a member of the set of contents in the universe of discourse of the interpretation. (cxt ?c) is TRUE in an interpretation of BPAL if and only if ?c is a member of the set of contexts in the universe of discourse of the interpretation. (prec ?a1 ?a2) is TRUE in an interpretation of BPAL if and only if the activity ?a1 is before ?a2 in the linear ordering over activities in the interpretation. (xdec ?f ?a1 ?a2) is TRUE in an interpretation of BPAL if and only if ?f is a function that maps sentences in truth values TRUE or FALSE, consequently, if the ?f maps to TRUE, activity ?a1 is executed otherwise activity ?a2 is executed. (msg ?c ?a1 ?a2) is TRUE in an interpretation of BPAL if and only if activity ?a1 sends a content ?c to activity ?a2. (iter ?a1, ?an ?f) is TRUE in an interpretation of BPAL if and only if the activities contained between ?a1 to ?an are repeated until the conditional ?f returns value TRUE.

AXIOMS Axiom 1 (Branching)

Each time an activity is followed by more than one immediate successor activities, a decision atom must be interposed.


Mario Lezoche
email: lezoche@iasi.cnr.it

Michele Missikoff
email: missikoff@iasi.cnr.it

Leonardo Tininini
email: tininini@iasi.cnr.it

Business Process Evolution: a Rule-based Approach

Keywords: Business Process Modelling, Business Rules, Ontologies

Business Process (BP) evolution is a key aspect of BP lifecycle. There are several reasons that may cause BP modifications. Among these, particularly important are the changes of the enterprise organization and operation strategies, which can be captured by business rules (BRs). We focus here on a BP-based enterprise that, in addition to the enterprise BPs, is also regulated by a set of BRs: such BPs and BRs need to be globally consistent (and have to be maintained consistent after any changes). In this paper we present an ontological approach capable of representing BRs and BPs in a coherent way. Then, our objective is twofold: (i) clarifying the intended meaning of a BR that (when firstly formulated) may have more than one interpretation; (ii) identifying all processes in the BP repository that are (or have become) inconsistent with the BRs and thus need to be changed to reestablish the overall consistency.

Introduction

Business process (BP) modelling is opening a new phase in the development of enterprise software applications (ESA), thanks to the recent proposal of the Model Driven Architecture (MDA) approach, promoted by OMG [START_REF] Soley | Model Driven Architecture[END_REF]. In essence, MDA proposes 3 levels of BP models: I. computational independent models (CIM), where business experts provide a first (informal) description of a BP (e.g. by using EPC [START_REF] Van Der Aalst | Formalization and Verification of Event-driven Process Chains[END_REF]); II. platform independent models (PIM), where business experts work together with IT experts to build a procedural specification of the process in a rigorous way (e.g., by using BPMN [START_REF] White | Introduction to BPMN[END_REF]), but leaving out low level technical details; III. platform specific models (PSM), developed by IT experts, where all the technical details are introduced to achieve a complete specification, (e.g., by using BPEL4WS [START_REF]The Business Process Execution Language for Web Services[END_REF]), ready to be executed by a suitable engine (e.g., ActiveBPEL 1 ) [START_REF] Qian | Tool Support for BPEL Verification in ActiveBPEL Engine[END_REF], invoking the required services.

The OMG-MDA proposal has been mainly conceived to support a layered development of enterprise software applications, however for what concerns BP lifecycle, and in particular BP evolution it does not propose any specific approach. In 1 www.activebpel.com a dynamic enterprise, BPs need to be periodically revised and updated. Such BP evolution may be necessary for different reasons, for instance: poor functional performances (e.g., a process takes too much time or fails to fully achieve what expected), poor non-functional performances (e.g., security and privacy are not sufficiently guaranteed), new company policies (requiring the update of non conformant BPs). In this paper we address the latter issue, in a context where company policies are mainly expressed by business rules (BR).

Company policies are often represented in the form of business rules (BRs.) Business experts usually tend to formulate a BR in natural language. For instance, a BR can say: "all expenses greater than 5.000€ require the approval of the Head of Unit". Another BR may involve the way business operations are performed, for instance: "the receiving of a quotation must precede the issuing of a purchase order". The latter BR can be synthesized by the expression: A precedes B. In the context of BP evolution, a challenging problem is to automatically identify the BPs that violate a BR and, possibly, to make the former evolving according to the latter.

In this paper we present an ontological approach to BP modelling, proposing a method to verify if, given a BR, a process is consistent with it. To this end, we briefly introduce the BPAL (Business Process Abstract Language) ontological framework and we show how the semantics of a BP can be modelled. The modelling primitives of BPAL have been derived from BPMN. We focus then on the problem of a BR formulation in the context of a BPAL ontology and on how to decide if a given BP is still consistent with the BR content or it should be modified. Our proposal is positioned across the CIM and PIM levels of the MDA. The idea is to enhance intuitive modelling tools, such as BPMN, by associating to them a BP ontology system. The latter will provide a formal setting and the related semantic services.

Often, BRs are specified in natural language (NL) by business people and the intended meaning may not be sufficiently precise, therefore it is necessary to preliminarily understand what the BR content is, i.e., its semantics. The focus of the first objective of the paper is, therefore, on a method aimed at supporting business expert to disambiguate BRs that may be interpreted in different ways.

Once a BR has been disambiguated and reformulated to explicitly represent its intended meaning, we can address the second objective of the paper: BP consistency.

Here it is necessary to first identify the BPs that violate the BR, and then to propose the updates necessary to make the former consistent with the latter.

BRs can represent a large variety of enterprise directives and constraints. Here we focus on a specific case, the procedural aspect of a BP, namely the sequence of activities, and BRs that indicate the correct order in which activities should be performed. Such BRs, having the form: A precedes B, have been extensively analysed by Van der Aalst [START_REF] Van Der Aalst | DecSerFlow: Towards a Truly Declarative Service Flow Language[END_REF]. Here, for sake of conciseness, we address the same problem, but our solution is inherently different since we address the intensional level, i.e., BP schemas, while in [START_REF] Van Der Aalst | DecSerFlow: Towards a Truly Declarative Service Flow Language[END_REF] the focus is on the extensional level, i.e., BP instances.

The literature reports a large number of relevant results in the areas of process modeling, rules representation and management and, in particular, results addressing the analysis of activities sequencing. However, we wish to point out that we avoided sophisticated approaches, such as those based on temporal algebra (see the proposals based on the Allen's work [START_REF] Allen | Maintaining knowledge about temporal intervals[END_REF]) or temporal logic [START_REF] Gabbay | Temporal Logic: Mathematical Foundations and Computational Aspects[END_REF], and its variations (such as Event Calculus [START_REF] Kowalski | A logic-based calculus of events[END_REF] and Situation Calculus [START_REF] Pirri | Some contributions to the metatheory of the Situation Calculus[END_REF].) Instead, here we approached the analysis of BP and the sequencing of their activities by using the simple notion of precedence. Furthermore, we are not addressing here the problem of consistency of conditional expressions, such as those that may appear in a decision that determines the behavior of a branching. Here we simply record the nature of the brench, namely: and, or, xor. The simplified approach assumed in this work is already sufficiently expressive to produce a few interesting results and, at the same time, leaves space for future work where we plan to introduce a richer modeling paradigm.

The rest of the paper is organised as follows. The next section introduces a simplified version of BPAL to represent a BP and its specification. Section 3 illustrates how a BR can be expressed and formally represented, then Section 4 elaborates on the precedence rule and its different meanings. Here two are the main contributions: (i) how to support the business expert in clarifying his/her mind, when the BR looks ambiguous; (ii) how to verify if a given BP is contradicting the rule or not. Finally, Section 5 presents the conclusions and some directions for future research.

BP schema and instances in BPAL

BPAL [START_REF] De Nicola | An Ontological Approach to Business Process Modeling[END_REF] is an ontology modelling framework that allows a predicative specification of a BP Schema to be formulated. The simplified version of BPAL2 adopted in the rest of the paper uses symbols for constants (a, b, c, …), variables (?a, ?b, ?c, …), and conditionals (?h, ?k, …), as well as the following atoms to represent:

-Activities: act(?a) -Precedence relations: prec(?a,?b) -Decisions: dec(?k,?a) Note that decision atoms can be specialized to AND, OR or XOR type, e.g. a XOR decision will be represented by xdec(?k, ?a). Where ?a represents the then-activity in a typical IF-THEN-ELSE decision. When more than 2 mutually exclusive branches are available, it is necessary to use a sequence of xdec. Conversely, the AND, OR decisions essentially act as a semaphore "go/no-go" and therefore they only require a conditional.

We distinguish a BP Schema (BPS), which is a set of predicative atoms, from a BP Instance (BPI) represented by a chain of ground terms. A BPI originates from the actual execution of a BP Schema and each element of the chain (activity instance) corresponds to an execution of an activity (variable) in BPS.

Activity variables are assumed to be typed, according to a set of activity kinds, denoted by capital letters (A, B, C). To keep the notation lightweight, in this paper we avoid the explicit typing of activities, and the implicit typing is achieved by matching the first letter of the term. For example, type(?a, A) is always true. A similar method is applied to instantiation and activity instances are denoted by letters that correspond to the activity kinds. A relation inst(?a,a) says that a is an instance activity of ?a. We will also refer to a BPI as a BP Log.

Activity kinds are essential to express rules and constraints, since they are general and do not apply to a single BPS or BPI, but to all of them (unless otherwise specified.) Therefore a rule of the form: prec(A,B) imposes a control flow constraint on all activities act(?a) and act(?b) of type A and B, respectively. Then, prec(?a,?b) is consistent with a BR stating prec(A,B) and consequently all its executions will produce valid ground terms of the form: prec(a,b).

In the following we show a simple example of a BPS modelled as a set of atoms, and its BPIs, modelled as chains of ground terms. In Figure 1, the following BPS is displayed: bpi XOR = {<a,b,d,e>, <a,c,e>}. Please note that an activity instance is registered in the log at the moment of its completion. Therefore prec(b,c) may hold, even if the activity instance c has started before b, because c execution may take longer, causing c completion to follow that of b.

Representing Business Rules

Business rules are used by managers to indicate invariants that impact on the organization and its way of operating. Rules represent a very powerful modelling paradigm. Here we focus on the impact of rules guiding the design and the evolution of BPSs. BRs are usually specified in natural language, but it is well-known that NL is often ambiguous and error-prone. For this reason, there are interesting proposals of using structured (controlled) natural language. Recently, OMG promoted the use of structured English in the business rules framework SBRV [START_REF]Semantics of Business Vocabulary and Business Rules Specification[END_REF]. Another interesting proposal is ACE (Attempto Controlled English, [START_REF] Fuchs | Discourse Representation Structures for ACE 6.0[END_REF]): a rich subset of standard English, designed for specification and knowledge representation. By using ACE, BRs can be expressed in rigorous way, having at the same time a simple (almost) natural language interface that can be easily used by business experts. ACE relies on a platform capable of translating a sentence expressed in a controlled natural language into a first order logic (FOL) formula. The latter can be then verified by using a theorem prover.

In this paper we show how the problem of BR formulation can be effectively solved in the context of a BPAL ontology. In particular, we will show how it is possible to support a business expert in formulating an example BR of the kind: "A precedes B". The BR will be initially expressed in generic terms, then incrementally refined, by prompting the business expert with simple, specific questions, aiming at progressively removing the ambiguities.

On the semantics of a BR

As anticipated, in order to illustrate the BPAL approach to BR formulation, we use an example BR, informally expressed by the sentence: "A precedes B". Although the intuitive meaning seems to be clear, a more careful analysis shows different possible interpretations. Here we will consider, as an illustrative example, a subset of the cases reported in [START_REF] Van Der Aalst | DecSerFlow: Towards a Truly Declarative Service Flow Language[END_REF]. The semantics of each case will be represented at an intuitive level, reporting a BPI. 1) Response: every time activity A executes, activity B has to be executed after it. B does not have to execute immediately after A, and another A can be executed between the first A and the subsequent B. Furthermore, an execution of B does not require to be preceded by A. i.e. <b, a, a, c, b> 2) Precedence: if activity B is executed, its (possibly multiple) executions must follow the execution of A. i.e. <a, c, b, b, a, b> 3) Alternate response: after activity A there must be an activity B, and before that activity B there can not be another activity A (but a B not following A is ok). i.e. <b, a, c, b, a, b> 4) Alternate precedence: every instance of activity B has to be preceded by an instance of activity A and the next instance of activity B can not be executed before the next instance of activity A is executed. i.e. <a, c, b, a, b, a> 5) Chain response: the next activity after each activity A has to be activity B, then the execution <b, a, b, c, a, b> is a correct one. 6) Chain precedence: requires that the activity A is the first preceding activity before B (but is not necessary that a B follows an A) and, hence, the sequence <a, b, c, a, b, a> is correct

Clarifying the semantics of a BR

Our goal is to disambiguate the BR "A precedes B", with respect to the six reported cases, by posing few and simple questions to the user. Instead of using a question for each of the six (fairly complex) cases reported above, we propose a more intuitive disambiguation method, requiring a lower number of simple yes/no questions. α. Can I execute any activities between A and B? β. Can an activity B be executed before an activity A? χ. Does an activity B has to be executed after an A?

The proposed disambiguation method is based on these three questions and a Decision Table, as reported below. By answering these simple yes/no questions the user will be driven to clarify the intended meaning of the BR prec(A,B), by selecting it among possible alternative meanings. Table 1 represents the mapping from answer combinations to possible meanings.

In the next section we will show the impact of BR onto BPS in relation to the intended meaning.

Impact of BR onto BPS

As anticipated the goal of this paper is twofold: to support the business expert in clarifying the intended meaning of a rule (when its interpretation is ambiguous) and verifying which BPs in a repository are not consistent with the rule. In the previous section we addressed the first objective, here we address the latter. To this end, we consider an example of a BPS fragment and analyse the impact that the constraint prec(A,B) has on it. Note that our approach is inherently different from BP instance based approaches (e.g. that in [START_REF] Van Der Aalst | DecSerFlow: Towards a Truly Declarative Service Flow Language[END_REF]), since we only address the intensional level, i.e., BP schemas. Note also that our approach can be even if some decision nodes are not fully specified (i.e., as AND, OR, XOR), although more detailed and precise information about BR violation can be inferred when decision nodes are specified.

Testing BP consistency to BRs

Table 2 shows the validity of a process schema for each of the six different semantics of the constraint "A precedes B" considered above. We assume that in order to be valid a BP must satisfy the rule for all its possible execution (instances). In the first column an example of business process schema is shown with two (generic) decision nodes. The possible specification combinations for the decision nodes are listed in the second column, in particular:

• AND: The presence of an AND operator creates a non determinism in the process execution. In fact, it is not possible to determine a-priori the execution order of two activities located on two parallel paths. • XOR: In this case the two branches are mutually exclusive and the resulting logs will be constituted by the activity sequences of either one or the other branch.

• OR: The semantics of the OR decision node is the most articulated since the resulting logs is the union of the two previous cases.

The third column is organised in six sub-columns: one for each meaning that the natural language sentence "A precedes B" can assume, more precisely: The row-column intersections show the validation results corresponding to the combinations of decision node specifications and sentence meanings, namely:

• V: Every instance of the schema validates the constraint.

• N: No instance of the schema validates the constraint.

• S: Some instances of the schema doesn't validate the constraint. An example of BR to be tested on this BPS is the following: the activity of receiving a quotation must precede that of issuing a Purchase Order.

In order to disambiguate the BR we apply the decision table method presented above and we assume, for example, that the three yes/no answers of the table identify the Alternate Precedence (4) as the intended BR meaning. By analysing the consistency table for this BPS, we can infer that a path is inconsistent and some BP instances may be invalid. In particular the BPI can violate the specified BR if the quotation is not accepted. In general the management should therefore be promptly alerted that some modifications to the BPS, to make it consistent with the BR are required, sometimes could also happen that the management comprehend that the BR describes no more the reality of the company and it should be updated. In Figure 3 the branch arising the problem is highlighted.

Conclusions

In this paper we have focused on some important issues related to BP evolution, in particular to changes of the enterprise organization and operations strategy, which can be captured by business rules (BRs). We have presented an ontological approach, where BPs and BRs can be formally represented in a unified context and their consistency checked and maintained by means of well-established tools (e.g. theoremprovers on decision tables). Our contribution is twofold. Firstly, we have illustrated a method for the disambiguation of BRs having multiple possible interpretations, based on decision tables and simple natural language questions. Secondly, we have proposed an approach for identifying the processes in a BP repository that have become inconsistent after some BR change (update or insertion of some new ones, that require appropriate modifications in the inconsistent BPs), and supporting BPS, evolution to reestablish the overall consistency. This truth maintenance process can be applayed also to partially specified BPS, say BPS Sketches. Then starting from a BPS sketch, with undefined decision nodes, and a BR, it is possible to consistently completing the BPS with the decision nodes appropriate for the selected BR interpretation. Our future studies will be focused on providing a method for the creation of a minimal set of questions to disambiguate a BR, and a general technique for updating the whole BPs in relation to the expressed BRs.

Fig. 1 .

 1 Fig. 1. A simple BPS diagram. The execution of the BPS in Figure 1 will produce one of the following instances, depending on the kind of branching: 1) In case of an AND branching: bpi AND = {<a,b,c,d,e>, <a,c,b,d,e>, <a,b,d,c,e>} 2) In case of an OR branching: bpi OR = {<a,b,c,d,e>, <a,c,b,d,e>, <a,b,d,c,e>, <a,b,d,e>, <a,c,e>} 3) In case of a XOR branching:bpi XOR = {<a,b,d,e>, <a,c,e>}. Please note that an activity instance is registered in the log at the moment of its completion. Therefore prec(b,c) may hold, even if the activity instance c has started before b, because c execution may take longer, causing c completion to follow that of b.

Fig. 2 .

 2 Fig. 2. A Purchase Business Process.

Fig. 3 .

 3 Fig. 3. The highlighted problem in the precedent Purchase Business Process.

Table 1 .

 1 Decision Table to disambiguate the BR "A precedes B".

A complete specification of the BPAL ontology framework falls outside the scope of this paper, can be found in[START_REF] De Nicola | An Ontological Approach to Business Process Modeling[END_REF].

The values obtained (V, N, S) can be effectively used to support the BP designer in updating and refining the BP schema, by highlighting the inconsistencies and providing warnings for potentially inconsistent situations. Note that in 5 out of the 6 possible BR interpretations an inconsistency can be detected, even if both decision nodes remain unspecified. Conversely, when considering the first interpretation, the consistency can be verified in some cases, even if only one of the two decision nodes is specified.

A practical example

In Figure 2, we present an example of a BPMN process (realised by using the Intalio Editor Tool [START_REF]Intalio Business Process Management Suite[END_REF]). This process deals with a procurement scenario; the two pools are two different organizations performing the roles of Buyer and Supplier. The Buyer sends the Request for Quotation (RFQ) to the Supplier which replies sending back a Quotation. Afterwards, the Buyer analyzes the Quotation and, if satisfied, sends the Purchase Order (PO) to the Supplier, otherwise, the Quotation is rejected. Invoicing from the Supplier and Payment from the Buyer concludes the process.

The illustrated BPMN process can be represented in BPAL as follows: act(sendingRFQ), act(processingRFQ), act(sendingQuotation), act(receivingQuotation), act(issuingPo), act(processingPo), act(invoicing), act(payingInvoicing), act(rejectingQuotation), prec(sendingRFQ, processingRFQ), prec(processingRFQ, sendingQuotation), prec(sendingQuotation, receivingQuotation), prec(recivingQuotation, quotationAccepted), prec(xdec, rejectingQuotation), prec(xdec, issuingPO) xdec(quotationAccepted, issuingPO), prec(issuingPO, processingPO), prec(processingPO, invoicing), prec(invoicing, payingInvoice).


Mario Lezoche

Antonio De Nicola
email: denicola@iasi.cnr.it

Tania Di Mascio

Francesco Taglino
email: taglino@iasi.cnr.it

Semantic Lifting of Business Process models

Keywords: business process, ontology, semantic alignment, bp design

Business Process modeling is constantly acquiring attention in modern enterprises. Today, BP editor tools support modelers in building correct diagrams only from the syntactic point of view. Enriching them with ontologies may bring many advantages, that go from the possibility of applying advanced reasoning techniques, aimed at the identification of contradictions and mistakes in the model specification, to the possibility of organizing BP models repositories, with advanced search and retrieval facilities. Finally, semantic technologies can substantially help the solution of the Business/IT alignment problem. Semantic enrichment of a BP can be achieved by representing a BP, or part of it, with an ontology-oriented formalism (semantic lifting) and mapping it to a reference ontology. In this paper, we present the basic elements of a Business Process Ontology framework (OPAL+BPAL) and its concrete representation according to an OWL syntax. Finally, we show how it is possible to generate an OWL representation of a BPMN diagram.

Introduction

Traditionally, Business Process Management (BPM) has been perceived as divided into two distinct levels:

• BPM as a management discipline that supports business organizations in standardizing and continuously optimizing operational processes that have a large impact on achieving corporate performance goals; • BPM as a technology (for software production) providing IT organizations with a set of tools to model, deploy and execute processes that include human and system tasks (as, e.g., workflows) or that span across different business applications and require a broad set of integration capabilities (as, e.g., messaging, transformation, adapter technology; known as EAI -Enterprise Application Integration.)

Both cases represent challenging activities that require highly skilled Business and IT experts, respectively. However, today in the two areas, the experts operate without a systematic interaction and cooperation, causing the well known problem of Business/IT alignment. In fact, one key problem is the alignment of different tools, methods and sometimes even jargons used by the two communities (business and IT experts).

To reduce the gap between these two areas, BISOGNO DI UN SUPPORTO SOCIALE ONTOLOGIA COME SUPPORTO SOCIALE in quanto prodotto risultante da una collaborazione di un gruppo multidisciplinare e mirato al raggiungimento di un consenso condiviso.

In our contest, ontology-based semantic technologies appear to be a valid option. In fact, such technologies are based on the usage of reference ontologies, which allow a social playground for the two expert communities to be built.

With respect to the IT community, the application of ontologies and semanticsbased solutions is already a promising reality, since several initiatives are gaining consensus. They are mainly focused on web service discovery and composition (i.e., WSMO [START_REF] Roman | D2v1.3. Web Service Modelling Ontology (WSMO)[END_REF], SAWSDL [21], and OWL-S [START_REF] Owl-S | Web Ontology Language for Web Service) 1.2 Release[END_REF]). The business community is starting now to consider it.

In this paper we focus on the business level. We aim at supporting business process production, reengineering and maintenance with the adoption of SUPPORTO SOCIALE FORNITO DALL'ONTOLOGIA semantics-based technologies. The preconditions to our solution are the existence of a business ontology (e.g., [EO],

[TOVE], [PHMIT]) gathering structural and procedural knowledge of an enterprise, and the possibility to represent a business process into an ontology language. In particular, in this paper we concentrate on this last aspect, referred to as semantic lifting, aiming at ALLINEARE UN DIAGRAMMA/PROCESSO BPMN RISPETTO AD UNA RAPPRESENTAZIONE ONTOLOGICA transforming a business process, modeled using BPMN (Business Process Modeling Notation) [START_REF]Business Process Modeling Notation Specification[END_REF], in OWPAL. OWPAL is the OWL representation of the OPAL+BPAL [START_REF] D'antonio | Formalizing the OPAL eBusiness ontology de-sign patterns with OWL[END_REF] [3] ontology modeling framework. In details, the envisaged advantages of the semantic lifting (SEMANTIC ALIGNMENT) are listed below.

• Support to business process design by verifying semantic alignment of a business process with respect to a reference ontology. The semantic alignment can be achieved by performing consistency checking through the use of a reasoning engine, like RACER or PELLET. • Support to business process reengineering providing suggestions to business experts during the design phase of a BP. In fact a business expert can be supported in finding, for instance, alternative elements of a business process by performing semantic search and similarity reasoning over the business ontology. • Support to business process maintenance by automatically checking the alignment between one of more business processes with the business ontology when the latter is modified. This provides strong benefits since, for instance, a change in the company organization, could affect many business processes that need to be manually checked. By using an ontology, the manual changes are limited to the business ontology since its alignment with business processes can be automatically verified by performing consistency checking.

Furthermore our proposal is not specific for a particular business process language or ontology language. In this paper we focus on BPMN and OWL but our approach can be easily extended to other languages.

The rest of the paper is organized as follows: In Sections 2 we present the related works. In Section 3 the main constructs of the BPMN modeling notation are presented. In Section 4, we focus on the OPAL+BPAL ontology modeling framework. In Section 5 the semantic lifting (SEMANTIC ALIGNMENT) from a BPMN diagram to OWPAL is described. Finally in Section 6 we present some conclusions.

Related works

In the last years there has been an intense research activity on methods for process ontologies. We here briefly report on: OWL-T, OWL-P, and oXPDL. OWL-T [START_REF] Tran | OWL-T: A Task Ontology Language for Automatic Service Composition[END_REF] (T stands for Task) is a method for coding an ontology in OWL, expressing user demands (tasks) at a high-level of abstraction, without dealing with the technical details of the underlying infrastructure. The OWL-T meta-model is characterized by a hierarchy of task types: Atomic, Composite, Simple, Complex. Each task is described in terms of properties and components. In particular, functional properties allow inputs, outputs, preconditions, post-conditions, preferences and effects to be represented. For its characterization, OWL-T is particularly suitable for generation of executable processes. The OWL-T developers aim to transform tasks into executable processes by employing some automatic methods of service composition. OWL-P [START_REF] Desai | OWL-P: A methodology for Business Process development[END_REF] proposes an approach for business process modeling and enactment, based on a combination of protocols and policies. The key idea is to capture meaningful interactions as protocols. OWL-P is an ontology framework for protocols coded in the OWL. OWL-P describes concepts such as roles, messages exchanged between the roles, and declarative protocol rules. The main computational aspects of protocols are specified using the Semantic Web Rule language (SWRL) [START_REF] Horrocks | SWRL: A semantic web rule language combining OWL and RuleML[END_REF] for defining rules which allows implication rules over entities defined as OWL-P instances to be specified. Both the two initiatives above are mainly concentrated on the generation of executable business processes and do not appear semantically aligned with BPMN as required for formal verification of the related BP. oXPDL [START_REF] Haller | oXPDL: a Process Model Exchange Ontology[END_REF] is a process interchange ontology formalism based on the standardized XML Process Definition Language (XPDL) [START_REF]Workflow Standard Process Definition Interface -XML Process Definition Language[END_REF]. oXPDL explicitly represents the semantics of a process model defined according to XPDL in a Web ontology language. oXPDL also focuses on reusing and integration of existing standard and ontologies such as SUMO [START_REF] Niles | Towards a standard upper ontology[END_REF], eClassOWL [START_REF] Hepp | Products and services ontologies: A methodology for deriving owl ontologies from industrial categorization standards[END_REF], RosettaNet [START_REF] Haller | Towards a complete SCM Ontology -The Case of ontologising RosettaNet[END_REF] and PSL [START_REF] Gruninger | Ontology of the process specification language[END_REF].

With respect to OPAL+BPAL, oXPDL, as a process interchange formalism, is mainly for interoperability issues, e.g., integration of different BP management tools, than to actually support BP design activities.

BPMN aims at standardizing business process modeling notations in order to simplify the process organization, and the communication among business users, customers, suppliers, and process implementers. To achieve this result is introduced a graphical notation with an intuitive semantics dedicated to business process modeling, and some basic syntactic rules, e.g., sequence and message flow rules.

Figure 1 shows the basic categories of BPMN constructs: flow objects, swim-lanes and connecting objects. In this section, we define the BPMN modeling constructs, categorized according to the BPMN Specification (see [START_REF]Business Process Modeling Notation Specification[END_REF] for details), involved in the BPMN example process. We use this example as key reading of the transformation from BPMN schemas to OWPAL formalism in order to align It is worth noting that, from a graphical point of view, a process is not a graphical object. It is a composition of graphical objects representing BPMN constructs.

Flow Objects represent the business process behavior by using event, activity, and gateway. An event is something that "happens" during the course of a business process. An activity is a generic term representing the work performed within a company. In BPMN, an activity can be atomic or compound. In particular, BPMN activities are sub-process and task. A gateway is a modeling construct used to represent the interaction among different sequence flows; moreover they diverge and/or converge within a process. When sequence flows arrive at gateway, they can be merged together on input and/or split apart on output. Gateways can define all the types of business process sequence flow behaviour: decisions/branching, merging, forking and joining. In order to depict these behaviours, the BPMN uses the following gateway: exclusive decision/merge XOR, inclusive decision/merge OR, parallel fork/join AND, and complex decision/merge. Swimlanes are used to model any relevant entity, able to activate or perform a process. Swimlanes aggregate organization or specific units, they group the corresponding BP modeling constructs: pool and lane that allow partitioning activities according to performers.

Connecting Objects represent the possible connecting ways from flow objects to each other or to other information. Main connecting objects are sequence flow, message flow and association. The sequence flow is used to show the process activities order. Their source and target must be events, activities or gateways. The message flow is used to show the flow of messages between two participants (two different pools) of a process.

In order to illustrate how the BPMN diagram is transformed in OWPAL, we present (see Figure 2) the BPMN process example (built with the Intalio Editor Tool [START_REF]Intalio Business Process Management Suite[END_REF]). This process deals with a procurement scenario; the two pools are two different organizations performing the roles of Buyer and Supplier. The Buyer sends the Request for Quotation to the Supplier which replies sending back a Quotation. Afterwards, the Buyer analyzes the Quotation and, if satisfied, he/she sends the Purchase Order to the Supplier, otherwise, the Quotation is rejected. Invoicing from the Supplier and Payment from the Buyer concludes the process.

An ontology-based framework for business modeling

As mentioned in the Section 1, our approach to validate BPMN diagram semantics entails a contrast between the BPMN diagrams in OWPAL format and the OPAL+BPAL ontology in the same OWPAL format. In this section we briefly describe the OPAL+BPAL ontology framework. In essence, OPAL provides designer with the constructs necessary to model a static view of the reality. Here also processes are modeled, but only from a structural point of view. BPAL is mainly concerned with operational aspects of processes. Starting from the OPAL knowledge, BPAL is able to model control and data flow in business processes.

OPAL: an ontology framework for structural modeling of business domains

OPAL (Object, Process, Actor modeling Language) [START_REF] D'antonio | Formalizing the OPAL eBusiness ontology de-sign patterns with OWL[END_REF] is an ontology framework aimed at supporting business experts in building a structural ontology. OPAL upper level concepts are functors (e.g., Actor), and arguments represent individual variables and constants (e.g., "Peter Smith"). OPAL atoms are unary and relational predicates. OPAL business ontology is built by defining concepts as specialization of unary predicates (e.g., Organization isa Actor) and relating the defined concepts by using relational predicates (e.g., Employee works_in Organization). In the following, the main OPAL predicates are presented.

Unary predicates (u_pre)

• proc(_pr)process; it aims at modelling atomic or structured activities;

• ar(_ar)business actor; it aims at modelling any relevant entity of the domain able to activate, monitor, or perform processes; • obj(_obj) -a business object; it aims at modelling a passive entity, on which a process operates; • bod(_bod) -a business object document; it is a specialization of business object;

• aa(_aa)atomic attribute, for example Street Name;

• ca(_ca)complex attribute; for example Address. It is defined as an aggregation of lower level complex attributes and/or atomic attributes.

Relational predicates

• isa(_upre11 , _upre2)specialization relation; it allows building specialization hierarchy, supporting a top-down refinement when applied to unary predicates (_upre1 is a specialization of _upre2); • pof(_upre1, _upre2)part-of relation; it allows a top-down decomposition of concepts when applied to unary predicates (_upre1 is part of _upre2); • ndrel(_upre, _upre, _relName)named association; it is defined between two unary predicates; • udrel(_upre, _upre)unnamed association; it is defined between two unary predicates; • pred(ca| aa, ar|obj)association; it is defined between an attribute and a concept.

OPAL example for the purchasing application

In the following we present a portion from the OPAL example about purchasing application (see the boxed fragment in Figure 1):

Organization(_x), ar(_x), isa(Organization, ar), RejectingQuotation(_y), proc(_y), isa(RejectingQuotation, proc) IssuingPO(_z), proc(_z), isa(IssuingPO, proc).

BPAL: an abstract language for BP Ontologies

The BPAL atoms [START_REF] De Nicola | An Ontological Approach to Business Process Modeling[END_REF] are predicates where functors represent ontological categories, and where arguments are typed variables representing concepts in the Core Business Ontology (CBO), built according to the OPAL framework [START_REF] D'antonio | Formalizing the OPAL eBusiness ontology de-sign patterns with OWL[END_REF]. In the following, we analyze in detail BPAL predicates.

Unary predicates

The BPAL unary predicates are:

• bp(_bp) -a business process;

• bact(_act) -a business activity, element of business process;

• role(_rl) -a business actor, involved with a given role in one or more activities;

• dec(_bexp) -a generic decision point; its argument is a boolean expression evaluated to {true, false}; it is used in the preliminary design phases when developing a BP with a stepwise refinement approach; in later phases, it will be substituted with one of the specific decision predicates (see below);

Relational predicates

The BPAL relational predicates are:

• ev(_ev,_time,_bexp) -an event; its arguments are a boolean expression and a timestamp; • msg(_msg,_obj,_source,_dest) -a message, characterized by the content (_obj), a sending activity (_source), and a receiving activity (_dest);

• cxt(_listObj,_rl) -a context, represented by a collection of information structures, it is related to a role; • adec(_dec,_bexp), odec(_dec,_bexp) -decision points representing a branching in the sequence flow, where the following paths will be executed in parallel or in alternative, respectively • xdec(_dec,_bexp,_act) -a decision where the business activity _act will receive the control, depending if the boolean expression _bexp is true. • sort(_x, _y) -"a sort of", it represent a bridge between OPAL and BPAL; if _x is a BPAL role, then _y is an OPAL actor; if _x is a BPAL activity or business process, then, _y is an OPAL process; • prec(_act|_dec|_ev,_act|_dec|_ev) -a precedence relation among activities, decisions, events; • coop(_rl1,_rl2, …,_rln,_act) -roles involved in performed activities;

• perf(_rl,_act) -a relation indicating which role is dedicated to which activity • gen(_act,_obj), upd(_act,_obj), arc(_act,_obj) -indicating the business activity _act that can create, manipulate, archive the object _obj.

BPAL example for the purchasing application

In the following we present the BPAL example of the excerpt from the purchasing business process:

Buyer(_x),

Semantic lifting of BPMN constructs

In this section we analyze the main constructs of BPMN, providing for them a formal semantics based on the OPAL+BPAL ontology framework. This is referred to as semantic lifting. Table 1 presents an overview of the proposed semantic lifting of the main constructs of BPMN in terms of the OPAL+BPAL predicates. To actually build an ontology of a BP modelled in BPMN, we also need a concrete syntax. To this end, an OWL representation of the abstract OPAL+BPAL predicates is given. Such an OWL representation, named OWPAL, is reported in accordance with the N3 notation [18], which results more concise respect to the XML syntax of OWL. For the OWPAL representation, it is assumed that two namespaces, opal and bpal, exist where OPAL and BPAL keywords have been defined. The xsd namespace is where the XMLSchema types are defined. According to the table above, using the OWL/N3 syntax, a fragment from the example extracted by the Figure 2 is now represented.

As Anticipated, this code can be enriched with the ontology knowledge (including axioms) and fed to a reasoner to check the semantic validity

Conclusions

In this paper, the semantic lifting of BPMN diagrams to OWPAL has been presented. OWPAL is the OWL representation of the OPAL+BPAL ontology framework. The lifting aims at representing a BPMN diagram by using an ontology-based formalism in order to use ontology reasoning techniques for several activities as, for example, business process design and consistency checking, automatic BP maintainance. In particular, in the paper, the BPMN core construct and OPAL+BPAL ontology framework are presented and used to semantic enrich BPMN constructs. The proposed formalization uses predicates and Horn Logic to compactly represent them introducing OWPAL, a homogeneous OWL representation with the BP coding. Finally the BPMN example process is introduced in order to well appreciate the semantic enrichment from the BPMN model to OWPAL format.

Figure 1 :

 1 Figure 1: Hierarchy of BPMN modelling constructs.

Figure 2 :

 2 Figure 2: A Purchase Business Process realized with the Intalio Editor Tool.

Table 1 :

 1 Semantic lifting of main BPMN constructs

	BPMN Constructs	OPAL	BPAL	OWPAL (N3 notation)
			Flow objects
			Purchasing1(_y)	Purchasing a owl:Class;
		Purchasing(_x)	bp(_y)	rdfs:subClassOf opal:PROCESS Purchasing1 a owl:Class; rdfs:subClassOf
	Process	proc(_x)	isa( Purchasing1, bp)	bpal:BUSINESS_PROCESS rdfs:subClassOf
	e.g.: Purchasing	isa( Purchasing, proc)	sort( Purchasing Purchasing1,	[a owl:Restriction; owl:onProperty bpal:SORT; owl:allValuesFrom Purchasing]
			)
	activity (task)		IssuingPO1(_y)
		IssuingPO(_x)	bact(_y)
	e.g. IssuingPO	proc(_x)	isa( IssuingPO1, bact)
	activity (sub-process)	isa( IssuingPO, proc)	sort( IssuingPO1, IssuingPO
			)
				rdfs:subClassOf
				[a owl:Restriction;
				owl:onProperty bpal:IFTRUE;
				owl:allValuesFrom IssuingPO1 ]
			Connecting Objects
				_PayingInvoice a owl:Class
				rdfs:subClassOf
	sequence flow E.g.,		prec(_act|_dec| _ev, _act|_dec|_ev)	bpal:BUSINESS_ACTIVITY _Invoicing a owl:Class rdfs:subClassOf
	Invoicing PayingInvoice precedes		prec(Invoicing1, PayingInvoice1)	bpal:BUSINESS_ACTIVITY rdfs:subClassOf [a owl:Restriction
				owl:onProperty bpal:PREC
				owl:allValuesFrom _PayingInvoice]
			Swimlanes
		Organization(	Buyer(_y)	Organization a owl:Class;
	pool	_x)	role(_y)	rdfs:subClassOf opal:BUSINESS_ACTOR
		ar(_x)	isa(	Buyer a owl:Class;
	E.g. Organization	isa( Purchasing,	Buyer, role) sort(	rdfs:subClassOf bpal: ROLE rdfs:subClassOf [a owl:Restriction;
		ar)	Buyer,	owl:onProperty bpal:SORT;

IssuingPO a owl:Class; rdfs:subClassOf opal: PROCESS IssuingPO1 a owl:Class; rdfs:subClassOf bpal: BUSINESS_ACTIVITY rdfs:subClassOf [a owl:Restriction; owl:onProperty bpal:SORT; owl:allValuesFrom IssuingPO] gateway (XOR/OR/AND) dec(_dec,_bexp), adec(_adec,_bexp), odec(_odec,_bexp), xdec(_xdec_bexp, _act) QuotationAccepted(_ xdec, "YES", bact(IssuingPO1)) isa(QuotationAccepte d, xdec) QuotationAccepted a owl:Class; rdfs:subClassOf bpal:XDEC rdfs:subClassOf [a owl:Restriction; owl:onProperty bpal:BEXP; owl:allValuesFrom [a owl:Class owl:oneOf (:YES)]]

_upre. is a variable that refers to the generic unary predicate.