Patterns for modelling expert knowledge

There are different ways to model or structure the expert knowledge in a technology-based system. Some of the approaches are actually quite complicated and theoretical. At least they seem that way to me.

The approach I take to knowledge engineering is what I believe to be quite a simple approach. In my view, knowledge engineering for an expert system that actually “ships” as opposed to spending its life in a research or development state, is already hard enough without adding complex structure to the knowledge base. That’s one of the reasons why I prefer a very simple, rule-by-rule approach.

Even simple rules will form a general pattern or approach in the logic tree can become detailed and quite sophisticated as a whole.

High level pattern

Let’s start with a high level description of a common pattern I use:

  1. Diagnose the problem
  2. Give information about the problem
  3. Narrow the problem (deeper diagnosis)
  4. Give more information about that narrowed problem
  5. Repeat #3 and #4 as required
  6. Optional: provide self-help guidance or tools
  7. Optional: provide more than one option for an outcome, whether it’s a conclusion or guidance
  8. End the process

In more natural language, this approach moves from general to specific. Each branch of the logic tree leads to the most specific conclusion or outcome possible, to the degree or granularity that knowledge engineers are able to create.

Here’s an alternative way to look at this pattern:

  1. Identify the problem the expert system has to solve or the question it has to answer
  2. Apply factual knowledge from the domain (that’s available to everyone, even if they haven’t looked it up) and heuristic knowledge (judgement of experts in the domain) to the problem or question
  3. End the process

Reuse and Recycle

Knowledge engineers may notice a particular pattern or set of outcomes crystallizing within the domain. They may see similar things happening again and again. This is a sign that the pattern may work across the domain.

Don’t force it

The goal of knowledge engineering is to capture and formalize or structure knowledge from domain experts and deliver it to non-experts through an expert system. The domain, subject matter experts and users all come first. Knowledge engineers may find it difficult to take a pre-set pattern and force the domain into it.*

In other words, a pattern shouldn’t take precedent over the domain or what users need from your expert system.


*I’m working on ways to make this happen. It could make knowledge engineering much faster, simpler and more predictable.

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑