GRAVITY TWENTY EIGHT -- Thursday, October 15, 1992

More about systems today. If the last two notes have left you somewhat confused, or bored, I completely understand. Given a choice I'd have spread out the nitty-gritty treatment over several weeks. As the end is drawing near, I'm feeling under the gun to at least cover the basics.

In my example, Van has just received these three names:

< nlpLand : casey | parser >
< henry | textBase >
< songAssociate >

Van knows these are part of the system called 'songlink' and now needs to clarify just what these other names refer to. I choose these three because they illustrate three different kinds of acclimation. The first requires Van to do some talking to an entirely different ThoughtShop, the one called 'nlpLand'. The next requires Van to talk to another agent in the same ThoughtShop as Axle. Van also needs to find out about 'songAssociate' from Axle. As these are the major sub-headings of the system 'songlink', Van will have acquired the system when it resolves these three names.

This is where it gets hairy and, in my opinion, exciting. First thing that
happens is Van splits into three different agents. Agents can have sub-agents, just as items can have sub-items. I haven't mentioned this till now to keep things simple. So now we have Van.1, Van.2, and Van.3, each of which has its own private context, as well as the single shared Van context.

Van.1 is in charge of finding out about 'parser' from the agent 'casey' of the ThoughtShop 'nlpLand'. This requires Van.1 to connect to the ThoughtShop 'nlpLand', which probably involves dialing up this other ThoughtShop and establishing a dialog with Casey. This of course assumes that Van knows of the ThoughtShop 'nlpLand' and that Casey exists on that ThoughtShop. I do have a procedure for dealing with the case where names denote unknowns, but for our purposes, let's say things things work smoothly and Van.1 can connect to Casey. Van.1 sends the name: < nlpLand : casey | parser | send >.

As this is happening, Van.2 is sending a similiar kind of name to the
agent Henry, which is a co-agent of Axle (if you haven't guessed by now, co-agents are agents that belong to the same ThoughtShop). Van.2 sends the name: < henry | textBase | send >.

At the same time, Van.3 sends the name: < songAssociate | send >. Note that since these last two sub-agents inherit the context of Van, they need not explicitly specify the ThoughtShop 'metal.head' as Van.1 did with 'nlpLand. For the same reason, Van.3 doesn't have to specify the agent component.

*#@!

Oh hell. There's just too much to explain here. This will be far too
difficult without doing a full treatment of rules and options. I could write fifty pages on what'll happen in these three seperate sub-dialogs, and another ten on how the contexts of the three sub-agents coalesce back into the main Van context, but can't with just three notes left. There's another part of Gravity that I want to discuss instead, which is something that's quite new in the world of software design as far as I know.

Let's take the case where Van already knows about Henry's 'textBase' item. Van may have accessed that system in the past, and wouldn't need to learn it from Henry. In this case, Van would have simply taken the name and recorded it as a sub-item of the system 'songlink', without any further action. < henry | textBase > would have been in Van's context, and Van could have assumed it knew what Axle was using as a sub-item of 'songlink'.

But here is a major issue. What if < henry | textBase > had been changed between the time Van accessed it and the time Axle used it?

Tomorrow: multi-context processing (a.k.a. counterpoint)