Well, I feel better I didn't truly ruffle any tail feathers...
I'm in agreement that AIML does not basically need any real changes to
accommodate a secondary channel. I would say that it is probably more
fitting to call it a telemetry channel. In a multi-user environment, I would
not propose the addition of one secondary channel per user, although, I
suppose there's no real reason why it could not be done.
When I wrote the REXX program to run in an IBM mainframe's z/OS TSO
environment, I tinkered with using the alternate input for what I call
unsolicited interrupts in a conversation. My initial tests used messages to
alert the conversing user some event occurred; perhaps a batch program ended
or a time-initiated event occurred. Great stuff.
I supposed I should detail this idea further with some more background
information... This is kind of exciting.
One thing led to another. I realized the oopic application could work when I
observed members of the B9 Robot Builders Club putting on a demonstration.
These folks have done an absolutely remarkable job recreating a replica of a
robot character from a 1960's television program. These fully articulated
models are very realistic in just about every respect except most are
controlled by a joystick or laptop. In standing there watching, I thought to
myself, "My God, this is a perfect application for an ALICE chatbot
program." So, I opened a Pandorabot account and started to define the
personality of the robot as was portrayed by two actors on the show. I have
a group of about 17 testers out of 300 members that are exercising the AAA
code excising and changing every bit of what we feel is not in character. We
then bring in other members who have not chatted before and ask them to rate
the experience. Our initial goal is to build a usable AIML set that truly
has the personality of the robot (and is G-rated, as well).
We've been working out the details of porting the AIML to an ALICE program
running in the B9 frame. We are going to add a modification to pipe the text
output to a Text To Speech program. The actor that did the original robot
voice is available and we will undoubtedly ask him to help us build a voice
dictionary. TTS is the next priority as everybody wants to hear the robot
talk.
Now these folks have been using oopics to control the robot frame, the
oopics track position increments in stepper motors, degrees of movement in
arm and grip actuators, and quite a few other features. I saw no reason why
the alternate channel could not pass simple ASCII codes back and forth.
Conceptually, what I've done is made up an AIML set that takes a directive
from ALICE, "RAISE YOUR RIGHT ARM" and would do a "commented" call to a
specific oopic (they are networked together to the PC) and instructs it to
start the action.
Separately, I've coded patterns to handle any status string any oopic would
generate, but I could not let the string be spoken or show up on the user
interface. That's where the second channel fit so well, because I needed to
keep the flow of data coming back from different sources hidden.
Steve, would not the Prolog side have the ability to populate a table where
one row could consist of one or more columns containing the X10 address and
the status of the address? Since the X10 network would not change much in
terms of number of stations, could you not use a simulated table of
predicates or variables, one assigned per X10 station? Build some code that
takes the SQL table and populates the predicate table. So, if you coded
something like, <get name="A10"/>, you would have the status of A10 at your
disposal, then do an SRAI to take some action depending on the value of A10?
Perhaps you could also have an algorithm that periodically does a <think> or
some action that dumps a changed value back from ALICE into the SQL table.
Well, I've probably written way too much this evening, but I was just so
anxious to share this idea. I hope I didn't bore anyone.
Thanks.
Dave
-----Original Message-----
From:
alicebot-developer-admin@...
[mailto:
alicebot-developer-admin@...] On Behalf Of
alicebot-developer-request@...
Sent: Thursday, May 26, 2005 3:00 PM
To:
alicebot-developer@...
Subject: alicebot-developer digest, Vol 1 #473 - 1 msg
Send alicebot-developer mailing list submissions to
alicebot-developer@...
To subscribe or unsubscribe via the World Wide Web, visit
http://list.alicebot.org/mailman/listinfo/alicebot-developeror, via email, send a message with subject or body 'help' to
alicebot-developer-request@...
You can reach the person managing the list at
alicebot-developer-admin@...
When replying, please edit your Subject line so it is more specific
than "Re: Contents of alicebot-developer digest..."
Today's Topics:
1. Re: Subconscious Alice (Steve Prior)
--__--__--
Message: 1
Date: Wed, 25 May 2005 23:51:30 -0400
From: Steve Prior <
sprior@...>
To:
alicebot-developer@...
Subject: Re: [alicebot-developer] Subconscious Alice
Reply-To:
alicebot-developer@...
Dave Sienkiewicz wrote:
...
> 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.
...
>
> 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-developerEnd of alicebot-developer Digest
_______________________________________________
alicebot-developer mailing list
alicebot-developer@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer
