[Up: JB] [Map] [No prior] [Robot Wisdom home page]
[I was freed to write this truthful memoir of my years as a programmer at Roger Schank's Institute for the Learning Sciences of Northwestern University, when Schank fired me at the end of 1992, for asking for a forum in which to present an original idea to the group.
It was posted first, one chapter at a time, to rec.arts.int-fiction, in late January 1993. It was reposted in approximately this form to comp.ai in early February. My intention in writing it was to subvert any attempt Schank might make to blacklist me, by explaining my side of the story in a lively, open and honest way.
Although I was trying to aim my explanations for interactive fiction amateurs, I think in many places the writing is still way too complex. Sorry.]
I didn't really hear about Roger Schank until 1987, from a student of his, Kris Hammond, who had just been hired out of Yale by the CS department of the University of Chicago. I phoned Kris out of the blue after hearing him on the radio talking about his planner "CHEF", wanting to ask him about planning within videogames. He referred me to Abelson and Schank's "Scripts, Plans, Goals and Understanding" (locally pronounced spuh-GOO). It's definitely my personal favorite among Roger's books, because it wrestles unapologetically with the absurdly difficult question of whether a small finite set of symbols can represent the full breadth of human experience.
I was dreaming of a videogame that went beyond the take-drop-use-fight cliches of adventure games. Schank's "CD notation" offers a set of verbs that may be boiled down to:
give-take-make-move thing
give-take-make idea
insert thing into thing (ingest, but also enter)
extract thing from thing (expel, or exit)
These are inarguably general, but somewhere in the generalization process all the interesting story content got bleached out: an 'insert' into a body may be food or drugs or poison or penis or semen or scalpel or Jarvik heart or shiv or bullet or midget-sub or gerbil... and even ideas might be seen as insertions into the head...!
So in '87 Hammond turned me on to A&S's SPG&U. And I was delighted, because everything I'd been sampling on the bookstore shelves, AI-wise, seemed just depressingly unconnected to my practical goals. One tiny exception, in an anthology on 'the Frame Problem', was a synopsis of the "histories approach" to that problem: in modelling the world, you can reduce the amount of background detail you have to keep track of, if you can analyse out a finite set of qualitatively distinct life-histories that the system can embody. Eg, a charged particle aimed towards a small target may be: a) refracted, b) reflected, c) absorbed, or d) transmitted-without-change. Each of these stories has an infinite range of mathematically distinct instances, which might be described to any ridiculous degree of detail/precision, but the most useful, practical, tractable, compact summary of any particle-interaction is just to classify it, in two bits, as one of these four 'histories'.
So who's compiling the catalog of human histories? What's it look like, already? For interactive fiction, you want to know, eg, when an elf meets an orc, what different ways might the meeting go? Fight, communicate, gift, theft, etc etc etc... but who knows what shape an exhaustive inventory of such histories, broad enough to support true interactive literature, will assume?
As regards planning, I got the sense from Hammond that not a whole lot of progress had been made since the 1960's game-tree-exhaustive- combinatorial-search approaches. Hammond called his CHEF a 'case-based' planner, effectively a histories approach to planning: pick an old plan from the set of known plans and twiddle its variables until they fit the current task. But he admitted that CHEF's successes were real limited.
And then after a couple of visits Kris got too busy to go further, and I wandered off on my own path (compiling a histories-based analysis of romantic love, actually!) until in 1989 I heard that Schank was moving from Yale to Northwestern, and mailed him my application for employment...
Very likely if I hadn't gotten in on the ground floor of ILS the way I did, months before it officially existed, my job-application would have disappeared in the first cut, because I have no degree, and all my experience had been in videogame conversions. In their first months ILS was doing a lot of hiring, with not a lot of advance public notice. So I was in the right place at the right time... but I have to give Schank credit for taking a chance on me.
In my approach letter I was totally outspoken about my sense of Schank's work as 'on target' in a unique way... which surely helped my chances! What I came to understand in those first weeks was that Schank's "scruffy school" of AI saw themselves as a fairly lonely island of story-content- savvy realism in a desolate sea of "straight", math-and-logic-oriented AI. (I wonder now if there aren't other factors contributing to that communications gap. Be aware that I see myself as a post-Schank Schankian -- I consider that Schank himself is Schankian AI's worst enemy! I'm even inclined to call it Abelsonian AI, after that much more honorable man...)
At that time (Sept 1989), ILS had about 50 people-- faculty, grads, programmers, and admin. Schank's PR-image for ILS has been that they are "trying to fix the schools" by building educational software that better fits the natural ways students learn. Most of ILS's financing comes from corporate sponsors like Arthur Andersen accounting, who spend such huge sums on training their employees that they can afford to risk a few million more on fairly basic research.
The first encouraging connection I made at ILS was with Andrew Ortony, who'd just published (with Clore and Collins) "The Cognitive Structure of Emotions" (about $12 paper from Cambridge U.P.). I love typologies, and the emotions-typology in this book is certainly the only one I've ever seen that shows real, careful analytic thinking, identifying several distinctly 'orthogonal' dimensions. Ortony et al. (aka OCC) sort emotions into three superclasses-- event-oriented, person-oriented, and thing-oriented:
Emotions about things: liking, disliking.Emotions about persons: approving, disapproving.
about self: pride, shame.
about others: admiration, reproach.Emotions about events for self: pleasing, displeasing.
for other: gloating, pity, resentment, happy-for.
about events in the future: hope, fear.
realized (positive): satisfaction, relief.
realized (negative): disappointment, fears-confirmed.
(This last is a nice instance of a 'new' emotion predicted by theory, like the positron in particle physics.)Emotions about another person's role in events: gratitude, anger.
about self's role: 'gratification', remorse.
We were conscious of the narrow gap between this theory, and (in particular) Chris Crawford's "Trust and Betrayal: the legacy of Siboot", built around a little society of creatures who approve and disapprove of each other's actions. (Siboot was also held up around ILS as an enviable implementation of the inverse-parser concept: you can build sentences in that game from elegant iconic menus. Crawford is selling the source for $150 but I haven't seen it yet. You can get his address from the r.a.i-f FAQ.) Ortony's student Clark Elliott has since implemented a microworld of hot-tempered taxidrivers using this analysis. You can order his thesis as an ILS tech report-- see below.
So here, clearly, was one little piece towards the 'inventory of human histories' that I was after. Ortony wanted to follow up this 'cognitive' theory of emotions with a look at the 'affective' side: given that what emotions we feel depends on such factors as approval and anticipation, was a similar analysis possible of how one acts in consequence of each emotion? We were looking at categories like what sounds and movements you'd tend to make, where your thoughts would be directed, etc. But at this point we drifted apart, and I'm not sure where that work stands now. I don't think Ortony has taken the step of asking, for each emotional category, what are the usual 'human histories' it plays a role in, which is where I'd like to see him go.
Andrew sees himself as a psychologist, which normally sets off danger alarms for me-- one alternative way of posing the 'inventory of human histories' question, it seems to me, is to ask: what will be the section-headings in the ideal psychology text of the future? I consider that the current cluster of paradigms that pass for 'scientific' psychology and so dominate the psych texts, are hopelessly bogged down in jargon and speciously imitative 'scientistic' methodology, and anybody who tries to conform to those standards is just wasting good brainpower. :^) I expect to see that whole realm cannibalized from without by survival-of-the-fittest among interactive fictions-- any other sort of 'lab-work' in psychology is hopelessly premature. You can't measure behavior if you don't yet have a model of its dimensions!
(Imagine an IF-development environment sophisticated enough that you could, eg, feed in the ethical codes of every sort of human philosophy or religion, letting you explore the stories that result when they interact! Now that I'd be proud to call psychology!)
In our first weeks at ILS, the new hires all got a short'n'sweet overview of Lisp programming from Chris Riesbeck, and a nice shiny Macintosh each, with Macintosh Allegro Common Lisp (MACL) to start experimenting on.
Anyone who gripes about the profligate way Lisp uses parentheses is completely missing the point. Parentheses are just the simplest possible way of depicting tree-structures. For instance, the tree:
A B 1 a b 2 C
is topologically equivalent to: ((A)(((a)(b))(2))(C)). Lisp requires exactly as many parentheses as it needs to define such trees, and no more.
(G. Spencer-Brown's "Laws of Form" (1969, out-of-print-- an underappreciated masterpiece) formalizes this level of abstraction very elegantly, in the domain of Boolean algebra.)
Using this uniform notation system for both data and program, as Lisp does, allows one to decompose more-complex structures into simpler ones, and to take advantage of structural similarities between units of different overall complexity.
MACL is a big comfy chair of a programming environment, very quick for prototyping, very easy to maintain and modify if used wisely, but pretty much of a bytes-and-hertz hog. (SIMMS and speeds being what they are, though, these days, it's quite an excellent choice for lots of sorts of exploratory development.)
The latest version of MACL uses the CLOS (CEE-loss) object system. I think it might not be too radical to divide the history-to-date of AI into two periods, the first characterized by exploration of the concept of abstraction hierarchy (c500 BC to c1980), the second by "object-oriented programming," where the program's vocabulary of 'verbs' is distributed across an abstraction hierarchy of types (and their instances), with more-specialized nodes inheriting verbs from the generalizations above them. Perhaps the next era will arrive via a neat solution to the CLOS meta-object-protocol problem, analysing the most-elegant internal mechanics for connecting types, instances, and code-methods.
I'm chasing after the idea that we might view code-segments as the histories (or stories) of their parameter/argument/variables, so that the "+" story is one of the usual, useful stories you'd want to tell about two integers, and "show-view" is ditto for a data-object and a user, and "edit-hierarchy" ditto for a programmer and a knowledgebase. In MACL's CLOS, all the interface objects like windows and menus end up in the same overarching hierarchy with all the data objects one chooses to represent (eg persons, places, things), so using the story-history metaphor for both looks like potentially a neat 'win'.
Here's Doug Lenat on Lisp vs Prolog (this is from a book commissioned by Texas Instruments and distributed by Radio Shack, a combo about as tasty as a 9-volt battery shorted across the tongue ;^)
Q: How does Prolog differ from Lisp?Lenat: There has been a constant dream in AI, by a large fraction of people in the field for 25 years, of the form: there really ought to be some way of formalizing and axiomatizing human thought and reason. But time and time again, all attempts at axiomatizing things have led people to trivialize them, to the point where they no longer apply to what they were originally modelled after in the real world.
There are a lot of people in the field who want to be sure, who want to believe that they can get absolutely precise, logically guaranteeable models that are close to what is going on in the real world. If you believe that, then the kinds of operations you want as primitives are logical operations, those involved simply in theorem proving. Those are the sort of operations that are present in Prolog.
Q: Why is Prolog used more in Europe than in the U.S.?
Lenat: In most European countries [and elsewhere- jb], you have very rigid hierarchies of 'ancient' professors, and then younger professors, and then research associates-- and then it filters down about seven levels to the people actually writing the programs. It is the people at the top who decide what research is going to get done, not the people at the bottom who have experience with what is actually happening.
The people at the top-- who [may] want to believe in a nice, simple, mathematical, axiomatizable universe-- basically determine the kind of research that is going to get done. The experiences that would lead them to change their minds are simply not occurring to them, they are occurring to the people at the bottom, who have no say.
Q: Is Prolog used in the Japanese 5th Generation Project for the same reason?
Lenat: In Japan, they use Prolog mainly because it is not an American language; it adds to their national spirit and pride to be removed from what is going on in America. But if you look real hard, what the Japanese have done is to build Lisp-like functions on top of Prolog so that by now it is hard to tell what language they are using. They would have probably been about two years ahead if they had used Lisp to start with instead of Prolog.
from "Understanding Artificial Intelligence" by H.C. Mishkoff, 1986.
[Although I put down this book, if you don't judge it by its cover its signal-to-noise (S/N) ratio is totally admirable, and my stickerprice shows an unbelievable $3.95 in 1986 dollars. If this were, say, a British import, it would be way cool, but as it is I'm always having to apologize for giving it shelfspace.]
[Someone on r.a.i-f took issue with Lenat's attack on Prolog, and thought he may have outgrown that opinion. Anybody know? It seems clear to me that you can rewrite Prolog in Lisp a lot easier than vice-versa...]
[This chapter, and #6, are fairly technical. I will be proposing some simpler ways of looking at this material in later chapters, but at this point I'm trying to retrace my steps at ILS.]
If you enumerate all the interesting categories of 'human histories' on indexcards, all the stories of emotion, every plausible configuration of events you'll ever need in an interactive fiction (elf meets orc, villain plots counterattack, boy kisses girl), and lay them out on the floor (of a gym, figure... it's gonna be a lot of cards!), so that as far as possible the most similar ones are closest together... what's the overall pattern?
If you then stretch lengths of string from each card to all its most similar neighbors, and also to some distant neighbors that are maybe very different, but still similar in some important ways (analogous, contradictory-- all the ways our real, human brains seems to link stories)... is there a simple pattern to the crosslinks?
This, in fact, is the central problem of CBR, one Schank's been pursuing his whole career.
Long before 1989, it seems, the Yale school's focus of interest had shifted from SPG&U to Schank's next book "Dynamic Memory". DynaMem is credited with opening up the whole field of CBR, introducing the model of an indexed network of storylike cases. (The 'dynamic' part-- creating a memory that revises itself-- is still a dream. Just creating a static case-based memory structure turns out to be a plenty big problem.)
DynaMem suggested three sorts of longdistance link between indexcard- stories (which stories it lumpily termed Memory Organization Packets or MOPs):
1) Story X1 is one scene within more-complex story Y1;
2) Story X2 is just like the more-obvious story Y2, but with a different, unexpected ending (an "expectation failure"); and
3) Story X3 is a simplified version of story Y3.
#1 seems totally useful for IF-- it will always be most economical to analyse out all elements shared by two or more stories, and store them separately.
#2 was suggested by real-life observation of the sorts of stories that we're naturally reminded of in the course of the day-- we'll always remember the story of the time when things went haywire, not least so we can make sure that doesn't happen again! A planning algorithm in IF must similarly consider all the ways the planned story could go wrong, and even if it's not case-based, it will still have to use something equivalent to links like these.
#3 is the abst-spec link of traditional abstraction hierarchies, but its application to stories is not at all simple. One definition of simplification might be to remove 'scenes' from a story, one by one, to create more general stories, so that Y3 = X3 + X1. (Story X3 is boy-talks- to-girl, Scene X1 is girl-winks-at-boy, Story Y3 is girl-winks-at-boy- who's-talking-to-her)
DynaMem also speculated about a possibly-perpendicular hierarchy of "Thematic Organization Packets" that account for occasions when a story in one domain reminds us metaphorically of a story from a totally different domain-- her wink was like a door swinging open.... So stories X and Y, from different domains, may both point to an indexcard that presents a common abstraction of their themes: in this case, access-level- increased, where Door = Heart's emotional locks. (We will look more closely at these TOPs in a future chapter.)
The first case-based domain I was assigned to turned out to be meteorology, weather. We had (or thought we had) some money from the Navy to write training software for their weather-school. We were just going to make a modest casebase of weather stories, from balmy summer afternoon to hurricane tsunami. Students would look at a weather map and abstract out its features (by hand), and the tutor would retrieve closely matching cases.
Weather stories can be expressed pretty simply in terms of temperature trend, wind trend, cloudcover trend, precipitation trend, etc. Each of these 'slots' needs only a handful of possible fillers (the fillers for the slot TempTrend might be rising, falling and steady), and a way to search for the best match among the known cases. But before we really got started on the retrieval problem, the funding dried up... though in retrospect I can ask myself, how could we have built the network of weather histories as a CBR storybase?
The concept of 'scene' is easily generalized to the much-mushier 'feature', so 'cloudy' might be a scene within low-black-cumulonimbus- followed-by-thunder-and-torrential-rain. It would be quite natural to present the student with a weather situation along with the various ways it might go next: "Remember that time it was sunny and clear, and then a minute later all hell broke loose? Better take your raincoat-- it might happen again..."
In theory, 'simpler' weather-stories might treat one or two of the trend- dimensions (eg, temp and cloudcover) and ignore the others: more complex stories could then be created additively. (Some combinations would never occur in real life-- bald spots on the meteorological 'gym floor'.)
Alternatively, a 'simpler' story might follow all the trends, but for a shorter span of storytime, or in less finely-resolved detail. So the story "overcast" is a simplification of "overcast, then clearing later", and also of "overcast with a couple of places where the sun peeked through".
Choosing one of these classes of simplification is choosing an 'indexing scheme', effectively determining the sequence of menus that should be presented to a human user trying to navigate the storybase. So in the latter case, at any point you'd be offered a menu of scenes-that-might- happen-next, and in the former case a menu of other-features-that-apply-in- the-same-moment. There's a human-factors element to this, in that you must avoid overlong menus without resorting to confusingly abstract menu- items.
The 'indexing problem' is subtly different from the representation problem: you can sufficiently represent a weather story, but still not know how best to index it within a tree of menus so you can find it when you need it. SPG&U was mainly about representation, DynaMem shifted the focus to the general theory of indexing.
[Was this too 'heady'? Let me know if you found it useful. If you need more examples, check out Dynamem, or "Tell Me a Story". For programmming mechanics, look at "Inside Case-Based Reasoning" by Riesbeck and Schank.]
Standing back from the last chapter, it seems obviously to boil down to one elegant question: what does it mean for one story to be simpler than another? (Any part of a story must be simpler than the whole, is a partial answer.)
One might visualize the network of human histories as concentric circles (or spheres), with a central point of zero story content, the "null story", each ring adding a single quantum (!) of story content. Reallife instances will necessarily have infinite content (where, exactly, was that grain of dust between the ridges of your left indexfingertip?), so instances must stand as far from the null-content origin, as the sphere of stars is from our starry stares....
But can these content 'atoms' be enumerated? Are they finite? What are the toplevel headings of our story-inventory-textbook-tree? (Well, here's my answer: first-- person place thing motive, second-- person place thing motive again, and third-- the set of all simple relationships between whatever you choose for those first two. So if you choose 'person' and 'thing' you'll be offered makes-acquires-uses-breaks-disposes. But the last time I said that publicly, I got viciously terminated for my trouble, so I'm still a bit skittish... :^( ) ((Crosswordpuzzle clue hint: ILS has the not-invented-here syndrome real bad, where 'here' = between Roger's Rs!))
Back to 1989, or 1990, some random images:
There was a party I went to where someone described Schank's methodology as 'mere' introspection, to which I said, yea-verily. How else are you supposed to see what's going on inside you? Refusing to introspect doesn't make you objective-- coming to terms with your self-deluding, self-denying impulses makes you objective! So great literature is most often highly objective (that's what makes it great), but not at all distant or cold.
Almost everything I can say about parsers at ILS is hearsay, because I almost never saw one-- ILS philosophy is (correctly, I think) that the parser problem is too hard to bother with until the CBR-inventory- of-human-stories problem is solved. According to legend, Roger's old company, Cognitive Systems, managed to create only a single AI product that was actually used: an email router for a bank, called ATRANS. I heard ATRANS described as a case-based parser, because it worked by exhaustively annotating every turn of phrase this bank-office-email- router might need to understand. (This illustrates the Schankian principle of AI as the ability to handle realworld-scale casebases without drowning. See Schank's ILS tech report, "Where's the AI?" ...or on second thought, my paraphrase is probably adequate... :^)
Every so often on comp.ai, someone will inquire after an Abelsonian ;^) CD-parser, expecting that ILS (or someone) must have something they've been maintaining and evolving since the 70s. But CD is acknowledged at ILS as hopelessly unwieldy, and the 'next thing' has yet to arrive. (Charles Martin's Direct Memory Access Parser DMAP was the theoretical rage for a month or two-- I was almost reassigned to try and code it-- but it's also wholly dependent on the (expected) invention of an elegant CBR-memory to parse directly into!) [End of parsers part.]
A random poetic image from 1989, for armchair freudians and sex-magic mystics: once I'd established my competence, I was given a big raise and moved to a better office, by Schank himself. (The symbolism of chairs and offices at ILS is an adventure unto itself...) The night before I got this seal of approval, I had a dream that Roger invited me into his bed.... (praise dog, I woke up! ;^)
Which reminds me of another story: at a certain point I was assigned to index some randomly chosen stories (on video-- see next chapter), which happened to be a top ILS faculty member reminiscing about Roger's chair fetish. He told this story of Roger's spending a term in Switzerland, at some outfit where the director had the only 'good' chair in the building, so every morning Roger would steal it from the director's office, and every evening (!?) the director would claim it back. I resigned the challenge, because the indexings I was coming up with were operatic-prima-donna, or rock-star-with-M&Ms (see a.f.u FAQ again, I think, for the M&Ms). I see now I coulda gone with bully-forces-other- short-end-of-stick (which can be made to sound flattering if you rephrase 'bully' to 'macho stud').
Also, the big raise had a hidden cloudlining (an eternal ILS verity): I was told it would be retroactive to September, and celebrated by buying an expensive piece of fine art (a huge, pretty Calman Shemi wall hanging, if you didn't wanna know). When the raise came, the retroactive-to-September part turned out to be just 5%, with the other 30 or 40% starting from then on....
"Button theory" shows Schank at his most bozoic -- my unconscious mental image is of a brightly colored clownsuit with a row of fluffy pompoms down the front, the clown baffled by just what they're for.... Actual ILS software, currently consuming sponsors' funds, greets the user with a row of Schankian button-icons, the most conspicuous of which eternally drools "HUH?"
Button theory started from a seminar where a list of usual-educational- software-control-commands was compiled, with the admirable idea that ILS software would uniformly use a single panel of buttons for these uniform commands. The list included:
more/ less detail
what now?
why?
review
too slow/ fast
jump ahead
change tasks
The whole list, after repeated boilings-down, was still around 20 commands, and the proposed panels of icons overwhelmed the remaining screen area, while boggling one with their obscurity.
I had a hunch that there was an elegant design solution possible, and cooked up a panel of 20-or-so tiny 16-by-16-pixel Mac icons, unified by the (pc!) theme of Kid Button and her/his bike trip, following a natural chronology from preparation to starting out to taking a break to returning home to reviewing the day, with an 'uphill strain' icon and a 'downhill out-of-control' icon, etc etc etc. It was completely ignored by Schank, but the design principle of "The Menu Is A Story" stayed with me-- even the Macintosh 'File' menu tells a chronological Open-Close-Quit story (by this principle, it ought to be arranged Open-Save-Print-Close-Quit).
This principle was also visible in the natural shape that my 1987-88 inventory of histories of romantic love had taken. I read every love poem in every anthology in every library and bookstore I could get to (can you guess? it was unrequited ;^/ ), and compiled the best images into a frame that went from loneliness thru courtship thru failed courtship, successful courtship, relationship and breakup. I drafted similar structures for business psych (starting-a-business to bankruptcy, sending-a-resume to termination) and several others. But there are no anthologies of brilliantly evoked business stories, so these latter frameworks remain relatively unfilled-in! Ditto, interestingly, for relationship-problem stories. I was reduced to self-help books! (And then there was the mortifying foul-up where I returned one of these to the wrong library branch and had to spend literally months arguing about whether I owed them for "Love Stinks: true tales of jerk-ass boyfriends" or some such... ;^) One interesting result of the romance research was the vivid demonstration that human love-histories (!) are identical whether you're talking ancient Egypt, aborigine, medieval China, Swahili, or Palookaville... [Now partly online]
I also suggested around ILS, once or twice, resigned, that the buttonpanel be implemented as a tool palette, so that you could point to any part of the screen with, eg, the Huh? tool, an idea I see from Computer Gaming World is now common in point-and-click adventure interfaces, where Huh? will likely appear as a magnifying-glass cursor/icon, or an eye. The latest issue of CGW also mentions a forthcoming game where each object has its own set of verbs-- a boombox has insert-tape, play-tape, etc-- (object-oriented adventuring!), and another with an MIT-developed pop-up-right-under-your-current-mouse-position diamond-of-icons, and a really cool sounding trick where you can "take movies" of what you see and play them later for others, as a way to talk without typing. (Wish I'd thought of that! What an IF-challenge, to build puzzles around that new form of competence!) The ILS design-stratum had a consistent scorn for the emerging conventions of Mac interface, and things generally had to be implemented so compleat idiots (like captains of industry) wouldn't be embarrassed by them-- so tool palettes were effectively out of reach.
Chapter 6: Ask Tom (AI in SuperCard!)
So after the weather project was cancelled, I got juggled around for a week or two and then offered this swat-team 'one month' easy-showpiece top-priority project already named "Ask Tom", a passive hypervideo 'browser' for exploring a storybase of videoclips of a top Arthur Andersen trust-banking expert, telling accounting-consulting 'war stories'.
Early on in the project, I bemoaned my sense of hypocrisy that all we were doing was making a really conventional textbook of trust-banking, with the cross-references hardwired in, but Larry Birnbaum explained, in a fatherly talk that was the turningpoint in my reconciliation to ILS's homely-looking ambitions, that the general problem of how to build a coherent outline for any arbitrary domain of knowledge was as important a question as any in AI. Yes, Larry said, Roget (the thesaurus-ist) was doing AI, as is, after a fashion, any bright popularizer trying to make a complex domain accessible to the general reader. Looking back on Ask Tom, I now see pretty much every important abstraction of AI programming, hardwired into... SuperCard.
(SuperCard, for you non-Mac readers, is a more-powerful version of
HyperCard, the breakthru 'paint'-an-application application. It's
*really easy to use, and so, on the surface, seems beneath a
professional-AI-macho-stud's contempt.)
There was also something wildly disproportionate about spending hundreds of thousands of dollars putting high-quality video into an application, when all the video showed was an accountant's talking head! (The S/N here seems about a googol times worse than an ascii transcription of his words. ;^) But I actually feel this was a sort of heroic pragmatism, that if video-based educational software is worth exploring at all, it's gonna cost astronomical sums and deliver very little at first. You might as well start with talking heads, because filming the trust bank itself would be a lot more expensive!
The semi-flashy 'gimmick' that made "Ask Tom" special was that Roger wanted us to come up with a simple, consistent view of the storybase where, after seeing a storyclip, one would always be presented with the same 'meta-menu' of followup clips, or rather followup-clip types. The theoretical rationalization was to be derived from an old paper of Roger's on "cognitive associative categories", which looked at the sorts of ways an ordinary human conversation can change course. (You can stay on the topic, or shift in the direction of some subtopic, etc.) So one of our tasks was to compile an inclusive list of all the sorts of followup a browser might enjoy, and then boil it down to a short-list that would look graceful on the SuperCard screen!
We all watched hours of accounting-video so we'd be able to 'ground' our speculative proposals in concrete examples. And the final list of "CAC-links" (cogn-asso-cate, above) included just eight: background, results, context, examples, warnings, opportunities, alternatives, and indicators. So after seeing Tom talk about the difference between small and large banks, say, you might be offered followups that talked about why some banks grow and others don't, or examples of each, or the implications of bank-size for a trust consultant, what to look out for if it's a small bank rather than a large one, etc.
As this list was distilled from the much-longer list, categories were necessarily merged, and the most general label chosen to include them both, so these final eight labels were necessarily rather vague, and it's not at all clear to me that they're really useful, compared to just listing the same followup stories in order of interestingness, say. And worse, a whole class of Schankian CACs got ignored, because there was no way to include them simply: Schank's original article focussed most on links of the type: same-person, same-object, same-theme, etc... but our spec just didn't allow the complexity of enumerating the persons, objects, and themes in a story, so that you'd be able to choose the one you wanted to followup via...
The screen display was designed on a spec that consisted of Roger waving his hands to suggest a network of nodes in a black 3-D outer space, twisting parallaxically as you moved from node to node. With SuperCard's limited animation capabilities, we re-imaged this as a SuperCard 'card' for each storyclip, represented with a central story-card surrounded by eight peripheral pseudo-3D piles of story-cards, one for each of the eight CAC-links, forming a 'lotus' (or 'crown of thorns', on bad-fridays). The parallax-twisting ended up looking more like Vegas poker-dealing....
This was the first ILS project that required the function of "media indexer," which is now an official ILS job-title, borne with diffident pride by dozens of ILS employees. (As clerical jobs go, it's definitely on the interesting end of the scale, or would be if project-design hierarchies at ILS were a little more enlightened.) All the links from story to story in the Ask-Tom casebase had to be 'hand-crafted' or hardwired, which ultimately meant looking at every possible pair of clips and asking whether either would make an interesting followup to the other, and which of the eight CAC-links it made most sense under.
So the network as a whole was just a stack of screens, almost identical, where the CAC-card-piles were implemented as buttons that 'moved' the top card of that pile to center screen. The only programming task was writing 'meta-code' that made these standardized screens self-generating (given the card titles and what-was-linked-to-what)....
I said earlier that I felt, at first, we were just writing a not-very- special hypertextbook, but the textbook-outline aspect of Ask Tom was completely perpendicular to the CAC-browser. Since the CAC-browser had to be perfectly homogeneous, with exactly the same sort of links no matter where in the network you stood, there was a need for an external 'orienting-structure', if nothing else so that you didn't always have to begin at the same point in the network.
This we called the 'zoomer' as opposed to the 'browser', suggesting vertical versus horizontal movement, and implemented finally as a very witty hierarchical sequence of graphical 'maps' of trust-banking meta-concepts: the toplevel screen identified the four main 'players' in the trust-banking-consulting game: Andersen-as-an-institution, the individual Andersen consultant (who was taken to be the user of the storybase), the client bank, and the banking industry-as-a-whole. You could click on any of these, or on the colored bands connecting them, which bands represented the relationships between the basic players.
Clicking on one of these screen-elements led down a level to a screen that might depict, eg, the sequence of steps usually experienced in one of the toplevel relationships (the Andersen-client relationship 'expanded' into Andersen-courts-client, client-communicates-need, Andersen-proposes- solution, etc), or the internal structure of one of the players (the bank's organizational hierarchy, say). Clicking on any part of one of these displays led to a 'themes' screen that sketched the most important themes that Tom's storytelling had pointed up, within that area, and offered a few choice stories as startingpoints for browsing. This was the most ad-hoc design decision, and grew (partly) out of my insistence that the way to deal with large casebases is to write each storytopic on an indexcard, and sort them into piles!!! So my cardpile categories became the themes under the subdivisions of the toplevel 'maps'.
It was these graphical-conceptual 'maps' that became the focus of interest in the once-Tom-was-done project, a followup tool for building generalized 'Ask systems'. We did some really nuts-and-bolts AI-thinking at this point, about how to take any heap of stories, and carve from it with the aid of a software tool, a system comparable to Ask Tom. One of my favorite generalizations from that period (to give a taste of the level of abstraction we were trying to come to terms with) was the idea of a 'sorting task' ...in the course of any sort of intellectual-creative effort, there will be phases where what you're doing is taking object X (and Y and Z) and looking at a row of 'buckets', one or more of which you might want to drop it into. A tool to make this easier will always need a "???- Try again later" bucket that commits you to no particular bucket-assignment, and allows you to reopen the matter later, for reconsideration.
The following ILS tech reports are relevant to this story in one way or another. They're free to academics, and just a few dollars each for the rest of us.
Elliott: The Affective Reasoner (the TaxiWorld thesis)
Kolodner & Jona: Case-Based Reasoning: an overview
Schank, Ferguson, Birnbaum, Barger, & Greising: Ask Tom
Schank & Osgood et al: A Content Theory of Memory Indexing (UIF)
Schank & Fano: A Thematic Hierarchy for Indexing Stories
=----------=- ,!. --=----=----=----=----=----=----=----=----=----=----= Jorn Barger j't Anon-ftp to ftp.mcs.com in mcsnet.users/jorn for: <:^)^:< K=-=:: -=-> Finnegans Wake, artificial intelligence, Ascii-TV, .::.:.::.. "=i.: [-' fractal-thicket indexing, semantic-topology theory, jorn@mcs.com /;:":.\ DecentWrite, MiniTech, nant/nart, flame theory &c! =----------= ;}' '(, -=----=----=----=----=----=----=----=----=----=----=
[Up: JB] [Map] [No next] [Robot Wisdom home page] (Feedback)