Subconscious Alice

For the past few months, I’ve been experimenting with writing ALICE algorithms in REXX and in my ham-handed attempts at programming, I discovered something quite by accident that is so interesting in the way it changes the quality of a conversation that I just had to pass it along.

 

In a nutshell, the change is simply to add a secondary means of input that the end-user would not normally see to the program. Everything else is exactly the same, but what it provides is a way of simulating something being remembered or an event being experienced, by interfacing what I call scheduled events, status codes, things of that nature, that may affect a conversation. I see this kind of an option of particular use in robotics although I’m sure there are situations useful in just chatting.

 

Say for example, I have ALICE running on a PC that is interfaced to an OOPIC controller that can raise or lower an actuator that we’ll call an arm.

I can code a pattern of RAISE ARM with a template composed of the utterance “OK” plus a system call to the OOPIC of a code that commands the actuator to be raised.

I can then program the OOPIC controller to return a string of characters when the arm is raised. The string could essentially be a status word, e.g. “ARMISRAISED” which the user does not see, but could for example trigger a template with the utterance, “Uh, my arm is raised as high as it can go.” It kind of works like “think” but the data is being externally input from an unseen source instead of directly from the user.

 

Another example, let’s say I have a crontab or some other scheduling resource. Theoretically, I could use that to signal an event. For example at 2100 hours, perhaps I could send a secondary input of a pattern SLEEP 2100, which can have a template assigned, “It is 9 PM. It’s time to go to sleep.” Or let’s say I have a wireless X10 controller that issues simple ASCII codes that can advise on a house temperature, status of light switches, burglar alarms and so on. X10 would issue a code like A21 which could be assigned, “The light was left on in the study.” I mean there are a lot of applications, fingerprint reader, UPS alarm; all kinds of stuff could be done.

 

Imaging conversing with ALICE, and having her suddenly say, “there’s someone coming to the front door”, just before the door bell rings. Being able to accept hidden status information in the form of simple ASCII strings, I think, opens up an entire new level of realism.

 

I’m not advocating that we rip all our existing code apart to add this interface, but I think this is something that is well worth considering in future versions.

 

Thanks for your time.

Dave Sienkiewicz

--- Dave Sienkiewicz <daves1@...> escreveu:

Well, I hope this won't frustrate you -- it certainly
doesn't diminish the value of thinking of it by
yourself -- but AIML already provides a mechanism for
doing what you described. It's called the <srai> tag,
and it works by feeding its contents back to the input
parser, then returning the output.

Let's code your example of the robot arm in a way
compatible with my ChatterBean AIML interpreter:

<category>
  <pattern>RAISE ARM</pattern>
  <template>
    Ok.
    <srai>
      <!-- In ChatterBean, the system tag feeds its
      contents to a BeanShell interpreter. This is not
      against the AIML standard, but it's unusual
      enough that I thought necessary to notice it.
-->
      <system>
        Arm arm = new Arm();
        /* the tag will return the contents of the
        system variable converted to string. */
        system = arm.raise();
      </system>
    </srai>
  </template>
</category>

<category>
  <pattern>ARMISRAISED</pattern>
  <template>
    Uh, my arm is raised as high as it can go.
  </template>
</category>

If the arm.raise() call returns the "ARMISRAISED"
string, the following dialogue would be possible:

<user> Raise arm.
<bot> Ok. Uh, my arm is raised as high as it can go.

> Another example, let's say I have a crontab or some
> other scheduling resource. Theoretically, I could
> use that to signal an event. For example at 2100
> hours, perhaps I could send a secondary input of a
> pattern SLEEP 2100, which can have a template
> assigned, "It is 9 PM. It's time to go to sleep."

Now that's something I can't think of doing with AIML
alone -- but then again, it has more to do with the
interpreter application than with the language itself.
If my interpreter, say, left a socket open for
accepting remote inputs, but printed the corresponding
outputs to the user interface, then I could have
another application (like a cron daemon) sending it
some warn about an event, and it would in return send
some message to the user.

> I'm not advocating that we rip all our existing code
> apart to add this interface, but I think this is
> something that is well worth considering in future
> versions.

AIML scope is to provide a good way for representing
stimulus/response information; deciding how or when
this information will be accessed is someone else's
job. What you propose are alternative channels for
stimuli to get to a bot's brain; it's a good idea, but
it has to do with AIML interpreters and the system
around them, not the AIML language.

Bloat kills. Different AI technologies are best suited
for different classes of problems; it's by combining
them together, and not by trying to apply the same
tool in all tasks, that more intelligent systems will
become possible.

--
Ja mata ne.
Helio Perroni Filho



       
       
               
____________________________________________________
Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br
_______________________________________________
alicebot-developer mailing list
alicebot-developer@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer

Dave Sienkiewicz wrote:
... ...
>
> Imaging conversing with ALICE, and having her suddenly say, “there’s
> someone coming to the front door”, just before the door bell rings.
> Being able to accept hidden status information in the form of simple
> ASCII strings, I think, opens up an entire new level of realism.
>
> Dave Sienkiewicz
>

Given that my personal project is home automation, I have done some things
similar to what you're talking about, but I took a different approach.
I have a simple natural language interpreter I wrote in Prolog which handles
the "action" type inputs like "Please turn on the outside lights." which
calls some Prolog libs I wrote which make CORBA calls to an X10 server which
turns on the lights.  Then the Prolog side returns a string like "The lights
are now on" which is passed back to the chat window the user typed in.  In
the event that the sentence is not parsable by my Prolog engine, the input
string is passed through the http interface to an Alicebot which provides the
answer to the chat interface.  The user doesn't know that two different
systems cooperated to provide a seamless user interface (in fact the programs
are on different computers), but the effect is pretty impressive.
Since the chat interface I provide for the user is actually also a CORBA service
I can send it asynchronous messages like your "someone is coming to the front
door." without any problems.

The thing I'm missing at the moment is for the two systems to share "context"
information so that if the Alicebot learned something in the conversation, the
Prolog side doesn't have access to it.  Since both systems can access MySQL
tables there is a possibility I can use this, but first I'd have to rip out
the caching that Alicebot does for those tables - haven't gotten around to that
yet.  The other thing I don't handle well yet is multiple userid support
between the two pieces like Alicebot does through its web interface.

Steve
_______________________________________________
alicebot-developer mailing list
alicebot-developer@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer