This paper introduces HiPWorks, a hypermedia authoring system built in the Poplog1 AI programming environment. HiPWorks is under development as part of the Hypermedia in Poplog (HiP) project. The aim of the paper is to illustrate how HiPWorks is used to integrate Expert and Knowledge-based systems with hypertext and hypermedia. The paper explains how expert systems can benefit from hypermedia support. It discusses some of the themes we have developed in HiPWorks, looking at metaphor, terminology, usability and scripting. It describes the framework and architecture of the HiPWorks system, including the Object Compiler, the Display Manager, the Interaction Manager and the Offline Manager. The paper outlines a demonstration application for HiPWorks.
Until recently, knowledge based programming environments such as KEE or Poplog [Shearer 1987], and hypermedia authoring systems, such as HyperCard or ToolBook have developed in a related but unconnected fashion. Both have become larger and more sophisticated. Both embody the notion of high-level environments which are used for application development and delivery. Both offer rapid prototyping, dynamic or incremental compilation, debugging tools, and some variant of object orientation. Above all, both are focused on the user and the task at hand.
Reflecting the increasing needs of developers and users, a new trend for combining these two technologies is emerging. Systems which combine these technologies gain several benefits.
Early expert systems such as MYCIN [Shortliffe 1976] were self-contained and the user had no power to explore the knowledge domain or question the system's explanations. Hypermedia can be used to enable users of an expert system to browse graphical representations of the knowledge base [Diaper 1991]. For example, a tree structure representing the rules can be displayed, with currently active rules highlighted. Users could select rules using the mouse to find out more information about the rule or to obtain an explanation for the rule.
Gill [1986] points out that expert systems decontextualize knowledge by removing much of the information that is significant to people. Hypermedia can help to restore this context with the relevant use of photographs, sounds and diagrams for objects represented in the knowledge base. Hypertext can be used to provide access to on-line journals which describe the domain in greater detail, or to documents (statutes, regulations, codes of practice, text books) which may be the ultimate source of authority and context for the expert system. In some cases, Hypermedia systems may be a more appropriate way of representing a piece of knowledge than the automated inferencing of a rule based system [Morrison 1989].
Not only can expert systems benefit from hypermedia, but hypermedia can be improved through the use of expert systems technology. Users of complex hypermedia systems find it difficult to gain an overview of the data, or to find information relevant to a specific topic [Nielsen 1990]. Knowledge based systems can be used to provide intelligent agents, which are capable of learning about user's aims and needs and adapting to meet them [Laurel 1990]. Similar techniques can be used to convert a reader's query into a `path' through a hypertext document [Biennier 1990]. Knowledge based technologies can be used to create the hyperlinks in a hypertext document [Tompsett 1989].
Although there appear to be clear advantages to combining these two technologies, there are few commercial examples of software which successfully combine expert systems with hypermedia.
Developing an expert system is a complex process involving much more than the design of a rule base. Problems facing developers include: how to extract the knowledge from human experts and how to organise and represent this knowledge to end users of the expert system in an efficient and meaningful way.
Many of the problems encountered by developers of expert systems are related to the limitations of the implementation technologies - the expert system shells or toolkits: These technologies can be used to construct impressive prototypes, but these prototypes are hard to `scale up' to real world applications; the tools often restrict the number of rules that can be entered into the knowledge base; they typically provide the developer with a limited number of reasoning techniques to manipulate the knowledge base; they work well on some problem domains, but are ineffective for solving problems in other domains; they often perform slowly, making rapid prototyping infeasible. They usually run on personal computers which do not have the resources required for hypermedia expert system.
By providing a wide range programming paradigms in one workstation-based programming environment, Poplog addresses many of these problems. In the next section we briefly look at some of the features of the Poplog environment.
Poplog [Hardy 1982] is an interactive programming environment developed by the University of Sussex and marketed by Integral Solutions Ltd.
A key factor motivating the development of Poplog is to provide many programming paradigms in one integrated environment. Access to multiple paradigms is essential for building complex expert systems, since developers must choose not simply the right paradigm for a task, but the right paradigm for each subtask within a complex domain [Sloman 1984] [Osborne 1991].
Poplog began as a development environment for writing programs in Pop-11 [Barrett 1985] [Gibson 1984], an AI language which has been under continual development since the late sixties [Burstal 1968]. To integrate logic programming with the functional and algorithmic capabilities of Pop-11, Prolog was integrated into Poplog. A Virtual Machine was used to solve the problems of combining these two dissimilar paradigms [Mellish 1984] [Hardy 1984].
Since then, more paradigms have been implemented. Poplog now supports seven programming languages. The Virtual Machine provides incremental compilation for four of these languages: Pop-11, Prolog, Common Lisp and Standard ML. The other three - C, Pascal and Fortran - are first compiled and then dynamically linked into the Poplog environment. In each language there are libraries for calling functions and evaluating expressions written in other Poplog languages.
Within Poplog, Pop-11, Common LISP and Prolog support object orientation. There is a Prolog interface to relational databases such as Oracle and Ingress. and a Pop11 interface to the X Window System using the X Toolkit and Motif or OpenLook widgets.
[Figure 1: The Poplog Control Panel]
As well as a graphical user interface (see Figure 1) and language sensitive text editor, Poplog has a large body of libraries and tutorials. These include several example expert systems which are provided for teaching purposes. Users copy and modify these tutorials and libraries to suite their own applications.
There are several higher level tools for buildering knowledge based applications in Poplog. Two of these are Poplog-Rules and Poplog-Flex.
Poplog-Rules is a knowledge elicitation tool. It uses data analysis techniques to automatically generate rules about a domain. It includes several learning algorithms based on information theory and statistics.
Poplog-Flex is a Prolog-based expert systems toolkit. It includes both forward and backward chaining inference mechanisms. It provides an object oriented frame schema, and an English-like Knowledge Specification Language (KSL). Here is an example of a KSL rule:
rule prescribe_lomotil if the patient complains of diarrhoea and the patient does not suffer from liver_disorder and the patient is definitely not pregnant then I advise the patient to take lomotil browse file medical_journal_7 .
Flex was created by Logic Programming Associates and has been ported to a range of Prolog compilers.
Having surmounted the task of creating an expert system, developers often face additional hurdles when they try to add hypermedia to their expert system. One reason for this is that developers are usually forced to implement these two areas of their application using different software packages (such as HyperCard and Mac Prolog) which are then combined. In our experience, combining separate software packages is a difficult task requiring a deep understanding of both packages. Each piece of software usually expects to be in control of its own environment and user interface, rather than to follow the instructions of another program. The developer is frequently forced to deal with performance issues and memory shortages. They also have to duplicate knowledge already held in the expert system, this time representing the knowledge in a format suitable for the hypermedia system.
By implementing the hypermedia software and the expert system in a single environment, Poplog applications can avoid these problems. In fact, Poplog has already been used to build both hypertext systems and graphical interfaces to expert systems.
For example, the Poplog on-line documentation is a widely used hypertext system implemented using Poplog. Help text is displayed using the Poplog text editor's buffer mechanism (the editor manages and displays multiple buffers). The help text includes cross references which can be followed by typing a key sequence (usually Escape H). Following references causes additional edit buffers to be displayed. Backtracking is done by selectively quitting from those edit buffers (by typing Escape Q). The user can select buffers explicitly from a list, and rotate buffers so as to bring an earlier buffer to the front. Early on in the design of the help system, different kinds of documents and links were identified. There are now 4 main categories of help: Reference material, General Help (Overviews), Teaching material, and Documents. Cross references are indicated using the asterisk character in combination with the document type, for example REF *PRINTF (see Figure 2). ASCII text notation was chosen because of the rarity of graphical terminals in 1981. More recently, a search tool was added to allow users to search for entries within the documentation (this is also shown in Figure 2).
[Figure 2: REF *PRINTF]
Examples of graphically driven knowledge based applications written in Poplog are: EXCAP, which displays a graphical simulation of a metal machining process, and FAUST, a system for diagnosing and displaying faults detected by on-line telemetry in the electricity supply on the National Grid [Bramer 1988].
HiPWorks is a natural progression from this work. HiPWorks provides an authoring environment in Poplog that is well suited to creating hypermedia interfaces for expert systems. HiPWorks is due for release in the first quarter of 1993.
HiPWorks develops on ideas originally introduced by the Macintosh HyperCard application, as well as on newer hypermedia authoring environments like SuperCard and ToolBook. In this section we describe some of the themes that are present in HiPWorks. In the subsequent section we look in more detail at the architecture of the HiPWorks software.
It is important to chose a purposeful and enabling metaphor for applications and environments which use hypermedia [Tello 1989, pp 47]. Metaphors centred on things such as desks or toolboxes all have limited extensibility since they refer to objects which are found in an environment rather than being environments in their own right. For HiPWorks we wanted a metaphor which was easily extendible. We chose a Workplace, which is an appropriate location for tools such as sound mixers, video controllers, and can also act as the entry point to the HiPWorks environment.
[Figure 3: The Workplace]
When the developer starts HiPWorks a simple image of the Workplace is displayed (see Figure 3). This shows a sparse environment with hyperlinks to the various tools and facilities in HiPWorks. The Workplace includes upper and lower margins where developers can place buttons which provide links to their own tools and applications. The Workplace can easily be extended to have several work areas, some of which are shared, whilst others are specific to individuals. We have not given the Workplace a special status in HiPWorks, so developers are not required to use the Workplace as the starting point for their own applications.
In HiPWorks, each application is packaged as a production. This is a single unit which contains the various components, code and resources (sounds, icons, images, etc.) of an application.
When a HiPWorks application is complete, the developer `delivers' the production. At delivery time, all the code and shared resources of the production are compiled into a single binary `saved image'. Using saved images makes HiPWorks applications run appreciably faster since less of the application is dynamically compiled. Saved images also allow developers to protect source code and shared resources from modification by end users.
For documentation purposes the developer can ask for a `breakdown' of a production, which produces an ASCII file describing each of the components of the production.
A production is made of one or more storyboards. Although the term `storyboard' may seem at odds with software which is not primarily designed for animation, a real storyboard has a number of features which can help the developer to see how to use this structure in HiPWorks. Conventionally, storyboards are used to ensure coherent structuring when a number of animators/designers are working on an animation. In HiPWorks, a storyboard is a structure which contains a related sequence of scenes.
The concept of a scene intuitively breaks down into background and foreground layers. In HiPWorks, backgrounds and foregrounds are used to hold dynamic and still images and interactive objects. Backgrounds can be shared by several scenes, whereas each foreground is unique to a scene. Currently, interactive objects that can be placed on backgrounds and foregrounds include text fields (which users type into) and buttons (which users click); animations and live video windows will be added in the future.
Workstations have large high-resolution colour displays, which are frequently under-used by expert system applications. In HiPWorks we take advantage of the `real estate' of these displays to show detailed icons and graphics (see Figure 4). This high level of detail can be used to clarify the understanding and use of icons, providing a richer environment for the developer and the user of the expert system.
[Figure 4: An example of using high-definition icons in a palette]
In HiPWorks, the developer can choose to have the font browser, icon browser, property boxes and tool palettes all active and visible, sharing the workspace with the current scene. Each property box and browser affects the currently selected object(s). It is possible to change the value of, for example, a button's font any number of times, without having to call up the font browser after each selection. Developers are not restricted to selecting a single object at a time, and may perform operations (such as alignment) on a group of objects.
Allowing several property boxes and tool palettes to be active on the workspace at the same time (see Figure 5) reduces the number of modes in the application (see [Thimbleby 1990] for a discussion of why fewer modes is a good idea), and increases the likelihood of developers trying out many different combinations before settling on the best solution.
[Figure 5: Using several property boxes.]
All hypermedia authoring environments provide a programming or scripting language which is used to specify how components in the environment behave. These languages sacrifice speed and efficiency to achieve readability and simplicity for the novice programmer. As a result, developers who use these languages for building sophisticated expert system applications find that the scripting language rapidly runs out of expressive and computational power.
In HiPWorks, scripts are written using a superset of Pop-11. Pop-11 has been used since 1984 to build a wide range of working expert systems and has the additional advantage of being easily integrated with other programming paradigms in the Poplog environment. For example, a HiPWorks script can call the Poplog-Flex mechanism to evaluate a goal or produce an explanation of a hypothesis. Through Pop-11, scripts have full access to all of the facilities in the Poplog environment.
Pop-11 allows programmers to extend the language by defining new syntax words. We have used this feature to add one new piece of syntax to Pop-11, the `on' statement. The `on' statement is used to specify handlers for events generated by HiPWorks. Here is a sample handler:
on mouseUp
;;; ring the bell three times,then fade to workplace
repeat 3 times hip.bell endrepeat;
fadeEffect -> hip.theVisualEffect;
hip.gotoWorkplace;
end mouseUp;
Pop-11 offers a wide range of datatypes, such as linked lists, hash-tables, vectors, complex numbers and arbitrary precision integers. Pop-11 supports the ability to create new datatypes. It uses `true' object orientation rather than the `object like' style [Shafer 1988, pp. 12] used by HyperCard and other hypermedia authoring environments. This enables programmers to specialize existing classes to create application specific interactive objects.
Note that extending the syntax of Pop-11 to make it an application oriented language (in this case the application is hypermedia authoring) is a normal implementation technique in Poplog. For example, the RESCU/COGSYS project used Pop-11 in this way to create a language for modelling processes in a chemical plant.
In this section we look at the main components used to implement HiPWorks, and describe how they interrelate. There are four central components: The Offline Manager, the Object Compiler, the Display Manager and the Interaction Manager (see Table 1).
The Offline Manager is responsible for storing and retrieving the hypermedia data that is manipulated by HiPWorks. It accesses data from two main sources: libraries, which can be shared by many HiPWorks applications; and productions, which contain the storyboards, scenes, backgrounds, graphics, text and buttons that are specific to each application.
The Offline Manager currently uses a straightforward human-readable file format. Separate files are used for each scene, storyboard, icon and cursor object. We chose this representation technique whilst developing HiPWorks because ASCII files can be manipulated using the powerful UNIX text manipulation tools (such as grep, awk and sed) to search, modify and extend the data representation. In addition, UNIX is optimised to handle many small files.
The Offline Manager is a discrete unit in HiPWorks, so it is possible to modify it to make HiPWorks use third party databases to store the Hypermedia components. We intend to implement a version of the Offline Manager which makes use of an Object Oriented Database to store the objects created by HiPWorks. Relational databases such as Oracle and Ingres are also possibile targets for Hypermedia.
A possible further use of the Offline Manager is to store persistent objects, such as the ruleset of a large knowledge base. These objects can then be accessed via HiPWorks scripts.
The Object Compiler takes the data structures generated by the Offline Manager and makes them `real'. It converts textual descriptions of objects into instances of those objects.
For example, the Poplog incremental Pop-11 compiler is called to convert script source text into procedure objects which can be run. It is during this stage that elements of Poplog are linked into the HiPWorks application, since the Pop-11 scripts will often employ facilities which are either part of Poplog or part of an expert system built using Poplog.
After instantiating the objects, the Object Compiler builds indexes and other tables which are used by the HiPWorks system but not stored in the offline representation.
Once compiled into an internal representation, objects can also be decompiled by the Object Compiler to regenerate the representation suitable for storage on disk. The Object Compiler takes `real' or live button, field and storyboard objects and extracts the data which is persistent, passing this data to the Offline Manager.
The Object Compiler can be instructed to retrieve certain elements of an object from memory rather than from the Offline Manager. Because Poplog supports `saved images', developers have the option of loading data and code into Poplog and then creating a saved image containing the data and code. The saved image is restored when the HiPWorks session is started. Using saved images, developers can compile and link all of the scripts and shared data of an application into the HiPWorks binary.
The Display Manager is the most complex component of HiPWorks. It implements a uniform high-level interface to the facilities provided by X Windows programming libraries such as Xlib, the X Toolkit, and OSF/Motif. It also implements additional functionality not provided by these libraries.
An important part of the Display Manager is the font manager. This maps from machine and X Server independent font names into the IDs needed by X text drawing primitives. The font manager uses a set of rules to perform font substitution for size, style and typefaces when necessary.
The Display Manager also provides functions used to create and manipulate X Windows cursors, colours, icons and off-screen images. The image data for cursors, pixmaps and images is stored and retrieved using the Offline Manager.
HiPWorks uses the Display Manager to create and manage windows, menus, palettes and dialog boxes. The Display Manager implements several dialog boxes which are used by the HiPWorks authoring environment and HiPWorks applications. These include a font browser, a colour browser, a file browser and an icon browser.
The Display Manager provides functions for generating graphics on the X Server display. These include all of the X Windows drawing primitives for rendering objects such as lines and arcs. In addition, higher-level operations such as flood fill are implemented. The drawing primitives in HiPWorks can output postscript code for printing a hardcopy version of a scene.
Events passed to the Display Manager from the X Windows server are packaged into high- level descriptions of the event which are then passed to the Interaction Manager.
The Interaction Manager is the central component of the HiPWorks system. It coordinates the user interface and defines responses to events generated by the user (e.g. mouse clicks) or by the system (e.g. signals).
The various modes used by HiPWorks (such as the browse mode, the draw mode and the author mode) are implemented by the Interaction Manager; it ensures that the correct cursor, palettes and dialog boxes are displayed for each mode. It also ensures that dialog boxes and menu items become sensitive to user input when appropriate. For example, if the user selects a button while in authoring mode, the icon browser becomes active, indicating that the user can chose an icon for the button.
The Interaction Manager is responsible for ensuring that the displayed version of an object is consistent with the object's representation in memory and on disk. It does this by using `dirty' flags which are raised when the user manipulates the object on screen (the same approach is used for pictures). At critical places (such as when HiPWorks exits, or moves from one scene to another) objects which have the dirty flag set will be sent a `save_yourself' message. Objects respond to this message by asking the Object Compiler to save the current version of the object to disk via the Offline Manager.
When a property (such as the current fill pattern) is displayed in more than one menu or dialog box, the Interaction Manager ensures that all of the menus and dialog boxes show a consistent value for the property. It does this using a notion of `shared properties'. Whenever a shared property is modified, an `update_yourself' message is sent to all of the objects which express an interest in the property, causing the new value to be displayed on the screen.
In this section we describe some of the ramifications of implementing a hypermedia authoring environment using an AI toolkit like Poplog.
Systems using hypermedia need to respond to users' actions promptly. Because HiPWorks performs automatic memory management for an application, at times it needs to invoke garbage collections to free unused store. During this operation HiPWorks does not respond to the user's actions, and any tasks currently in progress (such as an animation) freeze.
We have used several techniques to alleviate this problem. Based on end users' comments, we changed HiPWorks to indicate to the user when a garbage collection is taking place by changing the cursor shape to a recycling arrow. This is better than performing the garbage collection silently since it does not keep the user guessing why the system has stopped.
If garbage collections are performed frequently they do not take very long (typically less than a second in HiPWorks). By forcing the system to garbage collect at appropriate places (i.e. at the start of an action that the user knows will take several seconds, like opening new storyboards) it is possible to make the garbage collections less noticeable.
The problem of garbage collections is compounded by multitasking operating systems such as UNIX in which the computer's resources are being shared by many programs, or `processes'. Applications like the X Window System use a large amount of memory. To cope with this workstations are forced to `page' memory segments onto the hard disk, which reduces performance dramatically. If there are many processes running, the operating system is also likely to stop the HiPWorks process to run other processes. One simple, though expensive, solution is to increase the amount of memory in the computer. This reduces paging, but doesn't entirely stop the operating system from interrupting the software. Fortunately, some modern UNIX operating systems (such as the IRIX operating system for Silicon Graphics Workstations) offer `real time' facilities. These allow programs to indicate, by specifying a priority, which sections of code are time critical, e.g. during an animation. The operating system can then devote more resources to these tasks.
HiPWorks, following the tradition of Smalltalk [Goldberg 1983], provides the Pop-11 code which implements the authoring environment as an integral part of the product.
This `Open Architecture' enables the developer to discover how HiPWorks implements the various elements of its environment. It is easy for developers to reuse the code, and to modify and extend the behaviour of the system. The Open Architecture of HiPWorks reflects our belief that designers of authoring environments can not predict all of the possible applications that people will want to write in the authoring environment.
Developers can use HiPWorks to create both expert systems and hypermedia user interfaces within the Poplog environment. They are therefore unhindered by the context switching that they must perform when using several separate software environments to create an application. Both the expert system developer and the interface designer can work at the same workstation using the same software, reviewing a prototype application and making direct changes to code and graphics. A multi-skilled team of experts, knowledge engineers, HCI designers and graphic designers, becomes a real asset in a shared and sophisticated development environment. Each member has an understanding of the whole system, but they can each specialise in pushing one area to its limits.
We envisige several kinds of users for HiPWorks. Firstly, we know of several projects where the prototyping is done using HyperCard, and the final implementation is written using a programming environment on a workstation. Users of these systems would benefit from the `single environment' approach of HiPWorks. Secondly, there are an increasing number of universities offering courses in Human Computer Interaction and Artificial Intelligence. At universities more users are supported by UNIX based computers than personal computers, making HiPWorks a good choice as a teaching environment at these establishments. Thirdly, there are commercial developers who wish to write large scale hypermedia and KBS programs, and need an environment such as HiPWorks to provide these capabilities. Finally, there are researchers in the field of Intelligent Human Interfaces that need the combination of paradigms offered by HiPWorks.
One of the aims of HiPWorks is to allow developers of expert systems to build effective hypermedia interfaces to those systems. In order to test this ability of HiPWorks, we are currently implementing an interface to the Radiology Tutor [Sharples 1989], a knowledge based program itself written using Pop-11.
The Radiology Tutor is a learning aid for student radiologists, in particular relating to the study of pathologies of the heart and lungs. It aims to provide a more dynamic and flexible learning environment for the student radiologists and to relieve the tutoring burdens of senior medical staff. It is an impressive example of a system which uses graphics to provide context for a rule based AI program.
The Radiology Tutor displays an X-Ray photograph to the student and asks a series of questions about features in the photograph. The user responds using simple English sentences. For each image, the tutoring system has a knowledge base consisting of image features, anatomical features, clinical data about the patient, the pathology covering the image and teaching rules. These rules are used to analyse the student's responses. The system uses a variety of techniques to correct the student's misunderstandings, and has an agenda of teaching actions to teach the student about features in the image.
HiPWorks is being used to provide a friendly user interface to the program. The existing user interface displays grayscale X-Ray photographs in windows, and annotates the photograph using coloured lines and text. The annotations are used to highlight features that a student missed and needs to examine in more detail.
The display of the X-Ray photographs is being modified to use HiPWorks. This will allow the student to browse through a collection of images. HiPWorks will also present questions to the user in a structured manner, using a separate scene for each question. The user types responses into text fields placed on those scenes. Simple HiPWorks scripts pass those responses to the tutoring system for analysis. Based on the analysis of the tutoring system, HiPWorks will display further scenes, X-Rays, information, questions or advice.
The Radiology Tutor is also being enhanced by the provision of hypertext documentation and help information which the user can browse. The documentation will include a hypermedia introduction to the pathologies of the heart and lungs for new students.
Expert systems benefit from hypermedia when it is used to `re-contextualize' the knowledge held by the system. Hypermedia can also be used to create more accessible documentation and to allow users to explore and interact with the knowledge domain of an expert system.
HiPWorks provides a powerful vehicle for delivering applications which contain hypermedia and expert systems. It embodies the philosophy of providing the best paradigm for solving each subtask of a complex software application.
An area of future work is the use of expert systems and knowledge based systems to create more intelligent user interfaces. Techniques such as gesture recognition, natural language input, and intelligent agents could be used in exciting applications which utilize the synergy between Artifical Intelligence and hypermedia to enhance the usability of complex software applications.
HiP is a joint project between Integral Solutions Ltd. and the University of Sussex, partly funded by the Teaching Company Scheme, a UK government programme for transferring technology from universities to industry and commerce.
Barrett, R., Ramsey, A. and Sloman, A. (1985) Pop-11: A Practical Language for Artificial Intelligence, Ellis Horwood.
Bienner, F., Guivarch, M., Pinon, J. (1990) Browsing in hyperdocuments with the assistance of a neural network, in Hypertext: Concepts, Systems and Applications, ed. Rizk, A., Streitz, N., Andre, J., Cambridge University Press.
Bramer, M., Pearce, J., Muirden, D., Platts, J., Vipond, D. (1988) FAUST - An expert system for diagnosing faults in an electricity supply system, in Research and Development in Expert Systems volume 5, ed. Kelly, B., Rector, A., Cambridge University Press: Cambridge.
Burstall, R., Collins, Popplestone, R. (1968) Programming in Pop-2, University Press, Edinburgh (out of print).
Diaper,D. & Rada, R. (1991) Expertext: hyperizing expert systems and expertising Hypertext, in Hypermedia/Hypertext and Object-Orienteded Databases, ed Brown, H., Chapman and Hall:London.
Gibson, J. (1984) Pop-11: an AI programming language, in New Horizons in Educational Computing, ed. Yazdani, M., Ellis Horwood.
Gill, K. (1986) Artificial Intelligence for Society, Wiley.
Goldberg, A. Robson, D. (1983) Smalltalk-80 The Language and its Implementation, Addison-Wesley.
Hardy, S. (1982) The Poplog Programming System. Cognitive Science Research Paper no. 35, School of Cognitive and Computing Sciences, University of Sussex.
Hardy, S. (1984) A new soft environment for list-processing and logic programming, in Artificial Intelligence: Tools, Techniques and Applications, ed. O'Shea, T., Eisenstadt, M., Harper and Row.
Laurel, B. (1990) Interface Agents:Metaphors with Character, in The Art of Human Computer Interface Design, ed. Laurel, B. and Joy Mountford, S. Addison Wesley
Mellish, C., Hardy, S. (1984) Integrating Prolog in the Poplog programming environment, in Implementations of Prolog, ed. Campbell J., Ellis Horwood.
Morrison, A. (1989) Hypertext and Expert Systems - Experiences and Prospects, in Fith International Expert Systems Conference, Learned Information:Oxford.
Nielson, J. (1990) Hypertext and Hypermedia, Academic Press: San Diego.
Osborne, K., (1991) Tackling Complex Expert Systems, in Proceedings of the European DECUS Conference.
Shafer, D. (1988) HyperTalk Programming, Hayden.
Sharples, M. (1989) The Radiology Tutor: Computer-Based Teaching of Visual Categorisation, Cognitive Science Research Paper no. 135, School of Cognitive and Computing Sciences, University of Sussex.
Shortliffe, E. (1976) Computer-Based Medical Consultations: MYCIN, Elsevier.
Shearer, C. (1987) KEE and Poplog: alternative approaches to developing knowledge based systems, in KBS 87: proceedings of the international conference help in London, June 1987, Online : London.
Sloman, A. (1984) Why we need many knowledge representation formalisms, in Research and Development in Expert Systems, ed. M. Bramer, Cambridge University Press.
Tello, E. (1989) Object-Oriented Programming for Artificial Intelligence, Addison-Welsey.
Thimbleby, H. (1990) User Interface Design, Addison-Wesley.
Thompsett, C. (1989) Knowledge-Based Support for Hypertext, in Fith International Expert Systems Conference, Learned Information:Oxford.