CHATTERBOTS
Artificial intelligence software programmed to provide a human-like interface could soon be put to work on the Web, answering product questions or completing order forms. Gateway 2000 wants to add these "chatterbots" to its Web site to answer technical questions: "It could be a great way to automate support so people don't have to wait on hold," says a Gateway technology manager. "It's one of our top priorities." Chatterbot software works by first analyzing questions and then placing them into categories. An answer is then formulated from a repository of software code, called a script.
(Investor's Business Daily 13 Apr 98)
Chapter 2
A portal for text
In designing projects and presentations, you are probably used to the idea of opening up an application which has a full range of menus and helpful palettes to assist in the authoring process. With the help of the useful tools provided, you gradually build up your production and then, when it is finished, you attach the player, or engine of code, to run or play the production according to the designs specified in the authoring environment.
It may come as somewhat of a surprise then, to find in this book, we are going to learn how to dispense with an authoring environment altogether.
Instead of working from inside of an authoring application, we are going to work with just the player, the biotelemorphic cell. We are going to be on the outside of this cell, trying to get stuff in - something much like pushing components through the neck of a bottle to build a "ship in the bottle".
Concept note
It may cross your mind that this a convoluted way to go about creating Web and multimedia presentations: why not just create a proper multimedia document from one of the many multimedia authoring packages and then get the appropriate document player to play it?
A little thought will soon tell you that this would restrict access to the cell's engine code only to the people who possessed a full authoring package. It's not that we are worried about restricting the design of cell activity to the possessors of an authoring package; it's more that we don't want to restrict the design of cell activity to HUMANS.
This chapter is designed to bring out this point: we shall be arranging the cell to be controlled by documents.
Typing code into a field is a human way to do things and, even for a human, it isn't a very convenient way to program a cell, particularly if we want to do this from a remote computer located on the other side of the world across the Internet.
Ideally, we should like to arrange for the cell to get its input in the form of text documents, perhaps an email. This would also open up the programming of the cell to non humans - in fact, to any software application which could produce text - including the biotelemorphic cell itself (YES! the cell can become self programming and able to modify its own instructions - but more of that later in the book)
Figure 2.1 shows, diagrammatically, what we are looking for. We want the biotelemorphic cell to be able to accept inputs through a portal which passes them on to the engine code to create objects in RAM.
Figure 2.1
A Director 5 biotelemorphic cell illustrating the principle of inputs resulting in the creation of objects within the cell RAM space
Let's begin by making a working example of the design shown in figure 1.3 of chapter 1. This is the second paradigm, where the cell is modified to allow a human user to choose a particular document which contains instructions for the cell to act upon. This will involve redesigning the portal.
Using Director 5, we will construct a new portal document (remember we have to use the full Director authoring package to make portals) and this time add a facility to allow the cell to read in a text document (rather than a multimedia document created with an authoring package).
We will design this facility such that the text is placed into the "Input" field for the "Do" button to act upon:
Figure 2.2
A button script which imports a named text document and places it into a field named "Input"
Figure 2.2 shows a typical Director 5 Lingo button script which will import the text from a text document (named "Instruct.txt") and place it into a field named "Input".
Technical detail:
This script uses the FileIO Xtra which is built into the Director engine of the biotelemorphic cell. The line:
put FileIO(mNew,"read",theFile) into gReadObject
turns the variable gReadObject into an object (in RAM) which can be called upon to read text from the document named in the variable theText.
This gReadObject object is set to read the text one line at a time, in a repeat loop using the line:
put gReadObject(mreadLine) into it
Each line is then added to the variable theText until an empty line is encountered. When this happens the text reading object (gReadObject) is removed from RAM with the line:
gReadObject(mDispose)
and the text that has been placed into the variable theText is placed into the field "Input".
This simple script has two problems for our purposes. Firstly, it will stop whenever it encounters an empty line. Secondly it will read in all text encountered.
To make this text reading procedure more suitable for our purposes, it would be preferable if the text were parsed in some way so that only chosen sections of a document would be read and entered into the input field. This we can do with the script modified as shown in figure 2.3. The lines not darkened out are the lines added to the previous script.
Figure 2.3
Altering the "read" script so that it reads only a specified section
Figure 2.3 shows how each line read with the gReadObject is examined to see what word it starts with. It will ignore all lines until it encounters the special word "qxz", whereupon it will collect together all subsequent lines and put them into the "input" field, until it encounters the word again.
This simple parsing trick allows programming instructions to be included in any document - perhaps included in an ordinary email where any protocol headings , messages for humans or "chatty" stuff is ignored by the cell which reads only the part intended for the cell itself.
Looking forward a moment, to what we shall be doing later, it is quite easy to see how, using a number of different "parsing words" we could have many different messages embedded in a single text document. If you want a good metaphor - this is exactly how the DNA in our cells are used to activate the various embedded genes - but more of that later.
Note: the FileIO object gReadObject can be instructed to read only the text between certain specified characters of a text file, but, for the purposes of this book, we shall be parsing text using words rather than characters.
The next problem we encounter with the scripts shown in figures 2.2 and 2.3 is that they are "hard-wired" to read only one particular text document: "Instruct.txt".
What we want to be able to do is to arrange for the human chooser to be able to decide from a number of different options as to which text document (set of instructions} the cell reads from.
The fileIO object can be given an instruction to let the user choose any document available on the system with the command line:
set gReadObject to FileIO(mNew,"?read","txt")
This line, with the "?" before the parameter "read", will get the cell's code engine to bring up a standard system dialog box to allow the user to choose which document the cell reads from.
Unfortunately, as with the use of authoring packages to specify a cell's activity, this method necessitates having a human in the system - which might not always be convenient.
To overcome this problem, we can arrange for the cell to reference a specific directory or folder on the hard disk of the local system where it can look for or pick up its instructions.
If we look at a Director Lingo syntax book, we will find that the Director 5 cell's engine code will respond to a command:
getNthFileNameInFolder(theFolder,i)
This is a function call which will return the name of the file or document number i in a folder specified in the variable theFolder.
By using this function call in a repeat loop, we can get the name of every file or document contained in a particular directory or folder. Figure 2.4 shows a button script of a button included in the portal movie which gets the name of every file or document in a folder on the hard disk named "Instruct.fld".
Figure 2.4
Button script which gets the name of all the documents in a folder on the hard disk and puts them into a field
You will notice that the script in figure 2.4 puts all the names of the text files into a new field called "Instructions". For convenience, we arrange this new field to appear on a new screen (figure 2.5).
Figure 2.5
Frame 2 of portal showing the text files which are contained in the folder "Instruct.fld"
Technical note:
Director can arrange for different screen layouts by specifying different frames. For our purposes, all of these frames will be "paused" in the exitFrame handler. The portal we are designing here will have another frame added which will cause the screen to look like that shown in figure 2.5. Clicking on the button described in figure 2.4 will put all the file names into the field "Instructions" and then sets the screen to frame 2 where this "Instructions" field is displayed.
Once the file names are recorded in a field they will be accessible to all scripts and will be able to be used by non humans to retrieve the documents named.
To allow a human user to determine the cell's activity from a choice of these different instructions we can use the Lingo code in the cell's engine which tells us which line in a field is clicked on: the mouseLine.
Figure 2.6 shows a "click on" script (mouseUp and mouseDown) which we can put into the scriptText of the "Instruction" field.
Note: The engine of a Director biotelemorphic cell detects clicks on fields as well as buttons so it will activate any appropriate scripts in the scriptText area of the field when a mouse click is detected.
Figure 2.6
A field "click on" script which selects a document to be used for a cell's input instructions
When the clicked on line is detected, the script in the field tells the cell engine to select the file named in the line clicked on and to parse it between the markers (qxz) and place the parsed section into the input field.
Technical detail:
The field script of figure 2.6 is activated by any mouseUp message which is sent if the user clicks anywhere in the field. The handler that responds to this message uses the mouseLine() function in the cell's engine to return the number of the line the user clicked on. This line is highlighted on screen and the content of the line put into a variable fName.
The variable fName is then sent as a parameter with the message putItInInput to the handler of the same name written into the same scriptText as the mouseUp handler.
The putItInInput handler uses the fileIO XObject, similar to the way shown in figure 2.2, to read the file specified in the parameter. The part of the file between the two instances of the word "qxz" are parsed out and put into the "Input" field".
This device now allows the human user to select a text document to be placed into the "Input" field. All the user has to do then is to click on the "do" button and whatever instructions are contained in the selected text document will be sent to the code in the cell.
As we shall see later, even with this simple cell, people will be able to receive all kinds of complex programming instructions in their email messages.
Summary of the conceptual position this far
From a technical programming point of view, we haven't done anything spectacular. We've just used a few of the Lingo code instructions, incorporated in the engine of a biotelemorphic cell, to facilitate the transfer a piece of text from the hard disk to a field.
However, from a conceptual view point this is a major break through: we have provided a communication link between the cell and the outside world. More importantly this link can be used by both humans and text documents to control the activity of the biotelemorphic cell.
To illustrate, just how significant is this conceptual jump, let's send ourselves a few Emails. When they arrive we'll put them into the "Instruct.fld" folder and see how they perform.
Overriding human control
In the last section, it needed a human, to select the files to be read and placed into the "input" field. It needed a human to click upon the "do" button to initiate subsequent activities.
Although we are unlikely to want to do away with human control for the initial start to the cell's activity, it would be extremely cumbersome to have to have a human standing around all the time to activate instructions coming into a cell from outside sources.
So, what we are going to do now is to make arrangements for documents and objects to be able to override human intervention and do everything themselves.
You might feel justifiably alarmed at this proposal. Allowing documents to cut humans out of the control loop and take charge themselves is somewhat dangerous - it could be the thin end of the wedge - but, it has its advantages (if documents are going to end up ruling the Internet in the long term anyway, why stop them now?).
To facilitate document and object control we have to install an agent inside the cell with whom documents and objects can communicate with directly . This agent must be able to do the work of a human in arranging for specified documents outside of the cell to be read and their contents acted upon by the cell engine.
This is simply arranged by installing an object in RAM at start up, which will be able to read outside documents and transmit the code to the engine upon receiving an appropriate message with suitable parameters.
In Director, we can arrange for this in the portal document by birthing the object from a startMovie script and using a suitable parent script placed into the scriptText area of a cast member.
Figure 2.7 shows such a startMovie handler which is activated by an automatic startMovie message when the portal document is opened.
Figure 2.7
StartMovie handler which births a human override object when the portal document is opened
The startMovie handler first creates a global variable named humanOverRide then births an object into it using the "humanOverRide" parent script (cast member 18 in figure 2.7)
This parent script is shown in figure 2.8.
Figure 2.8
Parent script used for creating the humanOverRide object.
The humanOverRide parent script contains a handler which responds to the message doInstructions. When this message is sent to the humanOverRide object it is sent with parameters, which specify the name of the document to be used (fileName), its address (folder) and the parsing word which must be used to select the right portion of the text to be used (parseWord).
If you compare the instruction lines of this doInstructions handler with those of the mouseUp handler (used by humans) shown in fig 2.3 , you will see that they are very similar except that instead of the chosen text being out into the "Input" field it is put into a variable (theText).
The text is then parsed to extract any embedded scripts, using similar code as the "do" button. Then the contents of the variable theText is acted upon directly by the do command sending the instruction directly to the cell engine without it having to go via the "input" field.
We can check out how this works by sending ourselves an email which, when the text is acted upon by the cell, will send a doInstructions message to the humanOverRide object.
Figure 2.9
An email which will send a message to the humanOverRide object telling it to do the instructions contained in a text document named "Eqxz0002.txt"
When the human user selects this email to be read by the cell the single line shown in figure 2.10 will be placed into the "Input" field.
Clicking on the "do" button, with this line in the "Input" field, will take the human out of the control loop and put the documents in charge.
Figure 2.10
The instruction which will cut out the human control and put the documents in charge of subsequent cell activity.
Thinking time again
This extremely simple one line message can take control of the biotelemorphic cell out of the hands of the human user and give it to the documents.
Before reading the next section to see how this can happen, spend a little time to think it out for yourself.
Remember, at this early stage in the book, we are only importing text from files in a single folder on the hard disk. In later chapters we shall be altering the cell to be able to use an Internet protocol engine. This will allow the cell to be able to import text from anywhere on the system, from floppy disks, from CD-ROMs and from the Web. When this happens, giving over control to the documents, will mean the biotelemorphic cell is controllable by a vast intelligence made up from the combined input of thousands of documents all over the Web.
Unbelievable? Before seeing this one line command such a possibility may have seemed like science fiction. After reading the next section you will see how it is possible.
See if you can work it out for yourself though - before reading on.
Control by Email
The statements made at the end of the last section would seem to be unrealistic. The conventional use of text documents gives no hint or suggestion that they could acquire an intelligence or could take control of anything.
Leaving aside for the moment the question of intelligence (until later chapters), just consider the element of control.
We have seen already that text documents can act like viruses and use the cell's built in code engine to create objects of any design and install them into the RAM space of a biotelemorphic cell.
Now think what would happen if one document could call another and that document could call yet another. Imagine a whole sequence of different documents being called upon to add their input to an avatar being created in the biotelemorphic cell.
This process could go on indefinitely to produce any desired order of object oriented complexity within the cell.
We are now going to demonstrate this principle; nothing complicated: just enough to show you a proof of concept. We are going to get a few documents calling each other to create objects which communicate with each other and the computer screen. The documents will then hand back control to the human who initiated the process.
Figure 2.11 show the schematic of what we are going to do. We are going to send ourselves a set of emails which can be used to manipulate the cell's code, create and communicate with objects in the cell put a few messages on screen before handing back control.
Figure 2.11
Documents calling each other and setting up objects to control a biotelemorphic cell involving sending messages to the screen
In total we are going to use five emails. Always, the first document has to be called and activated by the human user.
This first human activated document (the email shown in figure 2.9 of the previous section) carries the message to activate the humanOverRide object which then acts on the message to read in the parsed text of a second email. The text of this second email is shown in figure 2.12.
Figure 2.12
The second email sets up another object in the RAM space of the biotelemorphic cell and then sends a message to the humanOverRide object to read in another email
The second email is read in by the humanOverRide object which parses out any unwanted instructions or text. The instructions tell the cell's engine code to record the action details and the time in the "Input" field and then install a parent script called "Joker" into the "dummy" member's scriptText and from this create an object named joker.
As you will see from the script in figure 2.12, the joker object is capable of answering just one joke, the answer of which it returns to whatever object or document asked the question. Also, every time the joker object is asked to answer a joke it will send a message to the cell's engine to record that it was in action and the time it was in action in the "Input" field displayed on screen.
Now here is the cunning trick which maintains control with the documents. The last line of the text document sends a message to the humanOverRide object and tells it to load in another text document for more instructions.
The second email effectively transfer control to the third email which is shown in figure 2.13.
Figure 2.13
The second email hands over control to the third email which sets up a global called "pocket" and another object called "clock"
The third email's text is read in by the humanOverRide object and the parsed instructions sent to the cell's code engine.
These instructions set up a global called pocket and installs another object in RAM named clock.
The presence of the third email is then noted in the pocket global and then the humanOverRide object is then sent a message to transfer control to the fourth email.
The text of the fourth email is shown in figure 2.4.
Figure 2.14
The fourth email sets up an object "answerMan" which has a communication link to the Joker object. It then asks the clock object the time before recording its presence in the cell.
The fourth email contains the instructions which gets the biotelemorphic cell to install another object (answerMan) in RAM which can communicate with the Joker object.
This fourth document then gets the time from the clock object and records this time and details of its activity in the pocket global.
As before, this fourth object keeps the cell under document control by instructing the humanOverRide object to get further instructions from email document number 5 (see figure 2.15).
Figure 2.15
The fifth email uses all the objects placed in the cell by the other emails and puts the appropriate messages on screen. It then relinquishes control to the human
Instructions in the fifth email utilize many of the objects set up by the other emails. The log held in the global pocket is displayed on screen in the "Input" field.
A dialogue box with the question "What noise annoys an oyster?" is presented on screen (using the alert command contained in the cell's Lingo code engine). See figure 2.16.
Figure 2.16
The fifth email asks a question
The question is sent to the answerman object which gets the answer from the joker object. The return is displayed in another alert dialog box (see figure 2.17)
Figure 2.17
Objects, placed into RAM by other emails, combine to supply an answer to the fifth email's question.
The final appearance of the screen, recording the various activities and the final signing off are shown in figure 2.18.
Figure 2.18
Appearance of the screen after control is handed back to human control. It shows the actions of the various emails which have taken part in controlling the activity of the cell.
Although the activity and accomplishments of these five emails have been trivial, they should have been sufficient to give you an inkling of the potential power of biotelemorphic cells.
These are the salient points to note at this stage:
1) Apart from the small amount of programming involved in the "portal" document the cell was virtually devoid of any prior programming or set up.
2) Control over the cell, including the sophisticated use of its Lingo code engine, was arranged through ordinary text documents of the type which could be sent over the Internet or down-loaded from a Web page.
3) Once the "portal" document is set in place, all programming can be arranged without the need for any special authoring package or environment. This allows documents to be able to program and manipulate the cell.
4) Once the control of the cell is handed over to the documents they can keep control until they break the link themselves.
5) Through the single "dummy" cast member (the stepping stone) in the portal document, all kinds of objects can be introduced into RAM by the documents. Only the limitation of the RAM size of the biotelemorphic cell will limit the number and sizes of these objects (notice particularly that once an object is created in RAM there is no longer any need for its parent script to hang around, which can be written over or removed).
6) Objects in RAM, the text documents documents and the cell's Lingo code engine can all communicate with each other and send messages and other data to the screen.
7) The objects can be of any desired complexity, containing enumerable handlers to handle a variety of messages and carry out all kinds of computations, repetitions and logical operations.
8) Most important of all is that the center of gravity of what goes on inside the biotelemorphic cell is taken outside of the cell itself. The planning, the intelligence, the vectors of implementation and the control can be far away from the cell. The cell is used merely as a device to manifest whatever avatar phenomenon is propagated.
Where do we go from here?
Chapter two gave you a tantalizing glimpse into the possibilities available with the biotelemorphic cell. Yet this is only the tip of the iceberg. This book is going to take you very much further than this.
We have yet to see the power which can be unleashed by the RAM objects themselves. They can be arranged to carry images and sounds which they themselves can put onto the screen at any time. They can be given memories and personalities. They can be given powers of computation and logic, perhaps even simulated emotions and intelligence. Certainly they can be made to learn, adapt and evolve (as was demonstrated in the CD-ROM "How God Makes God" which was published in 1993).
All this can be achieved through the organizational power of text documents and will be demonstrated by practical examples later in this book.
We shall be dealing with the holistic effects of having many RAM objects combining together and cooperating on complex operations. We shall see the effects of many different documents contributing to and modifying the activities of these interacting systems.
We shall be seeing what happens when the biotelemorphic cell is equipped with an Internet protocol engine. We shall be seeing how documents and RAM objects make use of this engine to bring in new documents, scripts, objects and all kinds of media from the Web; seeing cells sending out documents and installing Web pages for other biotelemorphic cells to read.
We saw what happened when five simple emails from a folder on the hard disk took control of the cell. Now try to imagine text documents having the power to pass on control to other text documents on the Web: for the control to pass from Web page to Web page. Technically, this is no more complicated than passing on control from one text document to another text document located on the hard disk (all it needs is a small addition to the parent script of the humanOverRide object for it to be able to use the protocol engine to read and parse Web pages).
Imagine. These imported Web pages of text using the cell and protocol engines to import their own sounds and graphics; bringing them into the cell from sources around the world. All it takes is for another very little additional scripting of the humanOverRide object for any media item on the Web to be at the beck and call of the controlling text documents.
We shall be seeing how text documents can create new text documents; how text documents can modify each other; how text documents can change adapt and evolve (this is very similar to the techniques used for self modifying objects which were covered in chapter 14 of "Lingo Sorcery - the magic of lists object and intelligent agents" which was published in1996 by John Wiley & Sons Ltd. We shall also be seeing how Web pages can be used as system variables; how they can be used in repeat loops and conditional logic gates.
By using text documents and Web pages like the molecules involved in molecular and cell biology, cascades of actions can be triggered from single events. As will be demonstrated later, a simple button click could result in monumental activity involving hundreds of documents and media from far and wide across the Web: assembling, combining and interacting within the confines of a single biotelemorphic cell.
Of even more sensational potential, will be the ability of a biotelemorphic cell to control and design itself. In the engine code of every cell is the ability of the cell to modify or create its own objects in RAM, to be able to write out its own text documents to disk or send them across the Internet: by email or installing them as Web pages using the protocol engine. We shall be demonstrating this in later chapters.
Only a little thought will let you realize that what may have seemed wild speculations in the introduction to this book, are in fact real possibilities: the Internet and the World Wide Web can be dominated by documents and biotelemorphic cells, independent of human control and supervision. Science fiction writers eat your heart out.
But is it science fiction? It has already happened. This exact scenario, in a physically different setting, has already been played out by nature. This is the story of evolutionary biology.
At the end of chapter two it was pointed out that the experiment with the emails had taken the control of the biotelemorphic cell outside of the cell itself. The center of gravity had moved - but moved to where? It is in the understanding of this "where" which requires the greatest conceptual jump.
When a business is modeled in a spread sheet, where is the center of gravity of that model? Where does that model exist? When a bivouac of army ants builds a a bridge, or, a colony of termites builds a cathedral-like structure, where is the central organization?
This is no simple problem of comprehension. It is a problem where the answer can give an explanation for life itself.
We know, as one of the species of life on this planet, we are made up from a collection of communicating cells. Theses cells are manipulated with chemical messages and complex molecules in the same way as text can manipulate a biotelemorphic cell. Within each cell is a vast colony of symbiotic viruses and bacteria. These combine with each other in complex interactions between themselves and the DNA of the cell nucleus in exactly the same way as software objects interact with each other and the engine of code in a biotelemorphic cell.
Where is the organizing power that brings all this complexity together to form a human shape, or, the shape of any life-form? It is no good looking into the cell for the answer. The answer lies in looking at the phenomena of an abstract entity known as the "gene pool". This exists as a physical reality which cannot be located specifically in any individual cell or even in any life-form created from the cells. It is an abstract property of the species as a whole. Individuals are born as a temporary instance of the total genes within the gene pool.
It is in this same sense that we shall be looking at avatars created on the Internet. We shall be seeing them as instances of the combined temporary coming together of biotelemorphic cells, objects, documents, messages and media.
As to having an understanding as to where it is going; where the center of gravity is and what is the driving force, currently we are not much better off than the ancient Eastern Buddhas and Zen masters. They gave us a conceptual framework to contemplate this phenomenon, but, not the tools to explore and experiment. We now have an edge over those ancient mystics - we have the tools and an environment to experiment with, so, it shouldn't take us thousands of years to better their explanations.
Our first examples have been with a biotelemorphic cell made from Macromedia's Director authoring environment. This has many limitations, but, we shall also be creating biotelemorphic cells in Allegiant's SuperCard and Apple Computer's HyperCard. These will soon both be cross platform with Internet protocol engines and will offer many advantages over the Director cell.
There are many other cells we shall be playing with such as Adobe's "Acrobat" and MicroSoft's "Visual Basic". There are the Java cells and the giant cells of Netscape's "Navigator" and MicroSoft's "Explorer". Most of the major software companies will be bringing out players and protocol facilities within the next year or two. Each in a limited specialized way will be able to contribute to the overall complexity and versatility of the Internet and the World Wide Web.
The beauty is that we are not limited to the use of single biotelemorphic cells. Just as we can have several types of objects in the RAM space of a single cell we can have several biotelemorphic cells, of different makes, operating together in the total RAM space of a single computer. All it needs is for these different makes of cell to be able to communicate, swap messages, data and media for them all to work together in a common environment - just like different types of workers using their different skills in complimentary ways to complete a multi-skilled project.
Of course, these biotelemorphic cells are not going to replace everything else on the Web, they will exist side by side with the conventional browsers, plug-ins and other applications which are using Web documents coded in HTML or other proprietary formats. However, the engine code of the biotelemorphic cell does contain the code necessary to open other applications and get them to run their documents when needed - so, perhaps one day, the descendants of the biotelemorphic cell may take over from the giant all purpose HTML browsers - in the same way as the little mammals once took over from the dinosaurs.
--- o---
The intention is for this book to be published as a regular book before the end of 1997. There will also be a separate project to create a CD-ROM to include as many examples as possible.
However, the really big adventure is going to be in the immediate continuation of this current Web publication on-line - as it is being written and developed. This beginning introduction and chapters, starting off by using conventional HTML Web pages, is soon going to continue in the form of manifestations within biotelemorphic cells. After all, if this concept is so powerful, ought it not to be used to explain itself? Not only will readers be able to receive "live" demonstrations of the biotelemorphic cell in action, they will also be able to take part in the demonstrations themselves.
If you want to know more about the continuation of this work, send an email to Peter Small at peter@genps.demon.co.uk