Leo Ktaba - Apr 19, 2011:

Effectively, it is just as you have described.

If you look the use of conditions in the pattern is the <topic> tag. The variable “topic” is evaluated in the matching process, so it is something like what I described and that being a bit perverse you saw no utility.

I’m sorry, I think I’m missing the point here?

[quote author=“Merlin” date=“1303224456”
For complex topics it might be easier to branch to a self contained set of patterns and responses.

You could be right about maintaining separate sets of patterns/responses,
but I see danger for introducing duplication of knowledge. Duplicated sets of patterns/responses also means duplicated maintenance. In software design, parallel hierarchies are considered bad practice. Perhaps I need some practical experience with it to see advantages.

Merlin I think you’ve hit the jackpot.

With the condition in the template reduces the number of alternatives in the pattern matching, with the resulting benefit of speed. You know that any response code is located on the same template.
But if that code is so large that it prevents us visualize it correctly, like many conditions chained, perhaps the alternative of dividing the code into several pieces can be a good option. It could be divided into several <srai>, but this alternative does not really like me because you’re putting new patterns in the search tree.

As I said before <topic> and <that> tags are actually variables to match with the pattern, but integrated into the language in a more or less blindly. In many cases one could dispense with them using <set> and <condition> tags.

Shi - Apr 19, 2011:

You could be right about maintaining separate sets of patterns/responses,
but I see danger for introducing duplication of knowledge. Duplicated sets of patterns/responses also means duplicated maintenance. In software design, parallel hierarchies are considered bad practice. Perhaps I need some practical experience with it to see advantages.

I don’t use AIML in my system but many of the concepts are similar. You would not use this structure to duplicate both patterns and responses.

In the general case, you would put all standard responses together in the same output response and use the condition tag like in Steve’s example. Mapping multiple input patterns to the single response makes it easy to manage. I tend to do this most when testing a boolean value.

Patterns in my system all have a priority. By branching based on conditions, I can change the priorities of duplicated patterns. In addition, branching on the input pattern allows me to activate (or bypass) sets of patterns that relate to a specific topic. When editing responses for a specific topic, it is easier to have them all in one location. If the rule set is small I will normally include them in the standard stream. If it grows above a certain size, I will refactor and move the rules to a bundle.

Maybe it is begging the question to assume that a match in AIML is the correct match.  If so, there would not be problems with shadow categories. If the pattern matching is not allowed to continue, shadowed patterns are dead code.  On the other hand, if by some additional logic beyond the simpler match of the graph-master indexing (including the <that> and <topic> tags), a preliminary match can be determined as false, then the shadow pattern has a chance.
Remember, shadow patterns are typically included in the AIML first and then a category is added that covers them.  Which means they are valid patterns in the original context.  The covering pattern may be in another context capturing another part of the conversation.  That new pattern may not be controlled by a topic since it isn’t so narrowly defined.  It still may be favored according to some features of the discussion (shaped by a predicate like “it” or something) and inappropriate for other conditions which is better handled by the original category that got shadowed.
The argument is that a <srai> tag can deal with the situation, but such a call will only recurse back into the covering category and still not get to the shadow category.
This extended pattern matching was used in AIMLpad to include Cyc (actually OpenCyc) in the pattern matching cycle as well as the template processing cycle.  This meant that instead of having a policy to combine (or ignore) duplicate patterns, the interpreter could, with one more step, resolve how to utilize the duplicate.  It also opened up the limitation of only having a topic to group categories.  That enabled a more complex dialog management function where a pending question usually handled by the <that> tag could be interrupted with another volley. For example, “How are you? What’s up?” can set two context variables so that either can be answered or even both in a multiple sentence input.  The two questions could span several volleys and still be handled correctly.  Or gracefully, if one is already answered, the context can be set to bypass processing a response <template> intended only for a first time answer.  This is far less complicated than building a massive <template> full of conditions for every way the matched pattern can be used.  It fits with the rudimentary <that> and <topic> tags style but handles much more of the dialog management.