Post on 01-Apr-2015
Template knowledge models
Reusing knowledge model elements
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
Template knowledge models
3
The need for reuse
prevent "re-inventing the wheel" cost/time efficient decreases complexity quality-assurance
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
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”
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)
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
Template knowledge models
8
Task hierarchyknowledge-intensive
task
analytictask
classification
synthetictask
assessment
diagnosis
configurationdesign
planning
scheduling
assignment
modelling
prediction
monitoring
design
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
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
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
Template knowledge models
12
Classification:inference structure
object
class
attribute
feature
truthvalue
generate
specify
match
obtain
Template knowledge models
13
Classification: method control
while new-solution generate(object -> candidate) docandidate-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;
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
Template knowledge models
15
Classification: domain schema
object type
attribute
value: universal
object class
classconstraint
requires
has-attributeclass-of
2+ 1+
Template knowledge models
16
Rock classification
volcanicrock
igneousrock
plutonicrock
syenite diorite
peridotite dunite
mineral
rock
texturegrain sizecolour
mineralcontent
percentagepresence
1+
mineral contentconstraint
silicate
nesosilicate
tectosilicate
olivine quartz
mineralsontology
Template knowledge models
17
Nested classification
rock
rockclassifcation
minerals
obtain: Quartz percentage
mineral classification
Quartz olivine
sub-task
identifyQuartz
contains
Template knowledge models
18
Rock classification prototype
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
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
Template knowledge models
21
Assessment:inference structure
case
abstractedcase norms
normvaluedecision
abstract
select
match
specify
evaluate norm
Template knowledge models
22
Assessment: method control
while new-solution abstract(case-description -> abstracted-case) do
case-description := abstracted-case;
end whilespecify(abstracted-case -> norms);
repeatselect(norms -> norm);
evaluate(abstracted-case + norm -> norm-value);
evaluation-results := norm-value union evaluation-results;
until has-solution match(evaluation-results -> decision);
Template knowledge models
23
Assessment control: UML notation
abstract
specifynorms
selectnorm
matchdecision
evaluatenorm
[more abstractions]
[no moreabstractions] [match fails
no decision][match succeeds:decision found]
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
Template knowledge models
25
Assessment: domain schema
case
casedatum
case datum
value: universal
decisionnorm
truth-value: boolean indicates
has abstraction
implies
decisionrule
requirement
abstractionrule
1+
1+
1+
Template knowledge models
26
Claim handling for unemployment benefits
:claim
collectdata
dataentry
decide about claim
computebenefit
sendnotification prepare
payment
[no right][right]
claim handling finacialdepartment
Template knowledge models
27
Decision rules for claim handling
<norm>WW benefitrequirement
<decision>WW benefit
right
<decision rule>benefit decision
rule
DEFINES
insured = falseDEFINESWW-benefit-right.value = no-right
iunemployed = falseDEFINESWW-benefit-right.value = no-right
weeks-worked-requirement = falseDEFINESWW-benefit-right.value = no-right
insured = true ANDunemployed = true ANDweeks-worked--requirement = true ANDyears-worked-requirement = falseDEFINESWW-benefit-right.value = short-benefit
insured = true ANDunemployed = true ANDweeks-worked--requirement = true ANDyears-worked-requirement = trueDEFINESWW-benefit-right.value = long-benefit
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
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
Template knowledge models
30
Diagnosis:inference structure
complaint
cover
specify
select obtain
hypothesis
observable
finding
hypothesis
verify
result
Template knowledge models
31
Diagnosis: method control
while new-solution cover(complaint -> hypothesis) do
differential := hypothesis add differential;
end while
repeatselect(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;
Template knowledge models
32
Diagnosis: method variations
inclusion of abstractions simulation methods see literature on model-based diagnosis
library of Benjamins
Template knowledge models
33
Diagnosis: domain schema
systemfeature
systemobservable
value: universal
systemstate
status: universal
fault
prevalence: number[0..1]
systemstate
systemfeature can cause
causaldependency
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
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
Template knowledge models
36
Monitoring: inference structure
newfinding
select
systemmodel
specifycompare
classify
parameter
difference
norm
discrepancy
historicaldata
receive
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;
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
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
Template knowledge models
40
Synthesis
Given a set of requirements, construct a system description that fulfills these requirements
"P166 processor requires 16Mb"
"prefer cheapest component"
preference
constraint
"price lower than $2,000"
"fast system"
hard requirement
soft requirement
requirements(external)
constraints & preferences(internal)
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
Template knowledge models
42
Synthesis:inference structure
requirements
hardrequirements
softrequirements
possiblesystem
structures
list of preferredsystem structures
valid system structures
constraints
preferences
preferenceordering
knowledge
systemcompositionknowledge
operationalize
generate
selectsubset
sort
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
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
Template knowledge models
45
Elevator configuration: knowledge base reuse
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
Template knowledge models
47
Configuration: method decomposition
requirements
softrequirements
hardrequirements
skeletaldesign
design
extension
violationtruthvalue
action
actionlist
operationalize
critique
modify
verify
specify
propose
select
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) dodesign := 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
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
Template knowledge models
50
Configuration: domain schema
design element
parameter
value: universal
component
model list: list
fix action
action type
constraint
designelement
component
calculationexpression
constraintexpression
computes
implies
1+
1+
1+
1+ fix
has-parameter
0+
definespreference
preference
rating: universal
preferenceexpression
1+
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)
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
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
Template knowledge models
54
Assignment:inference structure
subjectssubject
set
subjectgroup
resourceresources
currentallocations
selectsubset
group
assign
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
Template knowledge models
56
Assignment:method variations
Existing allocations additional input
subject-specific constraints and preferences see synthesis and configuration-design
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
Template knowledge models
58
Planning method
plan goal
hardrequirements
softrequirements
possibleplans
list of preferredplans
valid plans
constraints
preferences
preferenceordering
knowledge
plancompositionknowledge
operationalize
generate
selectsubset
sort
requirements
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
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
Template knowledge models
61
Scheduling:inference structure
job
schedule
candidateunit
targetresource
truthvalue
specify
modify
verify
assign
select
select
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
Template knowledge models
63
Scheduling: method variations
Constructive versus repair method Refinement often necessary
see scheduling literature catalog of Hori (IBM Japan)
Template knowledge models
64
Scheduling: typical domain schema
schedule job
release-date: timedue-date: time
unit
start: timeend: timeresource-type: string
resource
type: stringstart-time: timeend-time: time
includes
{dynamically linked}
{temporallyordered}
job unit
preferenceconstraint
is performed at
resourcecapacity
constraint
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
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
Template knowledge models
67
Example: apple-pest management
mintorcrop
identifypest
plan measure
executeplan
[possible threat]
[possible pest]
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