[alicebot-archcomm] [proposal] <get pattern=

[Noel Bush]

Kim said:

> After reading your proposal more closely, I think I 
> completely missed your
> point. I'll try again in the next post.

Oh, please, where is your next post?? :-)  (I fear I have greatly
frustrated Kim with my repeated Godzilla-like blunders through CVS :-) )

Rich wrote:

> The trouble comes when I imagine myself in front of a class of AIML
> students,
> trying to explain what <get pattern="I LIKE *"><star/></get> means.

Just like Philip Dick, I have been to an alternate universe (a) where
this was already the case, and here is how I explained it:

   (a) If you write:
   (a) 
   (a) <get pattern="I LIKE *"><star/></get>
   (a) 
   (a) This means that the engine will try to find a category whose
pattern is exactly "I LIKE *".
   (a) 
   (a) If the category is found, then the next question is: has it been
activated for the current user?
   (a) 
   (a) If it has been activated for the current user, that means the
wildcard captured a value, and <star/> will return what was captured.
   (a) 
   (a) If it hasn't been activated, then this will return absolutely
nothing (an empty string).

In my alternate universe, a student asked,

   (a) How can I know whether the category referenced has been
activated?

My answer was,

   (a) You can't, directly, but you could do something like this:
   (a) 
   (a) <category>
   (a)   <pattern>WHAT DO I LIKE</pattern>
   (a)   <template>
   (a)     <think>
   (a)       <set name="likes"><get pattern="I LIKE
*"><star/></get></set>
   (a)     </think>
   (a)     <condition name="likes">
   (a)       <li value="*">You told me you like <get
name="likes"/>.</li>
   (a)       <li>You didn't tell me!</li>
   (a)     </condition>
   (a)   </template>
   (a) </category>

To this example, the student replied,

   (a) But that is pretty cumbersome!  Wouldn't it be better just to
edit the original category with the pattern "I LIKE *"?

To which I replied,

   (a) Sure, if you *can* edit that category.  But if that category was
loaded from some external source, such as the alicebot.org-hosted
Standard AIML set, you can't.

(In this alternate universe, alicebot.org hosts the Standard AIML set
and people can use it with a
<learn>http://alicebot.org/resources/aiml/standard/filename.aiml</learn>
.)

The student then replied,

   (a) Okay, I will grant that point.  It is useful.  But the
construction you showed is still cumbersome.

I agreed, and explained,

   (a) Yes, that's true.  However, I must tell you that I have been to
an alternate universe (b), in which a "serialized" form of AIML is
supported.  This means that attributes can also be expressed as element
children.  In my AIML class in that universe, I gave the following
example:
   (a)
   (a) (b) First of all, you can check whether the get retrieves a
result more directly, like this:
   (a) (b) 
   (a) (b)    <category>
   (a) (b)      <pattern>WHAT DO I LIKE</pattern>
   (a) (b)      <template>
   (a) (b)        <condition>
   (a) (b)          <name><get pattern="I LIKE *"><star/></get></name>
   (a) (b)            <li value="*">You told me you like <get pattern="I
LIKE *"><star/></get>.</li>
   (a) (b)            <li>You didn't tell me!</li>
   (a) (b)          </condition>
   (a) (b)        </template>
   (a) (b)      </category>
   (a) (b)
   (a) (b) But, since the pattern attribute of AIML can also be
expressed as an element child, you can even do this:
   (a) (b)
   (a) (b)      <category>
   (a) (b)        <pattern>WHAT DO I *</pattern>
   (a) (b)        <template>
   (a) (b)          <condition>
   (a) (b)            <name>
   (a) (b)              <get>
   (a) (b)                <pattern>I <star/></pattern>
   (a) (b)                <star/></get>
   (a) (b)            </name>
   (a) (b)            <li value="*">
   (a) (b)              You told me you <star/>
   (a) (b)              <get>
   (a) (b)                <pattern>I <star/></pattern>
   (a) (b)                <star/></get>.
   (a) (b)            </li>
   (a) (b)            <li>You didn't tell me!</li>
   (a) (b)          </condition>
   (a) (b)        </template>
   (a) (b)      </category>
   (a)
   (a) The student in that universe complained,
   (a)
   (a) (b) This is getting awfully hard to follow.  It appears as though
the context of <star/> is determined by its position -- if it is a
direct child of a <get>, then it is the wildcard content from the
"gotten" category, but elsewhere it is the wildcard content from the
current category.  Is that right?
   (a)
   (a) I replied,
   (a)
   (a) (b) Yes, what is so hard about that?
   (a)
   (a) Student:
   (a)
   (a) (b) Nothing, but I heard that AIML was supposed to be easy to
learn.
   (a)
   (a) Me:
   (a)
   (a) (b) It is!  You don't *need* this functionality.  But this is
AIML 401 -- didn't you notice when you registered?
   (a)
   (a) Student:
   (a)
   (a) (b) Okay, fine.  I am some kind of expert GUI developer in any
case, so I will build an editor that will make it easier to handle this.
   (a) (b)
   (a) (b) But I have another issue.  It seems unpleasant to re-get the
category after having tested it.  Why didn't you just set the retrieved
value in the first place?
   (a)
   (a) Me:
   (a)
   (a) (b) That's true; as in an example I gave in an alternate universe
(), it is possible just to set the result of the get and so only perform
it once, like so:
   (a) (b)
   (a) (b)      <category>
   (a) (b)        <pattern>WHAT DO I *</pattern>
   (a) (b)        <template>
   (a) (b)          <think>
   (a) (b)            <set name="whatIstar">
   (a) (b)              <get>
   (a) (b)                <pattern><star/></pattern>
   (a) (b)                <star/></get></set>
   (a) (b)          </think>
   (a) (b)          <condition name="whatIstar">
   (a) (b)            <li value="*">You told me you <star/> <get
name="whatIstar"/>.</li>
   (a) (b)            <li>You didn't tell me!</li>
   (a) (b)          </condition>
   (a) (b)        </template>
   (a) (b)      </category>
   (a) (b)
   (a) (b)   Actually, even better is this:
   (a) (b)
   (a) (b)      <category>
   (a) (b)        <pattern>WHAT DO I *</pattern>
   (a) (b)        <template>
   (a) (b)          <think>
   (a) (b)            <set>
   (a) (b)              <name><star/></name>
   (a) (b)              <get>
   (a) (b)                <pattern><star/></pattern>
   (a) (b)                <star/></get></set>
   (a) (b)          </think>
   (a) (b)          <condition>
   (a) (b)            <name><star/></name>
   (a) (b)            <li value="*">You told me you <star/>
<get><name><star/></name></get>.</li>
   (a) (b)            <li>You didn't tell me!</li>
   (a) (b)          </condition>
   (a) (b)        </template>
   (a) (b)      </category>
   (a) (b)
   (a) (b) That is to say, you can have dynamically-named predicates.
Again, all of this is so-called "advanced AIML", not the stuff for
beginners, and certainly not necessary, but I should mention that in
another alternate universe it is part of the basis for a dialogue-based
targeting system, which essentially realizes "guided learning" in a
fashion that is wholly commensurate with the original notions of AIML.

Now, back from all these alternate universes, I still hear this question
from Kim:

> What's wrong with using the current variables mechanism for this? I
> personally don't think that referring to the actual pattern is more
> abstract, more 'devoid of meaning' than inventing an 
> identifier for the
> value we just got. 'Assigning a name for...' is biased 
> towards the meaning,
> you're right with that,that's why I'm talking about 
> 'identifiers'. That this
> identifier carries a meaning, is just a coincidence (since, 
> so does 'I LIKE
> *', no matter how you try to put it).

Part of this question is answered by the problem of not having control
of the AIML you're using.  You cannot rely on other people to include
<set name=""></set> instructions with the name value you'd like.

But the other part of the answer is this:

It's true that an identifier can be said to carry a "meaning".  But if
we look at how AIML works, we must also admit that that "meaning" is
fleeting, except in the case of special predicates like that, topic,
star, etc.

The meaning is "fleeting" because, for all of its potential uses, it is
a kind of association that cannot be retrieved from all contexts.
Unless every context knows that a certain 'name' value can be counted
upon to behave in a certain way, we cannot say that the "meaning" is a
kind of "fact".  In fact, there are no "facts" in AIML, and this is a
core principle of AIML.

Just like Alan Turing substituted the notion of imitation for the notion
of "thinking", AIML substitutes the notion of "acceptable behavior" for
the notion of "knowing".  A kind of hidden thesis of AIML is that this
"acceptable behavior" is all that we humans do when we think we're
expressing our "knowledge".

Being able to retrieve the value associated with some name, in some
contexts, is a kind of acceptable behavior that makes an Alicebot seem
to "know" something, like your name.  But the word "name" is also just a
word, according to AIML, and Russian AIML might, for instance, associate
the word "ÉÍÑ" with your name.  AIML says we don't need a dictionary or
an ontology to make use of these bits of "knowledge" -- it says that an
AIML set might be built up the way a person builds up knowledge, so in
one set you might have the pattern "MY NAME IS *" reduced to "íåîñ úï÷õô
*" (a native Russian speaker who has learned English), in another you
might have the reverse (a native English speaker who has learned
Russian), and in still another you might have both patterns operating
independently -- so-called "knowledge" might get exchanged in other
places (a person who has learned both Russian and English since birth).

The point is, our current function <get name="name"/> is kind of like
saying:

"He said 'name' is what?"

The proposed new function <get pattern="MY NAME IS *"/> is like saying:

"He said 'my name is' what?"

This is akin to saying that a human being does not fully-formulate every
single piece of information s/he receives *immediately* as a
"predicate", but that some things must be *recalled* from memory.

It may be that when we recall them, we assign some kind of simpler
predicate, such as in the example from the first alternate universe
where I assigned the predicate "likes" to whatever I recalled that the
user had said in place of the wildcard in "I LIKE *". It may also be
that we sometimes don't bother to assign a simpler predicate, such as in
the example from the second alternate universe in which I recalled the
value twice. I think that this example, cumbersome as it may appear,
also models something that humans sometimes do, perhaps especially when
they don't know a language so well:

Interlocutor> Qu' est-ce que j'aime?
Me> (thinking, what did he say that started like "J'aime...."?)
  [one possibility: nothing -- Vous n'avez pas diser.]
  [another possibility: something -- Vous avez diser, (thinking, again,
what did he say...?) pizza.

(This is an especially good example since my French is so awful that the
above is probably full of mistakes.)

That is to say, I may recall what someone said based solely on a
remembered "pattern match", and I may "return" the result, but still
fail to capture it because I don't really understand what the result
"means" beyond the fact that it came from that pattern-match.

One more point about "not being able to control other AIML": it is not
necessary to suggest that the analog of this in human beings is some
kind of "world mind" in which knowledge is retrieved from other sources
-- it is enough to suggest that as a human I do not "rewrite my
categories", so if I have had a "bad education" that might mean that I
don't possess a lot of useful names with which to associate things, but
I am still able to carry on a conversation based on pattern recall. (In
fact, one can go farther and say that the *fewer* names I have for
things, the better, because my potential for learning is unconstrained
by a "sea of assertions" that associate possibly complex things with
simplistic "names".)

I know this is long, but I hope someone will take me up on this and we
can continue to discuss the point. I will pre-agree (what is a better
word for that?) that the form this "proposal" is taking is not suitable
for a real proposal, but if the idea continues to seem fruitful I'll
write it up in a more compact form.

Noel