|
View:
New views
3 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: proactive alice (was: alicebot-developer digest, Vol 1 #471 - 2 msgs)--- 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 msgsI'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 |
| Free Forum Powered by Nabble | Forum Help |