Closed leungmanhin closed 8 years ago
@leungmanhin Which component needs link grammar? We don't have OpenCog nlp running in HR stack as I know. I guess you meant in the near future when we integrate OpenCog chatbot/OpenPsi, we will need link grammar. I can create a branch and add the link grammar to hrtool for the coming OpenCog chatbot/OpenPsi.
@wenwei-dev Yes that's what I meant, also relex (https://github.com/opencog/relex/tree/master/install-scripts) is needed for opencog nlp to work as well, would be nice if it can be added to hrtool too
Both octool -l
and https://github.com/opencog/relex/tree/master/install-scripts
will install Link Grammar, but in different ways.
octool installs the current version (which is now 5.3.7), relex script installs the version of 5.3.3 and builds it with Java7. Which one should I use? I guess both can work.
I think using the current version in octool is better
Thanks @wenwei-dev !
Wenwei,
The OpenCog AIML interpreter mostly works now, especially after fixing a bug (in atomspace) yesterday. Theres 's still a bit more cleanup and grooming that needs to be done, but its ready to test, and there should be bug reports opened for the things that don't work right. The behavior is slightly different than classic AIML: it doesn't always use the "best fit" rule, but instead randomizes things a bit. At the moment, topicstar and thatstar are not supported, -- I vaguely plan to add these -- but it seems these are not really needed, so I wasn't sure if I should bother. There will be other changes in the near future, so things won't be quite stable for a while, but I really would appreciate any sort of testing and feedback.
The AIML pipeline does NOT need link-grammar. However, the question-answering portions do. Question-answering does not yet work very well, and it will be a while before it does, but again, this is a component worth messing around with, to see how it works.
topicstar is used 3 times in the alice legacy chatbot aiml, thatstar 41 times.
To be safe we could replace these answers (one is something we've actually heard, How do you like your life in Hong Kong) not using these constructs, or delete them altogether. In general I stripped a lot of other star response material so that people can't get the robot to say horrible things by star substitutions.
On Thu, Jun 9, 2016 at 9:48 AM, Linas Vepštas notifications@github.com wrote:
Wenwei,
The OpenCog AIML interpreter mostly works now, especially after fixing a bug (in atomspace) yesterday. Theres 's still a bit more cleanup and grooming that needs to be done, but its ready to test, and there should be bug reports opened for the things that don't work right. The behavior is slightly different than classic AIML: it doesn't always use the "best fit" rule, but instead randomizes things a bit. At the moment, topicstar and thatstar are not supported, -- I vaguely plan to add these -- but it seems these are not really needed, so I wasn't sure if I should bother. There will be other changes in the near future, so things won't be quite stable for a while, but I really would appreciate any sort of testing and feedback.
The AIML pipeline does NOT need link-grammar. However, the question-answering portions do. Question-answering does not yet work very well, and it will be a while before it does, but again, this is a component worth messing around with, to see how it works.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-224918656, or mute the thread https://github.com/notifications/unsubscribe/AF3ylznxwySN-NkmW7N84QVRFBHOEDR4ks5qKCe2gaJpZM4ItXsJ .
I am in favor of ignoring topicstar and thatstar in the OpenCog AIML system, and rephrasing any critical rules that use them, so as to not use them...
I don't think these are terribly hard, but I'd rather minimize the amount of AIML-ish hassle we need to deal within OpenCog ---- since over the next 6-12 months we are likely to get rid of this explicit AIML stuff from OpenCog anyway; I see this as scaffolding...
-- ben
On Fri, Jun 10, 2016 at 1:27 AM, demaris notifications@github.com wrote:
topicstar is used 3 times in the alice legacy chatbot aiml, thatstar 41 times.
To be safe we could replace these answers (one is something we've actually heard, How do you like your life in Hong Kong) not using these constructs, or delete them altogether. In general I stripped a lot of other star response material so that people can't get the robot to say horrible things by star substitutions.
On Thu, Jun 9, 2016 at 9:48 AM, Linas Vepštas notifications@github.com wrote:
Wenwei,
The OpenCog AIML interpreter mostly works now, especially after fixing a bug (in atomspace) yesterday. Theres 's still a bit more cleanup and grooming that needs to be done, but its ready to test, and there should be bug reports opened for the things that don't work right. The behavior is slightly different than classic AIML: it doesn't always use the "best fit" rule, but instead randomizes things a bit. At the moment, topicstar and thatstar are not supported, -- I vaguely plan to add these -- but it seems these are not really needed, so I wasn't sure if I should bother. There will be other changes in the near future, so things won't be quite stable for a while, but I really would appreciate any sort of testing and feedback.
The AIML pipeline does NOT need link-grammar. However, the question-answering portions do. Question-answering does not yet work very well, and it will be a while before it does, but again, this is a component worth messing around with, to see how it works.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-224918656 , or mute the thread < https://github.com/notifications/unsubscribe/AF3ylznxwySN-NkmW7N84QVRFBHOEDR4ks5qKCe2gaJpZM4ItXsJ
.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-224967085, or mute the thread https://github.com/notifications/unsubscribe/AFolXKZb0MYf07sGU-TnzOwLebRjftZXks5qKEz7gaJpZM4ItXsJ .
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
The need to author and precisely craft dialogs will remain an important requirement indefinitely -- the robot will, de-facto, get deployed in various situations where canned dialogs will be a requirement.
Regarding the use of stars -- we now certainly have the capability to restrict the star matching -- for example: accept a * match only if * is one of this explicit set of words, or * is a happy word or * is the name of a thing or * is a verb that is a synonym for "take a flying leap" -- the ability is now there, the hard part is inventing some way to make it easy for such things to be authored by the non-programmer.
--linas
On Thu, Jun 9, 2016 at 8:42 PM, bgoertzel notifications@github.com wrote:
I don't think these are terribly hard, but I'd rather minimize the amount of AIML-ish hassle we need to deal within OpenCog ---- since over the next 6-12 months we are likely to get rid of this explicit AIML stuff from OpenCog anyway; I see this as scaffolding...
-- ben
On Fri, Jun 10, 2016 at 1:27 AM, demaris notifications@github.com wrote:
topicstar is used 3 times in the alice legacy chatbot aiml, thatstar 41 times.
To be safe we could replace these answers (one is something we've actually heard, How do you like your life in Hong Kong) not using these constructs, or delete them altogether. In general I stripped a lot of other star response material so that people can't get the robot to say horrible things by star substitutions.
I'd like to run it on my work machine. I remember there are some manual steps to populate the database, and run the server. Those are not integrated. Maybe Man Hin @leungmanhin can help make a script to run the same thing that we ran Tue. night?
On Fri, Jun 10, 2016 at 12:13 PM, Linas Vepštas notifications@github.com wrote:
The need to author and precisely craft dialogs will remain an important requirement indefinitely -- the robot will, de-facto, get deployed in various situations where canned dialogs will be a requirement.
Yes, agreed. Whether AIML syntax in particular is the way we want to do this authoring for OpenCog -- indefinitely -- is obviously a different question, though..
Regarding the use of stars -- we now certainly have the capability to restrict the star matching -- for example: accept a * match only if * is one of this explicit set of words, or * is a happy word or * is the name of a thing or * is a verb that is a synonym for "take a flying leap" -- the ability is now there, the hard part is inventing some way to make it easy for such things to be authored by the non-programmer.
Understood...
@wenwei-dev ok I'll do that
By the way for the aiml files, we have "generic" and "futurist" in HEAD/src/chatbot/aiml/
, and for Sophia some of those in character_dev/character_aiml/
will also be needed I believe, is there any more we need to load?
Thanks.
No, those are all we use for Sophia. I don't know how you will load them and store them. Those in character_dev are proprietary content, so should not be put in public repository.
On Fri, Jun 10, 2016 at 5:35 PM, leungmanhin notifications@github.com wrote:
@wenwei-dev https://github.com/wenwei-dev ok I'll do that
By the way for the aiml files, we have "generic" and "futurist" in HEAD/src/chatbot/aiml/, and for Sophia some of those in character_dev/character_aiml/ will also be needed I believe, is there any more we need to load?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225138435, or mute the thread https://github.com/notifications/unsubscribe/AAhJ93FuAOyTK959ZkJo-T0y49Q1kxSNks5qKS_2gaJpZM4ItXsJ .
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas notifications@github.com wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248, or mute the thread https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ .
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
If there is any algorithmic transformation of the aiml that would be useful for a different kind of matching, I have some facility by now with this 'beautiful soup' library. So it's pretty easy for me to do things like delete some construct only in certain AIML elements.
It sounds like maybe you would like to eliminate the stars in the pattern fields and just match on keywords? That's probably pretty easy to do in your input parser as well.
Maybe a bigger issue for using any of the generic files is does the opencog AIML substitution work - I understood that it probably did, since things like star and that substitute variable values into the response. We eliminated some but not all of the star tags that do substitution.
As far as I know all the files in generic are loaded - it's possible to do a subset or control the order in .yaml.
On Fri, Jun 10, 2016 at 10:46 AM, bgoertzel notifications@github.com wrote:
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas notifications@github.com wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248 , or mute the thread < https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ
.
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225219473, or mute the thread https://github.com/notifications/unsubscribe/AF3ylxrPHVOGL-UOaDlX7W5F76fLz1o7ks5qKYbGgaJpZM4ItXsJ .
Hi Ben,
On Fri, Jun 10, 2016 at 6:46 PM, bgoertzel notifications@github.com wrote:
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
Ooh, I really like some of these ideas, but others won't work as written.
First -- the fuzzy matcher only finds similar graphs -- it does NOT do input-to-output re-writing. However, we possibly could use the fuzzy matcher to do the matching of OpenPsi rules -- that is an interesting idea that needs exploration and work (and I guess I should be the one to try to do this)
Next, there isn't one, but two fuzzy matchers: a "raw" one and a "linguistic" one. The raw one just computes a similarity score by comparing two graphs, with no special treatment. The "linguistic" one is being developed by ManHin, its a bit ad-hoc, I assume, but it tries to do linguistic matching, e.g. treating noun matches as being more important than matching or missing out on determiners, or for example, allowing verbs to match even if tenses do not agree. I have not reviewed ManHin's work, I suppose its time I did.
As far as I know, neither the "raw" nor "linguistic" fuzzy matchers provide a fill-in-the-blanks capability, which would be needed for handling stars. I had started work on this, long ago, but set it aside after some difficult technical issues cropped up.
One of the places where AIML wastes CPU time is in "SRAI" which is used to normalize inputs -- that is, to convert slang expressions into a common form, and then look up the response for the common form. I've noticed that some of the SRAI rewrite chains can be quite long -- 3 or 5 or 6 lookups deep. Its certainly possible that we could use the fuzzy matcher instead of using SRAI for many of these cases .. maybe... however, the fuzzy matcher (in its current form) will never realize that "que pasa mumbasa" is a synonym for "hello". We still have a weak architecture for synonymy.
Yes, I like the idea of using the fuzzy matcher in more places, its a good
--linas
p.s. I envision that we could use fuzzy matching for identifying the conditions for openpsi clauses in general: a fuzzy match to what is being seen, not just to what is has been said. However, that means that we would need a third fuzzy matcher: one that is tuned to visual processing. Or something like that?
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas notifications@github.com wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248 , or mute the thread < https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ
.
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225219473, or mute the thread https://github.com/notifications/unsubscribe/AAFwoNTEDottC4yetTy12TcApCLqRnLmks5qKYbFgaJpZM4ItXsJ .
Hi David,
Right now, the OpenCog AIML implementation is more or less fully and completely compatible with standard AIML (with some asterisks **) One asterisk is some minor details I'll fix when back in Austin. The other asterisk is that all applicable AIML rules get a shot at running, and are given proportional weights -- this differs from the AIML spec, which mandates that only the last rule fires. The random weighting thing was done because that seems to be closer to what HR wants .. the current HR python AIML engine was modified to do something like this.
I've said this before, I'll say it again: OpenCog allows you to write far more powerful, flexible, fancy-ass rules than what AIML allows. Use that to go wild. Trying to figure out how to restrict yourself is counter-productive.
--linas
On Fri, Jun 10, 2016 at 8:26 PM, demaris notifications@github.com wrote:
If there is any algorithmic transformation of the aiml that would be useful for a different kind of matching, I have some facility by now with this 'beautiful soup' library. So it's pretty easy for me to do things like delete some construct only in certain AIML elements.
It sounds like maybe you would like to eliminate the stars in the pattern fields and just match on keywords? That's probably pretty easy to do in your input parser as well.
Maybe a bigger issue for using any of the generic files is does the opencog AIML substitution work - I understood that it probably did, since things like star and that substitute variable values into the response. We eliminated some but not all of the star tags that do substitution.
As far as I know all the files in generic are loaded - it's possible to do a subset or control the order in .yaml.
On Fri, Jun 10, 2016 at 10:46 AM, bgoertzel notifications@github.com wrote:
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas < notifications@github.com> wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248 , or mute the thread <
https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ
.
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225219473 , or mute the thread < https://github.com/notifications/unsubscribe/AF3ylxrPHVOGL-UOaDlX7W5F76fLz1o7ks5qKYbGgaJpZM4ItXsJ
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225244190, or mute the thread https://github.com/notifications/unsubscribe/AAFwoKTEILLEbMXzXRZv83ZzxK5zQgXSks5qKZ4zgaJpZM4ItXsJ .
We are now using the fuzzy matcher for (star-free) pickup rules and it seems to work OK...
At the moment Man Hin is serving as the "master brewer" of the dialogue system, and I'm serving as the "reviewer /tester", soon to be augmented in that role by Rui Ting ...
On Thu, Jun 16, 2016 at 1:14 AM, Linas Vepštas notifications@github.com wrote:
Hi David,
Right now, the OpenCog AIML implementation is more or less fully and completely compatible with standard AIML (with some asterisks **) One asterisk is some minor details I'll fix when back in Austin. The other asterisk is that all applicable AIML rules get a shot at running, and are given proportional weights -- this differs from the AIML spec, which mandates that only the last rule fires. The random weighting thing was done because that seems to be closer to what HR wants .. the current HR python AIML engine was modified to do something like this.
I've said this before, I'll say it again: OpenCog allows you to write far more powerful, flexible, fancy-ass rules than what AIML allows. Use that to go wild. Trying to figure out how to restrict yourself is counter-productive.
--linas
On Fri, Jun 10, 2016 at 8:26 PM, demaris notifications@github.com wrote:
If there is any algorithmic transformation of the aiml that would be useful for a different kind of matching, I have some facility by now with this 'beautiful soup' library. So it's pretty easy for me to do things like delete some construct only in certain AIML elements.
It sounds like maybe you would like to eliminate the stars in the pattern fields and just match on keywords? That's probably pretty easy to do in your input parser as well.
Maybe a bigger issue for using any of the generic files is does the opencog AIML substitution work - I understood that it probably did, since things like star and that substitute variable values into the response. We eliminated some but not all of the star tags that do substitution.
As far as I know all the files in generic are loaded - it's possible to do a subset or control the order in .yaml.
On Fri, Jun 10, 2016 at 10:46 AM, bgoertzel notifications@github.com
wrote:
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas < notifications@github.com> wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248 , or mute the thread <
https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ
.
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225219473 , or mute the thread <
https://github.com/notifications/unsubscribe/AF3ylxrPHVOGL-UOaDlX7W5F76fLz1o7ks5qKYbGgaJpZM4ItXsJ
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225244190 , or mute the thread < https://github.com/notifications/unsubscribe/AAFwoKTEILLEbMXzXRZv83ZzxK5zQgXSks5qKZ4zgaJpZM4ItXsJ
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-226255610, or mute the thread https://github.com/notifications/unsubscribe/AFolXJkkE-B20g46r3YfrShkfeykm7flks5qMDMEgaJpZM4ItXsJ .
Ben Goertzel, PhD http://goertzel.org
Super-benevolent super-intelligence is the thought the Global Brain is currently struggling to form...
Well I think I got a relex build to work yesterday so I'm ready to start shooting my foot or something. Is this the best documentation, or is there some other starting point now that integrates with HEAD, tts etc? I have some problem that prevents me running webui cleanly but this sounds like it's indepdendent.
https://github.com/hansonrobotics/opencog/blob/master/opencog/nlp/chatbot/README
On Wed, Jun 15, 2016 at 12:14 PM, Linas Vepštas notifications@github.com wrote:
Hi David,
Right now, the OpenCog AIML implementation is more or less fully and completely compatible with standard AIML (with some asterisks **) One asterisk is some minor details I'll fix when back in Austin. The other asterisk is that all applicable AIML rules get a shot at running, and are given proportional weights -- this differs from the AIML spec, which mandates that only the last rule fires. The random weighting thing was done because that seems to be closer to what HR wants .. the current HR python AIML engine was modified to do something like this.
I've said this before, I'll say it again: OpenCog allows you to write far more powerful, flexible, fancy-ass rules than what AIML allows. Use that to go wild. Trying to figure out how to restrict yourself is counter-productive.
--linas
On Fri, Jun 10, 2016 at 8:26 PM, demaris notifications@github.com wrote:
If there is any algorithmic transformation of the aiml that would be useful for a different kind of matching, I have some facility by now with this 'beautiful soup' library. So it's pretty easy for me to do things like delete some construct only in certain AIML elements.
It sounds like maybe you would like to eliminate the stars in the pattern fields and just match on keywords? That's probably pretty easy to do in your input parser as well.
Maybe a bigger issue for using any of the generic files is does the opencog AIML substitution work - I understood that it probably did, since things like star and that substitute variable values into the response. We eliminated some but not all of the star tags that do substitution.
As far as I know all the files in generic are loaded - it's possible to do a subset or control the order in .yaml.
On Fri, Jun 10, 2016 at 10:46 AM, bgoertzel notifications@github.com wrote:
I looked at the various AIML files in the character-dev, futurist and generic aiml folders today...
A couple thoughts are
1) The various files labeled "pickup" are not responses but rather conversation-initiators. They can just be fed into OpenCog as non-AIML sentences, to be chosen by the fuzzy matcher rather than the AIML engine.
2) A bunch of the AIML rules are basically just triggered by small sets of keywords. Often they are large sets (3-30, maybe) of responses, collectively triggered by the same small set of keywords or keyphrases...
Examples are the "futurist" rules that I supplied, and the list of "destroy humans" rules... and probably others.
IMO these do not really need to be AIML. The templates for these rules can just be fed into OpenCog as sentences, to be matched by the fuzzy matcher.
Actually I suspect it is these rules that are making the OpenCog AIML processing so slow. These rules tend to have lots of stars in their patterns, but the stars are just there to do keyword matching within AIML syntax. I think with some minor tuning, the fuzzy matcher can handle these just fine.... In short I think the AIML rules that are most costly to process are in nearly all (or all) cases actually rules that don't need to be AIML anyway...
-- Ben
On Fri, Jun 10, 2016 at 11:17 PM, Linas Vepštas < notifications@github.com> wrote:
Man Hin, please check with David DeMaris, I believe that not every file in "generic" is used; only some of them are loaded, according to some yaml or json config file somewhere.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225211248 , or mute the thread <
https://github.com/notifications/unsubscribe/AFolXM9xZQSv7TWqmGo9R-Lb5ZwEa6Vgks5qKX_wgaJpZM4ItXsJ
.
Ben Goertzel, PhD http://goertzel.org
"When in the body of a donkey, enjoy the taste of grass." -- Tibetan saying
— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225219473 , or mute the thread <
https://github.com/notifications/unsubscribe/AF3ylxrPHVOGL-UOaDlX7W5F76fLz1o7ks5qKYbGgaJpZM4ItXsJ
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-225244190 , or mute the thread < https://github.com/notifications/unsubscribe/AAFwoKTEILLEbMXzXRZv83ZzxK5zQgXSks5qKZ4zgaJpZM4ItXsJ
.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-226255610, or mute the thread https://github.com/notifications/unsubscribe/AF3yl2VFKJGWNmkOjajzN1SgeIp7gv12ks5qMDMEgaJpZM4ItXsJ .
I don't think its tied into HEAD, yet, at least not in any stable branch; its up to Wenwei and Vytas to figure out when its stable enough and fast enough and usable enough to be used by default in HEAD.
There is an OpenCog chatbot that works with HEAD -- we tried it on the robot yesterday -- but you will need to ask Man Hin how to run it and where it is .. and he just left the office...
On Thu, Jun 16, 2016 at 6:48 PM, Linas Vepštas notifications@github.com wrote:
I don't think its tied into HEAD, yet, at least not in any stable branch; its up to Wenwei and Vytas to figure out when its stable enough and fast enough and usable enough to be used by default in HEAD.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-226451715, or mute the thread https://github.com/notifications/unsubscribe/AFolXJMCBKfvkud6A5hKM48Q2RivmIj5ks5qMSoHgaJpZM4ItXsJ .
Ben Goertzel, PhD http://goertzel.org
Super-benevolent super-intelligence is the thought the Global Brain is currently struggling to form...
The chatbot is here: https://github.com/opencog/opencog/tree/master/opencog/nlp/chatbot-psi
It is not tied into HEAD yet, and depends on what you want to do, I can go through the steps that are required for running it
You have used it with HEAD though, right? isn't that how you got it running on the robot?
On Fri, Jun 17, 2016 at 12:17 AM, leungmanhin notifications@github.com wrote:
The chatbot is here: https://github.com/opencog/opencog/tree/master/opencog/nlp/chatbot-psi
It is not tied into HEAD yet, and depends on what you want to do, I can go through the steps that are required for running it
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-226536188, or mute the thread https://github.com/notifications/unsubscribe/AFolXO0WKjYieIR25mVsL9Zz792N-8Ttks5qMXcogaJpZM4ItXsJ .
Ben Goertzel, PhD http://goertzel.org
Super-benevolent super-intelligence is the thought the Global Brain is currently struggling to form...
Yes I have used it with HEAD and got it running on the robot, doing so requires disabling the current chatbot in HEAD, enabling the corresponding ros publisher/subscriber, starting relex-server, loading rules and content into atomspace etc. All these could/should be automated once we decide to use it by default on the robot
On Thu, Jun 9, 2016 at 11:13 PM, Linas Vepštas notifications@github.com wrote:
Regarding the use of stars -- we now certainly have the capability to restrict the star matching -- for example: accept a * match only if * is one of this explicit set of words, or * is a happy word or * is the name of a thing or * is a verb that is a synonym for "take a flying leap" -- the ability is now there, the hard part is inventing some way to make it easy for such things to be authored by the non-programmer.
Very promising progress!
Ean Schuessler, Brainfood Co-Founder ean@brainfood.com 214-720-0700
By 'enabling the corresponding ros pub/suber' it sounds like one is written and it would be started by the dev.sh script or some launch file. But I don't see it in the chatbot source dir, so maybe it's not checked in yet? I don't mind doing the steps by hand but don't want to rewrite anything that exists and works.
On Thu, Jun 16, 2016 at 11:37 AM, leungmanhin notifications@github.com wrote:
Yes I have used it with HEAD and got it running on the robot, doing so requires disabling the current chatbot in HEAD, enabling the corresponding ros publisher/subscriber, starting relex-server, loading rules and content into atomspace etc. All these could/should be automated once we decide to use it by default on the robot
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hansonrobotics/HEAD/issues/24#issuecomment-226541635, or mute the thread https://github.com/notifications/unsubscribe/AF3yl34XNfJWrM-Swn2s3yCCLeH7_Ae4ks5qMXvcgaJpZM4ItXsJ .
The pub/suber are in the ros-behavior-scripting repo, if you want to run it with HEAD, changes like these would be needed, for now:
Looks like we need to install link grammar as well otherwise some of the opencog nlp modules won't be installed correctly.
Download the latest stable version from http://www.abisource.com/downloads/link-grammar/ and follow the instructions in README will do, probably we should add this to hrtool