1 BPMO Requirements Analysis and Design
Zhixian Yan1 , Emilia Cimpian1 , Manuel Mazzara2 , Michal Zaremba1

Digital Enterprise Research Institute
Leopold − F ranzens U niversit¨
at Innsbruck

Distributed Systems Group
Inf ormation Systems Institute
V ienna U niversity of T echnology


This deliverable is concerned with Semantic Business Process Management (abbreviated as SBPM), especially its cornerstone Business Process Modeling Ontology (BPMO).
Basically, the document focuses on the requirements analysis and design of BPMO, which
is considered as the semantic description framework for business process in the SemBiz
project. To determine the description requirements for business process management, we
analyze business use cases from the industrial partners and abstract a generalized process
scenario. For realizing the determined requirement list, we propose the comprehensive
BPMO framework, and finally make it feasible with the extension of the semantic Web
service description framework WSMO. Although the main framework for BPMO has been
determined, some details may be modified in the following period, based on the BPMO real
implementation with the use cases provided by the industrial partners.


List of Abbreviations

Architecture of Integrated Information Systems
Abstract State Machine
Business Process Execution Language
Business Process Execution Language for Web Services
Business Process Management
Business Process Modeling Initiative
Business Process Modeling Language
Business Process Modeling Notation
Business Process Modeling Ontology
Business Process Ontology
Business Process Query Language
Business Process Reengineering
Knowledge Interchange Format
Web Ontology Language
OWL for Services
Process Specification Language
Semantic Business Process Management
Semantically-Enabled Service-oriented Architecture
Service-Oriented Architecture
Semantic Web Services Framework
Semantic Web Services Initiative
Semantic Web Services Language
Semantic Web Services Ontology
Unified Modeling Language
Workflow Management Coalition
Web Service Choreography Description Language
Web Service Choreography Interface
Web Service Conversation Language
Web Service Description Language
Web Service Modeling Framework
Web Service Modeling Language
Web Service Modeling Ontology
Web Service Modeling Tool
Web Service Modeling eXecution environment
Yet Another Workflow Language


. . .3 3 4 5 Requirements Analysis for BPMO 13 3. . . 10 2. . . . . . . . . . . . . 5 2. . . . . . . . . . . . . . . . .3. . 19 4. . . . . . . . . . . SESA . . . . . . . . . . . Transaction Logic . . . . . . . . 3 1. 8 2. . . . .1 Non-Semantic Process Modeling Approaches . . . . . . . . . . 10 2. . . . .2 Abstract State Machine .2. . . . . . . . . . .2 BPMO UML Diagram . Pi-Calculus . . . . . . . . . . .1 Concepts Involved in Business Processes . . . . . . . . . . 10 2. . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. . . . . . . . . . . . . . 11 2. .3. . . . . . . . . . .2 Business Process Modeling Ontology . . .3 Semantic Web Services. . .2 Functional Requirements for Process Description . . . . . . . . . . .3 Process Algebra. . . . . . . . . . . . . . . . . .1 Workflow. .Contents 1 2 Introduction 3 1. . . . . . . .2. . . . . . . . . . . . . 19 4. 9 Academic Foundations of Process Modeling . . . . . . . . . . .1 Why Semantic Web Service for BPMO . . . .2 Why WSMO for BPMO . . . . . . . . . . . . .3. . . .1 Semantically-Enhanced Workflow Model . . 4 State-of-the-Art 5 2. . . . . . . .2 Semantic Business Process . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. . . . . . . . Business Process Reengineering and Management . . . . . . . . .1 Petri Net . . . . 11 2. . . . . . . . . 14 3. . . . . . . . . . 25 4. .2. . . . . . . . .2 Web Services. . . . . . . . . . . . . . . . . 5 2. . . . . . . . . .1 Semantic Business Process Management . . . 17 BPMO Design 19 4.1. . . . . . . 6 Semantic Process Modeling Approaches . . . . . 13 3. . . . . . . 26 4. . . . . . . . . . . . . . . . . .3. .3. . . . . . . . .2. . . . . . .5 AI Model . . . . . . 25 4. . . . . . .3. . . 8 2. . .3. . . . . . . . . . . . .3. . . . . . . . 14 3. . .3 How to Extend WSMO for BPMO . .2 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. 8 2. . . . . . . . . . . .2.2 Process Description Requirements . . . . . . . . . . Service-Oriented Architecture (SOA) . . .3 Nonfunctional Requirements for Process Description . . . . .1 Process Scenario . . . . . . . . .3 BPMO Element Definition . . . . . . .1. . . . . . . . . . . . 26 Conclusions and Future Steps 30 . . . . . . . . .4 Temporal Logic.1 Extension Highlights . . . . . . . . . . . . . . . . . . . . . .

we provide an overview of the state of the art on business process modeling approaches and their influence on the emerging semantically-enhanced business process management. With the analysis of considered approaches and business scenarios presented. In the second section. In the first section. Finally. The extension of Web Service Modeling Ontology (WSMO) to realize BPMO will be addressed in the last main section of this deliverable based on the requirements previously extracted. 2 . giving the reader some additional information on the content of the sections in such a way he could read only those parts relevant for his specific purposes. the third section determines the description requirements for SBPM. we add some conclusive remarks and future directions.Outline This outline is intended to partially integrate the index. a general introduction on Semantic Business Process Management (SBPM) and its cornerstone Business Process Modeling Ontology (BPMO) is given.

e. SBPM in the SemBiz project has the following objectives: • develop an exhaustive semantic description framework for business processes that allows BPM by business experts on a higher level of abstraction as well as support for automated handling and execution of business processes on the technical level. editing.1 Introduction In this section. discovering. Figure 1 gives an intuitional demonstration of the ”bridging-gap” role of SBPM between business level and technical level [23] Figure 1: Idea of Semantically Enabled Business Process Management To really bridge the gap between business perspective and technical perspective. and composing semantically described business processes. • develop semantically enabled core facilities for novel aspects of BPM that can be supported by semantic descriptions.: browsing. the SemBiz project (fully named ”Semantic Business Process Management for flexible dynamic value chains”) proposes Semantic Business Process Management (SBPM). 1. discovery and composition of processes. especially the main idea of Semantic Business Process Management and its cornerstone Business Process Modeling Ontology. • develop a prototypical tool suite that utilizes the techniques developed for semantically enabled BPM and allows business experts to handle and manage business processes. i. we give a general introduction for the context of the SemBiz project. which results in a gap between the business perspective and the technical level for IT-supported business process execution. ranging from graphical workflow design tools to complex IT systems for automated execution support of business processes. Numerous technologies and tool suites are providing BPM support. 3 . which enables BPM by business people rather than IT experts and allows scaling up to a new level of complexity in querying.1 Semantic Business Process Management Business Process Management (BPM) refers to managing IT-supported business operations from a business expert’s perspective rather than from a technical perspective. in order to bridge the gap between the business and the technical perspective. However. Therefore. the degree of automation and support for the business experts perspective in existing BPM technologies is still very limited.

we can realize that the sematic description for business processes plays a crucial role in the whole SBPM proposal. Basically. the BPMO framework can be considered as the starting point and cornerstone for the SBPM vision.• test and evaluate the usability and applicability of the developed tools in a real world use case scenario in the telecommunication sector. • allow recursive definition and specification of the BPMO elements. In the SemBiz project. • determine specification languages for BPMO. and composition of business processes. additional constructs are required for the BPMO with respect to the business level BPM facilities to be supported: Goals and Queries as the underlying notions for semantically enabled querying. The detailed BPMO framework will be defined in the deliverable and improved in the future period. Ontologies shall be used as the underlying data model in order to ensure semantic interoperability and advanced information processing. 4 . and Mediators for handling possibly occurring mismatches between business processes and other resources needed for executing these.2 Business Process Modeling Ontology From the previous general introduction of SBPM. • define design strategies of BPMO. one of the three main objectives is to define a semantic business process description framework. 1. Basically. Besides an adequate semantic description model for business processes themselves. meaning that all element descriptions as well as all information interchanged are based on ontologies. there are at least following four core tasks for the BPMO framework: • determine requirements of semantic business process descriptions. discovery. The aim of BPMO is to define a precise and sufficient semantic description model for business processes that encompasses business process description on a higher level of abstraction in order to enable business level BPM facilities as well as connection to the technical implementation level for supporting automated execution of business processes. named Business Process Modeling Ontology and abbreviated as BPMO.

such as Web service choreography. 2.joops. there are several studies about web service cooperation. To fully support process interoperability.wfmc. and then gradually evolve into Business Process Reengineering (BPR) and Business Process Management (BPM). Workflow in WfMC is defined as: 1 http://scoop.2 State-of-the-Art In this section. including both non-semantic and semantic relevant approaches. traditional workflow technology has been researched for many years. we consider that getting familiar with the current approaches is one of the pre-requisites in providing a solid. well-documented set of requirements. orchestration and conversation. referring to workflow and Web services. language-based process description is another main focus.org/ 2 5 .com.au/ http://www. such as the emergence of SCOOP1 (developed by Michael Zisman) and OfficeTalk2 (developed by Skip Ellis and Gary Nutt). modeling language Business Process Modeling Language (BPML). for the description and execution of processes.cim. Besides the relevant industrial standards. several Web service approaches can be used as building blocks. 2.1. In August 1993 the Workflow Management Coalition (WfMC)3 was founded. which provides more powerful description capabilities and efficient process modeling and management strategies. such as Unified Modeling Language (UML) diagram.1 Workflow. There are many approaches supporting process modeling. and gradually improved and evolved into business process reengineering and business process management. Business Process Reengineering and Management About process modeling. we will briefly survey the state of the art of process modeling technologies. The graphical process modeling can be traced back to workflow. Business Process Modeling Notation (BPMN) and Event-driven Process Chains (EPCs). Besides the graphical modeling tools. which can be traced back to some office automation systems developed in 1970s. Workflow Workflow [52] has a long research history. we further provide some concentration on the academic foundations for process modeling. Although providing a state of the art analysis is not one of this deliverable’s objective. among which Business Process Execution Language for Web Services (BPEL4WS) is one of the representatives. including workflow and BPM. querying language (BPQL) and executing language (BPEL). aiming to standardize the process research. and in particular.com/ 3 http://www.1 Non-Semantic Process Modeling Approaches The focuses of traditional process modeling are pervasively on providing graphic-based tools to design processes.

BPM has a process-centric controlling layer. but the synthesis and extension of all these technologies and techniques into a unified whole. Aalst et al. which are not to make non-value adding works but to automate and re-engineer existing works. control-flow patterns. BPM is business-driven covering more than a set of process related technologies. such as the efficient design. workflow management systems are responsible for defining. Process modeling became more mature as the evolution from workflow to BPM took place. quality documentation and the effective change management.1. which is not business-process reengineering. to support higher-level integrations. which was yielded from the claim in the Harvard Business Review by Michael Hammer in 1990 [21]. Business Process Reengineering (BPR) Different from workflow. especially some grounding technologies. in whole or part. SOA further takes services as the building blocks for system integration architecture for reusing and automating services in software engineering. Besides the documentation (or message)-centric capability of workflow. BPR is further concerned with automating and re-engineering existing works. The claim was about companies’ focusing issues. 2. Enterprise Application Integration (EAI). workflow management or another packaged application. Howard Smith called BPM the third wave [48]. 6 . The main difference between them is their perspectives: workflow is a purely technical perspective to model process flow. The workflow patterns can be used for the analysis. many existing workflow techniques. Business Process Automation (BPA) and Business Process Integration (BPI). to maximize enterprise efficiency and agility. BPR is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. executing and monitoring the workflow. especially process design. Service-Oriented Architecture (SOA) Web service research also provides some process modeling supports. BPM encompasses a robust Workflow.e. i. whilst BPM pays more attention on business perspective. In a nutshell. during which documents. Therefore. It’s a fundamental and radical approach by either modifying or eliminating non-value adding activities. B2B integration and concepts such as Business Process Re-engineering (BPR). enterprise application integration. focusing on message sequences. Business Process Management (BPM) Besides process redesigning and automating. information or tasks are passed from one participant to another for action. BPM is concerned with much more than workflow and BPR.The automation of a business process. comparison and reuse of workflows.2 Web Services. according to a set of procedural rules. data patterns and resource patterns. can be reconsidered as the basis for process reengineering [25]. To achieve the fully-fledged automation vision. Furthermore. have surveyed the patterns and assigned them to three categories [51].

Web service can be seen as the building blocks for the process technologies in current industrial and academic process world. Combined with Web services.org/TR/wscl10/ http://www. and Integration (UDDI). BPM could become a new breed of software automating processes both intra. published. coordinated and configured using XML artifacts for the purpose of developing distributed interoperable applications” [14].and inter.w3. such as service coordination. loosely coupled. self-contained web-enabled application. A common understanding of SOA is that it expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users7 . and describes how those Web services can interact with each other to attain a more comprehensive and integrated ”service” [4]. To express it more clearly. There are several corresponding languages. Discovery. BPEL4WS is a representative of such convergence. The three standards cornerstones are respectively taking charge of service communication protocol. Thus. but difficult to extend to the enterprise. but lacks the ability to turn those services into an agile.org/TR/wsci/ 6 http://www. Orchestration provides a central process acting as the controller of several involved Web services. we briefly discuses the two kinds of service interoperation interfaces service orchestration and service choreography. 4 http://www. BPEL4WS has emerged as the de-facto standard to define and manage business process activities and business interaction protocols for collaborating Web services. Some existing works on service interoperability.wikipedia. With the combination of BPM. especially in the final process execution duration. A commonly-recognized definition of Web services is: ”Web service is a platform-independent. For the process technologies like workflow and BPM. Web Service Description Language (WSDL) and Universal Description. There are three cornerstones for attaining interaction between different programs: Simple Object Access Protocol (SOAP). SOA without BPM is useful for creating reusable and consistent services. which is described. which becomes industrial and the de-facto standard for business process execution. Web Service Choreography Interface (WSCI)5 and Web Service Choreography Description language (WS-CDL)6 . such as Web Service Choreography Language (WSCL)4 .w3. can further demonstrate the building block role of Web services for the process technologies. supporting communication between applications. Service-Oriented Architecture (SOA) SOA is a next evolutionary step for companies and allows both internal and external system integration as well as the flexible reuse of application logic through the rearrangement of Web services [37]. competitive enterprise [8]. Web services play a crucial role. discovered. aiming at a perfect combination for enterprise computing [1]. the Web service technologies had significantly boosted the Web to dynamic Web. SOA can get a more business-enhanced perspective along the technical lines. Choreography utilizes a set of message exchanging between the participating services to consume a process [40].w3. service conversation and service composition. As mentioned. BPM without SOA is useful for building applications.org/wiki/Service-oriented architecture 5 7 .enterprises.Web Services A Web service is a service that is available over the web.org/TR/ws-cdl-10/ 7 http://en. service description and service discovery.

To achieve this semantic interoperability. aims to develop the architecture for Next Generation Grids. which combines semantic Web service technologies 8 http://www. can be semantically aligned to support (semi-)automatic interconnectivity and reduce the communication efforts [13]. business processes and Web services. the goal of which is workflow interoperability: to understand. and schedule workflows in different languages [19]. PSL acts as a modular.m3pe. Processes modeled by Petri-Net and represented in the OWL language. aims to enhance Petri-net process model with semantic descriptions. In contrast to the previous section. a new ontology OWL-WS (OWL for Workflow and Services) is proposed to support semantic workflow and Web service description [7]. The first process ontology named BPO. PSL [10] is intended to be a commonly recognized process representation language that is pervasive to all business and management applications. and powerful enough to represent the process in any given applications. together with the background ontology modeled in UML and translated into OWL.1 Semantically-Enhanced Workflow Model There is not much research on the semantically enhanced workflow model. which can further facilitate process composition. there are two distinguished researches referring to semantic business process ontology.uni-karlsruhe. then. 2. from Karlsruhe AIFB11 .2. The second process ontology called BPMO. simulation and validation [29].2 Semantic Business Process To the best of our knowledge.2.edu/kif/dpans. we will discuss the considered semantic approaches according to the reference division of workflows.html 11 http://www. To attain such goal. 2. semantic process methodologies are still in their infancy stage.org/ 10 http://logic.nextgrid. to generate choreography interfaces.org/ http://www. there are two basic steps: first.aifb.stanford. reason. The NextGRID9 project. We will briefly address two distinguish research projects and the Process Specification Language (PSL).2. a more comprehensive exisiting one. is the considering ontology to realize SBPM. The PSL ontology can be described by KIF (Knowledge Interface Format)10 . extensible first-order logic ontology capturing concept requirements and business process specification. the researchers on this project have further proposed m3po (multi meta-model process ontology) as the linking ontology for internal and external business processes [20]. to map from internal workflow models to the intermediary formal mode. Based on OWL-S. Besides those workflow-based ontologies for individual projects.2 Semantic Process Modeling Approaches Compared with so many non-semantic approaches for business processes. proposing a workflow-centric Grid Virtual Infrastructure Model. Most of the works focus on the semantic description or ontology extension of workflow. The project m3pe8 is referring to workflow ontology extension. Recently.de/Publikationen/Forschungsgebiete/viewForschungsgebietenglish?fgebiet id=124 9 8 .

WSMF: WSMO/WSML/WSMX Web Service Modeling Framework (WSMF) was provided as a fully-fledged framework to model semantic Web services [17].3 Semantic Web Services. service profile.org/services/swsl/ 13 9 .org/wsml/ 15 http://www. sBPMN Ontology and sBPEL Ontology)[22] [24].wsmo. the properties presents.daml. and supports of Service link to the above three core ontologies respectively. the BPMO ontology framework proposes a set of ontologies and formalisms. from a collection of information into a distributed device of computation. Service profile presents ”what a service does”.e. This new Web will be enhanced in both semantic and behavior level.Architecture of Integrated Information Systems) [23].(WSMO in particular) and BPM methodologies (especially ARIS12 .org/ 14 http://www. which serves as an organization point of reference for declaring Web services.org/ 16 http://www.daml. a set of corresponding technologies has been developed. To finally enable the framework.org/ 17 http://www. involving basic ontology UPO (Upper-Level-Ontology) and three primary extension ones (sEPC Ontology. specifies a set of ontologies based on OWL to describe different aspects of a semantic Web service [3]. There are three core ontologies. and we will briefly review the following four representatives. 2.wsmo. service model describes ”how a service works” .wsmx. Web service and mediator) to model any aspects related with the services’ definition and usage. describedBy. part of the DAML Program16 . SESA Semantic Web services technology acts as an integrated approach combining semantic Web and Web service. All the three ontologies are linked to the top-level concept Service.pera. and will achieve more intelligent and automatic service. protocols and so forth (normally expressed in WSDL).html http://www. OWL-S Web Ontology Language for Web Services (OWL-S). goal. further realizing the vision of the next generation of Web [43]. There are many considerable researches towards semantic Web services. To attain full potential of the web. service grounding supports ”how to access it” via detailed specifications of message formats.2. service model and grounding. Through the analysis of relevant competency questions. SWSF Semantic Web Services Framework (SWSF) is a specification produced by the SWSL Committee17 of the Semantic Web Service Initiative (SWSI).net/Methodologies/ARIS/ARIS Paper by Ted Williams. SWSF has its own conceptual model Semantic Web Service Ontology (SWSO) and relevant language Semantic Web Service 12 http://www. WSMF gives two main principles (maximal de-coupling complemented by scalable mediation service) and four elements (ontology. such as the modeling ontology WSMO 13 [45]. i. the description language WSML 14 [16]. and the execution environment WSMX 15 [35].

The difference and the key contribution of SWSO are its rich behavioral process model. proposes a mechanism to augment WSDL with semantics.2. Petri nets are suitable for modeling. supporting first-order-logic and logic programming respectively [5]. simulating and analyzing business processes. SWSO has been influenced by OWL-S and adopts its three ontologies. which provides formal semantics for further process analysis. 2. Besides industrialcentric approaches. service profile. hierarchy etc. With such extensions. Due to the formal foundation for concurrency modeling.1 Petri Net Petri net.3. SWSL-FOL and SWSL-Rules. provides means to describe systems in an unambiguous way using a semantically well founded mathematical notation. 2. in particular focusing on the services’ functional descriptions. developed by the Meteor-S group at the LSDIS Lab 18 . in the meantime. tasks are modeled by transitions. and/or stochastic [36]. there are some formal techniques as the result of academic contribution. Formally. SWSO can support more powerful descriptions and reasoning on Web services. WSDL-S Web Service Description Language . WSDL-S has the advantage of attaining semantics building on existing Web services. and arcs) on classic Petri Nets. it’s rather straightforward to model workflow using Petri nets. and cases are modeled by tokens. places. it does not dictate a specific language for semantic description [6]. asynchronous. many analysis techniques can be utilized in the analysis and validation of processes.cs. Furthermore.2 Abstract State Machine Abstract State Machine. transitions. distributed. The core constituents are the 18 http://lsdis. we have discussed many different considered approaches and relevant standards for process modeling. we provide a concise introduction of those formal approaches and their relations to process modeling. is a promising tool for describing and studying systems that are characterized as being concurrent. please refer to the related references afterward. conditions are modeled by places.e. As discussed in Section 2. ASM for short.Semantics (WSDL-S). based on PSL.3 Academic Foundations of Process Modeling During the previous section. Based on the WSDL. On particular.uga. For more detailed information.3. SWSL has two sub-sets. nondeterministic.edu/projects/meteor-s/wsdl-s/ 10 . Petri net model is represented in the OWL language to realize semantic business process ontology called BPO. Among those researches. like supporting color. In addition to the three basic elements (i.Language (SWSL). time. a Petri net is a directed bipartite graph with nodes (places and transitions) and arcs. including both graphic-modeling tools and language-based descriptions. i. model and grounding. introduced by Carl Adam Petri in 1962 in his PhD thesis. there are many extensions to get more powerful description capability. In this section. parallel. considering non-semantic as well as semantic approaches. and many research activities are focusing on this.2.e. 2.

2. rejected and delayable. executing. simulation. as described in [32]. There are two main categories in ASM. Transaction Logic was developed by Anthony J. temporal logic can be used for process mining and verification [50]. which differentiate themselves by the expressive power and computational complexity of the reasoning tasks [11]. Additionally.4 Temporal Logic. Transaction Logic Some logic-based formalizations can also be used for process modeling. are a family of approaches to formally model concurrent systems. and the formality”. executing and reasoning on workflows (or processes). especially service choreography.5 AI Model In [30]. done. While most recent standards like BPEL. 2.3. such as CCS (Calculus of Communicating System). also called process calculi. such as Temporal Logic and Transaction Logic. analysis and verification of mobile communication systems [47]. Basic ASM and Multi-Agent ASM. and committed. 2. a formal foundation for BPM is still missing. many detailed algebras appear. we can model tasks in a process as: not executing. the authors present a formal framework for the representation of enterprise knowledge with business processes. the ground model technique and the refinement principle [18]. Upon those models. The framework is largely based on AI and its concepts (objectives and 11 . For example. ASM has been chosen as the underlying model for modeling WSMO interface. communications and synchronizations between processes [9]. events in a process can be modeled as forcible. it is possible to describe the interactions. such as the necessity operator and the possibility operator [34]. also known as service orchestrations. It is an extension of predicate logic that accounts for state changes in databases and logic programs.3. Basically. Some approaches propose using transaction logic for modeling. BPMN. the maximality of modeling expressive. namely. Temporal logic is also a formal approach for process modeling. Temporal logic has been broadly used as a general logic for representing and reasoning about temporal information. With the development of process algebra. Several variants of transaction logic have been developed. temporal logic extends classical logic with modal operators denoting a temporal modifier. or WS-CDL only tackle the problem from a practical side. The most recent addition to the process algebras family is pi-calculus. Recent results have shown that the pi-calculus is well suited for modeling classical workflows. Pi-calculus has its own advantages to take charge of this role. as well as service choreographies that together form a core foundation of future BPM [41] [46]. aborted. Based on ”the minimality of modeling primitive. Pi-Calculus Process algebras. CSP (Communicating Sequential Processes) and ACP (the Algebra of Communicating Processes).3.3 Process Algebra. especially one of the extensions called currency transaction logic [27] [12]. The pi-calculus provides a framework for the representation.notation. which was invented by Robin Milner as a formal language for concurrent computational processes. Bonner and Michael Kifer.

actions and processes. roles and actors. there are some detailed algorithms for process management. In addition to those generalized AI methodologies. partial order refinement. goals etc. An agent-based infrastructure for managing business processes was provided in [26]. autonomous agents. service composition can benefit from several planning paradigms. and further applying them in the British Telecom business process. such as state-based planning. planning as satisfiablity. responsibilities and constraints) allowing business analysts to capture enterprise knowledge in an intuitive and formal way. initial world. demonstrating the key technologies of negotiating. Considering some formalization as the pre-requisites (such as the planning domain.goals. 12 .). graph-based planning. such as case-based reasoning for workflow model [33] and AI planning for Web service composition [28]. service providing. and planning as logic programming [28].

and execute it directly if exists. we have to decompose the goal into sub-goals.etel. As shown in Figure 2. many process description requirements can be extracted. 3. eTel provides the Product Ordering use-case 21 . and finally develop BPMO (Business Process Modeling Ontology). business rules and business logic to assist the invocation of business process? More inward and detailed requirements will be discussed in the next section. We can loop this query procedure. and query relevant business processes for each sub-goal. or adapt/modify existing processes. However.1 Process Scenario For the requirement analysis for BPMO we have to consider not only the current state of the art in process representation. but more complex scenarios will be analyzed as soon as they become available 20 13 . in this section.at/ 21 As we are still in an early phase of the project we consider these small application scenarios as our starting point. For process description requirements. Firstly.net/ http://www. If there are still no matching processes for this goal. the system tries to find the exact matching process for such a goal. until we reach an indecomposable goal/sub-goal. HANIVAL proposes an application scenario for business process within its own order-billing and provisioning system for the chillydomains platform. In this case. to describe their detailed process scenario. 19 http://www. From these two scenarios we abstract the generalized scenario for business process (shown in Figure 2). Finally. HANIVAL19 and eTel20 are the two industrial partners in the SemBiz project. we compose the relevant business processes and invoke them at a certain sequence to achieve the whole business goal given before.hanival. it is frequent that no such exact-matching business process exists for the given goal. Although the above process scenario is abstract and simplified. composition and finally invocation? • How to describe the business goal. we will focus on the requirement analysis for semantic business process description BPMO. we have the following two obvious questions: • How to describe the business process to improve the soundness and efficiency of process discovery. we will create a new process for the indecomposable goal.3 Requirements Analysis for BPMO Considering the different process modeling approaches discussed in the state of the art. and in particular the extension mechanisms of WSMO to realize BPMO. We can use this abstract scenario to analyze and derive the description requirements for semantic business processes. the main and final aim of the scenario is to achieve a given business goal. according to the certain business logic and relevant business rules. They both use popular graphic modeling techniques. but also to analyze process use cases in the some real-world applications. like EPC or BPMN.

2 Process Description Requirements By analyzing the real-world process use cases and the abstract process scenario. secondly. we will derive the description requirements for the business processes modeling. stakeholders. the functional description requirements will be discussed. goals. The commonly recognized first step is trying to define system boundaries. 3. to determine the process description’s requirements more completely. and tasks etc. some non-functional requirements for business processes are proposed. Hereby. Firstly. we apply relevant requirement 14 . the involved concepts will be overviewed and summarized.1 Concepts Involved in Business Processes Requirement Engineering is a branch of software engineering which has many arbitrary techniques to elicit the requirements before the system development [38].2.Figure 2: Generalized Use Case Scenario for Business Processes 3. last but not least.

We can infer the following main requirements referring to the involved concepts. business rule.business processes. or software (application programs) are involved in the process execution. 15 . business rules can evaluate the data provided by the process and control the basis for change in (business processes) flows.e.engineering techniques. which may be an un-dividable atomic activity or an integrated one involving many sub-business processes/activities. decisions and loops. Basically. we make the requirements list and mark them with certain serial numbers. process component and process interaction. Process-Related Concepts: • process component: the core element during the whole process scenario. which are consistent with the two questions in Section 3. • business data: a lot of information is exchanged during the process scenario and relevant models are needed to describe them. the process can be seen as a map of flow controls. we call the former interaction ”process interface” and the later one ”process interoperation” Basically. taking some responsibilities in executing the process. namely business goal. business data. which ought to consider all the involved concepts. business data include business messages. • business roles: to finally achieve the business goal. most information can be classified into two categories. business rules. which affect the execution path for inter. business role. there are several concepts involved: business goal. For the sake of simplicity. • business rule (also called business logic): business rules are abstractions of the policies and practices of a business organization. and all relevant document resources involved in the whole business process lifecycle can be classified into and modeled with such concept. From the real-world use cases and the abstract scenario mentioned above. and the other is with other business processes such as process composition.1. i. generally. • process interaction: interaction is unavoidable during the process execution. hardware (equipments or machines). summarize them and provide relevant classification.or intra. relevant events and time records. business-related and process-related. The following R1 and R2 will mainly focus on the related concepts description requirements for the business process. peoples (organization in enterprises). we can distinguish between two possible interaction modes: one is with business-related concepts such as user interaction. a fully-fledged description meta-model should be provided. We overview all the involved concepts in the whole business process scenario. Business-Related Concepts: • business goal: the final business objectives. To make the requirements more clear. business process and business data.

3: Representation of the business role. business rule. hardware. There are two main process-related concepts.1: Representation of the business process as a (or part of a) process component We can classify business process as according to the granularity in the two categories. and business data. Accordingly.e. R1. considering process interface interaction to invoke the process and attain the goal from the process execution. R2: The process-related concepts should be clear and concisely represented. the other is between processes themselves. i. functional requirements specify specific behaviors of a system. R1. the business logic influencing the process execution. This distinction is rather important only if we consider that a domain expert (human user) is going to be involved in the process execution.1: Representation of the business goal. involving the internal work on the software to finally realize the use 16 . R1. business role. i. However. split. there are four sub-requirements to concisely represent those business-related concepts. there are four main concepts referring to the business. especially to make choices and provide a logic sequential for process execution. i. all the relevant data involved in the whole life cycle of business process. the process itself and the process interaction. 3. we can build upon those logic constructs for business processes referring to the workflow patterns. such as documentation. the final aim for the execution of business processes. choice.R1: The business-related concepts should be clear and concisely represented As mentioned. organization ontology. and overall its description can be considered equivalent with the description of a semantic Web service choreography. parallel.e processes that can not be divided. R2. Furthermore. events. the later can be compared to Web service orchestration.e.2 Functional Requirements for Process Description According to the definitions in requirement engineering. the second category consists of processes composed by other processes involving certain logical constructs such as sequential. it is not important who is actually interacting with the process. and from this point of view the business process execution is different from the semantic Web service execution. messages. but only how the interaction takes place. business goal.2. The former can be compared to Web service choreography. The first one consists of atomic processes. join etc. R2. loop.2: Representation of the business rules. software.2: Representation of the interaction requirements for business processes There are two kinds of interactions: one is between business process and the involving business role. involving people.4: Representation of the business data. considering process functionality composition to achieve integrated business processes. if we consider the automatic execution of processes. R1. especially control-flow based patterns.

BPMN etc. referring to BPEL4WS 3.3: Representation of matching between business process and business goal R3. Web services can be considered as the building blocks for final process execution. a certain query language is needed to match processes and goals. With the above two kinds of concepts involved in the process scenario. like EPC.case [2]. referring to R2.1: Representation of grounding language. the relevant processes ought to be integrated together according to certain logic. Therefore. For example.e. process composition and process invocation. i. Process Invocation: R3: Functional descriptions needed for process discovery have to be included in process specification To query the matched processes for the goal/sub-goal.) R4: Functional descriptions needed for process composition have to be included in process specification To match a complex goal.2: Representation of matching between business goals R3. we will analyze the functional requirements for business process management according to this classification. sequence or loop etc. R5. Therefore. process discovery. R3.1: Representation of composition language. Taking the above concepts description requirements (R1 and R2) as the footstone. such as concurrency. there are also some non-functional requirements playing important roles in software engineering. there are three main functional behaviors during the life cycle of business process. a certain match model between the goal and the process is required. Typical non-functional requirements are some 17 . most functional requirements of process description can be determined and specified. On the meanwhile. Basically the input/output parameters of the process are needed to match the processes and the goal.4: Representation of legacy process (how to re-describe existing processes modeled by traditional methods.2.3 Nonfunctional Requirements for Process Description In addition to the functional requirements. From the business process use cases and abstract scenarios mentioned in section 3. further functional requirements are needed to describe the specific behavior of business processes. Many workflow patterns and other composition techniques can be refined for process composition. processes should be invoked with certain grounding technology.1integrated process R5: Functional descriptions needed for process execution have to be included in process specification To finally achieve the business goal.1: Representation of the process query language R3. Process Composition. Process Discovery. Web services should be wrapped and further described as the process activities.1. R4.

and the non-functional requirements with additional process information to assist successful business goal achievement. i. such as the reliability. and compensation have to be modeled There are broad description requirements for complete process modeling during the whole process life cycle.specific criteria used to evaluate the quality of the system. the concepts involved in the business process life cycle. and costs [15] [49].e. In a nutshell. there are also some non-functional information needed to be modeled. R6: Nonfunctional descriptions referring to the process quality have to be modeled R7: Nonfunctional descriptions referring to the process security. and reputation etc). robustness. the functional requirements for business process. scalability. the substitute for traditional ACID transaction. To completely realize the business process. such as process quality and process compensation (the error port. 18 . there are three main description requirements for BPMO. security.

we argue for the importance of Web services to finally achieve automatic process. mediation or invocation of SWS. WSMO consists of four main modeling elements. and finally realize a semantic framework to describe business processes.4 BPMO Design This section presents the initial design for Business Process Modeling Ontology. composition. there are many existing semantic Web services approaches. invocation. which corresponds with the intersection of Description Logic and Horn Logic (without function symbols and without equality). The objective involving semantics in Web services is to enable automatic service discovery.1 Why Semantic Web Service for BPMO With the survey on the various process modeling approaches and the analysis of the process description requirements discussed above. in [31] the authors provide a set of requirements for semantic Web services. as presented further in this section. invocation. However. Generally. • there exist already a reference implementation for WSMO.2 Why WSMO for BPMO As discussed in Section 2. which provides a set of decoupled components with different functionalities. Description Logics. 19 . WSML-Rule and WSML-Full. namely WSML-Core. • the representation language used by WSMO (WSML) allows the modeling of both semantic Web service capability and behavior. namely WSMX. and by proposing several adjustments and modifications that would allow the business process modeling. It starts with an argumentation for using semantics for modeling business processes. Therefore. First-Order Logic and Logic Programming. the Web service technologies can be considered as the building blocks for business process. It continues by presenting the relevant WSMO concepts for BPMO. we chose to use WSMO as the starting point for various reasons: • it is currently (one of) the most complete and consistent ontology for all semantic Web services related aspects. WSML-DL.2. and in particular the final process execution. WSML is based on different logical formalisms.3. and a justification for choosing WSMO as the starting point for BPMO. the WSMO Web Service description constitutes the starting point for process representation. 4. like discovery. In detailed. WSML-Flight. composition. For the first version of BMPO we will use the WSML-Core variant as the simplicity for the implementation. namely. extended with datatype support in order to be useful in practical applications. semantic Web services’ specification can be refined and enhanced for business processes. business processes have similar requirements for automatic process discovery. WSMX can be considered our starting point in modeling the BPMO Suite. and monitoring. and from our initial investigations it can also be used for representing any process related aspects. 4. In order to fulfill this objective. and consists of a number of variants based on these different logical formalisms. interoperation etc.

Mediators and Goals (a graphical representation of the WSMO top level elements shown in Figure 3): • Ontologies provide the terminology used by other WSMO elements to describe the relevant aspects of the domains of discourse. which provides the human readable syntax. such as contributor. • Web Services describe the computational entity providing access to services that provide some value in a domain. ¨ Listing 1: WSMO Element Definition C l a s s wsmoElement hasAnnotation type a n n o t a t i o n § ¥ ¦ Annotations are entities used in defining the WSMO elements. creator. The set recommended by WSMO consists of most of the elements from [53]. identifier. we use the semantic Web service modeling language WSML. etc. Figure 3: WSMO four top level elements WSMO refers to the set of concepts it defines as elements. • Mediators resolve the possible heterogeneity problems between the other elements. These descriptions comprise the capabilities. WSMO top Level Elements Based on WSMF. For presenting the following detailed WSMO elements definition. 20 . description. date. publisher. • Goals express the objectives that a client wants to achieve by invoking a Web service. Listing 2 depicts the WSMO definition of an ontology. WSMO proposes an overall framework for semantic Web services description considering four top level elements.In the next subsection we will provide a brief overview of the Web Service Modeling Ontology. Web services. interfaces and internal working of the Web service. title. language. involving Ontologies. The general definition of an element is given in Listing 1. source. Ontologies Ontologies provide the terminology used by other WSMO elements to describe the relevant aspects of the domains of discourse.

A relation can be defined as being a sub-relation of one or more relations. and by this between their instances (Listing 5).¨ Listing 2: WSMO Ontology Definition C l a s s o n t o l o g y sub−C l a s s wsmoElement importsOntology type ontology usesMediator type ooMediator hasConcept type concept h a s R e l a t i o n type r e l a t i o n hasFunction type f u n c t i o n h a s I n s t a n c e type i n s t a n c e h a s R e l a t i o n I n s t a n c e type r e l a t i o n I n s t a n c e hasAxiom t y p e axiom § ¥ ¦ As ontologies can become quite complex. In WSMO concepts represent the basic elements of the ontologies. WSMO offers support for modularization. i.e. ¨ Listing 3: Concept Definition C l a s s c o n c e p t sub−C l a s s wsmoElement hasSuperConcept type concept h a s A t t r i b u t e type a t t r i b u t e h a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y = s i n g l e −v a l u e d § ¥ ¦ The attributes are defined as shown in Listing 4 and they can be filled at instance level. 21 ¥ ¦ . A concept (Listing 3) can contain attributes with names and types and it could be a sub-concept of other concepts (the isA relation). The definition is a logical expression that can be used to formally describe the semantics of the concept. as having a given set of parameters and as being refined by a logical expression. ¨ Listing 4: Attribute Definition C l a s s a t t r i b u t e sub−C l a s s wsmoElement hasRange type c o n c e p t m u l t i p l i c i t y = s i n g l e −v a l u e d § ¥ ¦ In WSMO relations can be defined to model relationships between concepts. If heterogeneity problems exists. ¨ Listing 5: Relation Definition C l a s s r e l a t i o n sub−C l a s s wsmoElement h a s S u p e r R e l a t i o n type r e l a t i o n hasParameter type parameter h a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y = s i n g l e −v a l u e d § Accordingly. an ooMediator can be used (more about WSMO mediators can be found subsequently) to perform an alignment of the imported ontology. an ontology can import another ontology as long as no heterogeneity conflicts need to be solved. As such. a parameter definition is given in Listing 6. the logical expression defines or restricts the extension (the instances) of this concept.

anonymousId } § ¥ ¦ ¥ ¦ Similarly. one can define relation instances and parameters values. one can refine its ontology by using axioms. l i t e r a l . ¨ Listing 9: Relation Instance Definition C l a s s r e l a t i o n I n s t a n c e sub−C l a s s wsmoElement hasType type r e l a t i o n hasParameterValue type parameterValue § ¨ Listing 10: Parameter Value Definition C l a s s p a r a m e t e r V a l u e sub−C l a s s wsmoElement h a s P a r a m e t e r t y p e p a r a m e t e r m u l t i p l i c i t y = s i n g l e −v a l u e d h a s V a l u e t y p e { i n s t a n c e . The attribute values (Listing 8) have to be defined in respect with the type declaration in the concept definition.¨ Listing 6: Parameter Definition C l a s s p a r a m e t e r sub−C l a s s wsmoElement hasDomain t y p e c o n c e p t m u l t i p l i c i t y = s i n g l e −v a l u e d § ¥ ¦ An instances of a WSMO concept has the form defined in Listing 7 where an attribute values represents the value associated with a concept’s attribute in the instance. Additionally. which can constrain or logically define the various aspects of the ontology (see Listing 11). ¨ Listing 11: Axiom Definition C l a s s axiom sub−C l a s s wsmoElement h a s D e f i n i t i o n type l o g i c a l E x p r e s s i o n § ¥ ¦ The logical expressions are used in the WSMO model to capture specific nuances of meaning of modeling elements or their constituent parts in a formal and unambiguous way. anonymousId } m u l t i p l i c i t y = s i n g l e −v a l u e d § ¥ ¦ ¥ ¦ The elements presented before correspond into the language to the so called conceptual syntax. More details about the syntax of the formal language used for specifying the logical expressions can be found in [44] while the semantics of this language is given in [16]. respectively (see Listing 9 and Listing 10). l i t e r a l . 22 . ¨ Listing 7: Instance Definition C l a s s i n s t a n c e sub−C l a s s wsmoElement hasType type c o n c e p t h a s A t t r i b u t e V a l u e s type a t t r i b u t e V a l u e § ¨ Listing 8: Attribute Value Definition C l a s s a t t r i b u t e V a l u e sub−C l a s s wsmoElement h a s A t t r i b u t e t y p e a t t r i b u t e m u l t i p l i c i t y = s i n g l e −v a l u e d h a s V a l u e t y p e { i n s t a n c e .

scalability. The preconditions and assumptions define the information space of the Web service and the state of the world. assumptions. before execution while the postconditions and effects the information space of the Web service and of the world. wwMediator } h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e −v a l u e d h a s I n t e r f a c e type i n t e r f a c e § ¥ ¦ Listing 13 defines the class used to describe the Web service specific non-functional properties. respectively. after the execution of the services. The shared variables represent variables that 23 . reliability. etc [42]. ¨ Listing 13: Non-Functional Properties Definition C l a s s n o n F u n c t i o n a l P r o p e r t y sub−C l a s s wsmoElement h a s D e f i n i t i o n type l o g i c a l E x p r e s s i o n § ¥ ¦ The capability of a Web service is defined in terms of preconditions. wgMediator } h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y h a s S h a r e d V a r i a b l e s type s h a r e d V a r i a b l e s h a s P r e c o n d i t i o n t y p e axiom h a s A s s u m p t i o n t y p e axiom h a s P o s t c o n d i t i o n t y p e axiom h a s E f f e c t t y p e axiom § ¥ ¦ The importsOntology. security. imported ontologies) and to the set of mediators the service is referring to in order to address the heterogeneity problems (see Listing 12). networkrelated QoS. Additionally. ¨ Listing 12: Web Service Description Definition C l a s s w e b S e r v i c e sub−C l a s s wsmoElement importsOntology type ontology u s e s M e d i a t o r t y p e { o o M e d i a t o r . postcondition and effects (Listing 14).e. to the set of ontologies modeling the elements used in this descriptions (i. respectively. or properties like like accuracy. the description of the Web service can also refer to a set of non-functional properties. robustness. usesMediator and hasNonFunctionalProperties have the same meaning as in the case of the Web service descriptions. performance. ¨ Listing 14: Capability Definition C l a s s c a p a b i l i t y sub−C l a s s wsmoElement importsOntology type ontology u s e s M e d i a t o r type { ooMediator . WSMO does not pose restrictions of how the non-functional properties have to be encoded by logical expressions but such non-functional properties could include cost-related and charging-related properties of a Web service [39].Web service A Web Service description in WSMO is a description of both the functionality of the Web service (as a capability) and its behavior (as an interface).

22 If ?v1.. the selection of the most appropriate service for a certain task. assumptions. postconditions. WSMO defines mediators (see Listing 17) between two ontologies (ooMediators).. The choreography of the service specifies how the requester should interact with the service while the orchestration specifies how the service achieves its functionality by invoking other services.?vn (pre(?v1.. The Web service interface is described in terms of the choreography and orchestration (Listing 15)... two goals (ggMediators) and a requestor and a provider of a service (wgMediators). then the following holds: forAll ?v1..?vn) implies post(?v1....?vn)). assumptions. Mediators The WSMO mediators are mechanisms for getting different systems to work together. Listing 15: Interface Definition ¨ C l a s s i n t e r f a c e sub−C l a s s wsmoElement importsOntology type ontology usesMediator type ooMediator h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y hasChoreography type choreography h a s O r c h e s t r a t i o n type o r c h e s t r a t i o n § ¥ ¦ Goals The Goal description (Listing 16) is similar with a Web Service description (WSMO treats both the requestor and the provider of a goal as equal partners)..?vn) and eff(?v1.?vn)......?vn) and ass(?v1. ass(?v1. post(?v1.. to agree on the format of messages exchanged and protocols/processes used. ggMediator } h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y r e q u e s t s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e −v a l u e d r e q u e s t s I n t e r f a c e type i n t e r f a c e § ¥ ¦ Having similar descriptions for the services and the service request facilitate the Web service’s discovery by a potential client. containing a description of the required capability (what the service should offer) and of the required interface (how the service should be accessed). two services (wwMediators).... the actual invocation of a service and the composition of multiple services for accomplishing a common task. and pre(?v1..are shared between the preconditions..?vn are the shared variables defined in a capability...... Listing 16: Goal Definition ¨ C l a s s g o a l sub−C l a s s wsmoElement importsOntology type ontology usesMediator type { ooMediator .......... and effects respectively.. 24 .. postconditions and effects22 ...?vn).?vn) are used to denote the formulae defined by the preconditions..?vn) and eff(?v1.

the WSMO ontology definition provides almost the concept needed in representing a process. mediator } h a s T a r g e t type { ontology . respectively as ontology. one difference is that we accept only one type of mediators. and not with how it can be invoked or with how it can orchestrate other services. mediator } h a s M e d i a t i o n S e r v i c e t y p e { g o a l .3. The distinguish point hereby is that we should emphasis the detailed concepts involving in the business process scenario. we will present the main extension strategies of WSMO for BPMO.2. in the business processes environment. wwMediator } § 4. wgMediator . ggMediator } hasTarget type { goal . • For BPMO ontology. These operations are going to be handled by specialized components in the BPM Suite [54]. business role. webService . in consistent with the description requirements R1. ontology. goal .1 Extension Highlights In this section. business goal. g o a l . wwMediator } h a s T a r g e t t y p e { w e b S e r v i c e . Web service. Generally. wwMediator } C l a s s o o M e d i a t o r sub−C l a s s m e d i a t o r hasSource type { ontology .3. ggMediator . g g M e d i a t o r } h a s T a r g e t type { webService . goal . can be significantly reused in BPMO. • The BPMO business process is similar with WSMO Web service. the ontology-to-ontology mediator. and R1.e. webService . The main reason is that. goal . we will provide some modification and extension for modeling business process. R1.3 ¥ ¦ How to Extend WSMO for BPMO Starting with WSMO. another main difference is we use execution instead of interface for business process. and mediator.4. ggMediator } C l a s s w g M e d i a t o r sub−C l a s s m e d i a t o r usesMediator type ooMediator h a s S o u r c e t y p e { w e b S e r v i c e . wgMediator } C l a s s wwMediator sub−C l a s s m e d i a t o r usesMediator type ooMediator h a s S o u r c e t y p e { w e b S e r v i c e . and business data. 25 . goal. involving business rule. ooMediator } C l a s s g g M e d i a t o r sub−C l a s s m e d i a t o r usesMediator type ooMediator hasSource type { goal . 4. involving the similar and the distinguished characteristics of BPMO. i. we are more concerned with how the process is actually executed. w e b S e r v i c e . there are the following extension highlights: • The four main high-level elements in WSMO.¨ Listing 17: WSMO Mediators Definition C l a s s m e d i a t o r sub−C l a s s wsmoElement importsOntology type ontology h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y hasSource type { ontology . mediator. business process.

• For BPMO mediator.3. and will be improved and refined in our future works. Figure 4: BPMO Elements UML Diagram Basically. BPMO uses it to express the business objectives that can be achieved by executing business processes. which can be inherited from WSMOElement.3 BPMO Element Definition As mentioned. the BPMO goals do not have a dedicated interface.• For BPMO business goal. there are five core elements inheriting from the fundamental element BPMOElement. as the requester is not aware of how the process is executed. The current diagram is still in its infancy. 4. • Different from Non-functional-properties in WSMO. 4. BPMO does not consider the need of mediating between any two entities. ¨ Listing 18: BPMO element Definition C l a s s bpmoElement sub−C l a s s wsmoElement § ¥ ¦ 26 . unlike WSMO. Therefore.3. which acts as special properties together with the four elements. we propose a comprehensive UML diagram involving all the BPMO elements. Only ontology-to-ontology mediator is considered in the Sembiz project. Unlike the WSMO goals. as shown in Figure 4. all the existing description properties in WSMO can be reused in the BPMO framework. BPMO provides a more separate mode for NFP according to the more complex non-functional requirements. like WSMO goal.2 BPMO UML Diagram To make the framework clearer and provide a basis for the BPMO implementation. BPMO can be inherited from WSMO as reusing many existing features from semantic Web service description (see Listing 18).

for BPM we need the support of ontologies for modeling all the concepts needed in representing a process. time .Ontology Like the role of ontology in WSMO. e v e n t s . the WSMO ontologies provide almost all the modeling elements BPMO need. ¨ Listing 20: BPMO businessProcess Definition ¥ C l a s s b u s i n e s s P r o c e s s sub−C l a s s bpmoElement importsOntology type ontology usesMediator type ooMediator h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e −v a l u e d hasExecution type e x e c u t i o n C l a s s c a p a b i l i t y sub−C l a s s bpmoElement importsOntology type ontology usesMediator type ooMediator h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y h a s S h a r e d V a r i a b l e s type s h a r e d V a r i a b l e s h a s P r e c o n d i t i o n t y p e axiom h a s A s s u m p t i o n t y p e axiom h a s P o s t c o n d i t i o n t y p e axiom h a s E f f e c t t y p e axiom C l a s s e x e c u t i o n sub−C l a s s bpmoElement h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t i e s h a s S t a t e S i g n a t u r e type s t a t e S i g n a t u r e h a s S t a t e type s t a t e h a s T r a n s i t i o n R u l e s type t r a n s i t i o n R u l e s § 27 ¦ . ¨ Listing 19: BPMO ontology Definition ¥ C l a s s o n t o l o g y sub−C l a s s bpmoElement importsOntology type ontology usesMediator type ooMediator hasConcept type concept h a s R e l a t i o n type r e l a t i o n hasFunction type f u n c t i o n h a s I n s t a n c e type i n s t a n c e h a s R e l a t i o n I n s t a n c e type r e l a t i o n I n s t a n c e hasAxiom t y p e axiom C l a s s b u s i n e s s R u l e sub−C l a s s o n t o l o g y / / e x p r e s s e d a s axiom o r f u n c t i o n / / e x p r e s s e d a s ASM r u l e s C l a s s b u s i n e s s R o l e sub−C l a s s o n t o l o g y / / s p e c i f i c b u s i n e s s o r g a n i z a t i o n o n t o l o g y . what we want to emphasis here is the business-related concepts involved in the business process scenario (see Listing 19). For now. r o l e s and t a s k s C l a s s b u s i n e s s D a t a sub−C l a s s o n t o l o g y / / s p e c i f i c b u s i n e s s data ( messages . However. documents . and is presented in List(see Listing 20). from the Web Service modeling Ontology. ) / / and l o g i n f o r m a t i o n i n v o l v e d i n t h e w h o l e BPM l i f e c y c l e § ¦ Business Processes The definition of a business process is very similar with the definition of Web Services.

Goals can be considered as specific business processes that would potentially satisfy the user desires. relevant information needs to be modeled in more separate mode. ¨ Listing 22: BPMO businessGoal Definition C l a s s b u s i n e s s G o a l sub−C l a s s bpmoElement usesMediator type ooMediator h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y h a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e −v a l u e d § 28 ¥ ¦ . according to the more complex non-functional requirements. the requester is not interested in how the process is executed.we care only what the requirement is in terms of the required functionality and not in terms of the required behavior (or in other words. process logs are the valuable information sources to support process monitoring and process mining. see Listing 22). non-functional issues usually are modeled with the four elements as special properties. Unlike the WSMO goals. For BPMO. and the process improvement finally (see Listing 21).Non-Functional Properties Non-functional properties needed for the Business Process modeling additionally include In WSMO. There are four major non-functional issues that should be emphasized in process modeling. QoS of process can make high-quality process available. Listing 21: BPMO nonFunctionalProperties Definition ¨ ¥ C l a s s n o n F u n c t i o n a l P r o p e r t i e s sub−C l a s s bpmoElement h a s C o n t r i b u t o r t y p e dc : c o n t r i b u t o r h a s C o v e r a g e t y p e dc : c o v e r a g e h a s C r e a t o r t y p e dc : c r e a t o r h a s D a t e t y p e dc : d a t e h a s D e s c r i p t i o n t y p e dc : d e s c r i p t i o n h a s F o r m a t t y p e dc : f o r m a t h a s I d e n t i f i e r t y p e dc : i d e n t i f i e r h a s L a n g u a g e t y p e dc : l a n g u a g e hasOwner t y p e owner h a s P u b l i s h e r t y p e dc : p u b l i s h e r h a s R e l a t i o n t y p e dc : r e l a t i o n h a s R i g h t s t y p e dc : r i g h t s h a s S o u r c e t y p e dc : s o u r c e h a s S u b j e c t t y p e dc : s u b j e c t h a s T i t l e t y p e dc : t i t l e h a s T y p e t y p e dc : t y p e hasVersion type v e r s i o § hasCompensation type Compensation h a s Q u a l i t y type Q u a l i t y h a s S e c u r i t y type S e c u r i t y hasLog t y p e Log ¦ Business Goal Like goals in WSMO. security is always the primary precondition for the business community. the Business goals do not have a dedicated interface . BPMO uses goals to express the business objectives that can be achieved by executing business processes. Process compensation should be considered as the substitution of the ACID transaction requirement in traditional database systems.

p r o c e s s } § 29 ¥ ¦ . their functionality being covered by several components from BPM Suite [48] ¨ Listing 23: BPMO mediator Definition C l a s s m e d i a t o r sub−C l a s s bpmoElement importsOntology type ontology h a s N o n F u n c t i o n a l P r o p e r t i e s type n o n F u n c t i o n a l P r o p e r t y hasSource type { ontology } hasTarget type { ontology } h a s M e d i a t i o n S e r v i c e type { goal . the other three types of WSMo mediators are not beeded for BPMO.Mediator We acknowledge the importance of mediators in a semantic environment. The ontologies used for modeling different processes or process requests may differ. as defined by Web Service Modeling Ontology. so we adopt the WSMO definition of ooMediator (see Listing 23). However. but unlike WSMO we do not consider the need of mediating between any two entities.

The next steps will be the detailed design of all the BPMO elements for the actual implementation. 2005. SWSF Available from [6] R. BPTrends. we briefly overview the state of the art of process modeling approaches. we will reuse already existing WSMO framework and its description language WSML. 2001. Farrell. pages 148–155. http://devresource. J.com/resources/solutions/soa/bpm-soa. Bergstra.5 Conclusions and Future Steps At the beginning of this deliverable. N.html. Gruninger. [7] S.psu. B. [2] Functional requirement.org/services/owl-s/1.edu/library/download/WSDL-S-V1. M. 1993. J. Handbook of Process Algebra.wsdl-s. http://citeseer. [3] Owl-s 1. we determine the description requirements of semantic business process. Verma. http://www. Psl: A semantic domain for flow models. USA.ist. Beco. K. Kifer. As previously stated in this document.hp. Transaction logic programming.0. Finally.com/drc/technical white papers/WSOrch/WSOrchestration. Akkiraju. including non-semantic and semantic ones. Behara. After the survey. pages 209–231. a unified framework for process design and deployment. Cantalupo. and S.2 release. References [1] Business process management on an soa foundation. M. A. DC. together with the starting point of business process real use cases and abstracted scenarios.org/services/swsf/1. 2005. pages 257–279. In International Conference on Logic Programming. [5] Semantic web service framework. In E-SCIENCE ’05: Proceedings of the First International Conference on e-Science and Grid Computing. . Bock and M. [11] A. http://en. L. Schmidt.tibco. Matskanis.0/. and M. and considering both industrial standards and formal theoretical foundations. [9] J. J.uga. Ponse. Washington. Giammarino. Web service semantics .wikipedia. http://www. Nagarajan. 2005. 2002. [8] G. [10] C..html. A. adapting them to suit the business process scenario in the SemBiz project. Smolka. swsf version 1. Software and Systems Modeling Journal. Elsevier Science Inc. Surridge.org/wiki/Functional requirements. we present the feasible WSMO extension to design BPMO. Technical note Available from http://lsdis.0/. Bonner and M.cs.pdf. May 2006.daml. [4] Web service choreography. Owl-ws: A workflow ontology for dynamic grid service composition. and K. aiming at the achievement of comprehensive description framework for the above determined semantic description requirements.edu/kobayashi03typebased.daml. Miller. April 2005.pdf. IEEE Computer Society. Bpm and soa: A strategic alliance. Sheth. Available from http://www.

[24] M. The web service modeling framework wsmf. Super deliverable1. Wahler. Hammer. Fensel.[12] A. Semantic business process management: A vision towards using semantic web services for business process management. WSMO Deliverable available from [17] D. D16 the wsml specification. B. Cerami. Agent-based business process management. and M. International Journal of Flexible Manufacturing Systems. Hepp. Koschmider. February 2007. Oberweis. Kotinurmi. Springer.org/TR/d16/. F. Wahler. and G. and P. Yu. Oren. Giaglis. de Bruijn. Oren. 12(4):247–252. Hepp. Web Services Essentials. Johnson. Leymann. A. SOAP. 1999. Brockmans. Stark. 2006. 2002. P. In IEEE International Conference on e-Business Engineering (ICEBE 2005). J. Nixon. In Proceedings of Wirtschaftsinformatik 2007. M. pages 142–156. [14] E. 31 .ip-super. 2002. Studer.A Method for High-Level System Design and Analysis. Domingue. Wiegand. Bussler. Fensel and C. [16] J. February 2005. [19] A. 2006. Haller and E. An ontology framework for semantic business process management. 5(2&3):105–130. Domingue. Distributed Applications with XML-RPC. [21] M. In Joint International Conference and Symposium on Logic Programming. Concurrency and communication in transaction logic. [22] M. Abstract State Machine .1 process modeling ontology and mapping to wsmo. In In Proceedings of the Workshop on Semantics for Business Process Management Workshop at ESWC2006. m3pl: A work-flows ontology extension to extract choreography interfaces. Groger and R. Harvard Business Review. T. China. Bonner and M. Non-Functional Requirements in Software Engineering. Haller. Karlsruhe. [18] E. [23] M. V. pages 535–540. In In Proceedings of the International Conference on Services Computing (SCC 2006). Hlupic. J. Hepp. [13] S. In ICEIS (3). Jennings. Fensel.wsmo.O’Brien. A. 2006. 2002. 2000. http://www. Chung. Montenegro. A.Faratin. M. Beijing. UDDI and WSDL. Business process re-engineering: A modeling perspective. pages 191–196. obliterate. [20] A. Semantic alignment of business processes. P. Electronic Commerce Research and Applications. 1990. Norman.org/. Germany. J. Re-engineering work: Don’t automate. [25] Z. International Journal of Cooperative Information Systems. October 2005. 1996. m3po: An ontology to relate choreography models to workflow models. Irani. Kifer. [26] N. pages 209–231. and R. E. pages 104–112. Springer. Leymann. 1996. F. and D. 2006. and D. and E. Chicago. O’Reilly. A. http://www. [15] L. Illinois. Ehrig. A. Budva.

ACM Press. [34] Z. analysis and applications. 2004. The Temporal Logic of Reactive and Concurrent Systems: Specification. S. April 1989. A case-based reasoning framework for workflow model management. http://devresource. [36] T. AIFBKarlsruhe. Web service orchestration. Lausen.extending service oriented architectures with semantics.php/2027911. Easterbrook. Using the i-calculus for formalizing workflow patterns. [38] B. Moran. Addison Wesley Professional. Murata. 2005.pdf. [39] J. Semantic web services: Description requirements and current technologies. Kifer. 50(1):87–115. In roceedings of the IEEE.com/drc/technical white papers/WSOrch/ WSOrchestration. Springer. September 2003. A pi-calculus based semantics for ws-bpel. Puhlmann and M. 2005. Distributed Parallel Databases.com/services/article. Mazzara. 77. Edmond. Filling the gap . [31] R. In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering. Plexousakis. Quality of service for web services-demystification. Requirements engineering: a roadmap. Hofstede. Arulazi. 32 . E. and D. Lucchi and M. Rajesh and D. and Semantic Web Services. tools.developer. Fensel. T. [28] M. pages 153–168. NY. and A. and best practices. Pnueli. [35] A. Oberweis. Understanding SOA with Web Services. Petri nets: Properties. pages 541–580. J. Arroyo. H. D. Web service composition as ai planning . Transaction logic for the busy workflow professional. Modeling semantic business process models. 12(23):117–133. L. and M. No. Lomow.a survey. J. December 2004. 4. [30] M. Peltz and H. M. Cimpian. and B. Weske. [32] R. March 2003. [40] C. Madhusudan.hp. Shanghai. Zhao. Agents. In Business Process Management. 1996. limitations. Koschmider and A. Manna and A. Vol. China. Business process modeling and design: Ai models and methodology. [29] A. October 2006. Journal of Logic and Algebraic Programming. 1999. Kifer. January 2003. See http://www. In In International Workshop on Electronic Commerce. [42] S. New York. de Bruijn. Lara. 2000. Data Knowledge Engineering. Packard. Koubarakis and D. [41] F. 2006. Zaremba. pages 594–601. 2002. O’Sullivan. USA. What’s in a service? towards accurate description of non-functional service properties.[27] M. Nuseibeh and S. and standards. Mocan. In EEE International Conference on e-Business Engineering 2006 (ICEBE 2006). Marshall. pages 35–46. [33] T. a review of emerging technologies. Newcomer and G. [37] E. 1991.

Distrib.org/TR/d28/d28. trends and research in ontology-based systems. D28. Roman. process algebra. H. 2006.1/. Bussler. Methods. Workflow Management: Models. Roman. B. SemBiz Deliverable. Lausen.Approaches and Perspectives. 2004. (eds. available from http://www. de Bruijn.A Theory of Mobile Processes. [46] S. and U. Cambridge University Press. K. Toma. van der Aalst. A.Kiepuszewski. and L. Mazzara. 33 . WSMO Final Draft.org/services/swsl/materials/WS-CDL. [47] D. D3. van der Aalst and K. web service modeling ontology (wsmo). In OTM Conferences (1).pdf.3 Web Service Modeling Ontology (WSMO). WSMO Deliverable. C.Dublin Core Metadata for Resource Discovery. and M. Fensel. RFC 2413 . [53] S. USA.org/TR/d2/v1. van der Aalst.4/v0. J. Kunze. D2v1. and A. WILEY.Barros. Cimpian. pages 130– 147.wsmo.org/TR/d2/v1. http://www. 2003. Technical report. 2002. de Beer.4v0. H. Cabral. and M. and B. Fingar. 2002. Parallel Databases.1 sembiz bpmsuite requirements analysis and design. Kopecky.[43] D. F. ter Hofstede. Wolf. September 1998. Galizia. Workflow patterns. C. I. February 2007. [51] W. Domingue. Business Process Management: The Third Wave. H.3/. [44] D. 14(1):5–51. [50] W. Lausen. October 2006. Walker.wsmo. D. Lausen. Weibel. [48] H. The Pi-calculus . E. Toma and D. J. Web services choreography and http://www. D2v1. Tampa. [52] W. Roman.). Foxvog. and U. 2004. Meghan-Kiffer Press. Mocan.wsmo. [45] D.3. van Hee. J. Zaremba. 2005. [54] Z. chapter Semantic Web Service . and Systems. Semantic Web Technologies.1 non-functional properties in web services. Keller. Ross-Talbot. J.P. Process mining and verification of properties: An approach based on temporal logic.daml. S. Sangiorgi and D. A. H. [49] I. van Dongen. Yan. Octomber 2006.3/. FL. Lagoze. WSMO Deliverable available from http://www. October 2006. MIT Press. Smith and P. M.