Small and medium-sized enterpises need support by processaware information systems (PAIS) that o er a high degree of exiblity in work ow execution. Current agile work ow approaches lack acceptance as they introduce a signi cant overhead for work ow control. Therefore, we propose a new approach for exible PAIS, based on workow enactment exibility by deviation. We enable the potential deviation of the factual work ow from the ideal work ow, while keeping track of the work ow execution. In this paper we describe the proposed SEMAFLEX architecture, which semantically integrates exible workow and knowledge-based document management, as well as selected use cases for illustrating the interrelationships among the architectural components.
Process-Aware Information Systems [
Flexible approaches concerning work ow management are discussed since about
ten years [
Work ow management is tightly connected with the exchange of documents,
which must be organized systematically. Knowledge-based document
management allows the semantic analysis and management of documents with the help
of various kinds of background knowledge [
The SEMAFLEX concept combines exible work ow management and knowledgebased document management. As illustrated in Fig. 1 both approaches are semantically integrated on the basis of an ontology, which stores knowledge about documents and work ows. With the help of the document management, incoming documents are classi ed and relevant information is extracted automatically leading to semantic annotations of the documents. This process is based on the conceptual knowledge of the ontology. From the semantic annotation we aim to derive by abductive inference which work ow tasks may have been executed in the real world that caused the observed documents to be present. While speci c information in the document might enable to easily determine the work ow instance to which the document belongs to, the semantic description of tasks will provide knowledge for abductively deriving a hypothesis about actually executed task. Deviations concerning actually enacted tasks (de facto work ow) and de ned ideal work ow (de jure work ow) are detected and used for further work ow control. The deviations will be classi ed w.r.t. their criticality and if necessary, warnings can be issued. In particular, the work ow engine must consider the deviation when determining the further progress of the work ow. For example, it must decide whether a skipped task can be omitted or whether it must be catched up. This requires additional domain speci c knowledge about execution constraints on the level of work ow de nitions.
To implement this new approach, we propose an architecture on the basis of a semantic integration of knowledge based- document and work ow management. Figure 2 shows the architecture including its single components and their interrelationships. The architecture consists of three main parts. The green modules are responsible for the general work ow functionality, which basically includes the realization of the approach of Flexibility by Deviation. The blue components realize the semantic integration of documents to represent external process contribution. Every module coloured in orange belongs to a certain user interface. Not only the colours illustrate associated components, but also the layout points out di erent layers. Whereas the outer parts, i.e. the work ow and the knowledge store, represent the storage layer, the centered components, i.e. the work ow and the knowledge manager, act as application layer. The lower and upper parts incorporate the presentation layer. Smaller modules, depicted in the main modules, take care of speci c functionality. The connections between the core components represent the most important kinds of interaction, data ow or activities. In the following every main module and its functionality is described in detail.
Knowledge Manager: The knowledge manager includes all modules that create, extract and process knowledge. With its access to the Knowledge Store it will expand a simple document store to a knowledge based document management system. The core components combine- extracted data with the prede ned conceptual knowledge of the ontology to extract process relevant information within the context of already available knowledge, provided by former documents and by the work ow manager directly. Its main goal is to provide enactment hypotheses to the Work ow manager.
Knowledge Store: The knowledge store contains the stored data like documents, conceptual knowledge, and instantiated knowledge. The document store preserves all documents which were uploaded by the user and o ers access to all kind of documents for the purpose of extraction and visualization. The user is granted access to certain documents if they are necessary to enact a task. Another substantial part of the knowledge store is the ontology, which can be divided into two main parts. On the one hand there is knowledge about general concepts, like processes and documents, called upper ontology, which can be applied universally for this work ow-approach. On the other hand a domain ontology is necessary to provide information about domain concepts and speci c work ows, with relations between documents and tasks, which is essential for the overall mapping process that incorporates the semantic integration. The instances determined by the extraction module or from noti cations of the workow manager are stored as triples in the RDF store. Beside the metadata and extracted data from documents the RDF Store also re ects the state of all workow tasks as well as additional information delivered by the work ow manager.
Work ow Manager: The work ow manager covers the application layer concerning work ow functionality and is responsible for the realization of exibility by deviation. Core components take charge of work ow execution, deviation detection, constraints validation, and managing the task suggestion. The previously mentioned modules are elucidated in the subsequent section with respect to the use cases.
Work ow Store: The work ow store contains all data concerning the workows, which involves general work ow knowledge, as well as concrete instantiated work ows and their state. Data structures represent the de nitions (work ow prototypes), which is the ideal work ow enactment, as well as the executed, traced instances (work ow instances) including the data context. The work ow prototypes comprise the de jure work ow, which is regarded as ideal ow of activities in the context of SEMAFLEX, and constraints which might be constructed additionally. Constraints describe dependencies or requirements between tasks, which should not or must not be violated. As soon as a work ow starts, a new work ow instance will be created on the basis of the corresponding work ow prototype. The current de jure work ow and the constraints of the work ow instance are duplicated and stored in the work ow prototype, as they might be modi ed over time. The de facto work ow is built step by step as a simple sequence of activities by means of the logged task enactments. The context contains information about the data which is used or generated during the work ow execution. Thus, the user has access to relevant data, while working on tasks.
User Interfaces: There are di erent types of users, who interact with the system using di erent interfaces. There will be a graphical user interface for operational users who complete their work following the work ow. Required documents and information, which are necessary to complete certain tasks, are accessible, either loaded from the document or the work ow store. Furthermore, another graphical user interface provides work ow modelling, which should be enabled for users, who have permission to create or adopt work ow prototypes or associated constraints. The third user interface component, which is called Work ow Monitoring, will o er a central overview of all running and terminated work ows. It combines the data from the work ow store and the knowledge store to provide an overview for the real and deviated processes and the impact of and connection to context relevant knowledge. 4
The following use cases derived from the application eld of de ciency
management in construction [
The rst use case (see Fig. 3, left side) represents a task enactment triggered by the user through the choice of a proposed task like in a standard WFMS. A signi cant situation in practice might be a de ciency, which is not caused by the enterprise itself, but has to be reported to a subcontractor for remedial actions. The user chooses to send this noti cation and thus activates the task enactment. Through interaction with the web application, the user selects a task in the worklist which he wants to execute (see 1). The work ow engine is noti ed about the enactment and updates the de facto work ow, either creating a new instance with the speci c task and possibly a corresponding data object, if a new work ow has been started, or appending the new nodes to an existing de facto work ow. This updated information is stored in the work ow store (see 2a). Furthermore the worklist manager updates the suggested tasks in the web application, which might be executed next by the user (see 2b). The selection of these tasks is based upon the data of the de jure work ow and the currently executed task. Besides, the user interfaces are updated concerning the changed work ow status (see 3a). Additionally the knowledge store, speci cally the RDF store, is noti ed about the changing work ow data (see 2c). Another impact of the task enactment, triggered by the work ow engine is the activation of the module deviation detection. This module logs deviations concerning the task enactment with regard to the de jure work ow. Furthermore the deviation detection sets the de jure and the de facto work ow of the work ow instances into relation.
The second use case (cf. right side of Fig. 3) covers the semantic integration of documents and tasks. In de ciency management this might be a received document, which reports the state of the de ciency, with attached picture. Because of extracted information, like customer, contract site, etc. it can be identi ed as a de ciency acquisition task. As for each de ciency there is one running workow and as there might be several de ciencies for one contract site, it might be di cult to determine the corresponding running work ow. Therefore, the user has to manually assign the correct instance. The user transfers a document (see 4), which may be an uploaded pdf-document or a mailed picture, to the web application, which is afterwards processed by the knowledge manager. The rst step is to store the document for later accessibility (see 5). Afterwards the module Document Classi cation and Information Extraction classi es the document based on the de nition from the ontology (see 6). The extracted data is stored in the RDF-Store and is linked semantically to available knowledge (see 7). As a new triple is added to the RDF-Store the module Analyser with Enactment Proposal activates an ontology reasoner, which uses modelled inference rules, e.g. property chains of the ontology to check, if this new information can re-enact or start new tasks (see 8). These task candidates are proposed to the work ow manager (see 9). If there are several possible task candidates, the module enactment decision is activated, which involves the user in the mapping process. He might be able to choose the right task instance out of the proposed candidates, as he might be aware of missing information while viewing the corresponding document. An example would be a picture, which represents relevant information. As the extraction module is currently only able to process textual content, visual information is inaccessible and cannot be utilized automatically. If the decision is completed, the chosen task is executed, resulting in an activation of the work ow engine. Constraints are now validated, as the mapping process might have resulted in an undesired state of task enactments. If any constraint is violated, a warning will be send to the user. The warnings are sent to the web application as well as to the work ow monitoring interface. Once an enactment is determined, this new state is send to the knowledge manager (see 10) and subsequently stored in the RDF store (see 11). Such changes will cause another change detection and will start the Analyser again, which results in a loop which ends as soon as no new enactment proposals can be found. The examples reveal that any information might be a contribution to the state of knowledge, whether they come from semantic integrated documents or directly through a user interaction.
We presented an architectural concept for a new work ow management
approach, which utilizes semantic integration of knowledge-based document and
work ow management for the realization of exibility by deviation. Document
classi cation and information extraction modules are used for the semantic
integration, which are ontological-based and use inferencing mechanisms. The
workow component combines imperative and declarative [