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


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

objec t

c lass

attribute

feature

truthvalue

generate

spec ify

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

objec t type

attribute

value: universal

objec t c las s

c las scons traint

requires

has -‐attributec lass -‐of

2+ 1+


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


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


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

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

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+


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


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


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

compla int

cover

s pec ify

s e lect obta in

hypothes is

obs ervable

finding

hypothes is

verify

res ult


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

systemfea ture

systemobservable

value: universal

systemsta te

status: universal

fault

prevalence: number[0..1]

systemsta te

systemfea ture can cause

causa ldependency


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

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


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


“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

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


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

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


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

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+


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

subjec ts subjec tset

subjec tgroup

resourc eresources

currentalloc ations

selec tsubset

group

ass ign


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


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

c andidateunit

targetresource

truthvaluespec ify

modify

verify

ass ign

selec t

selec t


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


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

mintorc rop

identifypest

plan measure

executeplan

[poss ible threat]

[poss ible 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

Date post:	11-Jun-2015
Category:	Technology
Upload:	guus-schreiber
View:	460 times
Download:	1 times

CommonKADS knowledge model templates

Technology