Yeah, I agree,  “He is well” means he is in good health, mental or physical.  He is good means he is a good person, that is, has a good attitude.

There is no absolutes though.  don’t try nailing all this stuff down to have a perfect chatbot.. you’ll never get it right, each person has their own interpretation.

@Gary: even as a non-native, I understand what you mean.

Nevertheless: is it more important to understand the user, than writing the best algorithm to understand proper English?

And what about making mistakes as a bot? Will he be considered as more human?

Last year, during the IVA conference, I saw a researcher working on virtual humans who spend lots of time researching speaking bots and using ‘mmm’s in natural spoken language. What is considered to be most natural?

@Victor

Interpretation is not the topic exactly.  I thought this thread is how to get the bot to learn.  In an earlier submission which didn’t get posted, I suggested there are several distinct ways of storing the facts from a linking verb like “is”.  I remember a system called REL (Rapid Extension Language) back in the early 1970’s that tried to convert verbs into copulas.  It had storage for “Individuals”, “Classes”, “Relationships” and the definitions of verbs. Thus

“Jan is my name.” is storing for the individual Jan.
“Jan is a person.” is storing the individual Jan in the class of person.
“Jan is old.” is storing the attribute old for the individual Jan.

The last post I made was to point out that individuals not only have modifiers, but also have state, thus “good” is an attribute and “well” is a state.

For the verb “owns”, the REL definition = <subject> is owner of <object>.

Ok, I apologize.  I mixed up my threads here.  But the “Jan is my name.” fits with how to use the parts of speech.  I sorry that I goofed about the bot learning instead of the bot understanding how to put it into a subject-verb-object format.  I think that since the linking is between specific objects and the sentence can be reversed giving the same meaning, that either side of the copula is the subject.  It is <subject> is <subject> for all practical purposes in this context.

Gary Dubuque - Aug 29, 2010:

“Jan is my name.” is storing for the individual Jan.
“Jan is a person.” is storing the individual Jan in the class of person.
“Jan is old.” is storing the attribute old for the individual Jan.

These are great examples.  My bot will know how to differentiate these based on what it knows about the words “name”, “person” and “old”.  Also, it will take into consideration the modifer “a” to “person” to understand that you mean

                Jan is an instance of the class person

I don’t agree with your <subject> is <subject> though.  It is often very tempting to ‘force’ how we think of grammar so it fits a nice simple algorithm, but I think it will lead you to a dead end.  Natural language and grammar are exceedingly complex, and any attempt to ‘force’ it to work a certain way, to make programming easier, will fail.    My approach, is not to force grammar to work to my algorithm, but force my algorithm to work as our grammar does.

  “Jan is my name”

I think you may be confusing the fact that you have two nouns, “Jan” is the subject noun, and “name” is also a noun, but it is the direct compliment noun, whereas “Jan” is the subject noun.  A direct compliment noun forms part of the predicate. 

rule: Sentence = subject (nouns)  +  predicate

subrule: Predicate = verb + compliment

subrule: compliment = adjective or noun

This is only one possible definition of a sentence.  Some sentences, rather than use a single word for the subject noun, can have a noun clause as the subject.    Other sentences do not have any direct compliment noun or direct compliment adjective, but instead simply a verb, and that verb being modified by a prepositional phrase.

here is how my bot parsed that input .. .

pos = simple-sentence
subject.noun1.val = Jan
subject.num-noun = 1
predicate1.dcomp.noun1.adjective1.val = my
predicate1.dcomp.noun1.num-adjective = 1
predicate1.dcomp.noun1.val = name
predicate1.dcomp.num-noun = 1
predicate1.num-verb = 1
predicate1.verb1.val = is

In the above, “dcomp” is short for “direct compliment”. 

Also, I ran the other way through CLUES (“My name is Jan”), here is what it reported…

pos = simple-sentence
num-predicate = 1
subject.noun1.adjective1.val = my
subject.noun1.num-adjective = 1
subject.noun1.val = name
subject.num-noun = 1
predicate1.dcomp.noun1.val = jan
predicate1.dcomp.num-noun = 1
predicate1.num-verb = 1
predicate1.verb1.val = is

Erwin Van Lun - Aug 29, 2010:

Nevertheless: is it more important to understand the user, than writing the best algorithm to understand proper English?

What I am going to do with my bot is, first try proper English grammar.  If that fails to parse the input, the system will then try ignoring some rules, then trying again to see if it is able to parse the input.

Think of it as a spell check, where a given word from the user is compared to known words by how many letters are in common.  Same idea, except, CLUES will determine how many grammar rules it had to ignore in order to parse your input. 

Example, if it had 2 grammar rules, Rule 1 and Rule 2.

If Rule 1 was made up of 3 ‘subrules’ (see above), 1 of which was ignored and was able to parse user input.

If Rule 2 was made of 4 subrules, and 2 had to be ignored to enable parsing,

then system would use Rule1 to interpret the user input.

It could also tell the user so they could improve their english.

Example,  “You are to fast”

this is the incorrect form of ‘to’ , it should be ‘too’.

to = preposition
too = adverb

if CLUES couldn’t parse by using ‘to’ as it was written, it may ‘bend the rules’ and consider ‘to’ as ‘too’, (adverb), and then try again.

If parsing was possible after changing ‘to’ to ‘too’, it will assume the user meant that instead.

CLUES will know this because it knows ‘fast’ is an adjective, and you using don’t have a prepositional phrase of ‘to fast’ with the antecedent of ‘are’.

Instead, ‘fast’ is an adjective being modified by adverb ‘too’ and ‘fast’ is modifying ‘are’.

Since it will have a rule that relates ‘too fast’ to antecedent ‘are’ but NOT have a rule that relates ‘to fast’ to antecedent ‘are’, after it has changed ‘to’ to ‘too’ it will work (parsing would then be possible).

I will have a mapping of commonly misused words like ‘to’ and ‘too’.  Also their, there and they’re.

So to answer your question of proper English versus understanding the user—it still needs to be based on grammar, since the system has to know how far off the user is from each proper English grammar rule.  The rule he/she was closest to, could be what the user really meant.

I just was informed about a classic grammar example. Can you parse this?

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

The example is explained at http://en.wikipedia.org/wiki/Buffalo_buffalo_buffalo

Also, just to play adversary here, there are many, many grammars involved with even just one language like English. Chomsky made one, I think it is called transformational grammar, but it is not the only one. I’ve heard of case grammar, syntax grammar, semantic grammar, dialogue grammar, discourse grammar, story grammar, etc. MontyLingua I suspect uses different grammar than the Link parser and I know that CCG (OpenCCG) can apply various grammars for the same or different languages. I’ve discovered OpenCOG can chat by using Link piped to RelEx (something like the steps used in CLUE) piped to NLGen (although the example they offer for free hasn’t patched in NLGen yet.)  It is interesting to me that sometimes the grammar to generate language is not the same as the grammar to parse it. I’ve even run across the practice of grammar automatically generated by statistical analysis of a large corpus.

I think one grammar, the one we all know, standard, everyday English, will suffice to create a useful chatbot.

I don’t think too many ordinary people use Chomsky’s grammar… but yes, sure, you can add that grammar, all it means is more permutations for the system to check.. it doesn’t mean grammar is not the way to go. 

And yes, my engine would parse that sentence, because it does create every possible permutation for every word’s part of speech.  That is, every word in your sentence can have every part of speech.

Now, in my bot, if it cannot find the appropriate concept specification that filters out all the grammar parse trees to find the probable intended meaning, it will report how many parse trees need to be filtered.  So you’d get a response something like “There are

450 possible parse trees, of which all have a merit value of 5.3, please update concept specifications to be more specific in order for more filtering.”

But an extreme case like Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo, is a bit of a waste of time except for maybe stress testing the bots abilities to generate all grammar parse trees.  But I think normal English, normal everyday complex sentences do that enough !!!

On the other hand, “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo” does reassure me I am on the correct path having grammar as the foundation of my bot, with semantics derived, rather than simple “pattern matching”, you’re right, that would be impossible to parse that way.

If you said that to a human in a text chat, they would think you are insane… and the human would not pass the Turing test.  It is easy to tell why, if researchers have been chasing these useless avenues of investigation, why we have no computer that can carry a

conversation, a normal, English grammar conversation like two humans have.

Good post though, I see you’re really thinking about this.

But I feel there is an endless requirements list, and most of those requirements are useless.

It’s something like this..

Goal - build a system that can move people from A to B

solution - a car.

No, fail !  a car can’t fly.. and flying is a form of transportation.

ok, let’s work even longer and think of building a plane

No, fail ! a plane can’t take me to the moon

...etc…etc..

Let’s start somewhere and not worry about our car flying, or a chatbot parsing Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.

Let’s worry about useful, practical things it can do, like parsing sentences that are just as long as “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo” but that an average person, in a productive conversation uses.

And work our way up, not try to solve an infinite number of issues on our first try.

I think people believe that an AI should be able to do absolutely everything—they watch too much science fiction

Hi guys,
sorry for the ridiculously late reply. I tend to zoom out of the world a bit when working intensely (new release coming shortly).
Anyway, it turns out that in my system at least (and at the moment), it is easier to rely on the semantic stage for figuring out whether to interpret ‘Jan is my name’ as ‘subject-verb-object’ or ‘object-verb-subject’. And for this particular example, I am breaking English grammar rules. it’s just to ridiculous not too (but makes the semantics all the more important for other sentences like some of the previously given examples by various people). I’m breaking grammar rules more and more by the way for other stuff as well: future time and sentences like ‘I could do that, I would do that, I should do that, I will do that, (you get the idea, forgot the exact name), my current path of thought leads me to thinking they are all the same, english grammar rules makes to many distinctions). Basically, I’m trying to redesign my grammar in such a way that it mostly recognises small chunks like agent, verb,... but not the particular order of things, this is handed over to later stages.

Well, looks like I’ll have to eat my words on this one. Though it would be easier for some examples, the sementical technique I had in mind begins to stutter with other stuff, so this will probably be a dead end.

Yep, don’t re-invent the wheel my friend.  Grammar has already been figured out by people years and years ago.  I just go with it

Final results are in. After fixing a few basic bugs in the algorithm, things started to fall into place. I think I now have a working mix to get bad grammar in simple sentences working. I’ve mostly concentrated on the verb ‘be’ but other verbs appear to follow roughly the same rules, so ‘filling in’ the rest will be for later.
You should now be able to say things like: me be jan, Jan I am,...
Of course, it’s just a first version of the algorithm, so it still needs some more work to get all the caveats out of it. You can try it out in the new web based version of Aici from here.
I think I’ll be focusing on getting complex sentences working, cause I need those to get the self modifying code going.