Things to do with the Facts database

Improving the interface

Think about how the responses from the system could be made more helpful. There is already some attempt to provide feedback to the user - e.g. forget if given [some fact or other] replies:

O.K. SOME FACT OR OTHER IS FORGOTTEN.

But query (or rather its helpmate check) is not nearly talkative enough when it finds no matching fact in the database. It is easy enough to make it better.

Modelling memory

One idea for extending the functions of the system is to experiment with simulating memory loss (progressive or random) or short term versus long term memory (e.g. the seven most recently learned facts versus all the facts or the rest of the facts). You might, for example, define a version of query, looking only at short term memory which you might call quickquery.

Developing the pattern matching

More interesting is to develop the system's pattern matching capabilities.

It would be useful, for instance, to extend match? so that it returns "true when given [?? eats fat] and [Jack Sprat's wife eats fat] - i.e. to allow for a second wildcard, perhaps using a double question mark (??), which matches strings of words of any length. When you have done this, see if you can identify types of circumstance in which the use of this wild-card runs into problems.

Another possibility might be to allow the database facts to include wild cards (just like the queries) so that the query [? likes fat] would be matched by the database fact [John likes ?]. A database list including a ? would not, of course, be semantically equivalent to an English question. Instead, in this context, [John likes ?] would be taken to mean John likes anything. How would you need to alter match? to allow for such a change?

Ron Brasington
Department of Linguistic Science
The University of Reading
Reading
UK

E-mail: ron.brasington@rdg.ac.uk