Successfully reported this slideshow.

CommonKADS knowledge modelling basics


Published on

Ch. 5 of the CommonKADS textbook

Published in: Technology
  • Be the first to comment

  • Be the first to like this

CommonKADS knowledge modelling basics

  1. 1. Knowledge Model Basics Challenges in knowledge modeling Basic knowledge-modeling constructs Comparison to general software analysis
  2. 2. Knowledge-modelling basics 2 Knowledge model ■  specialized tool for specification of knowledge- intensive tasks ■  abstracts from communication aspects ■  real-world oriented ■  reuse is central theme
  3. 3. Knowledge-modelling basics 3 Relation to other models organization model task model agent model knowledge- intensive task communication model knowledge model design model requirements specification for interaction functions requirements specification for reasoning functions task selected in feasibility study and further detailed in Task and Agent Models
  4. 4. Knowledge-modelling basics 4 The term “knowledge” ■  “information about information” ■  example: sub-class hierarchy of object types ■  no hard borderline between information and knowledge ➤  knowledge is “just“ semantically rich information ■  target: “knowledge-intensive” systems ➤  large bulk of meaningful information is present ➤  scope is broader than traditional KBS
  5. 5. Knowledge-modelling basics 5 Challenges in specifying knowledge pers on age income loan amount interes t J ohn  has  a  loan  of  $1,750 Harry  has  a  loan  of  $2,500 A  person  with  a  loan  should  be  at  least  18  years  old A  person  with  an  income  up  to  $10,000  can  get  a  maximum  loan  of  $2,000 A  person  with  an  income  between  $10,000  and  $20,000  can  get  a  maximum  loan  of  $3,000 INF OR MATION KNOW L E DGE has  loan
  6. 6. Knowledge-modelling basics 6 Structuring a knowledge base R ule  1:  IF  ...  T HE N  ... R ule  2:  IF  ...  T HE N  ... R ule  3:  IF  ...  T HE N  ... R ule  12:  IF  ...  T HE N  ... R ule  4:  IF  ...  T HE N  ... R ule  5:  IF  ...  T HE N  ... R ule  6:  IF  ...  T HE N  ... R ule  7:  IF  ...  T HE N  ... R ule  8:  IF  ...  T HE N  ... R ule  9:  IF  ...  T HE N  ... R ule  10:  IF  ...  T HE N  ... R ule  11:  IF  ...  T HE N  ... <plus  many  others> s ingle  flat   knowledge  bas e multiple  rule  s ets containing  rules with  s imilar  s tructure rules  of  type  A rules  of  type  D rules  of  type  B rules  of  type  C
  7. 7. Knowledge-modelling basics 7 Knowledge categories ■  Task knowledge ➤  goal-oriented ➤  functional decomposition ■  Domain knowledge ➤  relevant domain knowledge and information ➤  static ■  Inference knowledge ➤  basic reasoning steps that can be made in the domain knowledge and are applied by tasks
  8. 8. Knowledge-modelling basics 8 Knowledge model overview Dis eas e (type) S ymptom (type) Tes t (type) hypothesize (inference) verify (inference) DIAGNOS IS (task) Task  knowledge task  goals task  decomposition task  control Inference  knowledge basic  inferences roles Domain  knowledge domain  types domain  rules domain  facts    
  9. 9. Knowledge-modelling basics 9 Example domain: car diagnosis fuel  tank empty battery low battery  dial zero gas  dial zero power off engine  behavior does  not  s tart engine  behavior s tops gas  in  engine fals e fus e blow n fus e  ins pection broken 1 2 3 4 5 6 7 8 9
  10. 10. Knowledge-modelling basics 10 Domain knowledge ■  domain schema ➤  schematic description of knowledge and information types ➤  comparable to data model ➤  defined through domain constructs ■  knowledge base ➤  set of knowledge instances ➤  comparable to database content ➤  but; static nature
  11. 11. Knowledge-modelling basics 11 Constructs for domain schema ■  Concept ➤  cf. object class (without operations) ■  Relation ➤  cf. association ■  Attribute ➤  primitive value ■  Rule type ➤  introduces expressions => no SE equivalent
  12. 12. Knowledge-modelling basics 12 Concept & attribute ■  “Concept” describes a set of objects or instances ■  multiple concept hierarchies ➤  along distinct dimensions ■  can have any number of attributes ■  Am attribute refers to a value ■  values are atomic and are defined through a value type ■  attribute may not refer to another concept ➤  use relation construct
  13. 13. Knowledge-modelling basics 13 Example: car concepts VALUE -­‐TY P E  dial-­‐value;        VALUE -­‐LIS T:  {zero,  low,  normal};        TY P E :  ORDINAL; E ND  VALUE -­‐TY P E  dial-­‐value; CONCE P T  gas  dial;        ATTRIBUTE S :                value:  dial-­‐value; E ND  CONCE P T  gas-­‐dial; CONCE P T  fuel-­‐tank;        ATTRIBUTE S                status:    {full,  almost-­‐empty,  empty}; E ND  CONCE P T  fuel-­‐tank; gas  dial value:  dial-­‐value fuel  tank status:  {full,                          almost-­‐empty,                          empty}
  14. 14. Knowledge-modelling basics 14 Example: apple concept apple color:  {yellow,  yellow-­‐green,  green} rusty-­‐surface:  boolean greasy-­‐surface:  boolean form:  {flat,  high} Granny  S mith: apple  class Golden  Delicious: apple  class Grey  Reinet: apple  class Present  of  England: apple  class apple  class has  class    
  15. 15. Knowledge-modelling basics 15 Example: car subtypes car  state status:  universal observable:  boolean invisible car  state observable:  {false} visible car  state observable:  {true} car  observable value:  universal fuel  tank status:  {full,              almost-­‐empty,              empty} battery status:  {normal,                              low} fuse status:  {normal,                            blown} gas  in  engine status:  boolean power status:  {on,                                  off} engine  behavior status:  {normal,                                does-­‐not-­‐start,                              stops} fuse   inspection value:  {normal,                            broken} gas  dial value:  dial  value battery  dial value:  dial-­‐value    
  16. 16. Knowledge-modelling basics 16 Example: house sub-types apartment entrance-­‐floor:  natural lift-­‐available:  boolean res idence hous e square-­‐meters:  natural CONCE P T  house;        DE S CRIP TION:            "a  residence  with  its  own  territory";        S UB-­‐TY P E -­‐OF:  residence;        ATTRIBUTE S :                square-­‐meters:  NATURAL; E ND  CONCE P T  house; CONCE P T  apartment;        DE S CRIP TION:                "part  of  of  a  larger  estate";        S UB-­‐TY P E -­‐OF:  residence;        ATTRIBUTE S :                  entrance-­‐floor:  NATURAL;                  lift-­‐available:  BOOLE AN; E ND  CONCE P T  apartment;
  17. 17. Knowledge-modelling basics 17 Relation ■  typically between concepts, any arity ■  cardinality specification ■  special construct for binary relations ■  relations can have subtypes as well as attributes ■  reification of a relation is allowed ➤  relation functions as a concept ➤  cf. Association class in UML ➤  a form of higher order relations
  18. 18. Knowledge-modelling basics 18 Example: car relation car pers on car pers on ownership owners hip purchase  date:  date; a) b) car pers on owned-­‐by c) 0+ 0-­‐1    
  19. 19. Knowledge-modelling basics 19 N-ary relation agent name position obs ervation value date time obs ervable type location department hospital patient name diagnosis
  20. 20. Knowledge-modelling basics 20 Modelling rules ■  “rules” are a common form for symbolic knowledge ■  do not need to be formal ■  knowledge analysis is focused on finding rules with a common structure ➤  a rule as an instance of a rule type
  21. 21. Knowledge-modelling basics 21 Rule type ■  models a relation between expressions about feature values (e.g. attribute values) gas-dial.value = zero -> fuel-tank.status = empty ■  models set of real-world “rules” with a similar structure ■  dependency is usually not strictly logical (= implication) ➤  specify connection symbol
  22. 22. Knowledge-modelling basics 22 Example rule type loan constraint  restricts   person.income  < =  10,000                  RESTRICTS   loan.amount  < =  2,000 person.income  >  10,000  AND  person.income  < =  20,000                RESTRICTS   loan.amount  < =  3,000 person name:  string income:  integer loan amount:  integer interest-­‐rate:  number 1+
  23. 23. Knowledge-modelling basics 23 Rule type structure ■  <antecedent> <connection-symbol> <consequent> ■  example rule: fuel-supply.status = blocked CAUSES gas-in-engine.status = false; ■  flexible use for almost any type of dependency ➤  multiple types for antecedent and consequent
  24. 24. Knowledge-modelling basics 24 Rule types for car diagnosis invisible car  state car  state car   observable invisible car  state manifestation rule state dependency  causes   has manifestation 1 1 11
  25. 25. Knowledge-modelling basics 25 Knowledge base ■  = conceptual knowledge-base partition ■  contains instances of knowledge types ■  rule-type instances = “rules” ■  structure: ➤  USES: <types used> from <schema> ➤  EXPRESSIONS: <instances> ■  instance representation: ➤  intuitive natural language –  connection symbol ➤  formal expression language (appendix of book)
  26. 26. Knowledge-modelling basics 26 Example knowledge base KNOWLEDGE-BASE car-network; USES: state-dependency FROM car-diagnosis-schema, manifestation-rule FROM car-diagnosis-schema; EXPRESSIONS: /* state dependencies */ fuse.status = blown CAUSES power.status = off; battery.status = low CAUSES power.status = off; …. /* manifestation rules */ fuse.status = blown HAS-MANIFESTATION fuse-inspection.value = broken; battery.status = low HAS-MANIFESTATION battery-dial.value = zero; ….. END KNOWLEDGE-BASE car-network;
  27. 27. Knowledge-modelling basics 27 Inference knowledge ■  describes the lowest level of functional decomposition ■  basic information-processing units: ➤  inference => reasoning ➤  transfer function => communication with other agents ■  why special status? ➤  indirectly related to domain knowledge ➤  enables reuse of inference
  28. 28. Knowledge-modelling basics 28 Example inference: cover complaint hypothesiscover causal model my  car  does  not  start fuel  tank  is  empty fuel  tank  is  empty  leads  to  lack  of  gas  in  engine if  there  is  no  gas  in  the  engine,  then  the  car  does  not  start dynamic  input  role dynamic  output  role static  role inference
  29. 29. Knowledge-modelling basics 29 Inference ■  fully described through a declarative specification of properties of its I/O ■  internal process of the inference is a black box ➤  not of interest for knowledge modeling. ■  I/O described using “role names” ➤  functional names, not part of the domain knowledge schema / data model ■  guideline to stop decomposition: explanation
  30. 30. Knowledge-modelling basics 30 Knowledge role ■  Functional name for data/knowledge elements ■  Name captures the “role” of the element in the reasoning process ■  Explicit mapping onto domain types ■  Dynamic role: variant input/output ■  Static role: invariant input ➤  cf. a knowledge basel
  31. 31. Knowledge-modelling basics 31 Example inference INFERENCE cover; ROLES: INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model; SPECIFICATION: "Each time this inference is invoked, it generates a candidate solution that could have caused the complaint. The output thus should be an initial state in the state dependency network which causally ``covers'' the input complaint."; END INFERENCE cover;
  32. 32. Knowledge-modelling basics 32 Example dynamic knowledge roles KNOWLEDGE-ROLE complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-state; END KNOWLEDGE-ROLE complaint; KNOWLEDGE-ROLE hypothesis; TYPE: DYNAMIC; DOMAIN-MAPPING: invisible-state; END KNOWLEDGE-ROLE hypothesis;
  33. 33. Knowledge-modelling basics 33 Example static knowledge role KNOWLEDGE-ROLE causal-model; TYPE: STATIC; DOMAIN-MAPPING: state-dependency FROM car-network; END KNOWLEDGE-ROLE causal-model;
  34. 34. Knowledge-modelling basics 34 Transfer functions ■  transfers an information item between the reasoning agent and another agent ■  from the knowledge-model point of view black box: only its name and I/O ■  detailed specification of transfer functions is part of communication model ■  standard names
  35. 35. Knowledge-modelling basics 35 Types of transfer functions obtain receive present provide s ys tem initiative external initiative external information internal information
  36. 36. Knowledge-modelling basics 36 Inference structure ■  combined set of inferences specifies the basic inference capability of the target system ■  graphical representation: inference structure ■  provides constraints for control flow
  37. 37. Knowledge-modelling basics 37 Example: car inferences complaint   cover predict compare obtain expected finding actual finding result causal  model manifestation  model hypothesis
  38. 38. Knowledge-modelling basics 38 Using inference structures ■  Important communication vehicle during development process ■  Often provisional inference structures ■  Can be difficult to understand because of “vague” (non domain-specific terms) ■  Often useful to annotate with domain-specific examples
  39. 39. Knowledge-modelling basics 39 Annotated inference structure complaint   cover predict compare obtain expected finding actual finding result causal  model manifestation  model hypothesis engine  does not  start state  dependency rules empty  fuel  tank gas  dial  =  zero/low gas  dial  =  normal not  equal manifestation rules
  40. 40. Knowledge-modelling basics 40 Reusing inferences ■  Standard set of inferences?! ➤  difficult subject ■  See catalog in Ch. 13 ■  Use as much as possible standard names
  41. 41. Knowledge-modelling basics 41 Task knowledge ■  describes goals ➤  assess a mortgage application in order to minimize the risk of losing money ➤  find the cause of a malfunction of a photocopier in order to restore service. ➤  design an elevator for a new building. ■  describes strategies that can be employed for realizing goals. ■  typically described in a hierarchical fashion:
  42. 42. Knowledge-modelling basics 42 Task decomposition for car diagnosis diagnosis diagnosis through generate-and-test obtain cover predict task task method compare decomposition inferences transfer function
  43. 43. Knowledge-modelling basics 43 Task ■  Description of the input/output ■  Main distinction with traditional functions is that the data manipulated by the task are (also) described in a domain-independent way. ➤  example, the output of a medical diagnosis task would not be a “disease” but an abstract name such as “fault category”
  44. 44. Knowledge-modelling basics 44 Example task TASK car-fault-category; GOAL: "Find a likely cause for the complaint of the user"; ROLES: INPUT: complaint: "Complaint about the behavior of the car"; OUTPUT: fault-category: "A hypothesis explained by the evidence"; evidence: "Set of observations obtained during the diagnostic process"; SPEC: "Find an initial state that explains the complaint and is consistent with the evidence obtained"; END TASK car-diagnosis;
  45. 45. Knowledge-modelling basics 45 Task method ■  describes how a task is realized through a decomposition into sub-functions ■  sub-functions: another task, inference, transfer function ■  core part of a method: “control structure” ➤  describes ordering of sub-functions small program, captured reasoning strategy ■  additional task roles ➤  to store intermediate reasoning results
  46. 46. Knowledge-modelling basics 46 Example task method TASK-METHOD diagnosis-through-generate-and-test; DECOMPOSITION: INFERENCES: cover, predict, compare; TRANSFER-FUNCTIONS: obtain; ROLES: INTERMEDIATE: expected-finding: "The finding predicted, in case the hypothesis is true"; actual-finding: "The finding actually observed";
  47. 47. Knowledge-modelling basics 47 Example method control CONTROL-STRUCTURE: REPEAT cover(complaint -> hypothesis); predict(hypothesis -> expected-finding); obtain(expected-finding -> actual-finding); evidence := evidence ADD actual-finding; compare(expected-finding + actual-finding -> result); UNTIL "result = equal or no more solutions of over"; END REPEAT IF result == equal THEN fault-category := hypothesis; ELSE "no solution found"; END IF
  48. 48. Knowledge-modelling basics 48 UML activity diagram for method control cover predict obtain compare [no  more  solutions of  cover] [new  solution of  cover] [result  =  equal] [result  =  not  equal] solution  found no  solution  found start diagnosis through generate-­‐and-­‐test
  49. 49. Knowledge-modelling basics 49 Control structure elements ■  “procedure” calls: ➤  tasks, transfer functions, inferences ■  role operations ➤  assign, add/append, delete/subtract, retrieve, .. ■  control primitives ➤  repeat-until, while-do, foreach-do, if-then-else
  50. 50. Knowledge-modelling basics 50 Control structures (cont.) Conditions: ■  logical expressions about roles: ➤  until differential = empty ■  two special conditions ➤  has-solution –  invocation of inference that can fail ➤  new solution –  invocation of inference that can succeed multiple times, e.g. the cover inference in the car-diagnosis model
  51. 51. Knowledge-modelling basics 51 Inference or task? ■  “If the internal behavior of a function are important for explaining the behavior of the system as a whole, then one needs to define this function as a task” ■  During development: provisional inference structures ■  Function = task or inference (or transfer function)
  52. 52. Knowledge-modelling basics 52 Knowledge model vs. SE analysis model ■  “Data model” contains “data about data” ➤  = knowledge ■  Functions are described data-model independent ➤  enables reuse of reasoning functions ■  Emphasis on “internal control” ➤  strategy of reasoning process ■  Knowledge model abstracts from communication aspects
  53. 53. Knowledge-modelling basics 53 The data-function debate DATA viewpoint FUNC TION viewpoint Object-­‐Oriented  Analysis (OMT,  Booch,  ....) S tructured  Analysis (Y ourdon) CommonK ADS : function-­‐data  decoupling functional  decomposition  is  starting  point data  types  are  derived  from  DFDs static  information  structure  is  starting  point functions  are  grouped  with  the  data reuse  of  data/function  groups  ("objects") parallel  function/data  description reusable  functional  decompositions reusable  data/knowledge  types