Chapter 7 Task-Stage Knowledge Support
7.1 Task-needs evolution pattern modeling
7.1.1 Task-stage Knowledge Support Module
There are three phases in providing pertinent task stage knowledge, namely, data pre-processing, task-needs discovery, and adaptive task-stage knowledge router.
Note that the task-needs evolution discovery phase is the kernel of the system for analyzing the worker’s task stage and task-need topics of stages.
Two types of valuable information: content data and usage data are acquired during data pre-processing phase. The text pre-processing module extracts information from unstructured or semi-structured data. The user behavior tracker is an on-line module that tracks a user’s interaction with the system. The user’s task-related behavior can be captured and recorded into the profiles, including the access behavior on the task-based domain ontology and relevance feedbacks on knowledge items. The profile handler uses an adaptive task-based profiling approach
to adjust workers’ profiles based on the workers’ dynamic behavior. The operation details of the adaptive task-based profiling approach can be found in our previous work [47]. The task-need evolution discovery phase is the kernel of the system for analyzing the worker’s task-related behavior during task performance, as shown in Figure 10. The task-stage identifier and the task-need analyzer are within the task-needs evolution module for identifying the worker’s task stage and analyzing task-need topic of each stage based on the variety of profiles. Herein, worker’s task-needs are modeled as the topic nodes in DO at different abstraction level which are relevant to the target task.
•
Task-Stage Identifier: The task-stage identifier is responsible for analyzing
and determining worker’s task stage based on the changes of the task profile over time.•
Task-Need Analyzer: The task-need analyzer is responsible for tracking the
worker’s access behavior over a period of time. The access behavior is analyzed based on the domain ontology (DO) to discover worker’s task-needs on specific topics. Herein, the DO is a multi-level structure and each node in the DO represents a research topic in our application domain, as shown in Figure 3 of Section 4.2.The IF strategy can be adopted to provide stage-relevant knowledge based on the analyzing results of task-needs evolution phase, namely, stages and stage topics.
Therefore, the adaptive task-oriented knowledge router could provide workers
Domain Ontology
Fig. 10. Task need evolution module
needed and pertinent task-relevant codified knowledge that considers the workers’
current task-stage and the needed topics at each stage.
7.1.2 Task-needs evolution pattern modeling
The user behavior tracker tracks and records the worker’s access behavior over a period of time when the worker logs into the system. A user-task session and
transaction are defined in this work to analyze workers’ implicit and explicit
feedback behaviors on codified knowledge items periodically. A session is defined as a sequence of user feedback behavior (e.g., reading, downloading or rating an information item) during a single visit to the system. Furthermore, the tasktransaction records the worker’s access to the knowledge repository across sessions.
In other words, a worker’s task transaction comprises n sessions, where n ≥ 0. The time interval of a transaction is based on the characteristics of our research application domain, in which the user behavior tracker is activated to generate or update profiles once a worker has uploaded behavior for a specific task.
The worker’s session or transaction temporal profile is generated based on the tracking result over a time period of session or transaction. Furthermore, the system analyzes the relevance degree between session or transaction temporal profile and topics in domain ontology (DO). Consequently, a worker’s task-needs pattern is expressed in terms of set of topics that are the field-level or task-level nodes in the DO. We use a real example to explain how to detect and track a worker’s access behavior and conduct task-needs pattern modeling.
Example 1: In the given example, three sessions are identified in the third
transaction of executor “PoTsun” who is the executor of “ITIL-based: Context-awareKnowledge Recommendation” task. As we have mentioned previously, the time
interval of a transaction in our research application domain is that the worker uploads the task-relevant information to the system. Accordingly, the third transaction means the third upload information behavior by the executor “PoTsun” for a specific task.Meanwhile, after conducting data preprocessing in phase one, a set of the worker’s access behavior patterns across sessions, Transi={s1, s2, …, sm}, and a set of accessed knowledge items, O={I1, I2, …, In}, are identified.
1 368
( 3S ) :
AI Trans < I >
32 376, 458, 376, 375, 460
( S ) :
AI Trans < I I I I I >
3 376 461 462 375 368 376
( 3S ) : , , , , ,
AI Trans < I I I I I I >
( iSj)
A I T ra n s represents a sequence of knowledge items accessed in session j of transaction i. Our user’s access behavior includes explicit feedback behavior, such as rating and uploading, and implicit feedback behavior, such as browsing and downloading. For example, the implicit and explicit behavior for knowledge item I376
occurs at different times of the same session.
Task-needs patterns: The temporal profile is derived from the feature vectors of
those documents accessed by a worker over a time period. In this work, TransiSjJJJJJJG
denotes the temporal profile (feature vector of weighted terms) derived from the documents accessed in session j of transaction i. And then we take further analysis by calculating the similarity (e.g., the cosine measure) between the temporal profile,
Sj
Transi
JJJJJJG
and the profile of a topic, topicJJJJJGj
. Notably, JJJJJGtopicj
represents the associated profile (feature vector of weighted terms) of topicj. Note that the topic j represents a research topic, which is the node in the proposed multi-level domain ontology (DO).
Accordingly, a worker’s task-needs pattern can be expressed as a set of topics and associated relevance degree. The task-need pattern of a session j in transaction i is denoted by j
P a tt is expressed as a set of topics with the associated relevance degree (topicj
, rd
j).Top task-relevant topics: Furthermore, we set a threshold δ or top-N to select the
top task-relevant topics (denoted as TRTs) from the task-needs pattern, ji s T ra n s
P a tt . Let TRTWs denote the set of top relevant topics with the associated weight derived by the similarity calculation. TRTWs is expressed as a set of (task_id, relevance
degree) pairs. Accordingly, the TRTWs with associated degree of relevance are
recorded in the worker’s topic-based task profile to model his/her task-needs to the target task over a time period (regarding a transaction/session).Example2: A set of TRTs with the associated weight is derived by the similarity
calculation and is expressed by (task_id, relevance degree) pair. The top-4 task-relevant topics of each session within transaction 3 are listed below.1 07 50 12 31
( sj)
t i
TRTW s Trans denotes the top task-relevant topics in session j of transaction i.
The superscript t in TRTWs Transt( isj) denotes the task-level topics of DO. We further express the top task-relevant topics to the field-level topics of DO by (field_id,
relevance degree) pairs. For example, task 7 and task 50 both belong to field 8, as
shown in Figure 2. Therefore, the top task-relevant topics can be aggregated to the field-levels listed below.1 08 08 06 01
From the example, it is easy to see that the worker’s task-needs focus increasingly on the topic of f8, i.e., “Office Automation”. The example is a simple case to explain the basic process of usage pattern modeling. Based on the proposed idea, the system can track and identify the worker’s task-needs on specific topics from different abstraction level of multi-level structure of DO.