| Say that you own an
ice cream parlor. Whenever you bring on a new employee, you expect
that you will have to train them. You explain the job: "this
lever pumps the cones... never pump ice cream into your mouth...
the chocolate shots are in a bucket under the sink..." The
new employee bobs his or her head in agreement.
What next? Do you toss the them
the keys and say "lock up at eight"? Of course not. What
comes next is testing and repetition; you want to make sure that
they "get it."
For the purposes of describing
Brainhat programming, the dumber the counter sitter, the better
the analogy; Brainhat only knows what you tell it. Furthermore,
the natural task progression that comes naturally to a human--the
concept of "steps"--is meaningless to Brainhat. You must
lay out proposition milestones that help a conversation graduate
from one stage to another. To assure that the scenario you are
describing to Brainhat "works" requires testing and
repetition.
Let's take a specific example.
Say that you want an ice cream parlor exchange to progress from
the arrival of a customer to the question "do you want a
sugar cone?"
If the speaker is hungry then
the speaker wants ice cream. If the speaker will have
something then the speaker wants something. If the speaker
wants ice cream then ask if the speaker likes vanilla ice
cream. If the speaker does not like vanilla ice cream then
ask if the speaker likes chocolate ice cream. If the
speaker does not like chocolate ice cream then tell the speaker
that the speaker likes weird ice cream and ask if the speaker is
unhealthy. If the speaker likes ice cream then ask if the
speaker wants a sugar cone.
Brainhat has chocolate ice
cream. Brainhat has vanilla ice cream.
Consider that we might take
multiple paths along the way. The user might want chocolate or she
might want vanilla. She might even ask for ice cream of no
particular flavor (wierd). Notice that I have tried to bound the
conversation so that we get to the "sugar cone" question
by almost any path. This is not a requirement; the conversation
can become unscripted at any time. However, once we fall off the
subject at hand, Brainhat will run out of things to say. It will
be up to the user to take over the lead in the conversation.
How might the conversation go?
>> hi
hello.
>> i am hungry
the speaker is famished. the speaker wants ice cream.
does the speaker
like vanilla ice cream?
>> do you have chocolate ice cream?
yes. brainhat has chocolate ice cream. does the
speaker like vanilla ice
cream?
>> i like chocolate ice cream.
the speaker likes chocolate ice cream. does the
speaker want a cone?
>> yes
the speaker wants a cone.
Scenario development takes some
patience. Occasionally, Brainhat's logic will take a turn that you
hadn't anticipated. Or you may ask the user a question that is
likely to be answered in a fashion that Brainhat doesn't interpret
correctly. Accordingly, the questions you ask and the statements
that you make should lead the interlocutor toward a dialogue you
have already tested.
The good news is that you can
stuff Brainhat full of amusing, off-topic information so that if
the user does stray, there will be something unexpected to
discover. Today, for instance, I heard someone in our office tell
Brainhat that they don't like cold weather. Brainhat told the
person that Egypt is warm, and that the person should go to Egypt!
I had coded that into a scenario and forgotten about it. It was a
amusing surprise to hear it re-surface.
If you wish to experiment with
the ice-cream scenario, here are the additional words you will
need to include into Brainhat's input files:
- define flavor-1
label flavor
child attribute-1
define chocolate-1
label chocolate
child flavor-1
orthogonal flavor-1
define vanilla-1
label vanilla
child flavor-1
orthogonal flavor-1
define ice-cream-1
label ice cream
child food-1
typically cold-1
define sugar-cone-1
label sugar cone
label cone
child food-1
|
