Knowledge Management vs Knowledge Engineering
The terms knowledge management and knowledge engineering seem to be used as interchangeably as the terms data and information used to be. But if you were to ask either a manager or an engineer if their jobs were the same, I doubt if you would get them to agree they were. A brief examination of the terms management and engineering shows that to manage is to exercise executive, administrative and supervisory direction, where as, to engineer is to lay out, construct, or contrive or plan out, usually with more or less subtle skill and craft.
The main difference seems to be that the (knowledge) manager establishes the direction the process should take, where as the (knowledge) engineer develops the means to accomplish that direction. Not all that much different from the relationships in any other discipline. So therefor we should find the knowledge managers concerned with the knowledge needs of the enterprise. We should see them doing the research to understand what knowledge is needed to make what decision and enable what actions. They should be taking a key role in the design of the enterprise and from the needs of the enterprise establishing the enterprise level knowledge management policies. It is to the knowledge managers that the user should go with their “need to know“.
On the other hand, if we were look in on the knowledge engineers we should find them working on such areas as data and information representation and encoding methodologies, data repositories, work flow management, groupware technologies, etc,. The knowledge engineers would most likely be researching the technologies needed to meet the enterprise’s knowledge management needs. The knowledge engineers should also be establishing the processes by which knowledge requests are examined, information assembled, and knowledge returned to the requestor. What is significant in both of these “job descriptions” is that nowhere do I claim that either is the “owner” of the enterprise knowledge, information, or data. Ownership remains the prerogative of the enterprise, or the enterprise element manager, or even the individual depending on the established policies for enterprise level knowledge ownership. As we might well expect, other views exist as to the roles of the knowledge manager and the knowledge engineer. For example, to the developer of knowledge-base computer software systems, the knowledge engineer is most likely a computer scientist specializing the development of artificial intelligence knowledge bases. From the view of the corporate board-room the knowledge manager may be the Chief Information Officer (CIO) or the person in charge of the Information Resource Management (IRM). The point is, when discussing terms such as knowledge manager or knowledge engineer, or any other role designation, it is important that all parties share a clear mutual understanding. Brian D. Newman © January 5, 1996
Multi-Perspective Modeling for Knowledge Management and Knowledge Engineering (John Kingston) Multi-Perspective Modeling
The purpose of this thesis is to show how an analytical framework originally intended for information systems architecture can be used to support knowledge management, knowledge engineering and the closely related discipline of ontology engineering. The framework suggests analysing information or knowledge from six perspectives (Who,What, How, When, Where and Why) at up to six levels of detail (ranging from “scoping” the problem to an implemented solution). The application of this framework to each of CommonKADS’ models is discussed, in the context of several practical applications of the CommonKADS methodology. Strengths and weaknesses in the models that are highlighted by the practical applications are analysed using the framework,
with the overall goal of showing where CommonKADS is currently useful and where it could be usefully extended. The same framework is also applied to knowledge management; it is established that “knowledge management” is in fact a wide collection of different approaches and techniques, and the framework can support and extend every approach to some extent, as well as the decision which approach is best for a particular case. Specific applications of using the framework to model medical knowledge and to resolve common problems in ontology development are presented.
The thesis also includes research on mapping knowledge acquisition techniques to CommonKADS’ models (and to the framework); proposing some extensions to CommonKADS’ library of generic inference structures; and it concludes with a suggestion for a “pragmatic” KADS for use on small projects. The aim is to show that this framework both characterises the knowledge required for both knowledge management and knowledge engineering, and can provide a guide to good selection of knowledge management techniques. If the chosen technique should involve knowledge engineering, the wealth of practical advice on CommonKADS in this thesis should also be beneficial.
ANOVA 