1.Introduction

1.1. Expert systems 'shells' and 'toolkits'

The big boom in expert systems technology during the last decade has led to the emergence of 'knowledge engineering' as a discipline in its own right, generally in its role as an applied subset of artificial intelligence. Software support for knowledge engineers is typically thought of as comprising 'shells' at the low end and 'toolkits' at the high end of the support spectrum. Roughly speaking, shells offer the knowledge engineer a ready-made interpreter following a particular style or paradigm of representation, such as backward-chaining rules. Adherence to the supplied paradigm has the advantage of providing various offthe-shelf facilities, such as automatic explanation generation, but the disadvantage of straight-jacketing the knowledge engineer into a particular and possibly inappropriate style of working. Shells are also characterised by a relatively fast design/edit/run/debug cycle, which is one of their main attractions, since prototype expert systems can be developed quickly for end-user evaluation.

At the other end of the spectrum are toolkits, which offer the knowledge engineer the hybrid features of several different styles or paradigms, along with sophisticated graphics and modelling facilities, so that different parts of a complete expert system can be developed using whichever paradigm is most appropriate. The advantage of toolkits is that they are flexible, but of course this means the user has to suffer the disadvantage of a longer learning period, plus a higher capital investment both for the toolkit itself and the underlying hardware/software platform which supports it (typically an advanced graphics workstation running Common Lisp).

Predictably, the distinction between shells and toolkits, like the distinction between PCs and advanced graphics workstations, is beginning to disappear. Cheap shells are arriving with more and more features added. Full-featured toolkits are dropping in price. The PC world is migrating towards more powerful machines, such as 386-based and 68030-based hardware. Proprietary AI hardware, including dedicated Lisp chips, can be plugged into Macintosh-IIs and Sun workstations. It is in the context of this 'downward migration' of expensive AI hardware and software that we decided to provide comprehensive knowledge engineering software which ran entirely on a conventional PC.

1.2. Why another toolkit?

In 1986 an Open University team began to design a series of industrial training packages on topics related to Artificial Intelligence. The packages were each to involve approximately 80 hours of study, undertaken either by individuals in their spare time, or alternatively by groups in their place of work. We decided to begin with some 'hands-on' courses, identifying three target areas: Prolog, Common Lisp, and Knowledge Engineering. In developing the Knowledge Engineering course, we wanted to provide students with a reliable, powerful, portable, and low-cost piece of software that would enable them to undertake 'grown up' knowledge representation exercises on their own computers. Ideally, we wanted the software to PC-based, although we were open to other options.

We did not want to develop the software ourselves, especially since there are a number of excellent shells and toolkits already on the market (e.g. KEE, GoldWorks-II, Nexpert Object, Leonardo, Xi Plus, Flex). However, we already had extensive experience of developing knowledge engineering environments for industrial collaborators (Motta et. al, 1986; 1988; 1989; Eisenstadt and Brayshaw, 1987, 1988, 1989), and decided in the end that if we did develop our own tool, we could provide a triple-benefit for our students:

(a) we could bundle the knowledge engineering tool with our course materials at no extra charge

(b) we could ensure that our students would have an ?upward migration? pathway, i.e. that the skills they acquired on our course would be relevant if they moved on to more powerful commercially-available tools

(c) we could provide fully-commented source code listings for those who wanted to learn some lessons about precisely how one goes about implementing an integrated toolkit.

Our deliberations ended with our decision to develop MIKE (Micro Interpreter for Knowledge Engineering), and to implement it entirely in a subset of Edinburgh-syntax Prolog so that it would run on standard PC?s. The capabilities and implementation of MIKE are the focus of the remainder of this article. We particularly emphise benefit (c) above, and therefore this article will be of most use to those who want to look at some