Download
advanced knowledge modeling n.
Skip this Video
Loading SlideShow in 5 Seconds..
Advanced Knowledge Modeling PowerPoint Presentation
Download Presentation
Advanced Knowledge Modeling

Advanced Knowledge Modeling

109 Views Download Presentation
Download Presentation

Advanced Knowledge Modeling

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Advanced Knowledge Modeling Additional domain constructs Domain-knowledge sharing and reuse Catalog of inferences Flexible use of task methods

  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. Two different organizations of the disease hierarchy

  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. Viewpoint: graphical representation

  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. 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. 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. 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. Constraint rules • Rules about restrictions on a single concept • No antecedent or consequent

  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. 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. Ontology should allow for “representational promiscuity” ontology parameter constraint -expression mapping rules viewpoint knowledge base B knowledge base A parameter(cab.weight) parameter(safety.weight) cab.weight + safety.weight parameter(car.weight) rewritten as = car.weight: constraint-expression( cab.weight + safety.weight cab.weight < 500: = car.weight) constraint-expression( cab.weight < 500)

  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. 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. 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. Ontology specification • Many different languages • KIF • Ontolingua • Express • LOOM • UML • ...... • Common basis • Class (concept) • Subclass with inheritance • Relation (slot)

  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. 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. 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) • Multiple subclasses • Reified relations • Import/export mechanism • Sloppy class/instance distinction • (Second-order) constraint language • Aggregation

  21. Art & Architecture Thesaurus Used for indexing stolen art objects in European police databases

  22. The AAT ontology description object universe instance of 1+ 1+ description dimension class of object type object class in dimension 1+ value set 1+ 1+ has descriptor descriptor descriptor value set descriptor 1+ value has feature value class constraint

  23. Document fragment ontologies: instructional

  24. Domain ontology of a traffic light control system

  25. Two ontologies of document fragments

  26. Ontology for e-commerce

  27. Top-level categories:many different proposals Chandrasekaran et al. (1999)

  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. 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. 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. 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 tasktypes: 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. 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. 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. Dealing with dynamic method selection

  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