Let a function fKRD (role r, base knowledge node kn) return the relevance degree of kn to role r; and let a function FTRD (role r, base knowledge node set V) return the total relevance degree of a virtual knowledge node vkn with knowledge node set V. FTRD (r, V) =
fKRD (r, kni) for all kni V. The total relevance degree estimates the closeness between a role and a set of base knowledge nodes.
5.3.2 Deriving Knowledge Concepts of Virtual Knowledge Nodes
Deriving knowledge concepts for a virtual KN, vkn, is to abstract all knowledge concepts of its member knowledge nodes to proper concept levels based on role r’s knowledge requirement degrees. An illustration example is shown in Figure 20.
Supposedly, the vkn consists of two base KNs, k1 and k2, as shown in Figure 20(a).
The knowledge concepts of k1 and k2 should be abstracted. The knowledge concept abstraction process involves following steps and utilizes profiles and settings in the role-based framework:
(1) Identify the set of operations performed by r and associated with vkn. The set
vkn
OPr can be obtained from combining knowledge node profiles of vkn’s member KNs.
According to Figure 20(b), OPrvkn is {opx, opy} after combing knowledge node profiles {<k1, opx>, <k2, opy>}.
(2) Discover the set of required knowledge concepts to conduct operations op
vkn
OPr . The setKCSopca comprises a set of 3-tuple <operation op, knowledge category ca, knowledge concepts KCS >. It illustrates that the knowledge concepts KCS in ca are required to perform op. KCSopca can be obtained from operation required knowledge concept profile.
Based on the operation required knowledge concept profile shown in Figure 20(d),
52
ca
KCSop can be formed as { <opx, ca1, {C111, C112}>, <opy, ca1, {C112}>, <opx, ca2,
{C221}>, <opy, ca2, {C222}>}.
(3) Let CRDrvkn be a set of 3-tuple <concept c, category ca, knowledge requirement degree krdeg >, which indicates the knowledge requirement degree krdeg of knowledge concept c for role r with respect to knowledge category ca. CRDrvknis derived from
ca
KCSop and role-operation knowledge requirement degree profile.
Based on Figure 20(e), the role-operation knowledge requirement degree , ca knowledge requirement degree ,
ca
(4) Adjust (generalizing) the knowledge concepts to the appropriate concept level according to the role’s knowledge requirement degree ca,
krdegr c . The knowledge requirement degrees are used to abstract the required knowledge concepts into appropriate concept levels in order to satisfy a role’s operation knowledge requirement. The adjust step follows the hierarchy structure of domain ontology to generalize knowledge concepts to their parent knowledge concept until the concept levels of the parent knowledge concepts meets roles’ requirement ca,
krdegr c.
A function GenACL is defined to map the knowledge requirement degree to the appropriate adjusted concept level. GenACL may be defined to map the value of degree 0.8 to one concept level of abstraction, and the value 0.6 to two levels of abstraction, and so on.
For example, the concept level cl of c111 is 4 based on the ontology shown in Figure 20(c).
The knowledge requirement degree of c111 ( ,1111 concept (c11) at level 3 in ca1 by applying function GenConcept.
53 (d) Operation required
knowledge concept profile
ca1 ca2
opx {C111, C112} {C221} opy {C112} {C222}
Top
C1 C2
C11 C12
C112
C111
C21 C22
C211 C221 C222
(e) Role-operation knowledge requirement degree profile
krdeg ca1 ca2
opx 0.8 1.0
opy 0.6 0.6
k1 k2
(a) Virtual KN, vkn
k1 opx
k2 opy
(c) Ontology (b) Knowledge
node profile
(5) Follow Definition 16 (Implied Concept) to remove the implied (redundant) concepts.
Iteratively applying the five steps to all virtual KNs in the deriving virtual knowledge flow, the virtual knowledge flow should be proper for the role r by fulfilling his/her knowledge requirements.
Figure 20. Illustration example of deriving knowledge concepts for a virtual KN.
The detail algorithm of deriving knowledge concepts of role-based virtual KNs is described in a previous work [35].
54
5.4 Designing a role-based KFV system
This section analyzes the proposed r-KFV 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 designers, 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 domain. The system architecture, activity diagram and ontology prototype are the fundamental elements for putting the theoretical model into practice.
Figure 21. System architecture of the role-based KFV system.
Figure 21 depicts the system architecture to implement the role-based KFV system, which comprises four layers: data link layer, configuration layer, modeling layer and application layer.
Data link layer: This layer enables data links to other legacy systems to collect information from external data sources during the design time and run time. The operation logs preserve the history of roles’ operations in workflow management systems. The
55
knowledge databases store codified knowledge which is labeled by the knowledge concepts of domain ontology. Knowledge-based management systems manage these knowledge databases and provide interfaces for the role-based KFV system to access required codified knowledge. Domain ontology stores the pre-defined knowledge concepts and their hierarchical relationships for the purpose of representing knowledge-needs and facilitating knowledge concept abstraction.
Configuration layer: This layer comprises three parts: profile management module, base KF and role-based virtual KF repository as well as relevance degree calculating engine. KF designers and experts utilize the profile management module to collect essential information, such as role-operation relevance profiles, operation required knowledge concept profile and knowledge node profiles. The base KF and role-based virtual KF 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 knowledge nodes.
Modeling layer: This layer includes three definition tools to define base KFs, role-based virtual KFs and roles’ knowledge degrees. Roles use the knowledge degree definition tool to set krdeg to reflect role-operation knowledge requirement degrees based on their knowledge-needs. Meanwhile, KF designers work with experts to specify base KFs and corresponding role-based virtual KFs by base KF and role-based virtual KF definition tools, respectively.
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.
Figure 22 shows the activity diagram of the role-based KFV system. The actors in the activity diagram are KF designers, roles and experts. They perform these procedural activities and produce relevant material for generating role-base virtual KFs. 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
56
performed by actors manually or executed by the tools of the role-based KFV system. And the rectangles show the material such as profiles, configurations 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 system modeling to describe the control flow of the role-based KFV system, such as exploring the knowledge concept abstraction and knowledge node generation approaches, as well as the complex configuration evaluation and adjustment methods.
Figure 22. Activity diagram.
An approach of iterative evaluation and adjustment is adopted in the design to fine-tune profiles and configurations to improve the fitness level of virtual knowledge flows. At the bottom of the left partition in the activity diagram, role r should evaluate the fitness level of the generated virtual knowledge flow. If role r is satisfied with the virtual knowledge flow, the procedure stops. Otherwise, role r would reflect the discrepancies of current virtual knowledge flow to KF designers and/or experts. Then, they may adjust base KF, ontology, krdeg, or other configurations and estimation methodologies, and the
57
regenerate virtual knowledge flows again until role r satisfies the result. For example, the iteration of krdeg’s adjustment is shown by the merging of a start point () and the label
○C in the top of the left partition in Figure 22.
Protégé 4.0 software is utilized to build an ontology prototype, as shown in Figure 23, to represent a part of the knowledge concepts and their hierarchical relationships in mobile phone development domain. The process of ontology construction would include an evaluation 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 concepts of ontologies in system design phase.
Figure 23. An ontology prototype.
5.5 Case illustration and analysis
This section uses the base knowledge flow (KF) of a mobile phone company as described in Section 4.5. 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 department manager role
58
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 virtual KF from the base KF to represent the sourcing department manager role’s knowledge-needs to support task execution.
The following discussion illustrates the process used to generate the role-based virtual KF. First, the base KF and the relevance degrees between the sourcing department manager role and the knowledge nodes are obtained by the approach described in Section 5.2. The base KF in Figure 24 includes knowledge nodes, k0 to k8. Each knowledge node contains multiple knowledge concepts and has distinct relevance degrees to r, herein; r stands for the sourcing department manager role.
Figure 24. Relevance degrees between role r and base knowledge nodes.
Next, KF designers generate virtual KN based on a threshold (TH) 0.4. They select a base KN with the highest order, k0, as a seed node to generate the first virtual knowledge node vkn1. The adjacent knowledge node set AKNS of k0 is {k1}. So, vkn1 is considered a legal virtual knowledge node having two member knowledge nodes k0, k1. After checking FTRD (r, {k0, k1}), KF designers can find FTRD (r, {k0, k1}) = fKRD (r, k0) + fKRD (r, k1) = 0.1 TH, which meet the threshold requirement. And vkn1 also complies with the
59
1. Consumer behavior 2. Price/performance of parts 3. Service level agreement of 3rdparties
4. Display options 5. Battery options
6. Card options 7. Design rule of RF /Baseband
1. Compliance guideline
1. Features of iOS and Android 2. Multimedia functions vkn1 and its member knowledge nodes, k0 and k1, are determined. Repeating the iteration, the KNs are merged into four virtual knowledge nodes vkn1, vkn2, vkn3 and vkn4 to form a role-based virtual KF, as shown in Figure 25.
Figure 25. Virtual KNs and their relevance degrees when TH=0.4.
The following discussion takes virtual knowledge node vkn2 as an example to illustrate the concept abstraction method. First, KF designers set r’s knowledge-needs in terms of role-operation knowledge requirement degree krdeg by different knowledge categories. A partial domain ontology which includes different knowledge categories, such as: marketing, industrial design, hardware design, software design, quality verification and sales, is illustrated in Figure 26. It is to be noticed that the partial domain ontology is only used for concept explanation 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 in Figure 26.
60
Figure 26. Partial knowledge categories of Marketing and Hardware Design.
Figure 27 shows the relevant information of the sourcing department manager role.
According to the steps described in Section 5.3.2, the knowledge requirement degree
, ca
krdegr c represents the knowledge requirement degree of role r in regard to the knowledge concept c in the knowledge category ca. Hence, ca,
krdegr c includes <Marketing, consumer behavior, 0.6), <Marketing, price/performance of parts, 0.8>, <Marketing, service level agreement of 3rd parties, 0.8>, <Hardware Design, battery options, 0.6>, <Hardware Design, card options, 0.6>, <Hardware Design, display options, 1.0>, <Hardware Design, RF design rule, 0.6>, and <Hardware Design, Baseband design rule, 0.6> through computing the operation required knowledge concepts and the role-operation knowledge requirement degrees krdeg.
Finally, the knowledge concepts are generalized by mapping knowledge degrees to adjusted concept levels. Consequently, the knowledge concepts of virtual knowledge node vkn2 are marketing, outsourcing, hardware design and display options. The same method can apply to other virtual KNs. Figure 28 shows the final result of the role-based virtual KF.
61 1. Marketing 2. Outsourcing 3. Hardware design
3. Display options 1. Quality verification 2. Sales
< major parts identification, Marketing, {consumer behavior}>
< major parts identification, HW Design, {display, battery, card}>
< parts sourcing, Marketing, {price/performance, SLA}>
<parts sourcing, HW Design, {display}>
<hardware design, HW Design, {RF rule, Baseband rule}>
base knowledge node profile
<k2, major parts identification>
<k3, parts sourcing>
<k4, hardware design>
role-operation knowledge requirement degree profile
<r, major parts identification, marketing, 0.6>
<r, major parts identification, HW design, 0.6>
<r, parts sourcing, marketing, 0.8>
<r, parts sourcing, HW design, 1.0>
<r, hardware design, HW design, 0.6>
Virtual KN
Knowledge requirement degree to abstract knowledge concept Role- KN relevance degree to generate virtual KN
Threshold TH = 0.4
Figure 27. Information of sourcing department manager role.
Figure 28. Role-based VKF for sourcing department manager role.
5.6 Discussion
This chapter presents the role-based approach for discovering role-based virtual KFs suitable for participating roles through applying the role-based framework. The r-KFV model is an extension of KFV model described in Chapter 4. The knowledge-needs of workers in a team may vary because they have different roles when they execute tasks. The role-based KFV model examines the worker’s knowledge-needs in terms of his/her role.
Discovering role-based virtual KFs involves two major steps: identifying role-based virtual knowledge nodes (virtual KNs) and deriving the knowledge concepts of virtual KNs. A
62
role-based virtual KF comprises a set of virtual KNs, which are generated from the base KNs according to their relevance to the role. The relevance of a base KN to a given role can be specified by the KF designers or derived by analyzing the role’s knowledge referencing behavior in document access logs. The relevance degree indicates the importance of a base KN to the role. Once the relevance of the aggregated base KNs reaches a certain threshold, a virtual KN is identified for the role. Then, KF designers can derive the knowledge concepts of the virtual KN based on the role’s knowledge requirement degrees. The concept abstraction approach adjusts (generalizes) the knowledge concepts of virtual KNs to the appropriate concept levels based on the operation required knowledge concept profile and the knowledge requirement degrees of the role for the operations.
The proposed system architecture and activity diagram can be the base to conduct detailed system design for building functional specifications as well as for implementation.
It is notable that a role-based KFV system tends to evolve in a longitudinal process. The back-and-forth between system evaluation and parameter adjustment is necessary for obtaining a well-run system; it will not be trivial work and needs lots of time and effort.
The r-KFV model brings practical benefits as follows: (1) the role-based virtual knowledge flows show roles with a full picture of knowledge-needs by presenting corresponding knowledge concepts with proper concept levels; (2) workers can describe their knowledge-needs precisely and gain a consensus quickly in teams by common domain ontology and role-operation knowledge requirement degree profiles; (3) KF designers can avoid complex and time-consuming tasks of estimating parameters for each different role; (4) the iterative evaluation and adjustment approach can fine-tune the fitness level of virtual knowledge flows to increase roles’ satisfaction; and (5) the proposed model facilitates organizational knowledge support platforms to help teams improve their communication quality and increase members’ productivity.
63
Chapter 6 Conclusions
6.1 Summary
This dissertation proposes the novel concepts of knowledge flow abstraction:
knowledge-flow view model and virtual knowledge flows. The knowledge-flow view model enhances the conventional knowledge flow models to improve the effectiveness of knowledge sharing and knowledge support in organizations. In addition, the virtual knowledge flows illustrate teammates’ different knowledge-needs precisely and facilitate collaborative knowledge provision in teamwork environments from task function and role perspectives.
In knowledge-intensive working environments, workers need task-relevant knowledge and documents to support task performance. To meet these requirements, many organizations have built knowledge support platforms that allow workers to preserve, share and reuse task-relevant knowledge. The value of knowledge support thus pertains to the importance of realizing knowledge management and promoting business intelligence in knowledge-based organizations.
Knowledge flow models have been proposed as an effective tool for building knowledge support platforms recently. Knowledge flows represent the flows of an individual’s or group members’ knowledge-needs and the referencing sequence of documents in conducting business operations and/or research activities. Through knowledge flows, organizations can facilitate knowledge support mechanism by providing knowledge to fulfill workers’ knowledge-needs. However, the conventional KF models only provide single view to teammates, without considering participants different knowledge-needs according to their task functions and roles; this leads to decrease the efficiency of knowledge sharing in organizations. To satisfy team workers with different knowledge-needs, this work proposes the BKF model to illustrate knowledge-needs precisely, and the essential KFV model and r-KFV model, which are capable of generating multiple virtual knowledge flows.
64
The KFV model and r-KFV model construct virtual knowledge flows to serve workers’
knowledge-needs. The knowledge-needs are arising from the gap between workers’
knowledge and the necessary requirements of tasks, which including the fine-grand knowledge which workers need during performing jobs and the coarse-grand knowledge for team communication. To fulfill such knowledge-needs, virtual knowledge flows are derived from a base knowledge flow and provide abstracted knowledge.
According to the task functions, the KFV model builds virtual KFs based on concealing criteria and abstracts base KNs in a base KF to generate corresponding virtual KNs through an order-preserving approach and a knowledge concept generalization mechanism. In addition, the r-KFV model analyzes the levels of knowledge required by workers based on their roles, and develops role-based knowledge flow abstraction methods that generate virtual knowledge nodes to provide the appropriate level of knowledge for each role.
The virtual knowledge flows not only fulfill workers’ different knowledge-needs but also facilitate knowledge support in teamwork. The concept of knowledge-flow view advances the conceptual applicability of knowledge flow research to cooperative knowledge support environments and helps researchers to obtain a clear view of
The virtual knowledge flows not only fulfill workers’ different knowledge-needs but also facilitate knowledge support in teamwork. The concept of knowledge-flow view advances the conceptual applicability of knowledge flow research to cooperative knowledge support environments and helps researchers to obtain a clear view of