CommonKADS knowledge model templates
2 likes4,996 views
This document discusses knowledge model templates for reusing elements when creating new knowledge models. It presents different types of tasks like classification, assessment, diagnosis, and monitoring that knowledge models can perform. For each task, it provides the typical inference structure, control structure, and domain schema that can be reused from templates. It also discusses how task templates can be customized for different variations and domains.
![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]](https://image.slidesharecdn.com/05-km-templates-140810193556-phpapp02/85/CommonKADS-knowledge-model-templates-23-320.jpg)
![Template knowledge models 26
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](https://image.slidesharecdn.com/05-km-templates-140810193556-phpapp02/85/CommonKADS-knowledge-model-templates-26-320.jpg)
![Template knowledge models 33
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](https://image.slidesharecdn.com/05-km-templates-140810193556-phpapp02/85/CommonKADS-knowledge-model-templates-33-320.jpg)
![Template knowledge models 67
Example: apple-pest
management
mintor
crop
identify
pest
plan
measure
execute
plan
[possible
threat]
[possible
pest]](https://image.slidesharecdn.com/05-km-templates-140810193556-phpapp02/85/CommonKADS-knowledge-model-templates-67-320.jpg)
CommonKADS knowledge model templates
- 1. Template knowledge models Reusing knowledge model elements
- 2. 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
- 3. Template knowledge models 3 The need for reuse ■ prevent "re-inventing the wheel" ■ cost/time efficient ■ decreases complexity ■ quality-assurance
- 4. 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
- 5. 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”
- 6. 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)
- 7. 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
- 8. Template knowledge models 8 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
- 9. 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
- 10. 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
- 11. 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
- 12. Template knowledge models 12 Classification: inference structure object class attribute feature truth value generate specify match obtain
- 13. 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;
- 14. 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
- 15. Template knowledge models 15 Classification: domain schema object type attribute value: universal object clas s clas s cons traint requires has-‐attribute class-‐of 2+ 1+
- 16. Template knowledge models 16 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
- 17. Template knowledge models 17 Nested classification rock rock classifcation minerals obtain: Quartz percentage mineral classification Quartz olivine sub-‐task identify Quartz contains
- 18. Template knowledge models 18 Rock classification prototype
- 19. 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
- 20. 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
- 21. Template knowledge models 21 Assessment: inference structure case abstracted case norms norm valuedecision abstract select match specify evaluate norm
- 22. 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);
- 23. 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]
- 24. 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
- 25. Template knowledge models 25 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+
- 26. Template knowledge models 26 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
- 27. Template knowledge models 27 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 W W -‐benefit-‐right.value = no-‐right weeks-‐worked-‐requirement = false DE F INE S W W -‐benefit-‐right.value = no-‐right insured = true AND unemployed = true AND weeks-‐worked-‐-‐requirement = true AND years-‐worked-‐requirement = false DE F INE S W W -‐benefit-‐right.value = short-‐benefit insured = true AND unemployed = true AND weeks-‐worked-‐-‐requirement = true AND years-‐worked-‐requirement = true DE F INE S W W -‐benefit-‐right.value = long-‐benefit
- 28. 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
- 29. 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
- 30. Template knowledge models 30 Diagnosis: inference structure complaint cover specify select obtain hypothesis observable finding hypothesis verify result
- 31. 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;
- 32. Template knowledge models 32 Diagnosis: method variations ■ inclusion of abstractions ■ simulation methods ■ see literature on model-based diagnosis ➤ library of Benjamins
- 33. Template knowledge models 33 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
- 34. 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
- 35. 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
- 36. Template knowledge models 36 Monitoring: inference structure new finding select system model specifycompare classify parameter difference norm discrepancy historical data receive
- 37. 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;
- 38. 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
- 39. 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
- 40. Template knowledge models 40 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)
- 41. 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
- 42. Template knowledge models 42 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
- 43. 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
- 44. 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
- 45. Template knowledge models 45 Elevator configuration: knowledge base reuse
- 46. 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
- 47. Template knowledge models 47 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
- 48. 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
- 49. 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
- 50. Template knowledge models 50 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+
- 51. 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)
- 52. 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
- 53. 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
- 54. Template knowledge models 54 Assignment: inference structure subjects subject set subject group resourceresources current allocations select subset group assign
- 55. 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
- 56. Template knowledge models 56 Assignment: method variations ■ Existing allocations ➤ additional input ■ subject-specific constraints and preferences ➤ see synthesis and configuration-design
- 57. 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
- 58. Template knowledge models 58 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
- 59. 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
- 60. 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
- 61. Template knowledge models 61 Scheduling: inference structure job schedule candidate unit target resource truth value specify modify verify assign select select
- 62. 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
- 63. Template knowledge models 63 Scheduling: method variations ■ Constructive versus repair method ■ Refinement often necessary ➤ see scheduling literature ➤ catalog of Hori (IBM Japan)
- 64. Template knowledge models 64 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
- 65. 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
- 66. 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
- 67. Template knowledge models 67 Example: apple-pest management mintor crop identify pest plan measure execute plan [possible threat] [possible pest]
- 68. 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