Marcus Endicott - May 31, 2012:

...  At least by the time you reach the limits of AIML…

Marcus - the only limits are within the programmer not the language.

Uchiha, don’t let it get to you. There’s an old saying that goes, “A journey of a thousand miles begins with a single step”. It may look a bit daunting now, but if you break up your main goal into lots of little goals, and if you celebrate those little goals as if they were the big one, you’ll soon find that that big goal isn’t so tough after all, and before you know it, your big goal will be complete, too. Hang in there, mate! we’re pulling for you!

@Steve: Yup! I agree!

> http://www.youtube.com/watch?v=g35o62nlOEM

Event Driven Business Architecture

> http://www.youtube.com/watch?v=F7vLKXkMQow

What is Enterprise Messaging?

= = =

Here are two videos that explain relatively simply Event-driven Architecture and Message-oriented Middleware.  What I got out of the message-oriented middleware is that it is not GUI middleware, as I tend to think of middleware, but rather “message-oriented”; in other words, the middleware actually consists of messaging rather than GUI.  One might even say that message-oriented middleware is more like command-line middleware.

I might add that one of the beauties of the modular API model is that APIs can all be written in different languages, but the API functionality is in effect language-agnostic, which then can be more easily integrated with middleware, IDEs or frameworks.

Marcus Endicott - May 31, 2012:

What I got out of the message-oriented middleware is that it is not GUI middleware, as I tend to think of middleware, but rather “message-oriented”; in other words, the middleware actually consists of messaging rather than GUI.  One might even say that message-oriented middleware is more like command-line middleware.

There is middleware for just about anything

We choose Qt as the GUI framework, again because it integrates nicely with Python, and because it’s the foundation of the KDE desktop environment that runs on our Linux-based desktops.

There is also database middleware, like object-relational mappers (Hybernate comes to mind). One of the reasons we choose the PyTables database is that it negates the need for a database middleware layer. This again helps on the ‘simplicity’ part of the project.

Marcus Endicott - May 31, 2012:

I might add that one of the beauties of the modular API model is that APIs can all be written in different languages, but the API functionality is in effect language-agnostic, which then can be more easily integrated with middleware, IDEs or frameworks.

Messaging middleware is in effect also a sort of API; when you choose a messaging protocol that is fairly widely used, this means that there are messaging clients for many other development systems and languages. Using a messaging system for internal communication in the system means that anything can be developed outside of the project, that can interface to the AI system through messaging.

Uchiha - Mar 10, 2012:

Looks like we need modules.

Purpose processing - multiple sub modules - long term and short term purpose
Task list - long term and short term
Computer Language - prolog, c++, etc integration.
Visual - general tracking - advanced hardware and programming required
Audio - Will be very hard
Text>Direct
Language processing - audio, visual and direct text
Logic Processing - further sub modules
Prediction
Knowledge & Information database - further Sub modules
Creativity Processing.

Any other modules we need?

I’m working along these lines. I have a multi-agent system with a controller (subbot.org/controller/) and agents. The controller submits input (asynchronously) to each agent and selects the highest-scoring response. Scores are assigned by the agents, and can be modified by the user at runtime.

The agent-assigned score represents the agent’s confidence in its response; the user can modify those scores while interacting with the bot.

“Long-term purpose” is tricky with my system. For example, i have a Wolfram Alpha agent (subbot.org/waagent) that can take a while to respond (due to network latency, speed of the wolfram site, complexity of the question, etc.). I want the bot to respond immediately with another agent’s response, then when the Wolfram Alpha agent finishes processing, return its response. (The “long-term purpose” is, that the bot remembers a question across subsequent interactions, and answers the question when it can.) In practice I find that I get a lot of extra responses that I want to hide, so I want to improve the ability of the user to customize and filter the bot’s output.

“Task list”: i have a TODO agent (subbot.org/todoagent).

“Computer Language”:  the agents are standalone command-line programs, so they can be in any language. I have agents in C, java, python, ruby, php, perl; the StudentAgent (subbot.org/studentagent) is in Logo (but I don’t use that one anymore).

Logic processing - i have a logic agent (subbot.org/logicagent) that does simple aristotelian syllogisms using natural language input. I’ve also experimented with if-then statements, modus ponens, unification…

My vision is for everyone to write standalone programs that can handle specific domains. The agents could then easily attach to a controller that submits input to them and collects their responses (asynchronously). Then the user can use feedback to select the agents they like most.

If someone writes a general intelligence algorithm that can handle all domains, that agent could supercede all the others and become the only necessary one.

> http://www.meta-guide.com/home/open-chatbot-standards

Robert, have you seen my recent videos on “Open Chatbot Standards for a Modular Chatbot Framework”, above?  I’m trying to encourage everyone to build web APIs, as commercial, meterable “modules” in the form of programmatic interfaces to conventional web services.

Apparently, Karsten Fluegge of Pannous.com, creator of the Jeannie Android app, has also created something like generic API access for agents related to his Voice Actions app.  I believe Richard Wallace has written something about it on his new “Answer Devices Blog”, below and including documentation, below2.

> http://www.answerdevices.com/index.php?/blog/1/entry-1-pannous-launches-web-service-to-aid-mobile-assistants/

> https://docs.google.com/document/d/1dVG_B5Sc2x-fi1pN6iJJjfF1bJY6KEFzUqjOb8NsntI/edit

Hans said, “One of the reasons we choose the PyTables database is that it
negates the need for a database middleware layer.”

The following questions are general, for the sake of conversation
about Python and a database tier for A.I. projects:

Why negate the need for a database middleware layer?

May not a database middleware layer do some heavy lifting for Python?

Thank you, Hans.

8PLA • NET - Jun 30, 2012:

Hans said, “One of the reasons we choose the PyTables database is that it
negates the need for a database middleware layer.”

The following questions are general, for the sake of conversation
about Python and a database tier for A.I. projects:

Why negate the need for a database middleware layer?

May not a database middleware layer do some heavy lifting for Python?

Thank you, Hans.

Database middleware is mostly used for two reasons; the most obvious one is where the database is written in another language, or running on another platform. In this case the middleware takes the form of a library for the target language that maps statements to translated calls to the database. In most cases this is somewhat of a kludge, adding new functions (in this case in Python) to be able to use the external database.

The second use for middleware is where the data-representation in the language differs from that in the database. The most common case is linking an object oriented language to a relational database; we call this the object-relational mapper.

Now back to my choice: using PyTables in Python eliminates both problems. The database uses existing Python data-structures to manage the database. There is no translation between data-representations and there are no ‘outside’ functions needed to use the database. There are of course additional statements (functions) to get data to and from the database, but the code does not use any SQL. It’s all pure Python.

This of course is simplifying things considerably in prototyping and concept testing situations.