[alicebot-developer] RE: alicebot-developer digest, Vol 1 #471 - 2 msgs
Gary Dubuque
alicebot-developer@list.alicebot.org
Wed, 25 May 2005 18:48:45 -0700
I've been toying with a similar idea because I want the predicates in the
<set> and <get> to be generated by a blackboard system of some outside
agents. In multi-user interpreters, this is somewhat problematic, but in
Program N, it is a real possibility. So I tried an experiment. Input comes
from the built-in web server. It triggers a category that runs a script
command to output into the text editor. A sample category is like this:
<category>
<pattern>ARMRAISED</pattern>
<template>Ack<script>"The arm is raised."</script></template>
</category>
Which thus responds to the program reporting the arm's status through a http
post (to localhost:81) with an "Ack" back on that channel. At the same time
it also displays the text about the arm's raised status in the Program N
editor. I tried to make the MS agent actually speak the status, but it seems
the current version can't do it (might be something to do with threads.)
But it is totally possible for the web interface to add data by way of
predicate values to the editor's interface. Thus you have the alternate
path for transparent inputs to the conversation and can experiment with
effects that mechanism might produce.
Ok, this may be considered a bug in the Program N interpreter, but it might
be a fun one to play with!
-----Original Message-----
From: alicebot-developer-admin@list.alicebot.org
[mailto:alicebot-developer-admin@list.alicebot.org]On Behalf Of Dave
Sienkiewicz
Sent: Wednesday, May 25, 2005 4:39 PM
To: alicebot-developer@list.alicebot.org
Subject: [alicebot-developer] RE: alicebot-developer digest, Vol 1 #471
- 2 msgs
Well thank you very much for taking the time to respond to my rambling.
I sincerely appreciate it. I'm not trying to flame you but I would like to
clarify my ideas. Nor am I frustrated because, as I said, I have written an
ALICE interpreter in REXX that expounds the idea and let me just reiterate
it changes the quality of the conversation raising it to a new level. I
thought I'd share the idea.
Your explanation of the <srai> construct wasn't necessary and somewhat
missed the mark. <think> would have been more appropriate I believe but
still not really applicable. It's my fault.
What you did not consider is that in my example, the oopic controller is a
device which can function somewhat independently of the stimulus of being
passed an AIML template. First, I should have made you aware there can be
latency between the time a command is passed off to it, and the time needed
for the mechanism to service the request. The interpreter can continue
chatting and not have to wait for the mechanism to complete its operation.
It's more realistic to let things appear to operate asynchronously than
synchronously. The hidden input, whether by TCPIP socket, serial interface,
or some other method allows that to information to be passed without the
user actually seeing the string of data that is informing ALICE.
Secondly, again using an oopic as an example, it could signal ALICE as a
result of some event taking place. Let's say, a pressure sensitive switch
closed, an oopic could send a status message to ALICE indicating this event
occurred, and ALICE could respond, "Someone touched me". What I do is queue
the secondary input in FIFO order with any user input that might be going on
at the time.
I agree that very little new language specification is required, but seeing
that the title of this list is "alicebot-developer" not "AIML-standard",
gave me a distinct impression the topic was entirely appropriate and open
for discussion. Wallace's works discuss the design of the interpreter almost
as much as the language itself.
If you are looking at areas of the language specification where improvements
could be made, one of the most troubling problems I have with it, is that
the chatbot talks at you not to you. Conversations are whatever the AIML
parsing finds. What would be terrific is finding a way to establish zones of
security and confidentiality, based on an identified user, and on a level
lower than topic. I've been toying with an idea of setting a security level
in a pattern. Then I could see these systems gaining widespread business
use, and not usage seemingly limited to college science labs and students.
Some sort of tagged AIML security interface would work not unlike some of
the earlier versions of large-scale commercial transaction processing
systems.
I have to say I enjoyed reading your sweeping generalizations used to try to
strengthen your technical points of view. You must hail from an academic
environment. Bravo, sir! Thanks for the discussion!
Dave
-----Original Message-----
From: alicebot-developer-admin@list.alicebot.org
[mailto:alicebot-developer-admin@list.alicebot.org] On Behalf Of
alicebot-developer-request@list.alicebot.org
Sent: Wednesday, May 25, 2005 3:00 PM
To: alicebot-developer@list.alicebot.org
Subject: alicebot-developer digest, Vol 1 #471 - 2 msgs
Send alicebot-developer mailing list submissions to
alicebot-developer@list.alicebot.org
To subscribe or unsubscribe via the World Wide Web, visit
http://list.alicebot.org/mailman/listinfo/alicebot-developer
or, via email, send a message with subject or body 'help' to
alicebot-developer-request@list.alicebot.org
You can reach the person managing the list at
alicebot-developer-admin@list.alicebot.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of alicebot-developer digest..."
Today's Topics:
1. Subconscious Alice (Dave Sienkiewicz)
2. Re: Subconscious Alice (Helio Perroni Filho)
--__--__--
Message: 1
From: "Dave Sienkiewicz" <daves1@ptd.net>
To: <alicebot-developer@list.alicebot.org>
Date: Tue, 24 May 2005 19:15:54 -0400
Subject: [alicebot-developer] Subconscious Alice
Reply-To: alicebot-developer@list.alicebot.org
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C56095.022F1200
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
------=_NextPart_000_0000_01C56095.022F1200
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>For the past few months, I’ve been =
experimenting with
writing <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">ALICE</st1:place></st1:City>
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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Say for example, I have <st1:City =
w:st=3D"on"><st1:place
w:st=3D"on">ALICE</st1:place></st1:City> running on a PC that is =
interfaced to
an OOPIC controller that can raise or lower an actuator that we’ll =
call
an arm.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Imaging conversing with <st1:City =
w:st=3D"on"><st1:place
w:st=3D"on">ALICE</st1:place></st1:City>, 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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks for your time.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dave Sienkiewicz<o:p></o:p></span></font></p>
</div>
</body>
</html>
------=_NextPart_000_0000_01C56095.022F1200--
--__--__--
Message: 2
Date: Tue, 24 May 2005 21:39:08 -0300 (ART)
From: Helio Perroni Filho <xperroni@yahoo.com>
Subject: Re: [alicebot-developer] Subconscious Alice
To: alicebot-developer@list.alicebot.org
Reply-To: alicebot-developer@list.alicebot.org
--- Dave Sienkiewicz <daves1@ptd.net> escreveu:
> 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.
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@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-developer
End of alicebot-developer Digest
_______________________________________________
alicebot-developer mailing list
alicebot-developer@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-developer