Figure 1. Filtering system architecture
The filtering process is carried out by agent programs that are constructed from a user model and registered at a publication centre. Agents examine objects as they are published and decide whether to ignore the object, forward it completely to the user or forward only the meta-data.
We propose that this architecture be used for the distribution of web pages.
At present the web is characterised as a "user pull" system where users reach across the network to retrieve objects. If large numbers of users wish to access a popular web page the resulting load on the network and the server can be a serious problem. This can be partially alleviated by a system of caches so that the first user from a region retrieves the object and subsequent users in that region get the object from a local cache. Another problem is that users must browse or use search engines to find newly published items of interest.
Our architecture is a "server push" system that allows pre- emptive caching and filtering. Popular pages are multicast to regional publication centres where they are examined by user agent programs and, possibly, forwarded to a user's home system for viewing. This avoids the problem of network overload since the server at the original publication point will multicast the object to a manageable number of regional centres and this process may be repeated to send the object to sub-centres. It also aids the user in finding new and interesting items since they are notified if they are accepted by their personal filtering agent.
The User Model information is managed with the um( Kay 1995) user modeling toolkit. Information about a user's preferences in a particular domain is extracted from the user model and embedded in a small filtering agent program written in the Python(Rossum 1991) programming language. This program is sent to a publication centre using a message delivery system(Kummerfeld 1992). Newly published objects (web pages etc) are passed to the agent program for analysis.
The way that this operates is shown in the bottom of Figure 2. The customiser produces a customised document which it presents to the user. That customisation process is driven by instructions embedded in the customisable document, which we call a metahypertext. We have been exploring several approaches to this: simple use of the C preprocessor (Kay 1994); more recently, variants on this using Python as the customisation language; extensions to SGML to provide a customisation language that is consistent with HTML (Hong 1995); and an interface for creating and managing customisation (Smith 1995).
Each of these systems explores issues in creating and managing a metahypertext. Those concerned with issues of expressive power and naturalness of the customisation language are outside the main focus of this workshop. What is highly relevant is the way that the user model fits into the customisation process. Essentially, it is the individual user model that filters the metahypertext to produce the final document that is presented to the user.
We see the metahypertext as a large space that its author must manage. To do this well, the author needs to maintain a clear vision of both the document and the potential user models that will drive the customisation.
The top part of Figure 2 illustrates the relationship between WWW customisation and filtering. Suppose we want to create a WWW document that teaches the C programming language(Kay 1994). One solution is to write a series of hyper-books on the subject, for example, one for the mathematically inclined reader, one for the reader who is a potential Unix guru and likes to learn about C in terms of the operating systems internals, one that is especially written for people who know Pascal and now want to learn C, and so on .... Each of the can be published at a publication centre. When the user issues a request for a hyper-book on C their agent goes to the publication centre and filters all documents to find those that are substantial hyper-books about C. In addition, the agent carries relevant parts of the user model, aspects about their knowledge and preferences related to programming languages and learning these. The agent can use these to filter the collection of hyper-books on C to select those written for this user.
The lower part of the diagram illustrates an equivalent process based upon customisation. In this case, the author of a metahyper-book takes account of a range of possible classes of users and publishes this at the publication centre. This document should be selected by an agent seeking C hyper-books. Then the user model must be used to customise the metahypertext to produce the deliverable C hyper-books.
For example, document 1 is the sequence of small squares shown at the top of Figure 2. The same document could be produced from the the customisable document at the lower right of the figure if the right user model was used to create the customised document consisting of the small squares.
From the user's point of view, there is little inherent difference between the filtering at the top and the customisation at the bottom of Figure 2. From the author's point of view, the difference is a matter of being able to produce one coherent and integrated document that can be used to generate a range of documents for different users. In practice, it would be unlikely that the three documents illustrated in Figure 2 would be entirely disjoint: there would be some sections that would be provided for all readers and this is one of the reasons that the customisation approach has appeal for authors.
This example has been in terms of teaching a programming language, just one specialised teaching task. The same issues could have been described in terms of a broad range of other areas including individualised news, infotainement and other teaching domains.