I’m working on a basic aiml importer and have some questions about topics and patterns (I am not familiar with aiml’s syntax details).
1. the topic name can contain a ‘*’, how should I interpret that?
2. are there any other special signs allowed in the template definition, other than * and _ (and they mean var1 and var2 correct?)

topic name=”*” just means a blank topic and isn’t really used.
topic name=“_” would override every other topic and again isn’t used.

topic name=“RED *” would cover topics of “red tomatoes”, “red light” etc. Anything that starts with RED
topic name=”* RED” would cover topics of “code red”, “colour red” etc. Anything that ends with RED
topic name=“THE * RED” would cover topics of “the code red”, “the colour red” etc. Anything that starts with THE and ends with RED

topic name=“RED _ ” would cover ANY topic that starts with red and overrides anything even a direct match of say, “topic name=“RED LIGHT”

If you had a topic of “RED TOMATOES” and one of “RED *” and the bot set the topic to “red tomatoes”, the direct match would prevail. However, if you had “RED _” as a topic, this will always be called whether you had a direct match or not.

There are no other special symbols used in topics and yes, they just refer to var1, var2 and so on.

and so on

Ahh yes, you can have multiple * or _ in a pattern correct? and they mean exactly the same?

For the topic wildcards, I will have to add a small feature to my pattern matcher, the rest should be convertible I think.

I’m still having a little trouble understanding against what the topic pattern should be matched with. Does this have to match some variable that can be set or something?

Hold it, I think I’m starting to understand: does it have to match the name of the last activated topic? Please say yes, that’s how I do it…

Yes you can have topics such as THE * RED _ IN THE * if you like which would match “THE LITTLE RED CAR IN THE GARAGE” for example.

How it works, is that while you are talking to a bot, it should set the topic name to say “SPORTS” and then if you say something like “What is your favourite?” It knows the topic is sport and so should reply with its favourite sport. Then while talking, you might say something like, “I went to the cinema” and so the bot would set the topic to “MOVIES”. If you were then to say some babble like “FGHFGHFGH”, it could respond by asking a general question about movies.

Please say yes, that’s how I do it…

Spot on. The topic tag is set by the bot and then categories under that topic are activated.

Thanks Steve. I can work with that. I currently don’t allow wildcards in the topic names, I simply do an exact match. But this is something that I can add.
I probably have some more questions later on like how the gender tag and such work, but that’s for later.

No problem Jan. Not many topics should have wildcards in, if the bot is coded decently and I doubt any will have more than one or two wildcards in at best.

I think that I would add (with emphasis) that it’s a VERY good idea to avoid topics that contain wildcards at all, though coding in support for them will avoid false bug reports later on, should someone else create AIML with topics that contain wildcards.

As a side note, I’m not a fan of the underscore rule of overriding a direct match, but I didn’t make the rules.

the underscore rule of overriding a direct match

Is this also true when it’s used in patterns?

It is, Jan. A pattern of “MY NAME IS _” will match before a pattern of “MY NAME IS DAVE” when the user inputs “My name is Dave”. Now I can see the point of this behavior when it’s used to simplify inputs, which is (I believe) the original intent. For example, removing superlatives (I think that’s what they’re called ), such as the word “very”, can be done like so:

In the above example, the input “I am very tired.” would reduce to “I AM TIRED”, which can be beneficial, since wildcards require at least one word, thus making patterns like “I AM * TIRED” useless for both “I am tired” and “I am very tired”.

Ok Thanks, I had implemented variables as being always lower in weight, but it’s no biggy, basically 1 extra line in the patternmatcher. A little more for the pattern definition (I’ll have to make the weight variable).

A couple more questions. This time about ‘that’.
- the pattern of a pattern-side-that, does it have to match the pattern of another category, or is the pattern simply evaluated at run-time against the last input?
-I’m a bit confused about the purpose of a template-side-that. What’s it for exactly? is it simply to return a previously uttered output statement?

The easiest way to understand that is to think about what happens when someone says, “yes” to your bot. How can you code a category to give a sensible response? You need to make the bot aware of what it has just said using the that tag.

The that tag simply matches what the bot has just said and would be used like this:

Human: I have a chicken
Bot: Do you like eggs?
Human: Yes
Bot: Me too. Yummy

You can use wildcards in that tags as well.

Using that in templates allows you more flexibility like so:

Bot: Do you like school?
Human: Yes
Bot: What do you like best about school?

You can use <thatstar index=“2”> like you use <star index=“2”>

The ‘ThatStar’ was one of the next questions. I’m currently doing something similar, except that I currently require a hardlink to another output pattern, so there is no actual pattern-matching involved to evaluate ‘that’, but it simply checks which output pattern was last used.
Adding an extra pattern match isn’t so hard for the pattern-matcher, a little more work for the designer, cause now there has to be a select: hard ref to another output pattern, or declare a new pattern.
Thanks.

Another question: I read that conditions can’t be nested (yet). Is this still the case, or can they be nested?

They can be nested as many as you like. Obviously though, the more you nest, the harder it gets to manage your code.