commonkads knowledge model templates
Post on 11-Jun-2015
467 Views
Preview:
DESCRIPTION
TRANSCRIPT
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 hierarchy knowledge-‐intens iv e
tas k
ana ly tictas k
c las s ifica tion
s ynthetictas k
as s es s ment
diagnos is
config ura tiondes ign
planning
s cheduling
as s ig nment
modelling
predic tion
monitoring
des ign
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
objec t
c lass
attribute
feature
truthvalue
generate
spec ify
match
obtain
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;
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
objec t type
attribute
value: universal
objec t c las s
c las scons traint
requires
has -‐attributec lass -‐of
2+ 1+
Template knowledge models 16
Rock classification
volcanicrock
igneousrock
plutonicrock
s yenite diorite
peridotite dunite
minera l
rock
texturegrain sizecolour
minera lcontent
percentagepresence
1+
minera l contentcons tra int
s ilica te
nes os ilica te
tec tos ilica te
oliv ine quartz
mineralsontology
Template knowledge models 17
Nested classification
rock
roc kc lass ifc ation
minera ls
obta in: Qua rtz percentage
mineral c lass ific ation
Quartz oliv ine
s ub-‐tas k
identifyQua rtz
conta ins
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
abstracted case norms
norm value decision
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 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);
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]
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
c as e
c as edatum
cas e datum
value: universal
dec is ionnorm
truth-‐value: boolean indic ates
has abstrac tion
implies
dec is ionrule
requirement
abs trac tionrule
1+
1+
1+
Template knowledge models 26
Claim handling for unemployment benefits
:c laim
collec tdata
dataentry
dec ide about c laim
computebenefit
sendnotific ation prepare
payment
[no right][right]
c laim handling finac ialdepartment
Template knowledge models 27
Decision rules for claim handling
<norm>WW benefitrequirement
<dec ision>WW benefit
rig ht
<dec is ion rule>benefit dec is ion
rule
DE F INE S
insured = falseDE F INE SWW -‐benefit-‐right.value = no-‐right
iunemployed = falseDE F INE SWW -‐benefit-‐right.value = no-‐right
weeks-‐worked-‐requirement = falseDE F INE SWW -‐benefit-‐right.value = no-‐right
insured = true ANDunemployed = true ANDweeks-‐worked-‐-‐requirement = true ANDyears -‐worked-‐requirement = falseDE F INE SWW -‐benefit-‐right.value = short-‐benefit
insured = true ANDunemployed = true ANDweeks-‐worked-‐-‐requirement = true ANDyears -‐worked-‐requirement = trueDE F INE SWW -‐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
compla int
cover
s pec ify
s e lect obta in
hypothes is
obs ervable
finding
hypothes is
verify
res ult
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;
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
systemfea ture
systemobservable
value: universal
systemsta te
status: universal
fault
prevalence: number[0..1]
systemsta te
systemfea ture can cause
causa ldependency
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 s e lect
s ys temmode l
s pec ifycompa re
c la s s ify
pa rameter
diffe rence
norm
dis crepancy
his torica lda ta
rece ive
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
"P 166 proces s or requires 16Mb"
"pre fe r cheapes t component"
preferenc e
c ons traint
"price lower than $2,000"
"fa s t s ys tem"
hard requirement
s oft requirement
requirements(externa l)
cons tra ints & preferences(interna l)
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
ha rdrequirements
s oftrequirements
pos s ibles ys tem s tructures
lis t of pre ferreds ys tem s tructures
va lid s ys tem s tructures
cons tra ints
pre ferences
pre ferenceordering
knowledge
s ys temcompos itionknowledge
opera tiona lize
g enera te
s e lec ts ubs et
s ort
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
s oftrequirements
hardrequirements
s keletaldes ign
des ign
extens ion
violation truthvalueaction
actionlis t
operationaliz e
critique
modify
verify
s pec ify
propos e
s elec t
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
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
des ign e lement
parameter
va lue : univers a l
component
model lis t: lis t
fix ac t ion
act ion type
cons tra int
des ignelement
component
ca lcula t ionexpres s ion
cons tra intexpres s ion
computes
implies
1+
1+
1+
1+ fix
ha s -‐pa rameter
0+
definespreference
preference
ra ting : univers a l
preferenceexpres s ion
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
subjec ts subjec tset
subjec tgroup
resourc eresources
currentalloc ations
selec tsubset
group
ass ign
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 g oa l
ha rdrequirements
s oftrequirements
pos s ibleplans
lis t of pre ferredplans
va lid plans
cons tra ints
pre ferences
pre ferenceordering
knowledge
plancompos itionknowledge
opera tiona lize
g enera te
s e lec ts ubs et
s ort
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
c andidateunit
targetresource
truthvaluespec ify
modify
verify
ass ign
selec t
selec t
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
s c hedule job
release-‐date: timedue-‐date: time
unit
start: timeend: timeresourc e-‐type: s tring
res ourc e
type: s tringstart-‐time: timeend-‐time: time
inc ludes
{dynamically linked}
{temporallyordered} job unit
preferencecons traint
is performed at
res ourc ec apac itycons traint
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
mintorc rop
identifypest
plan measure
executeplan
[poss ible threat]
[poss ible 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
top related