[alicebot-archcomm] Conditional wildcards

[Gary Dubuque]

Whoops, that last reply got on the wrong thread.

What is the difference between "hello *" and "hello * dude"?  This is
multiple patterns matching ambiguously to the same input of "hello surfer
dude".

Is there a standard that says one or the other has precendence?

But the point here is that the discussion of conditional wildcards is not a
discussion of ambiguity.  It is a finer, more precise specification for an
already ambiguous feature.  It is for a specific purpose of extract
meaningful units that don't fit the in the same packaging as words.  Yet
there are qualities of these units that can be identified enough to process
them as logical entities.  It is clear that a date is a date even though it
is expressed in a varying format.  To extrapolate the requirement to some
generalized "sets" of patterns may be premature.  The focus is on known
qualtities.  I don't want to dive into the deep waters of semantic meanings
yet.  I want to stay at the level of word recognition when I propose this
enhancement.

Thanks,
  Gary Dubuque

-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]On Behalf Of Dr. Rich
Wallace
Sent: Sunday, March 02, 2003 2:04 AM
To: alicebot-archcomm@list.alicebot.org
Subject: Re: [alicebot-archcomm] Conditional wildcards


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




_______________________________________________
alicebot-archcomm mailing list
alicebot-archcomm@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-archcomm