Previous: Next Generation Architectures Up: Issues in Knowledge Level Modelling Next: Conclusion

Roles of Knowledge Level Modelling

Knowledge level analysis is not a goal in itself but has a role to play in a broader methodological approach toward knowledge system development. Three roles are the basis for common methodological usage of Knowledge Level models:

  1. Guidance in knowledge acquisition
  2. Functional specification of system
  3. High-level design of system

A fourth role, support for sharing and re-use, is a natural complement to these roles.

Guidance in Knowledge Acquisition.
If a knowledge level model is a model in terms of knowledge, then its creation is equivalent to knowledge acquisition. A KL-model (in the sense of Sec. ), by proposing an adequate structure on knowledge, can serve as a frame for knowledge acquisition. It helps in interpreting observed behaviour or in understanding protocols. This is the original role intended for the KADS interpretation models [2]. It is also the role explicit supported by the MOLE [18] and Protege work [30][27] where dedicated knowledge acquisition tools take care of "stuffing" the knowledge in the right slots of a pre-selected or constructed KL-model.

Functional Specification of System.
A knowledge level model predicts behaviour. It can therefore be naturally interpreted as a functional specification of a system's behaviour. It could be argued that it becomes necessary to use a knowledge level model as soon as goal-directed behaviour is too complex to capture it in an enumerative or algorithmic way. But the effect is the same: a knowledge level model, together with the principle of rationality serves to predict or specify what a system will do in a given situation. As such it plays the role of a functional specification. It is functional in the sense that it has no necessary implications for how the behaviour should be realised, but restricts system behaviour to a number of possibilities.

High-Level Design of System.
It was already pointed out that a Knowledge Level model has more structure to it than originally intended. Basically, this is clear from the more elaborate ontology that one uses in Knowledge Level modelling. Instead of goals and knowledge, a much richer terminology is being practiced. Notions like domain model, task, problem solving method, mechanism, inference or knowledge role allow additional structure in the knowledge level model. It is tempting to view this structure as a high-level design of a system.

Sharing and Re-Use.
Most modelling approaches to knowledge engineering assume that models associated with applications that have similar requirements will be similar. Generic or re-usable models capture these similarities and are a cornerstone in the support that such methodologies provide. For example, a KADS interpretation model [2] contains a re-usable inference structure and task decomposition, appropriate for a class of tasks. Similarly, a Generic Task [7] is a packet of a task and domain model that is re-usable for a series of similar tasks.

With respect to the last role it is assumed that an analysis of the requirements of the application provides an index to a re-usable model. This is what we have called the task features previously. The earliest attempts to come up with a categorisation of application types followed a task oriented approach [2][21][9]. More recently other than the task perspective have been explored. McDermott's taxonomy of problem solving methods [26] takes a method orientation. Work on re-usable ontologies [20] researches into generic terminology and structures within certain domains. Work on KIF - the knowledge interchange format - is prototypical for this research [19]. KIF is a logic based language that can be used as an implementation independent format for exchanging knowledge bases. A specialisation of KIF, called OntoLingua [20], can capture in a general and standardised way ontologies that are useful in domains such as medical diagnosis or design. Steels' Componential Methodology [36] supports the usage of chunks that contain any combination of task, domain, problem solving method with or without associated pieces of code. Although the idea of re-usable models is shared by many approaches, the foundations of generic models and the selection and modelling mechanisms that are needed to work with them are not well researched [44].

A major weakness in the combination of these roles is that it hides a subtle shift from observed behaviour (for example from an expert) to system behaviour. As Linster put it, there is modelling for making sense and modelling for system design [23]. It is tacitly assumed that a smooth transition from the one to the other is possible and useful. The assumption behind this role is that a KL-model can be found that is adequate for the range of situations one wants to deal with. Moreover this can be done before the detailed knowledge has been acquired (see also the tools described in [22] and [30]). Consider the situation of a human expert behaving in an environment, and then replace that expert by a system, or by an agent-system combination (Fig. ). What is the relation between the knowledge level models for these three behaviours? Can we assume that they are the same, that they are related or are they really different?

Various authors, implicitly or explicitly motivated by these issues, are exploring ways to deal with them. A first approach is to explicitly distinguish between models for analysis and models for design. This is, for example, done in CommonKADS [48] but the relation and transition between the 'present' and 'target' models is largely an open issue. A second approach is to support knowledge level modelling for end-users themselves, as it is done in the Componential Methodology [36]. Here modelling is always done in the context of designing an application, and it is grounded in the needs and understanding of the users. A third approach is to restrict knowledge level modelling only as a tool for analysis. Here the aim is to find out about those features that make up interesting knowledge-based and goal-directed behavior, in particular the epistemological and pragmatic problems (Sect. ). The knowledge that is used to overcome these problems may be ephemeral, but the problems themselves are not. How to deal with these problems is treated as an entirely separate problem and the knowledge level analysis may or may not be useful here. This is my understanding of some of the suggestions in [32].

walter@arti