This post is part of my attempt to create a start to finish* or end-to-end knowledge engineering process description for (legal) expert systems.
Problem identification is a great place to start.
Problem Identification
There’s no real methodology involved with identifying a problem. Problems just happen.
The knowledge engineer’s job is to examine the problem and ask 3 key questions:
- Is this a problem for non-experts that wouldn’t be a problem for experts?
- Is there a relatively uniform knowledge domain here?
- Would expert reasoning or guidance help non-expert users with the problem?
First, an expert system isn’t the right tool for every problem. It helps to put expert knowledge and guidance in the hands of non-expert users. So if the problem is affecting the world’s top experts in a domain, an expert system may not help. If, on the other hand, experts don’t suffer from the same problem as non-experts, an expert system might be an effective response to the problem.
Second, knowledge engineers need to tap into expert knowledge. Experts usually have heightened levels of knowledge and expertise in a given domain. Polymaths aside, expertise will be specialized, at least in contrast with things outside the expert’s domain. In addition, the knowledge engineer will be looking to extract recognizable and repeatable patterns of reasoning within a relatively uniform domain. The knowledge base will have boundaries to it. So too must the domain.
Third, the problem has to be one that can be eliminated or mitigated for non-experts if they receive expert reasoning and guidance. An expert system can become a tool for disintermediation if it removes the middle-man standing between the expert knowledge and the non-expert who needs it but can’t access it because of resource problems such as a lack of experts or a lack of resources to pay for experts. But if users would be better off with access to this knowledge or expertise, an expert system could be an appropriate tool.
Positive answers to these 3 questions won’t guarantee success. But they will get a knowledge engineer off to a good start.
This post will become part of the Knowledge Engineering Start to Finish page here.
*According to this methodology, the knowledge engineering process never really finishes or ends.