Expert Systems with Applications 37(2010)1703-1712 Contents lists available at ScienceDirect Expert Systems with Applications ELSEVIER journalhomepagewww.elsevier.com/locate/eswa An inner-enterprise knowledge recommender system Lu Zhen,, George Q Huang, Zuhua Jiang Department of Industrial and System Engineering, National University of sin Department of Industrial and Manufacturing Systems Engineering. The University of Hong Kong, PR China Department of Industrial Engineering and Management, Shanghai Jiao Tong University, Shanghai, PR China ARTICLE IN FO A BSTRACT his paper proposes a model of the inner-enterprise knowledge recommender system. Among an orga- nowledge management nization, different members have different demands for knowledge in different context. Comparing with recommender system aditional knowledge query way, the knowledge recommender systems supply us a more that could deliver the proper knowledge to the proper people at the proper time. The recommendation mechanism is based on semantic matching on context information from both users 'side and knowledges side Recommendation rules are also maintained in the recommendation engine which is the core mod- ule in the system. By adjusting the rules, the configuration of the knowledge recommender system could be adapted to different users. This paper presents the system design as well as some key technologies analysis, and also discusses the advantages and preconditions for implementing the proposed system e 2009 Elsevier Ltd. All rights reserved. 1 Introduction With the knowledge recommender, it likes 'knowledge seeks people' rather thanpeople seek knowledge the former is a proac With the advent of the knowledge economy the core of enter- tive way for knowledge while the latter one is a reactive way. this prises is moving from being labor or capital intensive to being paper proposes a model of inner-enterprise knowledge recom- technology intensive, and currently is moving towards knowledge mender system, and it will illustrate: how the recommender sys- ufacturing, customers, previous success and failure; it can produce derives benefits for the knowledge workers Terprise, and how it intensive Within enterprises, knowledge is related to design, man- tem is designed and implemented for the en a long-term and sustained competitive predominance for enter The rest of paper is organized as follows. Some related work rises. So, the knowledge management( KM) became a critical done by other scholars are briefly introduced in the next section ssue for enterprises'management, and it has captured the In Section 3, we briefly describes the general architecture of the attention from both academics and industries(Rouse, 2002) knowledge recommender system. The following three sections One of the most essential aims for knowledge management is to are the introductions to the three key technologies for the knowl- promote knowledge sharing among organizations, which can help edge recommender system: the context model, rules base, and rec- ensure successful outcomes, learning from experience, knowledge ommendation engine are introduced in Sections 4-6, respectively ver architecture based knowledge repository mode is the simplest menting the proposed knowled ges and preconditions for imple- y for implementing knowledge sharing. All the knowledge re- mark and summary are then outlined in the last section sources are accumulated and stored in some centralized knowl- Ige servers: users could query and search knowledge for their 2 Related works tasks. However, knowledge searching is a very time consuming work for users. Sometimes, users have known the knowledge they 2.1. Knowledge management need is surely stored in the repository, but they are not willing to spend too much time and energy to search it. In addition, as to Knowledge is the major driving force for organizations' compet- some unsolved puzzle, or unknown tasks context, users often have itive capacities and wealth creation, and it is defined as a justified no idea about what knowledge they should to search So a more belief that increases an entity's capacity for effective action(Non- dvanced mode, knowledge recommender systems, should be aka, 1994). Knowledge may be viewed from several perspectives brought into enterprises'knowledge management platform. state of mind, resource object, process, or condition, or capability (Gold, Malhotra, Segars, 2001). This paper is based on the re- 4 Corres g author. Tel. +65 81712396 source view of knowledge. Knowledge management(KM) is the E-mailaddress:zhenlu@yahoo.cn(LZhen) systematic and organizationally specified process of creating 0957-4174/s- see front matter o 2009 Elsevier Ltd. All rights reserved. doi:10.1016/eswa2009.06.057
An inner-enterprise knowledge recommender system Lu Zhen a,*, George Q. Huang b , Zuhua Jiang c aDepartment of Industrial and System Engineering, National University of Singapore, Singapore bDepartment of Industrial and Manufacturing Systems Engineering, The University of Hong Kong, PR China cDepartment of Industrial Engineering and Management, Shanghai Jiao Tong University, Shanghai, PR China article info Keywords: Knowledge management Recommender system Context awareness abstract This paper proposes a model of the inner-enterprise knowledge recommender system. Among an organization, different members have different demands for knowledge in different context. Comparing with traditional knowledge query way, the knowledge recommender systems supply us a more proactive way that could deliver the proper knowledge to the proper people at the proper time. The recommendation mechanism is based on semantic matching on context information from both users’ side and knowledge’s side. Recommendation rules are also maintained in the recommendation engine, which is the core module in the system. By adjusting the rules, the configuration of the knowledge recommender system could be adapted to different users. This paper presents the system design as well as some key technologies analysis, and also discusses the advantages and preconditions for implementing the proposed system. 2009 Elsevier Ltd. All rights reserved. 1. Introduction With the advent of the knowledge economy, the core of enterprises is moving from being labor or capital intensive to being technology intensive, and currently is moving towards knowledge intensive. Within enterprises, knowledge is related to design, manufacturing, customers, previous success and failure; it can produce a long-term and sustained competitive predominance for enterprises. So, the knowledge management (KM) became a critical issue for enterprises’ management, and it has captured the attention from both academics and industries (Rouse, 2002). One of the most essential aims for knowledge management is to promote knowledge sharing among organizations, which can help ensure successful outcomes, learning from experience, knowledge reuse, and improving efficiency of knowledge workers. Client–Server architecture based knowledge repository mode is the simplest way for implementing knowledge sharing. All the knowledge resources are accumulated and stored in some centralized knowledge servers; users could query and search knowledge for their tasks. However, knowledge searching is a very time consuming work for users. Sometimes, users have known the knowledge they need is surely stored in the repository, but they are not willing to spend too much time and energy to search it. In addition, as to some unsolved puzzle, or unknown tasks context, users often have no idea about ‘what knowledge they should to search’. So a more advanced mode, knowledge recommender systems, should be brought into enterprises’ knowledge management platform. With the knowledge recommender, it likes ‘knowledge seeks people’ rather than ‘people seek knowledge’, the former is a proactive way for knowledge while the latter one is a reactive way. This paper proposes a model of inner-enterprise knowledge recommender system, and it will illustrate: how the recommender system is designed and implemented for the enterprise, and how it derives benefits for the knowledge workers. The rest of paper is organized as follows. Some related works done by other scholars are briefly introduced in the next section. In Section 3, we briefly describes the general architecture of the knowledge recommender system. The following three sections are the introductions to the three key technologies for the knowledge recommender system; the context model, rules base, and recommendation engine are introduced in Sections 4–6, respectively. Section 7 discusses the advantages and preconditions for implementing the proposed knowledge recommender model. Closing remark and summary are then outlined in the last section. 2. Related works 2.1. Knowledge management Knowledge is the major driving force for organizations’ competitive capacities and wealth creation, and it is defined as a justified belief that increases an entity’s capacity for effective action (Nonaka, 1994). Knowledge may be viewed from several perspectives: state of mind, resource object, process, or condition, or capability (Gold, Malhotra, & Segars, 2001). This paper is based on the ‘resource’ view of knowledge. Knowledge management (KM) is the systematic and organizationally specified process of creating, 0957-4174/$ - see front matter 2009 Elsevier Ltd. All rights reserved. doi:10.1016/j.eswa.2009.06.057 * Corresponding author. Tel.: +65 81712396. E-mail address: zhen_lu@yahoo.cn (L. Zhen). Expert Systems with Applications 37 (2010) 1703–1712 Contents lists available at ScienceDirect Expert Systems with Applications journal homepage: www.elsevier.com/locate/eswa
L Zhen et al. / Expert Systems with Applications 37(2010)1703-1712 organizing, sharing, and using knowledge so that employees can In order to make the recommender systems adapt to large scale se it to become more effective and productive in their work network environment, Han et al. suggested a distributed CF algo- (Artail, 2006). There are four domains in KM: knowledge creation, rithm by using dht technology to construct a scalable distributed storage/retrieval, transfer and application (Alavi Leidner, 2001). recommender system( Han, Xie, Yang, Shen, 2004). Olsson studied The theme of this paper, knowledge recommendation, belongs to how peer finds each other without centralized control, so as to pro- the third domain: knowledge transfer (Lin, Geng, whinstor pose a headline recommender system in P2P environment(olss 2005). It occurs at different levels: transfer of knowledge between 2003). A multi-dimensional CF method based on workflow space individuals, from individuals to groups, between groups, across was addressed in(Zhen, Huang, Jiang, 2009). As to the knowledge groups and etc. ( Ko, Kirsch, King, 2005 ) The knowledge transfer grid environment, a conceptual model of proactive knowledge re rocess could be embodied as the forms of knowledge flow or cog- ommendation was proposed in(Zhen Jiang, 2008a), and reactive nitive flow(Zhuge, 2003), which could promote a knowledge- knowledge query model for supporting innovation was proposed based perspective on members'cooperation and coordination in(Zhen Jiang, 2008b). A multi-dimensional CF method based on ( Kotlarsky, van Fenema, Willcocks, 2008). workflow space was addressed in(Zhen, Huang, Jiang, 2009). As Knowledge management system(KMS)is of great interest and to the privacy issue in P2P environment, Foner proposed a distrib- potential value to business managers as well as to the information uted matchmaking system focused on preserving privacy(Foner, system function( King, Marks, McCoy, 2002). KMS refers to a 2003 ). Canny also proposed a decentralized p2P information distri class of information systems applied to managing organization bution system for considering the privacy reason( Canny, 2002). knowledge. They are It based systems developed to support and most researches about the recommender systems enhance the organizational processes of knowledge creation, stor- mainly concerned the recommendation algorithms, or recom- age/retrieval, transfer, and application(Nevo Chan, 2007). The menders for general situations in daily lives(e.g. recommend domain of KMs attracts numerous researches not only in aca- movies, books, music, news and etc. ) but seldom cover the demic prototype system level but also in industrial applications recommendation scenarios for office worker in enterprise. This level(Lin, Yen, Tarn, 2007). The knowledge recommender is paper will mainly introduce the implementation of the one kind of KMS for knowledge sharing Internet/ Intranet technol- knowledge recommender system in a manufacturing enterprise ogies provide a strong basis and opportunity for knowledge shar- in China ing among people with similar interests(Li, Montazemi, Yuan, 2006. The knowledge recommender also needs to learn users'de- mands for knowledge from their colleagues with similar interests 3. The inner-enterprise knowledge recommender system (Zhen, Jiang, Song, Liu, Liang,, 2008). The knowledge recommen- dation is a more advanced way for users to acquire knowledge, it 3. 1. The knowledge resources involved in the enterprise will not need users to seek knowledge by themselves: sometimes sers may not know what they should seek clearly. Nowadays, Before the implementation of knowledge recommender system, Knowledge search/information search is expected to have annual knowledge based system should In growth rates of 17%(King Lekse, 2006). Knowledge seeking, stores various types of inner-enterprise knowledge. The knowledge knowledge acquisition are important sub processes of knowledge resources involved in that enterprise consist of seven categories of gement. Each deal with some phase of process utilized by knowledge: design cases, patents, technical standards, design for users when seeking out facts, advice, opinions or the expertise mulas, design rules, software for design or simulation, experts in order to make a decision. while, knowledge recommendation and etc. is a proactive way for knowledge acquisition. It is knowledge seeks people' rather than 'people seek knowledge'(Zhen Jiang. Design cases refer to the successful or failure cases in the prod- uct design process reused again in the 2.2. Recommender system resent c Those successful cases could be design tasks so as to avoid waste of time and resource the failure cases also could give some warning to the designers so as to avoid following the same The knowledge recommender, the theme of this paper, is old wrong road. related to the recommend technologies, which has become a Patents are the accumulation of human technological achieve- promising and hot area in both academia and industries. There ments. Some innovative principles and technique evolution exist various recommendation systems have been developed route are contained among them. So, with hint from those cor (Adomavicius Tuzhilin, 2005). Tapestry is one of the earliest rec relative patents, designers would broaden their idea for innova- ommendation systems(Goldberg, Nichols, Oki, Terry, 1992). tion in product development. Based on this work, several automated recommendation systems Technical standards mainly refer to various types of standards have been developed A recommendation system for news and mo- files established by some authorities or their own enterprises. vie recommendations was developed by Konstan et al. (1997). As Design formulas are main part of knowledge concerning in the to book recommendation, Mooney and Roy proposed a content roduct developing process. The formulas for calculating or based recommendation system (Mooney Roy, 2000). McNee pro- checking some parameters of parts are usually brought out from sed a recommendation system to help research paper citation experience or experiments: they are very useful in the jobs of McNee et al., 2000). For improving e-commerce sites sales, a tax ct development. nomy recommendation system is developed by Schafer, Konstan, Design rules are generated during the product development and Schafer, Konstan, and riedl (1999). Based on analyzing cus- processes, and they are the excerption of the experts'experi tomer behaviors(navigational patterns ) Yong proposed a CF-based ences, which are very useful for the newly joined team members recommendation system for e-commerce sites(Yong, Yum, Song, to know how to make the design tasks more efficient. Su, 2005 ) Yeong et al. proposed a new methodology in which Software is frequently used in the design process, it will help customer purchase sequences are used to improve the quality of lculate parameters or simulate the performance CF-based recommendations(Yeong. Yoon, &Soung, 2005). Base of designing product. The software could be packed as tele-se n demand modeling and information filtering technologies, an vice which will enable distributed users to evoke the software nformation supply model was proposed(zhen et al., 2008)
organizing, sharing, and using knowledge so that employees can use it to become more effective and productive in their work (Artail, 2006). There are four domains in KM: knowledge creation, storage/retrieval, transfer, and application (Alavi & Leidner, 2001). The theme of this paper, knowledge recommendation, belongs to the third domain: knowledge transfer (Lin, Geng, & Whinston, 2005). It occurs at different levels: transfer of knowledge between individuals, from individuals to groups, between groups, across groups and etc. (Ko, Kirsch, & King, 2005). The knowledge transfer process could be embodied as the forms of knowledge flow or cognitive flow (Zhuge, 2003), which could promote a knowledgebased perspective on members’ cooperation and coordination (Kotlarsky, van Fenema, & Willcocks, 2008). Knowledge management system (KMS) is of great interest and potential value to business managers as well as to the information system function (King, Marks, & McCoy, 2002). KMS refers to a class of information systems applied to managing organization knowledge. They are IT based systems developed to support and enhance the organizational processes of knowledge creation, storage/retrieval, transfer, and application (Nevo & Chan, 2007). The domain of KMS attracts numerous researches not only in academic prototype system level but also in industrial applications level (Lin, Yen, & Tarn, 2007). The knowledge recommender is one kind of KMS for knowledge sharing. Internet/Intranet technologies provide a strong basis and opportunity for knowledge sharing among people with similar interests (Li, Montazemi, & Yuan, 2006). The knowledge recommender also needs to learn users’ demands for knowledge from their colleagues with similar interests (Zhen, Jiang, Song, Liu, & Liang, 2008). The knowledge recommendation is a more advanced way for users to acquire knowledge, it will not need users to seek knowledge by themselves; sometimes users may not know what they should seek clearly. Nowadays, Knowledge search/information search is expected to have annual growth rates of 17% (King & Lekse, 2006). Knowledge seeking, knowledge acquisition are important sub processes of knowledge management. Each deal with some phase of process utilized by users when seeking out facts, advice, opinions or the expertise in order to make a decision. While, knowledge recommendation is a proactive way for knowledge acquisition. It is ‘knowledge seeks people’ rather than ‘people seek knowledge’ (Zhen & Jiang, 2008a). 2.2. Recommender system The knowledge recommender, the theme of this paper, is related to the recommend technologies, which has become a promising and hot area in both academia and industries. There exist various recommendation systems have been developed (Adomavicius & Tuzhilin, 2005). Tapestry is one of the earliest recommendation systems (Goldberg, Nichols, Oki, & Terry, 1992). Based on this work, several automated recommendation systems have been developed. A recommendation system for news and movie recommendations was developed by Konstan et al. (1997). As to book recommendation, Mooney and Roy proposed a contentbased recommendation system (Mooney & Roy, 2000). McNee proposed a recommendation system to help research paper citation (McNee et al., 2000). For improving e-commerce sites sales, a taxonomy recommendation system is developed by Schafer, Konstan, and Schafer, Konstan, and Riedl (1999). Based on analyzing customer behaviors (navigational patterns), Yong proposed a CF-based recommendation system for e-commerce sites (Yong, Yum, Song, & Su, 2005). Yeong et al. proposed a new methodology in which customer purchase sequences are used to improve the quality of CF-based recommendations (Yeong, Yoon, & Soung, 2005). Base on demand modeling and information filtering technologies, an information supply model was proposed (Zhen et al., 2008). In order to make the recommender systems adapt to large scale network environment, Han et al. suggested a distributed CF algorithm by using DHT technology to construct a scalable distributed recommender system (Han, Xie, Yang, & Shen, 2004). Olsson studied how peer finds each other without centralized control, so as to propose a headline recommender system in P2P environment (Olsson, 2003). A multi-dimensional CF method based on workflow space was addressed in (Zhen, Huang, & Jiang, 2009). As to the knowledge grid environment, a conceptual model of proactive knowledge recommendation was proposed in (Zhen & Jiang, 2008a), and reactive knowledge query model for supporting innovation was proposed in (Zhen & Jiang, 2008b). A multi-dimensional CF method based on workflow space was addressed in (Zhen, Huang, & Jiang, 2009). As to the privacy issue in P2P environment, Foner proposed a distributed matchmaking system focused on preserving privacy (Foner, 2003). Canny also proposed a decentralized P2P information distribution system for considering the privacy reason (Canny, 2002). In all, most researches about the recommender systems mainly concerned the recommendation algorithms, or recommenders for general situations in daily lives (e.g. recommend movies, books, music, news and etc.), but seldom cover the recommendation scenarios for office worker in enterprise. This paper will mainly introduce the implementation of the knowledge recommender system in a manufacturing enterprise in China. 3. The inner-enterprise knowledge recommender system 3.1. The knowledge resources involved in the enterprise Before the implementation of knowledge recommender system, knowledge based system should already exist in enterprise. It stores various types of inner-enterprise knowledge. The knowledge resources involved in that enterprise consist of seven categories of knowledge: design cases, patents, technical standards, design formulas, design rules, software for design or simulation, experts and etc. Design cases refer to the successful or failure cases in the product design process before. Those successful cases could be reused again in the present design tasks so as to avoid waste of time and resource, while the failure cases also could give some warning to the designers so as to avoid following the same old wrong road. Patents are the accumulation of human technological achievements. Some innovative principles and technique evolution route are contained among them. So, with hint from those correlative patents, designers would broaden their idea for innovation in product development. Technical standards mainly refer to various types of standards files established by some authorities or their own enterprises. Design formulas are main part of knowledge concerning in the product developing process. The formulas for calculating or checking some parameters of parts are usually brought out from experience or experiments; they are very useful in the jobs of product development. Design rules are generated during the product development processes, and they are the excerption of the experts’ experiences, which are very useful for the newly joined team members to know how to make the design tasks more efficient. Software is frequently used in the design process, it will help designers to calculate parameters or simulate the performance of designing product. The software could be packed as tele-service, which will enable distributed users to evoke the software in long-distance. 1704 L. Zhen et al. / Expert Systems with Applications 37 (2010) 1703–1712
L Zhen et al Expert Systems with Applications 37(2010)1703-1712 environments Other Applications User portal Context Awareness Mandgement Portal context. Context- User context Edit portal Context Edit portal Rules-Edit Authorized Knonledge- Portal Query Portal Rules miner Knowledge- 2 Rules for recommendation Knowledge Recommendation Engine s Knowledge Flow Knowledge Recommender System -ec.--..-- Information flow -- Control Flow Fig. 1. The architecture of the knowledge recommender system. Experts is also one kind of the knowledge sources, since some management of the enterprise wished that: by using the knowledge mplicit knowledge is just contained in experts brains and could recommender system, users could browse much more knowledgere- t be easily expressed in text or chart forms(Bradley, Paul, sources related to their work. moreover, the system should be flexi- Seeman, 2006). Therefore, as to some certain technical domain, ble, so that users could adjust the configuration of the system by some corresponding experts contact information is stored. adding, removing rules or changing some parameters of the rules Those contact information will be recommended to designers According to those considerations, we designed the knowledge and help them communicate with expert recommender system for supplying the proper knowledge to the proper person at the proper time. The systems architecture In fact, according to the utilization mode of knowledge services, shown in Fig. 1 above seven categories could be divided into three sorts: (1) The knowledge recommender syste nly consists of three browse knowledge (2)calculation knowledge, and(3)expert parts (1) Context model and elicitation: Context model and aware- ess is the basis for the intelligent recommender system design work in the case enterprise, patents, design cases. As to our system, it mainly concerns building context model technical standards, formulas, and design rules are main rom both user and knowledge sides; and context elicitation text-formatted knowledge: users just need to browse those from users'environments and other applications. As to this knowledge. So they could be the form of ordinary web pages part, the following Section 4 will give detail introduction. for users’ browse. (2)Rules for recommendation: It mainly concerns maintaining (2)Calculation knowledge: As to the engineering design work some rules for recommendation engine to utilize. Those in the case enterprise, software mainly refers to calculating rules consist of three sorts: main rules constraint rules parameters or simulation of designing products. Those Sol and newly-added rules. Moreover, they could be mined out knowledge resources could be packed as web services based rom the query log data by the means of data mining tech on tele-service technique. Users could invoke the knowledge logies. as to this part, the following Section 5 will give calculation services in long-distance (3)Expert knowledge: It mainly concerns the corresponding (3)Recommendation engine: It is the core module to execute experts'contact information (e.g. affiliation, Email, tele- the recommendation process that concerns searching correl- phone, URL link for video communication and etc. ) Those ative knowledge resources from repository and deliver to the contact information will be supplied to designers and help users who may need them. The engine will employ semantic them communicate with experts about the technical prob matching technologies to determining the correlative degree lems confronted in their design tasks between users' requirements and knowledges domain. As to this part, the following Section 6 will give detail introduction. 3. 2. The architecture of the system 4. Context model and elicitation The enterprise(ssB) wanted the knowledge recommender system could save a lot of time and energy for employees to seek knowledge. 4. 1. Context model rent tasks, scenarios and etc. ) automatically, and find some poten tial
Experts is also one kind of the knowledge sources, since some implicit knowledge is just contained in experts’ brains and could not be easily expressed in text or chart forms (Bradley, Paul, & Seeman, 2006). Therefore, as to some certain technical domain, some corresponding experts’ contact information is stored. Those contact information will be recommended to designers and help them communicate with experts. In fact, according to the utilization mode of knowledge services, above seven categories could be divided into three sorts: (1) browse knowledge, (2) calculation knowledge, and (3) expert knowledge. (1) Browse knowledge: as to the office work or engineering design work in the case enterprise, patents, design cases, technical standards, formulas, and design rules are mainly text-formatted knowledge; users just need to browse those knowledge. So they could be the form of ordinary web pages for users’ browse. (2) Calculation knowledge: As to the engineering design work in the case enterprise, software mainly refers to calculating parameters or simulation of designing products. Those sort knowledge resources could be packed as web services based on tele-service technique. Users could invoke the knowledge calculation services in long-distance. (3) Expert knowledge: It mainly concerns the corresponding experts’ contact information (e.g. affiliation, Email, telephone, URL link for video communication and etc.). Those contact information will be supplied to designers and help them communicate with experts about the technical problems confronted in their design tasks. 3.2. The architecture of the system The enterprise (SSB) wanted the knowledge recommender system could save a lot of time and energy for employees to seek knowledge. The system should have the abilities to capture users’ context (current tasks, scenarios and etc.) automatically, and find some potentially useful knowledge so as to recommend to users. The top management of the enterprise wished that: by using the knowledge recommender system, users could browse much more knowledge resources related to their work. Moreover, the system should be flexible, so that users could adjust the configuration of the system by adding, removing rules or changing some parameters of the rules. According to those considerations, we designed the knowledge recommender system for supplying the proper knowledge to the proper person at the proper time. The system’s architecture is shown in Fig. 1. The knowledge recommender system mainly consists of three parts: (1) Context model and elicitation: Context model and awareness is the basis for the intelligent recommender systems. As to our system, it mainly concerns building context model from both user and knowledge sides; and context elicitation from users’ environments and other applications. As to this part, the following Section 4 will give detail introduction. (2) Rules for recommendation: It mainly concerns maintaining some rules for recommendation engine to utilize. Those rules consist of three sorts: main rules, constraint rules, and newly-added rules. Moreover, they could be mined out from the query log data by the means of data mining technologies. As to this part, the following Section 5 will give detail introduction. (3) Recommendation engine: It is the core module to execute the recommendation process that concerns searching correlative knowledge resources from repository and deliver to the users who may need them. The engine will employ semantic matching technologies to determining the correlative degree between users’ requirements and knowledge’s domain. As to this part, the following Section 6 will give detail introduction. 4. Context model and elicitation 4.1. Context model Recently, many existing researches on context awareness either focus on user side (demand side) or on information resource side Fig. 1. The architecture of the knowledge recommender system. L. Zhen et al. / Expert Systems with Applications 37 (2010) 1703–1712 1705
1706 L Zhen et aL./Expert Systems with Applications 37(2010)1703-1712 (supplier side)alone. We argue that effective and efficient context by the way of tele-service. While, some other knowledge aware recommender systems need to consider from both sides. In resources need users go to the knowledge resources' location. contrast to others work related in context research, our approach In this situation, the location information of users and knowl- stands out from that: we formalize an ontology based context edge resources should be considered in recommendation. model considering both users' side and knowledge resources side. Devices: It reflects the user's current PCs capacities, e.g. CPU The ontology based context model including user context and speed, RAM, and etc. Some knowledge resource(e.g.some knowledge context is illustrated in Fig. 2. web-service based software) need be invoked by tele-g On the user side the users' context mainly includes the user's current PC should have enough capacities to run them. Profile: It describes user's basic information user ID, user name On the knowledge side, the knowledge resourcescontext and etc mainly includes: Roles: It describes the roles that the user is acting as, and the roles'requirements for knowledge. For example, as to the role Profile: It describes knowledge resources basic information, some CAD software belongs to the roles knowledge qualification of capabilities and skills, if there is some new. Domains: It is the main feature for describing domain character nowledge, or notices of training about some CAd software, they istics of knowledge resources. It is the important criteria to judg- will be recommended to the mechanical engineers. ing whether one certain knowledge is suitable for some user Background: It describes the users background in educ cation some skills, e.g. English level, computer level, and etc. It may. Types: Different knowledge types need different management need users qualified with some background knowledge or skills tools and invoke ways of knowledge services. to read, understand, or utilize some knowledge resources Location: It reflects knowledge resources'location. The same Interests: It describes the user's interests in knowledge or infor- as users location context, they all have ect effect to mation. Because this system is mainly utilized in enterprises recommendation offices, the interests are mainly oriented to knowledge or infor-. Prerequisite: The utilization of some knowledge may need mation requirements in engineering or operations domain users' background knowledge and skills be qualified or users Tasks: It describes the tasks that the user is taking on, and the PC devices have enough capacity to use the knowledge(e.g. soft air conditioner thermodynamic simulation, the thermody-. Evaluations: It keeps users' evaluations to knowledge, e.g. ' rela- namic simulation theories or tools for air conditioner are the tive but no need supplied again, relative and supplied again task requirements. So, some knowledge on that area will be sup- and irrelative. It could be utilized to judge: whether it plied to the members who are fulfilling that task. newknowledge for the user; as to the 'old'one, whether it is Time: It is the current date which could be gained from the sys- need to be recommended again tem time of the users PC. At some special time, there is some certain affair need the user to handle. It may imply some knowl- It should be mentioned that: as to above context features edge requirements to aid the user. In addition, based ontime related to knowledge requirements descriptions, e.g. 'Interest context, system could judge whether the user is performing taskin user context, and'domain' in knowledge context, we used some certain task, which is also related to some requirements to a set of tuples including keywords and its weight: for knowledge. ICi, W)IC E C, WE W; C is a set of pre-designed categories, and Location: It reflects the users current location(e.g. city, site of w is the set of weights for rating the categories. company, etc. ) There is no direct relationship between location The work for determining the keywords must based on a pre- and the requirements for knowledge, but it has indirect effect. designed ontology, which contains the categories of things that Some knowledge resources could be viewed online, or invoked may exist in the domain concerning the enterprise in the case Profile Roles Context Ontology Profile (Background Domains Interests Users Knowledge Ontology Untold Location Time Prerequisite Location Evaluations Devices Fig. 2. The ontology based context model
(supplier side) alone. We argue that effective and efficient contextaware recommender systems need to consider from both sides. In contrast to others’ work related in context research, our approach stands out from that: we formalize an ontology based context model considering both users’ side and knowledge resources side. The ontology based context model including user context and knowledge context is illustrated in Fig. 2. On the user side, the users’ context mainly includes: Profile: It describes user’s basic information, user ID, user name and etc. Roles: It describes the roles that the user is acting as, and the roles’ requirements for knowledge. For example, as to the role ‘mechanical engineer’, some CAD software belongs to the role’s qualification of capabilities and skills, if there is some new knowledge, or notices of training about some CAD software, they will be recommended to the mechanical engineers. Background: It describes the user’s background in education or some skills, e.g. English level, computer level, and etc. It may need users qualified with some background knowledge or skills to read, understand, or utilize some knowledge resources. Interests: It describes the user’s interests in knowledge or information. Because this system is mainly utilized in enterprises’ offices, the interests are mainly oriented to knowledge or information requirements in engineering or operations domain. Tasks: It describes the tasks that the user is taking on, and the tasks’ requirements for knowledge. For example, as to the task ‘air conditioner thermodynamic simulation’, the thermodynamic simulation theories or tools for air conditioner are the task requirements. So, some knowledge on that area will be supplied to the members who are fulfilling that task. Time: It is the current date which could be gained from the system time of the user’s PC. At some special time, there is some certain affair need the user to handle. It may imply some knowledge requirements to aid the user. In addition, based on ‘time’ context, system could judge whether the user is performing some certain task, which is also related to some requirements for knowledge. Location: It reflects the user’s current location (e.g. city, site of company, etc.). There is no direct relationship between location and the requirements for knowledge, but it has indirect effect. Some knowledge resources could be viewed online, or invoked by the way of tele-service. While, some other knowledge resources need users go to the knowledge resources’ location. In this situation, the location information of users and knowledge resources should be considered in recommendation. Devices: It reflects the user’s current PC’s capacities, e.g. CPU speed, RAM, and etc. Some knowledge resource (e.g. some web-service based software) need be invoked by tele-service; the user’s current PC should have enough capacities to run them. On the knowledge side, the knowledge resources’ context mainly includes: Profile: It describes knowledge resources’ basic information, knowledge ID, title, creator, owner, and etc. Domains: It is the main feature for describing domain characteristics of knowledge resources. It is the important criteria to judging whether one certain knowledge is suitable for some user’ demands. Types: Different knowledge types need different management tools and invoke ways of knowledge services. Location: It reflects knowledge resources’ location. The same as user’s location context, they all have indirect effect to recommendation. Prerequisite: The utilization of some knowledge may need users’ background knowledge and skills be qualified, or users’ PC devices have enough capacity to use the knowledge (e.g. software sorts of knowledge). Evaluations: It keeps users’ evaluations to knowledge, e.g. ‘relative but no need supplied again’, ‘relative and supplied again’, and ‘irrelative’. It could be utilized to judge: whether it is ‘new’ knowledge for the user; as to the ‘old’ one, whether it is need to be recommended again. It should be mentioned that: as to above context features related to knowledge requirements descriptions, e.g. ‘Interest’, ‘task’ in user context, and ‘domain’ in knowledge context, we used to a set of tuples including keywords and its weight: fhci; wiijci 2 C; wi 2 Wg; C is a set of pre-designed categories, and W is the set of weights for rating the categories. The work for determining the keywords must based on a predesigned ontology, which contains the categories of things that may exist in the domain concerning the enterprise in the case. Fig. 2. The ontology based context model. 1706 L. Zhen et al. / Expert Systems with Applications 37 (2010) 1703–1712
L Zhen et aL/ Expert Systems with Applications 37(2010)1703-1712 With the domain ontology as criterion, the knowledge resources but maybe still important tasks. The'tasks'contextual information and users'requirements will be marked with the same 'language of the user, which mainly refers to: what temporary tasks the user that is also machine-understandable. Otherwise, some mistake or is taking on currently, what the due time is, what the ongoing conflict(e.g.'gasoline'vs 'petrol,)may emerge due to users' differ- tasks'descriptions are (it reflects the tasks'requirements for ent habits for naming some knowledge. In all, context could be extracted through above two channels. 4.2 Context elicitation So, when the system detected the current time from the users PC environment, the tasks context about the user will be extracted Context elicitation is a process of deriving the values of context through above two processes. It should be mentioned that: tasks attributes. There are mainly three ways for context elicitation: context information reflects users'knowledge requirements about form-filling, context detection, and context extraction. their ongoing tasks, which is the major basis for following recom- mendation process. (1) Form-filling: In the form-filling way, contextual infor- users'input, e.g. user's profile, roles. 5. Rules for knowledge recommendation background, interest, location and etc. As to the contextual information of knowl 5.1. Rules in recommendation engine edge resources, they are mainly input by authorized users, e.g. knowledge engi The knowledge is recommended according to the rules, which is neers or the knowledge's creators, and set manually or mined from other sources. Those rules are im rant configuration control parameters to adjust the recommenders (2)Context detection: The goal of context detection is to collect performance and functions, e.g. how many knowledge resources or example, the 'time could be derive between knowledge and users requirements shot directly from the system time of users PC. The same with the'devices' contextual The rules could be divided into three sorts. nformation, it could also be captured directly from the system parameters of (1)Main rules: They are the initial criteria for recommendation users’PC. (3)Context extraction: The context extraction process may be the repository. Based on main rules, system will gain a pre more complex than above two, it could liminary list of knowledge. Main rules mostly concern the users' context information in 'tasks, 'interest, and information of the user, which is very (2)Constraint rules: There are constraints for some knowledge essential for the recommender system in resources' utilization. As to the users who are not qualified his case. The main target of this system to use the knowledge for some reasons (e.g. background is oriented to office environments the knowledge, or hardware capacity ) Those rules are mainly tasks' contextual information reflects a utilized to filter above preliminary list of knowledge. main demand of knowledge for office (3)Newly-added rules: They are added by authorized users workers. Our system will extract 'tasks (e.g. knowledge engineers), or mined out from uses'query contextual information from outside data. They act as the supplements for above main rules applications, e.g. project management system, and email system. The table 1 illustrate in the system N Some important and formal projects'schedule and information could not always coincide with users'requirements, there exists 2. 1. Context extraction from project management system It should be mentioned that: the recommended knowledge are maintained by some project management system. The enter- a correlative values' between users and knowledge As to the Sup- prise in this case is using the 'Microsoft Project Server'as the pro ply(Uinterest, 0.8)"in above rule(ri), the 0.8 is the 'correlative ject management software. Through the PDs( Project Data Service) values. It means to recommend the knowledge according the component, which is the API of 'Microsoft Project Server,our users' requirement descriptions ' U interest with the correlative values higher than 0.8. If the value is omitted in Supply(). it mea tem could capture the project data from the project managemen default value%, which denotes completely coincident. system. In fact, that captured information is the ' contextual information of the user, which mainly refers to: what tasks the user is taking on currently, what output the user should submit 5.2. Rules mining based on query log for the project, what the ongoing tasks' descriptions are(it reflects the tasks' requirements for knowledge). Our recommender system has a knowledge query users. The query histories data stored in query log DB co 4.2. 2 Context extraction from email system lized to m some recommendation rules by the mean Some informal or temporary tasks are triggered by email sys- mining technologies. In fact, those rules mined out from tem. For example, the leader assigned a temporary task to one data are the third sort of rule, ' newly added rules member trough the email system. Those tasks assignment emails Traditional rules mining(X= y) conforms to the general model are usually marked with'AR'(action required) so as to differ from of market analysis, where all items are assumed to belong to one other ordinary mails. Moreover, those AR emails structure is in item set of transaction data, e g. X CT and y ct. In our recor uniform format: assigner. assignees, due time, tasks description, mender system, rules mining involves two different item sets, that and attachment. Through the APl of the enterprise 's email system, is, XCU and Y cK, corresponding to user context domain(U) we could capture the context information as to those temporary and knowledge context domain(K"). respectively
With the domain ontology as criterion, the knowledge resources and users’ requirements will be marked with the same ‘language’ that is also machine-understandable. Otherwise, some mistake or conflict (e.g. ‘gasoline’ vs. ‘petrol’) may emerge due to users’ different habits for naming some knowledge. 4.2. Context elicitation Context elicitation is a process of deriving the values of context attributes. There are mainly three ways for context elicitation: form-filling, context detection, and context extraction. (1) Form-filling: In the form-filling way, contextual information is acquired directly from the users’ input, e.g., user’s profile, roles, background, interest, location and etc. As to the contextual information of knowledge resources, they are mainly input by authorized users, e.g. knowledge engineers or the knowledge’s creators, and etc. (2) Context detection: The goal of context detection is to collect users’ dynamic contextual information. For example, the ‘time’ could be derived directly from the system time of users’ PC. The same with the ‘devices’ contextual information, it could also be captured directly from the system parameters of users’ PC. (3) Context extraction: The context extraction process may be more complex than above two, it could be utilized to capture ‘tasks’ contextual information of the user, which is very essential for the recommender system in this case. The main target of this system is oriented to office environments. The ‘tasks’ contextual information reflects a main demand of knowledge for office workers. Our system will extract ‘tasks’ contextual information from outside applications, e.g. project management system, and email system. 4.2.1. Context extraction from project management system Some important and formal projects’ schedule and information are maintained by some project management system. The enterprise in this case is using the ‘Microsoft Project Server’ as the project management software. Through the PDS (Project Data Service) component, which is the API of ‘Microsoft Project Server’, our system could capture the project data from the project management system. In fact, that captured information is the ‘tasks’ contextual information of the user, which mainly refers to: what tasks the user is taking on currently, what output the user should submit for the project, what the ongoing tasks’ descriptions are (it reflects the tasks’ requirements for knowledge). 4.2.2. Context extraction from email system Some informal or temporary tasks are triggered by email system. For example, the leader assigned a temporary task to one member trough the email system. Those tasks assignment emails are usually marked with ‘AR’ (action required) so as to differ from other ordinary mails. Moreover, those AR emails’ structure is in uniform format: assigner, assignees, due time, tasks description, and attachment. Through the API of the enterprise’s email system, we could capture the context information as to those temporary but maybe still important tasks. The ‘tasks’ contextual information of the user, which mainly refers to: what temporary tasks the user is taking on currently, what the due time is, what the ongoing tasks’ descriptions are (it reflects the tasks’ requirements for knowledge). In all, context could be extracted through above two channels. So, when the system detected the current time from the user’s PC environment, the tasks’ context about the user will be extracted through above two processes. It should be mentioned that: tasks context information reflects users’ knowledge requirements about their ongoing tasks, which is the major basis for following recommendation process. 5. Rules for knowledge recommendation 5.1. Rules in recommendation engine The knowledge is recommended according to the rules, which is set manually or mined from other sources. Those rules are important configuration control parameters to adjust the recommender’s performance and functions, e.g. how many knowledge resources should be recommended, how much threshold value for similarity between knowledge and user’s requirements should be proper, and etc. The rules could be divided into three sorts: (1) Main rules: They are the initial criteria for recommendation engine to search for correlative knowledge resources from the repository. Based on main rules, system will gain a preliminary list of knowledge. Main rules mostly concern the users’ context information in ‘tasks’, ‘interest’, and etc. (2) Constraint rules: There are constraints for some knowledge resources’ utilization. As to the users who are not qualified to use the knowledge for some reasons (e.g. background knowledge, or hardware capacity). Those rules are mainly utilized to filter above preliminary list of knowledge. (3) Newly-added rules: They are added by authorized users (e.g. knowledge engineers), or mined out from uses’ query log data. They act as the supplements for above main rules or constraint rules. The Table 1 illustrates some example of recommendation rules in the system. It should be mentioned that: the recommended knowledge could not always coincide with users’ requirements, there exists a ‘correlative values’ between users and knowledge. As to the ‘Supply(U.interest, 0.8)’ in above rule (R1), the ‘0.8’ is the ‘correlative values’. It means to recommend the knowledge according the users’ requirement descriptions ‘U.interest’ with the ‘correlative values’ higher than 0.8. If the value is omitted in Supply(), it means default value ‘100%’, which denotes completely coincident. 5.2. Rules mining based on query log Our recommender system has a knowledge query portal for users. The query histories data stored in query log DB could be utilized to mining some recommendation rules by the means of data mining technologies. In fact, those rules mined out from query log data are the third sort of rule, ‘newly added rules’. Traditional rules mining ðX ) YÞ conforms to the general model of market analysis, where all items are assumed to belong to one item set of transaction data, e.g. X # T and Y # T. In our recommender system, rules mining involves two different item sets, that is, X # U and Y # K , corresponding to user context domain ðU Þ and knowledge context domain ðK Þ, respectively. L. Zhen et al. / Expert Systems with Applications 37 (2010) 1703–1712 1707