[alicebot-archcomm] Topic handling
Ernest Lergon
alicebot-archcomm@list.alicebot.org
Mon, 28 Jul 2003 18:12:06 +0200
Jonathan Roewen wrote:
> Dr. Rich Wallace wrote:
>> There is a lot of material in this proposal.
>
> Hehe, yup .. that's our Ernest ;-)
>
I take this as compliment ;-)
> Ernest Lergon wrote:
>> The use of the attribute "value" is consistent in the face of the
>> overall use of name/value in AIML.
>
> Where is value attribute used? It's <get name="name"/>, <set name="name"/>,
> and the other (prolly) most common attribute used is "index". The only
> occurence of value that I can think of is with <condition> and it's <li>
> children.
>
You pointed out the best examples:
<set name="topic">LIZARDS</set>
<condition name="topic">
<li value="LIZARDS"> ... </li>
...
So the *name* of the predicate is 'topic' and it's *value* is 'LIZARDS'.
In correct XML you could also say:
<set name="topic" value="LIZARDS"/>
Shortening the above term delivers:
<topic value="LIZARDS">
BTW: The advantage of not using the attribute- but the content-form of
<set> is to be more flexible in preparing the content by calling other
AIML elements inside <set>.
It's only consequent to apply the proposed change.
> [context, nesting, history]
>
I think, allowing an arbitrary change of the topic inside the category,
when a top-level topic is defined, makes everything *more* complex.
We have to look at <topic> not as a simple variable like <set> or <bot>
but a structuring element, which has special characteristics. Using
top-level <topic/that> as well as pattern-side <topic/that> opens a
better way to group categories. This must be backed by the interpreter
returning errors, if the grouping rules are hurt.
The following lists give the allowed contexts - aka the hierarchy,
elements are encountered by the AIML-parser:
aiml category topic that
aiml category that topic
aiml topic category that (no topic in category)
aiml that category topic (no that in category)
aiml topic that category (neither topic nor that in category)
aiml that topic category (neither topic nor that in category)
An example tree in different views aka groupings:
aiml
cat1
patternA
topic2
that2
/cat1
cat2
patternB
topic1
that2
/cat2
cat3
patternC
topic1
that1
/cat3
cat4
patternD
topic2
that2
/cat4
/aiml
aiml
topic1
cat2
patternB
that2
/cat2
cat3
patternC
that1
/cat3
/topic1
topic2
cat1
patternA
that2
/cat1
cat4
patternD
that2
/cat4
/topic2
/aiml
aiml
that1
cat3
patternC
topic1
/cat3
/that1
that2
cat1
patternA
topic2
/cat1
cat2
patternB
topic1
/cat2
cat4
patternD
topic2
/cat4
/that2
/aiml
aiml
topic1
that1
cat3
patternC
/cat3
/that1
that2
cat2
patternB
/cat2
/that2
/topic1
topic2
that2
cat1
patternA
/cat1
cat4
patternD
/cat4
/that2
/topic2
/aiml
BTW: This approach makes it easy to implement an export function for an
AIML editor - giving the author a simple choice of how to group the cats
in the produced AIML files.
We have talked about consistence - one part of it is having clear
structures without many exceptions.
So <topic> is analog to <that>, because it *has* a history as well:
Having a topic stack or not is the same question as having a that stack
or not as well as having an input stack or not etc.
Moreover we could ask, why can't we access <that> with <get
name="that/">? Why can't we access <star> with <get name="star"/>? You
see the point?
I think, <topic>, <that> and <input> are separate from <set/get> and
this must be reflected in their specifications.
BTW: To keep the user predicates (aka memory stored between each call)
small, ProgramV implements a "forget threshold" of a hardcoded lenght of
42 stack entries for <input> and <that>. This should be configurable by
the botmaster and should be applied to <topic> as well.
> If case matters, there are tags to manipulate case .. <lowercase>
> <uppercase> <formal> and <sentence>. So paying attention to case is only for
> the lazy programmer/aiml writer.
>
This is an English-centristic view. It isn't that easy - what about
languages like German, where the case of words really matters? And
<that> and <input> as well as <star> are stored "as-entered" already to
avoid those problems. I just wanted to point out another analogy between
<topic> and <that>.
>> I think, that a topic stack is useful especially in catch-all categories
>> to return to a previous topic.
>
> They're harder to keep track of, and what do you do when you want to
> completely erase the topic stack? What if you set the topic instead of using
> push, and then call pop? There are a multitude of issues that have yet to be
> uncovered for such an implementation.
>
Yes, we have to keep track of the conversation topics, which is now only
possible with complex "pure" AIML constructs. An interpreter-side
implemented topic stack will simplify this.
Setting a topic according to the proposal is always pushing it on the
stack. And we could simply define another attribute like:
<topic clear/> erase the topic stack,
set current topic to '*'
(and again, it might read clear="1" or clear="all" - XML gurus? )
We are still in an experimental phase with AIML. I think, we should
offer certain functionallity and see, what AIML writers make out of it.
And again: One of the goals should be the overall consistence of AIML.
Ernest
--
ProgramV - Alice on Perl - available at
http://www.virtualitas.net/perl/aiml/
VIRTUALITAS - Manufacturer of fine OOPPS - since 1996
*********************************************************************
* VIRTUALITAS Inc. * http://www.virtualitas.net *
* Ernest Lergon * mailto:Ernest@virtualitas.net *
*********************************************************************
PGP-Fingerprint 6E6F DC17 A886 342D D63F 7880 12F5 6BA9
PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
---------------------------------------------------------------------
SPAM ALERT http://www.virtualitas.net/spam.html
---------------------------------------------------------------------