CommonKADS knowledge model templates

1,175 views
1,133 views

Published on

Ch. 6 of the CommonKADS textbook

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,175
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
40
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CommonKADS knowledge model templates

  1. 1. Template knowledge models Reusing knowledge model elements
  2. 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. 3. Template knowledge models 3 The need for reuse ■  prevent "re-inventing the wheel" ■  cost/time efficient ■  decreases complexity ■  quality-assurance
  4. 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. 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. 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. 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. 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. 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. 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. 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. 12. Template knowledge models 12 Classification: inference structure object class attribute feature truth value generate specify match obtain    
  13. 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. 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. 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. 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. 17. Template knowledge models 17 Nested classification rock rock classifcation minerals obtain:  Quartz  percentage mineral   classification Quartz olivine sub-­‐task identify Quartz contains
  18. 18. Template knowledge models 18 Rock classification prototype
  19. 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. 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. 21. Template knowledge models 21 Assessment: inference structure case abstracted case norms norm valuedecision abstract select match specify evaluate norm
  22. 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. 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. 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. 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. 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. 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. 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. 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. 30. Template knowledge models 30 Diagnosis: inference structure complaint cover specify select obtain hypothesis observable finding hypothesis verify result
  31. 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. 32. Template knowledge models 32 Diagnosis: method variations ■  inclusion of abstractions ■  simulation methods ■  see literature on model-based diagnosis ➤  library of Benjamins
  33. 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. 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. 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. 36. Template knowledge models 36 Monitoring: inference structure new finding select system model specifycompare classify parameter difference norm discrepancy historical data receive
  37. 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. 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. 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. 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. 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. 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. 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. 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. 45. Template knowledge models 45 Elevator configuration: knowledge base reuse
  46. 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. 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. 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. 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. 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. 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. 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. 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. 54. Template knowledge models 54 Assignment: inference structure subjects subject set subject group resourceresources current allocations select subset group assign    
  55. 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. 56. Template knowledge models 56 Assignment: method variations ■  Existing allocations ➤  additional input ■  subject-specific constraints and preferences ➤  see synthesis and configuration-design
  57. 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. 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. 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. 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. 61. Template knowledge models 61 Scheduling: inference structure job schedule candidate unit target resource truth value specify modify verify assign select select    
  62. 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. 63. Template knowledge models 63 Scheduling: method variations ■  Constructive versus repair method ■  Refinement often necessary ➤  see scheduling literature ➤  catalog of Hori (IBM Japan)
  64. 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. 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. 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. 67. Template knowledge models 67 Example: apple-pest management mintor crop identify pest plan   measure execute plan [possible  threat] [possible  pest]
  68. 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

×