[alicebot-archcomm] Conditional wildcards

[Dr. Rich Wallace]

Well stated Jon.

It is worth pointing out that, the AIML pattern language + matching
algorithm has the very nice, simple property that there is a one-to-one
correspondence between inputs and matching templates.  The more complex
and ambiguous the pattern language becomes, the less clear this one-to-one
map becomes.   Adding "sets" to the patterns raises problems of ambiguous
matches, multiple categories matching the same input, and deciding the
matching priority of these ambiguous unifications.

When the AIML set becomes large, the one-to-many matching creates a
scaling problem.  Every new category introduced potentially upsets the
delicate balance of order of the existing categories.  Certain commercial
bot systems in existence are known to have this scaling problem for
precisely the same reason: their bot languages permit more general, and
hence more ambiguous, matching of inputs to responses.

If you keep the pattern matching languge simple, as we have in AIML, the
one-to-one matching property is not lost.  So the same scaling problems do
not arise.  It is quite clear in AIML how every new pattern or category
fits into the encyclopedia of knowledge already in the robot's brain.   
There is no cross-referencing or indexing necessary to determine when a
particular category will be activated, and no new category will upset the
order of matching among the pre-existing ones.



>> This version of AIML would work if you wanted to record every number
>> possible.  Already we have many categories for just entering someone's
> age.
>> The idea is that these are classes of items to match.  Classes that
>> don't fit into the realm of just natural language. Surely you're not
>> saying that entering all those dates would simplify the processing of
>> them.  I would image the minimalist would say no, no, no, we want it
>> simple.  Just let us call a date a date.  Don't make us list all the
>> possible dates there are.
>
> Who says you have to? You don't have to do that, just to make use of a
> class. There are ways to find out what kind of class (if any) that a
> word is after it has been matched to a wildcard when being processed in
> the template.
>
>> So how are we going to know when someone is going to use a date as an
>> answer?  One has to ask deliberately for a date or expect that only a
>> date is appropriate from the context of the inputted phrase.  This
>> leaves alot
> of
>> wiggle room.
>
> Only if you let there be wiggle room.
>
> Such things as conditional wildcards have been attempted before. There
> was the typeof tag Jon Baer experimented with, and maybe not quite as
> known was creating sets, and specifying a set (a restricted wildcard,
> using @ syntax).
>
> There are problems with both.
>
> Typeof has the problems of how to expand the tag .. does it occur while
> processing the template, or does it get expanded into multiple
> categories at load time? Also, what happens with two or more instances
> of the same typeof in both the template and pattern? Such as:
>
> <pattern><typeof_a/> * IS <typeof_a/> *</pattern>
> <template>I didn't know <typeof_a/> <star/> is <typeof_a/> <star
> index="2"/></template>
>
> And <typeof_a/> is defined to be "a" and "an". How do you know which is
> which in the template? Do you instead treat matching to a typeof as an
> additional wildcard, so it'd instead be:
> <template>I don't know <star/> <star index="2"/> is <star index="3"/>
> <star index="4"/></template>
>
> If you do, this would imply the category doesn't get expanded at load
> time.
>
> And the @ syntax has the same problem as your conditional wildcard idea.
> How do you decide among two plausible matches?
>
> What if you have @NUMBER and @PHONE? @PHONE would just be a more
> restricted form of @NUMBER but the interpreter doesn't know that.
>
> I do believe that <typeof> could become a possible solution .. it would
> just require a bit of work to establish exactly how it would work. But
> it is still susceptible to the same problem as these others.
>
> So I guess the real question is: is the possibility for ambiguity such
> as this acceptable?
>
> Jon =)
>
>
> _______________________________________________
> alicebot-archcomm mailing list
> alicebot-archcomm@list.alicebot.org
> http://list.alicebot.org/mailman/listinfo/alicebot-archcomm


-- 
Dr. Rich
W A L L A C E
ALICE A.I. Foundation
drwallace@www.alicebot.org