Knowledge Modeling
3.2 Knowledge Modeling, Knowledge Tasks, and Task Templates
The success of the first expert systems such as DENDRAL [Feigenbaum et al., 1971] and MYCIN [Shortliffe, 1976] contributed towards the increase of interest of the large AI research community in knowledge modeling and representation.
In the successive years, researchers advanced many theories and frameworks for building knowledge-based systems. CommonKADS is such a methodology, built upon the principles of modeling those aspects of knowledge that serve to the goals
1A part of this chapter has been previously published in the EJKM journal [Mustafaraj et al., 2006b]
of knowledge-based systems. The discussion that follows is entirely based on the CommonKADS methodology.
3.2.1 Knowledge Modeling
A knowledge model can be regarded as composed of three components: domain knowledge, inference knowledge, and task knowledge. Figure 3.1 schematically shows the relations among these three components. Each of these components can be decomposed further into a series of smaller knowledge constructs. Concretely, the domain knowledge component consists of the domain schema(s) and the knowledge base(s). A domain schema itself includes concepts, relations, and rule types (com-monly known as domain knowledge types); a knowledge base contains instances of these knowledge types.
Base
Domain Schema role mapping
define control over
Task & Methods
Inference Structure
Knowledge
Figure 3.1: The three layers of a knowledge model: task knowledge, inference knowledge, and domain knowledge
The second component, inference knowledge, contains inferences, knowledge roles, and transfer functions. The construct of knowledge roles is particularly inter-esting, because it is the link connecting domain knowledge constructs (like concepts and rules) to the inferences (primitive functions that perform reasoning tasks on the data mapped to the knowledge roles).
The last component, task knowledge, consists of the task —also known as the
“what” view (what needs to be done) and the task method —the “how” view (how is it done) on the reasoning task. A task is understood as a knowledge-intensive, reasoning process that usually is iteratively decomposed into smaller tasks (until primitive functions like inferences are encountered), whereas the task method defines how this decomposition is realized and carried out.
The four following figures show concrete examples of the three components, reproduced from examples published in [Schreiber et al.,1999].
blown}
Figure 3.2: Domain knowledge component: Graphical Domain Schema Concretely, Figure 3.2 shows a domain schema for an application of car diag-nosis, where several domain concepts (such as fuel tank, battery, or fuse) and their relations are depicted. Then, in Figure3.3we find an example of a knowledge base related to the domain schema of Figure3.2. The knowledge base contains the causal relationships among the different instances of domain concepts. Further, Figure3.4 shows an example of mapping domain concepts to knowledge roles (e.g., visible car state to complaint or invisible car state to hypothesis). And finally, Figure 3.5
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;
power.status = off CAUSES
engine.behavior.status = does-not-start;
fuel-tank.status = empty CAUSES gas-in-engine.status = false;
gas-in-engine.status = false CAUSES
engine.behavior.status = does-not-start;
gas-in-engine.status = false CAUSES engine.behavior.status = stops;
/* manifestation rules */
fuse.status = blown HAS-MANIFESTATION fuse-inspection.value = broken;
battery.status = low HAS-MANIFESTATION battery-dial.value = zero;
fuel-tank.status = empty HAS-MANIFESTATION gas-dial.value = zero;
END KNOWLEDGE-BASE car-network;
Figure 3.3: Domain knowledge component: Knowledge Base
indicates a possible way of decomposing the task of diagnosis in task methods.
3.2.2 Knowledge Tasks
Knowledge tasks (or knowledge-intensive tasks) are those tasks in which knowledge plays the primary role. Indeed, the most famous of knowledge tasks, diagnosis (from Greek: dia=by, gnosis=knowledge) literally means “to arrive at a conclusion by knowledge”. During many years of research in cognitive science and knowledge engineering, a categorization of task types has emerged, which is shown in Figure3.6.
The division in analytic and synthetic tasks is based on the nature of the object in focus.
If we consider as system the object to which a task is being applied, then for analytic tasks the system preexists; while for synthetic tasks it does not, and the goal of these tasks is to produce a system description.
The further subcategorization of analytic and synthetic tasks in Figure 3.6 is based on the problem type solved by the task. In the literature, the notions of prob-lem type and task are used interchangeably. For example, [Lenz et al.,1998] discuss analytic problem solving in the framework of CBR. Because CBR is a problem solv-ing methodology and tasks are strategies for solvsolv-ing problems, many denotations
static role
complaint cover hypothesis
causal model
state dependency visible
car state
invisible car state inference−domain
mapping
inference−domain mapping inference−domain
mapping
inference knowledge
domain knowledge
dynamic output role dynamic input role inference
concept rule type concept
Figure 3.4: An example of mapping between domain knowledge and inference knowledge through knowledge roles
task
through generate−and−test
cover
predict compare
obtain
inferences transfer function
task method
diagnosis diagnosis
decomposition
Figure 3.5: An example of a schematic representation of task knowledge
diagnosis prediction
classification design planning assignment
configuration design knowledge−
intensive task
analytic task
synthetic task
assessment monitoring modelling scheduling
Figure 3.6: A hierarchy of knowledge task types
exist that highlight the connections between CBR and task type, such as case-based design [Leake and Wilson, 2001; B¨orner, 1998], case-based diagnosis [Lenz et al., 1998], case-based planning [Bergmann et al., 1998], etc. Two of the tasks we are interested in, diagnosis and monitoring, are discussed in detail in the next sections.
3.2.3 Task Templates
There is always a goal behind a reasoning process, or actually, it is the goal of achieving something that we want, that guides the reasoning process. The knowl-edge for describing such goals and the strategy for realizing them is referred in CommonKADS as task knowledge (as mentioned in Section 3.2.1). As we saw, the task (goal of reasoning) is tightly bound to the problem that is faced. Meanwhile, the strategy for achieving the goal (task method) can be regarded as an iterative decomposition of the task into other sub-tasks until arriving at simple inferences and transfer functions as those seen in Figure 3.4 and Figure 3.5. Inferences and transfer functions are routines that need input and output data. Such input and output data will usually depend on the nature of the task. Therefore, it makes sense to have a general vocabulary, which, independently of specific domain vocabulary, refers to the input and output data that are processed during task execution.
In the CommonKADS methodology, the vocabulary needed to describe task knowledge is organized in task templates. In the following, task templates for
two analytic tasks that are important to the goals of this thesis (monitoring and diagnosis) are presented in Figure 3.7and Figure 3.8.
DIAGNOSIS
Goal Find the fault that causes a system to malfunction.
Typical Example Diagnosis of a technical device, such as a copier.
Terminology (Knowledge Roles)
Complaint/symptom: the data that initiate a diag-nostic process.
Hypothesis: a potential solution (thus a fault).
Differential: the active set of hypotheses.
Finding(s)/evidence: additional data about the sys-tem being diagnosed.
Fault: the solution found by the diagnostic reasoning process.
Input Symptoms and/or complaints.
Output Fault(s) plus the evidence gathered for the fault(s).
Features In principle, a diagnosis task should always have some model of the behavior of the system being diagnosed. An example could be a casual model of system behavior.
Figure 3.7: General characterization for the Diagnosis task template
Clearly, these two templates are very abstract at this level of description; nev-ertheless, the given details are sufficient for starting task modeling in any desired domain. Still, problems might arise from the fact that domain experts do not con-ceptualize their domains using the constructs described here, so that considerable efforts are needed from the knowledge engineers to establish a mapping between modeling constructs and real sources of knowledge for a given application2.
In the next section, we analyze a document, which would be usually used by a knowledge engineer to create a task model for an application, and point out the difficulties of such an undertaking. We also question the feasibility of creating for-mal representations as those promoted by many knowledge engineering approaches for knowledge systems. In our regard, knowledge systems that perform automatic deductive reasoning are difficult to build and maintain and do not offer flexibility in problem-solving situations. For that reason, we propose and develop a case-based reasoning approach in this thesis, which offers the needed flexibility, as we will demonstrate in further chapters. For the moment, we continue this chapter with the analysis of available knowledge sources for knowledge modeling.
2An application is considered as the process of applying a given task in a given domain.
MONITORING
Goal Analyze an ongoing process to find out whether it behaves according to expectations.
Typical Example Monitoring an industrial plant.
Terminology (Knowledge Roles)
Parameter: an entity for which the current value can be relevant for the purpose of detecting abnormal be-havior.
Norm: the expected value or value range of parameter in the case of normal behavior.
Discrepancy: this indicates abnormal behavior of the system being monitored; sometimes it is an ordered list of the potential discrepancies, e.g., small-deviation, medium-deviation, etc.
Input Historical data about the system being monitored, usually gathered during prior monitoring cycles.
Output The discrepancy found (if any).
Features The crucial distinction between monitoring and diagnosis lies in the nature of the output. Monitoring “just” ob-serves a discrepancy, without any exploration of the cause of fault underlying the deviant system behavior. However, in many domains monitoring and diagnosis are tightly cou-pled tasks: when monitoring leads to a discrepancy, a di-agnosis task is started using the monitoring information as its input.
Figure 3.8: General characterization for the Monitoring task template