The Workspace and Coderack in Copycat
The Hoftstadter and Mitchell's implementation, the slipnet is only one part of an elaborate AI based search engine. In fact, the slipnet primarily encodes the "axioms" or prior knowledge the system has about a particular domain. The true "intelligence", if any, or the system is accomplished through a tightly couples pair of structures known as the workspace and the coderack. Since Copycat's workspace and coderack are rather complicated structures, and to a large degree are implemented in a rather problem specific fashion, we will provide only a brief overview here. These structures might be compared to blackboard systems.
The metaphor behind blackboard systems is this:
A team of experts stands in front of a chalkboard upon which is written a problem that they wish to solve. Each expert watches the board carefully and whenever possible adds any information that she can. Collectively, a large body of information is gathered, and eventually some expert is able to take the final small step that solves the problem.
In Copycat, the workspace corresponds to the chalkboard, and the coderack, together with the information encoded within the slipnet, corresponds to the team of experts.
The workspace is where the "working hypotheses" for a problem are developed. Whereas in the slipnet, the 'topological' structure of the network is static (although activation of nodes and length of links may change), in the workspace the very connectivity of the system is constantly in flux. Copycat utilizes a rather elaborate workspace structure, creating "bonds" between objects within the workspace, collecting objects into "groups", and creating "bridges" between groups of objects. The coderack guides this evolution through a probablistic heuristic.
The coderack is essentially a probablistic, prioritized queue of snippets of code called "codelets". Each codelet can either construct or destroy relations between objects within the workspace, or add or delete other codelets from the coderack. Each codelet has a "priority" which signifies how relevant Copycat believes the potential action to be. Codelets are selected to be run in a randomized fashion, so that every codelet has some probability of being run, but those with high priorities are more likely to be chosen. (In particular, Copycat utilized a "roulette wheel" selection routine.)
Initially, the coderack is filled with "exploratory" codelets, that look for, and eventually reify relations between objects in the workspace that exist within the slipnet. As these "bottom-up" codelets run, a general "sense" for the problem is developed, and a more concrete structure is created. This structure is either strengthened or destroyed by "top-down" codelets that examine particular aspects of the construction. Eventually, Copycat settles upon a particular way of looking at things, and this perception is used to generate a final solution.
Although Copycat performs rather well, and comes up with both reasonable and creative answers to the analogy problems it is presented with, Hoftstadter and Mitchell's implementation of the workspace is largely problem specific. The ROD model corrects some of these problems by constructing a slipnet and query system that form a "closed" system--so that in RODM, the structures built within the workspace are simply subgraphs of the original slipnet.
The general structure of these componentents within RODM is fairly clear. The workspace is just the existing query space and the coderack should be a fairly straightforward application of Copycat's design (each codelet would conduct a RODQL or related query upon the workspace). There is some difficultly, however, in designing a system that minimizes the dependence on user's ability to design and code slipnet knowledge and RODQL queries. We have chosen not to implement the second phase of the project until these issues are resolved, but have some thoughts on how one might design the system.
It seems that many AI problem domains (those that are more than straightforward, if difficult, computation like vision and speech recognition) can be divided into to two broad categories: problems of search and problems of discovery.
The search category includes theorem provers and planning problems. For these, the knowledge base (slipnet) takes the form of a collection of states and of rules that specify how might one get from one state to another. (Analogously, we might look at the slipnet as a collection of axioms and properties and a set rules of logical derivation.)
For these problems the workspace we must construct a sequence of nodes and links that take us from our intial state to our goal state. The constructed sequence may consist of links already in the slipnet, or of those "implied" by rules of derivation. It is the construction of these rules of derivation that are the most difficult aspect of the problem. Ideally, one could separate the basic rules so that a similar collection might be applied to different axiom sets. Perhaps the solution is to introduce "conditional" links, that state that "X implies Y", so that if we have the node "X" within our workspace, we are free to introduce "Y".
Problems of discovery are those for which we have no direct representation within the slipnet. The simple form of these problems is analogy building, like Copycat was designed to tackle. A related but more difficult task is the problem of learning, where we want the system to recognize and internally codify some pattern or patterns. An example of this might be having the system devise a strategy to play chess by actually playing the game. The slipnet might then be simply a collection of the basic rules and concepts, and the workspace would be constructed as a collection of strategies.
The difficulties proposed by problems of discovery are in expressing the terminating conditions of a search. For a planner or theorem prover, it is easy to know when to stop--when we've reached our desired state. In analogy problems, the termination criteria are much "fuzzier".
One solution for the analogy building domain is to assert that the program must discover and refiy some structure within the workspace, namely a relation between the "A" and "B" portions of the analogy, one between the "C" and "D" portions, and a meta-relation that links the two. Of course, not just any relation will do. We must assert that there is some meaningful bond between the two portions of the analogy.
Developing a "problem statement language" that incorporates all of these domains without requiring a doctorate in computer science from end users is clearly not an easy task. This development is planned for the second phase of the project.