Repensar a estrutura da WorkingMemory

[andre-paraense]

• Hoje, a estrutura da WorkingMemory é hard-coded, com um conjunto pré-definido de estruturas do tipo Memory. Isso engessa e amarra o desenvolvimento do MECA. Penso que uma estrutura melhor seria criar um Map<String,Memory> e pré-inserir as Memories que estão hoje lá, mas criar mecanismos para a criação de novas Memory pelo usuário, flexibilizando o MECA e deixando que novas Memories possam ser criadas pelo usuário, de acordo com as necessidades da aplicação.

[rgudwin]

Proposta de Nova Estrutura para a Working Memory

• Criar mecanismo para criação de novas sub-memórias: cada sub-memória terá um nome associado, e um MemoryContainer que armazenará integralmente a sub-memória. Por quê um MemoryContainer ? Para a gente se beneficiar do mecanismo automático de seleção de memória interna
• Uma ideia complementar seria aumentar o número de mecanismos de seleção no MemoryContainer. Hoje, a seleção é sempre feita a partir do MemoryObject interno com maior valor de eval. A ideia seria criar um mecanismo genérico, que permitisse a inclusão de novos mecanismos de seleção.
• O conhecimento armazenado na Working Memory deve ter um formato padronizado. Anteriormente cogitamos que esse formato fosse o OWRL. Nesse momento, penso em criar uma estrutura mais simples, muito provavelmente "imitando" os WMEs do SOAR. Minha ideia é criar duas categorias de conhecimento: LinkNode e ValueNode. O primeiro tipo é um nó que permite a conexão com outros nós, e o segundo é um nó de valor, que poderá "guardar" qualquer tipo primitivo, como por exemplo, double, int, boolean ou String.
• Outra ideia seria criar métodos para criar automaticamente objetos nessse formato interno da Working Memory, a partir de objetos Java, e também o reverso, permitindo a conversão dos objetos WME-like para objetos Java, para permitir um bom interfaceamento entre diferentes Codelets interagindo com a Working Memory.