Template knowledge models Reusing knowledge model elements Template

Template knowledge models Reusing knowledge model elements Template knowledge models

Lessons n n n 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 Template knowledge models 2

The need for reuse n n prevent "re-inventing the wheel" cost/time efficient decreases complexity quality-assurance Template knowledge models 3

Task template n reusable combination of model elements ä ä ä n n (provisional) inference structure typical control structure typical domain schema from task point-of-view specific for a task type supports top-down knowledge modeling Template knowledge models 4

A typology of tasks n range of task types is limited ä n n n 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” Template knowledge models 5

The term “system” n n 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) Template knowledge models 6

Analytic versus synthetic tasks n analytic tasks ä system pre-exists – it is typically not completely "known" ä ä n 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 Template knowledge models 7

Task hierarchy Template knowledge models 8

Structure of template description in catalog n General characterization ä n Default method ä n roles, sub-functions, control structure, inference structure Typical variations ä n typical features of a task frequently occurring refinements/changes Typical domain-knowledge schema ä assumptions about underlying domain-knowledge structure Template knowledge models 9

Classification n n establish correct class for an object should be available for inspection ä n n "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 Template knowledge models 10

Classification: pruning method n n 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 Template knowledge models 11

Classification: inference structure Template knowledge models 12

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; Template knowledge models 13

Classification: method variations n n Limited candidate generation Different forms of attribute selection ä ä ä n decision tree information theory user control Hierarchical search through class structure Template knowledge models 14

Classification: domain schema Template knowledge models 15

Rock classification Template knowledge models 16

Nested classification Template knowledge models 17

Rock classification prototype Template knowledge models 18

Assessment n n find decision category for a case based on domainspecific 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 Template knowledge models 19

Assessment: abstract & match method n n Abstract the case data Specify the norms applicable to the case ä n n 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 Template knowledge models 20

Assessment: inference structure case abstracted case specify norms evaluate decision Template knowledge models match select norm value 21

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); Template knowledge models 22

Assessment control: UML notation [more abstractions] abstract specify norms [no more abstractions] [match fails no decision] [match succeeds: decision found] select norm evaluate norm Template knowledge models match decision 23

Assessment: method variations n norms might be case-specific ä n n 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 Template knowledge models 24

Assessment: domain schema Template knowledge models 25

Claim handling for unemployment benefits Template knowledge models 26

Decision rules for claim handling Template knowledge models 27

Diagnosis n find fault that causes system to malfunction ä n terminology: ä n default method: simple causal model sometimes reduced to classification task ä n state, chain, component should have some model of system behavior ä n complaint/symptom, hypothesis, differential, finding(s)/evidence, fault nature of fault varies ä n example: diagnosis of a copier direct associations between symptoms and faults automation feasible in technical domains Template knowledge models 28

Diagnosis: causal covering method n n n 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 Template knowledge models 29

Diagnosis: inference structure Template knowledge models 30

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; Template knowledge models 31

Diagnosis: method variations n n n inclusion of abstractions simulation methods see literature on model-based diagnosis ä library of Benjamins Template knowledge models 32

Diagnosis: domain schema Template knowledge models 33

Monitoring n n analyze ongoing process to find out whether it behaves according to expectations terminology: ä n main features: ä ä n n parameter, norm, discrepancy, historical data dynamic nature of the system cyclic task execution output "just" discrepancy => no explanation often: coupling monitoring and diagnosis ä output monitoring is input diagnosis Template knowledge models 34

Monitoring: data-driven method n n 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 Template knowledge models 35

Monitoring: inference structure Template knowledge models 36

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; Template knowledge models 37

Monitoring: method variations n model-driven monitoring ä ä ä n classification function treated as task in its won right ä n system has the initiative typically executed at regular points in time example: software project management apply classification method add data abstraction inference Template knowledge models 38

Prediction n n n 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 Template knowledge models 39

Synthesis n Given a set of requirements, construct a system description that fulfills these requirements Template knowledge models 40

“Ideal” synthesis method n Operationalize requirements ä n n Generate all possible system structures Select sub-set of valid system structures ä n preferences and constraints obey constraints Order valid system structures ä based on preferences Template knowledge models 41

Synthesis: inference structure Template knowledge models 42

Design n n n 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 Template knowledge models 43

Configuration design n 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) n n form of design that is well suited for automation computationally demanding Template knowledge models 44

Elevator configuration: knowledge base reuse Template knowledge models 45

Configuration: propose & revise method n Simple basic loop: ä ä ä n Specific domain-knowledge requirements ä n Propose a design extension Verify the new design, If verification fails, revise the design revise strategies Method can also be used for other synthetic tasks ä ä assignment with backtracking skeletal planning Template knowledge models 46

Configuration: method decomposition Template knowledge models 47

Configuration: method control operationalize(requirements -> hard-reqs + soft-reqs); specify(requirements -> skeletal-design); while new-solution propose(skeletal-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 Template knowledge models 48

Configuration: method variations n Perform verification plus revision only when for all design elements a value has been proposed. ä n 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 Template knowledge models 49

Configuration: domain schema Template knowledge models 50

Types of configuration may require different methods n Parametric design ä ä ä n Layout ä ä ä n Assembly is largely fixed Emphasis on finding parameter values that obey global constraints and adhere to preferences Example: elevator design Component parameters are fixed Emphasis on constructing assembly (topological relations) Example: mould configuration Literature: Motta (1999), Chandrasekaran (1992) Template knowledge models 51

Assignment n create mapping between two sets of objects ä ä n n mapping has to satisfy requirements and be consistent with constraints terminology ä n allocation of offices to employees allocation of airplanes to gates subject, resource, allocation can be seen as a “degenerative” form of configuration design Template knowledge models 52

Assignment: method without backtracking n n 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 ä n n 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 Template knowledge models 53

Assignment: inference structure Template knowledge models 54

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 Template knowledge models 55

Assignment: method variations n Existing allocations ä n additional input subject-specific constraints and preferences ä see synthesis and configuration-design Template knowledge models 56

Planning n n n 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 Template knowledge models 57

Planning method Template knowledge models 58

Scheduling n 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 ä n n n 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 Template knowledge models 59

Scheduling: temporal dispatching method n n n 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 Template knowledge models 60

Scheduling: inference structure Template knowledge models 61

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 Template knowledge models 62

Scheduling: method variations n n Constructive versus repair method Refinement often necessary ä ä see scheduling literature catalog of Hori (IBM Japan) Template knowledge models 63

Scheduling: typical domain schema Template knowledge models 64

Modeling n n n included for completeness "construction of an abstract description of a system in order to explain or predict certain system properties or phenomena" examples: ä ä n construction of a simulation model of nuclear accident knowledge modeling itself seldom automated => creative steps ä exception: chip modeling Template knowledge models 65

In applications: typical task combinations n monitoring + diagnosis ä n monitoring + assessment ä n Nursing task diagnosis + planning ä n Production process Troubleshooting devices classification + planning ä Military applications Template knowledge models 66

Example: apple-pest management Template knowledge models 67

Comparison with O-O analysis n Reuse of functional descriptions is not common in OO analysis ä n But: see work on design patterns ä ä n notion of “functional” object strategy patterns templates are patterns of knowledge-intensive tasks Only real leverage from reuse if the patterns are limited to restricted task types Template knowledge models 68