A Framework for Model-Based Adaptive Training

Foundation - Knowledge Acquisition

A suitable domain for the MOBAT framework is a knowledge-intensive training subject (i.e., a training subject that involves only sensory-motor skills is not a suitable area to consider for the MOBAT approach). This involves the knowledge principle from [Lenat & Feigenbaum 1987]: if a program is to perform a complex task well, it must know a great deal about the world it operates in. This statement does not mean knowledge is intelligence, the principle just states that knowledge is important. The MOBAT framework helps with the specification of the knowledge base for training subjects that are maintainable for a changing subject area. Maintenance is not just about correcting bugs – maintenance is about the mapping of changed information from the environment into defined problem spaces. This kind of maintenance is usually called knowledge acquisition in KBS research. Knowledge acquisition is a key activity for both the initial construction and the ongoing maintenance of a training subject knowledge base; deciding what knowledge should be brought to bear, how the knowledge can be used, how to extract, explain, represent and encode it are all aspects of knowledge acquisition.

The Knowledge Level

Training domains specified with the MOBAT framework will change, however it is likely that there will be considerable knowledge sharing and re-use areas. Research in software reusability has identified that a crucial issue is the search for an appropriate level of abstraction at which to think about reuse [Krueger 1989]. An appropriate level considered by many KBS researchers is the knowledge level [Newell 1981, McDermott 1988, Steels 1991]. Splitting a single level into knowledge level plus symbol level permits each of the separate aspects to be adequately developed technically. Newell’s work has heavily influenced much of the research in knowledge acquisition. For example, see the conceptual and system design levels in automating knowledge acquisition in [Marcus 1988] and the KADS methodology [Tansley & Hayball 1993].

To make software development easier, the primary issue is to identify helpful abstractions for knowledge level and symbol level objects so that program pieces can identify and compose themselves on the basis of immediately salient characteristics of tasks [McDermott 1990]. The knowledge level and symbol level concept is expanded by Luc Steels with an intermediate level called the knowledge-use level. At the knowledge-use level the focus is on:

  1. how the overall task will be decomposed into manageable subtasks;
  2. what ordering will be imposed on the task;
  3. what kind of access to knowledge will be needed (and, consequently what representations must be chosen); and,
  4. how pragmatic constraints such as limitations of time and space or limited observability can be overcome [Steels 1990].

What is the content of the knowledge level and what is the exact relation between the knowledge level and symbol level? The knowledge level compares with system analysis in software engineering and the symbol level is similar to system design. As noted by Luc Steels, there are two ways the knowledge level can be presented: the knowledge level is an abstract representation of the domain which links to detail in the symbol level; or, the knowledge level fully represents the domain which is translated into the symbol level. With the first approach, the knowledge level descriptions can link to several implementation languages and the knowledge level is a specification for symbol level code chunks. With the second approach, the system specification is created completely at the knowledge level as the abstract representation can be directly translated to symbol level code chunks. The translation may be done automatically with code generating tools.

What is the minimum structure necessary to allow the domain expert to adapt an ITS to the environment? A simple view of knowledge acquisition is to map data directly from an expert to a knowledge base with the possible risk of wrong interpretations. The KADS view of the knowledge acquisition process is one of “interpretation” and mapping onto representations and structures [Tansley & Hayball 1993]. Many researchers recognise that knowledge acquisition is made easier with:

  1. a few well-defined roles for knowledge to play;
  2. a problem-solving method that integrates these roles; and,
  3. a knowledge intensive task domain [Lenat & Feigenbaum 1987, Marcus 1988, McDermott 1988, Steels 1990].

In the following section the concept of problem solving roles and methods is discussed in greater detail.

Flower Show
© | | Sitemap