DOPA: A Data-Driven and Ontology-Based Method for Ad Hoc Process Awareness in Web Information Systems

Transcription

1 DOPA: A Data-Driven and Ontology-Based Method for Ad Hoc Process Awareness in Web Information Systems Meimei Li, Hongyan Li, Lv-an Tang, and Baojun Qiu National Laboratory on Machine Perception, School of Electronics Engineering and Computer Science, Peking University, , P.R. China {Limm,Lihy,Tangla,Qiubj}@cis.pku.edu.cn Abstract. The knowledge in Web Information Systems (WISs) makes that business process can not be described by a fixed model. Due to not integrating with domain knowledge seamlessly, traditional workflow management technology can not manage the ad hoc process very well. In order to solve that problem, we propose a data-driven and ontologybased method to support process awareness. Using an ontology-based model we integrate domain knowledge and WIS structure into process. A set of reasoning rules are designed to regulate the task transfer. Learning is done from the cases to help users make decision. A smart tool used for ontology building and WIS generation is developed and we prove the feasibility of this method in a real Web-based application. 1 Introduction The concept of Web Information System (WIS) was proposed in 1998[1]. As a new generation of information system, WIS obtains information resources and exhibits business data via Web technologies. In the early time, most WISs were developed by data-oriented approach. Early in 1990s, business process reengineering illustrates the increased emphasis on process. Thus system engineers are resorting to a process-oriented approach to develop a WIS. However, in some knowledge-intensive domains such as hospital, law and stock, the business process is ad hoc. That means the process model can not be defined in advance. Take a Hospital Information System as an example: doctors diagnose according to their own experience and patients symptoms. The different illness and clinical experience make process different every time. It is impossible to design a model to deal with all the possibilities. One of the reasons leading to that problem is ignoring the influence of data to business process. In knowledge-intensive WISs, each process is dynamically driven by the interaction of function and data. So, case handling trends to be Supported by Innovation Found For Technology Based Firms under grant number 06C Corresponding author. K. Aberer et al. (Eds.): WISE 2006, LNCS 4255, pp , c Springer-Verlag Berlin Heidelberg 2006

2 DOPA: A Data-Driven and Ontology-Based Method 115 driven by data flow instead of totally by control flow. However, it is very crucial to describe those data and the relations between data and process. In fact, the data itself, the relations among them, their influence to process, etc, can be considered as knowledge. Further, the cases of process are a kind of knowledge too. A typical object describing knowledge is ontology. Many researchers have proposed some ontology-based process models [3][4]. However, the research is still in its infancy although most methods make progress in different aspects. Another important matter is describing process in Web environment. WIS has its own components, which may be Web pages, navigators, messages, etc. Thus, the tasks of a process, transfer between tasks, and the constraints, etc, need depend on those special components to carry out. The process finished by different users is also a concentration but not only the process done by one user. In order to support the process awareness in WISs in a better way, especially the ad hoc processes in knowledge-intensive domain, we adopt a data-driven and ontology-based method, DOPA in short, and the chief features are: Knowledge-supported: A concept model described by ontology combines the process closely with related knowledge and WIS structures; Data-driven: Depending on data transmission and estimation, support the dynamic processes; Rule-restricted: A set of rules are used to make sure the process is correct and effective; Tool-visualized: The graphical tool supports the What you see is what you get in model building. The remainder of paper is organized as follows: section 2 presents some methods of process awareness; section 3 describes WIS Ontology including DOMAIN Ontology, STRUCTURE Ontology and PROCESS Ontology; section 4 explains how the case is handled through reasoning and learning from WIS Ontology; section 5 introduces experiment and application; at last, section 6 summarizes the paper and discusses future work. 2 Related Work Process-Aware Information Systems (PAISs) support business processes in organizations based on explicit knowledge of both the organization and the processes [14]. Four typical process-aware methods are: Workflow, Groupware, Ad-hoc Workflow and Case Handling. Figure 1(a) compares them from two dimensionalities: process structure and process driver. In terms of process driver, Workflow and Ad-hoc Workflow drive the process according to the control structure defined in models while Groupware takes data as the basis of process. But due to its weak abilities on control, Groupware can not adapt to the complexity in WIS very well. From the dimensionality of process structure, the highly-structured model in Workflow must be designed in advice. The main idea of Ad-hoc Workflow to support the semi-structured process is manually changing the process by end users, such as Caramba [8]. This method increases the workloads. Compared with others, Case Handling supports

3 116 Meimei Li et al. (a) (b) Fig. 1. (a) Process-aware Methods. (b) The Web page of Bed Assignment. both semi and highly structured processes driven by data and process [9]. But it may be a trouble for Case Handling if the processes are ad hoc structured. Although the process-aware methods have evolved rapidly, unfortunately, they seldom consider the domain knowledge. In order to integrate the knowledge, many people are engaged in building the ontology-based process models. The model created by Gianluigi Greco [4] provides a semantic vision of the application context and of the processes themselves. But, it belongs to the Workflow method mentioned in Fig.1(a), so it is hard to handle ad hoc processes. At the same time, much work has been done to support BPM in Web application [5][7][10][11]. OOHDM and UWE base on UML to describe the control flow among operations done by one user in a time. WebRatio is a tool to develop data-intensive Web application using ontology [3][5]. It adopts Web Modeling Language (WebML)[6] integrating process modeling into the design of Web application in hypermedia framework. WSDM is equipped with a Task Modeling step and defines various relations among tasks corresponding to each possibility. However, those examples are oriented toward simple personal applications, whose primary function is to exhibit data. Compared with the web sites, WIS focuses on more complex operations of data, abundant domain semantic and business logic. Besides, although some of them e.g. WebRatio extends the data model it is still limited to metadata. But in WIS data are so important for process that they can not be ignored. 3 WIS Ontology WIS Ontology includes DOMAIN Ontology, STRUCTURE Ontology and PRO- CESS Ontology. The DOMAIN Ontology describes the domain data and relations between them, while the STRUCTURE Ontology describes the structure of WIS components and PROCESS Ontology describes such a task network that complies with the business logic and routine. 3.1 DOMAIN and STRUCTURE Ontology The details of DOMAIN and STRUCTURE Ontology in WIS development can be found in [12]. Here is only a general picture:

4 DOPA: A Data-Driven and Ontology-Based Method 117 DOMAIN Ontology: It is used to describe the objects in a special domain and relations between them. For example, in hospital, each person corresponds to an organization like pharmacy, surgery or orthopaedics. The drugs and equipments are distributed to some organizations or persons. This kind of knowledge is presented by DOMAIN Ontology. Because it is domainspecific, it should refer to the domain standards, e.g. the Reference Information Model (RIM) in HL7 [15]. STRUCTURE Ontology: In WIS, Web pages are the interfaces to communicate with people. Through the pictures, text fields, tables and buttons, etc, they tell people what they have known and what they can do. The layout of such elements is the structure of a Web page. The navigations between the Web pages lead users to implement functions step by step. Those pages and navigations consist of the structure of WIS. 3.2 PROCESS Ontology In order to illustrate the scenario, an example in hospital is given first. Fig.1(b) is the page of Bed Assignment in the internet Total Hospital Information System (ithis) [2]. The page indicates a task in the hospital process and implicates much knowledge. The textfield Bed in it is a basic item in STRUCTURE Ontology which has the attributes such as type, size, position and constraint. The item corresponds to a data object Bed in DOMAIN Ontology. In WIS, tasks like Bed Assignment of processes are implemented by a set of Web pages connected by navigations. But whether the task is triggered and when is implemented rely on the state of data objects. As a result, PROCESS Ontology should base on DOMAIN Ontology and STRUCTURE Ontology. The definitions are as following: Definition 1. The business process BP is a 5-tuples, BP =< TS, DS, RS, ST, FT >, where TS, DS and RS are respectively a set of tasks, data and relations between tasks. Relations represent the fore-and-aft order of two tasks. They are not defined in advance but during the running time dynamically. ST means the task at the beginning of BP, e.g. Patient Admission and FT means the final tasks, e.g. Leave hospital. They comply with the constraints Cont(ST) =1; Cont(FT) 1 Cont(s) is the function to get the element number of s. In the whole process, all data is created by tasks, so the DS is the union of GD in each task (see definition 2), which is DS = t TS (t.gd). Definition 2. The task T is a 6-tuples, T =< TN, TC, GD, MD, P S, Ro >, where TN isthenameofthetask,tc means the indispensable conditions for implementing the task. GD is the data generated after running, e.g. the information of bed assignment while MD is the data needed for running, e.g. the information of admission and charge. P S is the Web Page Set to implement task function, and Ro indicates the legal role, e.g. nurse can assign the bed. For special tasks, there are Cont(ST,MD) =0; t TS t ST,Cont(t.MD) 1; Andthe GD of a task is considered as the union of PGD in each page of task s P S, so GD = p P S.P S (p.p GD).

5 118 Meimei Li et al. Definition 3. The Web Page Set P S is a 3-tuples, P S =< PS, LS, SP >, where PS is the set of all Web pages in P S, and LS is the set of all navigations between pages in PS. SP means the page at the beginning. From SP, all the other pages in PS must be arrived through navigations in LS, so p P.PS p SP, (p i,l i ),Link(SP.o k0,p 1.o k1 LS Link(p j o kj,p j+1 o k(j+1) LS Link(p n o kn,p o k ) LS(j (2,n 1)). Link (a,b) is a navigation from a to b. What is more, in the same period, all the pages can be accessed only by the same user. Definition 4. The Web page P is a 4-tuples, P =< BIS, OS, PGD, PAD >, where BIS and OS are respectively set of basic items, like droplist of specialty, and operation items like button of assign. PGD means the data generated after running the page and PAD is the accessorial data to give some help, like information in the table of Bed Assignment Summary. The operations in a page have different types. The data objects related to SELECT or INITIATE are used to provide information to users so that they belong to PAD. While INSERT and UPDATE either create a new object instance or give a new value to some data object, so the data objects related to them belong to PGD. Some data objects can belong to both, such as the PGD of INSERT can be the PAD of UPDATE. So there are PAD = bi BIS (bi.d) PGD ; PGD = o.ot Y = Insert or Update (o.obis.d); p, o 1,o 2 (o 1 p o 2 p o 1.OBIS = o 2.OBIS o 1.OBIS p.p AD o 2.OBIS p.p GD). Definition 5. The operation item O is a 5-tuples, O =< ON, OBI, OC, OTY, OBIS >, whereon is the name of the operation,obi means the basic item on which the action is triggered, OC indicates the execution conditions, e.g. for operation of assignment OC is that the values of bed, specialty, room and ward can not be NULL, OTY is the type of O, which are mainly the operations to Database, and OBIS is the execution parameters, e.g. droplist of specialty is one of parameters of operation Assign. For all sets in the definition, there are s {TS,DS,PS,BIS,OBIS}Cont(s) 1. Definition 6. The navigation L is a 4-tuples, L =< P Sou, P Tar, LC, LO >, where P Sou is the current Web page showed to user, and P Tar is the Web page showed after the navigation, LC is the condition deciding the direction of navigation, such as whether the operation successes or not, and LO is the operation item on which L is triggered. E.g. the operation update is triggered, and if the action successes, it will return to the same page with new values generated by updating. Definition 7. The Relation R is a 4-tuples, R =< R Sou, R Tar, RD, RO >, where R Sou is the former task which is implemented first, R Tar is the latter task which is triggered after R Sou is finished, RO is the trigger operation and RD is the data transferred from R Sou to R Tar. After a task is finished, the MD and the PAD in the SP of the R Tar should be transferred for further estimation and implementation. As a result, there is RD = t.md t.p S.SP.P AD. In order to illustrate the elements and their relations of the definition above clearly, Fig.2(a) uses a UML model to describe the PROCESS Ontology.

6 DOPA: A Data-Driven and Ontology-Based Method 119 (a) (b) Fig. 2. (a) UML Model of PROCESS Ontology. (b) Running States of a Task. 4 Reasoning and Learning from WIS Ontology As we have said that the case is not driven by a well-defined model, then how to establish the relations among tasks during the running time? A set of rules are established for that problem. Certain rules are established by domain experts. While others are reasoned according to the data conditions or recommended through learning. 4.1 Reasoning When a task is completed, case must transfer to others. During this process, four steps would be taken one by one: 1. Find out tasks which may run after task t as candidate task set (CandidataTasks(t)); 2. For each ct in CandidateTasks(t), test whether the generated data objects meet TC of ct ; 3. Get rid of ungratified ones from CandidateTasks(t), and post task set Post- Tasks(t) is left; 4. Transfer data to every pt in PostTasks(t) and send a request. All the four steps will cause the transformation of running state. After step 1, ct is initiated. Estimated by step 2, ct is passed if result fails. Otherwise, it turns to be ready. The ready ct becomes to pt. According to the strategy of distribution, when request is chosen by a worker and resources are all prepared, pt begins to run. The state transformation of a task in the life cycle is shown in Fig.2(b). Rules are used to express the semantic of each state transformation, and are described as logic sentences, e.g. a A b, where a is the condition of the rule, b is the result and A means the action needed to be done. In step 1, it needs to find what is ct. If there is certain relation between t and ct, the rule is like Rule-1, and means it is the compelling rule. Otherwise, frequent choices of other users can give you some advice, and you can choose a better one or not from those advices, so means it is an optional rule, like Rule-2.

7 120 Meimei Li et al. Rule-1 Complete (t) A Ready (ct), A is: (1) Put ct into PostTasks(t);(2) Transfer RD from t to ct ; (3) Send a request and wait in ct.tasklist; (4) Put <t,ct> in Task-Path. Rule-2 Complete(t) A Ready(ct), A is the same as Rule-1. If there are not rules like Rule-1 or Rule-2, we will choose ct according to state of data objects. Instead of all tasks, we choose a subset as ct whose MD intersects with TGD of t.the feasibility can be explained in two aspects:(1) in the view of t, TGD implies changes of data and the new state will affect the future process; (2) in the view of ct, if MD only contains those data unchanged for a long time, the task may be finished or has less possibility to run again. So, the more potential tasks are the ones whose MD includes new information. Rule-3 to Rule-5 indicate this situation. Rule-3 ct.md t.t GD Φ = Initiate(ct). Rule-4 Initiate(ct) ct.t C is contented = A Ready(ct), A is the same as Rule-1. Rule-5 Initiate(ct) ct.t C is not contented = Pass(ct) RD will be transferred from t to ct if ct is ready. There are various manners to carry the point, and the typical one is using database. Task t stores its TGD in database from which ct fetches what it wants. Each task maintains a T asklist to save the requests of cases. After ct is confirmed, a 2-tuples <pretask, post task > is added to the task sequence Task-Path that case has passed through. The transformation from Ready to Running is described by Rule-6. Rule-6 Ready(ct) All resource are prepared request of case is chosen= Running(ct), A is (1) Tag request in ct.tasklist to inform others that request is replied;(2) Jump to ct.sp to run the task. Tasks do not run as well as we expect. Abnormities usually happen, such as human interruption. Therefore, we save those temporary data for restarting like Rule-7. Another problem is caused by DELETE operation. Elimination of the existing data in the former task may lead rollback or collapse of latter task. Rule-8 and rule-9 are used to solve this problem. But if the latter one has finished, no influence will be exerted. Rule-7 Running(ct) user triggers to interrupt the task = A Interrupt(ct), A is (1) Store the data which have been generated; (2) Release the resources which have been occupied. Rule-8 Ready(ct) RO.OT Y == DELETE = A Initiate(ct), A is Remove request from ct.tasklist.

8 DOPA: A Data-Driven and Ontology-Based Method 121 Rule-9 Running(ct) RO.OT Y == DELETE = A Ready(ct), A is (1) Delete all the data which have been generated by ct; (2) Remove request from ct.tasklist. 4.2 Learning In Task-Path, a sequence of 2-tuples records the trace of a case, such as {< t0,t1 >, <t1,t2 >, <t2,t5 >, <t5,t10 >, <t10,t1 >, <t1,t3 >, <t1,t4 >, <t3,t5 >, <t4,t6 >, <t4,t7 >, <t5,t8 >, <t8,t9 >, <t6,t8 >, <t8,t9 >}. In ordinary workflow log, this example will be {t0, t1, t2, t5, t10, t1, t3, t4, t5, t8, t9, t6, t8, t9}. It only describes the order of tasks but not the Relation between tasks. Note that, it is easier to discover priority, parallel and circle from Task- Path than workflow log. Through synthesis of different Task-Paths, we aim to get a conceptual model from which the system can learn new rules to help users make decisions. Unlike strict model such as Petri-net, our model dose not emphasize whether each junction is AND/OR Join or AND/OR Split, but adopts a set of weights to illuminate the parallel degree. If the weight is larger than the value given by user, the path segment will be added into the rule set for reasoning. Fig.3 is a simple example. First, Task-Path needs preprocessing. It aims to:(1)simplify circle: Replace the segment of circle with a node, thus the model is converted to a directed acyclic graph (DAG);(2)Get rid of dead nodes: The second element of 2-tuples may not be implemented in reality (see Fig.2(b)). In DAG, dead nodes are the leaf nodes which are not final tasks; (3) Mark the running order to help analyze AND/OR logic. Fig.4(a) is the model of Task-Path mentioned at the beginning of this section and Fig.4(b) is the result of preprocessing. Fig. 3. The model is a directed graph. The node is task, and the edge is Relation between tasks. In each node, there are a split table and a join table, recording the weight of AND/OR logic. E.g. T 2,T4:0.27 means the weight of the situation that T2 and T4 implement together is Next, depended on the models in Fig.4 (b), we generate the model in Fig.3. The method of breadth-first search is used to each model, and the split table of parent node is edited due to the fact that all brother nodes are AND split. For join logic, if the order of some join edge is larger than that of some split edge, e.g. 10 of <t6,t8 > is larger than 9 of <t8,t9 >, the logic of t8 is OR join, otherwise it is AND join. The algorithms of pretreatment and model generation are in Fig.5.

9 122 Meimei Li et al. Fig. 4. (a) Model of Task-Path. (b) Result of Preprocessing. Fig. 5. Algorithms of Preprocessing and Model Generation 5 Experiments and Application In order to verify the feasibility of DOPA, we combine experiment and application together. Our main experimental environment is the project WISE which aims to construct WIS automatically from users view. The main parts of WISE are: WISE Builder: A visual graphic tool helps the engineers build WIS Ontology. It supports What You See Is What You Get when defining model [12]; Data Mapper: A data mapping module used to generate the SQL codes for data access and manipulation. All the actions of SELECT, INSERT, UP- DATE and DELETE are automatically carried out with the help of this part [13];

10 DOPA: A Data-Driven and Ontology-Based Method 123 Code Generator: A powerful component aims to generate most of codes in target system.its function includes: Convert the models to Web pages and generate function modules. What is more, it assists Process Builder to generate process engine, etc; Process Builder: A useful part defines PROCESS Ontology and rules, and creates the process engine with reasoning and learning ability. The engine embedded in target system will support the process-awareness in WIS. Fig.6(a) shows the architecture of WISE. Our experiments focus on a simple process in hospital with seven single-page tasks: User Login, Main Page, Patient Admission, Bed Arrangement, Diagnose, Blood Test, and Leave Hospital. To compare, three experiments have been done independently: Experiment 1: Two professional programmers with 3 years experience on JSP and WIS develop on IBM Websphere Studio Application Developer 5.0, the requirement documents and design details are provided; Experiment 2: A medicine student who is familiar with the application domain and a professional programmer depends on a workflow management tool; Experiment 3: All the conditions are the same as experiment 2 except that the tool is WISE. The three experiments share the same database and hardware environment. The time cost can divide into two parts: the time of generating function pages and generating process engine. The top figure in Fig.6(b) records the time cost for generating the seven Web pages and we suppose that the WFM tool in Experiment 2 don t support the auto-generation of function modules. The time cost for generation of process engine is shown in the bottom figure in Fig.6(b) and consist of manual programming time, modeling time and code-generating time. It also shows the time needed for ten times changes in process. Note that, Experiment 3 generates JSPs and Java Codes automatically, so the actual workloads are reduced much. The time costs for process generation in (a) (b) Fig. 6. (a) Architecture of WISE. (b) Time Cost in Experiments (Unit: min).

11 124 Meimei Li et al. three experiments are similar, but the time for updating is different. Although the time for each change in Experiment1 or Experiment 2 is not long, ten times of the time are needed for ten times of changes. However, in Experiment 3 some changes can be reasoned through rules so maybe only 6 7 times of changes are needed in ten times. Thus the whole time is less than the other two. 6 Summary and Future Work DOPA is a novel method for ad hoc process awareness in knowledge-intensive WIS. This paper delves deeply into modeling process ontology and handling cases through reasoning and learning. The chief contributions include: propose an ontology-based model for business process which integrates domain knowledge and WIS structure; present a data-driven method to implement process awareness through reasoning from PROCESS Ontology based on a set of rules and learning from cases to help users make decision; and develop a smart tool used for ontology building and WIS generation. The research on supporting the ad hoc process awareness in WIS is just at beginning and future efforts are oriented to the following aspects: 1. Improve the abnormity handling: dead circle is an instance of abnormity. Further, wrong operations of users or the disconnection of internet will also disturb the process. So rules need be refined; 2. Enhance the reasoning and learning: more knowledge will be imported to control the process so reasoning will be more powerful such as supporting ontology query. Moreover, the results of learning can be used to assist analysis and optimization; 3. Establish the verification: because the processis ad hoc, verification is needed to pledge the correctness of the resulting process, especially for the hospital business processes which require the steps to be verified in order to ensure the suitable patient care. References [1] Tomas Isakowitz, Michael Bieber, Fabio Vitali: Web Information Systems. Communications of the ACM, Vol.41(7), A CM Press (1998) [2] Hongyan Li, Ming Xue, Ying Ying: A Web-based and Integrated Hospital Information System. In Proceedings of IDEAS04-DH, China, (2004) [3] Marco Brambilla: Extending Hypertext Conceptual Models with Process-Oriented Primitives. Lecture Notes in Computer Science Vol.2813, (2003) [4] Gianluigi Greco, Antonella Guzzo, Luigi Pontieri, and Domenico Sacc: An Ontology-Driven Process Modelling Framework. In proceedings of International Conference on Database and Expert Systems Applications-DEXA, Zaragoza, Aug. 30-Sep. 3 (2004). [5] Piero Fraternali: Tools and Approaches for Developing Data-Intensive Web Application. ACM Computing Surveys, Vol.31, No.3 (1999).

12 DOPA: A Data-Driven and Ontology-Based Method 125 [6] Ceri, S., Fraternali, P., Bongio, A.: Web Modeling Language (WebML): a modeling language for designing Web sites. WWW9/Computer Networks 33(1-6) (2000) [7] Hans Albrecht Schmid, Gustavo Rossi: Modeling and Designing Processes in E-Commerce Applications. IEEE International Computing Vol.8 (1): JAN-FEB (2004) [8] Dustdar S: Caramba-A Process-aware Collaboration System Supporting Ad hoc and Collaborative Processes in Virtual Team. Distributed and Parallel Databases Vol.15(1), (2004) [9] Wil M.P.van der Aalst, Mathias Weske, Dolf Grnbauer: Case Handling: A New Paradigm for Business Process Support. Data & Knowledge Engineering Vol.53(2), (2005) [10] Olga De Troyer, Sven Casteleyn: Modeling Complex Processes for Web Applications using WSDM. In Proceedings of the 3rd International Workshop on Web- Oriented Software Technologies, (2003) [11] Nora Koch, Andreas Kraus: The Expressive Power of UML-based Web Engineering. In Proceedings of the 2nd International Workshop on Web-Oriented Software Technologies, IWWOST, (2002) [12] Tang Lv-an, Li Hongyan, Pan Zhiyong, Tan Shaohua: PODWIS: A Personalized Tool for Ontology Development in Domain Specific Web Information System. LNCS Vol.3399, (2005) [13] Hongyan Li, Ming Xue, etc: Understanding User Operations on Web Page in WISE. In proceedings of 6th International Conference in Web-Age Information Management, LNCS Vol.3739 (2005) [14] Wil M.P. van der Aalst, Michael Rosemann, Marlon Dumas: Deadline-based Escalation in Process-Aware Information Systems. BPM Center Report, (2005), [15] HL7 Homepage: