There is a spectre haunting cognitive science: the spectre of Humorlessness. Well, actually it doesn’t really seem to haunt cognitive science very much, but it should. This paper is about a proposed new implementation of the CRCC/FARG approach to cognitive modeling (the parallel terraced scan), which goes by the modest little name of "Magnificat". Magnificat is an attempt to recast the approach used rather successfully in Copycat, Metacat, Letter Spirit, and TableTop into a more general cognitive model, in the course of which we will attempt to make a stab at some of our favorite cognitive phenomena, such as, well, humor, language, intention, dialog, analogy – you know, all that simple stuff.

Along the way my own personal goal is to produce some software components which can see generally useful application in real-life problems; the parallel terraced scan concept is something which I think could have a great impact on a number of messy applications for which no particularly principled or indeed halfway good solutions exist.

The incarnation of FARG philosophy that we call "Magnificat" deserves a more detailed introduction. In studying the existing FARGware (consisting of CopyCat, MetaCat, TableTop, and the various stabs at Letter Spirit) I was struck repeatedly by what seemed to me a certain narrowness in conception. Well. The word "narrowness" is too harsh and not really what I mean; I certainly don’t want to denigrate this work, because every one of these implementations of the basic parallel terraced scan is brilliant, a thing of beauty and elegance.

But, for instance, in email correspondence with John Rehling about his experiences with Letter Spirit, he mentioned what seemed to me to be a very surprising thing: in his opinion, only about 20% of the code of Letter Spirit might conceivably be reusable in a different domain. I was somewhat dismayed. I had hoped to look at the various FARG implementations, come up with a common ground of some sort, and then produce a reusable software component.

Instead, I discovered that what unites the existing FARGware isn’t so much a common codebase, but a common philosophy of construction. This is understandable, but disappointing. Surely the domain in which a given FARGware implementation operates should be relatively interchangeable, right? We’re after a description of cognitive processes here, after all. Isn’t the basis of cognition itself the same thing, whether we’re solving letter analogy problems or building gridfonts, designing software or translating poetry?

When I spoke the very first time with Doug Hofstadter about my possibly joining CRCC, he also expressed a little disappointment with the outcome of the various implementations. Obviously, he likes the fact that they work, and that they do so in a cognitively extremely plausible manner. But it seemed to him that they fall somewhat short of, well, cognition. It is, he said, as if we had constructed an insect which solved letter analogy problems. It does so very intelligently, but without pizzazz. Without humor. Without any real understanding as to what it was doing, and why. (These are not quotes; I’m constitutionally unable to quote. They’re paraphrases of what I remember from that initial discussion.)

Of course, I was quick to say that I could solve this trivial little problem. I may not be the world’s best businessman, but life as a sole proprietor does tend to reinforce any marketing talent at all. So we embarked on a series of discussions (with my partner in crime Jay Muller) about Life, the Universe, and Cognition, in which we discussed (among many other things) what it is that we hope to achieve in the next iteration of the FARG software. And somewhere along the way we came up with the name "Magnificat." It was either that or something like "Punchlion." Very Hofstadterian in nature, that name, and of course we all wanted to have some reference to felines in the name, but I was hoping for something a little more impressive, and darn it, a lion just isn’t precisely a cat, now is it? So Magnificat it turned out to be.

So: what do we really want Magnificat to be? That’s a complicated question, and it has a number of different answers, but a wish list might include some of the following things:

• Magnificat will be restricted initially to the letter analogy domain, but the basic underlying architecture must be easily extensible to arbitrary domains.
• The ideal Magnificat, the magnificent Magnificat, should have a sense of humor. It should appreciate letter analogy problems for what they are, and what they aren’t. It should be able to propose new problems that occur to it, and tell you why they’re interesting.
• Magnificat should learn.

"Slow down," you’re saying, "what was that second point there? You can’t be serious." I suppose we’ll see how serious we are, a few years down the road, but – yes. We’re serious about humor. (Get it?) Humor, you see, is intimately bound up with analogy, frame blends and breakage, expectations and their fulfillment or defeat – in short, humor is cognition at its most sublime. High-flown language, I suppose, but this point deserves some attention, as it’s bound up with something that bothered me about the FARG approach before I spent so much time trying to understand Douglas Hofstadter as someone other than the author of a couple of books I like.

When I first saw the letter analogy problem domain, I thought, "what a silly little toy. Why in the world do serious researchers write programs to deal with little things like that?" I’m fairly confident that most people see things this way, which is, I believe, one of the reasons that the FARG architecture (or "FARGitecture," as I prefer to elide it) has seen so little exposure in the software community. This is despite the fact that I can think of three or four applications offhand which would be extremely difficult on their face, but which would be at least manageable with a drop-in "Copycat module." In fact, it was the desire to use the architecture in one real-world situation (text categorization) which originally brought me back into contact with it and led, indirectly, to my eventual association with CRCC.

After continual exposure to letter analogy problems, however, I have begun to understand their attraction. Of course, I suppose an analogy could be made to cult membership, but I think I haven’t been so much brainwashed as simply educated. There really is a lot of depth to the domain, even though – and this is the crucial point – it’s manageably small. The problem with building something you can reasonably call "cognitive," of course, is that it’s difficult to draw lines. You can’t have an artificial intelligence just spring full-blown from your lab into real life, Athena from Jupiter’s brow, ready to run out and do whatever it is gods do, understanding the Wall Street Journal from day one. No, you have to start small, even though it’s hard to find capital that way.

So what do you do? You choose a domain with just a handful of concepts, but one which you can reasonably say represents all the best in humanity: esthetics, elegance and inelegance, surprises, tradeoffs. The letter analogy domain has all these and more – it even has humor. Granted, I have yet to get a real belly laugh from a letter analogy problem. But you can construct a set of letter analogy problems rather easily which lead the solver down a garden path, for instance, and when it realizes this, it should be able to laugh, to say, in effect, "You can’t be serious! That’s like saying this!" And that, in a nutshell, is what Doug Hofstadter has always wanted to see from the FARGitecture: by avoiding the overhead of attempting to construct a model of the entire universe of human discourse, we can instead concentrate on tiny examples of human behavior, like appreciation of humor and elegance (to my mind, the existing FARGware implementations are focused most closely on elegance.)

But this goal has been attained only in part. An illustration from the gridfont domain might help explain what I mean. Letter Spirit can only conceive of letter forms which conform to the grid. There is simply nothing else in Letter Spirit’s world. This necessarily limits its creativity. A human can easily conceive of a letter form larger than the grid, for instance, and then afterwards explore what might be necessary to play by the rules, to force the letter into the grid. The result might even be humorous – the entire font might end up being a joke. Letter Spirit, however, can never get that joke, as the Grid is All. There is simply no way that Letter Spirit could comprehend a joke that included anything outside the grid.

In other words, the constraints of a puzzle domain, for a human, are challenging, in the sense that coping with the challenge of meeting the constraints has the potential to draw more creative work from the human being. If, however, we build software to deal with the puzzle domain and only that domain, the rules aren’t just challenging constraints; they define the universe. Letter Spirit is not "playing by the rules" when it builds a font. Letter Spirit is in a real sense doing nothing more interesting than, oh, digestion, or oxidation. Gridfonts are somewhere around its metabolic level.

That’s why there’s something missing. None of the FARGware is having fun. None of the FARGware is even capable of having fun, playing, and making jokes. It’s all deadly earnest stuff. It’s not particularly human. The conclusion might be that the domain is too small; that we’ve thrown out the humanity with the bath water.

What’s the solution, then? Do we need to have fun-finding algorithms, humor codelets, jokers in the deck? I think that this would be completely missing the point; I think we’ll get where we want to go, if we’re more serious about modeling concepts. Now, I still hear your protest: "But you’re the Center for Research in Concepts and Cognition! What have you been doing all these years if not, well, researching concepts and cognition?" But I mean it – what FARGware isn’t doing is defining a common infrastructure to deal with concepts. Yes, in a certain sense the Slipnet represents the relationships between concepts, and in a certain sense the codelets which build structure in the Workspace also produce a sort of emergent understanding that corresponds to concepts. But there’s the rub – the codelets are specialized little pieces of software. They’re rigid, even if the architecture that uses them is not. The structures they build are carefully crafted and hand-tuned to represent a domain, and that’s really the essence of the problem: the domain is defined by the codelets, not by an abstract set of descriptions or encodings of situations which I’d be comfortable calling "concepts."

What we need, then, is a slightly different approach, one which I think is more cognitively motivated. Instead of dealing directly with pieces of, say, a letter analogy, Magnificat should be dealing with pieces of concepts which represent a letter analogy. This feels like introducing a useless layer, as it could be (and is) argued that structures in the Copycat/Metacat Workspace are themselves the concepts they represent; yet the problem is that their semantics are deeply intertwined with the workings of the codelets and the specific connections in the Slipnet.

Instead, if Workspace structures simply describe the concepts they represent, we gain two things: first, the codelets that manipulate these hypothetical abstract concepts should be much more general. Second, the concept structures should be amenable to arbitrary definition. Their semantic content should be transparent, changeable, even learnable. Indeed, we should in principle be able to make the system learn on its own, by remembering past episodes and generalizing to present circumstances.

Really, none of this is particularly surprising. What I’m proposing is analogous to the leap natural evolution made from non-human to human intelligence: instead of working with concrete things, the human mind abstracts out symbols and pushes them around. Dangerously loaded words here, aren’t they? I’m not proposing a return to symbolic computing, after all, not in the sense commonly used in the AI community. At least I don’t think I am; the symbols I mean are much, much richer than the sere trees of LISP. But the symbolic camp would have us believe that the difference here is one of quantity, rather than quality… We’ll see if they’re right. I don’t think so.

Magnificat, then, instead of having working structures corresponding to specific pieces (or potential pieces) of a letter analogy, must have richly connected, internally complex structures. By introducing a conceptual description, we hope that Magnificat will make something of the leap into the human that we hope to see.

Of course, none of this postulation is going on in a vacuum. I have a specific plan in mind; this is a particular Magnificat I’m talking about, not just any arbitrary selection from the vast space of possible Magnificats. I plan to use the FARGitecture to implement the cognitive grammar model of Ronald Langacker, or at least something very similar to it. I didn’t choose that arbitrarily, either; my interest in Langacker’s theory and Copycat roughly coincide, both dating back on the order of a decade.

I first heard of Langacker when he gave a talk here at Indiana University. My friend Jennet Tillotson told me I should go hear his talk – and she was right! For some odd reason, the talk was held in the Optometry building. Having been to a couple of linguistics talks before, I was prepared for lots of fairly small, really cool examples from various languages, which would make me want to run out and learn, say, Swahili. Instead, the entire talk was an analysis of one single idiom, as far as I can remember: the English idiom of "let the cat out of the bag."

What captivated me was that Langacker used pictures to demonstrate his analysis. These pictures, basically little symbolic cartoons, seemed somehow to resonate with the way I was thinking about concepts and mental processes.

Here’s what the diagram looked like, to the best of my memory and Word’s graphical rendering capabilities:

Admittedly, this little diagram is a tremendous and egregious oversimplification of the actual meaning and usage of "the cat is out of the bag." And in fact, it’s a tremendous oversimplification of Langacker’s original diagram. What excited me about this approach, however, was its intimate way of showing syntax and semantics in the same structure. Instead of feeding me some line about a magical syntactical machine which would do its work, then hand things over to the semantics module to figure out the rest, Langacker was confirming my own intuition about the way language gets processed in my own head: there are a great number of different pressures and processes going on all at once, and their combined, synergistic result is an understanding of what it is I’ve just heard. Some of these processes are syntactic, some are semantic, others are more rarefied things, like what I think the speaker intends, or what I want to say next, or what I had for lunch, or the movie I just saw. Instead of breaking things into chunks, Langacker is acknowledging the wonderful chaotic soup we call "mind." I loved it on sight.

Moreover, instead of making a sharp delineation between syntactic structure and morphological structure, Langacker was actually proposing a multi-word structure which combined aspects of both: the idiom "let the cat out of the bag" is fully analyzable on a syntactic level and yet it behaves in part, at least, just like an atomic word; its meaning is different from the combined meanings of its components. It is at one and the same time a phrase and a lexeme.

This wonderful flexibility runs all through Langacker’s work. He’s continually looking at cases where traditional linguistics has a tendency to throw up its hands, and saying, "Look, this is still language, it’s still linguistics, but at the same time it’s cognition, it’s thought and perception and intention all rolled up into one." And so, as a programmer, I immediately wanted to use this quintessentially human approach to language to construct a computer program to work with language. John Searle and Joseph Weizenbaum notwithstanding, it’s my firm belief that software can be imbued with humanity; after thirteen years of professional programming, I know as firmly established fact that computers have whatever it is we call "mind," if in very small amounts to date.

Thus I was led back to the parallel terraced scan. It also embodies a wonderful chaotic soup, and so it has always been perfectly obvious to me that to build Langacker’s model there is no other architecture which could possibly fit better.

The step from [Copy|Meta]cat to Magnificat really isn’t terribly great. The basic mode of operation will be the same: structures are built in a workspace. The instances (tokens) in the Workspace correspond to lexemes (types) in the long-term memory, which is the new implementation of the Slipnet (except it isn’t, quite: read on for why). Instead of Slipnet, I’m calling it the Lexicon, because it is where concepts are stored. The Lexicon is far more complex than the Slipnet; the latter consists of zero-dimensional nodes, but the "nodes" of the former are themselves structures that contain other structures. More on this point later.

The basic method of processing in Magnificat is still the stochastic invocation of codelets; codelets still have urgency which influences how probable it is that they’ll run. Instead of a global temperature, however, individual structures in the Workspace will probably have "temperatures" consisting of variable levels of attention, which indicate their felicity. Thus well-built structures will gain stability.

Where Magnificat differs is in the structure of its Lexicon, the domain-generality of its codelets, and the fact that it could conceivably create new concepts in its Lexicon (i.e. it can fix memories. Metacat has a memory, but it is fairly limited in scope.) The Lexicon describes the domain in which Magnificat will work. Thus instead of building codelets which understand the letter analogy problem domain, we will build codelets which "simply" manipulate concepts which are either built from input or retrieved from the Lexicon.

The basic unit of the lexicon is … well, Langacker calls it the "unit." The word "unit," however, is unfortunately already in use in about ten million different ways, most particularly as a node in a neural network, so I often use "lexeme" instead, even though that still invites confusion (a "lexeme" in traditional linguistics usally means a single word, whereas many, if not most, of Magnificat’s lexemes will have no particular word attached). The lexeme is certainly a very different thing indeed from a neural network unit. A lexeme can be thought of as a very simple concept. A full concept is a vast cloud of interconnected lexemes and potential lexemes, what Hofstadter calls a "conceptual halo."

Lexemes contain other lexemes. In the "cat is out of the bag" structure, you see a cat and a bag, for instance. The larger meaning of the phrase also contains "secrecy" and "secret." Langacker calls containing lexemes "domains." A sublexeme thus has a position in that domain. The ur-domain is the visual field, and languages often treat abstract domains in a spatial way, using explicitly spatial prepositions such as "over" or "in." Other examples of not-so-abstract domains are, say, the color domain, or the temperature domain. Various extents in these domains have names, like "red" or "hot," and we use an object’s extent in that domain to assign it adjectives.

But domains can be abstract as well, so that the "in" lexeme has two extents, the outside thing and the inside thing. This same situation is also used for the "outside of" lexeme, which is identical to the "in" lexeme except that it profiles its components differently. (Profiling has to do with which components are the backdrop and which in the limelight, so to speak: Langacker uses the word "trajector" to mean the focal components, which I find a rather pretty word.)

The meaning of a lexeme is thus some kind of conglomeration of the pieces of meaning it gets from its participation in other lexemes. The entire set of relationships is what determines its meaning, its unique flavor. This conceptualization of the lexicon is an extremely attractive one. It takes into account so many of the things that contribute to the beauty and flexibility of language – and it doesn’t preclude covering non-linguistic phenomena with the same mechanisms. You can easily imagine a completely non-linguistic "lexeme" (if you’ll forgive my use of a linguistic term to describe it) which consists of the hand movements required to open a door using its doorknob, for instance. Those hand movements are commonly referred to as a motor program, and obviously (very obviously) form part of the human meaning of "doorknob" and indeed other words such as "door," "open," and maybe even "enter." At least in America, they do. In Europe, they don’t have doorknobs, but instead door handles. So obviously the meaning of "enter" is ever so slightly different for a European than for an American.

My proposed implementation of this model is pretty simplistic. I foresee two basic databases of concepts, the Lexicon and the Workspace. The former is long-term memory and episodic memory, and contains concepts, while the latter is short-term memory and contains tokens of concepts. A token is bound back to its concept, allowing very complex interactions between Workspace tokens simply on the basis of their structure. However, there is a set of codelets operating simultaneously on the Workspace, comparing and contrasting, building expectations and tearing them down: building brand-new structure. A further process at work is a recall process, which continually looks at Workspace structure and looks into the Lexicon for similar things. Recall is not an all-or-nothing process; instead, structure is pulled into the Workspace bit by bit, as urgency demands. If an instance of recall is particularly powerful (it matches structure and fulfills expectations well, thus resolving questions) then its urgency will cause it to proceed rather quickly and completely, but if a memory fits a situation only vaguely, then it will influence the structure in the Workspace only vaguely.

Looking back over that paragraph, I realize that I’ve described, or rather failed to describe, a structure which is somewhat new to the FARGitecture: the expectation. This notion is borrowed from Langacker, and I use it to mean a marker set up by a comparison or scan process, which signals, basically, "I expect something here with such-and-such characteristics." An expectation can be seen as a scan in progress – it wants to be fulfilled with something, be that something additional structure in the Workspace, or structure it builds in the Workspace, or structure copied from the Lexicon. I expect the expectation to be a rather powerful organizing force in Magnificat’s operation.

That is a fairly high-level description of the Workspace; now what, precisely, is the Lexicon? The Lexicon is simply a database containing all the lexemes in the conceptual universe of Magnificat. As mentioned earlier, it corresponds to the Slipnet in earlier work, but where the Slipnet’s nodes are structureless (the structure of the Slipnet is embodied in its links), the lexemes of the Magnificat Lexicon are richly structure and interconnected. Moreover, the state of the Slipnet is a part of the state of the entire system in Copycat/Metacat, but Magnificat’s Lexicon is a static structure, with the entire state of the system being reflected in the Workspace.

So really, it may just be a red herring to compare the Lexicon with the Slipnet. However, since people will inevitably do so anyway, it’s probably a good thing that I nip it in the bud here and now. The Lexicon is a source of structure; concepts from the Lexicon are copied into the Workspace in order to impose structure on the current situation. The Lexicon, therefore, gives meaning to the current situation. (Oho! Strong words indeed!) The Slipnet, in contrast, determined contextual meaning of various concepts in the context of the current situation. I’m uncomfortable with this wording, but it comes close to expressing the difference I see between the two approaches.

To round out the architectural Trinity, we need to describe the Coderack, which is essentially unchanged from earlier implementations. The Coderack is the current state of queued codelets, and codelets are chosen to run based on their urgency plus a random element. In Copycat, the random element is determined by the overall "happiness," or temperature, of the system; in Magnificat, I’m not entirely sure what will do so. Intuitively, I’m bothered by the global temperature of Copycat, and I feel as though it should be a more locally determined thing, but in point of fact I don’t yet know how these vague suspicions should be implemented.

The Magnificat Coderack, however, consists of queued codelets; each codelet is attached to some structure or structures in the Workspace. Many of these structures will be expectations. I suspect that each Workspace structure will itself have an urgency or saliency value associated with it, and these values will influence the choice of codelets in some way. We’ll just have to muck around with the details and see what works.

The question might have arisen in your mind, "How does all this get us to humor, language, intention, dialog, analogy – you know, all that simple stuff?" Aha! I’m glad you asked! I have absolutely no evidence to go on except my own intuition. However, I’m convinced that the basic FARG approach is exactly the right one to take. You can easily conceive of a FARGware program, for instance, which was constructed to show the analogies in a set of jokes. Metacat itself is a FARGware program which builds analogies between letter analogy problems, thus introducing a meta-analogy level. By introducing a level of representation, I believe that we’ll be giving Magnificat the same open-endedness that human language itself provides. Thus if we don’t "automatically" gain some glimpse of all those neat cognitive phenomena listed, we will surely be one step closer to them.

What I’m doing, in essence, is giving Magnificat the ability to construct its own FARGware implementations. The very open-endedness of our minds is what makes us human. It’s my hope that the open-endedness of Magnificat’s architecture will demonstrate that point.