>> Ben asked: What kind of bot are you using? Do you mean a physical robot
or a chat bot? <<
Just a chat bot for right now Ben.
Although I could imagine a future robot manufacturer licensing the code to
allow a customer to customize
the high level cognitive/personality functions of the bot.
>> Ben aasked:
Would you be willing to share a few example patterns from your database, so
that we can have a better sense of what you're actually talking about?
Right now I have only a very vague idea....
This example pattern could literally take hundred of patterns to represent
in other pattern languages and most bot engines wouldn't be able to handle
misspelling word run together, etc... without creating separate patterns to
account for each possible case which would be highly impractical to do.
My patterns usually are much longer and include quite a bit more complexity
that this simple example. But this simple example should give you flavor
without me giving to much of the mojo away.
Please understand though I am not open sourcing the project. And although I
am not certain which parts of what I am doing that are patentable if any, I
have documented the development and the partial disclosure of it so that I
am in a position to challenge anyone else who might try to
patent/commercialize it before me. I'm not trying to delay the singularity
but if have quite a lot invested in the development and need to make sure
the technology is used wisely.
<< Pattern to match goes here
>> Statements executed after correct pattern is found
{} Required at exactly one inside to match
() Optional match one or zero inside
| seperator for {} or () choices
[] invokes subpattern, subpatterns may invoke other subpatterns
// Comments ok here
# Function names start with this character
Functions must be defined in the VB .Net code the language is implemented
in.
Variables for the knowledge base and may be assigned in the main.nlp main
program
Variables can also be created dynamically from within the program.
Variable states are store to an ASCII file at program exit.
eg. variable used in pattern
[Location]="{[City]|[State]|[Country]|[Continent]|[Province]|[Tourist_Attrac
tion]}"
[City]="{Greensburg|Jeanette|Las Vegas}"
[State]="{Ohio}"
[Country]="{Canada|Mexico}"
[Tourist_Attraction]="{the Grand Canyon}"
Some example user inputs the below pattern will match.
Greensburg is near Jeanette
Ohio is by California
Mexico is close to Canada
Las Vegas is right by the Grand Canyon
<< [Location]{({'|;})s| is} (j{u|i}st
)({extremely|pretty|quite|rather|really|truly} )(very )
{close|[Direction]|in close proximity|near} {by|of|to} [Location]
>> [Temp1]="[#Last([Location],1)]"
[Temp2]="[#Last([Location],2)]"
// Insert call to Google Maps API to get distance between [Temp1] and
[Temp2] returning [Distance]
if([Distance]>"20")
They're not that close, on the map it looks like around [Distance]
miles or so.
#else
They are pretty close on the map it looks like around only [Distance]
miles.
#endif
[There]="[Temp1]"
[#Learn("[Temp1] is [Distance] miles from [Temp2].")]
Fuzziness can be built into the pattern for common keying errors ie. People
often hit ";" instead of '
{;|'} in pattern matches either.
Fuzziness spaces in pattern are matched as ( ) optional spaces allowing for
words bleed together.
Spell Check has a dictionary of words ordered by frequency of use in
nl-text.
Spell check algorithm uses Boyer Moore algorithm to sequentially replace
potentially correct word for
mispelled word in user input. This is only done if no patterns match input.
This code would need to be a little more complicated due to cities of the
same name residing in different states or countries.
I would probably set [CurrentTopic] in an earlier matched pattern to
something like "where user lives" or something.
>> Ben said: The grounding issue is not just about voice versus text ---
it's about grounding of linguistic relationships in physical
relationships...
For instance, Novamente can learn that "near" is approximately transitive
via observing the 3D simulation world to which it's connected; it can then
use inference to generalize this transitivity to other domains that it has
not directly experienced, e.g. to reason that if Rockville is near Bethesda
and Bethesda is near DC then Rockville must be somewhat near DC. I.e. the
system can ground the properties of "near"-ness in its embodied experience.
Without this kind of experiential grounding, a whole bunch of patterns that
humans learn implicitly must somehow be gotten into the AI either by
explicit encoding or by verrrrry subtle mining of relationships from a huge
number of NL texts or verrrrrrry tedious and long-winded chats with
humans... >>
Agreed when my son 3-5 I had a lot of verrrrrrry tedious and long-winded
chats teaching him about the world also. My
bot currently has no capability to generalize. It therefore relies on the
same stereotypical generalizations that humans have already learned to base
it's reasoning. Ie. Gravity makes things fall. If you drop * it will fall.
But it also needs to know that dropping your drawers usually means something
quite different, so idioms must have a higher recognition when operating in
a context where they would make sense. Ie. Normally a dropping your drawers
is idiomatic for removing your pants but if the context is moving furniture
it probably reverts back to the furniture type drawers. I am quite sure my
son did a lot of generalizing. But quite honestly I think he did quite a
bit more explicit encoding.
-----Original Message-----
From: Ben Goertzel [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 07, 2006 9:41 AM
To: agi@v2.listbox.com
Subject: Re: [agi] Logic and Knowledge Representation
Hi,
> My opinion on the most probable route to a true AI Entity is:
>
> 1. Build a better fuzzy pattern representation language with an
> inference mechanism for extracting inducible information from user
> inputs. Fuzziness allows the
> language to understand utterances with misspellings words run
> together etc...
> 2. Build a bot based on said language
> 3. Build a large knowledgebase which captures a large enough
> percentage of real world knowledge to allow the bot learn from natural
> language data sources i.e. the web.
> 4. Build a pattern generator which allows the bot learn the
> information it has read and build new patterns itself to represent the
knowledge.
> 5. Build a reasoning module based on Bayesian logic to allow simple
> reasoning to be conducted.
> 6. Build a conflict resolution module to allow the Bot to
> resolve/correct conflicting information or ask for help with
> clarification to build correct mental model.
> 7. Build a goal and planning module which allow the Bot to operate
> more autonomously to aid in the goals which we give it i.e.. achieve
singularity.
>
> Steps 1 and 2 an took me a couple years.
What kind of bot are you using? Do you mean a physical robot or a chat bot?
> 3 is an ongoing effort. Into my fourth year now with 28000 patterns.
This is interesting. Would you be willing to share a few example patterns
from your database, so that we can have a better sense of what you're
actually talking about? Right now I have only a very vague idea....
> Steps 5, 6 and 7 don't sound that difficult to me right now but that's
> only because I haven't thought about them in enough detail.
IMO, steps 5-7 are by hard the hardest ones, and contain many more hidden
difficulties than your wording reveals!
The Novamente AGI system loosely fits into your framework, though the fit is
not 100% natural as you leave out a bunch of things I think are important
In Novamente we have put a lot of work into 5 and are in the thick of
working on 7, to use your breakdown
We are not doing your step 3, but instead are using a rule-based language
parser and semantic mapper to import basic knowledge into the system from
existing NL texts
> People have challenged the top down approach saying that such a bot
> would lack grounding or the ability to tie it's knowledge to real world
inputs.
>
> But it should not be difficult to use a commercial voice recognition
> engine to transform voice inputs into ASCII inputs. And the fuzzy
> recognizer for be able to compensate many times for the mistakes that
> the voice recognition software makes in recognizing a word or two in
> the input stream.
The grounding issue is not just about voice versus text --- it's about
grounding of linguistic relationships in physical relationships...
For instance, Novamente can learn that "near" is approximately transitive
via observing the 3D simulation world to which it's connected; it can then
use inference to generalize this transitivity to other domains that it has
not directly experienced, e.g. to reason that if Rockville is near Bethesda
and Bethesda is near DC then Rockville must be somewhat near DC. I.e. the
system can ground the properties of "near"-ness in its embodied experience.
Without this kind of experiential grounding, a whole bunch of patterns that
humans learn implicitly must somehow be gotten into the AI either by
explicit encoding or by verrrrry subtle mining of relationships from a huge
number of NL texts or verrrrrrry tedious and long-winded chats with
humans...
-- Ben Goertzel
-------
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/[EMAIL PROTECTED]
-------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/[EMAIL PROTECTED]
