Discovering role-based virtual knowledge flows for organizational knowledge support

Discovering role-based virtual knowledge

flows for organizational

knowledge support

Duen-Ren Liu

⁎

, Chih-Wei Lin, Hui-Fang Chen

Institute of Information Management, National Chiao Tung University, No. 1001 Ta Hsueh Rd., Hsinchu 300, Taiwan

a b s t r a c t

a r t i c l e i n f o

Article history: Received 20 May 2011

Received in revised form 24 October 2012 Accepted 4 November 2012

Available online 28 January 2013 Keywords:

Knowledgeflow Knowledgeflow view Knowledge support Knowledge management Role

Ontology

In knowledge-intensive work environments, workers need task-relevant knowledge and documents to support the execution of tasks. A knowledgeflow (KF) represents an individual's or group's knowledge-needs and referencing behavior of codified knowledge during the performance of organizational tasks. Through knowledge flows, organi-zations can provide workers with task-relevant knowledge to satisfy their knowledge-needs. In teamwork environ-ments, knowledge workers with different roles and task functions usually have diverse knowledge-needs, but conventional KF models cannot satisfy such needs. In a previous work, we proposed a novel concept and theoretical model called Knowledge Flow View (KFV). Based on workers' diverse knowledge-needs, the KFV model abstracts knowledge nodes of partial KFs and generates virtual knowledge nodes through a knowledge concept generaliza-tion procedure. However, the KFV model did not consider the diverse knowledge-needs of workers who play differ-ent roles in a team. Therefore, in this work, we propose a role-based KFV model that discovers role-based virtual knowledgeflows to satisfy the knowledge-needs of different roles. First, we analyze the level of knowledge required by workers to fulfill various roles. Then, we develop role-based knowledge flow abstraction methods that generate appropriate virtual knowledge nodes to provide sufficient knowledge for each role. The proposed role-based KFV model enhances the efficiency of KF usage, as well as the effectiveness of knowledge sharing and knowledge support in organizations.

© 2013 Elsevier B.V. All rights reserved.

1. Introduction

In knowledge-intensive work environments, workers need task-relevant knowledge and documents to support their execution of tasks. Thus, how to effectively fulfill workers' knowledge-needs by pre-serving, sharing and reusing task-relevant knowledge is an important issue in realizing knowledge management and promoting business in-telligence. Organizations can provide task-relevant knowledge through knowledge_{flows (KF), which represent the flow of an individual's or} group's knowledge-needs and referencing behavior of codified knowl-edge during the performance of organizational tasks[16].

In recent years, a considerable number of studies have focused on KF models and applications in business and scientific research con-texts. One major area of research focuses on knowledge sharing among knowledge workers. For example, researchers cite prior re-search and propose new ideas through publishing papers, thereby creating KFs in the realm of science[46]; and in the business domain, KFs facilitate knowledge sharing during the execution of tasks[45]. KFs can be discovered by analyzing workers' knowledge-needs, after which appropriate codified knowledge can be recommended to workers based on the KFs[16,20]. When a task involves teamwork,

knowledge workers have different roles and task functions, so they usually have diverse knowledge-needs. However, conventional KF models do not provide different perspectives of a KF to fulfill team members' diverse needs. Although several KF models have been pro-posed, they do not consider the concept of virtual knowledgeflows, which provide abstracted knowledge. In a previous work[21], we proposed an approach called the knowledge flow view (KFV) model, which constructs virtual knowledgeflows to serve workers' knowledge-needs. A virtual knowledge_{flow (VKF) is derived from a} KF and provides abstracted knowledge. Given the knowledge-needs of different workers, the model abstracts some knowledge nodes of a KF to generate several virtual knowledge nodes by an order-preserving ap-proach and a knowledge concept generalization procedure.

In the KFV model, we investigated VKFs and developed algorithms to generate suchflows, but we did not consider workers' knowledge-needs in terms of the different roles they play in an organization. If a task in-volves teamwork, workers' knowledge-needs will vary, depending on the roles they play. To ensure effective cooperation, each worker not only needs a specific level of knowledge to perform his/her individual task, but will also need a general level of knowledge about the other workers' tasks. For example, in a computer manufacturing company, en-gineers are responsible for product development and marketing people design strategies to launch and promote new products. In this scenario, engineers need a specific level of technical knowledge, but marketing people need only a general level of such technical knowledge to assist ⁎ Corresponding author. Tel.: +886 3 5131245; fax: +886 3 5723792.

E-mail addresses:dliu@mail.nctu.edu.tw(D.-R. Liu),jwlin.iim93g@nctu.edu.tw

(C.-W. Lin),hfchen@iim.nctu.edu.tw(H.-F. Chen).

0167-9236/$– see front matter © 2013 Elsevier B.V. All rights reserved.

http://dx.doi.org/10.1016/j.dss.2012.11.018

Contents lists available atSciVerse ScienceDirect

Decision Support Systems

them in communicating with the engineers. Thus, the KFV model is re-quired to include the aspect of roles in order to apply knowledge management applications in teams[15]. Since workers' knowledge re-quirements may vary, it is essential that organizations provide role-based VKFs to ensure effective cooperation and knowledge sharing. The concept of role-based VKFs has not been addressed in previous stud-ies on KFV models. Therefore, in an attempt tofill this research gap, we propose a role-based KFV model to fulfill workers' knowledge-needs. The model analyzes the levels of knowledge required by workers based on their roles, and develops role-based knowledgeflow abstrac-tion methods that generate virtual knowledge nodes to provide the appropriate level of knowledge for each role.

This work is targeted as a theoretical paper to establish the role-based KFV model and extend knowledgeflow research to cooperative teams for organizational knowledge support. To the best of our knowl-edge, the proposed role-based KFV model is one of the pioneering the-oretical studies to illustrate a comprehensive formal representation of VKFs from the perspectives of roles and operations. This work intro-duces three innovative concepts: (1) identifying VKFs in role and oper-ation perspectives, (2) integrating an approach for evaluating role-knowledge node relevance and an order-preserving algorithm to derive VKFs, and (3) applying role-operation knowledge requirements to facil-itate knowledge concept abstraction. From the perspective of coopera-tion and knowledge sharing, our research facilitates collaboracoopera-tion in an organization. The proposed role-based KFV model can enhance the theoretical scope of KF research. In addition, our work improves the efficiency of KFs, as well as the effectiveness of knowledge sharing and knowledge support in organizations.

The remainder of this paper is organized as follows. The next sec-tion contains a review of related work. Then, we illustrate the founda-tion of the KFV model inSection 3and discuss the important concepts of the role-based KFV model in Section 4. Methods of generating role-based VKFs are introduced in Section 5. Next, we conduct a basic system design and present a case study inSections 6 and 7, respectively. Finally, we summarize our conclusions and indicate possible directions for future research inSection 8.

2. Related work

In this section, we discuss the research background and related work on knowledge management, knowledge flow, ontology and process-view abstraction.

2.1. Knowledge management and knowledge support

Knowledge is one of the key assets that organizations use to main-tain a competitive advantage[31]; and knowledge management pro-vides the principles of creation, organization, transfer and application of knowledge within enterprises[40]. Generally, knowledge is classi-fied as tacit or explicit knowledge, and information technology (IT) is regarded as a natural medium for managing knowledge[4]. Organiza-tions usually use community-based electronic discussion platforms to transfer tacit knowledge from individuals to a knowledge repository

[8]. In task-based business environments, knowledge management systems (KMS) facilitate the preservation, reuse and sharing of knowledge, and also support collaboration among workers. For exam-ple, based on the specifications and process-context of a task, the KnowMore system[1]provides context-aware knowledge retrieval and delivery to support workers' procedural activities. Holz et al.

[13] proposed a similarity-based approach that organizes desktop documents and proactively delivers task-specific information to users. The task-based K-support system[24,25,39]provides knowl-edge to adaptively meet a worker's dynamic information needs by an-alyzing his/her access behavior or relevance feedback on documents. Furthermore, because of the nature of teamwork, a collaborative mechanism is essential for establishing KMS[2,43].

2.2. Knowledgeflow

Knowledge_{flow (KF) research focuses on how KFs transmit, share} and accumulate knowledge in a team. In a workflow situation, work knowledge mayflow among workers, while process knowledge may flow among various tasks[45,47,48]. Thus, the KF re_{flects the level} of knowledge cooperation between workers or processes, and in flu-ences the effectiveness of teamwork or workflow. The KF in a soft-ware development team can gather knowledge from one team member and carry it to another member, and thereby facilitate knowledge sharing [45]. To improve the efficiency of teamwork, Zhuge[47]proposed a pattern-based approach which combines cod-ification and personalization strategies to design an effective knowl-edgeflow network. To enable the automation of KFs, Sarnikar and Zhao[32,33]developed a framework of knowledge workflow to auto-mate KFs by integrating work_{flow and knowledge discovery} tech-niques. Rodriguez et al. [30] posited that KFs in communities of practice help members to share their knowledge and experience about a speci_{fic domain, in order to complete their tasks. KFs can} also facilitate knowledge sharing and reuse in research environments. Specifically, a citation network can be seen as a KF that disseminates knowledge among researchers. Citing a scientific article implies the occurrence of a KF between the authors of the article and the person citing it.

In recent years, several KF models have been proposed. Luo et al.

[26]designed a Textual Knowledge Flow (TKF) model for a semantic link network. TKF can recommend appropriate browsing paths to users after evaluating their interests and inputs. KFs can also repre-sent the sequence of knowledge-needs and/or knowledge reference patterns when workers perform tasks. Lai and Liu[16]constructed a time-ordered KF model to determine the sequence of workers' knowledge referencing behavior. Workers can obtain knowledge to satisfy their needs through the KFs discovered from document access logs. Moreover, the referencing sequence in weblogs can be regarded as a KF, and described as a sender-message-receiver model, since a blogger's weblog post may include a hyperlink to a weblog post of an-other blogger[3]. Kim et al.[14]proposed a KF model that utilizes a process-oriented approach to capture, store and transfer knowledge. Zhang et al.[41]used Petri-net to model a KF. Specifically, a knowl-edge node can generate, learn, operate, understand, synthesize and deliver knowledge based on four types offlow relations: creation, merging, replication and broadcasting. Zhao et al.[42]introduced a method that integrates business processes and KFs by dividing KFs into sequence, distribution, combination and self-reflection, based on a Role-Activity-Diagram model.

2.3. Ontology

Ontology illustrates how people view the world. It represents the objects and their inter-relationships in a specific domain. More pre-cisely, it is a conceptualization mechanism that defines the concepts of objects explicitly and constructs a hierarchical structure of the ob-jects' inter-relationships[11,28]. The mechanism has been applied in many domains. For example, the common terminologies and knowl-edge concepts in an ontology can improve the problem-solving capa-bility and efficiency of a supply chain [5]. Wikipedia articles and categories can also be used as an ontology to predict the concepts of documents[35]. In an organization, an ontology defines the knowl-edge concepts that are understood throughout the organization, and provides a hierarchical structure to demonstrate the relationships among the concepts[29]. Building ontology is an evolving process and involves many techniques and tools to facilitate the whole pro-cess. Obviously, the construction process would include an evaluation and feedback mechanism to gradually improve ontology quality and obtain common understanding in organizations[18,28,36]. For exam-ple, Uschold and King[37]proposed a skeletal methodology to build

an enterprise ontology; it comprises four phases: scoping, building, evaluating and documenting. Du, Li and King[9] designed a six-phase process that includes the preparation, transformation, cluster-ing, recognition, refinement and revision for extracting ontology from unstructured HTML pages. Therefore, involving users in the evaluation or re_{finement phase is essential for gradually adjusting} the quality. Many ontology-building tools, such as Protégé, OntoEdit and SNet-Builder, can effectively support the ontology construction process to serve predefined purposes and meet users' requirements

[6,27].

2.4. Process-view abstraction

Workflow Management Systems (WfMS) are effective process man-agement tools that allow businesses to analyze, simulate, design, imple-ment, control and monitor their overall business processes[10,17]. Processes describe the operationflows involved in performing business activities. In practice, participants involved in a workflow need a flexible workflow model that is capable of providing appropriate process infor-mation[22]. Because of the increasing complexity of business processes and the variety of participants, it is beneficial to define virtual processes from different perspectives. Liu and Shen[22]presented a novel con-cept of process abstraction called process-view. It is a virtual process de-rived from a base process to provide abstracted process information. The process-view is generated by an order-preserving approach, which ensures that the original order of the activities in a base process is preserved. Under the process-view concept, a WfMS can provide var-ious views of a process for different participants within an organization or cross organizations[23]. Shen and Liu[34]proposed a role-based ap-proach to discover role-relevant process views for different workflow participants. They developed algorithms to generate such views auto-matically, based on the relevance degrees between roles and tasks. 3. Foundation of knowledgeflow view model

A virtual knowledgeflow (VKF) is an abstract form of a base knowledgeflow (BKF). It reveals abstract knowledge by providing customized views of a KF to team members. In our previous work

[21], a novel knowledgeflow view (KFV) model was proposed to con-struct VKFs to serve workers' knowledge-needs. The following sum-marizes the concepts and definitions of the KFV model. Please refer to[21]for detailed de_{finitions, semantics and examples.}

3.1. Virtual knowledgeflow: an abstract form of a base knowledge flow A KF that may have multiple VKFs is referred to herein as a base knowledge_{flow (BKF). A VKF is generated from a BKF and is} consid-ered to be a view of the BKF. We take an example from a mobile phone company to explain how to identify a BKF.

Fig. 1shows a business process of mobile phone development. To derive BKFs of the business process, KF designers may either consult do-main experts or investigate workers' document access logs to identify participants' knowledge-needs. A collection of the knowledge-needs and the order of referencing sequences would be used to construct BKFs, which represent participants' knowledge-needs by knowledge concepts. These knowledge concepts are stored in base knowledge

nodes (BKNs), respectively.Fig. 2illustrates an example of the BKFs to explain the concepts of base knowledgeflows. In this example, KF de-signers derive the BKF's knowledge dependencies from the process level dependencies because it is a more intuitive and easier way for team members to understand. Nevertheless, KF designers can apply dif-ferent ways to set the knowledge dependencies from other perspectives. Generally speaking, the knowledge dependencies in a BKF indicate the referencing sequence of knowledge (information) in task performance which may occur in a distributed software development team[44], an academic research project[16]or a web exploration[3]. So, knowledge dependencies do not always relate to process level dependencies. In practice, KF designers are responsible for setting knowledge dependen-cies based on the characteristics of applications.

In the KFV model, we adopt an order-preserving approach and a knowledge concept generalization mechanism to generate VKFs based on task functions and organizational security rules. Hence, team mem-bers have their own VKFs to fulfill their knowledge-needs and assist them to obey security policy.

Suppose that the BKF in Fig. 3 is the corresponding BKF of a manufacturing process. Product managers need not know all of the knowledge concepts in detail, but they must have general manufactur-ing knowledge to understand yield trends and increase communication effectiveness with factory members. So, KF designers may design an ap-propriate VKF for the product managers as follows: base knowledge nodes k1and k2are abstracted to a virtual knowledge node vk1; k3, k4,

k5and k6are abstracted to vk2. In addition, manufacturers have their

own VKF to serve for their knowledge-needs. Consequently, team members have respective VKFs to represent their knowledge-needs in collaborative environments.

3.2. Basic definitions of the knowledge flow view model

BKFs and VKFs are formally defined in the KFV model. A BKF con-sists of base knowledge nodes and dependencies. A BKN contains knowledge concepts to represent knowledge-needs, and a dependen-cy is the order between two BKNs. Likewise, a VKF, an abstract form of a BKF, consists of virtual knowledge nodes (VKNs) and virtual depen-dencies. A VKN is formed by abstracting a set of BKNs. Besides, a VKN contains knowledge concepts derived from its member knowledge nodes' knowledge concepts. Those knowledge concepts can be identi-fied in organizational domain ontology.Fig. 4shows the components of the KFV model, in which the basic definitions of BKF and VKF are presented accordingly.

3.2.1. Definition 1 (domain ontology, O)

Domain ontology is constructed to define the knowledge concepts and their hierarchical relationships in an organization. It is divided into different knowledge categories. We define the ontology as O= bC, HR>, where C is a set of knowledge concepts derived from a do-main; and HR is a set of hierarchical relations that define the par-ent–child relationships between the knowledge concepts in C. HR is formally expressed as HR = {hr | hr∈C×C}. Given two knowledge concepts: x and y, if x has a downward link to y (or y has an upward link to x) in the concept hierarchy, then x is a parent concept of y and y is a child concept of x. Two semantic relations, Generalization and Specialization, are used to describe the parent–child relations. The

Hardware Design Major Parts Identification Commercialization Business Analysis Application Design Parts Sourcing Industrial Design Platform Setup

relation between a parent concept x and a child concept y is formally expressed as: Specialization(x) = {y | y is a child concept of x} and Generalization(y) = {x | x is a parent concept of y}.

3.2.2. De_{finition 2 (concept level, CL)}

A knowledge concept is mapped to the corresponding CL in the domain ontology. CL is defined by letting the root of the domain on-tology be level one. If a knowledge concept is at level l, then its child concepts are at level l + 1. The CLs indicate the levels of knowl-edge concepts and represent their granularity; that is, the knowlknowl-edge concepts with larger CLs (i.e., in the lower levels of domain ontology) are more specific than those with smaller CLs (i.e., in the upper levels of domain ontology).

3.2.3. Definition 3 (knowledge concepts, KC)

Knowledge concepts represent the different types of knowledge in domain ontology. Some KCs are general and some are specific. A knowledge concept's generality (or specificity) is determined by its CL.

3.2.4. Definition 4 (base knowledge node, BKN)

A BKN x is a 2-tuplebbid, BKC>, where bid is the label of x and BKC is a set of knowledge concepts. BKC of x are denoted by BKCx= {c1, c2,

c3,…, cm}, where the knowledge concept cican be identified in

do-main ontology and is associated with a corresponding CL. 3.2.5. Definition 5 (base knowledge flow, BKF)

A BKF is a 2-tuplebBKNS, BD>, where BKNS is a non-empty set of BKNs. BD is a non-empty set of dependencies. The preceding node and succeeding node of a dependency are in BKNS.

3.2.6. Definition 6 (virtual knowledge node, VKN)

A VKN vx is a 4-tuplebvid, KNS, D, VKC>, where vid is the label of vx, KNS is a non-empty set of BKNs or previously defined VKNs. D is a non-empty set of dependencies whose preceding and succeeding

nodes are in KNS. The VKC, abstracted knowledge concept set, is a non-empty set of knowledge concepts defined in domain ontology. The knowledge concepts of vx are denoted as VKCvx= {vc1, vc2, vc3,…,

vcq}, where vciis abstracted from some knowledge concepts of vx's

member knowledge nodes.

3.2.7. Definition 7 (virtual dependency, VD)

Given a based knowledgeflow BKF=bBKNS, BD> and two virtual knowledge nodes vx and vy, a virtual dependency vdep(vx, vy) from vx to vy exists if dep (x, y) is in BD, where x is a member of vx and y is a member of vy. A virtual dependency is used to connect two virtual knowledge nodes vx and vy.

3.2.8. Definition 8 (virtual knowledge flow, VKF)

A virtual knowledgeflow is a 2-tuple bVKNS, VDS>, where VKNS is a non-empty set of virtual knowledge nodes; and VDS is a non-empty set of virtual dependencies.

Based on the KFV model, KF designers can obtain VKFs from a given BKF by an order-preserving approach and a knowledge concept generalization method. The detailed algorithms and examples of the approach and the method are listed in our previous work[21]. Conse-quently, different VKFs can be derived to fulfill team members' knowledge-needs in teamwork environments.

4. Introducing roles into the knowledge_{flow view model} In this section, we extend the knowledgeflow view (KFV) model to a role-based KFV model by adding the role aspect. The purpose of the role-based KFV model is to derive role-based virtual knowledge flows (VKFs) from a base knowledge flow (BKF). In the role-based KFV model, virtual knowledge nodes (VKNs) are generated from base knowledge nodes (BKNs) based on the relevance degrees be-tween roles and BKNs. In addition, a concept abstraction method is developed to abstract knowledge concepts of BKNs for a VKN.

Design rule of RF and Baseband 1. Consumer behavior 2. Display options 3. Battery options 4. Card options 1. Competitive pricing 2. Direct channel selection 3. Operators bundling 1. Geographic segmentation 2. Life-style based segmentation 3. Consumption environment 4. Consumer behavior 1. Multimedia functions 2. Internet access options 1. Display options 2. Price/performance of parts 3. Service level agreement of 3rd parties 1. Carrying capability 2. Customized features 3. Human factors Features of iOS and Android

Fig. 2. A sample BKF of the mobile phone development process.

k

k

k

k

k

k

Base knowledge flow

Virtual knowledge flow

various views on the

same base KF

vk

vk

product manager

vk

vk

manufacturing

vk

4.1. Concepts of role-based virtual knowledgeflows

In this sub-section, we present the concepts of role-based VKFs. A role-based VKF comprises a set of VKNs that are aggregated from BKNs according to their relevance to a role. Some BKNs may be more relevant to the role than others. A VKN in a role-based VKF de-notes a meaningful (aware-needed) knowledge unit of interest to the role; thus, it should be relevant to the role. The process of identifying a role-relevant VKN involves aggregating BKNs based on their rele-vance to the role. Once the relerele-vance of the aggregated BKNs to the role reaches a certain threshold, a VKN is identified for the role. The relevance of a BKN to a particular role can be specified by KF de-signers or derived from the relevance degrees between the role and the operations which are associated with the BKNs. The relevance de-gree of a BKN indicates how important it is to the role. Based on the relevance degrees of all BKNs, procedures can be clearly defined to generate appropriate role-based VKFs for different organizational roles.

After a VKN has been identified, KF designers can derive its knowl-edge concepts. The objective is to obtain abstractions of the knowlknowl-edge concepts in the VKN's member knowledge nodes that do not conform to the knowledge required by the role. The knowledge requirements are represented by knowledge concepts which can be identi_{fied in} do-main ontology. Dodo-main ontology is a hierarchical structure comprising knowledge concepts. The lower levels of the hierarchy contain specific knowledge, while the upper levels contain knowledge that is more gen-eral. The various roles in an organization have different knowledge re-quirements. Workers need specific knowledge about their own roles and tasks, but need general knowledge about other roles' tasks. For example, R&D workers design and develop products, so they must have specific technical skills and knowledge. The marketing and sales personnel, who launch and promote products, may not have specific technical knowledge about the products, but they must have general knowledge about the technical aspects.

4.2. Role-knowledge node relevance and knowledge requirement The crucial part of deriving role-based VKFs is tofind the rele-vance degree between each BKN and each role in a given BKF. Based on the derived relevance degrees, a proposed approach can then gen-erate appropriate VKFs for different organizational roles. The process of generating a role-based VKF incorporates the concept of opera-tions, which is essential in organizational environments. In this sub-section, base knowledge node profile and role-operation relevance

profile are introduced for evaluating role-knowledge node relevance to generate VKNs. In addition, operation required knowledge concept set (KCS) profile and role-operation knowledge requirement degree (krdeg) profile are proposed for deriving roles' knowledge require-ments to abstract knowledge concepts for VKNs.

4.2.1. Base knowledge node profile

A BKN is associated with different operations. The base knowledge node profile is a set of 2-tuple bbase knowledge node bkn, operation op>, which expresses that operation op is associated with base knowledge node bkn.

4.2.2. Role-operation relevance profile

The profile is used to determine how important an operation is to a role, since some operations are more relevant to a role than others. The profile, which records the relevance degree between a role and an operation, is a set of 3-tuplebrole r, operation op, operation vance degree ordeg>. Each 3-tuple records that the operation rele-vance degree between role r and operation op is ordeg. Roles have different ordeg to their operations. The more the relevance between a role and an operation, the higher the ordeg will be. The ordeg is used as a quantified value to abstract BKNs into VKNs.

For example, suppose a software engineer r is assigned to perform an operation op called developing a sales database system. Because the engineer's job function is system development, the op is highly rele-vant to r. Therefore, the operation relevance degree of op to r is high. The ordeg is limited to the range [0, 1]. In this case, the value is between 0.7 and 1.0. The role-operation relevance profile is de-scribed asbr, op, 0.9>.

4.2.3. Operation required knowledge concept set (KCS) profile

The profile comprises a set of 3-tuple boperation op, knowledge category ca, knowledge concept set kcs>, which represents the set of required knowledge concepts kcs in knowledge category ca for performing operation op. The domain ontology is divided into knowl-edge categories, and an operation may be related to more than one knowledge category. A knowledge concept set (kcs) indicates which knowledge concepts in a given knowledge category are required to perform an operation.

For example, according to its operation characteristics, performing a selling iPad operation requires specific marketing-related knowl-edge concepts including Apple, target user, benefit and discount and general IT-related knowledge concepts including requirement, design and programming. These knowledge concepts can be mapped to IT

Base Knowledge Flow Base Knowledge Node Dependency Knowledge Concept Knowledge-Flow View (Virtual Knowledge Flow)

Virtual Knowledge Node Abstracted Knowledge Concept Virtual Dependency linked by consists of contains consists of linked by contains Domain Ontology identified in identified in abstracts from contains abstracts from Fig. 4. KFV model.

or Marketing knowledge categories, as shown inFig. 5where IT oc-cupies c2 and Marketing ococ-cupies c3. Thus, the operation required KCS profiles for the operation selling iPad are bselling iPad, IT, {c21, c22, c23}> and_{bselling iPad, Marketing, {c3111, c332, c3311, c3422}>.} 4.2.4. Role-operation knowledge requirement degree (krdeg) profile

For a given operation, different roles may require different degrees of knowledge in different knowledge categories. The pro_{file is a set of} 4-tuplebrole r, operation op, knowledge category ca, knowledge re-quirement degree krdeg>. Each tuple indicates that the degree of knowledge required by role r with respect to operation op in knowledge category ca is krdeg. The value of krdeg is between 0 and 1 and it is used to define how specific or general the required knowledge in a certain knowledge category should be for role r while executing operation op.

Overall speaking, two phases are required to generate VKFs. Phase I generates VKNs and Phase II abstracts knowledge concepts for these VKNs. In Phase I, role-operation relevance profile, base knowledge node profile and a granular threshold TH (a parameter defined in

Section 5.1.2) are used to generate VKNs. In Phase II, role-operation krdeg profile and operation required KCS profile are used to abstract knowledge concepts to required concept levels for VKNs.Table 1

shows the profiles and parameters exploited in the role-based KFV model. Items 1, 2 and 3 are related to Phase I and items 4 and 5 belong to Phase II. The profiles are derived by operation log analysis or opin-ions of domain experts in terms of the involved operatopin-ions and partic-ipating roles in the BKF. Moreover, the parameters can be adjusted by roles and KF designers in terms of roles' requirements.

As mentioned earlier, the operation required KCS profiles record the required knowledge concepts for performing an operation and

the role-operation krdeg profiles represent roles' knowledge require-ment degrees. Thus, KF designers can use krdeg, which is estimated by role r and KF designers, as a basis to abstract the required knowledge concepts into appropriate concept levels. Role r should continue eval-uating thefitness level of the abstracted knowledge concepts until they are satisfied with the derived VKFs.

Fig. 6shows an example to express the two phases for generating role-based VKFs. In Phase I (generate VKN), the relevance degree ordeg of role r to operation op1and op2is 0.2 and 0.05 respectively

(shown in role-operation relevance profile); op1and op2are

associat-ed with bkn1(shown in base knowledge node profile) and the

thresh-old is set to 0.4. In Phase II (abstract knowledge concept), the knowledge concepts required to perform op1are {c131, c132} in

mar-keting category and {c621} in hardware category (shown in operation required KCS profile); the knowledge requirement degree krdeg of role r to perform op1is 0.8 for marketing category and 1.0 for

hard-ware category (shown in role-operation krdeg pro_{file). The above} in-formation is used to generate role-relevant VKNs as well as derive the corresponding knowledge concepts for the VKNs.

Next, the following section discusses how to construct role-operation relevance profile and evaluate the relevance degrees between a given role and a BKN.

4.2.5. Construction of role-operation relevance profile

Initially, KF designers can obtain role-operation relevance profiles by consulting domain experts or by analyzing roles' operating logs through adopting process mining technique[38]or knowledgeflow mining methodology[16]. confirmation (c222) system (c221) IT (c2) design (c22) programming (c23) tool (c231) language (C232) user need (c212) requirement (c21) market need (c211) Java (c2321) VB (c2322) Root IT knowledge category interest (c322) use value (c321) Marketing (c3) produce (c32) business model (c33) pricing (c331) target user (c332) need (c312) distribution (c31) brand (c311) communication (c34) advertising (c3421) discount (c3422) service (c341) promotion (c342) Apple (c3111) benefit (c3311)

Marketing knowledge category

CL=1

CL=2

CL=3

CL=4

CL=5

Fig. 5. Partial IT and Marketing knowledge categories in domain ontology.

Table 1

List of profiles and parameters.

Phase Item Name and definition Meaning Building methods

I. Generate VKN 1 Role-operation relevance profile br, op, ordeg>

Relevance degree (ordeg) between r and op Analyzing operation logs or KF designers consult domain experts

2 Base knowledge node profile bbkn, op>

Associate bkn and op KF designers consult domain experts 3 Granular threshold

TH

Parameter to determine the granularity of the generated VKNs

Decided by roles and KF designers II. Abstract knowledge

concepts

4 Role-operation krdeg profile br, op, ca, krdeg> includes a parameter krdeg

Degree of knowledge required (krdeg) by role r with respect to operation op in category ca

Roles and KF designers input krdeg in the profile 5 Operation required KCS profile

bop, ca, kcs>

Required knowledge concept set (kcs) in category ca for performing op

Let T denote the number of times that role r performs all of the assigned operations, and let N denote the number of times that role r performs an operation op. The default operation relevance degree of r with respect to op is N/T. For example, three operations, selling iPAD (op1), devising business model (op2), and designing advertisement (op3),

are assigned to a role r, marketing manager. The role r performs op1

twice, op2seven times, and op3once; then T equals 10. The operation

relevance degree ordeg of r is 0.2 for op1, 0.7 for op2, and 0.1 for op3.

In-tuitively, a higher ordeg indicates greater relevance between a role and an operation. Moreover, the higher the cost associated with an tion performed by a role, the higher the relevance degree of the opera-tion to the role will be. Let Q denote the total cost of the operaopera-tions assigned to role r, and let C denote the cost of a specific operation op. The ordeg of role r when performing operation op is C/Q. Based on activity-based costing (ABC) models, the cost can be measured in terms of the time and resources expended by roles when they perform assigned operations. In summary, different statistics can be extracted from the historical log data. Some decision-making methods can be employed to derive the ordeg by combining the statistics.

It is noteworthy, while implementing a role-based KFV system, that the proposed methods for constructing the role-operation rele-vance profiles need to be fine-tuned in terms of the culture of organi-zations, the accommodation of peripheral systems and the context of operations. Workers' future operation logs can also be used to adjust ordeg to satisfy their real time knowledge-needs. These adjustments are essential to obtain appropriate VKNs.

4.2.6. Evaluation of role-knowledge node relevance

The relevance degree between a given role and a BKN can be de-rived from role-operation relevance profile and base knowledge node profile. For example, given a role-operation relevance profile {br, op1, 0.2>, br, op2, 0.05>} and a knowledge node profile {bbkn1,

op1>, b bkn1, op2>}, the relevance degree between r and bkn1 is

max (0.2, 0.05) = 0.2. That is, the relevance degree between r and bkn1is the largest ordeg among all operations related to bkn1.

5. Discovering role-based virtual knowledgeflows

In this section, we propose a role-based approach for discovering virtual knowledgeflows (VKF) suitable for participating roles. Gener-ating VKFs involves two phases: Phase I identifies role-relevant

virtual knowledge nodes (VKNs); and Phase II derives the knowledge concepts of the identified VKNs.

Phase I is to aggregate the BKNs based on their relevance to a given role. The relevance degree between a BKN and a role, which is derived as discussed inSection 4.2, describes how important the BKN is to the role. Based on the relevance degrees, procedures can be de_{fined to generate appropriate role-based VKFs for different} roles. The knowledge concept abstraction process in Phase II obtains the knowledge concepts of VKNs based on operation required KCS pro-file and role-operation krdeg propro-file. An operation required KCS propro-file indicates the specific knowledge concepts required to perform an op-eration. For a given operation, different roles may require different degrees of knowledge. The role-operation krdeg profile indicates how specific the knowledge required for the role will be. The smaller the krdeg, the more general the required knowledge will be. The krdeg is used to adjust operation required knowledge concepts to a more general concept level in the domain ontology. The abstraction meth-od analyzes the concept levels of required knowledge concepts and abstracts them to a suitable concept level.

InSection 5.1, we propose an approach for identifying role-relevant VKNs. In addition, the corresponding ideas and algorithms for generat-ing role-based VKFs are introduced. We explain how to derive the knowledge concepts of VKNs inSection 5.2.

5.1. Phase I: generate virtual knowledge node

We propose algorithms that generate role-relevant VKNs auto-matically based on the role-knowledge node relevance degrees de-scribed in Section 4.2, which can be derived from role-operation relevance profile and base knowledge node profile. To obtain VKNs, KF designers take the highest order BKN x in the BKF as a seed node to identify a role-relevant VKN by combining adjacent BKNs based on their relevance to the given role. The detail steps are described in the following subsections.

5.1.1. Identifying role-relevant virtual knowledge nodes

A VKN in a role-based VKF denotes a meaningful knowledge unit of interest to the role; thus, it should be relevant to the role. Algorithm VKNSGenerator identifies VKNs based on a BKF bBKNS, BD>. The objec-tive is to discover the VKNs whose relevance degrees approximate a granular threshold, TH, which is decided by roles and KF designers. Fig. 6. Two-phase approach to generate role-relevant VKNs.

The algorithm VKNSGenerator inFig. 7selects the highest order BKN x in the BKF as the seed node to identify a role-relevant VKN. It uses the algorithm GenerateRVKN to aggregate the adjacent BKNs based on their relevance to the role. When the total relevance degree of the set of aggregated BKNs approximates TH, a VKN is identified for the role and deemed relevant to the role. The above steps are repeat-ed on the remaining BKNs until all of the derivrepeat-ed VKNs cover all BKNs of the BKF. The process yields a set of VKNs to build the target VKF. For any pair of VKNs, vx and vy, a virtual dependency vdep (vx, vy) exists if dep(x, y) exists in BD, where x is a member of vx and y is a member of vy.

Next we explain three important components of the algorithm VKNSGenerator: (1) determining the relevance between roles and BKNs, (2) generating a role-relevant VKN by algorithm GenerateRVKN and (3) verifying the order-preserving property.

5.1.2. Determining the relevance between roles and base knowledge nodes

From the base knowledge node profile, KF designers can determine whether a BKN is associated with certain operations. In addition, the role-operation relevance profile indicates the degree of relevance of an operation to a role. The relevance of a BKN to a role can be derived from the base knowledge node profile and the role-operation relevance profile by applying maximum function over the ordeg of the opera-tions associated with the BKN, as described inSection 4.2.

Granular Threshold TH determines the granularity of a generated VKN. After calculating the degree of relevance of each BKN to the role, the algorithm GenerateRVKN combines adjacent BKNs to gener-ate a role-relevant VKN. When the sum of the relevance degrees of the set of adjacent BKNs approximates TH, the set of adjacent BKNs can form a VKN, which is deemed relevant to the role. A larger TH cor-responds to the generation of fewer VKNs, which means that more BKNs are included in one VKN.

Total relevance degree FTRD: Let function fKRD(role r, base

knowl-edge node bkn) return the relevance degree of bkn to role r; and let function FTRD(role r, base knowledge node set V) return the total

de-gree of relevance of a virtual knowledge node vkn comprising the base knowledge node set V. FTRD(r, V) =Σ fKRD(r, bkni) for all bkni∈V.

The threshold TH in Phase I (Generate VKN) is determined by the roles and KF designers to obtain VKNs with their expected granularity. Abstracting BKNs based on the degrees of relevance of role-knowledge nodes could help to accumulate several less role-relevant BKNs until their total degree of relevance, FTRD, is close to a threshold TH. In order

to sustain productivity and conduct KM effectively, a role requires great-er attention paid to the opgreat-erations and associated knowledge concepts

of BKNs with high degrees of relevance to the role. Roles can omit the specific (detailed) information of BKNs with low degrees of relevance. Accordingly, BKNs with low degrees of relevance to a role are aggregated until they form a role-relevant VKN that is sufficiently relevant to the role. Here, a granular threshold TH is set as the criterion to determine suf_{ficient relevance. According to a role-relevant VKN, a role can have} a general idea about the BKNs included in the VKN and omit the specific (detailed) information of those BKNs.

For example, given three BKNs: k1, k2and k3with relevance degrees

0.1, 0.2 and 0.05 to role r, respectively, role r sets TH as 0.4. In other words, role r requests the detail information and knowledge concepts of these less role-relevant BKNs to be ignored until their total degree of relevance, FTRD, is close to 0.4 after abstraction. Hence, KF designers

aggregate k1, k2and k3to a virtual knowledge node, vkn1, following

the proposed role-based knowledgeflow abstraction methods. The de-gree of relevance between role r and vkn1would be 0.35, which is close

to 0.4. After the abstraction, the virtual knowledge node, vkn1, deserves

role r's awareness.

5.1.3. Virtual knowledge node generation algorithm

The algorithm GenerateRVKN generates a VKN, which contains a given seed node, by repeatedly aggregating the adjacent BKNs according to the order of their relevance degrees sorted from high to low. Note that the aggregation of BKNs needs to satisfy the order-preserving property; this will be illustrated inSection 5.1.4. The process is repeated until the total relevance degree of the aggre-gated BKNs approximates TH. The steps of the algorithm are detailed inFig. 8.

For a virtual knowledge node vkn =bvid, V, D, VKC>, the members of V must be identified first. Initially, V only contains the given seed knowledge node bkn. The algorithm then determines whether the BKNs which are adjacent to members of V can be added to maximize its total relevance degree FTRD(r, V) so that it approximates TH. V is

updated during the while loop by adding the adjacent BKNs that sat-isfy three conditions: (1) V conforms to the order-preserving proper-ty; (2) the total relevance degree of V does not exceed the threshold (FTRD(r, KNStmp)≤TH); and (3) V does not overlap with previously

derived VKNs (KNStmpRKNS). The repeat-until loop continues until

no other adjacent BKNs can be added to V, i.e., no more adjacent BKNs can be added to V, which still satisfy the threshold limit and maintain order-preserving property.

5.1.4. Verification of the order-preserving property

Liu and Shen[22]developed an order-preserving approach that gen-erates virtual processes from a base process in workflow environments.

The approach ensures that the generated virtual process satisfies the following order-preserving property: the implied ordering relations of activities in a virtual process must comply with the ordering relations of ac-tivities in the base process. The generation algorithm GenerateRVKN adopts the order-preserving approach to ensure that a VKF maintains the knowledge referencing order in its corresponding BKF. A legal virtu-al knowledge node vkn =〈vid, V, D, VKC〉 must satisfy the following order-preserving property: the implied ordering relations of VKNs in a VKF must comply with the ordering relations of the BKNs in its correspond-ing BKF. The order-preservcorrespond-ing property is satisfied when the ordering relations between any BKN x_{∉V and all member knowledge nodes in} V are identical as their ordering relations in the corresponding BKF. Re-garding the function OderPrsv in algorithm GenerateRVKN for adopting the order-preserving approach, please refer to our previous work

[19,21,22]for the detailed steps and examples. 5.1.5. Illustrating examples

Given a base knowledge node bkn1and its adjacent base

knowl-edge nodes, bkn2and bkn3, we explain how the algorithm generates

a virtual knowledge node vkn1.

Example 1. The role-knowledge node relevance degree is derived from the following profiles. (A) Base knowledge node profile: {bbkn1, op1>.

bbkn1, op2>,bbkn1, op5>,bbkn1, op7>}, which indicates that operations

op1, op2, op5and op7are associated with bkn1. (B) Role-operation

rele-vance profile: {br1, op1, 0.6>, br1, op2, 0.3>,br1, op5, 0.4>,br1, op7,

0.1>}, which indicates the relevance degrees between r1and the

oper-ations. Based on the above information, the maximum function is used to obtain the relevance degree between bkn1and r1: Max (0.6, 0.3, 0.4,

0.1)= 0.6

Example 2. A VKN is generated from the following profiles. (A) Base knowledge node profile: {bbkn2, op3>,bbkn2, op5>,bbkn3, op4>,bbkn3,

op6>}, which indicates bkn2is associated with op3, op5, and bkn3is

as-sociated with op4, op6. (B) Role-operation relevance profile: {br1, op3,

0.2>,br1, op5, 0.3>,br1, op4, 0.1>,br1, op6, 0.2>}. The profile indicates

the relevance degrees between r1and the operations associated with

bkn2and bkn3. Based on the above information, the maximum

func-tion is used to obtain the relevance degrees of bkn2and bkn3for r1.

Max (0.2, 0.3) = 0.3 for bkn2; Max (0.1, 0.2) = 0.2 for bkn3. The

rele-vance order of the adjacent knowledge nodes of bkn1is bkn2followed

by bkn3.

Taking the order structure into consideration, bkn2and bkn3are

candidate nodes to be combined with bkn1. Assuming that the

threshold TH is 1, the relevance degrees for bkn2and bkn3are 0.3

and 0.2, respectively. According to the function FTRD, the two nodes

cannot be combined with bkn1 together to form a VKN because

fKRD(bkn1) + fKRD(bkn2) + fKRD(bkn3) > 1. However, the total

rele-vance degree fKRD(bkn1) + fKRD(bkn2)≤1, which is not greater than

TH. Thus, bkn1is combined with bkn2to form a virtual knowledge

node vkn1.

5.2. Phase II: abstract knowledge concept

After a virtual knowledge node vkn has been generated, its knowl-edge concepts can be derived.Fig. 9shows the algorithm KCGEN-OKR that derives the knowledge concepts of vkn based on the operation re-quired knowledge concept set (KCS) profiles and the role-operation knowledge requirement degree (krdeg) profiles.

We explain how to derive the required KCS and corresponding krdeg for operations that the role performs on a VKN. The operation required knowledge concepts indicate the most specific level of knowledge in the domain ontology that are required to perform oper-ations. Different roles may require different degrees of knowledge to perform operations. In this work, we use the knowledge requirement degree krdeg as the basis to abstract the operation required knowl-edge concepts into the appropriate concept levels CLs) in order to sat-isfy a role's operation knowledge requirement. The virtual knowledge node vkn may include more than one BKN, so the knowledge concepts of all BKNs should be abstracted to derive the knowledge concepts of vkn. The knowledge concept abstraction process involves two steps. Thefirst step derives the required knowledge concept set (KCS) and cor-responding knowledge requirement degrees (krdeg). The second step Fig. 8. Algorithm for generating a role-relevant VKN.

adjusts (generalizes) the knowledge concepts in KCS to the appropriate concept level according to the corresponding krdeg of the role.

An operation required KCS profile specifies the knowledge concepts required in different knowledge categories to perform an operation. The domain ontology is divided into different knowledge categories; an op-eration may be associated with more than one knowledge category. From the operation required KCS profile, the specific knowledge con-cepts required for each operation in each knowledge category are obtained. For a given operation, different roles may have different de-grees of knowledge requirements in different knowledge categories. The role-operation krdeg pro_{file is used to define how specific or general} the required knowledge in a certain knowledge category should be for role r when it performs an operation. From the operation required KCS profile and role-operation krdeg profile, KF designers can generate the set of required knowledge concepts and their corresponding knowl-edge requirement degrees for the role to perform the operations associ-ated with vkn. A role may have different knowledge requirement degrees to perform different operations that need the same knowledge

concepts. Therefore, a knowledge concept required by a role may be associated with more than one krdeg. The maximum function is used to derive thefinal krdeg of a concept for the role.

Thefirst step in algorithm KCGEN-OKR is to derive required KCS and corresponding krdeg, which uses several working sets and variables for computation, including: (1) OPrvknis a working set of operations. The

op-erations are associated with vkn and performed by r. Thereby; vkn com-prises a set of merged BKNs. (2) KCSopcais a working set of knowledge

concepts. The knowledge concepts belong to knowledge category ca and they are required to perform operation op. (3) krdegr,opca is a working

variable of r's knowledge requirement degree. The krdeg is related to knowledge category ca and operation op. (4) CRDrvknis a working set

as-sociated with r and vkn. It is a 3-tuplebconcept c, category ca, knowl-edge requirement degree krdeg>, which indicates the required krdeg of c in ca. CRDrvknis derived from OPrvkn, KCSopcaand krdegr,opca as detailed

in algorithm KCGEN-OKR.

In algorithm KCGEN-OKR, the second step is to adjust (generalize) the knowledge concepts to the appropriate concept level according to Fig. 9. Algorithm for generalizing knowledge concepts of a VKN.

krdeg. For each knowledge concept in CRDrvknbconcept c, category ca,

knowledge requirement degree krdeg>, krdeg determines how many levels of the original concept c should be abstracted. The value of krdeg is between 0 and 1; the larger the value, the more specific the knowledge concepts that are required; conversely, the smaller the value, the more general the knowledge concepts that are required. If krdeg is 1.0, the most specific level of knowledge concept is re-quired, so there is no need to perform abstraction. A function GenConcept(c, ca, krdegr,cca) is used to adjust the concept c in category

ca to an appropriate concept level according to krdegr,cca. For example,

if krdegr,AppleMarketing= 0.8, GenConcept (Apple, marketing, 0.8) returns the

parent knowledge concept brand of knowledge concept Apple in cat-egory marketing. According toFig. 5, the concept level (CL) of brand is 4 and the CL of Apple is 5. That is, GenConcept (Apple, marketing, 0.8) executes one-level up abstraction of Apple to get generated con-cept (gc) through the domain ontology as shown in algorithm KCGEN-OKR. If krdegr,cca= 0.6, GenConcept(c, ca, 0.6) returns the grandparent

knowledge concept of concept c in category ca by executing two-level up abstraction through the domain ontology. If there are insuf_ficient levels in the domain ontology can be obtained when executing the func-tion GenConcept, the concept c is abstracted to the most general concept level. If krdegr,cca= 1.0, no abstraction is needed; GenConcept(c, ca, 1.0)

returns the concept c. It is notable that the mapping between the value of krdeg (0.8, 0.6,…) and the levels of abstraction (one-level up abstraction, two-level up abstraction,…) can be adjusted by KF de-signers depending on applications.

The function GenConcept(c, cl, acl) is used to adjust concept c to an appropriate concept gc. Let GKCS (generalized knowledge concept set) denote the set of knowledge concepts for vkn. For each knowl-edge concept c of the member knowlknowl-edge nods in vkn, GKCS is added with the generalized knowledge concept gc, which is derived from concept c, to meet r's knowledge requirement. The_{final step} of the procedure removes the implied (redundant) concepts from GKCS and yields the knowledge concepts VKC of vkn.

Example 3. The knowledge concepts of vkn, which combines bkn1

and bkn2, are derived as follows. (A) Base knowledge node profile:

{bbkn1, op1>,bbkn1, op2>,bbkn2, op3>}. (B) Operation required KCS

profiles: bop1, Marketing, {Apple (c3111), benefit (c3311), discount

(c3422)}>,bop1, IT, {Java (c2321), user need (c212)}>,bop2,

Market-ing, {need (c312), Apple (c3111), discount(c3422)}>,bop3, IT, {Java

(c2321), system (c221)}>. These knowledge concepts are in different knowledge categories as shown inFig. 5. (C) Role-operation krdeg profiles: br, op1, Marketing, 0.8>,br, op1, IT, 0.6>,br, op2, Marketing,

0.6>,br1, op3, IT, 0.4>.

Investigating the operation required KCS profiles in Example 3, op1

and op2require the same knowledge concepts Apple and discount in

Marketing knowledge category. Moreover, op1 and op3require the

same knowledge concept Java in IT knowledge category. Thus, the krdeg of knowledge concept Apple, discount and Java should be preprocessed by a maximum function before abstraction. In Market-ing knowledge category, the krdeg of Apple and discount for op1is

0.8, for op2is 0.6. After applying the maximum function Max (0.8,

0.6), thefinal krdeg of Apple and discount is 0.8, which means that the two knowledge concepts should be abstracted by one-level up to their parent knowledge concepts brand and promotion respectively, according to the domain ontology inFig. 5. In IT knowledge category, the krdeg of Java for op1is 0.6, for op3is 0.4. Thus, thefinal krdeg of

Java is Max (0.6, 0.4) = 0.6. Thus, the knowledge concept Java should be abstracted by two-level up to knowledge concept programming as well.

6. Designing a role-based KFV system

We analyze the proposed model and concepts to conduct the basic system design of a role-based KFV system. The basic system design

constructs an overall architecture by identifying important functional modules and decomposing them into layers. An activity diagram models the procedural_{flow of actions from the perspectives of KF} de-signers, roles and experts. Moreover, Protégé 4.0 software is used to build an ontology prototype to represent knowledge concepts and their hierarchical relationships in the mobile phone development do-main. The system architecture, activity diagram and ontology prototype are the fundamental elements for putting the theoretical model into practice.

Fig. 10depicts the system architecture to implement the role-based KFV system, which comprises four layers: data link layer, configuration layer, modeling layer and application layer.

6.1. Data link layer

This layer enables data links to other legacy systems to collect in-formation from external data sources during the design time and run time. The operation logs preserve the history of roles' operations in work_{flow management systems. The knowledge databases store} cod-ified knowledge which is labeled by the knowledge concepts of do-main ontology. Enterprise knowledge-based management systems can be utilized to manage these knowledge databases and provide inter-faces for the role-based KFV system to access required codified knowl-edge. Domain ontology stores the pre-defined knowledge concepts and their hierarchical relationships for the purpose of representing knowledge-needs and facilitating knowledge concept abstraction. 6.2. Configuration layer

This layer comprises three parts: profile management module, BKF and role-based VKF repository as well as relevance degree calculating engine. KF designers and experts utilize the pro_{file management} module to collect essential information, such as role-operation rele-vance profiles, operation required KCS profiles and base knowledge node profiles. The BKF and role-based VKF repository preserves model definitions and enactment instances. The role-knowledge node relevance degree calculating engine is responsible for obtaining the relevance degrees between roles and BKNs.

6.3. Modeling layer

This layer includes three definition tools to define BKFs, role-based VKFs and roles' knowledge requirement degrees. Roles use the knowl-edge degree definition tool to set role-operation krdeg profiles to reflect roles' krdeg based on their knowledge-needs. Meanwhile, KF designers work with experts to specify BKFs and corresponding role-based VKFs by BKF and role-based VKF definition tools, respectively. Moreover, the algorithms shown inFigs. 7, 8 and 9for generating role-based VKFs will be realized in the definition tools.

6.4. Application layer

An integrated platform is built in this layer for the operations of KF designers, experts and roles. This layer mainly provides an interface for them to get visualization support and maintain profiles.

We produced the activity diagram of the role-based KFV system, as shown inFig. 11. The actors in the activity diagram are KF de-signers, roles and experts. They perform these procedural activities and produce relevant material for generating role-based VKFs. The activity diagram is organized into three partitions to indicate the major responsible person of the activities of each partition. The rounded rectangles represent the activities which are performed by actors manually or executed by the tools of the role-based KFV sys-tem. And the rectangles show the material such as profiles, parame-ters or intermediate output that passed between activities. We omitted the detailed explanation of the activity diagram here because

it is somewhat self-explanatory. The activity diagram is useful for sys-tem modeling to describe the controlflow of the role-based KFV sys-tem, such as exploring the knowledge concept abstraction and knowledge node generation approaches, as well as parameter evalu-ation and adjustment methods.

An approach of iterative evaluation and adjustment is adopted in the design tofine-tune profiles and parameters to improve the fitness level of VKFs. At the bottom of the left partition in the activity dia-gram, role r should evaluate the_{fitness level of the generated VKF. If} role r is satisfied with the VKF, the procedure stops. Otherwise, role Fig. 10. System architecture of the role-based KFV system.

r would reflect the discrepancies of current VKF to KF designers and/or experts. Then, they may adjust BKF, ontology, krdeg, or TH and estimation methodologies, and regenerate VKFs again until role r satis_{fies the} result. For example, the iteration of krdeg's adjustment is shown by the merging of a start point (●) and the label © in the top of the left partition inFig. 11.

The role-based concept has been adopted in many workflow related studies to reduce the impact of people turnover. Hence, the role-based VKFs are generated from a role perspective instead of an individual user perspective. The knowledge concepts in a VKN are the required knowledge concepts for roles to perform corresponding operations and communicate with other teammates. In case, some certain users playing the roles may already have the knowledge contained in the VKN or they cannot be satisfied with the knowledge concepts of the VKN. The certain users canfine-tune krdeg to adjust the knowledge concepts in the VKN to meet their requirements afterwards.

We used Protégé 4.0 software to build an ontology prototype, as shown inFig. 12, to represent a part of knowledge concepts and their hierarchical relationships in mobile phone development do-main. The process of ontology construction would include an evalua-tion and feedback mechanism to gradually improve ontology quality and result in a common understanding in organizations. The ontology prototype is appropriate for system designers to understand the con-cepts of ontologies in system design phase. Since new knowledge is continually generated with changes in technology and business envi-ronments, KF designers should periodically maintain domain ontol-ogies and BKFs to check if any knowledge concepts should be added to or removed from BKNs. After the adjustment of BKFs, KF designers can regenerate new VKFs per roles' demands.

7. Case illustration and discussion

This section uses a base knowledge_{flow (BKF) of a mobile phone} company, named Smart-Tech Company, to illustrate the application of the role-based KFV model. The BKF represents the knowledge

which a project team requires while conducting a mobile phone de-velopment process. KF designers build the BKF based on the mobile phone development process, as shown inFig. 1. They consult domain experts to identify important knowledge-needs and seek proper knowledge concepts in domain ontology for the purpose of building the BKF to represent these knowledge-needs. The participants of the mobile phone development team work for different departments and play different roles in the team. For example, a sourcing planner role performs the logistics of parts outsourcing and a sourcing depart-ment manager role evaluates project performance and the sourcing planner role's productivity. The sourcing department manager role is responsible for communicating with the project manager about the project status and outsourcing strategy, as well as appraising the performance of the sourcing planner role. Therefore, KF designers can generate a role-based VKF from the BKF to represent the sourcing department manager role's knowledge-needs to support task execu-tion. The following discussion illustrates the process used to generate the role-based VKF. First, the BKF and the relevance degrees between the sourcing department manager role and the BKNs are obtained by the approach described inSection 4.2. The BKF inFig. 13 includes eight BKNs, k0to k7. Each BKN contains multiple knowledge concepts

and has distinct operation relevance degrees to r, herein; r stands for the sourcing department manager role.

Next, KF designers generate virtual knowledge nodes (VKN) based on a threshold (TH) 0.4. They select a BKN with the highest order, k0,

as a seed node to generate thefirst virtual knowledge node vkn1. The

adjacent base knowledge node set AKNS of k0is {k1}. So, vkn1is

consid-ered a legal VKN having two member knowledge nodes k0, k1. After

checking FTRD(r, {k0, k1}), KF designers canfind FTRD(r, {k0, k1}) = fKRD

(r, k0) + fKRD(r, k1) = 0.1≤TH, which meet the threshold requirement.

And vkn1 also complies with the order-preserving property. So,

vkn1is a legal VKN when it has two member KNs k0, k1. Because

FTRD(r, {k0, k1}) is not approximately close to TH, KF designers

con-tinue to evaluate AKNS of {k0, k1}, which is {k2, k5}. According to the

order-preserving property, we should add BKNs k2, k3, k4, k5and k6

into vkn1. However, FTRD(r, {k0… k6}) =∑fKRD(r, kj) {j = 0… 6} =

0.55 exceeds TH. Therefore, the_{first virtual knowledge node vkn}1

and its member knowledge nodes, k0and k1, are determined.

Repeat-ing the iteration, the BKNs are merged into four virtual knowledge nodes vkn1, vkn2, vkn3and vkn4to form a role-based VKF, as shown

inFig. 14.

The following discussion takes virtual knowledge node vkn2as an

example to illustrate the concept abstraction method. First, KF de-signers and role r set r's knowledge-needs in terms of krdeg by differ-ent knowledge categories. A partial domain ontology which includes five knowledge categories, such as: Marketing, Industrial design, Hard-ware design, SoftHard-ware design and Sales, is illustrated inFig. 15. It is to be noted that the partial domain ontology is only used for concept ex-planation and case illustration here, instead of implementing a role-based KFV system in an organization. Ontology construction for organization use is a complex task and needs to further consider users' requirements, IT environments and the context of applications. This type of ontology is much more complete and complex than the partial domain ontology inFig. 15.

Based on the two-phase approach for generating role-based VKFs shown inFig. 6, KF designers, experts and role r determine the rele-vant profiles and parameters as shown inFig. 16. According to the al-gorithm inFig. 9, the knowledge requirement degree krdegr,cca, which

represents the knowledge requirement degree of role r in regard to the knowledge concept c in the knowledge category ca, can be

obtained as below through computing the operation required KCS pro_{files and the role-operation krdeg profiles.}

krdegmarketing_{r;customerbehavior}¼ 0:6 krdegHardware Design_{r;card options} ¼ 0:6 krdegHardware Design_{r;battery options} ¼ 0:6 krdegHardware Design_{r;Baseband design rule}¼ 0:6

krdegHardware Design_{r;RF design rule} ¼ 0:6 krdegmarketing_{r;service level agreement of thirdparties}¼ 0:8 krdegmarketing_{r;price=performance of parts}¼ 0:8 krdegHardware Design

r;display options¼ 1:0:

Finally, the knowledge concepts are generalized to required con-cept levels. Consequently, the knowledge concon-cepts of virtual knowl-edge node vkn2 are marketing, outsourcing, hardware design and

display options. The same method can apply to other VKNs.Fig. 17

shows the_{final result of the role-based VKF for sourcing department} manager role.

7.1. Simulation by examples

As shown inTable 1, two phases are required to generate VKFs. Phase I generates VKNs and Phase II derives knowledge concepts for these VKNs. The profiles, including role-operation relevance profile and base knowledge node profile in Phase I, role-operation krdeg pro-file and operation required KCS propro-file in Phase II, are predetermined by KF designers according to the involved operations and the partici-pating roles in the BKF. The parameters, including threshold TH in Fig. 13. Operation relevance degrees between role r and BKNs.

Phase I and knowledge requirement degree krdeg in Phase II, can be adjusted by roles and KF designers to reflect roles' requirements. The simulation by examples is performed to evaluate these two parameters, which is based on the BKF shown inFig. 13.

In Phase I, the granular threshold TH is a parameter to determine the granularity of the generated VKNs.Fig. 18shows the simulation result when the threshold TH increases from 0.1 to 0.7, which illus-trate different level of aggregate abstraction of the BKF. The different level of aggregate abstraction can provide appropriate VKFs for

concealing the detail structure of the corresponding BKFs to reduce the complexity and improve comprehension for roles. As shown in

Fig. 18, larger TH deriving fewer VKNs can conceal the more detailed structure of BKFs. On the other hand, the smaller TH deriving more VKNs can illustrate the details of BKFs.

In Phase II, the krdeg is a parameter for roles to set the expected concept levels (CLs) of knowledge concepts in VKNs. Fig. 19(a) takes the vkn2inFig. 18(c) as an example. The TH of the

correspond-ing VKF is 0.4 and the knowledge concepts in the VKF can be found in Fig. 15. Partial knowledge categories of Marketing and Hardware Design.

Fig. 14. Following the algorithm inFig. 9to perform knowledge con-cept abstraction, theFig. 19(b), (c) and (d) demonstrate the result of knowledge concepts abstraction for vkn2when krdeg is set to 1.0,

0.8 and 0.6 for all knowledge categories respectively, which means no abstraction, one-level up abstraction and two-level up abstraction. Because the concept level reflects the granularity of knowledge con-cepts, the concept levels of knowledge concepts increases while krdeg increases, which means that the knowledge concepts are more specific. Thus, roles can select the smaller krdeg to obtain more general knowledge concepts to communicate with other team-mates or they can select the larger krdeg to get more specific knowl-edge concepts to perform their operations. Based on the investigation of the simulations, the parameters TH in Phase I and krdeg in Phase II serve different purposes and they are set by KF designers and roles according to their requirements.

7.2. Feasibility evaluation and implications

To investigate the feasibility of the role-based KFV model, a pre-liminary analysis was conducted. We illustrated the case of mobile

phone development and provided system design-related documents to several professionals to ask for their opinions about the feasibility of the proposed model from a practical perspective. Overall, there was general agreement that it is justified and feasible to realize the role-based KFV model in organizations. According to their opinions on system implementation, the provided system architecture and ac-tivity diagram can be the base to conduct detailed system design for building functional specifications as well as for implementation.

Moreover, these interviewees highlighted that a role-based KFV sys-tem tends to evolve in a longitudinal process. The proposed approaches heavily rely on the knowledge of domain experts, KF designers and roles while building KFs and virtual KFs. People put their knowledge in pro-files and estimate related parameters while realizing the model, but their experience and knowledge is implicit and hard to obtain systemat-ically. Hence, the back-and-forth between system evaluation and pa-rameter adjustment is necessary for obtaining a well-run system; it will not be trivial work and needs lots of time and effort. From the indus-trial professionals' perspective, profile setting and parameter estimation according to people' opinions is a common practice for implementing IT systems, especially in design and pilot run phases.

Fig. 17. Role-based VKF for sourcing department manager role.

(a)

(b)

(c)

(d)

(e)