Difficulty acquiring knowledge

For a system of rules, it is estimated that using interviews, we can generate “between two and five rules per day”. The causes given to explain this are as follows:

1. The engineer is not a specialist in the area of expertise, but he must learn a minimum knowledge base to communicate with the expert.

2. The expert does not generally think in terms of great principles but in terms of typical situations and classic events.

3. It is already difficult to develop a framework (notations) to express knowledge, even on paper.

For this reason, many works present methods for acquiring and modeling knowledge.

KADS (Knowledge Analysis and Design System)

Kads is a development methodology for knowledge-based systems developed in Amsterdam in the early 1990s.

- KADS is intended to be a methodology for the study, construction, use and maintenance of knowledge systems.

- The principle of rapid implementation of a prototype is rejected (“superficial” knowledge, lack of structure, maintenance), seeking instead to conceptualize and model the field completely before undertaking an implementation.

- The approach must make it possible to store the expert's knowledge independently of the expert system constructed.

CommonKADS, developed a few years later, takes and extends KADS.

CommKads Models 


Knowledge model

It describes, in an implementation-independent manner, the knowledge used in a knowledge-intensive knowledge task.


Domain knowledge consists of two parts:

1. a domain schema, which schematically describes types of knowledge and information using constructs (comparable to a data model). We define in the diagram:

. concepts (classes), in hierarchical form;

. attributes (for concepts);

. relationships between concepts;

. types of rules (relationships between values): 

  <antecedent> <connection-symbol> <consequent>

2. a static knowledge base, which applies to the domain diagram.

Example. Domain schema 



Example. Knowledge Base 

KNOWLEDGE-BASE car-network; 

  USES:     state-dependency FROM car-diagnosis-schema,

              manifestation-rule FROM car-diagnosis-schema;  EXPRESSIONS:   

               /* state dependencies */  

            fuse.status = blown CAUSES power.status = off;

            battery.status = low  CAUSES power.status = off;      ….

  /* manifestation rules */   

  fuse.status = blown HAS-MANIFESTATION

  fuse-inspection.value = broken;  

   battery.status = low HAS-MANIFESTATION

  battery-dial.value = zero;  …..

END KNOWLEDGE-BASE car-network;

Inference Knowledge 

Break down the reasoning to the lowest possible level (you must be able to explain each rule). Specify the form of the inference.

This knowledge is intended to be independent of domain knowledge, and reusable for different tasks (use generic names as much as possible).

To ensure knowledge independence, we use “knowledge roles”, a generic name that describes the role of knowledge in inference, and which is associated with a particular type in the domain.

Example.



Transfert Functions

In addition to inferences, we have “transfer functions” to represent the exchange of information between the system and other agents. Their names are standard.



Task Knowledge

1. description of the goals of the task;

2. description of the strategies used to resolve these goals;

3. decomposition of the task into subtasks.

Example.




Model Library

CommonKADS provides a Model Library indexed by task type.

Tasks Classification

We essentially distinguish between analysis tasks and synthesis tasks.

In an analysis task:

- the system studied already exists:

- we seek to characterize the system based on data on it. 

Examples of tasks :the classification ; assessment: diagnosis; the supervision ; the prediction.

In a Synthesis task:

- the system does not yet exist;

- we seek to build the system from queries on it.

Examples of tasks : design (with a subtask, configuration); modeling ; Planning ; scheduling; distribution.

Typical models

For each task, we give:

- a “provisional” inference structure

- a typical control structure (“algorithm”)

- a typical domain diagram

The classification

Archetype of analysis functions, one of the simplest with many methods. The object to be classified can be studied at your leisure (the user can be asked for attributes).
Example : classification of mushrooms


Method: Principle by elimination

- production of all available classes;

- choice of an attribute;

- obtaining the value of the attribute;

- elimination of classes not corresponding to the value.

Method variations

- Limit the generation of candidates (expression of sets of classes, heuristics);
- select the attributes to request (decision trees, etc.);
- exploration through a possible class structure.
Domain Schema


Assessement task

Decision to be made on a given case, using specific criteria. The number of decisions is limited, the criteria are clearly defined.

Examples : examination of a bank loan file, or the allocation of social assistance.


Method: abstraction – matching

- Abstract the case (example: “income: 1500 Euros” becomes “income: between 1000 and 2000 Euros”). Repeat the process.
- take all the criteria adapted to the case;
- select a particular criterion;
- confront him with the case;
- if this does not lead to a decision, repeat the selection step.

Abstraction – matching Method Inferences



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);

Variations of the abstraction-matching method

- Case abstraction is not always necessary.
- Standards selection strategies

Domain Schema



Modifié le: samedi 22 juin 2024, 10:49