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
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);
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
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
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
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
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