template knowledge models l.
Skip this Video
Download Presentation
Template knowledge models

Loading in 2 Seconds...

play fullscreen
1 / 68

Template knowledge models - PowerPoint PPT Presentation

  • Uploaded on

Template knowledge models. Reusing knowledge model elements. Lessons. 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. The need for reuse.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Template knowledge models' - irina

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
template knowledge models

Template knowledge models

Reusing knowledge model elements

  • 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
the need for reuse
The need for reuse
  • prevent "re-inventing the wheel"
  • cost/time efficient
  • decreases complexity
  • quality-assurance
task template
Task template
  • reusable combination of model elements
    • (provisional) inference structure
    • typical control structure
    • typical domain schema from task point-of-view
  • specific for a task type
  • supports top-down knowledge modeling
a typology of tasks
A typology of tasks
  • range of task types is limited
    • 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”
the term system
The term “system”
  • 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)
analytic versus synthetic tasks
Analytic versus synthetic tasks
  • analytic tasks
    • system pre-exists
      • it is typically not completely "known"
    • 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
structure of template description in catalog
Structure of template description in catalog
  • General characterization
    • typical features of a task
  • Default method
    • roles, sub-functions, control structure, inference structure
  • Typical variations
    • frequently occurring refinements/changes
  • Typical domain-knowledge schema
    • assumptions about underlying domain-knowledge structure
  • establish correct class for an object
  • object should be available for inspection
    • "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
classification pruning method
Classification: pruning method
  • 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
classification method control
Classification: method control

while new-solution generate(object -> candidate) do

candidate-classes := candidate union candidate-classes;

while new-solutionspecify(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;

classification method variations
Classification: method variations
  • Limited candidate generation
  • Different forms of attribute selection
    • decision tree
    • information theory
    • user control
  • Hierarchical search through class structure
  • find decision category for a case based on domain-specific 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
assessment abstract match method
Assessment: abstract & match method
  • Abstract the case data
  • Specify the norms applicable to the case
    • 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
assessment inference structure
Assessment:inference structure














assessment method control
Assessment: method control

while new-solution abstract(case-description -> abstracted-case) do

case-description := abstracted-case;

end while

specify(abstracted-case -> norms);


select(norms -> norm);

evaluate(abstracted-case + norm -> norm-value);

evaluation-results := norm-value union evaluation-results;

until has-solution match(evaluation-results -> decision);

assessment control uml notation
Assessment control: UML notation

[more abstractions]




[no more


[match fails

[match succeeds:

no decision]

decision found]







assessment method variations
Assessment: method variations
  • norms might be case-specific
    • 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
  • find fault that causes system to malfunction
    • example: diagnosis of a copier
  • terminology:
    • complaint/symptom, hypothesis, differential, finding(s)/evidence, fault
  • nature of fault varies
    • state, chain, component
  • should have some model of system behavior
    • default method: simple causal model
  • sometimes reduced to classification task
    • direct associations between symptoms and faults
  • automation feasible in technical domains
diagnosis causal covering method
Diagnosis: causal covering method
  • 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
diagnosis method control
Diagnosis: method control

while new-solution cover(complaint -> hypothesis) do

differential := hypothesis add differential;

end while


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;

diagnosis method variations
Diagnosis: method variations
  • inclusion of abstractions
  • simulation methods
  • see literature on model-based diagnosis
    • library of Benjamins
  • analyze ongoing process to find out whether it behaves according to expectations
  • terminology:
    • parameter, norm, discrepancy, historical data
  • main features:
    • dynamic nature of the system
    • cyclic task execution
  • output "just" discrepancy => no explanation
  • often: coupling monitoring and diagnosis
    • output monitoring is input diagnosis
monitoring data driven method
Monitoring:data-driven method
  • 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
monitoring method control
Monitoring: method control


select(new-finding -> parameter)

specify(parameter -> norm);

compare(norm + finding -> difference);

classify(difference + historical-data -> discrepancy);

historical-data := finding add historical-data;

monitoring method variations
Monitoring: method variations
  • model-driven monitoring
    • system has the initiative
    • typically executed at regular points in time
    • example: software project management
  • classification function treated as task in its won right
    • apply classification method
  • add data abstraction inference
  • 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
  • Given a set of requirements, construct a system description that fulfills these requirements
ideal synthesis method
“Ideal” synthesis method
  • Operationalize requirements
    • preferences and constraints
  • Generate all possible system structures
  • Select sub-set of valid system structures
    • obey constraints
  • Order valid system structures
    • based on preferences
  • 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
configuration design
Configuration design
  • 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)
  • form of design that is well suited for automation
  • computationally demanding
configuration propose revise method
Configuration:propose & revise method
  • Simple basic loop:
    • Propose a design extension
    • Verify the new design,
    • If verification fails, revise the design
  • Specific domain-knowledge requirements
    • revise strategies
  • Method can also be used for other synthetic tasks
    • assignment with backtracking
    • skeletal planning
configuration method control
Configuration: method control

operationalize(requirements -> hard-reqs + soft-reqs);

specify(requirements -> skeletal-design);

whilenew-solution propose(skeletal-design + 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

configuration method variations
Configuration: method variations
  • Perform verification plus revision only when for all design elements a value has been proposed.
    • 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
types of configuration may require different methods
Types of configuration may require different methods
  • Parametric design
    • Assembly is largely fixed
    • Emphasis on finding parameter values that obey global constraints and adhere to preferences
    • Example: elevator design
  • Layout
    • Component parameters are fixed
    • Emphasis on constructing assembly (topological relations)
    • Example: mould configuration
  • Literature: Motta (1999), Chandrasekaran (1992)
  • create mapping between two sets of objects
    • allocation of offices to employees
    • allocation of airplanes to gates
  • mapping has to satisfy requirements and be consistent with constraints
  • terminology
    • subject, resource, allocation
  • can be seen as a “degenerative” form of configuration design
assignment method without backtracking
Assignment:method without backtracking
  • 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
    • 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
assignment method control
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


subject-set := subject-set/subject-group;

resources := resources/resource;

end while

subjects := subjects/subject-set;

end while

assignment method variations
Assignment:method variations
  • Existing allocations
    • additional input
  • subject-specific constraints and preferences
    • see synthesis and configuration-design
  • 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
  • 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
    • 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
scheduling temporal dispatching method
Scheduling:temporal dispatching method
  • 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
scheduling method control
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

scheduling method variations
Scheduling: method variations
  • Constructive versus repair method
  • Refinement often necessary
    • see scheduling literature
    • catalog of Hori (IBM Japan)
  • included for completeness
  • "construction of an abstract description of a system in order to explain or predict certain system properties or phenomena"
  • examples:
    • construction of a simulation model of nuclear accident
    • knowledge modeling itself
  • seldom automated => creative steps
    • exception: chip modeling
in applications typical task combinations
In applications: typical task combinations
  • monitoring + diagnosis
    • Production process
  • monitoring + assessment
    • Nursing task
  • diagnosis + planning
    • Troubleshooting devices
  • classification + planning
    • Military applications
comparison with o o analysis
Comparison with O-O analysis
  • Reuse of functional descriptions is not common in O-O analysis
    • notion of “functional” object
  • But: see work on design patterns
    • strategy patterns
    • templates are patterns of knowledge-intensive tasks
  • Only real leverage from reuse if the patterns are limited to restricted task types