This book came from a need to establish a way to capture knowledge that can be easily translated into a computer program. To do this I wanted to establish a methodology or framework that would assist me. This framework must be a reusable method for getting this done. However, what should this framework contain? The first thing I wanted to be able to figure out was if the domain I was analyzing was suitable for development into an expert system.
I ascertained that there had to be concrete steps one can take to determine this. In 1991, I wrote an article called “Evaluating Potential Expert System Applications.” In this article I examined information from several articles taken from the AI Magazine, where I came across the “Checklist Approach.” This approach examined key areas of a system under discussion (i.e., task, payoff, customer management, system designer, domain expert, and user). I was intrigued by this approach, and I thought it was solid enough to adopt; therefore, this became my first step within the framework.
The next step and subsequent steps within the framework centered on building an expert system and how best to do this. In an expert system, the value of the system is related directly to the quality of knowledge that is discovered and constructed in its knowledge base. Therefore, once the domain was determined, I had to understand what the knowledge of the domain was and what types of knowledge were contained in the domain. This thinking led me to discover that the knowledge of a particular domain could be vast and that I must decompose this knowledge into smaller subtasks to understand it and understand it in a way that software could be developed for a computer program to interpret it. So, the next step became to “Decompose the Knowledge.”
Whether this knowledge was tacit or explicit or wherever in the organization it came from, I knew at this point that it was all about the knowledge. I wanted to peel back the covers and really understand the aspects of the knowledge that would be discovered. These aspects included determining any interdependencies, recognizing any knowledge patterns, determining if the knowledge contained any judgmental aspects or “fuzziness,” determining if there are any conflicts between experts when discussing similar aspects of the same domain and resolving them, and finally constructing the knowledge base.
Over the next several years I started to apply these techniques in my consulting practice developing expert (knowledge-based) systems. In doing so, the framework started to evolve and some best practices came to the forefront. In 1997, this led me to write an article titled “Capturing and Managing Intellectual Capital.” In this article, building knowledge architecture and understanding the knowledge acquisition tasks were examined more closely.