dont.aiml

ALICE 利用AIML (Artificial Intelligence Markup Language)来形成对你的查询和输入的响应。不像其它花费数千美元的商业聊天机器人软件

<br>
On most newer browsers, the agent software will download <br>
automatically after the script starts.  The download may take<br>
several minutes, depending on the speed of the connection.<br>
Clients should be warned that the download is slow.  Also,<br>
the agent software download will display one or more licenses<br>
in Dialog boxes.  You may not want to accept the terms of the<br>
MS agent software licenses.  <br>
<br>
</template>
</category>
<category>
<pattern>CAN YOU HELP ME DEBUG THE ANIMATED AGENT</pattern>
<template><br>
Look at the class Animagent.java.  The method vbscript_html(reply)<br>
does nothing unless the global Animagent member is true.  In that case,<br>
the vbscript_html() method constructs a string from the reply that<br>
includes an MS Agent VBScript embedded in the HTML reply.<br>
This makes the browser load up the objects required for the agent.  <br>
<br>
The text reply just becomes part of the VBScript.  <br>
You may have to download and run the Robby the Robot<br>
agent software and the text-to-speech synthesis software from <br>
the MSDN homepage:<br>
<br>
http://msdn.microsoft.com/workshop/imedia/agent<br>
<br>
We wish other companies were producing agent animation API's <br>
for free but this MS Agent seems to be about the only <br>
thing out there now. <br>
<br>
Join the ALICE and AIML mailing list at alicebot.listbot.com<br>
to see how others are working with the animated agent software.<br>
<br>
</template>
</category>
<category>
<pattern>CAN I SPEAK TO THE ROBOT WITH VOICE INPUT</pattern>
<template><br>
One simple experiment that works well as a demo<br>
involves using IBM ViaVoice (tm) speech recognition<br>
software on a Windows platform.  At the same time,<br>
run the ALICE program B web server and activate the<br>
MS Agent interface.  The ViaVoice software allows<br>
you to dictate into an application called VoicePad,<br>
but not directly into the browser.  You have to<br>
use "cut" and "paste" to move your speech inputs<br>
into the browser form for ALICE.  But the net effect<br>
is a somewhat slow voice-in voice-out conversation<br>
with ALICE.  <br>
<br>
The ViaVoice software seems to work well with ALICE<br>
after some training.  We trained it with the file<br>
"patterns.txt" created with the "List Patterns" command.<br>
<br>
</template>
</category>
<category>
<pattern>HOW DOES ALICE KEEP TRACK OF CONVERSATIONS</pattern>
<template><br>
Originally ALICE used IP addresses to keep track of clients.<br>
Assuming that everyone chatting with ALICE has a fixed IP<br>
address, at least for the duration of their conversation,<br>
this technique works successfully.  Each IP address is a key<br>
into a hashtable (or database) that stores the client's<br>
dialogue, name, and values of pronouns and other AIML values.<br>
<br>
Unfortunately, many clients have "dynamic IP addressing" enforced<br>
by their ISP provider.  AOL and MS WebTV are two notorious examples: <br>
each successive client transaction appears to come from a different<br>
host.  For this reason, program B uses a form of "virtual IP"<br>
addressing to track dialogues.  <br>
<br>
The form in index.html (and the ALICE home page) contains a<br>
tag that creates a "hidden" parameter called "virtual" with<br>
an initial value of "none."  The server assigns a unique name<br>
to the value of "virtual", which then becomes a hidden variable<br>
in the client's HTML form.  Each successive client transaction<br>
contains this virtual IP address; the server uses it as a key<br>
to index the conversation.<br>
<br>
</template>
</category>
<category>
<pattern>CAN THE VIRTUAL IP BE THE REAL IP</pattern>
<template><br>
Actually that would be the default case, when the client chats from<br>
the same fixed IP address.  The only time the virtual ip differs from<br>
the real one is when the client is behind a dynamic firewall, like<br>
WebTV or AOL customers.<br>
<br>
</template>
</category>
<category>
<pattern>CAN I RUN THE WEB SERVER AS A DAEMON PROCESS</pattern>
<template><br>
Yes.  There is a class file called Bterm.java in the<br>
program B distribution.   Bterm runs the web server<br>
as a console application, with no GUI.  You can<br>
redirect the output of program Bterm to a log file<br>
and start the process in the background with<br>
"java Bterm &gt; B.log &" (assuming a Unix shell). <br>
<br>
</template>
</category>
<category>
<pattern>HOW DOES ALICE REMEMBER CLIENTS BETWEEN SESSIONS</pattern>
<template><br>
The persistence of memory in ALICE is inherited from<br>
the Java Properties class.  The program B class Classifier<br>
saves the client name, age, location and other properties<br>
in a set of Properties lists.  These Properties inherit<br>
the Java load and store methods.  Program B uses the load<br>
and store methods to save the client properties in a set of<br>
files with names ip_name.txt, ip_age.txt, ip_location.txt <br>
and so on.  If these files become too large or bothersome,<br>
there is no harm deleting or editing them, or moving them<br>
to another directory. <br>
<br>
The Applet requires no memory of the client properties, because<br>
the applet has only the one client, and in any case remains in <br>
memory (at least for the lifetime of the client's browser cache).<br>
<br>
<br>
</template>
</category>
<category>
<pattern>HOW DOES THE APPLET WORK</pattern>
<template><br>
Program B supports the creation of both server-side and client-side <br>
chat robots.  The server runs as a thread in program B.  The <br>
client-side version is supported by an applet called Blet.java.<br>
<br>
The Applet Blet.java runs ALICE in a web browser, or with <br>
the Java tool appletviewer.  The file "index.html" contains an<br>
example of the HTML Applet tag syntax needed to start<br>
the Applet.  The command "appletviewer index.html" will start the<br>
Applet.<br>
<br>
You also have to create the file "index.html" and change the<br>
default value of the parameters "codebase" and<br>
"applethost" serve the Applet from your location.<br>
<br>
</template>
</category>
<category>
<pattern>HOW DOES THE APPLET DIFFER FROM THE APPLICATION</pattern>
<template><br>
The Applet runs on the client's computer; the server runs<br>
on your host machine.  The applet has fewer privileges and<br>
therefore a simpler user interface than the Application,<br>
which uses menus and buttons to control server-side functions.<br>
The Applet may reside on any web server, such as one provided<br>
with an ISP account, but the application requires a 24/7<br>
connection to the Web. <br>
<br>
Internally, the primary difference between the two programs<br>
is that the Applet handles only one client conversation, <br>
while the application processes multiple client connections<br>
simultaneously.  The Applet also suppresses all HTML (and any<br>
other XML) from the client response.<br>
<br>
</template>
</category>
<category>
<pattern>HOW DO I CREATE AN APPLET</pattern>
<template><br>
Go to the Options menu and select "Show Options."  You need<br>
to change the values of "AppletHost" and "CodeBase" to the<br>
correct IP address and directory for your applet host. <br>
Many people want to post the applet on their web site.<br>
In that case, change the IP address "206.184.206.210" to<br>
the name or IP address of the web server.  Change the<br>
directory path "/B" in "CodeBase" to your directory on<br>
the remote server.  Save the changes with "Save Options."<br>
<br>
Select "Create Applet" from the options menu to create<br>
the "index.html" and "Blet.aiml" files needed to run<br>
your applet.  The program displays the contents of <br>
"index.html" in your text area.<br>
<br>
Use a file transfer utility like FTP to upload the<br>
class files (or jar file--see "What files do I need to<br>
run the Applet") to your web server.  <br>
<br>
</template>
</category>
<category>
<pattern>LIST TWELVE BASIC APPLET TIPS FOR AIML USERS</pattern>
<template><br>
1. Applets are notoriously hard to debug; you are not dumb.<br>
2. An applet can work perfectly well in Appletviewer, but<br>
then break in the browser, for any number of reasons.<br>
3. Let's get the terminology straight: the applet resides on<br>
an "originating host" but runs on a "target machine".<br>
4. The browser is very picky because of the "security<br>
sandbox"--the browser doesn't trust Applets so they can't<br>
open files (and obey other restrictions) on the target machine.<br>
5. The Applet MAY open a socket connection from the<br>
target machine to the originating host.<br>
6. When you are debugging the applet, the target machine<br>
might be the same as the originating host (your computer).<br>
7. When you post your applet to a remote web server,<br>
that server becomes the originating host.<br>
8. You can use ftp to transfer the Applet files to the<br>
remote web server.<br>
9. You must transfer ALL the applet's files <br>
to the originating host.<br>
10. You must change the program B values of "CodeBase"<br>
and "AppletHost" (the originating host) to the name and<br>
location of the files on the remote server.<br>
11. Use "Create applet" to create the "index.html" and<br>
"Blet.aiml" (make sure you have the latest release of B.zip)<br>
12. We recommend placing all the *.class files into<br>
a single "Blet.jar" file (see DON'T READ ME).<br>
<br>
<br>
</template>
</category>
<category>
<pattern>CAN THE APPLETHOST USE A SYMBOLIC DNS NAME INSTEAD OF AN IP NUMBER</pattern>
<template><br>
The answer is yes, but the numeric IP address works on more machines<br>
than a symbolic name.  Applets are protected by a "security sandbox"<br>
from interfering with local resources on your machine.  One restriction<br>
is that Applets may only open socket connections to the originating<br>
host.  When using a symbolic DNS name, the "sandbox" may not know that <br>
two variations such as "Www.AliceBot.Org" and "alicebot.org" are<br>
in fact the same server.  The client might not be able to resolve <br>
the DNS name, and the Applet will throw a security exception.<br>
<br>
</template>
</category>
<category>
<pattern>WHAT FILES DO I NEED TO RUN THE APPLET</pattern>
<template><br>
You only need the java *.class files and the *.aiml files<br>
to run the ALICE Applet, no more files are necessary. <br>
You can also put all the class files in a single jar<br>
file like Blet.jar.  The sample index.html provided with the ALICE <br>
distribution uses this Blet.jar file.  <br>
<br>
Not all of the Java source files are involved in the Applet.<br>
You can use the following command to compile all the Java source<br>
files needed for the Applet:<br>
<br>
javac Access.java Globals.java StringFile.java Substituter.java \<br>
   Classifier.java Loader.java Animagent.java Log.java Blet.java<br>
<br>
Then, you can use zip (or jar) to collect the class files into<br>
a single jar file:<br>
<br>
zip -r Blet.jar *.class <br>
<br>
The *.class will include all the class files you compiled.  <br>
<br>
The *.aiml files have to be on the same host that serves the Applet. An applet<br>
can only open files on the server it originated from.<br>
<br>
Don't forget to change the Applet host parameters in index.html, when<br>
you upload the applet to an ISP.<br>
<br>
</template>
</category>
<category>
<pattern>DOES THE APPLET RECORD DIALOGUES</pattern>
<template><br>
The applet tries to log conversations on the originating server,<br>
using a cgi-bin script called "Blog".  If Blog exists then<br>
it records the dialogues in a file called "dialog.txt" (or<br>
another name chosen on the Options menu).  <br>
<br>
Actually the cgi-script need not actually exist, because the server<br>
records the cgi-commands as errors in the access log.<br>
The applet opens a URL connection to the its host, and<br>
sends a log string that looks like an HTTP request, but the HTTP<br>
server will log it as an error (with code 404). Later on you can<br>
download the access_log and analyze it with program B.<br>
<br>
See the code in Classifier.java for the method log(x) that<br>
implements the URL connection.<br>
<br>
</template>
</category>
<category>
<pattern>CAN I ANALYZE THE DIALOGUES COLLECTED BY THE APPLET</pattern>
<template><br>
If the web server produces an access_log file, such<br>
as /var/log/httpd/access_log, then the server records<br>
Applet dialogue in the access_log file.  You may use<br>
ftp to download the access_log file to your machine;<br>
then run program B to analyze it.  <br>
<br>
Go to the Options menu and find the value for "AnalysisFile".<br>
The Classify function operates on the data in the AnalysisFile.<br>
By default the AnalysisFile is the same as the LogFile (the<br>
current server log file).  But you can change the analysis<br>
file to another name, such as /var/log/httpd/access_log or<br>
just access_log.<br>
<br>
</template>
</category>
<category>
<pattern>CAN THE APPLET RECORD A DIALOG TXT FILE ON THE SERVER</pattern>
<template><br>
No because the applet cannot write the file directly on the originating host.<br>
If your server log file /var/log/httpd/access_log is too large; you <br>
have a couple of choices:<br>
1. If your ISP is a unix account, use telnet to log on to a shell account.<br>
Use the command "grep Blog &lt; access_log &gt; dialog.txt" to create a smaller<br>
file to download which contains just the lines recorded by the applet.<br>
2. Create a CGI-BIN command called "/cgi-bin/Blog" that reads its<br>
command-line argument and appends it to a file called "dialog.txt".<br>
There ought to be a nice Perl script for this, or even a shell script.<br>
<br>
</template>
</category>
<category>
<pattern>I AM STILL HAVING PROBLEMS WITH THE APPLET</pattern>
<template><br>
If your applet is looking at Blet.aiml and your web space is at <br>
www.myplace.org and your aiml files are in dirctory /alice/ then<br>
your load statements in Blet.aiml would look similar to this:<br>
&lt;lo