RE: alicebot-developer digest, Vol 1 #471 - 2 msgs

View: New views
3 Messages — Rating Filter:   Alert me  

Parent Message unknown RE: alicebot-developer digest, Vol 1 #471 - 2 msgs

by Dave Sienkiewicz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
[mailto:alicebot-developer-admin@...] On Behalf Of
alicebot-developer-request@...
Sent: Wednesday, May 25, 2005 3:00 PM
To: alicebot-developer@...
Subject: alicebot-developer digest, Vol 1 #471 - 2 msgs

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-developer
or, 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. Subconscious Alice (Dave Sienkiewicz)
   2. Re: Subconscious Alice (Helio Perroni Filho)

--__--__--

Message: 1
From: "Dave Sienkiewicz" <daves1@...>
To: <alicebot-developer@...>
Date: Tue, 24 May 2005 19:15:54 -0400
Subject: [alicebot-developer] Subconscious Alice
Reply-To: alicebot-developer@...

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@...>
Subject: Re: [alicebot-developer] Subconscious Alice
To: alicebot-developer@...
Reply-To: alicebot-developer@...

--- Dave Sienkiewicz <daves1@...> 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@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer


End of alicebot-developer Digest



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

Re: proactive alice (was: alicebot-developer digest, Vol 1 #471 - 2 msgs)

by Helio Perroni Filho :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

> 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.

Oh, I have no doubts the idea you exposed has the
potential to greatly improve the quality of a
human/bot conversation. I only disagree that it has
anything to do with changing AIML; instead, the way I
see it, it's exclusively a matter of AIML interpreter
features.

> 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.

So it's just another instance of my second
implementation suggestion, where a backdoor input
channel allows other processes to stimulate the AIML
interpreter, which in turns responds to the human user
interface.

Now I hope you don't use HTML mail, because it would
mess my diagrams up. Usual bot operation would go like
this, with the bot and the human user exchanging
messages:

+-----+ ---> +------+
| BOT |      | USER |
+-----+ <--- +------+

Occasionaly, however, an external application (like
your OOPIC controler) would send the bot a message
through a backdoor channel. The bot treats it just
like it received an input to the user, so it sends the
response to the user:

+-------+      +-----+      +------+
| OOPIC | ---> | BOT | ---> | USER |
+-------+      +-----+      +------+

My point is, this design is completely external to the
AIML language. It could easily be implemented around
the AIML interpreter, so not even it would know that
some of its stimuli comes from an actor other than the
user.

> 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.

Neither I argued against it. Just because I don't see
any need of changing the AIML language to make a more
proactive AliceBot doesn't mean I am against the
discussion itself.

> 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.

Stereotypes make for good start points when dealing
with people, but just as generalizations, they can be
misleading. So far my graduation course on computer
science accounts for all my academic experience; I am
very much an inhabitant of the private sector, where I
work since my early college days.

Yes, I did push a little too hard when doing that
wrap-up. But my point remains: why demand AIML to do
everything you want, when you can leave it at doing
what it does best and build the rest around it? It's
like the UNIX guys say: "be small, focus on what
you're supposed to do, know how to talk with other
applications".

AIML is simple for a reason -- so common people can
use it. It seems many people with a technical
background fail to realize that, because I often see
they bashing AIML or proposing ways to "fix" it. While
I don't believe AIML to be perfect, I don't see much
good in bloating it with stuff that could well be
built on top of it.

--
Ja mata ne.
Helio Perroni Filho


__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/ 
_______________________________________________
alicebot-developer mailing list
alicebot-developer@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer

RE: RE: alicebot-developer digest, Vol 1 #471 - 2 msgs

by Gary Dubuque :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
[mailto:alicebot-developer-admin@...]On Behalf Of Dave
Sienkiewicz
Sent: Wednesday, May 25, 2005 4:39 PM
To: alicebot-developer@...
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@...
[mailto:alicebot-developer-admin@...] On Behalf Of
alicebot-developer-request@...
Sent: Wednesday, May 25, 2005 3:00 PM
To: alicebot-developer@...
Subject: alicebot-developer digest, Vol 1 #471 - 2 msgs

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-developer
or, 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. Subconscious Alice (Dave Sienkiewicz)
   2. Re: Subconscious Alice (Helio Perroni Filho)

--__--__--

Message: 1
From: "Dave Sienkiewicz" <daves1@...>
To: <alicebot-developer@...>
Date: Tue, 24 May 2005 19:15:54 -0400
Subject: [alicebot-developer] Subconscious Alice
Reply-To: alicebot-developer@...

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@...>
Subject: Re: [alicebot-developer] Subconscious Alice
To: alicebot-developer@...
Reply-To: alicebot-developer@...

--- Dave Sienkiewicz <daves1@...> 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@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer


End of alicebot-developer Digest



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


_______________________________________________
alicebot-developer mailing list
alicebot-developer@...
http://list.alicebot.org/mailman/listinfo/alicebot-developer
LightInTheBox - Buy quality products at wholesale price