CommonKADS knowledge model templates

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

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-‐
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

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
truth
value
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
clas s
clas s
cons traint

requires

has-‐attribute
class-‐of
2+ 1+

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

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
norm
valuedecision
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;
until has-solution match(evaluation-results -> decision);

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
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+

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

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
=
no-‐right
weeks-‐worked-‐requirement
=
false
DE F INE S
=
no-‐right
insured
=
true
AND
unemployed
=
true
AND
weeks-‐worked-‐-‐requirement
=
true
AND
years-‐worked-‐requirement
=
false
DE F INE S
=
short-‐benefit
insured
=
true
AND
unemployed
=
true
AND
weeks-‐worked-‐-‐requirement
=
true
AND
years-‐worked-‐requirement
=
true
DE F INE S
=
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
result

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
➤  output monitoring is input 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
new
finding
select
system
model
specifycompare
classify
parameter
difference
norm
discrepancy
historical
data
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
"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)

“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
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

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
soft
requirements
hard
requirements
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);
until truth-value = true;
end while

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
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+

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
resourceresources
current
allocations
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
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

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

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

CommonKADS knowledge model templates

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a CommonKADS knowledge model templates

Semelhante a CommonKADS knowledge model templates (20)

Mais de Guus Schreiber

Mais de Guus Schreiber (20)

Último

Último (20)

CommonKADS knowledge model templates