[alicebot-archcomm] Conditional wildcards

Gary Dubuque alicebot-archcomm@list.alicebot.org
Sun, 2 Mar 2003 23:26:11 -0800


Suppose there were distinct classes of conditions that were not overlapping.
For example a date and a number are not formatted the same.  Suppose that a
list of standard formats was proposed that are discreet.  Then the only
caveat would be the order of _, word, * where conditionals could not be
last.

Instead of calling them conditional wildcards, I suggest it might be better
to call them typed wildcards.

The typed wildcards would have the same level of ambiguity as untyped
wildcards. They don't specifically define an exact match, but instead match
similar to regular wildcards so that they let one or more "words" pass
through to the template.  Here I refer to ambiguity with respect of
linguists in the sense that many utterances may match to a given pattern if
it contains a wildcard.  To the pattern "HEY *", "Hey surfer dude" and "Hey
dude" are the same and indistinguishable.  The pattern itself does not
resolve the difference.

The problem raised is that typing the wildcards may produce several possible
matches.  As I have pointed out already, we always have had several possible
matches to patterns. They eventually get resolved by processing stipulations
such as only consuming as much of the input as necessary to form the match.
The ordering of wildcards by the _ and the * type is another example showing
that when they are processed binds the one and only allowed match.  Here we
have with the power of language the opportunity to see another aspect of
ambiguity, that is, knowing which of several patterns is "right".

If typed wildcards were treated as the priority for the wildcards, we have
satisfied one of the limiting factors to picking the pattern for which we
want to execute the template. Then we have only to be sure that the typing
of the wildcards created unique matches to guarantee only one template is
chosen.  That is unless we arrange such wildcard typings into a order
similar to mathematical expressions where multiplication is done before
addition.  And I believe this is the crux of the matter.

All this is just as complicated as adding the $ to match a single word
instead of using * and hoping for the best.

The same question arises, is $ to be done before * and is $ to be done after
a word is tried?

Is matching to a date format to be done before *?  Is matching to a number
format to be done before matching to a date format?

Although attempting to create this specification may seem a bit complicated,
the actual use of such a type wildcard would be relatively simple.  It is
natural to substitute a date type wildcard instead of a generic wildcard in
a pattern where we know a date should occur.  The same can be said for any
number of formats such as time and phone number and urls and etc.

>From a template point of view, knowing that a star contains a certain type
of data makes processing it much easier. Otherwise eventually we will have
to dealt with exception processing which many default responses already
appear to be.  (Sometimes I wonder if I'm not just making one of those
info-commercial psychics that read Tarot cards when I write AIML.  Being
able to recover fom any situation still talking smoothly seems to be a
premium trait for AIML authors.)  Typing may only really be important for
template-side APIs to host systems.  If so, this discussion seems to be
awful a lot for so little (sorry SQL front-enders.)

Still considering,
  Gary Dubuque

-----Original Message-----
From: alicebot-archcomm-admin@list.alicebot.org
[mailto:alicebot-archcomm-admin@list.alicebot.org]On Behalf Of Jonathan
Roewen
Sent: Sunday, March 02, 2003 5:41 PM
To: alicebot-archcomm@list.alicebot.org
Subject: RE: [alicebot-archcomm] Conditional wildcards


 --- Gary Dubuque <gdubuque@attbi.com> wrote:
> Whoops, that last reply got on the wrong thread.

It was also completely bogus - saying * * is ambiguous
is completely false.

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

No. HELLO * cannot match "Hello surfer dude" if and
only if HELLO * DUDE, or a more exact match exists.

You are confusing ambiguity with exactness.

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

Yes. It is called the AIML Spec. The only thing I
think it fails to state explicitly is the fact that a
wildcard only consumes as much as is necessary to form
a match. This is implied by the design of the
graphmaster.
>
> But the point here is that the discussion of
> conditional wildcards is not a
> discussion of ambiguity.

Not true.

> 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.

You can't stay at this level if you want to propose
this idea! You can't have it both ways.

And conditional wildcards does produce ambiguity where
there previously was none before.

The only part that is ambiguous is the AIML writer's
understanding.

Jon =)



http://mobile.yahoo.com.au - Yahoo! Mobile
- Exchange IMs with Messenger friends on your Telstra or Vodafone mobile
phone.
_______________________________________________
alicebot-archcomm mailing list
alicebot-archcomm@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-archcomm