Measuring Quality Dimensions

Quality dimensions are an important means to determine process information quality and the overall relevance of process information for a particular process participant. Thus, they are important means to realize the POIL framework.

Generally, there exist different approaches that can be used to decide whether process information fulfills specific contextual quality dimensions: (1) algorithmic methods, (2) semantic technologies, (3) social methods, and (4) convergent methods.

Algorithmic methods are, for example, the vector space model, the term frequency algorithm and methods of clustering. The use of semantic technologies is another pos- sibility to determine process information quality (e.g., via ontologies) [171, 218]. Social methods include, among others, collaborative tagging or human-based rating of process information [219]. Finally, convergent methods improve the aforementioned methods through their combination (e.g., algorithmic detected relationships between process in- formation are editable by process participants). Table 6.2 illustrates which of these methods can be used to determine our introduced contextual quality dimensions.

# Quality Dimensions Algorithmic Semantic Social Convergent QD1 Punctuality × × × QD2 Topicality × × × QD3 Contextual Relevance × × × × QD4 Completeness × × × × QD5 Value-Added × QD6 Appropriate Amount × × × QD7 Granularity × × × QD8 Neighborhood × × × × QD9 Methods-of-Use ×

Table 6.2: Methods to determine process information quality.

6.6 Related Work

Context and context-awareness in general are discussed by Pascoe et al. [84], Schilit et al. [86], and Dey [87]. In turn, context-awareness in IL is discussed by Haseloff [42], Meissen et al. [77], Levashova et al. [120], and Lundqvist et al. [121].

In recent years, different approaches have been proposed to deal with challenges of context-awareness and context modeling. Especially, in the research field of mobile and ubiquitous computing a numerous of context layers (or context frameworks) have been proposed (e.g., Context Toolkit [220], Hydrogen [221]). Further context frameworks exist, for example, in the field of IR (e.g., SAiMotion [222]). In turn, a broader view on context models supporting business process agility is given by Th¨onssen and Wolff [223]. Only a few approaches combine business processes with context-awareness as described in this work. Context frameworks such as the ones of Pryss et al. [205, 206] and Grambow et al. [207, 208, 209] consider business processes and their tasks. The difference, however, to our work is the scope. Existing approaches are primarily designed for executing business processes and not for providing process information to process participants.

Several authors investigated possible categorizations of context information into con- text factors. For example, Schilit et al. distinguish between location (where you are), identity (who are you with), and device (what resources are nearby) [86]. Kaltz et al. [202, 224] propose user and role, process and task, location, device, and time as pos- sible context factors when representing web application scenarios. Dey et al. stated that certain context factors are more important than others [87, 203]. These are location, identity, activity, and time. In this thesis, we use process, user, location, device, time, and environment as context factors (cf. Section 6.4.2). Table 6.3 compares the chosen categorization of context information with the ones introduced by other authors.

The context factor user (also called identity or role) and location are proposed in all mentioned articles. Both Kaltz et al. [202] and Dey et al. [203] suggest process (also called

# Context Factors Thesis [86] [202] [203] CF1 Process × × × CF2 User × × × × CF3 Location × × × × CF4 Device × × × × CF5 Time × × × CF6 Environment ×

Table 6.3: Categorizations of context information into context factors.

task or activity) and time as important factors. The context factor device is mentioned by Kaltz et al. [202] and Dey et al. [203]. The context factor environment is addressed by none of the mentioned authors. Although examples are given for the environment, none of the mentioned author considers the environment as a context factor.

Based on context factors, it becomes easier to model a context. Different context modeling approaches can be used for this purpose: key-value, markup scheme, graphical, object-oriented, logic-based, and ontology-based models [225]. In the POIL context layer, ontology-based models (cf. Table 6.4) are used, since there exists powerful tool support for ontologies. Furthermore, partial validation and distribution of context information becomes possible and ontologies allow easy linking to other ontology-based models (e.g., ontology-based process information and business process models such as the SIN). Fi- nally, ontologies have strengths regarding normalization and formality. Several authors (e.g., by Strang and Linnhoff-Popien [225]) share our assessment that ontology-based models provide a promising approach to deal with the challenge of context modeling.

Criteria Key-Value Markup Graph. Object Logic Ontology

Ease of use ++ + o o – o

Formalization – o o o ++ ++

Expandability – – + o + – ++

Expressiveness – o + + ++ ++

++ = very good, + = good, o = neutral, – = bad, – – = very bad

Table 6.4: Comparison between context modeling approaches.

Quality dimensions of information in general have been considered in literature as well. Jung, for example, investigates data integration architectures and also sketches quality dimensions [217]. Wang et al., in turn, identify aspects of data quality based on empirical research and integrate their findings into a data quality framework [67, 226, 227]. Naumann et al. describe a framework for multi-database query processing

taking information quality into account [228]. Table 6.5 compares our quality dimensions (QD1-QD9) with the ones of the aforementioned authors (i.e., [217], [227] and [228]).

# Quality Dimensions Thesis [217] [227] [228]

QD1 Punctuality × × × × QD2 Topicality × × × × QD3 Contextual Relevance × QD4 Completeness × × × × QD5 Value-Added × × QD6 Appropriate Amount × × × × QD7 Granularity × × QD8 Neighborhood × QD9 Methods-of-Use × × * Relevance × × × * Periodicity × * Price ×

Table 6.5: Contextual quality dimensions from different viewpoints.

As shown in Table 6.5, quality dimension relevance is not a separate dimension in this thesis. The latter results from the combination of all identified quality dimensions (QD1-QD9). Moreover, the quality dimension periodicity is based on the information sources and is therefore not a quality dimension of process information. Further, quality dimension price can be omitted because commercial data providers are not in focus in this thesis. Note that Wang et al. subsume QD1 and QD2 under the term timeliness [227]. Jung subsumed QD4 and QD6 under the term completeness [217]. Naumann [228] closely follows Wang [227]. Due to different perspectives some quality dimensions of Wang [227] (e.g., QD5) are omitted in the research of Naumann [228].

6.7 Summary

This chapter presented the context layer that is fundamental for enabling context- awareness in POIL. We motivated the need for the latter and showed why the handling of context information is success-critical with respect to the context-aware delivery of pro- cess information. Most important, we introduced the context layer that allows gathering, representing, storing, analyzing, and providing context information along executed busi- ness processes. More specifically, we described the layer’s architecture and introduced important context factors and context information (to be used in context modeling). Moreover, we introduced contextual quality dimensions of process information helping us to determine the contextual quality of process information.

7 Application Layer

This chapter presents the application layer of the POIL framework. Section 7.1 gives a short introduction. Section 7.2 then describes the application layer and introduces its core component; i.e., the semantic information network facade (SIN Facade). Section 7.3 shows how this facade allows for the provision of SIN information and SIN process objects during business process execution. Finally, Section 7.4 discusses related work and Section 7.5 summarizes the chapter.

7.1 Introduction

In Chapters 5 and 6, we introduced the semantic and context layer that enable information-, process- and context-awareness in the POIL framework. A remaining POIL challenge, however, is to provide process participants with the needed process in- formation when performing business processes at the operational level. For that purpose we introduce the application layer (cf. Figure 7.1).

Application Layer Context Layer Semantic Layer Data Layer information- awareness process- awareness context- awareness

Figure 7.1: Application layer enabling delivery of process information.

Consider an engineer in the automotive domain who deals with the problem of finding colleagues working on similar process tasks. More specifically, this use case can be generalized as follows: “show all roles within a business process that perform similar or identical process tasks to a given role, selected by a process participant.”

To realize this use case, the engineer selects a specific role from the list of existing roles (cf. Figure 7.2A). Then, he defines a threshold (i.e., the minimum weight) that indicates the similarity between the selected role and the one to be found (cf. Figure 7.2B). The higher the threshold is, the higher the similarity between the two roles must be.

Relevant roles are identified in five consecutive steps: First, all process objects in the SIN representing a specific role must be identified. Afterwards, for each identified role, the SIN Facade must identify the process tasks the role is responsible for; i.e., based on

“is responsible for” relationships. Then, the SIN Facade identifies similar process tasks for the ones identified in the second step. Therefore, “is similar to” relationships and the threshold are used. Following this, responsible roles for the process tasks identified in the third step are being gathered. Again, “is responsible for” relationships are used to identify roles. Finally, the latter are provided to the engineer (cf. Figure 7.2C).

Figure 7.2: iDaimler: use case.

The remainder of this chapter introduces the application layer of the POIL framework. In particular, it shows how the SIN Facade provides information as well as process objects to process participants. Moreover, we show how the CM is used to filter the SIN enabling the delivery of contextualized process information being relevant for process participants.