I’m having a thesis, building a Chatterbot that sells stuff.

I’m planning to build it using ASP .net in Visual studio, with the use of pattern matching.
But still i don’t have any ideas upon it.

I’m also thinking if i can Connect AIML with ASP.

Can someone help me, and suggest the steps on doing my thesis and some guidance in pattern matching?

Thanks.

Welcome to the forum!

Is this a graduate or undergraduate thesis? (And relatedly, what is the time line for this project’s completion?) This will make a big difference in defining the goals for your chatbot. What specific aims do you have in mind? How do you intend to measure how successfully your bot achieves these aims? I suggest discussing this with your advisor if you haven’t worked out a clear gameplan yet. It’s easy to get bogged down in the details and lose sight of your goal. There has been a body of work developing bots for commercial purposes. What do you hope to add to/improve about their capabilities?

Most of the members here post using their real name and often a picture as well. It’s not required, but it may help you get more replies.

Suggestion:

Start simple with a bot that only answers yes or no questions,
depending on whether your input string length is odd of even.
The modulus operator works good for this.  I think about 99%
of this layout will be put to use when you extend this simple
bot design with regular expressions to match the input string.

Try http://www.aimlpad.com and under “AIMLpad Alternatives” download the ChatBot.zip

It is a ASP.NET user control that employs a MS SQL database containing AIML categories.  It is free source you can use to get you started coding your chat bot if you are really interested in ASP and AIML.  Nothing fancy, just the basics in a draft form.  I used it with DotNetNuke.

8PLA • NET - May 9, 2011:

Suggestion:

Start simple with a bot that only answers yes or no questions,
depending on whether your input string length is odd of even.
The modulus operator works good for this.  I think about 99%
of this layout will be put to use when you extend this simple
bot design with regular expressions to match the input string.

I wouldn’t rely on even and odd numbers of letters to indicate yes or no. What if the user says, “yeah”?

I agree, Steve. There are a LOT of holes in that method, I think. Input character count can’t allow for “maybe”, or “I don’t know”, either.

I suggested that the first chatbot design which was the forerunner
to Eliza, could be help, to build a new chatbot design from scratch. 

Here is how it worked… It only took yes or no questions, like this:
1. Count the total number of characters typed in by the user asking the question.
  a. If this count was even, it would answer: yes.
  b. If this count was odd, it would answer: no.

It is a very simple, very small chatbot engine, which let’s you focus
on the user interface design.  You can always swap out this tiny chatbot
engine with a more advanced chatbot engine later.  However, the interface
stays basically the same.

My point was that this is a good way to divide the bot building up into smaller tasks.
You would at least have a working bot, that you built yourself, with a minimum of coding.
Then you could extend the simple chatbot engine to pattern match on more data, to go beyond
just the limited “yes” or “no” responses.

I had a lot of fun building one this morning, to debug AJAX for the Program O project:

http://www.79b.org/fakeProgramO

Ok, that makes more sense than the way I had perceived it. My bad.

Let’s simplify by saying the bot sells only apples (instead of multiple products). The bot can start by saying, “Welcome to bot apples store, how may I help you?” Then the fun starts.  The bot will have to use regular expressions to handle the customers making the same requests in many different ways:

I need apples
I need some apples
I need to get apples
I would like to get apples
I need to get some apples
I would like to get some apple
I need to order apples
I would like to order apples
I need to order some apples
I would like to order some apples
I need to buy apples
I would like to buy apples
I need to buy some apples
I would like to buy some apples
I need to purchase apples
I would like to purchase apples
I need to purchase some apples
I would like to purchase some apples
I’m looking for apples
I’m looking for some apples
I’m looking to order apples
I’m looking to order some apples
I am looking for apples
I am looking to order apples
I am looking for some apples
I am looking to order some apples
Can you help me find apples
Can you help me find some apples
Do you have apples
Do you have any apples
Do you have any apples on sale
Where can I get apples
Where can I find apples
Where are the apples located

NOTE: Please don’t read this as me trying to make things complicated.  I’m not. I promise.  No one sees the insides of the bot brain, except us.  It is just that the more situations the bot can handle, the more amazing it is going to be, which in this case can be measured with increased sales figures.  I think this is a nice idea for a chatbot ... Making sales!

From there, the bot should help the customer determine what type of apples they need:

Fresh apples
Dried apples
Canned apples
Apple butter
Apple Candy
Apple Computer (I had to toss this in. Sorry)
etc.

With each type listing applicable varieties:

Fresh apples:

  Granny Smith
  Red Delicious
  Crab apples
  etc.

Even the simplest of sales bots will have a layered complexity that can quickly become (as Gnomb would say) “not-simple”.

However, that said I think the end product is well worth the effort.

[edit]For those confused by my somewhat esoteric reference, Gnomb is the Troll “god of eat” in the book series The Tamuli, written by David Eddings.[/edit]

Excellent point Dave,

And to handle just a handful of the customer requests in both of our examples,
the code may look similar to this ASP.NET C#:

(Code is untested. Posted just for the sake of conversation.)

The regular expression “^I (want|need|would like) (some|dried|canned) apples$”
translates to, “I want, or need, or would like, some, or dried, or canned, apples” which
allows it to make a decision on quite a range of customer requests. 

Of course, this can be extended to match much further than this.

One of the aspects of pattern matching is context.  A bot that expects a certain topic can reduce the number of patterns to try to match.  ChatScript is an example of this technique.  AIML added the <topic…> tag to accommodate this - although it had an another alternative of using the last exchanged text in the <that…> tag.  If you start your design with context in mind, you’ll have a distinct advantage later when composing the patterns.  Another context to consider, which is more important in the generation of the output, is the bot’s emotional state. A compatible state to the customer’s will increase sales.

Eliza uses keywords for matching.  That’s still a viable technique for getting the jist of an input.  It means much of the input can be lost, but really it does solve the need to find a reply in a database of responses.

I came across this article in the April 19, 2011 edition of Dr Dobbs magazine which I’d like to try:

“From the Vault: Ternary Search Trees”
By Jon Bentley and Robert Sedgewick
This seminal article from 1998 by two luminary algorithm specialists presents a new data structure, ternary search trees, which combine the time efficiency of digital tries with the space efficiency of binary search trees. The resulting structure is faster than hashing for many typical search problems, and supports a broader range of useful problems and operations.

If a trie is a word instead of a character, it might be a bit slower. The article shows some techniques for partial matches (like using wildcards) or near neighbor matching (like a given word within 3 of the another given word.)  I’m not sure regular expressions can do near neighbor matches. I know AIML does not.

Whoops, the near neighbor stuff described in the article is about a miss match on one or more tries, not on a trie being in various positions in the input.  Still I’d like to code a ternary search tree and experiment some on even the word ordering problem which shouldn’t be too hard to resolve.

Gary Dubuque - May 10, 2011:

Whoops, the near neighbor stuff described in the article is about a miss match on one or more tries, not on a trie being in various positions in the input.  Still I’d like to code a ternary search tree and experiment some on even the word ordering problem which shouldn’t be too hard to resolve.

Some clarification may be needed, sorry!

I use ternary search tries (TST) for a long time (years), and they are integrated into my stuff, are useful for robust for word-seeking, but not for pattern matching! If you use it, you need to build a new TST for each pattern-making the whole thing nasty and slow. (I mean runtime). Also this is no a compact stuff, it wastes a lot of space, the big O access is not logarithmic, its asymptotically linear.

The best approach is to build an automaton, and implement the graph for making one or more symbols optional, this works fine and is fast and scalable, you may also compile the whole thing, and build a table (transition table) then your automaton must only jump from rows to columns as the symbols are input and if you are in a terminal state when the input symbols ends, you’ve got a match! voila!