[alicebot-archcomm] Matching Order Revised

[Kim Sullivan]

> It is somewhat strange to set a topic but have a match outside of it,
> just because another user input (a pattern nor a category in the Dirk's
> way ) outside of the current topic could be (in the current
> matching order)
> "more important" than some other inside the topic.

The basic premise in AIML is that the more you know about the user input,
the bettern a certain response is - disregarding all other contexts. The
context could have changed without you catching it, the user can return
after a lengthy period of time and the only thing you can be 100% sure about
is the user's input. Then comes 'that' which you can guess pretty well, and
the 'topic' stays pretty elusive even if you try to keep track of it. Often,
you talk about something, then there's a small "BTW" branch in the
conversation (not really a topic change) lasting 1 or 2 exchanges and then
you get back on topic. Rich once described the process of creating a
category in this way:

1) Is a user input missing? Add it.
2) Is the user input there, but the bot replied badly in this conversation?
Add a <that>
3) We already have a category with a <that> and the bot still talks bogus?
Add a topic

You could omit step 2 and get right to 3 (depends on the bot's reply), but I
believe it is good practice to always start with step 1. I believe this
models pretty nicely humans talk as well. First and foremost (if you're
really having a dialogue) you reply to what your conversation partner said.
This allows you to stay flexible - when talking about the weather and
somebody suddenly yells "WATCH OUT!" you probably won't continue to talk
about the weather.

If you don't know what he said or his utterance is ambiguous (or you just
don't care what he said, or decide not to pursue it further), you decide on
the meaning by either "remembering" what you just said (e.g. in response to
a question, you have to remember what you asked in order to react) or by
respecting the topic you are discussing (I believe this is a very complex
issue and a single 'topic' variable does't do it justice, but it's all we
have in most implementations).

> Moreover, half of the matches can be skipped if no topic is set, and a
> quarter of the matches can be skipped too if no that is set.

Depends on the matching algorithm implementation. If it is implemented
smartly, you can skip "empty" contexts anyway (so this is not a flaw of the
current order, but more of certain implementations). Most of the time, you
should not have any pattern inside a context if you don't have it outside
too. Ideally any input should be handled, if it is inside a context it will
just be handled "better" because you know more about what the user said.

> This view seems IMHO more logic and contextual than the current one.
> (it's almost already there as you don't have to add a new things
> & tags ;-))

Like Jonathan said, you'd probably loose most categories "outside" a topic
once a topic was set, specifically with this:

> <topic> TOPIC <that>  * <input>    *
> <topic>   * <that>  * <input> PATTERN
> <topic>   * <that>  * <input>    *

This effectively says that the topic is the most important thing, once we
know what the topic is we don't care what the user said anymore. This makes
topic changes also extremely difficult. Let's suppose that you have an AIML
file specifically for topic changes. It contains generic categories handling
input like "let's talk about something else" or "What do you know about
foobar" (all of them of course without a topic).

Once you have a topic set, there's a high probability (esp. using catchall
categories) that the topic changing categories outside the topic will be
"shadowed" and therefore unacessible. You could either include all the topic
changing categories in your topic too (and in all other topics also), or
provide special "topic exit" categories inside each topic (which disrupts
the conversation flow, in my opinion).

Kim