Representing Domain-Specific Knowledge

An expert system is only as good as how well its domain-specific knowledge is represented — this lesson looks at how the general KR approaches from Unit 2 are specialised for building a real expert system.

Domain Knowledge vs General Knowledge

Representing Domain Knowledge as Production Rules

The most common representation in classic expert systems is the IF–THEN rule, because it maps naturally onto how human experts describe their own reasoning.

RULE 17:
IF   the patient has fever
AND  the patient has a rash
AND  the patient has recently travelled to an endemic region
THEN conclude (with certainty factor 0.7) that the diagnosis is dengue

The Knowledge Acquisition Process

This process is famously slow — called the "knowledge acquisition bottleneck" — because human experts often cannot fully articulate the heuristics they use unconsciously, and a knowledge engineer must repeatedly probe, encode, and test rules against real cases.

Beyond Simple Rules: Structured Domain Knowledge

Large expert systems often combine rules with frames (Unit 2) to represent structured domain objects:

Frame: Patient-Case
  slot: symptoms        value: [fever, rash]
  slot: travel-history   value: endemic-region
  slot: diagnosis         value: (to be inferred by rules)

Rules then reason over the slots of such frames, combining the compactness of frame-based structuring with the modularity of rule-based reasoning.

Handling Uncertainty in Domain Knowledge

Real domain experts are rarely 100% certain. Representations must therefore support degrees of belief:

Exam tip: be ready to write a sample IF–THEN rule for a given domain (medical, financial, agricultural) — examiners frequently ask you to construct a rule, not just define what one is.