Template knowledge models
Reusing knowledge model elements
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
The need for reuse
prevent "re-inventing the wheel"
cost/time efficient
decreases complexity
quality-assurance
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
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”
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)
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
Task hierarchy
knowledge- intensive
task
analytic task
classification
synthetic task
assessment
diagnosis planning
scheduling
assignment
modelling prediction
monitoring
design
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
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
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
Classification:
inference structure
object
class
attribute
feature generate
specify
match
obtain
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;
Classification:
method variations
Limited candidate generation
Different forms of attribute selection
decision tree
information theory
user control
Hierarchical search through class structure
Classification:
domain schema
object type
attribute value: universal object class
class constraint
requires
has-attribute class-of
2+ 1+
Rock classification
volcanic rock
igneous rock
plutonic rock
mineral rock
texture grain size colour
mineral content percentage presence
1+
mineral content constraint
silicate
silicateneso tecto silicate
minerals ontology
Nested classification
rock
rock
classifcation
minerals
obtain: Quartz percentage
mineral classification
Quartz olivine
sub-task
identify Quartz contains
Rock classification prototype
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
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
Assessment:
inference structure
case
abstracted
case norms
valuenorm decision
abstract
select
match specify
evaluate norm
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;
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]
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
Assessment:
domain schema
case
case datum case datum
value: universal
decision norm
truth-value: boolean indicates has abstraction
implies
decision rule requirement
abstraction rule
1+
1+
1+
Claim handling for
unemployment benefits
:claim collect
data data
entry decide
about claim
compute benefit [no right]
[right]
claim handling finacial
department
Decision rules for claim handling
<norm>
WW benefit requirement
<decision>
WW benefit right
<decision rule>
benefit decision rule DEFINES
insured = false DEFINES
WW-benefit-right.value = no-right iunemployed = false
DEFINES
WW-benefit-right.value = no-right weeks-worked-requirement = false DEFINES
WW-benefit-right.value = no-right
insured = true AND unemployed = true AND
weeks-worked--requirement = true AND years-worked-requirement = false DEFINES
WW-benefit-right.value = short-benefit
insured = true AND unemployed = true AND
weeks-worked--requirement = true AND years-worked-requirement = true
DEFINES
WW-benefit-right.value = long-benefit
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
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
Diagnosis:
inference structure
complaint
cover
specify
select obtain
hypothesis
observable
finding hypothesis
verify
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;
Diagnosis:
method variations
inclusion of abstractions
simulation methods
see literature on model-based diagnosis
library of Benjamins
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
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
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
Monitoring:
inference structure
findingnew select
system model
specify compare
classify
parameter
difference
norm
discrepancy receive
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;
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
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
Synthesis
Given a set of requirements, construct a system description that fulfills these requirements
"prefer cheapest component"
preference
constraint
"fast system"
hard requirement soft requirement
requirements (external)
constraints & preferences (internal)
“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
Synthesis:
inference structure
requirements
requirementshard
possible system structures
valid system structures
constraints
preferences system composition
knowledge operationalize
generate
select subset
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
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
Elevator configuration:
knowledge base reuse
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
Configuration:
method decomposition
requirements
requirementssoft
requirementshard
skeletal design
design
extension
violation truth
value action
action list operationalize
critique modify
verify specify
propose
select
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);
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
Configuration:
domain schema
design element fix action
action type
constraint
design element
calculation expression
constraint expression
computes
implies
1+
1+
1+ fix
defines preference preference rating: universal
preference expression 1+
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)
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
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
Assignment:
inference structure
subjects subject
set
subject group
resource resources
select subset
group
assign
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
Assignment:
method variations
Existing allocations
additional input
subject-specific constraints and preferences
see synthesis and configuration-design
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
Planning method
plan goal
requirementshard
possible plans
valid plans
constraints
preferences compositionplan
knowledge
operationalize
generate
select subset requirements
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
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
Scheduling:
inference structure
job
schedule
candidate unit
target resource
truth value specify
modify verify
assign select
select
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
Scheduling:
method variations
Constructive versus repair method
Refinement often necessary
see scheduling literature
catalog of Hori (IBM Japan)
Scheduling: typical domain schema
schedule job
release-date: time due-date: time
unit start: time end: time
resource-type: string resource
type: string start-time: time end-time: time
includes
{dynamically linked}
{temporally
ordered} job unit
preference constraint
is performed at
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
In applications:
typical task combinations
monitoring + diagnosis
Production process
monitoring + assessment
Nursing task
diagnosis + planning
Troubleshooting devices
classification + planning
Military applications
Example: apple-pest management
mintor crop
identify
pest plan
measure execute
plan
[possible threat]
[possible pest]
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
