Generic Tasks - Computer Science and Engineering Department

Generic Tasks 1
Generic Tasks
Ihab M. Amer
Graduate Student
Department of Computer Science, AUC, Cairo, Egypt
Introduction
The level of abstraction of much of the work in knowledge-based
systems (the rule, frame, and logic level) is too low to provide a rich enough
vocabulary for knowledge and control. It assumed that there is something
called domain knowledge that needs to be acquired quite independent of the
problems one might wish to solve, so it did not distinguish between different
types of knowledge-based reasoning. This contradicts the interaction
problem that states that “representing knowledge for the purpose of solving
some problem is strongly affected by the nature of the problem and by the
inference strategy to be applied to the knowledge.”
The shortage in these systems encouraged scientists to present a
higher level methodology in KBS named as Generic Tasks (GT). The
relationship of the constructs at the generic task level to the rule-frame-logic
level is analogous to that between high-level programming languages and
assembly languages in computer science.
Generic Tasks
1.
Definition
Generic tasks are simply, basic combinations of knowledge
structures and inference strategies that are powerful for dealing with certain
kinds of problems.
Generic Tasks 2
2. Main Concept
The appearance of generic tasks is considered to be a good step in
satisfying the interaction problem, since each problem type has a distinct
strategy type that uses a distinct knowledge type to solve it.
Notice here that we used the general term “type” to illustrate the
generality of GTs, since the problem is passed to the GT so that if it matches
its function, then the GT provides a knowledge representation and an
inference strategy that can be used to solve the problem. This is shown in
the following figure.
3.
Some GTs and Their Specs
There are several types of generic tasks. They are developed
for problems that may frequently appear and need solution. Here, we
briefly describe some of them in order to recognize the importance
of the GT concept.
Generic Tasks 3
3.1.
Hierarchical Classification
Input: Given a situation description in terms of features.
Output: Classify it as specifically as possible, in a classification hierarchy,
determining what categories or hypotheses apply to the situation.
Inference and Control: The establish-refine strategy specifies that when
a hypotheses is confirmed or likely (the establish part), its subhypotheses
(children of the node) should be considered (the refine part). Additional
knowledge may specify how refinement is performed, e.g. to consider
common hypotheses before rarer ones. If a hypotheses is rejected or ruledout, then its subhypotheses are also ruled-out.
Example Use: Medical diagnosis can be often viewed partly as a
classification problem.
3.2.
GT Hypothesis Matching
Input: Given a concept (a hypothesis) and a set of data (features) that
describe the problem state.
Output: Decide how well the concept matches the situation. The task is a
form of recognition.
Inference and Control: At each level, a degree of confidence in the
presence of a feature is computed from the features that constitute evidence
for it, and this is performed recursively until a degree of confidence for the
concept is computed. The basic theory is that recognition of a complex
concept is performed by hierarchically computing intermediate abstractions
from raw data.
Example Use: Recognition can be performed by means of this strategy.
e.g. the concept may be a disease and the data may be the patient data
relevant to the disease, and we wish to know what the likelihood of the
disease is.
3.3.
GT Abductive Hypothesis Assembly
Input: Given a situation description and a set of hypotheses each explaining
some aspects of the situation and each with some plausibility value.
Generic Tasks 4
Output: Construct a composite hypothesis that is the best explanation of
the situation.
Inference and Control: Assembly and criticism alternate. At each stage
during assembly the problem solving is driven by an attempt to explain the
most significant datum remaining unexplained.
Example Use: This Task is a diagnostic subtask in diagnostic reasoning as
well as in theory formation in science.
4.
Generic Task Tools
Of course researchers needed tools to watch the effect of using GTs
in problem solving. This has pushed them to release some versions for
different GT tools. Here we are going to mention some of them. For
example, Bylander and Mittal developed a tool called CSRL (Conceptual
Structures Representation Language) in 1986 as a tool for the hierarchical
classification GT. In the same year, Johnson developed his HYPER
(HYPothethes matchER), which as the name implies works as a generic tool
for the hypotheses matching problem. We also have for the abductive
hypotheses assembly a tool that was developed by Punch, Tanner and
Josephson in 1986 called PEIRCE that was named after C. B. Peirce, who
first described the form of inference known as abduction.
5.
GTs as Building Blocks
In the previous topics, we have described each of the common GTs
individually. This was just to overcome any confusion between them. But
actually what happens in the real life while solving complicated problems is
something else. Integration between all of these GTs happens in order to
solve the problem. So complex knowledge-based reasoning tasks can often
be decomposed into a number of GTs (imagine each of them as a building
block), each associated with certain types of knowledge and a family of
control strategy. At each stage in the reasoning, the system will engage in
one of the GTs, depending upon the knowledge available and the state of
problem solving. Actually if a certain GT needs information which can be
available by another one, then it may call it and use its results in a process
Generic Tasks 5
similar to what happens in modular programming where we find functions
calling each other.
This pushed scientists to develop what we call toolsets, which helps
one to build expert systems by using higher level building blocks. Fafner is
a release of an integrated toolset, which is available for research use.
Diagnosis is a problem of finding a cause or set of causes that “best
explain” a set of observations of a system, some of them indicating
behavioral abnormality.
The following figure illustrates how integration between various
GTs can solve a diagnosis problem.
Generic Tasks 6
Conclusion
After the discovery of GTs, solution to different kinds of problems
became much easier. For example, to solve a problem, a knowledge
engineer needs only choose a GT that is best suited for performing a
particular function, or can use different GTs for performing the same
function, or can use a combination of them. So, GT facilitates knowledge
acquisition because once the KE selects the GT that he will use, his
orientation while collecting knowledge will be close to that of the GT (GT
proposes a methodology that helps in analysis, design, and construction of a
practical knowledge system).
As expected, GTs have some drawbacks, the fact that pushes the
wheel of science forward. Its high granularity obliges the designers whether
to use a GT as it is or not to use it at all. This encouraged scientists to search
for other techniques for problem solving. Some of these techniques are
found and experimented in university laboratories, e.g. Component of
Expertise, and KADS.
References
Bylander, T., and Chandrasekaran, B. 1988. Generic tasks for knowledgebased reasoning: the “right” level of abstraction for knowledge acquisition.
Chandrasekaran, B. 1987. Towards a Functional Architecture for
Intelligence Based on Generic Information Processing Tasks.
Chandrasekaran, B. and Johnson, T., R. 1992. Generic Tasks and Task
Structures: History, Critique and New Directions.
Chandrasekaran, B. 1989. Generic tasks as building blocks for knowledgebased systems: the diagnosis and routine design examples.
Chandrasekaran, B. 1990. Design Problem Solving: A Task Analysis.
Generic Tasks 7