[alicebot-archcomm] Loose ends

[Ernest Lergon]

Kim Sullivan wrote:
> 
> Ernest Lergon wrote:
> > 
> > why don't you send some storm troops to drag me to the court in Den Haag
> > and call it 'humanitarian intervention'?
> 
> I'm sorry, I should have been more thoughtful in my choice of words.
> 
You're welcome!

> I'm not even sure if there should be an 'official' standpoint about this -
> sometimes it helps newbies to realize that its not the usual use of markup,
> and sometimes it helps to point out that it's not just another procedural or
> object oriented PL.
>
Maybe not 'offical' - but clarifying our goals.

So let's find a compromise - ssssssiiiiigggghhhhhh...

(Some terms in the following paragraph are intentionally ambiguous ;-)

   The Artificial Intelligence Markup Language is a Scripting Language
   used to specify an Artificial Linguistic Internet Computer Entity.

Therefore we can have different views on AIML without violating the
Origins and Goals stated in the specs:

1. Scripting as Description

The handfull of tags now recommended are sufficient to describe a
personality in the sense of the stimulus-response algorithm using Zipf's
law.

This will invite newbies to experiment with AIML and enable them to
achieve positive results soon.

I would second a proposal to move some or most of the tags now used in
different ways by the various implementations (ProgramD,V: startup.xml,
server.properties; J_Alice: std-startup.aiml etc.) into AIML fullfilling
the promise made in the specs: "AIML does not currently provide a
mechanism for specifying default values of predicates from within AIML."
- e.g. <bot...>: It's more clearly to a define a constant from within a
system I think.

2. Scripting as Programming

Future features will enable the botmaster to really program an ALICE:
Some tags will provide managing of complex datastructures as well as
grammar processing, games or logic, other will help setup knowledge
bases, memory or learning.

This will attract us eggheads to use AIML for intelligent applications
that become "so dominant as to be incomprehensible to us" (Richard M.
Dolan).

Think of what <shuffle> implies: What is it worth to have a tag just
providing draw-without-put-back without other features for a card game
like remembering the drawn cards, obeying the rules, counting points and
maybe even strategy - or conscious cheating?

Moreover using a plain <shuffle> - even with sophisticated mix
algorithms - to avoid repeated answers isn't sufficient. A more natural
conversation would be like:

U: Tell me what AIML is
A: AIML is...
U: What is AIML?
A: Didn't you understand? AIML is...
U: AIML is what?
A: I told you.
U: Please repeat.
A: Ok. AIML is...
[...time passes...]
U: Can you define AIML?
A: You asked that 10 minutes ago.
[...next day, same user...]
U: What is the meaning of AIML?
A: I told you yesterday.
U: Please repeat.
A: No. Why do you ask me always the same?

Please imagine, what this kind of dialogue implies: Full blown
array/hash processing with <add>, <remove>, <pop>, <push>, <sort>,
<reverse>, <index> etc. plus ALICE' awareness of time and context.

There could be a poor-man's <that/>- and <input/>-check already (I'm
sure, Kim will find a solution for this in pure AIML ;-)) but this leads
us again to the problem: What means 'equal'?
'Tell me what' == 'What is' == 'Can you define' == 'What is the
meaning'...

3. Scripting as Markup

Another part of AIML tags could be reserved for knowledge exchange
between ALICEs.

This will enable different AIML interpreters to communicate safely.

In this context I do not second the idea of AIML being an exchange
format on the whole. The better way are well-defined tags forming a
machine-readable interface (in contrast to plain text, HTML or voice).

For me reading a foreign AIML file into the running interpreter is like
unauthorized brain surgery. The botmaster must examine the warnings
while test-loading such a file offline - using the same configuration as
on his server. Generally it's not a good idea to take over unchecked
knowledge.

Therefore the question, if tags like <system>, <perl> or <php> make
problems on virtual AIML machines not interpreting them, needs not to be
answered. We have already a procedure to deal with this: The
forward-compatible processing definition. That should not hinder us to
discuss further a more general extension approach like <script...>.

But defining a subset of AIML tags only for knowledge exchange might
smoothly build a web of ALICEs - maybe like the PGP web of trust.

Just my 2.02 euro-cents (the dollar is falling ;-))

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  *
*                                *                                  *
* European Consultant Office     *                                  *
* Internationales Handelszentrum *                                  *
* Friedrichstraße 95             *   contact:Ernest Lergon          *
* 10117 Berlin / Germany         *    mailto:Ernest@virtualitas.net *
*********************************************************************
       PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc