Didier Devaurs
email: ddevaurs@uwindsor.ca

Kreshnik Musaraj
email: kreshnik.musaraj@liris.cnrs.fr

Fabien De Marchi
email: fabien.demarchi@liris.cnrs.fr

Hacid

Timed Transition Discovery from Web Service Conversation Logs

Keywords: Web service, business protocol, knowledge extraction, temporal constraint

Despite their importance, Web service business protocols are not always published with service interfaces, which hinders automatic management. A solution is to extract them from past executions. One of the raised issues is the discovery of temporal constraints called timed transitions, which are not explicitly recorded. In this paper we present our approach for discovering such transitions. We define a class of patterns called proper timeouts which are equivalent to timed transitions, and present a polynomial algorithm for extracting these patterns.

Introduction

A very important ambition associated with Web services relates to looselycoupled integration, which is already partially carried out by the fact that services use widespread standards. A good flexibility is possible only if users know how to interact with a service. This requires to associate with services elaborate descriptions (such as WSDL) enabling a good understanding of their execution semantics. However descriptions like WSDL are not sufficient for a sophisticated and automatic use of services because they provide only static properties [START_REF] Benatallah | Representing, analysing and managing web service protocols[END_REF]. This is what motivated authors in [START_REF] Benatallah | Representing, analysing and managing web service protocols[END_REF] to define a higher level model, the so-called business protocol, which specifies the conversations supported by a service, i.e. all valid sequences of message exchanges. It is formalized by a deterministic finitestate machine, where states represent the various service phases; transitions are triggered when the service sends or receives messages. A timed business protocol [START_REF] Ponge | Fine-grained compatibility and replaceability analysis of timed web service protocols[END_REF] is an enhanced version of the basic model allowing for the definition of timed transitions, which are not related to the emission of explicit messages but to temporal constraints (validity period, expiration date, etc); they are triggered automatically after a time interval is elapsed or after some date is reached.

Business protocols offer automatic reasoning mechanisms with many applications, such as correctness verification, compatibility testing, etc. However they are not often specified in real life services. Potential reasons include lack of time during implementation or uncontrolled evolution. A solution is then to infer this protocol from the conversation logs of a service. Direct applications are re-engineering issues, such as implementation correctness checking or service evolution. Once automated this extraction process could be applied in service discovery architectures [START_REF] Denaro | Towards self-adaptive service-oriented architectures[END_REF] for automatic service composition or replacement.

Discovering service protocols includes many technical challenges: cleaning logs from "noise", identifying the different conversations, defining assessable models, developing refining tools for an interactive extraction, etc. The first contribution to this problem has been proposed in [START_REF] Motahari Nezhad | Protocol discovery from imperfect service interaction logs[END_REF], but relates only to untimed business protocols. With the importance of temporal aspects in real life services it becomes crucial to extend this work to timed business protocols, which contain both explicit and timed transitions.

This paper presents our approach for extracting timed transitions from conversation logs. 4 We define a class of patterns called proper timeouts which reveal the presence of timed transitions in the protocol. We propose a characterization of the set of proper timeouts satisfied by the logs, which leads to a polynomial extraction algorithm. This work is an extension of [START_REF] Motahari Nezhad | Protocol discovery from imperfect service interaction logs[END_REF], and both take part in ServiceMosaic international project (http://servicemosaic.isima.fr) which aims at developing a platform for modeling, analysing and managing Web services [START_REF] Benatallah | Service mosaic: A model-driven framework for web services life-cycle management[END_REF].

Associating Patterns with Timed Transitions

We define an episode as a sequence of two message names. Given an episode α = m, m ′ , an occurrence of α is a sequence of two consecutive occurrences of m and m ′ in the logs. The occurrence duration of an episode occurrence is the difference between the message timestamps. The minimal (respect. maximal) occurrence duration of an episode is the smallest (respect. greatest) occurrence duration of all its occurrences. The occurrence duration interval (ODI) of an episode is the interval which includes all its occurrence durations. The minimal (respect. maximal) occurrence duration of a set of episodes is the minimum (respect. maximum) of all the minimal (respect. maximal) occurrence durations of these episodes. The occurrence duration interval (ODI) of a set of episodes is the interval which includes all the occurrence durations of these episodes. For each message m, we denote by P m the set of episodes whose first message is m.

Given two sets of episodes A and B, we say that A precedes B (denoted by A ≺ B) if ODI(A) is before ODI(B). 5 We say that A and B are not comparable (denoted by A B) if A ⊀ B and B ⊀ A. Given A, B ⊂ P m , we show that: if there exists a timed transition between the state from which the transitions corresponding to the elements of A are going out, and the one from which the transitions corresponding to the elements of B are going out, then A ≺ B.

We define a proper timeout as a triplet P T (m, A, B), where m is a message and A, B ⊂ P m . We say that logs L satisfy the proper timeout P T (m, A, B), which is denoted by L P T (m, A, B), if:

   A ≺ B ∀ α ∈ P m \ (A ∪ B), {α} ∦ A ∪ B ∀ Z ∈ {A, B}, ∀ X, Y ⊂ Z (X, Y = φ), (X ∪ Y = Z) ⇒ (X ⊀ Y ) . (1)
Given a message m and A, B ⊂ P m , we show that: if there exists a timed transition in the protocol, between two states s 1 and s 2 such that the sets of transitions going out of s 1 and s 2 respectively are in bijection with A and B, then there exist A ′ ⊆ A and B ′ ⊆ B such that L P T (m, A ′ , B ′ ). Since each timed transition involves the satisfaction of a proper timeout, we can find all of them. However we can discover more proper timeouts than there are timed transitions, if some messages always take longer to be sent or received than messages associated with other transitions of the same state. Thus we will say that: a satisfied proper timeout reveals the presence of a potential timed transition.

We show that: for practical purposes, proper timeouts are the best possible representations of timed transitions. That justifies the relevance of the development of a timed transition discovery method based on the research of the proper timeouts satisfied by the logs.

Extracting the Proper Timeouts

The complexity of a basic "generate and test" method for extracting proper timeouts is exponential. Instead, we propose a nice characterization of the set of satisfied proper timeouts, which leads to a polynomial algorithm. This characterization, formalized by Theorem 1, states that: the proper timeouts satisfied by the logs and related to message m are exactly given by the pairs of consecutive elements of the partition of P m satisfying (2). Thus, partitioning all sets P m gives us all the proper timeouts satisfied by the logs.

m , . . . , P (im) m } a partition of P m . The following assertions are equivalent:

P (1) m ≺ P (2) m ≺ . . . ≺ P (im) m ∀ 1 ≤ i ≤ i m , ∀ X, Y ⊂ P (i) m (X, Y = φ), (X ∪ Y = P (i) m ) ⇒ (X ⊀ Y ) . (2) ∀ 1 ≤ i < i m , L P T (m, P (i) m , P (i+1) m ) ∀ A, B ⊂ P m , L P T (m, A, B) ⇒ ∃ 1 ≤ i < i m , A = P (i) m , B = P (i+1) m . (3)
We propose a polynomial algorithm, called partitionP m , for constructing this partition in an incremental way. The input of algorithm partitionP m comprises a message m, the set P m , and the ODIs of all episodes in P m . The output is the partition Π of P m satisfying (2). Π is constructed by inserting one by one the elements of P m in such a way that ( 2) is satisfied at each step. In order to describe the general step of the algorithm, let us consider that Π is already partly constructed. Let α be an episode of P m not yet considered. A single pass is made over the partition to determine (i) whether the ODIs of some elements of Π overlap ODI(α), and (ii) between which sets of Π α is situated according to ≺. If there is no overlap, a new set containing α is created and inserted into the partition in compliance with ≺. If the overlap takes place with only one element of Π, α is simply inserted in this set. If the overlap occurs between α and several parts of Π, they are necessarily consecutive according to ≺; as such they are merged and α is inserted into the resulting set. As for each episode α ∈ P m only one pass is made over the partition, the complexity is O(|P m | 2 ).

The global method for extracting all the proper timeouts satisfied by the logs is divided in two steps. The first one is a preprocessing of the data, performed in order to obtain the set of messages, the set of episodes, and the ODIs of all episodes. A single pass is made over the logs, during which the occurrence duration of each sequence of two consecutive messages is calculated. The second step consists in constructing all sets P m , and running algorithm partitionP m for each of them. The logs' size being far greater than the number of episodes, the first step is the most costly in term of running time. Thus the complexity of the global algorithm is O(|L|).

We have implemented our discovery process to test its scalability. In order to easily have a big amount of data, we have also implemented a log generator which creates conversation logs from a given business protocol by mimicking the behaviour of a service. Results of our experiments confirm the complexity results we have established formally. The final test will be to run our algorithm on real-life data in further experiments.

Theorem 1 .

 1 Consider a mesage m, i m ∈ IN * , and {P (1) m , P

This work is partially funded by the ANR project Service Mozaïc (2007-2009, JCJC06 134393) and by the EU Framework 7 STREP project COMPAS (215175, FP7-ICT-2007-1).

Proceedings of CAiSE'08 Forum

Technical results are presented in an extended version of this paper[START_REF] Devaurs | Timed transition discovery from web service conversation logs (extended version)[END_REF].

≺ is a strict order relation on sets of episodes.


Michael Granitzer
email: mgranitzer@tugraz.at

Andreas S Rath
email: arath@know-center.at

Mark Kröll

Christin Seifert
email: cseifert@know-center.atdorisipsmillerm2n-consulting

Didier Devaurs
email: ddevaurs@know-center.at

Nicolas Weber
email: nweber@know-center.at

Stefanie Lindstaedt

Machine Learning based Work Task Classification

Increasing the productivity of a knowledge worker via intelligent applications requires the identification of a user's current work task, i.e. the current work context a user resides in. In this work we present and evaluate machine learning based work task detection methods. By viewing a work task as sequence of digital interaction patterns of mouse clicks and key strokes, we present (i) a methodology for recording those user interactions and (ii) an in-depth analysis of supervised classification models for classifying work tasks in two different scenarios: a task centric scenario and a user centric scenario. We analyze different supervised classification models, feature types and feature selection methods on a laboratory as well as a real world data set. Results show satisfiable accuracy and high user acceptance by using relatively simple types of features.

I. Motivation

Knowledge-intensive work plays an increasingly important role in organizations of all types. Workdays are characterized by processing and manipulating more and more digitized information. So far, indexing and search tools have been employed to make the stored information accessible. However, people realized, that systems have to take the knowledge worker's context into account to be truly supportive. As recently discussed in the information retrieval community [START_REF] Callan | Meeting of the minds: An information retrieval research agenda[END_REF], the emphasis of future information retrieval applications ought to be put on exploiting the user's current context in order to increase the accuracy of retrieval results.

Knowing the knowledge worker's current work activities, i.e., the work task the user resides in, allows various ways for support. Search queries can be generated based on the user context, submitted and the results can be ranked according to the user's profile and context. Furthermore, guidance through the work process may be provided automatically and declared experts may be suggested. Other research groups have recently started to examine approaches that are capable of identifying the current work task of a user. The TaskTracer project [START_REF] Dragunov | Tasktracer: A desktop environment to support multi-tasking knowledge workers[END_REF] at Oregon State University monitors human computer interactions with computer desktops and provides data for the machine learning system TaskPredictor [START_REF] Shen | A hybrid learning system for recognizing user tasks from desktop activities and email messages[END_REF]. Three major processing steps are incorporated into the system: (i) feature selection by mutual information, (ii) classification based on confidence threshold and (iii) classification with hybrid Naïve Bayes and SVM classifiers.

The SWISH [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF] system, developed at Microsoft Research, approaches user task predictions by clustering desktop windows on (i) window titles and (ii) window sequence. The basic assumption is that windows related to each other belong to the same task and that relations can be found by analyzing the window titles. Drezde et al. [START_REF] Dredze | Automatically classifying emails into activities[END_REF] applied various, similarity based methods to categorize emails by activities yielding promising results. Kellar et al. [START_REF] Kellar | A field study characterizing web-based information-seeking tasks[END_REF] noted that the knowledge of a user's current task type allows information filtering systems to apply useful measures for user interest. They focused on discovering features and studying their predictability for specific task types in web browsers. While previous work demonstrated the feasibility of work task classification, important properties like differences among learning techniques, feature representation, and predictable kinds of tasks are yet unclear.

In this work, we analyze different machine learning techniques and feature types for work task classification and compare them to results reported in literature. Due to missing standard and real world test data sets we present our own data acquisition strategy and the underlying data model which contains content and interaction based feature types. Based on the recorded real world interaction patterns, we

• compare the accuracy of standard machine learning techniques

• compare the impact of entropy based feature selection

• analyze the impact of content based and interaction based feature types

• compare different scenarios for work task classification The data sets used for evaluation reflect two different scenarios. In the first scenario, referred to as task centric scenario, we defined a set of tasks users had to work on. After a training phase, the system automatically identifies the current work task from this set. Since task categories are given a-priori, we refer to this scenario as task centric scenario. This scenario allows us to analyze whether our approach is capable to identify the same tasks over different groups of users, if trained accordingly.

In scenario two, referred to as user centric scenario, work tasks are guessed a-priori by the system and labeled by the user afterwards. Our task here is to accurately predict the user given label, if a similar task occurs again. Since the user is allowed to give what ever label she wants, this scenario allows us to evaluate whether our approach can capture the work behavior of a single user.

Our results demonstrate to favor the Naïve Bayes and the k-Nearest Neighbor approaches over Support Vector Machines and support findings of other groups, that window title based features are the most suitable form of representation. Overall, our work shows the maturity and applicability of work task classification in practical, real world scenarios.

The paper is structured as follows: The methodology that we followed to create a resource for task classification is described in Sections II. Data sets used, test design and experimental results for the task centric scenario are presented in Section III, while results on the user-centric scenario are presented in Section IV. The findings are discussed and compared to two other task classification approaches in Section V. Section VI contains concluding remarks and an outlook on future work.

II. Work Pattern Acquisition

This section describes the steps that are necessary getting from the recorded, raw data to the data that is used in our experiments and which may be used in a real world application. Therefore, we had to address that (i) the amount of data quickly reaches a critical value, if every single click is monitored, (ii) data is heterogeneous in nature, e.g., sequence data, textual contents, nominal values, (iii) data is noisy and (iv) interaction patterns tend to be very user specific. In order to cope with these challenges, we introduce a data model that allows data preprocessing, data aggregation and data abstraction.

A. Data Acquisition

Data acquisition starts on the lowest level on which the user interaction context is automatically captured. The user interaction context comprises all interactions of the user with resources, applications and the operating system on the computer desktop. The data about these interactions are referred to as events. Currently, monitored low level events are keystrokes, mouse movements and mouse clicks. Furthermore, for some applications it is possible to record the content managed by the application. In utilizing these functionality it is possible to access the content directly, when the user focuses such a supported application. Filename, author, organization, used template, document structure, whole document content, page number, window title or even just the content that the user currently sees on the screen are only small pieces of the data we ground the context construction on. For a more detailed description of the monitoring process, we refer to [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF][START_REF] Rath | Lowlevel event relationship discovery for knowledge work support[END_REF].

B. Data Model

Monitoring low level events results in massive amount data, intractable to be analyzed by machine learning techniques in near real time. So the question on how to cope with this mass of data has to be addressed.

Figure 1 depicts our aggregation model and transformation techniques used for aggregating low level events to work tasks. In a first step, a predefined static rule set aggregates low level event sequences to so-called event blocks which can be understood as intermediate representation form which groups together interaction on the same resource. An example of such a static mapping can be as follows: The user opens MS Windows and writes a paragraph, yielding numerous mouse click and keystroke events. This set of events is combined to an event block called edit a word document. The actual structure depends on the nature of an event block, i.e., which types of events it was aggregated over, whether an application provides particular data or not. Especially application-independent event blocks, like for example console events, rarely contain data at all. In a second step before classifying work tasks, the event blocks are automatically clustered based on their content resulting in event block clusters. Event blocks that share a significant amount of words are likely to end up in the same cluster. The event block clusters are validated and labeled by the user thus becoming task instances and the ground truth for learning the users task model.

C. Data Description

In our experiments we used following four fields for the event blocks: Application Name, Content, Window Title and Semantic Type.

Besides the semantic representation of an event block, the interior structure of an event block consists of 31 different fields, 13 general and 18 application-dependent ones. Taking only 4 out of 31 fields into account needs explanation and justification. Analysis of the field characteristics showed that fields containing content (non-empty fields) are unevenly distributed. The majority of the empty fields are application dependent. Furthermore, we opted for those fields providing data that is uniformly distributed over all event blocks, so to say adequately covering the entire data set.

The field Application Name, abbreviated as A, contains the name of the application the user is working with. For instance, if the user reads a document in Adobe Acrobat Reader, the field will contain the value acrord. Sensors for following applications have been implemented: MS Word, MS PowerPoint, MS Excel, MS Internet Explorer. In addition, a file system sensor, a clipboard sensor and a generic Windows XP system sensor allow for 14 different entries in the field Application Name.

The field Content, abbreviated as C, stores the language dependent content of the current window, which can be the text on the current MS PowerPoint slide or the content of the website the user is viewing. In our data set German and English content occurs, even mixed, e.g., a webpage with German content and English navigation elements. The raw Content field includes also special characters, markup and end-of-line characters.

The field Window Title, abbreviated as W, contains title of the current window. Depending on the application Window Title may (e.g. MS Word) or may not (e.g. Novel Groupwise, new email window) include the name of the application.

The field Semantic Type, abbreviated as S, stores a rulebased generated type taking on three different values. The values indicate whether a document is (i) read or (ii) edited by the user, or whether the state is (iii) unknown. The assignment of a semantic type is application dependent. Only MS Word, MS PowerPoint and MS Excel sensors are capable of allotting the semantic types (i) reading or (ii) writing. The discrimination is based on simple rules. If one key stroke is detected, the whole event block is classified as writing, otherwise as reading. Event blocks generated by other applications receive the semantic type unknown.

D. Data Preprocessing

Textual raw contents in the fields A, C, and W have been preprocessed by the following 4 steps (in this sequence): (i) remove EOL (end-of-line), (ii) remove markup, e.g., \&lg and ![CDATA, (iii) remove all characters but letters, (iv) remove German and English stopwords. As stated above the fields may contain words from mixed languages, so that stemming algorithm are hardly applicable. Preliminary experiments did not show any significant differences in classification performance and thus we omitted stemming. For each event block we formed a 'bag of words' representation for all fields and calculated the TF-IDF 1 measure. We used the Information Gain (IG) measure to rank features by their discriminative power. Information Gain is among the most common measures for feature selection in machine learning. 1 term frequency-inverse document frequency

E. Training Data Acquisition

Two different scenarios have been considered to acquire training data. Scenario one utilizes a task centric point of view. Herein, we defined a fixed set of tasks a controlled user group has to work on. The user marks the begin of a task and the end of the task after its completion. This allows us to explore whether our system is capable to correclty identify the same tasks over a different group of users, i.e. that it generalizes over different working behaviours. The second scenario, named user centric scenario, can be seen from a single user's perspective. To acquire our test data set, the untrained systems starts to record user interactions, aggregate them to event blocks, cluster those event blocks and provide the cluster result as a-priori task suggestion to the user. The user labels the task suggestions and may manually rearrange event blocks via the user interface. This experiment allows us to analyse whether our approach can capture the work behaviour of a single user.

The following sections outline in detail the data set structure, analyse data set properties and provide accuracy results for different machine learning techniques.

III. Task Centric Scenario

A. Data Set Structure

In the task centric scenario we selected five typical task models from our domain for the experiment. Three task models were routine tasks (Task 1: "Filling in the official journey form", Task 2: "Filling in the cost recompense form for the official journey", Task 3: "Creating and handing in an application for leave") and two were knowledge-intensive tasks (Task 4: "Planning an official journey", Task 5: "Organizing a project meeting"). Before we started the experiment we did an online questionnaire to confirm that the descriptions of the task models are clear to the users and that the routine task are tasks that have already been executed by the employees several times before. The dataset we gained by the methods and techniques presented in the previous sections has 218 task instances (Task 1: 55, Task 2: 45, Task 3: 51, Task 4: 52, Task 5: 15) from 14 participants. Half of the task instances were collected on a single laboratory computer common to all users and the other half on the employees' own work station computers.

Our experiment was carried out in the knowledgeintensive domain of the applied research. It was preceded by an analysis phase, during which several requirements were defined, by interviewing knowledge workers. Users required to know what kind of data was recorded to be able to access and modify it and that the evaluation results were anonymized. They could practice with the recording tool for a week before the experiment in order to reduce the bias of unfamiliarity during the experiment. This study/experiment was exploratory, the comparison was within subjects and the manipulations were achieved by the executed task (five different tasks).

Manipulation -Task: The manipulation resulted from varying the tasks themselves. During a preliminary meeting, the participants of the experiment agreed on a selec-tion of five tasks typical of the knowledge worker domain. These tasks had different characteristics in terms of complexity, estimated execution time, number of involved resources or granularity. A short questionnaire was issued before starting the experiment to make sure that the probands understood the tasks they had to perform, and also to have them thinking about the tasks before they actually executed them.

During the experiment, for capturing the users' usage data, we have used multiple sensors [START_REF] Rath | Context-aware knowledge services[END_REF] that record the user interactions with resources and applications on the computer desktop. Table 1 gives an overview of the number of instances, the number of attributes (the number of different terms in the term and the number of classes for selected field combinations for the used dataset (Dataset T).

B. Experimental Data

Constructing training instances for the machine learning algorithms is done on the task level. This means that each task represents a training instance for a specific class to be learned. A class corresponds to a specific task model. Having multiple task models hence results in a multi-class classification problem. A training instance for a class is built from features and feature combinations for a task. An example for the window title feature is the construction of a 'bag of words' consisting of all window titles of applications the user has interacted with during the execution of a task.

Table 1:

Overview of the number of attributes, instances and classes for all tasks for selected field combinations (columns) for Dataset T of the task centric scenario.

C. Experimental Design

In our experiment we evaluated the influence of three parameters on the task classification performance: (i) the number of features, (ii) the classification model and (iii) the feature category. The WEKA toolkit [START_REF] Witten | Data Mining: Practical machine learning tools and techniques[END_REF] and the WEKA integration [START_REF] El-Manzalawy | WLSVM: Integrating lib-SVM into Weka environment[END_REF] of the libSVM [START_REF] Chang | LIBSVM: a library for support vector machines[END_REF] provided us with the tool set to study the performance of the Naïve Bayes (NB), Linear Support Vector Machine (SVM) with cost parameter c ∈ {2 -5 , 2 -3 , 2 -1 , 2 0 , 2 1 , 2 3 , 2 5 , 2 8 , 2 10 }, and k-Nearest Neighbor (KNN-k) with k ∈ {1, 5, 10} algorithm. The interval for the cost parameter was chosen according to the lib-SVM practical guide at [START_REF] Chang | LIBSVM: a library for support vector machines[END_REF].

For each classifier algorithm l ∈ L and each feature category f ∈ F we selected the g attributes having the highest IG value to obtain our dataset. As values for g 50 different measure points were used. Half of them were equally distributed over the available number of attributes with an upper bound of 5000 attributes. The other half was defined by G = {3, 5, 10, 25, 50, 75, 100, 125, 150, 175, 200, 250, 300, 500, 750, 1000, 1500, 2000, 2500, 3000, 3500, 4000, 5000, 7500, 10000}. These measuring points were chosen because of two reasons:

(i) research in the task detection area reported that good results have been achieved for a lower number of attributes, more specifically between 200-300 attributes [START_REF] Shen | A hybrid learning system for recognizing user tasks from desktop activities and email messages[END_REF][START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF] and (ii) to also investigate the task classification performance of the learning algorithms for higher number of attributes as well. Stratified 10-fold cross-validation was applied and statistical values for each fold were computed. In addition, the mean and standard deviation of all values were calculated across all folds. We measured the accuracy (a) of the used algorithms, the number of attributes (g), the micro precision (p) and micro recall (r). In comparison to the user centric scenario there was no evaluation of the Semantic Type feature.

D. Results of the Task Centric Scenario

Table 2 shows the results for the task centric scenario. For each field combination/classifier pair we selected the number of features, where the accuracy of the classifier reached a maximum. If two values coincided at maximum, the combination with fewer features was chosen. Table 2 displays the best results achieved in terms of accuracy and corresponding features for each field combination/classifier pair. Maximal performance values for each field combination are highlighted in boldface. In Table 3 the three topmost values for each dataset are listed allowing a better comparison of best-performing classifiers, the field combination, the mean accuracy Â, the standard deviation of the accuracy σ(A) and the number of features.

Table 3: Overview of the best results for the task centric scenario. Showing the field combination (f ), the classifier (l), the accuracy ( Â), the standard deviation (σ(A)) and the number of features (g).

RANK

IV. User Centric Scenario

A. Data Set Structure

In the user centric scenario we recorded the work behaviour of a single user in a governmental domain over a period of two months. The user was requested to label the clustered event blocks with her current work task. If no label or an incorrect label was automatically suggested the correct label was assigned by the user. In this scenario task labelling is a subjective matter; in contrast to our task centric scenario and other approaches [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF][START_REF] Dredze | Automatically classifying emails into activities[END_REF][START_REF] Dragunov | Tasktracer: A desktop environment to support multi-tasking knowledge workers[END_REF].

Such unrestricted labelling yields to syntactically different tasks with the same semantic meaning. One such example is author an article vs. write an article. To harmonise this syntactical heterogeneity, we manually identified misspellings in a post processing step and aggregated user defined labels to the task categories outlined below. Hence, four different task sets have been created from the acquired data. Set UI is activity driven, i.e., giving priority to the own tasks at hand and reduces the user labelled tasks to the 5 most important task.

Set UII is process driven, i.e., a well defined step in a process and incorporates a semantic division of the event blocks.

Set UI consists of the following 5 tasks:

1. email -writing, reading, archiving email messages 2. paper -writing papers and articles 3. research -research to a given field 4. documentation -writing project documentation and protocols

information -collect information

Set UII consists of the following 4 sem antic tasks:

1. com -communication related event blocks, such as reading and writing emails 2. org -organisational and administrative things, such as writing timetables, make appointments 3. write -writing documents, articles, papers 4. read -reading internet pages, documents etc.

B. Data Set Analysis

We conducted experiments using different combinations of event block fields (see Section II-C). Depending on the combinations, the necessary field contents are concatenated to one string and preprocessing steps are applied. Further, the user labels are mapped to task labels according to Section II-E yielding Dataset UI and UII. There are cases in which event blocks are removed from the data set. Firstly, if no mapping from the user label to a task is found. Secondly, if the instance contains no data at all. Hence, field combinations differ in the number of instances. Table 4 gives an overview of the number of instances, the number of attributes (the number of different terms in the term vector) and the number of classes for selected field combinations for the used datasets.

C. Experimental Design

In our experiments we evaluated the influence of three parameters: (i) the number of features, (ii) the classification model and (iii) the field combination.

We compared three classification models -Naïve Bayes (NB), Support Vector Machines (SVM) and k-Nearest Neighbour (KNN). A Naïve Bayes classifier was chosen because of its simplicity and effectiveness. Furthermore, Naïve Bayes relies on the global data distribution, being robust and therefore less prone to noise. SVMs, besides performing well with textual data [START_REF] Joachims | Text categorization with support vector machines: learning with many relevant features[END_REF], put more weight to training data close to the decision boundary. Here, a linear kernel was applied -according to [START_REF] Dumais | Inductive learning algorithms and representations for text categorization[END_REF] the corresponding feature space possesses enough discrimination power. As representative for a nonlinear, more local classifier, we opted for the KNN, and set the number of neighbours k ∈ {1, 5, 10} to achieve different complexities of the decision boundary. The WEKA machine learning library [START_REF] Witten | Data Mining: Practical machine learning tools and techniques[END_REF] provided the necessary tools. The WEKA integration [START_REF] El-Manzalawy | WLSVM: Integrating lib-SVM into Weka environment[END_REF] of the libSVM [START_REF] Chang | LIBSVM: a library for support vector machines[END_REF] allowed the usage of a SVM as well.

Cross-validation has been used to obtain statistical sound experimental results for evaluating possible combinations of fields, number of features and classification models. L represents the set of all classifiers, L = {KNN-1, KNN-5, KNN-10, NB, SVM-lin}. Fifteen different field combinations P were taken into account resulting from forming the power set P ∈ Π(F ) \ ∅, where F = {A, C, S, W}. For each classifier l ∈ L on each field combination f ∈ P we selected the g attributes having the highest IG value to obtain our dataset. The value g was set to g = 1, 2, 3, . . . , 100% of all available attributes (the total number of attributes depends on the field combination). Stratified 10-fold cross-validation was applied and statistical values for each fold were computed. We evaluated the accuracy of the used techniques and for comparison with related work precision/recall measures. In addition, mean and standard deviation of all values were calculated across all folds. 5

D. Results of the User Centric Scenario

Tables 5 and6 show the results for the Dataset UI and UII. For each field combination/classifier pair we selected the number of features, where the accuracy of the classifier reached a maximum. If two values coincided at maximum, the combination with fewer features was chosen. Tables 5 and6 display the best results achieved in terms of accuracy and corresponding features for each field combination/classifier pair. Maximal performance values for each field combination are highlighted in boldface. In Table 7 the three topmost values for each user centric dataset are listed allowing a better comparison of bestperforming classifiers, the field combination, the mean accuracy Â, the standard deviation of the accuracy σ(A) and the number of features.

Table 7: Overview of the best results for the two user centric datasets Dataset UI and Dataset UII. This table displays the field combination (f ), the classifier (l), the accuracy ( Â), the standard deviation (σ(A)) and the number of features (g) for the three topmost accuracy values.

SET RANK f l  σ(A) g 1 SC KNN-

V. Discussion

The results of our experiments need to be interpreted in order to be applicable in similar settings. Our analysis concentrates on determining the impact of feature selection, the field combination and the classification model.

A. Effect of Feature Selection

Ranking the features by discrimination capability and handing them over allows to build classification models that achieve high accuracies. In the evaluation of the task centric secnario the best runs of the classifiers resulted from only up to 10% (25 to 300 attributes) of the maximum number of attributes. The only exception was the CW feature combination which used 750 attributes (30% of all attributes). The best performance in terms of accuracy has been achieved with 300 attributes (see Table 3). The results in Table 7 similarily reflect the effectiveness of feature selection. Regarding the evaluation of the user centric scenario only 2-6% of the total number of features sufficed for achieving the highest accuracy values. Our findings confirm the one of [START_REF] Shen | A hybrid learning system for recognizing user tasks from desktop activities and email messages[END_REF] and [START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF], that successful work task classification requires rather few features.

B. Effect of Field Combination

Each field is capable of adding information that might be valuable for separating the classes. Although the datasets differ from each other in terms of task classes and semantics, the single fields Content and Window Title performed best in most runs. Consequently, the same fields occur in field combinations that reached highest accuracies. In contrast, fields that performed poorly as individuals, e.g., the Application Name, seldom boost the classification in combination with others. Considering the overall performance, we conclude that accurate classification results can be achieved by taking only the Window Title into account confirming the outcomes of SWISH. We refer to the results of the task and user centric scenario to the Tables 2, 3, 5 and 6 respectively. Our results reveal that nearly all classification models reached top accuracies when using the window title tield W.

C. Effect of Classifier

In case of the user centric scenario, KNN-5, KNN-1 and linear SVM's had an advandtage over the Naïve Bayes classifier (see Table 7) with rather low differences. In the task centric scenario, again KNN-5 achieves rather good results. In contrast to the user centric scenario however, linear SVM stay behind to a large degree and Naïve Bayes achieve the best results (see Table 3). Noteably, the differences between Naïve Bayes and SVM runs in the user centric scenario are smaller compared to the differences in the task centric run. This is especially true for runs where the SVM outperforms Naïve Bayes. In constrat to that, differences between Naïve Bayes and SVM are larger in the task centric scenario, especially in the best performing runs. Overall, our results point the conclusion that Naïve Bayes and k-NN classifiers are more robust than SVM's regarding work task classification.

D. Comparison with other Approaches

Firstly, we address the main differences to the TaskPredictor project (see [START_REF] Shen | A hybrid learning system for recognizing user tasks from desktop activities and email messages[END_REF] for further detail). (i) The task labelling is restricted by offering only choices coming from a drop down box. In our user centric scneario the user was free in labelling her tasks in her own, personal way. (ii) Only window title, file path and URL are taken into account for the prediction task. (iii) There are no experiments mentioned considering different numbers of features, always used a fixed number of features was used, i.e., 200 features. (iv) The prediction results achieved a precision of 0.8 (see Table 8). It is not determinable, whether micro or macro precision was calculated. Furthermore, they introduced the term coverage specifying the degree of discarding certain test examples from being classified.

Secondly, we compare our approach to the SWISH system (see [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF]). The features in SWISH are restricted to the terms obtained from window titles. When focusing on the optimisation of the recall measure, they achieved a precision of 0.49 and a recall of 0.72. In Table 8 the key data of both evaluations is compared. The number of features used was On the whole, we achieved significantly better precision/recall values (see Table 8). Partly responsible for the performance decrease could be the differing granularity of the task classes, being more general in our case. In contrast to the other approaches, different field combinations and their influences on the task categorisation were analysed. Based on our findings, we confirm the field choice W of TaskPredictor and SWISH.

VI. Conclusions and Future Work

Our contribution comprises three major statements that are based on a thorough analysis of the conducted experiments.

• Task classification can be accurately performed by applying machine learning techniques to the captured user interaction context. This we showed in two independent scenarios (task and user centric) for different tasks and users in which we reached a high accuracy in detecting the user's tasks with our approach.

• Our findings confirm the feature type choice of three other research groups, which is the good discriminative power of the window title feature.

• We highlighted that standard machine learning techniques suffice to extract the context in order to support the knowledge worker.

In the presented work we studied two domain independent datasets for training and evaluation: (i) from a large scale laboratory experiment with 14 participants in which we put the focus on tasks and (ii) from a single user of a real world setting who had complete freedom in labeling the tasks. Since two datasets are not sufficient for reliably generalizing our findings the acquisition of more data in other settings with multiple tasks and users is currently in progress. We are going to evaluate our methodology on this enlarged data set.

Our design allows for extending the capability of the currently available sensors as well as easiliy adding further sensors, if it is required. Still, it would be interesting to add sensors that are capable of capturing telephone conversations or meeting discussions. Monitoring the physical state of knowledge workers to enrich the context by an additional dimension is not far fetched any more.

Finally, a reassessment of the feature creation process is to be considered. Instead of mixing features of all fields, a separating them in combination with different weighting schemes could be conceivable. A second approach would be to take structure into account and applying SVMs, where this additional information can be embedded into the kernel.

Future work also has to consider general, user independent task models and boostrapping methods. Both aspects are central for high user satisfaction. Therefore, we are working on a ontology-based user interaction context model for representing, automatically capturing and reasoning about the user's context. Exploiting the ontology peculiarities and structure for feature engineering in order to enhance task detection performance seems to be a fruitful extension in this direction. Furthermore, exchanging classification models between knowledge workers, especially between those with similar work styles and tasks may help to overcome the data sparsity problem. Both extensions raise a number of interesting questions and opportunities for further research in the areas of knowledge work, personal information mangement as well as in applied machine learning.

Figure. 1 :

 1 Figure. 1: Relationships between events, event blocks and tasks for context detection.

Table 2 :

 2 Classifier Performance for all field combinations for Dataset T (task centric). The table shows the maximum accuracy (averaged over all cross-validation runs) and the corresponding number of selected features.

		KNN-1	KNN-5	KNN-10	NB	SVM-lin
	A	37.12% (5)	35.02% (24)	36.23% (24)	39.94% (24)	42.16% (24)
	C	63.38(125)	62.88% (75)	63.23% (125) 62.79% (75)	60.15% (75)
	W	73.92% (75)	73.98% (100) 77.53% (75)	78.87% (100)	74.37% (75)
	AC	64.16% (200) 64.70% (150) 64.72% (125) 62.88% (2496) 62.97% (250)
	AW	77.10% (75)	79.33% (75)	78.44% (75)	77.81% (200)	75.28% (75)
	CW	76.13% (250) 75.76% (200) 75.28% (175) 82.58% (750)	76.19% (50)
	ACW 74.81% (200) 74.78% (250) 75.17% (200) 83.51% (300)	76.60% (50)

Table 4 :

 4 Dataset UI & UII: Overview of the number of attributes, instances and classes for all event blocks for selected field combinations (columns) for Dataset UI and UII (rows).

	SET f	A	C	S	W	ACSW
		#ATTRIB	14	3601	4	253	3706
	UI	#INST	349	170	77 307	349
		#CLASSES	5	5	5	5	5
		#ATTRIB	14	3718	4	356	3827
	UII	#INST	406	196	77 266	406
		#CLASSES	4	4	4	4	4

Table 5 :

 5 Classifier Performance for all field combinations for Dataset UI. The table shows the maximum accuracy (averaged over all cross-validation runs) and the corresponding number of selected features.

		KNN-1	KNN-5	KNN-10	NB	SVM-lin
	A	55.06% (7)	55.03% (5)	55.03% (5)	55.03% (5)	55.02% (5)
	C	72.35% (144)	74.12% (144)	73.53% (180)	65.29% (144) 69.41% (72)
	S	44.29% (3)	44.29% (3)	44.64% (3)	44.46% (1)	42.86% (1)
	W	73.30% (168)	73.26% (158)	73.60% (156)	69.68% (252)	71.95% (40)
	AC	65.29% (864)	65.59% (720)	64.49% (1224) 65.62% (252) 65.04% (216)
	AS	55.32% (13)	55.35% (10)	55.34% (6)	55.04% (4)	55.03% (5)
	AW	70.81% (250)	71.06% (164)	71.08% (172)	67.36% (62)	71.07% (60)
	SC	74.51% (108)	73.33% (108)	73.92% (72)	66.44% (144) 67.75% (108)
	WC	69.25% (2232) 69.22% (2700)	68.94% (2988) 68.62% (108)	71.23% (360)
	WS	72.02% (154)	72.66% (160)	71.97% (244)	70.39% (244) 72.39% (40)
	AWC	67.61% (1813) 67.34% (629)	67.34% (1739) 66.18% (777)	68.79% (259)
	AWS	69.95% (124)	69.66% (122)	69.90% (144)	63.91% (266)	71.66% (68)
	ASC	64.20% (1368) 64.15% (720)	64.18% (1188) 63.30% (684)	65.92% (252)
	WSC	70.59% (2232) 70.88% (3672)	71.18% (3312) 69.57% (288)	71.53% (360)
	AWSC 69.03% (3404) 69.35% (3256) 68.80% (3404) 66.21% (185) 69.31% (296)

Table 6 :

 6 Classifier Performance for all field combinations for Dataset UII. The table shows the maximum accuracy (averaged over all cross-validation runs) and the corresponding number of selected features. The clusters generated in SWISH such as buying a book of Harry Potter do not seem to generalise well. The keywords of this cluster are too specific to allow an abstraction for other books. In our setting we emphasise general task classes as for instance research and write.

		KNN-1	KNN-5	KNN-10	NB	SVM-lin
	A	57.17% (3)	57.18% (3)	57.16% (4)	57.18% (6)	57.16% (5)
	C	72.95% (222)	73.05% (2516)	74.03% (2553) 67.89% (333) 65.82% (74)
	S	74.46% (1)	73.93% (1)	74.29% (1)	74.46% (3)	74.46% (1)
	W	76.42% (188)	75.89% (192)	76.17% (214)	70.27% (64)	74.44% (130)
	AC	65.77% (703)	65.74% (2516)	65.79% (518)	65.27% (37)	64.32% (148)
	AS	57.20% (7)	57.19% (14)	57.17% (8)	57.16% (3)	57.17% (10)
	AW	74.65% (224)	74.40% (226)	74.90% (230)	69.24% (250) 73.62% (108)
	SC	72.29% (3404) 71.24% (3404)	71.71% (3478) 70.29% (37)	66.43% (37)
	WC	71.02% (2394) 71.32% (1672)	71.61% (2394) 63.23% (76)	69.33% (38)
	WS	74.44% (86)	74.48% (96)	74.18% (188)	68.56% (158) 74.74% (74)
	AWC	72.87% (266)	71.70% (304)	72.42% (266)	66.75% (76)	68.69% (76)
	AWS	74.12% (194)	73.70% (184)	73.87% (174)	61.58% (106) 73.88% (102)
	ASC	65.28% (629)	65.57% (1739) 64.79% (1702)	60.38% (148) 65.02% (111)
	WSC	72.43% (2622)	72.98% (3154) 72.44% (1330)	62.69% (76)	68.82% (114)
	AWSC 72.41% (3686) 71.95% (3420)	71.98% (2622) 63.57% (114) 68.73% (190)
	not determinable.

Table 8 :

 8 Comparing SWISH (S), participants FA and FB of the TaskPredictor system, and the results for DataSet UI and UII of our approach. Showing the field combinations (f ), the classification model (l), the number of tasks (t), the number of features (g) as well as the precision π and recall ρ values.

	DATA	f	l	t	g	π	ρ
	T	ACW	NB	5	300	0.95 0.85
	UI	W	KNN	5	156	0.91 0.75
	UII	W	KNN	4	188	0.90 0.74
	SWI	W	PLSI	5	(ALL) 0.49 0.72
	FA	WPU 3 NB/SVM 96	200	0.8 4	N.A.
	FB	WPU 3 NB/SVM 81	200	0.8 5	N.A.

W-window title, P -folder path, U -URI

at a coverage of 0.1

at a coverage of 0.2

Acknowledgement

The Know-Center is funded within the Austrian COMET Program -Competence Centres for Excellent Technologiesunder the auspices of the Austrian Federal Ministry of Transport, Innovation and Technology, the Austrian Federal Ministry of Economy, Family and Youth and by the State of Styria. COMET is managed by the Austrian Research Promotion Agency FFG. The project results have been developed in the DYONIPOS project (www.dyonipos.at) financed by the FFG under the project contract number 810804/9338.


Andreas S Rath
email: arath@know-center.at

Didier Devaurs
email: ddevaurs@know-center.at

Stefanie N Lindstaedt

UICO: An Ontology-Based User Interaction Context Model for Automatic Task Detection on the Computer Desktop

Keywords: H.1.2 [Models and Principles]: User/Machine Systems -Human information processing, H.3.1 [Information Storage and Retrieval]: Content Analysis and Indexing -Abstracting methods, Indexing methods, I.5.2 [Pattern Recognition]: Design Methodology -Classifier design and evaluation, Feature evaluation and selection Algorithms, Performance, Experimentation automatic task detection, user context model, context ontology, user context detection, machine learning

Understanding context is vital' [1] and 'context is key ' [2] signal the key interest in the context detection field. One important challenge in this area is automatically detecting the user's task because once it is known it is possible to support her better. In this paper we propose an ontologybased user interaction context model (UICO) that enhances the performance of task detection on the user's computer desktop. Starting from low-level contextual attention metadata captured from the user's desktop, we utilize rule-based, information extraction and machine learning approaches to automatically populate this user interaction context model. Furthermore we automatically derive relations between the model's entities and automatically detect the user's task. We present evaluation results of a large-scale user study we carried out in a knowledge-intensive business environment, which support our approach.

INTRODUCTION

Massive amounts of digital information are available to us today and are still constantly increasing. No matter if we talk about the information on the world wide web or the numerous documents, presentations, emails, and multimedia files we store on our computer desktops. Intelligent search technologies have been developed to tackle the challenge of finding and refinding information we need for achieving our goals but what is still missing is to understand the context in which information is used and produced. "Understanding context is vital" [START_REF] Greenberg | Context as a dynamic construct[END_REF] and "context is key" [START_REF] Coutaz | Context is key[END_REF] highlight the importance of context. As also recently discussed in the information retrieval community [START_REF] Callan | Meeting of the MINDS: an information retrieval research agenda[END_REF], the emphasis of future information retrieval applications ought to be put on exploiting the user's context in order to increase the accuracy of retrieval results. Detecting the user context thus appears to be of great interest for several research fields.

Two important issues in the context detection area are user context observation and user context analysis. In our previous work we have focused on context observation [START_REF] Rath | Context-aware knowledge services[END_REF], which we briefly summarize in Section 3.1. The focus of this paper is on context analysis and more specifically on automatic task detection. Automatic task detection is an important challenge within context analysis [START_REF] Coutaz | Context is key[END_REF][START_REF] Dey | A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications[END_REF]: if her current task is detected automatically the user can be better supported with relevant information such as learning and work resources or task guidance. A classical approach has been to model task detection as a machine learning problem. However, the focus has been so far on using only textbased features and switching sequences [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF][START_REF] Shen | Real-time detection of task switches of desktop users[END_REF][START_REF] Chernov | Task detection for activity-based desktop search[END_REF][START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF][START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF] for detecting the user's task, which do not rely on sophisticated models. Furthermore standard datasets for the evaluation of task detection approaches are still missing as well as a representative number of controlled user studies.

In this paper we propose an ontology-based user context model for increasing the performance of automatic task detection. Using an ontology-based user context model brings several advantages, such as an easy integration of new contextual attention metadata [START_REF] Wolpers | Tracking actual usage: the attention metadata approach[END_REF], a simple mapping of the raw sensor data into a unified model, and an easy extendability of the user context model with concepts and properties about new resources and user actions. Most impor-tantly we show that using an ontology-based representation of the user's context enhances the performance of automatic task detection in comparison to previous approaches. This is achieved by deriving new ontology-specific features for machine learning algorithms which increase their performance. We also present an evaluation of our approach based on a controlled user study (220 recorded task instances from 13 participants) we carried out in a knowledge-intensive business environment.

The outline of the paper is as follows: In the next section (Section 2) we describe our conceptual model and its realization as an ontology-based user context model. Section 3 elaborates on the mechanisms and techniques utilized to automatically populate the proposed ontology. In Section 4 we present the principles of our ontology-based task detection approach and how to evaluate it. Our experimental results and a comparison of our ontology-based approach to other recent task detection approaches are discussed in Section 5. Section 6 contains concluding remarks and an outlook on future work.

MODELING THE USER'S CONTEXT

Our view of the "user's context" goes along with Dey's definition that context is "any information that can be used to characterize the situation of entities that are considered relevant to the interaction between a user and an application, including the user and the application themselves" [START_REF] Dey | A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications[END_REF]. We specifically focus on the interactions of the user with applications and resources on the computer desktop. We refer to this focused perspective as the user's interaction context, or simply the user's context. Our perspective puts the individual user and her actions into the center of attention, and aims at learning as much as possible about this individual and her actions. Our goal is to study the relations between the user's interactions with the computer system and their meaning and relevance to the user's task.

Various representation formats are available for modeling the user's context. We go along with the conclusion of the surveys from Strang et al. [START_REF] Strang | A context modeling survey[END_REF] and Baldauf et al. [START_REF] Baldauf | A survey on context-aware systems[END_REF] which advocate the use of ontology-based approaches. In our context specifically we argue that an ontology-based context model brings the following advantages: (i) It allows to easily integrate new context data sensed by context observers to map the sensor data into a unified context model. (ii) It can be easily extended with concepts and properties about new resources and user actions. (iii) The relationships between resources on various granularity levels can be represented. (iv) The evolution of datatype properties (i.e., data and metadata) into objecttype properties (i.e., relations between instances of ontology concepts) can be easily accomplished. (v) Being a formal model, it also allows other applications and services to build upon it and to access the encapsulated context information in a uniform way.

Most importantly we will show that the performance of automatic task detection can be enhanced by using an ontologybased context model (see Section 5). This stems from the fact that our approach provides new ways of constructing features (see Section 4.1) for the machine learning algorithms, that enhance performance. [START_REF] Rath | Context-aware knowledge services[END_REF] comprises the event, the event block and the task layers. Information needs can originate from each layer and are fulfilled by resources.

Conceptual Model -

The Semantic Pyramid

The user's context can be seen as a pyramid, the semantic pyramid (see Figure 1), which connects the user's actions with resources acted upon. At the bottom are events that result from single user interactions with the computer desktop. Above are event-blocks, which are sequences of events that belong logically together. At the top are tasks, which are well-defined steps of a process, that cannot be divided into sub-tasks, and in which only one person is involved. The layers of the semantic pyramid represent aggregation levels of user actions. It also integrates the idea of delivering resources that are relevant to the user's actions based on her information needs. For detailed definitions and a more elaborated discussion about the semantic pyramid we would like to refer to [START_REF] Rath | Context-aware knowledge services[END_REF].

UICO: User Interaction Context Ontology

Our user interaction context ontology (UICO) can be seen as the realization of the semantic pyramid with the support of semantic technologies. We follow a bottom-up approach and build the UICO on the basis of our conceptual model, the semantic pyramid, and incrementally add relations when new sensor data or algorithms are added. UICO holds context information that has been sensed and relates the information that is automatically derived from it. By context information we mean the concepts and the relations between concepts of the semantic pyramid, as well as the resource data and metadata that have been captured by the context sensors.

The UICO's intention is to represent the user's interaction context originating from context sensors that automatically observe the user on the computer desktop and the corresponding automatically derived contextual information. If new sensor information is available new concepts and relations can be easily added to the ontology. Our methodology here is to capture and store all concepts and relations we can compute. Based on the application domain in which the UICO is used we decide which relations and concepts are useful and which are not. In the special case of ontologybased task detection we study concepts and relations that are significant for a specific task, i.e., highly discriminative between tasks. Although it would be possible to allow the user to manually add new concepts and relations to the UICO this is not in focus at the moment.

At the moment UICO contains 88 concepts and 272 properties and is modeled in OWL-DL 1 . From these 272 properties there are 215 datatype properties and 57 objecttype properties. The tool used for modeling the ontology was the Protégé ontology modeling tool2 . A visualization of the concept hierarchy in Protege is given in Figure 2.

From a top level perspective, we define in UICO five different dimensions. These are the action dimension, resource dimension, information need dimension, application dimension and user dimension.

Action Dimension. 2). As an example, if the user clicks on the search button of a search engine's web page in a web browser, this user interaction will generate an Event of type WebSearch.

The TaskState concept and its sub-concepts (visualized in the lower left part of Figure 2) are used to model the ways the user does task management and task executions. The types of task states are derived by the Nepomuk Task Management Model [START_REF] Groza | The NEPOMUK projecton the way to the social semantic desktop[END_REF] and integrated into the UICO. With the help of task states UICO can model the user's task handling , i.e., creating, executing, interrupting, finishing, aborting, approving and archiving a task. The behavioral patterns of the user's task handling and task state changes are tracked via the TaskStateChange concept.

The Model concept has been introduced to have connection points to top-down modeling approaches. Currently only one connection point in form of the TaskModel, a sub class of the Model concept, is present. Our TaskModel concept is similar to those defined in the area of workflow management systems or task process analysis.

At the moment, the TaskModel concept can be seen as a way of categorizing a task. An example of instances of the TaskModel and the Task concepts is "Planning a journey" and "Planning the journey to CIAO 2009 workshop" respectively.

Resource Dimension. The resource dimension, visualized in the upper right corner of Figure 2, contains concepts for representing resources on the computer desktop. Specifically we focus on modeling resources used by knowledgeworkers [START_REF] Drucker | Post-Capitalist Society[END_REF] and identified by interviews. Further resource types can be easily added if required. We define 16 different resource concepts. A resource is constructed from the data and metadata captured by the context sensors. The detailed description of the resource discovery and construction processes is given in Section 3.2.

Relations can be defined between concepts of the resource dimension and of the action dimension for modeling on which resources what kind of user actions have been executed. For example, if the user enters a text in a Microsoft Word document, all keyboard entries are instances of the Event concept, connected via the objecttype property isActionOn to the same instance of a TextDocument (and a FileResource) representing that document.

Information Need Dimension. The information need dimension represents the context-aware pro-active information delivery aspect of the UICO. An information need is detected by a set of fixed rules based on the available context information. An InformationNeed concept has properties defining the accuracy of the detection and the importance to fulfill the information need in a certain time-frame. For details about information need detection we refer to [START_REF] Rath | Low-level event relationship discovery for knowledge work support[END_REF].

An information need is associated with the user's action(s) that trigger(s) a rule. Hence a connection between the information need dimension and the action dimension exists. The resource dimension is also connected to the information need dimension, since each resource that helps for fulfilling the user's information need is related via the objecttype property suggestsResource with the InformationNeed.

User Dimension. The user dimension contains two concepts, the User and the Session concepts. The User concept defines basic user information such as user name, password, first name and second name. The user dimension is related to the action dimension in such a way that each Action is associated with a User via the objecttype relation hasUser.

Indirectly the user dimension is also related to the resource dimension and the information need dimension via the action dimension. The Session concept is used for tracking the time of user logins and the duration of a user session in our application.

Application Dimension. The application dimension is a

"hidden" dimension because it is not modeled as concepts in the UICO. This dimension is present is such a way that each user interaction happens within the focus of a certain application, e.g., the user's desktop, Microsoft Word or the Microsoft Windows Explorer. The Event concept holds the information about the user interaction with the application by the datatype properties hasApplicationName and hasPro-cessId. Standard applications that run on the Microsoft Windows desktop normally consist of graphical user interface (GUI) elements. Console applications also have GUI elements such as the window itself, scroll bar(s) and buttons for minimizing, maximizing and closing the application. Most of GUI elements have an associated accessibility object 3 which can be accessed by context sensors. Datatype properties of the Event concept hold the data about the interactions with GUI elements. Later on we show that these accessibility objects play an important role in task detection.

A resource is normally accessed by the user within an application hence there is a relation between the resource dimension and the application dimension. This relation is indirectly captured by the relation between the resource dimension and the action dimension, i.e., by the datatype property hasApplicationName of the Event concept.

Related Work

The UICO is similar to the Personal Information Model Ontology (PIMO) [START_REF] Sauermann | PIMO -a framework for representing personal information models[END_REF] developed in the research project NEPO-MUK 4 in terms of representation of desktop resources. However, for our purposes of automatic context capturing, a limitation of the PIMO is the coarse granularity of concepts and relations. Our UICO is a fine-grained ontology, driven by the goal of representing automatically captured low-level contextual information whereas the intension of PIMO is to enable the user to manually extend the ontology with new concepts and relations to define her environment for personal information management.

The native operations (NOP) ontology 5 which is used in the Mymory project [START_REF] Biedert | Designing a context-sensitive dashboard for an adaptive knowledge worker assistant[END_REF] models native operations (e.g., Ad-dBookmark or CopyFile) on generic information objects (e.g., email, bookmark or file) which are recorded by system and application sensors. Native operations are similar to the UICO's ActionType concepts and more specifically to the EventType concepts. The DataObject concepts describe several desktop resources in a more coarse granular way than we do for the UICO's Resource concepts.

In [START_REF] Xiao | A multi-ontology approach for personal information management[END_REF] a layered and semantic ontology-based framework for personal information management (PIM) which follows the principles of semantic data organization, flexible data manipulation and rich visualization is proposed. The framework consists of an application, domain and resource layer as well as a personal information space. The resource dimension of our UICO can be seen as a combination of the domain and resource layer because resource instances are mapped to concepts of the domain layer. The intention of the approach is to propose a framework for PIM whereas the UICO focuses on representing the user interaction context. The main differences are that in the UICO there are (1) no pre-defined ontology for resources and (2) no concepts or relations for representing user actions.

AUTOMATIC MODEL POPULATION

For a user it is not convenient to manually enter the data about her context on such a fine-granular level, as is defined in our UICO. Hence semi-automatic and automatic mechanisms are required to ease the process of "populating" the ontology. Rule-based, information extraction and machine learning approaches are utilized to automatically populate the ontology and automatically derive relations between the model's entities. We describe in this section how we build instances of concepts and augment relations between the concept instances. We show which kind of sensors we use to observe user interactions with the computer desktop, how to discover resources the user has utilized, unveil connections between resources, and aggregate single user interactions (events) into event blocks and tasks.

Context Observation

Context observation mechanisms are used to capture the user's behavior while working on her computer desktop, i.e., performing tasks. Low-level operating system and application events initiated by the user while interacting with her desktop, are recorded by context observers, which is similar to the approach followed by contextual attention metadata [START_REF] Wolpers | Tracking actual usage: the attention metadata approach[END_REF] and other context observation approaches [START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF][START_REF] Dragunov | TaskTracer: a desktop environment to support multi-tasking knowledge workers[END_REF][START_REF] Van Kleek | A practical activity capture framework for personal, lifetime user modeling[END_REF].

The data about the occurred events is sent as an XML stream to the context capturing framework for processing and analysis. Our targeted domain of the contextual attention metadata collection is the Microsoft Windows XP or Vista environment. Especially, we focus on supporting applications that knowledge workers are using in their daily work. We have identified the following applications to be worthwhile for utilization: the Microsoft Office 2003/2007 suite (Word, Excel, PowerPoint, Outlook), Microsoft Internet Explorer, Novell GroupWise, Mozilla Thunderbird and Mozilla Firefox. Context observers, also referred to as context sensors, are programs, macros and plug-ins that provide the functionality to observe the user interaction behavior on the computer desktop. We distinguish sensors based on the origin of the sensor data they deliver and talk about system and application sensors. We refer to [START_REF] Rath | Context-aware knowledge services[END_REF] for a complete listing of the available system and application sensors and for a description of what kind of contextual information they are able to sense.

Resource Discovery

The resources that populate the ontology model are for example links, documents, persons, emails, files, folders, web pages, organizations, locations, files, folders, presentations, text documents or spreadsheets. Resource discovery is about the identification of resources and the extraction of related metadata in the contextual attention metadata stream, referred to as the event stream. Furthermore it is about unveiling the resources the user has interacted with and the resources that are included or referenced in a used resource. We say that a resource is included in another one if its content is part of the content of another resource, e.g., copy of a part of text from an email to a text document. A resource is referenced by another resource if the location of the resource appears in the content of another resource, e.g., a link to a web page appears in the content of an email. The resources that are identified by resource discovery mechanisms are related to instances of the Event concept by the isActionOn objecttype property.

Three techniques are applied to discover resources: the regular expression, the information extraction and the direct resource identification approaches. (i) The regular expres-sion approach identifies resources in the event stream based on certain character sequences predefined as regular expressions. This is used to identify files, folders, web links and email addresses for example. (ii) The information extraction approach extracts person, location and organization entities in text-based elements in the event stream. This extraction is rule-based and utilizes natural language specifics. The extracted entities are mapped to concepts of the UICO based on the available context information. As an example, when the name of a person is identified in a text document, it is mapped to an instance of an already existing Person concept and a relation specifying that this person is mentioned in that document is added. (iii) The direct resource identification approach finds data about the resource to build directly in the sensor data, and directly maps certain fields of the event stream data to the resource. An example is the sensor data about an email that the user has opened. In this case the sensor sends the information that a specific email identified by the server message id has been opened for reading. Additional metadata about the email is attached by the sensor and added to the discovered resource. Another example is the ClipboardSnippetResource which is built from the content of the clipboard application sensed by the clipboard observer.

Event to Event Block Aggregation

Context sensors observe low-level context attention metadata that result in events. For logically aggregating events that belong together (i.e. grouping user's actions) into blocks of events, so-called event blocks, static rules are used. Logically in this sense means grouping the events that capture the interaction of a user with a single resource into an event block. Resources can be of various types and opened in different applications. Therefore for different types of applications different rules are applied in the grouping process.

An application can handle multiple resource types. This is the case for example for Microsoft Outlook or Novell Group-Wise in which emails, tasks, notes, appointments and contact details are managed. The complexity and accuracy of the static rules depend on the mechanism of the application for identifying a single resource and on the possibility to capture this resource id with a sensor. If it is not possible for a sensor to capture a unique id for a resource in an application then heuristics are used for uniquely identifying that resource.

Two types of rules can be distinguished for the event to event block grouping process. The first type is a set of rules designed for specific applications, and referred to as application specific rules. An example of such a rule is: group all events that happened on the same slide in the Microsoft PowerPoint application.

The second type of rules, referred to as default application rules, are applied if no application specific rule is applicable. They also serve as backup rules if there is a lack of information in the event stream for applying an application specific rule. The goal of these rules is to heuristically group events into event blocks based on event attributes which can be observed operating-system-wide by the context sensors. These attributes are the window title of the application, the process number (id) and the id of the window handle 6 . The window title and the process id perform the best for a generic event to event block grouping in which no application specific attributes are present. This discriminative power of the window title has been observed also in other work: In SWISH [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF] the window title results in an approximately 70% accurate task detection. This finding goes hand in hand with Shen et al.'s task detection research [START_REF] Shen | Real-time detection of task switches of desktop users[END_REF] in which a combination of the window title and the file path of the currently edited document has been utilized. In Granitzer et al. [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF] the window title is also mentioned as a good discriminating context feature for tasks.

Tasks

The aggregation of user actions into tasks is different from the previous rule-based approach since it would require to manually design rules for each task. This might be a reasonable approach for well-structured tasks, like administrative or routine tasks, but is obviously not appropriate for tasks that involve a certain freedom and creativity in the execution, e.g., for knowledge-intensive tasks like "Planning a journey" or "Writing a research paper". To be able to also handle such kind of unstructured tasks the idea is to automatically extract tasks from the information available in the user interaction context model by means of machine learning techniques. Once detected, these tasks will enrich the ontology model.

ONTOLOGY-BASED TASK DETECTION

A classical approach for automatic detection is to model it as a machine learning problem (classification task). This approach has been used for recognizing web based tasks [START_REF] Gutschmidt | Paving the path to automatic user task identification[END_REF][START_REF] Kellar | Using web browser interactions to predict task[END_REF], tasks within emails [START_REF] Kushmerick | Automated email activity management: an unsupervised learning approach[END_REF][START_REF] Dredze | Automatically classifying emails into activities[END_REF] or from the complete user's desktop [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF][START_REF] Shen | Real-time detection of task switches of desktop users[END_REF][START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF][START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF]. All these approaches are based on the following steps. First, the contextual attention metadata has to be captured by context sensors. Second, it has to be chosen which parts of the data (features) are used for building the training instances for the machine learning part. Since these features can not directly be used as inputs for machine learning algorithms the third step is to transform the context features into attributes [START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF]. This transformation may also include data preprocessing operations. An example for the famous window title feature would be a summarization of the words appearing in the window title into a "bag of words" then transformed into vector format. For text based features, preprocessing steps like removing stopwords [START_REF] Shen | Real-time detection of task switches of desktop users[END_REF][START_REF] Lokaiczyk | Enhancing just-in-time e-learning through machine learning on desktop context sensors[END_REF][START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF] or application specific terms [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF], are applied. The fourth step is to apply feature selection algorithms [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF][START_REF] Shen | A hybrid learning system for recognizing user tasks from desktop activities and email messages[END_REF] to select the most important features for the learning algorithms (optional). The fifth step is the training and testing of the learned model.

In the machine learning part we use the machine learning toolkit Weka [START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF] for parts of the data preprocessing, filtering, feature selection, and classification.

Training Instance Construction

Constructing training instances for the machine learning algorithms is done on the task level. This means that each task represents a training instance for a specific class to be learned. A class corresponds to a specific task model. Having multiple task models hence results in a multi-class classification problem. A training instance for a class is built from features and feature combinations of the context of an instance of a Task concept. The process of constructing features representing a task instance and of transforming them into attributes that can be used to train machine learning algorithms is referred to as feature engineering.

The context features we chose for building the training instances can be grouped in four categories: ontology structure, content, resource, and action. The ontology structure category contains features representing the number of instances of concepts and the number of datatype and objecttype relations used per task. The content category stands for the set of features that involve text based content: the content of the resource displayed, the content in focus and the text input of the user. The resource category includes the complete contents and URIs of the used, referenced and included resources, as well as a feature that combines all the metadata about the used resources in a 'bag of words'. The action category can be seen as the category that represents the user interaction. It contains features about the interaction with applications, graphical user interface elements (accessibility objects), resources types, resources, key input types (navigational keys, letters, numbers), the number of events and event blocks, the duration of the event blocks, and the time intervals between event blocks.

Besides the ontology structure category, which is obviously specific to our ontology-based approach, we have also new ontology-based features in the action and resource categories. These new features are constructed based on combinations of concepts with concepts as well as concepts with concept instances. An example for the first one is the combination of the EventType with the sub-concepts of the Resource concept. For the second one the combination of the EventType with an instance of the TextDocument concept is an example.

Data Preprocessing and Feature to Attribute Transformation

Following steps were performed to preprocess the content of text-based features (in this sequence): (i) remove end of line characters, (ii) remove markups, e.g., \&lg and ![CDATA, (iii) remove all characters but letters, (iv) remove German and English stopwords, (v) remove words shorter than three characters. We transformed text-based features into vectors of words representing this feature with the StringToWord-Vector function of Weka. For numeric features we applied the Weka PKIDiscretize filter to replace discrete values by intervals. We used the Information Gain (IG) measure to rank features by their discriminative power.

Evaluation

In our experiment we evaluated the influence of three parameters on the task detection performance: (i) the number of features, (ii) the classification model and (iii) the feature category. The Weka toolkit and the WEKA integration of the libSVM provided us with the tool set to study the performance of the Naive Bayes (NB), Linear Support Vector Machine (SVM), J48 decision tree (J48) and k-Nearest Neighbor (KNN-k) with k ∈ {1, 5, 10, 35} algorithm. For each classifier/learning algorithm l ∈ L and each feature category f ∈ F we selected the g attributes having the highest IG value to obtain our dataset. As values for g we used 50 different measure points that were equally distributed over the available number of attributes. Since we measured no performance increase by using more than 10000 attributes we introduced an upper bound at this point for the measuring interval. The total number of attributes depends on the chosen features. Stratified 10-fold cross-validation was applied and statistical values for each fold were computed. In addition, the mean and standard deviation of all values were calculated across all folds. We measured the accuracy (a) of the used algorithms, the number of attributes (g), the micro precision (p) and micro recall (r).

EXPERIMENT

This section describes the first results achieved from a task detection experiment we have carried out in the knowledgeintensive domain of the Know-Center. Furthermore we compare the performance of our approach to these of the TaskPredictor [START_REF] Shen | Real-time detection of task switches of desktop users[END_REF], the SWISH [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF] and the Dyonipos [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF] system.

For the experiment we selected five typical task models from our domain for the experiment. Three task models were routine tasks (Task 1: "Filling in the official journey form", Task 2: "Filling in the cost recompense form for the official journey", Task 3: "Creating and handing in an application for leave") and two were knowledge-intensive tasks (Task 4: "Planning an official journey", Task 5: "Organizing a project meeting"). Before we started the experiment we did an online questionnaire to confirm that the descriptions of the task models are clear to the users and that the routine task are tasks that have already been executed by the employees several times before. The dataset we gained by the methods and techniques presented in the previous sections has 220 task instances (Task 1: 55, Task 2: 47, Task 3: 51, Task 4: 52, Task 5: 15) from 13 participants. Half of the task in-stances were collected on a single laboratory computer common to all users and the other half on the employees' own work station computers. The dataset contains over 1 million triples. The average number of triples per task is 4900 with a standard deviation of 4200 triples. The task with the maximum number of triples contains 29700 triples.

Figure 3 shows the performance of the seven studied learning algorithms for different numbers of attributes based on the feature combinations for the presented categories. 1 highlights that the J48 decision tree and the Naive Bayes algorithm perform best and that features of the action category achieve the highest accuracy compared to the other feature categories.

The preliminary analysis of the task detection performance of singular context features showed that the name of the accessibility object (l=J48, g=26, a=84.55, p=0.95, r=0.84) and the value of the accessibility object (l=J48, g=1765, a=72.27, p=0.90, r=0.73) are good discriminative features.

Comparison with other Task Detection Approaches

Comparing our approach to the TaskPredictor, SWISH and Dyonipos approaches can not be done directly because the construction of the training instances varies in terms of the granularity. In SWISH window switching algorithms are introduced that determine the boundary of a training instance, in TaskPredictor Window-Document Segments (WDSs) are built to make a prediction. In the Dyonipos approach one training instance per event block is constructed. In our ap- proach, we construct one training instance for each task.

Since the number of training instances per class has an influence on the accuracy of the classification we focused on the feature engineering part for the comparison. We took the context features used by the mentioned approaches, preprocessed them as published in [START_REF] Oliver | SWISH: semantic analysis of window titles and switching history[END_REF] for SWISH, [START_REF] Shen | Real-time detection of task switches of desktop users[END_REF] for TaskPredictor and [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF] for Dyonipos, and evaluated the performance according to our experiment's setup (dataset and algorithms). Table 1 presents a comparison of the best algorithm runs in terms of accuracy for task detection for the various features/feature categories. It shows that the combination of the feature categories of our ontology-based approach outperforms the features used in other approaches in our experiment. The accuracy is increased by 6.82%, the micro precision by 0.02 and the micro recall by 0.05 in comparison to the best values achieved by other approaches.

For a detailed comparison of the precision and recall values between the TaskPredictor, SWISH and Dyonipos approaches we refer to [START_REF] Granitzer | Analysis of machine learning techniques for context extraction[END_REF].

CONCLUSIONS AND FUTURE WORK

In the digital information age with the high amount of digital information available to us it is important to know the task of the user in order to support her better. For detecting the user's task we introduced an ontology-based user interaction context model (UICO) that extends the spectrum of feature construction for automatic task detection. Based on our novel features we could outperform existing task detection approaches which we evaluated on the dataset collected from a large scale user study in a knowledge-intensive business environment.

The promising results achieved sparked interest in further investigating which features in particular are responsible for the high task detection performance. We will study combinations of the best features to find a good balance between the number of features required, the task detection speed as well as the accuracy, precision and recall of the detection. The 50 measure points interval we used to evaluate our approach only shows a tendency of the number of attributes that should be used in the classification hence we will continue to investigate finer intervals. Since the number of representative laboratory studies in the area of task detection is low we plan to do further ones to get a deeper insight on which kind of tasks can automatically be detected. The work presented in this paper will be integrated into our service-oriented knowledge services framework (KnowSe) which strives to provide highly contextualized and personalized knowledge services to the user.

Figure 1 :

 1 Figure 1: The semantic pyramid [4] comprises the event, the event block and the task layers. Information needs can originate from each layer and are fulfilled by resources.

Figure 2 :

 2 Figure 2: The concepts of the User Interaction Context Ontology (UICO) visualized in the Protégé tool. In the left area this figure shows the action dimension, in the right area the resource dimension, in the bottom left area the user dimension and the information need dimension on the bottom right area. The application dimension is not represented as concepts and hence is not visible here.

Figure 3 :

 3 Figure 3: Accuracy of the learning algorithms for correctly identifying the task model a task belongs to. In the top four pictures (a)-(d) the performances of the algorithms for each category is shown. The bottom picture (e) visualizes that the combination of all features of all categories outperform each single category. The information gain (IG) feature selection was used to select the top g number of attributes visualized on the x-axis.

Table 1 :

 1 Overview of the best accuracies (a) for the features (f ) from the UICO, Dyonipos, SWISH and TaskPredictor approaches. The learning algorihtm (l), the number of attributes (g), the micro precision (p) and the micro recall (r) are also given.

	Set	f	l	g	a	p	r
		Action Cat.	J48	776	83.64	0.95 0.82
		Content Cat.	NB	1409	65.00	0.87 0.67
	UICO	Resource Cat.	NB	1849	67.27	0.89 0.72
		Ontology St. Cat.	J48	232	65.00	0.87 0.63
		All Categories	J48	4201 89.55 0.97 0.90
		ApplicationN ame(A) J48	18	46.81	0.78 0.50
		Content(C)	KNN-1	109	62.72	0.86 0.63
		W indowT itle(W)	J48	241	79.01	0.93 0.78
	Dyonipos	AC	J48	2353	69.55	0.89 0.70
		AW	J48	313	80.91	0.94 0.81
		CW	NB	1509	81.82	0.95 0.84
		ACW	NB	755	82.73	0.95 0.85
	SWISH	W	J48	589	79.55	0.93 0.79
	TaskPredictor W&f ilepath	J48	701	81.82	0.94 0.82

http://www.w3.org/2004/OWL/

http://protege.stanford.edu

Microsoft Active Accessibility:

http://nepomuk.semanticdesktop.org

http://usercontext.opendfki.de/wiki/NopOntology

The window handle id is a unique identifier of the window constructed by the Microsoft Windows operating system.

ACKNOWLEDGMENTS

We would like to thank all the people from the Know-Center who participated in the experiment and supported us in carrying out our task experiment study. The Know-Center is funded within the Austrian COMET Program -Competence Centers for Excellent Technologies -under the auspices of the Austrian Ministry of Transport, Innovation and Technology, the Austrian Ministry of Economics and Labor and by the State of Styria. COMET is managed by the Austrian Research Promotion Agency FFG.