Knowledge Engineering Stopped Trying to Copy the Expert

The phrase knowledge acquisition made early expert-system work sound like collection. An expert possessed knowledge; a knowledge engineer obtained it; a program then used it. The working projects were more difficult. Experts sometimes disagreed, skipped steps they took for granted, or described a practice that looked different when observed. A formal rule also required the engineer to decide what counted as a condition, an exception, or a conclusion.

By the 1990s, researchers described an important change in the field: from a transfer view of knowledge engineering to a modeling view. Rudi Studer, V. Richard Benjamins, and Dieter Fensel set out this transition in their 1998 account of the discipline’s principles and methods. The aim was to construct a useful model of a domain and its tasks, not to imagine a person’s understanding could be copied intact into a machine. (Studer, Benjamins, and Fensel, 1998)

A model is built for a purpose

Consider the question “Can this component be reused on this project?” A specialist may consider the component’s version, prior use, inspection history, the proposed application, applicable standards, and exceptions. The system needs some representation of those things and their relationships if it is to help. But it does not need a complete theory of engineering. It needs enough structure to support this decision, with a route to the evidence and a way to recognize cases outside its scope.

Every part of that model is a choice. Two versions might be grouped when their differences do not affect this task and separated when they do. A standard may be attached to a component class, a particular use, a jurisdiction, or a time period. A test report may be treated as evidence of performance, not as blanket permission for reuse. If the system collapses any of these distinctions, it may answer the wrong question with great consistency.

The expert contributes indispensable judgment about the field. The engineer contributes decisions about representation and computation. The project owner contributes a task, institutional context, and an account of acceptable failure. There is no neutral pipe through which the expert’s knowledge flows. The resulting model reflects these choices and has to be tested against cases they did not anticipate.

Testing changes the model

A model can pass structural checks and still be wrong about the work. A record may include every required field while using an obsolete definition. Two concepts may be linked in a technically valid way that a practitioner would reject. Testing therefore needs real cases, including near misses and exceptions, and the people qualified to interpret them.

When a test fails, the failure should lead to a specific question. Did the system retrieve the wrong evidence? Did it apply a current rule to an old version? Did the model merge two things the organization must keep separate? Was the question itself poorly framed? A model that can be revised in response to those answers becomes a maintained representation, not a monument to the first workshop.

This change in thinking did not make knowledge engineering less technical. It made its technical work more honest. The engineer could define concepts, relationships, constraints, and reasoning steps while acknowledging that the model covered a task rather than the whole of human expertise.

The next development followed naturally. If knowledge engineering is the construction of models, a team should examine the organization and task before writing rules. It should also ask which parts of a model could be reused by another application. Methods such as CommonKADS were built to make that wider investigation explicit.