Advanced knowledge modelling
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Advanced knowledge modelling

  • 110 views
Uploaded on

Ch. 13 of the CommonKADS textbook

Ch. 13 of the CommonKADS textbook

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
110
On Slideshare
104
From Embeds
6
Number of Embeds
1

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 6

http://commonkads.org 6

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Advanced Knowledge Modeling Additional domain constructs Domain-knowledge sharing and reuse Catalog of inferences Flexible use of task methods
  • 2. Advanced knowledge modelling 2 Viewpoints ■  need for multiple sub-type hierarchies ■  sub-type-of = "natural" sub-type dimension ➤  typically complete and total ■  other sub-type dimensions: viewpoint ➤  represent additional ways of "viewing" a certain concept ■  similar to UML "dimension" ■  helps to introduce new vocabulary through multiple specialization ("inheritance")
  • 3. Advanced knowledge modelling 3 Two different organizations of the disease hierarchy infection meningitis pneumonia bacterial pneumonia acute  viral pneumonia chronic  viral pneumonia viral pneumonia infection meningitis pneumonia chronic pneumonia acute  viral pneumonia acute  bacterial pneumonia acute pneumonia
  • 4. Advanced knowledge modelling 4 Viewpoint specification concept infection; super-type-of: meningitis, pneumonia; viewpoints: time-factor: acute-infection, chronic-infection; causal-agent: viral-infection, bacterial-infection; end concept infection; concept acute-viral-meningitis; sub-type-of: meningitis, acute-infection, viral-infection; end concept acute-viral-meningitis;
  • 5. Advanced knowledge modelling 5 Viewpoint: graphical representation infection acute infection chronic infection viral infection bacterial infection mening itispneumonia acute  viral mening itis causal  agent time  factor
  • 6. Advanced knowledge modelling 6 Expressions and Formulae ■  need for expressing mathematical models or logical formulae ■  imported language for this purpose ➤  Neutral Model Format (NMF) ■  used in technical domains ■  see appendix
  • 7. Advanced knowledge modelling 7 Rule instance format ■  See appendix for semi-formal language ■  Guideline: use what you are comfortable with ■  May use (semi-)operational format, but for conceptual purposes! ■  Implicit assumption: universal quantification ➤  person.income < 10.000 suggests loan.amount < 1.000 ➤  “for all instances of person with an income less than 10.00 the amount of the loan should not exceed 1.000
  • 8. Advanced knowledge modelling 8 Inquisitive versus formal rule representation Intuitive rule representation residence-application.applicant.household-type = single-person residence-application.applicant.age-category = up-to-22 residence-application.applicant.income < 28000 residence-application.residence.rent < 545 INDICATES rent-fits-income.truth-value = true; Formal rule representation FORALL x:residence-application x.applicant.household-type = single-person x.applicant.age-category = up-to-22 x.applicant.income < 28000 x,residence.rent < 545 INDICATES rent-fits-income.truth-value = true;
  • 9. Advanced knowledge modelling 9 Using variables in rules to eliminate ambiguities /* ambiguous rule */ employee.smoker = true AND employee.smoker = false IMPLIES-CONFLICT smoker-and-non-smoker.truth-value =true; /* use of variables to remove the ambiguity */ VAR x, y: employee; x.smoker = true AND y.smoker = false IMPLIES-CONFLICT smoker-and-non-smoker.truth-value =true;
  • 10. Advanced knowledge modelling 10 Constraint rules ■  Rules about restrictions on a single concept ■  No antecedent or consequent component component constraint R ULE -­‐T Y P E  component-­‐constraint;                C ONS T R AINT :                                                  component; E ND  R ULE -­‐T Y P E  component-­‐constraint; E xample  constraints    (car  is  a  component): car.weight  <  500  kg car.length  <  5.5  m
  • 11. Advanced knowledge modelling 11 Knowledge sharing and reuse: why? ■  KE is costly and time-consuming ➤  general reuse rationale: quality, etc ■  Distributed systems ➤  knowledge base partitioned over different locations ■  Common vocabulary definition ➤  Internet search, document indexing, …. ➤  Cf. thesauri, natural language processing ■  Central notion: “ontology”
  • 12. Advanced knowledge modelling 12 The notion of ontology ■  Ontology = explicit specification of a shared conceptualization that holds in a particular context” (several authors) ■  Captures a viewpoint an a domain: ➤  Taxonomies of species ➤  Physical, functional, & behavioral system descriptions ➤  Task perspective: instruction, planning
  • 13. Advanced knowledge modelling 13 Ontology should allow for “representational promiscuity” ontology parameter constraint -expression knowledge base A cab.weight + safety.weight = car.weight: cab.weight < 500: knowledge base B parameter(cab.weight) parameter(safety.weight) parameter(car.weight) constraint-expression( cab.weight + safety.weight = car.weight) constraint-expression( cab.weight < 500) rewritten as viewpoint mapping rules
  • 14. Advanced knowledge modelling 14 Ontology types ■  Domain-oriented ➤  Domain-specific –  Medicine => cardiology => rhythm disorders –  traffic light control system ➤  Domain generalizations –  components, organs, documents ■  Task-oriented ➤  Task-specific –  configuration design, instruction, planning ➤  Task generalizations –  problems solving, e.g. UPML ■  Generic ontologies –  “Top-level categories” –  Units and dimensions
  • 15. Advanced knowledge modelling 15 Using ontologies ■  Ontologies needed for an application are typically a mix of several ontology types ➤  Technical manuals –  Device terminology: traffic light system –  Document structure and syntax –  Instructional categories ➤  E-commerce ■  Raises need for ➤  Modularization ➤  Integration –  Import/export –  Mapping
  • 16. Advanced knowledge modelling 16 Domain standards and vocabularies as ontologies ■  Example: Art and Architecture Thesaurus (AAT) ■  Contain ontological information ➤  AAT: structure of the hierarchy ■  Ontology needs to be “extracted” ➤  Not explicit ■  Can be made available as an ontology ➤  With help of some mapping formalism ■  Lists of domain terms are sometimes also called “ontologies” ➤  Implies a weaker notion of ontology ➤  Scope typically much broader than a specific application domain ➤  Example: domain glossaries, WordNet ➤  Contain some meta information: hyponyms, synonyms, text
  • 17. Advanced knowledge modelling 17 Ontology specification ■  Many different languages ➤  KIF ➤  Ontolingua ➤  Express ➤  LOOM ➤  UML ➤  ...... ■  Common basis ➤  Class (concept) ➤  Subclass with inheritance ➤  Relation (slot)
  • 18. Advanced knowledge modelling 18 Additional expressivity (1 of 2) ■  Multiple subclasses ■  Aggregation ➤  Built-in part-whole representation ■  Relation-attribute distinction ➤  “Attribute” is a relation/slot that points to a data type ■  Treating relations as classes ➤  Sub relations ➤  Reified relations (e.g., UML “association class”) ■  Constraint language ➤  First-order logic ➤  Second-order statements
  • 19. Advanced knowledge modelling 19 Additional expressivity (2 of 2) ■  Class/subclass semantics ➤  Primitive vs. defined classes ➤  Complete/partial, disjoint/overlapping subclasses ■  Set of basic data types ■  Modularity ➤  Import/export of an ontology ■  Ontology mapping ➤  Renaming ontological elements ➤  Transforming ontological elements ■  Sloppy class/instance distinction ➤  Class-level attributes/relations ➤  Meta classes
  • 20. Advanced knowledge modelling 20 Priority list for expressivity ■  Depends on goal: ➤  Deductive capability: “limit to first-order logic” ➤  Maximal content: “as much as (pragmatically) possible” ■  My priority list (from a “maximal-content” representative) 1.  Multiple subclasses 2.  Reified relations 3.  Import/export mechanism 4.  Sloppy class/instance distinction 5.  (Second-order) constraint language 6.  Aggregation
  • 21. Advanced knowledge modelling 21 Art & Architecture Thesaurus Used for indexing stolen art objects in European police databases
  • 22. Advanced knowledge modelling 22 The AAT ontology description universe description dimension descriptor value set value descriptor value object object type object class class constraint has feature descriptor value set in dimension instance of class of has descriptor 1+ 1+ 1+ 1+ 1+ 1+
  • 23. Advanced knowledge modelling 23 Document fragment ontologies: instructional
  • 24. Advanced knowledge modelling 24 Domain ontology of a traffic light control system
  • 25. Advanced knowledge modelling 25 Two ontologies of document fragments
  • 26. Advanced knowledge modelling 26 Ontology for e-commerce
  • 27. Advanced knowledge modelling 27 Top-level categories: many different proposals Chandrasekaran et al. (1999)
  • 28. Advanced knowledge modelling 28 Catalog of inferences ■  Inferences are key elements of knowledge models ➤  building blocks ■  No theory of inference types ➤  see literature ■  CommonKADS: catalog of inferences used in practice ➤  guideline: maintain your own catalog
  • 29. Advanced knowledge modelling 29 Catalog structure ■  Inference name ■  Operation ➤  input/output features ■  Example usage ■  Static knowledge ➤  features of domain knowledge required ■  Typical task types ➤  in what kind of tasks can one expect this inference
  • 30. Advanced knowledge modelling 30 Catalog structure (continued) ■  Used in template ➤  reference to template in the CK book ■  Control behavior ➤  does it always produce a solution? ➤  can it produce multiple solutions? ■  Computation methods ➤  typical algorithms for realizing the inference ■  Remarks
  • 31. Advanced knowledge modelling 31 Inference “abstract” ■  Operation: input =data set, output= new given ■  Example: medical diagnosis: temperature > 38 degrees is abstracted to “fever” ■  Static knowledge: abstraction rules, sub-type hierarchy ■  Typical task types: mainly analytic tasks ■  Operational behavior: may succeed more than once. ■  Computational methods: Forward reasoning, generalization ■  Remarks:. Make sure to add any abstraction found to the data set to allow for chained abstraction.
  • 32. Advanced knowledge modelling 32 Inference “cover” ■  Operation: given some effect, derive a system state that could have caused it ■  Example: cover complaints about a car to derive potential faults. ■  Static knowledge: uses some sort of behavioral model of the system being diagnosed. A causal network is most common. e. ■  Typical task types: specific for diagnosis. ■  Control behavior: produces multiple solutions for same input. ■  Computational methods: abductive methods, ranging from simple to complex, depending on nature of diagnostic method ■  Remarks: cover is an example of a task-specific inference. Its use is much more restricted than, for example, the select inference.
  • 33. Advanced knowledge modelling 33 Multiple methods for a task ■  Not always possible to fix the choice of a method for a task ➤  e.g. choice depends on availability of certain data ■  Therefore: need to model dynamic method selection ■  Work-around in CommonKADS ➤  introduce method-selection task
  • 34. Advanced knowledge modelling 34 Dealing with dynamic method selection associative generation generate hypothesis model-­‐based generation generation strategy heuristic match causal covering generate hypothesis causal covering single  method for  hypothesis generation work-­‐around  for   multiple  methods   for  the  same  task obtain nature  of  data
  • 35. Advanced knowledge modelling 35 Strategic knowledge ■  Knowledge about how to combine tasks to reach a goal ➤  e.g. diagnosis + planning ■  If complex: model as separate reasoning process! ➤  meta-level planning task