From OpenCog

Jump to: navigation, search

In preparation for GSOC 2012 and other similar-size projects, many items on the Ideas page should migrate to this talk page, leaving the Ideas page reserved for well-described high-priority project ideas.

Also, these proto-ideas may be discussed and/or developed further

  • define minimal and full APIs for AtomTable, CogServer, PLN and MOSES
  • Add a Wikipedia:DBus interface, for minimal APIs, e.g. this enables more loosely-coupled MindAgents to be written in any langauge with a a D-Bus API).

MOSES/Combo Ideas

These seem half-baked:

Improve the reduct engine to be property based instead of operator based

Generalize reduct so that it exploits properties instead of specific operators.

For instance, x+0->x, and x*1->x could be 2 instances of the same reduction rule which would exploit the knowledge that 0 is the neutral element of + and 1 the neutral element of *.

This will have 2 positive effects

  1. The reduct engine will be simpler
  2. When adding a new operator, we only needs to specify its properties (or add new rules if it has new properties) instead of adding rules for that particular operator.

This will be very important for operators that are created on the fly as in PLEASURE. In this case we probably need another component to infer (perhaps using PLN) the properties of a given function but that would be for another project.

But, realistically, how likely is it that this will ever pay off? First, I doubt that the reduct engine will get simpler. Second, I doubt that we'll ever add operators that will fit this pattern. Before doing this, we need many more *practical* examples. Linas 14:15, 16 March 2012 (CDT)
Actually, this is a great idea, but it is poorly explained: the examples above are too trivial, and we need a more general (more model-theoretic) explanation to this all. i.e. something invoking "equational theories" or "modulo theories" to explain this kind of generic reduction. Well, better, deeper examples at any rate... Linas 09:25, 25 May 2012 (CDT)

OpenCog Ideas

I'm removing the following entry:

XMPP support for CogServer
Add XMPP support to CogServer for CogServer-to-CogServer and CogServer-to-Person commmunications.
  • support GraphML for exchanging Atoms

Seems to be overtaken by the ZeroMQ idea and the webserver/REST api thing, right? Linas 09:22, 25 May 2012 (CDT)

XMPP is about presence and authentication more so than communication. E.g. XMPP could be used to establish public-key-auth'd communication between two cogservers so they can then go on to communicate via ZeroMQ or some other method. Also, XMPP is a natural choice for any chat session between a user and a CogServer. dhart 22:10, 25 May 2012 (CDT)