Ch. 6 of the CommonKADS textbook

1. Template knowledge models
Reusing knowledge model elements

2. Template knowledge models 2
Lessons
■ Knowledge models partially reused in new
applications
■ Type of task = main guide for reuse
■ Catalog of task templates
➤ small set in this book
➤ see also other repositories

3. Template knowledge models 3
The need for reuse
■ prevent "re-inventing the wheel"
■ cost/time efficient
■ decreases complexity
■ quality-assurance

4. Template knowledge models 4
Task template
■ reusable combination of model elements
➤ (provisional) inference structure
➤ typical control structure
➤ typical domain schema from task point-of-view
■ specific for a task type
■ supports top-down knowledge modeling

5. Template knowledge models 5
A typology of tasks
■ range of task types is limited
➤ advantage of KE compared to general SE
■ background: cognitive science/psychology
■ several task typologies have been proposed in the
literature
■ typology is based on the notion of “system”

6. Template knowledge models 6
The term “system”
■ abstract term for object to which a task is applied.
■ in technical diagnosis: artifact or device being
diagnosed
■ in elevator configuration: elevator to be designed
■ does not need to exist (yet)

7. Template knowledge models 7
Analytic versus synthetic tasks
■ analytic tasks
➤ system pre-exists
– it is typically not completely "known"
➤ input: some data about the system,
➤ output: some characterization of the system
■ synthetic tasks
➤ system does not yet exist
➤ input: requirements about system to be constructed
➤ output: constructed system description

8. Template knowledge models 8
Task hierarchy
knowledge-­‐
intens ive
tas k
analytic
tas k
clas s ification
s ynthetic
tas k
as s es s ment
diagnos is
configuration
des ign
planning
s cheduling
as s ignment
modelling
prediction
monitoring
des ign

9. Template knowledge models 9
Structure of template
description in catalog
■ General characterization
➤ typical features of a task
■ Default method
➤ roles, sub-functions, control structure, inference structure
■ Typical variations
➤ frequently occurring refinements/changes
■ Typical domain-knowledge schema
➤ assumptions about underlying domain-knowledge structure

10. Template knowledge models 10
Classification
■ establish correct class for an object
■ object should be available for inspection
➤ "natural" objects
■ examples: rock classification, apple classification
■ terminology: object, class, attribute, feature
■ one of the simplest analytic tasks; many methods
■ other analytic tasks: sometimes reduced to
classification problem especially diagnosis

11. Template knowledge models 11
Classification:
pruning method
■ generate all classes to which the object may belong
■ specify an object attribute
■ obtain the value of the attribute
■ remove all classes that are inconsistent with this
value

12. Template knowledge models 12
Classification:
inference structure
object
class
attribute
feature
truth
value
generate
specify
match
obtain

13. Template knowledge models 13
Classification:
method control
while new-solution generate(object -> candidate) do
candidate-classes := candidate union candidate-classes;
while new-solution specify(candidate-classes -> attribute)
and length candidate-classes > 1 do
obtain(attribute -> new-feature);
current-feature-set := new-feature union current-feature-set;
for-each candidate in candidate-classes do
match(candidate + current-feature-set -> truth-value);
if truth-value = false;
then candidate-classes := candidate-classes subtract candidate;

14. Template knowledge models 14
Classification:
method variations
■ Limited candidate generation
■ Different forms of attribute selection
➤ decision tree
➤ information theory
➤ user control
■ Hierarchical search through class structure

15. Template knowledge models 15
Classification:
domain schema
object
type
attribute
value:
universal
object
clas s
clas s
cons traint
requires
has-­‐attribute
class-­‐of
2+ 1+

16. Template knowledge models 16
Rock classification
volcanic
rock
igneous
rock
plutonic
rock
s yenite diorite
peridotite dunite
mineral
rock
texture
grainsize
colour
mineral
content
percentage
presence
1+
mineral
content
cons traint
s ilicate
nes o
s ilicate
tecto
s ilicate
olivine quartz
minerals
ontology

17. Template knowledge models 17
Nested classification
rock
rock
classifcation
minerals
obtain:
Quartz
percentage
mineral
classification
Quartz olivine
sub-­‐task
identify
Quartz
contains

18. Template knowledge models 18
Rock classification prototype

19. Template knowledge models 19
Assessment
■ find decision category for a case based on domain-
specific norms.
■ typical domains: financial applications (loan
application), community service
■ terminology: case, decision, norms
■ some similarities with monitoring
➤ differences:
– timing: assessment is more static
– different output: decision versus discrepancy

20. Template knowledge models 20
Assessment:
abstract & match method
■ Abstract the case data
■ Specify the norms applicable to the case
➤ e.g. “rent-fits-income”, “correct-household-size”
■ Select a single norm
■ Compute a truth value for the norm with respect to
the case
■ See whether this leads to a decision
■ Repeat norm selection and evaluation until a decision
is reached

21. Template knowledge models 21
Assessment:
inference structure
case
abstracted
case norms
norm
valuedecision
abstract
select
match
specify
evaluate norm

22. Template knowledge models 22
Assessment:
method control
while new-solution abstract(case-description -> abstracted-case)
do
case-description := abstracted-case;
end while
specify(abstracted-case -> norms);
repeat
select(norms -> norm);
evaluate(abstracted-case + norm -> norm-value);
evaluation-results := norm-value union evaluation-results;
until has-solution match(evaluation-results -> decision);

23. Template knowledge models 23
Assessment control:
UML notation
abstract
specify
norms
select
norm
match
decision
evaluate
norm
[more abstractions]
[no more
abstractions] [match fails
no decision]
[match succeeds:
decision found]

24. Template knowledge models 24
Assessment:
method variations
■ norms might be case-specific
➤ cf. housing application
■ case abstraction may not be needed
■ knowledge-intensive norm selection
➤ random, heuristic, statistical
➤ can be key to efficiency
➤ sometimes dictated by human expertise
– only acceptable if done in a way understandable to experts

25. Template knowledge models 25
Assessment:
domain schema
cas e
cas e
datum
cas e
datum
value:
universal
decis ionnorm
truth-­‐value:
boolean
indicates
has
abstraction
implies
decis ion
rule
requirement
abs traction
rule
1+
1+
1+

26. Template knowledge models 26
Claim handling for
unemployment benefits
:claim
collect
data
data
entry
decide
about
claim
compute
benefit
send
notification prepare
payment
[no
right]
[right]
c laim
handling finac ial
department

27. Template knowledge models 27
Decision rules for
claim handling
<norm>
WW
benefit
requirement
<decision>
WW
benefit
right
<decision
rule>
benefit
decision
rule
DE FINE S
insured
=
false
DE F INE S
W W -­‐benefit-­‐right.value
=
no-­‐right
iunemployed
=
false
DE F INE S
W W -­‐benefit-­‐right.value
=
no-­‐right
weeks-­‐worked-­‐requirement
=
false
DE F INE S
W W -­‐benefit-­‐right.value
=
no-­‐right
insured
=
true
AND
unemployed
=
true
AND
weeks-­‐worked-­‐-­‐requirement
=
true
AND
years-­‐worked-­‐requirement
=
false
DE F INE S
W W -­‐benefit-­‐right.value
=
short-­‐benefit
insured
=
true
AND
unemployed
=
true
AND
weeks-­‐worked-­‐-­‐requirement
=
true
AND
years-­‐worked-­‐requirement
=
true
DE F INE S
W W -­‐benefit-­‐right.value
=
long-­‐benefit

28. Template knowledge models 28
Diagnosis
■ find fault that causes system to malfunction
➤ example: diagnosis of a copier
■ terminology:
➤ complaint/symptom, hypothesis, differential, finding(s)/evidence,
fault
■ nature of fault varies
➤ state, chain, component
■ should have some model of system behavior
➤ default method: simple causal model
■ sometimes reduced to classification task
➤ direct associations between symptoms and faults
■ automation feasible in technical domains

29. Template knowledge models 29
Diagnosis:
causal covering method
■ Find candidate causes (hypotheses) for the complaint
using a causal network
■ Select a hypothesis
■ Specify an observable for this hypothesis and obtain
its value
■ Verify each hypothesis to see whether it is consistent
with the new finding
■ Continue this process until a single hypothesis is left
or no more observables are available

30. Template knowledge models 30
Diagnosis:
inference structure
complaint
cover
specify
select obtain
hypothesis
observable
finding
hypothesis
verify
result

31. Template knowledge models 31
Diagnosis:
method control
while new-solution cover(complaint -> hypothesis) do
differential := hypothesis add differential;
end while
repeat
select(differential -> hypothesis);
specify(hypothesis -> observable);
obtain(observable -> finding);
evidence := finding add evidence;
foreach hypothesis in differential do
verify(hypothesis + evidence -> result);
if result = false then differential := differential subtract hypothesis
until length differential =< 1 or “no observables left”
faults := hypothesis;

32. Template knowledge models 32
Diagnosis:
method variations
■ inclusion of abstractions
■ simulation methods
■ see literature on model-based diagnosis
➤ library of Benjamins

33. Template knowledge models 33
Diagnosis:
domain schema
system
feature
system
observable
value:
universal
system
state
status:
universal
fault
prevalence:
number[0..1]
system
state
system
feature
can
cause
causal
dependency

34. Template knowledge models 34
Monitoring
■ analyze ongoing process to find out whether it behaves
according to expectations
■ terminology:
➤ parameter, norm, discrepancy, historical data
■ main features:
➤ dynamic nature of the system
➤ cyclic task execution
■ output "just" discrepancy => no explanation
■ often: coupling monitoring and diagnosis
➤ output monitoring is input diagnosis

35. Template knowledge models 35
Monitoring:
data-driven method
■ Starts when new findings are received
■ For a find a parameter and a norm value is specified
■ Comparison of the find with the norm generates a
difference description
■ This difference is classified as a discrepancy using
data from previous monitoring cycles

36. Template knowledge models 36
Monitoring:
inference structure
new
finding
select
system
model
specifycompare
classify
parameter
difference
norm
discrepancy
historical
data
receive

37. Template knowledge models 37
Monitoring:
method control
receive(new-finding);
select(new-finding -> parameter)
specify(parameter -> norm);
compare(norm + finding -> difference);
classify(difference + historical-data -> discrepancy);
historical-data := finding add historical-data;

38. Template knowledge models 38
Monitoring:
method variations
■ model-driven monitoring
➤ system has the initiative
➤ typically executed at regular points in time
➤ example: software project management
■ classification function treated as task in its won right
➤ apply classification method
■ add data abstraction inference

39. Template knowledge models 39
Prediction
■ analytic task with some synthetic features
■ analyses current system behavior to construct
description of a system state at future point in time.
■ example: weather forecasting
■ often sub-task in diagnosis
■ also found in knowledge-intensive modules of
teaching systems e.g. for physics.
■ inverse: retrodiction: big-bang theory

40. Template knowledge models 40
Synthesis
■ Given a set of requirements, construct a system
description that fulfills these requirements
"P 166
processor
requires
16Mb"
"prefer
cheapest
component"
preference
cons traint
"price
lower
than
$2,000"
"fast
system"
hard
requirement
s oft
requirement
requirements
(external)
cons traints
&
preferences
(internal)

41. Template knowledge models 41
“Ideal” synthesis method
■ Operationalize requirements
➤ preferences and constraints
■ Generate all possible system structures
■ Select sub-set of valid system structures
➤ obey constraints
■ Order valid system structures
➤ based on preferences

42. Template knowledge models 42
Synthesis:
inference structure
requirements
hard
requirements
soft
requirements
possible
system
structures
list
of
preferred
system
structures
valid
system
structures
constraints
preferences
preference
ordering
knowledge
system
composition
knowledge
operationalize
generate
select
subset
sort

43. Template knowledge models 43
Design
■ synthetic task
■ system to be constructed is physical artifact
■ example: design of a car
■ can include creative design of components
■ creative design is too hard a nut to crack for current
knowledge technology
■ sub-type of design which excludes creative design =>
configuration design

44. Template knowledge models 44
Configuration design
■ given predefined components, find assembly that
satisfies requirements + obeys constraints
■ example: configuration of an elevator; or PC
■ terminology: component, parameter, constraint, preference,
requirement (hard & soft)
■ form of design that is well suited for automation
■ computationally demanding

45. Template knowledge models 45
Elevator configuration:
knowledge base reuse

46. Template knowledge models 46
Configuration:
propose & revise method
■ Simple basic loop:
➤ Propose a design extension
➤ Verify the new design,
➤ If verification fails, revise the design
■ Specific domain-knowledge requirements
➤ revise strategies
■ Method can also be used for other synthetic tasks
➤ assignment with backtracking
➤ skeletal planning

47. Template knowledge models 47
Configuration:
method decomposition
requirements
soft
requirements
hard
requirements
skeletal
design
design
extension
violation
truth
value
action
action
list
operationalize
critique
modify
verify
specify
propose
select

48. Template knowledge models 48
Configuration:
method control
operationalize(requirements -> hard-reqs + soft-reqs);
specify(requirements -> skeletal-design);
while new-solution propose(skeletal-design + design +soft-reqs -
> extension) do
design := extension union design;
verify(design + hard-reqs -> truth-value + violation);
if truth-value = false then
critique(violation + design -> action-list);
repeat select(action-list -> action);
modify(design + action -> design);
verify(design + hard-reqs -> truth-value + violation);
until truth-value = true;
end while

49. Template knowledge models 49
Configuration:
method variations
■ Perform verification plus revision only when for all
design elements a value has been proposed.
➤ can have a large impact on the competence of the method
■ Avoid the use of fix knowledge
➤ Fixes are search heuristics to navigate the potentially
extensive space of alternative designs
➤ alternative: chronological backtracking

50. Template knowledge models 50
Configuration:
domain schema
design
element
parameter
value:
universal
component
model
list:
list
fix
action
action
type
constraint
design
element
component
calculation
expression
constraint
expression
computes
implies
1+
1+
1+
1+ fix
has-­‐parameter
0+
defines
preference
preference
rating:
universal
preference
expression
1+

51. Template knowledge models 51
Types of configuration may
require different methods
■ Parametric design
➤ Assembly is largely fixed
➤ Emphasis on finding parameter values that obey global
constraints and adhere to preferences
➤ Example: elevator design
■ Layout
➤ Component parameters are fixed
➤ Emphasis on constructing assembly (topological relations)
➤ Example: mould configuration
■ Literature: Motta (1999), Chandrasekaran (1992)

52. Template knowledge models 52
Assignment
■ create mapping between two sets of objects
➤ allocation of offices to employees
➤ allocation of airplanes to gates
■ mapping has to satisfy requirements and be
consistent with constraints
■ terminology
➤ subject, resource, allocation
■ can be seen as a “degenerative” form of
configuration design

53. Template knowledge models 53
Assignment:
method without backtracking
■ Order subject allocation to resources by selecting first
a sub-set of subjects
■ If necessary: group the subjects into subject-groups
for joint resource assignment
➤ requires special type of constraints and preferences
■ Take an subject(-group) and assign a resource to it.
■ Repeat this process until all subjects have a resource

54. Template knowledge models 54
Assignment:
inference structure
subjects
subject
set
subject
group
resourceresources
current
allocations
select
subset
group
assign

55. Template knowledge models 55
Assignment:
method control
while not empty subjects do
select-subset(subjects -> subject-set);
while not empty subject-set do
group(subject-set -> subject-group);
assign(subject-group + resources + current-allocations ->
resource);
current-allocations := < subject-group, resource > union
current-allocations;
subject-set := subject-set/subject-group;
resources := resources/resource;
end while
subjects := subjects/subject-set;
end while

56. Template knowledge models 56
Assignment:
method variations
■ Existing allocations
➤ additional input
■ subject-specific constraints and preferences
➤ see synthesis and configuration-design

57. Template knowledge models 57
Planning
■ shares many features with design
■ main difference: "system" consists of activities plus
time dependencies
■ examples: travel planning; planning of building activities
■ automation only feasible, if the basic plan elements
are predefined
■ consider use of the general synthesis method (e.g
therapy planning) or the configuration-design method

58. Template knowledge models 58
Planning method
plan
goal
hard
requirements
soft
requirements
possible
plans
list
of
preferred
plans
valid
plans
constraints
preferences
preference
ordering
knowledge
plan
composition
knowledge
operationalize
generate
select
subset
sort
requirements

59. Template knowledge models 59
Scheduling
■ Given a set of predefined jobs, each of which
consists of temporally sequenced activities called
units, assign all the units to resources at time slots
➤ production scheduling in plant floors
■ Terminology: job, unit, resource, schedule
■ Often done after planning (= specification of jobs)
■ Take care: use of terms “planning” and “scheduling”
differs

60. Template knowledge models 60
Scheduling:
temporal dispatching method
■ Specify an initial schedule
■ Select a candidate unit to be assigned
■ Select a target resource for this unit
■ Assign unit to the target resource
■ Evaluate the current schedule
■ Modify the schedule, if needed

61. Template knowledge models 61
Scheduling:
inference structure
job
schedule
candidate
unit
target
resource
truth
value
specify
modify
verify
assign
select
select

62. Template knowledge models 62
Scheduling:
method control
specify(jobs -> schedule);
while new-solution select(schedule -> candidate-unit) do
select(candidate-unit + schedule -> target-resource);
assign(candidate-unit + target-resource -> schedule);
evaluate(schedule -> truth-value);
if truth-value = false then
modify(schedule -> schedule);
end while

63. Template knowledge models 63
Scheduling:
method variations
■ Constructive versus repair method
■ Refinement often necessary
➤ see scheduling literature
➤ catalog of Hori (IBM Japan)

64. Template knowledge models 64
Scheduling: typical
domain schema
s chedule job
release-­‐date:
time
due-­‐date:
time
unit
start:
time
end:
time
resource-­‐type:
string
res ource
type:
string
start-­‐time:
time
end-­‐time:
time
includes
{dynamically
linked}
{temporally
ordered}
job
unit
preference
cons traint
is
performed
at
res ource
capacity
cons traint

65. Template knowledge models 65
Modeling
■ included for completeness
■ "construction of an abstract description of a system
in order to explain or predict certain system
properties or phenomena"
■ examples:
➤ construction of a simulation model of nuclear accident
➤ knowledge modeling itself
■ seldom automated => creative steps
➤ exception: chip modeling

66. Template knowledge models 66
In applications:
typical task combinations
■ monitoring + diagnosis
➤ Production process
■ monitoring + assessment
➤ Nursing task
■ diagnosis + planning
➤ Troubleshooting devices
■ classification + planning
➤ Military applications

67. Template knowledge models 67
Example: apple-pest
management
mintor
crop
identify
pest
plan
measure
execute
plan
[possible
threat]
[possible
pest]

68. Template knowledge models 68
Comparison with O-O analysis
■ Reuse of functional descriptions is not common in O-
O analysis
➤ notion of “functional” object
■ But: see work on design patterns
➤ strategy patterns
➤ templates are patterns of knowledge-intensive tasks
■ Only real leverage from reuse if the patterns are
limited to restricted task types