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