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

[Kim Sullivan]

Second try.

What you actually want is to 'freeze' and record all state variables (this
includes star, that, topic and the output...) at the time a specific
category was activated. Something like a giant CVS system that allows you to
retrieve previous states.

Each time you activate a category, you save:
The user input,
All variables,
All matched wildcards
The processed template (the unprocessed also? I'm not sure this would be
necessary, since <random> could not be restored properly, but then again
what if the template changed completely?).
...
Activation count
Delta activation count (how many activations between the last 2 successive
activations)

The question is, would you store also the progression of the states, or just
the 'after' state, or also the 'before' state? Imagine a category like this:

<category>
<pattern>EXAMPLE</pattern>
<template>
some text...
<set name="var">value1</set>
some text...
<set name="var">value2</set>
other text...
<set name="var">value3</set>
</template>
</category>

Which value would
<get pattern="EXAMPLE><get name="var"/></get>
return?

A don't think that using the <get> element is a good idea (I know you're
trying to use the 'predicate' approach, but it seems just too complicated,
sorry). Something like <remember> would be IMVHO better, since you want the
bot to remember what it knew at the time the pattern EXAMPLE was activated.
(remember has 2 meanings, this might be dangerous - remember as 'I remember
what it was' and 'I will remember from now on'). Maybe 'reflect', or
'recall'. I'm not that good in English, in Czech we have the words
'vzpomenout' and 'zapamatovat' (in Russian they might be similar?).

using the 'reconstruction' mechanism is only one possible way to implement
it, storing all values would be another, using a CVS-like 'diff' system
(each activated category would be a 'revision') a third way.
Using the 'reconstruction' approach might be usefull if you modify the
template to set a new variable (that's not directly connected to the input,
like if you add a mood variable to all the categories) - you would get
'backward' knowledge (pretty weird thought - somewhat Pratchett-esque), but
what if also the actual values were modified in the template?

On to your other points:

> 1. I can retrieve things that were captured even if I have no control
> over the AIML (as when I am using AIML that is served from somewhere
> else).

I'm not exactly sure about this (in regards to AIML from somewhere else).
Since I still don't have control over 'foreign' AIML, I can't possibly guess
the patterns that might have been used to represent some knowledge. If I use
the construction
<get pattern="MY NAME IS *"/>
I will probably add  the pattern "MY NAME IS *" to my set too (each known
possible pattern should be added to the set, there is no such thing as a
wrong pattern). We would get some more 'control' if we could use the user
input to construct the category reference (trying to reference a category by
the wildcard just matched).

> 2. When writing AIML, I don't always have to predict which values I'll
> want to save for later use.  I can refer to the values by a more direct
> means -- their "meaning" with respect to some particular utterance --
> rather than being constrained to think up arbitrary names to associate
> with these values.

You're probably right with this one, but I don't see why I couldn't just
modify the category I'm referring to to capture the value in the future. One
reason might be 'backwards compatibility': Even if I didn't specifically
capture a value (since I didn't know I'd need it sometimes in the future),
it will stay remembered and possible to retrieve - and Alice's statement 'I
remember everything' will finally become true (not only as a metaphor to the
chatlogs the botmaster can process).

> Joe like "I like apples", or some action Joe took that I "interpreted"
> (symbolically reduced) to "I like apples".  I don't need to give special
> status to "likes" in understanding that: what I give special status to
> is the variable part of "I LIKE *", as it sits within the invarying
> part.

My personal opinion is that if we take the symbolic reduction one step
further, we can reduce the statement 'I like apples' to a variable
assignment. YMMV.

The idea of remembering every possible bit of information looks promising
though, even when I think we shouldn't talk about 'predicates'.

Looking forward to hear your thoughs,
Kim