Aula 12 - LIDA

Introdução ao LIDA

Cognitive Computing Research Group (CCRG): the CCRG’s research revolves around the design and implementation of cognitive, sometimes "conscious", software agents, their computational applications, and their use in cognitive modeling.

Apresentação

Nesta aula apresentamos aspectos gerais sobre o LIDA (Learning Intelligent Distribution Agent) como  modelo de cognição e como framework computacional. Dentre os textos e apresentações disponíveis no sítio do Cognitive Computing Research Group (CCRG) sugerimos duas leituras: A foundational architecture for AGI e LIDA: A computational model of GWT and developmental learning, para maiores detalhes sobre a arquitetura LIDA recomendamos o Full Tutorial.

OBS.: para ampliar as figuras contidas nesta apresentação basta ativar o botão direito do mouse sobre a figura e escolher a opção "Exibir imagem". 

Atividade 1: iniciamos nossa apresentação tratando do modelo de ciclo cognitivo no LIDA (vide tutorial do LIDA [ aqui ]).

Atividade 2: tratamos de alguns aspectos do framework (o código em Java pode ser obtido aqui) baseado no Tutorial V 1.0. e no texto (baseado no texto "The LIDA Framework as a General Tool for AGI" - disponível [ aqui ]).

Atividade 3: os tópicos e questões sobre os módulos operados pela arquitetura LIDA estão descritas na última seção [ aqui ] e pontuadas nas atividades anteriores: 

• tópico: a arquitetura baseada em codelets - descrito [ aqui e aqui].
• tópico: Perceptual Associative Memory - PAM - descrito [ aqui ]
• tópico: Behavior Network - descrito [ aqui ]
• tópico: Global Workspace Theory - GWT - descrito [ aqui ].

Para orientar esta atividade adotamos algumas questões referentes ao LIDA como proposta de modelo da cognição humana e como framework computacional de uma arquitetura cognitiva:

• questão: como é o sistema de percepção do ambiente no LIDA? - comentário [ aqui ]
• questão: como a percepção é implementada no framework? - comentário [ aqui ]
• questão: como é o sistema de memórias no LIDA? - comentário [ aqui ]
• questão: como as memórias são implementadas no framework? - comentário [ aqui ]
• questões: como ocorre a seleção das ações que irão atuar no ambiente? como são executadas? - comentários [ aqui ]

Conceitos Básicos sobre o Global Workspace Theory

A Teoria do Espaço de Trabalho Global (ou Global Workspace Theory - GWT) nasce das idéias sobre arquiteturas cognitivas introduzidas por Alan Newell e Herbert A. Simon (duas leituras de interesse: uma de Niels Taatgen e outra de Pat Langley). A resolução de problemas em sistemas com diferentes fontes de conhecimentos de forma cooperativa usando o espaço de trabalho global foi primeiramente proposto pelo grupo liderado por Newell (e seus colaboradores). Em seu estudo, Bernard J. Baars propõe uma conexão empírica (vide esquema na Figura 1) do espaço de trabalho global com a (uma) noção de consciência (Ref.:  aqui  - um texto mais curto aqui)  - de fato, alguns termos (palavras) tem uso (interpretação) específico no discurso do LIDA (veja o glossário).  

Assim como as outras propostas de arquiteturas cognitivas anteriormente vistas (Soar e CLARION), a GWT pode ser visto como um teatro interativo da performance mental (Ref.: In the theater of consciousness). Nessa metáfora do teatro interativo destacam-se o palco, um holofote que orienta a atenção do público, os atores que competem pelo foco de luz (do holofote), um público e um conjunto de auxiliares (atuam nos bastidores, porém influenciam diretamente a orientação do holofote) que cuidam do cenário, do figurino, etc. A consciência, nessa metáfora, se assemelha ao foco de luz no palco da memória de trabalho,  somente o que ocorre sob a luz do holofote é consciente. Na Figura 2, o quadro da direita mostra os elementos que interagem com o foco de luz, o quadro da esquerda mostra a integração do conteúdo consciente com expertise distribuído no cérebro (processadores especializados). 

Os vários eventos que ocorrem no palco (fora do foco de luz, parte inconsciente) juntamente com a atuação dos auxiliares influenciam o que está sob a luz da consciência. Há atividades na plateia, nos bastidores e na parte não iluminada do palco. Os espectadores também podem atuar, em particular, quando alguns e identificam com a atuação em destaque (sob a luz do holofote) podem subir no palco e realizar sua própria performance sob a luz do holofote (ou na parte escura do palco).

Em sua teoria, Baars, postula que processos cognitivos (cognition: como atenção, seleção de ação, condicionamento do comportamento (orientar o "fluxo de comportamento" - behavior stream), aprendizagem, etc) e meta-cognitivos (metacognitive process) são sustentados por um grande número de grupos de neurônios (processadores) especializados distribuídos globalmente no cérebro. Os processadores especializados podem formar coalizões (coalitions) para cooperarem entre si. A cooperação se dá por meio de trocas de recursos (informações) para a execução de tarefas. Os locais onde ocorrem as trocas (leitura e escrita das informações) são áreas específicas da memória de trabalho. Em uma coalizão, os processadores só têm acesso a informações locais. Essa limitação, da troca de informações locais, é superada por um sistema de comunicação global entre todos os processadores. O espaço de trabalho global é o lugar onde os processadores podem realizar o broadcast de seus requisitos a todos os outros processadores.

No GWT, somente uma única coalizão pode escrever no espaço de trabalho global em um determinado instante de tempo. Para decidir qual coalizão terá acesso ao espaço global de trabalho, é disparado um processo de competição entre processadores. A coalizão com o maior nível de ativação (média dos níveis de ativação de seus participantes) ganha acesso ao espaço de trabalho global (a cada instante de tempo). Cada processador possui um nível de ativação que expressa, por exemplo, a urgência em obter uma determinada informação. Com o acesso, os processadores da coalizão podem fazer o broadcast de suas requisições. Fora do foco de atenção os processadores atuam como parte de processos inconscientes, com acesso somente a informações locais. Somente em processos conscientes (sob o foco do spotlight) os porocessos podem efetuar o broadcast a todos os outros processadores. Na GWT, a consciência está relacionada com o funcionamento do espaço de trabalho global, como um mecanismo de integração e mobilização.

Inspirado no GWT, Stan Franklin propõe um framework computacional que implementa a teoria de Baars em uma arquitetura cognitiva: o LIDA. A implementação da "consciência" possui três componentes: um gerente de coalizão, um controlador do holofote (spotlight) e um gerente de broadcast; que podem variar conforme os tipos de codelets de atenção. Um codelet de atenção é um sinalizador para a "consciência": o codelet aguarda a ocorrência de situações específicas para requisitar o envolvimento de "consciência". Quando ocorre tal situação, o codelet de atenção aumenta o seu nível de ativação e procura formar uma coalizão com outros codelets que carregam informações detalhadas sobre a situação em questão. O gerente de coalizão é responsável pela formação e acompanhamento das coalizões, que são constituídas por um número limitado de codelets ativas e são iniciadas a partir de associação mútua. O controlador do holofote captura a coalizão mais relevante com base no nível de ativação das coalizões. O conteúdo da coalizão sob o holofote ("consciência") é transmitido pelo gerente de broadcast para todos os codelets.

Nas seções seguintes expomos os elementos básicos da estrutura (e a respectiva dinâmica) do modelo de cognição LIDA e do framework computacional LIDA.

Atividade 1: O Ciclo Cognitivo no LIDA

A construção de modelos de agentes autônomos (autonomous agent, artificiais ou não) que atuam em ambientes dinâmicos, em geral, toma como base diferentes tipos de ciclos: internos ao agente, do ambiente e presentes na interação agente-ambiente. O ciclo cognitivo (cognitive cycle) refere à relação iterativa que identifica a interação do agente com o ambiente. Ciclos cognitivos usualmente começam na percepção e terminam numa ação (interna ou externa ao agente). Nesta seção descrevemos o ciclo cognitivo em nove passos. A Figura 3 abaixo mostra os elementos envolvidos no ciclo cognitivo, a enumeração (destaque em laranja, lado esquerdo do rótulos que acompanham as setas) indica o passo a que pertence o processo.

Como mostra a figura acima, os passos de um a três envolvem percepção, memória associativa de longo prazo, memória episódica e a memória de trabalho. As estapas de quatro a nove correspondem à interação da "consciência" e os módulos de seleção de ação.

1. Percepção (perception): a percepção é o processo em que o agente extrai sentido (significado) das coisas no mundo (ambiente) - de atribuir significação aos dados de entrada. No LIDA, o aparato perceptual é constituído por sensores e codelets de percepção (especializados em identificar certas características, as que interessam ao agente) que alimentam uma rede Slipnet (como na arquitetura Copycat). Numa Slipnet, os nós armazenam conceitos perceptuais (formado por um núcleo e um conjunto de características que podem ser pré-estabelecidos - built-in) e as ligações (arestas) ponderam os conceitos (relacionam conceitos  e suas inter-relações pertinentes ao domínio do problema). Os dados de entrada (externos ou internos) são os estímulos sensoriais, captados e interpretados pelo aparato perceptual, que geram a base da "significação" (meaning). A partir das entradas captadas, os sensores e codelets de percepção ativam nós da Slipnet desencadeando um processo que culmina na formação de um (ou mais) percepto(s) - o significado associado aos estímulos sensoriais (em um único ciclo).
   • Codelets têm origem na arquitetura Copycat (Hofstadter e Mitchell, 1995), refere-se a um pequeno programa de computador com finalidade bem específica, em geral é executado em thread separada. Há vários tipos de codelets: de atenção, de comportamento, de informação, de expectativa, de intenção, etc. Na GWT, um codelet implementa um processador. As coalizões (coalitions) que ocorrem no lida sempre se referem a coalizões de processadores.
2. Percepto (percept):  o significado associado aos estímulos sensoriais (percepto) é armazenado no bufffer de pré-consciência do workspace (memória de trabalho). São armazenados juntamente com o percepto, a cada ciclo cognitivo que ocorre na memória de trabalho, dados, estruturas relacionais e componentes afetivas (feelings/emotions) associados ao significado da informação captada - cada buffer (são vários) está associado a um tipo de informação, por exemplo, visuo-espacial  ou fonológico. 
3. Associações locais (local associations): associações locais são automaticamente recuperadas da memórias episódica transiente (transient episodic memory) e declarativa (declarative memory) e armazenadas na memória de trabalho de longo prazo (long-term working memory).  As associações tomam como base os perceptos e o conteúdo da memória de trabalho (incluindo o conteúdo emocional).
4. Competição pela consciência: A memória de trabalho de longo prazo (long-term working memory) é um buffer de memória que contém percepções e associações locais para a competição de atenção. A partir da memória de trabalho de longo prazo, codelets de atenção (attention codelets) trazem eventos (presente, passado, sentimentos/emoções) novos (relevantes, urgentes) para a consciência. Esses eventos modificam as chances de uma dada coalizão chegar à consciência. 
5. Transmissão da consciência (conscious broadcast). A transmissão do conteúdo consciente (conscious content) é feita pela coalizão de codelets (coalition of codelets), normalmente formado por um codelet de atenção e codelets de informação (information codelets) com seus respectivos conteúdos, que ganha acesso ao espaço de trabalho global. Em humanos, a hipótese é a de que essa transmissão corresponda à consciência fenomenal (refere-se a experiência propriamente dita, a experiência que ocorre quando se está ciente). A transmissão consciente contém todo o conteúdo de consciência, incluindo componente afetivas (sentimentos/emoções). Essa experiência consciente (transmissão) afeta diferentes memórias: os conteúdos das memórias associativa perceptual (vide esquema na Figura 3) e episódica transiente são atualizados de acordo com a consciência (incluindo aspectos afetivos (sentimentos/emoções) e relações associadas aos aprendizados perceptual (perceptual learning) e episódico (episodic learning). A memória processual (procedural memory) é atualizada com reforço sob influência afetiva (attentional learning). A consolidação de uma experiência ocorre com o armazenamento do conteúdo da memória episódica transiente na memória declarativa de longo prazo (declarative memory).
6. Resposta à solicitação de recursos (recruitment of resources): no LIDA, a consciência está diretamente relacionada à resolução do problema de relevância na solicitação de recursos (efeito do broadcast), isto é, fornecer ao sistema acesso aos seus recursos internos que são mais relevantes para a situação atual. Codelets (behavior codelets) cujas variáveis estão associadas às informações do broadcast respondem à transmissão da consciência. Por exemplo, se o codelet de atenção vencedor for um codelet de expectativa indicando para um resultado não esperado de uma ação anterior, os codelets que respondem são aqueles que auxiliam a sair dessa situação (um tanto inesperada).
7. Configurando a hierarquia de contextos de metas (setting goal context hierarchy): é nesta etapa, juntamente com o conteúdo da consciência (contents of consciousness), que os sentimentos/emoções (feelings/emotions) atuam mais diretamente na instanciação e ativação dos contextos de metas. Se a cadeia de comportamentos corrente não for apropriada, então codelets de comportamento ativos instanciam uma cadeia de comportamentos que o seja. Havendo um codelet de comportamento executável e uma cadeia de comportamentos instanciada, ocorrem associações de variáveis e envio de ativações a outros comportamentos. Caso contrário, uma rotina de solução de problemas é evocada utilizando mecanismos adicionais. 
8. Seleção da ação: a cadeia de comportamentos seleciona um único comportamento e o executa. Cada seleção de comportamento inclui a geração de um codelet de expectativa (expectation codelet) (veja  o passo seguinte). 
9. Realização da ação:  a execução de um comportamento (goal context) resulta na realização das atividade especializadas pelos codelets de comportamento (behavior codelets) associados ao comportamento escolhido. Os codelets de comportamento ativos possuem um codelet de expectativa que monitora as ações realizadas: trazem à consciência ocorrência de desvios dos resultados esperados. 

A seguir percorremos esses nove passos do ciclo cognitivo em quatro momentos: percepção, recuperação de elementos da memória (memory retrieval), do broadcast consciente (conscious broadcast) e da ação.

• Percepção:

A Figura 4 mostra o esquema da percepção que, no LIDA, é o processo de atribuir significado aos dados sensoriais captados. Todos os dados sensoriais captados pelo agente, de alguma forma, são significativos para ele.

Nesse processo o agente reconhece objetos individuais; classifica-os; identifica as relações existentes entre objetos, situações e eventos de modo que possa atribuir sentido ao cenário capturado. O cenário não se restringe ao visual, estão inclusas cenas auditivas, olfativas, etc. A Figura 6, mostra uma das vias neuronais associada que, por exemplo, em relação à percepção visual a via ventral é responsável pela percepção de objetos e suas características. A percepção de localizações dos objetos e pela ação frente a eles está associado à via dorsal (vide Figura 3). A Figura 5 mostra um esquema das vias de processamento visual ventral e dorsal no cérebro humano. 

No LIDA, a percepção de baixo nível (bottom up - extraído diretamente da sensação) inclui a detecção de características (cores, texturas, formas, movimento, etc.) carregadas na memória perceptual associativa. A percepção de alto nível (top down - significados anteriormente estabelecidos contribuem para estabelecer significações posteriores) resulta da recuperação de informação das memórias associativa perceptual e sensorial  e da construção de estruturas pelos codelets que atuam no workspace - vide esquema na Figura 6. 

No contexto do LIDA, esse processo de atribuir significação auxilia o agente a decidir o que fazer a seguir, na seleção de ação (com isso é possível obrter uma forma de mensurar o significado).   

• Memory retrieval

No LIDA, o sistema de memória resulta da integração de várias memórias: sensorial-motora (vide Figura 3) perceptual associativa, procedural, episódica e declarativa (entre outras: a Figura 7 mostra um esquema de interação das memórias). A memória episódica pode ser transiente, que dura apenas algumas horas (ou um dia); de longo prazo, que tem potencial para armazenar informações por tempo indeterminado; declarativa de longo prazo, que inclui a memória autobiográfica, de eventos e a semântica - vide esquema parcial na Figura 8. Ou seja, a memória episódica mantém os acontecimentos ocorridos: o quê, onde e quando; podendo incluir aspectos semânticos, localização temporal, emocional e causal do evento

Os conteúdos do workspace podem ser utilizados como pistas (cues) para localizar informações entre os conteúdos-endereçáveis (content-addressable memory) que são devolvidas na forma de associações locais no workspace. Por exemplo, a imagem de um rosto (foto da face) no workspace pode ser usado como pista para obter associações locais que  podem incluir, por exemplo, o nome da pessoa ou de um evento (uma imagem de alguém conversando com a pessoa da foto num restaurante). 

A Figura 9 mostra a relação entre os papéis das memórias procedural (processual) e episódica. A memória procedural mantém um repertório de ações e procedimentos.

As ações da memória procedural podem ser executadas isoladamente (em paralelo, em série ou como combinação das duas) ou estar associada a um contexto em que uma dada ação seja útil. Note-se que a memória procedural está relacionada ao O QUE fazer a seguir, enquanto a memória sensorial-motora com o COMO fazer este algo. Logo, esses dois tipos de memória exigem diferentes mecanismos.

• Conscious broadcast

Na difusão consciente (conscious broadcast), codelets de atenção competem para levar informações para a consciência. O vencedor pode transmitir sua informação amplamente por todo aparato cognitivo. Um dos objetivos da divulgação é o de recrutar recursos apropriados para lidar com a situação corrente (uma vez que o conteúdo da consciência compreende uma representação compacta da situação corrente). A difusão consciente é destinada principalmente para a memória procedural, vide esquema na Figura 10, o objetivo é encontrar elementos adequados que possam auxiliar na escolha da póxima ação.

Outro papel da difusão consciente está relacionado com aprendizagem. No modelo de cognição LIDA, o aprendizado só ocorre após a informação ter passado pela consciência. A Figura 11 mostra o esquemas das formas de aprendizado no LIDA. 

Aprendizagem perceptual	Aprendizagem episódica
Aprendizagem atencional	Aprendizagem procedural
Figura 11. Formas de aprendizagem no LIDA

São quatro as formas de aprendizado: perceptual, episódicao, atencional e o procedural. A aprendizagem perceptual está relacionada ao reconhecimento de novos objetos, novas categorizações e novos relacionamentos. A difusão consciente inicia e atualiza o processo de aprender a reconhecer e categorizar, ambos recorrendo à memória perceptual. À medida que novos objetos, categorias, relações entre objetos, relações entre relações e outros elementos pertinentes à ontologia do agente são aprendidas, nós (objetos e categorias) e relações (links) são adicionados à memória perceptual associativa, mas não antes da difusão consciente (vide Figura 10).  O aprendizado episódico é armazenado na memória episódica na forma de eventos. Esse tipo de aprendizado, no LIDA, ocorre a medida em que eventos do conteúdo da consciência vão sendo armazenados na memória episódica transitória onde permanecerão até serem apagados. O conteúdo não apagado pode ser consolidado na memória declarativa. O aprendizado atencional trata dos novos codelets de atenção e do reforço aos codelets de atenção existentes. O reforço é feito sempre que o codelet participa de uma coalizão que ganha a consciência. Está em estudo o processo de como apreender novos codelets de atenção. O aprendizado procedural reforça os esquemas de ações já existentes e cria novos. 

• Ação

A Figura 12 mostra o esquema em que aparecem a atenção e a seleção de ação substituindo o bloco cinza "rest of cognition box" (vide Figura 9). Como já mencionamos, as informações construídas pela percepção e/ou armazenadas na memória episódica dão à atenção (attention) os recursos para a memória procedural auxiliar no processo de escolha da ação.

A execução de uma ação afeta o ambiente (externo ao agente,  interno ao agente ou ambos) completando um ciclo cognitivo e disparando um novo.  A Figura 13 mostra o esquema da ação no LIDA.

O LIDA funciona como um sistema de controle (mente) do agente autônomo, em processo contínuo (dentro do ciclo cognitivo) para produzir a próxima ação (constantemente selecionando uma ação). Nesse caso, a criação de automatismos (conjuntos de ações pré-estabelecidas para a obtenção de um resultado) poderia reduzir os broadcasts (são seriais e possuem capacidade limitada de processamento) diminuindo o tempo de um ciclo. Esses automatismos aumentam a sobreposição dos ciclos cognitivos, incrementando o paralelismo e evitando o uso da consciência no desempenho de atividades condicionadas (isto é, automatizadas).

Na seção seguinte tratamos da estrutura do framework na qual está inserido o ciclo cognitivo apresentado nesta seção.

Estrutura do Framework LIDA

Esta seção é um excerto do Tutorial V1.0 do LIDA. Assim como na seção anterior, recomendamos a leitura rápida do Glossário de termos do Tutorial V1.0.  Em relação à implementação do framework LIDA (em Java), há uma descrição detalhada de todas as classes em Javadoc.

Expomos nesta seção alguns elementos básicos necessários na implementação de agentes autônomos cuja baseados no modelo de cognição LIDA.  Iniciamos com uma descrição geral do modelo LIDA (parcialmente apresentado nas seções anteriores: sobre o GWT e sobre o ciclo cognitivo) e do framework LIDA. A seguir, damos uma descrição mais pormenorizada do framework (baseado no texto "The LIDA Framework as a General Tool for AGI" - disponível [ aqui ]). Prosseguimos apresentando alguns módulos, processos e estruturas contidas no framework. Finalmente, damos uma breve descrição de como a arquitetura de um agente é especificado em XML (vide XML Tutorial).

Introdução

A arquitetura cognitiva LIDA é parte simbólica (uso de regras, como no Soar) e parte conexionista (uso de redes neurais, como no CLARION). A parte símbólica carrega influências das idéias de Allen Newell (symbol manipulation was the essence of both human and machine intelligence) e a parte conexionista das idéias de Rodney Brooks (symbols are not always necessary since: the world is its own best model. It is always exactly up to date. It always has every detail there is to be known. The trick is to sense it appropriately and often enough - ref. aqui). Essas duas perspectivas de construção de modelos para a cognição humana são intergradas pela teoria que sustenta o LIDA: o GWT.

A GWT, como vimos anteriormente, postula que a cognição humana é implementada por uma variedade de pequenos processadores de propósito específico, quase sempre fazendo parte de processos inconscientes. São processadores relativamente simples (a comunicação entre eles não é usual) que podem estabelecer coalizões para a realização de uma tarefa específica. A GWT sugere a existência de um espaço de trabalho global que permite a interação desses processadores. Uma coalizão que ganha acesso ao espaço de trabalho global pode distribuir (espalhar) um recurso (uma informação, uma mensagem) para todos os processadores inconscientes. Esse processo permite a convocação de novos processadores para se juntarem na interpretação de uma situação nova ou na resolução do problema corrente. O papel da consciência (que ocorre nesse broadcast - vide setas amarelas na Figura 3) é a de permitir que o cérebro lide com situações novas ou problemáticas que não podiam ser tratadas de forma eficiente por meio dos processos inconscientes usuais. Essa difusão consciente visa compensar o fato de ter que mobilizar muitos recursos inconscientes para tratar de situações novas de forma não-rotineira. Com isso, a GWT sugere uma resposta para a limitada capacidade cognitiva associada à experiência consciente, à memória imediata e aos objetivos imediatos. Veremos nesta seção como essa dinâmica ocorre no LIDA: como modelo de cognição humana e como framework computacional. 

LIDA como Modelo e como Framework

Acreditamos que o uso, digamos, consistente (coeso e coerente) do framework LIDA exige um conhecimento dos aspectos  básico do LIDA como modelo de cognição (análogo à observação feita na Aula 4, vide [ aqui ]). O LIDA como modelo é uma abstração conceitual do que seja uma "mente humana", uma abstração estruturada como projeto arquitetônico computacional para agentes autônomos. O LIDA como framework é uma implementação parcial do modelo LIDA na forma de software utilizando a linguagem de programação Java. Evidentemente, o framework é apenas uma (mas não única) forma de implementação do modelo LIDA proposto, assim como o modelo LIDA é apenas uma (mas não única) forma de modelar a cognição humana baseado nos conceitos do GWT. Desse modo, é natural que um conceito (como retratado pela GWT) possa ter significados distintos no contexto do modelo e do framework.

• O modelo LIDA

A Figura 3 mostra o diagrama do modelo LIDA para a cognição humana.  O LIDA adota a GWT como sustentação para propor um modelo que ampare uma série de teorias em psicologia e neuropsicologia. No modelo LIDA, o ciclo cognitivo é a base da cognição. Qualquer sistema que seja instância do modo LIDA é capaz de, durante cada ciclo cognitivo, perceber o mundo (externo e interno ao agente), dar significado as coisas e manter um nível de representação dos eventos (passado e presente). Essa capacidade cognitiva decorre de um mecanismo que dota o sistema de "consciência". Como já mencionamos, o mecanismo associado à "consciência" atua desde a escolha apropriada de ações a executar até nas múltiplas forma de aprendizado (que ficam mantidas nas diferentes memórias). 

• O framework LIDA

O framework computacional LIDA deriva do modelo cognitivo LIDA. O modelo LIDA fornece uma arquitetura cognitiva implementável computacionalmente como base para a confecção de agentes autônomos capazes de perceber o ambiente em que estão situados, escolher uma resposta apropriada (ação) para a situação corrente, memorizar eventos, aprender. Enfim, agentes dotados de cognição. 

A produção de agentes cognitivos pode exigir programas extremamente complexos em sua implementação, dificultando a inclusão de atualizações e sua respectiva manutenção. O uso bem sucedido de frameworks na produção de software em larga escala sugere que a mesma estratégia pode ser aplicada na implementação computacional do modelo cognitivo LIDA. Um framework é um esqueleto da arquitetura sugerida pelo modelo LIDA contendo suas funcionalidades genéricas. Em geral, frameworks apresentam como características básica: a flexibilidade e o reuso de código, o que permite o desenvolvimento de aplicações customizadas com redução significativa do processo de produção.

As características do framework LIDA incluem implementações dos módulos e classes abstratas das partes genéricas da arquitetura de um agente cognitivo.

• OBS 1.: como dissemos, muitos termos são usados como jargão no framework LIDA - veja o Glossário. Por exemplo, o termo módulo é usado para indicar algo semelhante a um módulo no modelo cognitivo LIDA (veja:  Módulos e Processos do modelo LIDA). Um módulo no framework LIDA contém informações de vários tipos, estruturas de dados, processos e estratégias (algoritmos) que manipulam essas informações. Todos os módulos implementam uma interface genérica (API), porém cada uma possui sua própria API que define suas funcionalidades.
• OBS 2.: Abaixo colocamos alguns termos utilizados no framework (preferimos deixar o texto no original) como exemplo da necessidade de leitura do Glossário de termos.
  • Activation: activation can represent different things, but, generally, it represents the salience or usefulness of an element. Nodes, links, and other elements such as coalitions, codelets, and behaviors, have activation.
  • Link: a connection between a source Node and a sink, which may be either a Node or a simple Link. A Link has a LinkCategory, which is the Link’s conceptual meaning.
  • Listener: modules need to communicate with other modules. To implement this, we use the observer design pattern. In this pattern a "listener" module registers itself with another "producer" module. Each time the producer has something to send, it transmits the information to all of its registered listeners.
  • Module: similar to a module in the LIDA Cognitive Model, we generically define a module in the Framework. Modules contain information of various kinds, and include processes and algorithms with which to manipulate, modify, and move that information. All modules implement a generic module interface (API) but each one also has its own API that defines its particular functionality.
  • Node: a Node is a major unit of representation in the framework, which can represent a feature, object, category, event, etc.
  • Task: tasks are encapsulations of small, specialized, routines (algorithms), which typically run repeatedly at a specified rate. Tasks consist of an algorithm, an execution frequency, a time of next execution, and a status. Modules or even other tasks can create tasks to perform the small operations needed to achieve their specific functionalities. Tasks may run once or repeatedly. If they run repeatedly the period is based on their execution frequency.
  • TaskManager: the TaskManager. controls the scheduling and execution of all tasks in the framework. It maintains the Framework’s internal clock measured in ticks. Tasks are scheduled for execution in accordance with this clock.
  • Tick: each position in the task queue represents a discrete instant in the application’s time. These positions are termed "ticks". All tasks scheduled for a particular tick are executed concurrently and the TaskManager does not advance to the next tick until all tasks scheduled for the current tick finish.

Listamos alguns elementos que compõem o framework  que serão detalhados ao longo do texto: 

• módulo (module): uma coleção coerente de representações (dados) e processos que operam estes dados.
• task: um algoritmo que pode ser executado repetidamente implementando um pequeno processo.
• estruturas de dados: implementam representações internas (common internal representations).
• gerenciadores de tarefas (task manager): são algoritmos dedicados  à execução de tarefas multi-threaded.
• GUI (configurable GUI): mostra o estado interno dos processos e dados do sistema. 
• factory: usada para criar estruturas de dados e estratégias que encapsulam algoritmos.
• parser XML: usado para carregar e criar um agente a partir de um arquivo XML.

• A relação entre o modelo e o framework

Para cada componente do modelo cognitivo LIDA há um módulo no framework LIDA, isto é, cada caixa (box) do ciclo cognitivo (vide diagrama na Figura 3) tem seu módulo equivalente implementado no framework.

A idéia do framework é facilitar a implementação de agentes autônomos baseados no modelo cognitivo LIDA. Cada unidade de código no framework é encapsulado de modo que outras unidades de código possam ser acopladas. O acoplamento depende das funcionalidades de cada unidade de código e da composição funcional que se deseja obter (definido pela especificação do agente autônomo inicialmente projetado). Desse modo, o que se deseja é esse conjunto de unidades de códigos (o framework) permita a implementação dos elementos que formam o ciclo cognitivo no modelo LIDA (diagrama da Figura 3). 

As unidades de código (implementações de módulos e processos do modelo LIDA) do framework têm caráter genérico, cabendo ao usuário-desenvolvedor especificar e implementar o domínio do experimento cognitivo (cuja base é o modelo LIDA). A seguir pontuamos os pontos de ligação entre o framework e o modelo LIDA. Esse módulos e processos são apresentados mais adiante, [ aqui ].

• A idéia genérica de módulo no modelo LIDA é especificado na interface  FrameworkModule do framework LIDA.
• Módulos específicos no modelo LIDA são traduzidos em interfaces epecíficas no famework LIDA, por exemplo, o módulo referente à memória procedural é especificada na interface ProceduralMemory. (veja também o pacote lida.proceduralmemory).
• Os processos no modelo são implementados por diferentes tasks, no framework são implementados como processos na interface  FrameworkTask.
• O tempo no modelo LIDA é tratado no framework por um mecanismo que mede o tempo em unidades de tick.
• A execução assíncrona no modelo é implementado no framework na versão concorrente, o gerenciamento da concorrrência está em TaskManager.
• A comunicação entre módulos no modelo é feita por meio de listeners (observer design pattern) no framework estão implementados na interface ModuleListener.
• Os nós e arestas (links) no modelo estão implementados no framework em NodeStructures (que consiste de nós e aretas)
• A ativação dos nós, arestas e outros elementos (inclui estratégias que controlam o decaimento e a excitação desses elementos) do modelo LIDA estão implementados no framework na interface Activatible.

A seguir tratamos dos módulos e listeners; dos tasks e taskmanagers; dos nós, arestas e nodestructures; das ativações e estratégias.   

Conceitos Básicos do Framework LIDA

As principais componentes do framework LIDA são os módulos (modules) e os gerenciadores de tarefas (task managers). Os módulos forma uma estrutura interconectada (seguindo o esquema do ciclo cognitivo apresentado na Figura 3) e os gerenciadores de tarefas controlam a execução de todos os processos (implementados no formato demon-like, são os LIDA-tasks que podem ser executadas em threads separadas) que ocorrem no framework (tasks são executadas via TaskSpawners que trabalham com TaskManager). Uma das funções do gerenciador de tarefas é tornar a execução dos LIDA-tasks transparente para o usuário. O núcleo da principal estrutura de dados está no NodeStructure. Por fim, o framework LIDA fornece ferramentas para o usuário-desenvolvedor implementar o modelo cognitivo LIDA aos seus experimentos.

Módulos e Listeners

• Módulos

A idéia do framework LIDA é a de fornecer um conjunto de módulos, independente do domínio, para implementações concretas de experimentos que utilizam o modelo LIDA. De fato, alguns módulos são independentes do domínio, por exemplo, o workspace; enquanto outros são altamente dependentes do domínio, como, o sensorymemory e o  sensorymotormemory. Módulos podem conter submódulos, por exemplo, o Workspace contém o submódulo CurrentSituationalModel (cada submódulo é, de fato, um módulo).  Os módulos, no framework LIDA, são especificados genericamente na interface FrameworkModule. Implementações podem ser encontradas na classe abstrata FrameworkModuleImpl. O FrameworkModuleImpl define um método padrão para adição de listeners e serve de base para implementações de interfaces apropriadas. Por exemplo, uma implementação da memória sensorial  irá extender a FrameworkModuleImpl e implementar a interface SensoryMemory. A estrutura básica para módulos que estendem implementações permite a herança de um nome, de submódulos (se for o caso) e de um  TaskSpawner para auxiliar na execução das tasks. Veja na Tabela 1 um mapeamento dos módulos e tasks do framework (que serão apresentados mais adiante) e suas respectivas classes abstratas.

• Listeners

A conexão entre módulos é mantida pelo fluxo constante de informações entre eles. As setas do diagrama na Figura 3 mostram os canais de comunicação. No framework LIDA, essa estrutura de comunicação entre módulos é feita usando Observer Pattern. Para isso, muitos módulos fornecem uma interface para listeners que especifica os métodos necessários para receber conteúdo da comunicação entre módulos. Um módulo que desejar receber comunicações enviadas por algum módulo deve implementar todos os métodos da interface listener e e registrar-se para o módulo de envio. Os métodos dessa interface permitem ao módulo-fonte enviar informações para todos os seus ouvintes registrados sem que seja preciso o conhecimento de detalhes específicos dos módulos que estão na escuta.

A relação entre o módulo GlobalWorkspace e a interface BroadcastListener é um exemplo de uso do Observer Pattern. O modelo exige que a maioria dos módulos receba a transmissão consciente (conscious broadcast) do GlobalWorkspace. Desse modo, esses módulos devem implementar a interface BroadcastListener. Cada módulo receptor (consumer) deve registrar-se como o GlobalWorkspace usando o método addBroadcastListener. Quando o GlobalWorkspace precisar enviar um broadcast, ele chama o método receiveBroadcast (em  BroadcastListener) para cada listener registrado.

De fato, como mostra o diagrama na Figura 3, um módulo pode se relacionar com vários módulos e não necessariamente via listener; também podem estabelecer relações usando o método addAssociatedModule (em FrameworkModule). Um exemplo de relação que exige mais que simples uso do mecanismo de listener é o que ocorre entre o módulo AttentionCodeletModule e os módulos Workspace e GlobalWorkspace. O módulo AttentionCodeletModule precisa ter acesso direto (via codelets) aos módulos Workspace e GlobalWorkspace para poder verificar e recuperar o conteúdo do Workspace e adicionar coalizões diretamente no GlobalWorkspace (isso é possível unicamente neste módulo).

Tasks e TaskManagers

• Tasks

Os processos do modelo LIDA são implementados no framework LIDA usando o  FrameworkTasks (ou simplesmente "tasks" que pode ser imaginado como um codelet).  O coração do mecanismo de simulação, em implementações de agentes cognitivos, é o TaskManager (uma coleção de threads próprias para a execução de tasks). Os módulos não utilizam o TaskManager diretamente, porém cada módulo do framework está associado a um TaskSpawner que atua em conjunto com o TaskManager (um assistente do TaskManager que cuida do status da task e determina o que fazer com a task ao final de cada execução). 

O TaskManager controla o tempo, em ticks, das aplicações internas. O tick corrente é um número inteiro que começa no zero e é incrementado conforme a execução do agente durante a simulação. Todas as tasks são postas numa grade (agenda) e executadas num determinado tick. Cada task tem um algoritmo no método runThisFrameworkTask, um tick para o qual está agendado e um status. Uma task pode ser executada uma única vez ou repetidamente, por exemplo, para passar a ativação para um nó (Node), um ExciteTask (em ExciteStrategy) é executado uma única vez. Por outro lado, podemos implementar um detector de features como uma task que deverá ser executado a todo instante  (tick). A freqüência de execução de uma task é determinada por um atributo seu: ticksPerRun (veja uso RandomizingTaskSpawner).

• TaskManager

O TaskManager é o responsável pela execução das tasks e controle do relógio interno (regula os ticks). A escala de execução das tasks é colocada numa fila (queue) chamada task queue: a ordenação é pelo tick e cada posição da fila contém as tasks a serem executadas naquele tick. O loop principal do TaskManager obedece a seguinte seqüência: (1) todos os módulos têm suas ativações decrescidas; (2) executar todas as tasks agendadas para o tick corrente e aguardar as respectivas finalização; (3) possivelmente, atualizar a GUI; (4) incrementar o tick  corrente. O TaskManager tem métodos públicos para inicialização, parada e retomada de execução desta seqüência. O botão "Start/Pause" na barra de taferas do Framework GUI utiliza esses métodos para controlar a execução da simulação, também há formas de ajustar a duração do tick.

A execução de qualquer task sempre consome exatamente um tick no relógio do framework. Dependendo do pool de threads do TaskManager várias tarefas podem ser executadas simultaneamente, porém em um único tick. Como algumas tasks podem consumir mais tempo (em tempo real) de execução do que outras, os ticks não têm uma medida uniforme em unidades de tempo real. No arquivo de especificação primária do agente a propriedade lida.agentdata pode ser carregada com as características da simulação (vide exemplo no trecho de código abaixo):

              
# ------------------------------------------------------------
Exemplo A: de arquivo de configuração primária: lidaConfig.properties

## Propriedades do agente
lida.agentdata=configs/foolAgent.xml
lida.elementfactory.data=configs/factoryData.xml

... 

              
# ------------------------------------------------------------
Exemplo B: de arquivo de configuração secundária: foolAgent.xml


<?xml version="1.0" encoding="UTF-8"?> 

...  

<taskmanager>
    <param name="taskManager.tickDuration" type="int">1 </param> 
    <param name="taskManager.maxNumberOfThreads" type="int">100</param>  
</taskmanager>

... 

   

Nós, Arestas (links) e NodeStructures

O diagrama da Figura 3, pode ser resumido em uma estrutura relacional onde cada caixa é um nó (Node) e cada seta é uma aresta (Link). De fato, nós e arestas são as principais estruturas de dados no framework LIDA. No framework LIDA, um nó (Node) pode representar features, objetos, eventos, conceitos, feelings, ações, etc. Todo nó está ligado a um nó chamado PamNode (um nó na PAM). Desse modo, nós são instanciações de  PamNodes, isto é, todo nó (Node) numa simulação tem uma referência a um nó na PAM (bem como uma identificação única: uma id).

Uma aresta (Link) conecta um Node a outro Node (chamado de aresta simples - simple link) ou a outro Link (chamado de aresta complexa - complex link). Links têm um atributo LinkCategory que especifica a natureza da relação representada pela aresta, por exemplo, podemos representar "bola vermelha" usando um nó para "bola", outro para "vermelha" e uma aresta ligando o dois nós com atributo LinkCategory "feature". Nodes e Links implementam a intereface Linkable, com  ExtendedId que identifica unicamente qualquer elemento Linkable.

Uma NodeStructure é uma estrutura graph-like que funciona como "estrutura corrente" para troca de informações entre a maioria dos módulos. A  implementação NodeStructureImpl fornece os métodos para adicionar, remover ou recuperar, e gerenciar os Nodes e Links que compõem a estrutura em questão. Quando um Node ou Link é adicionado a uma NodeStructure, de fato, é adicionado (e devolvido) uma cópia do elemento (e não o original). Essa estratégia visa evitar situações problemáticas, já que o mesmo objeto Java existe em múltiplos NodeStructures. Se os objetos são distintos, o novo Node possui (pelo menos no início) os mesmos atributos do nó original, inclusive o id. Isso permite que novos elementos tenham parâmetros e/ou funcionalidades distintas do elemento original. Por exemplo, quando um Node na PAM é adicionado no buffer perceptual do workspace, o novo Node terá sua própria relevância (activation) e mecanismos distintos para controle de sua excitação (veja: ExcitationTask e  ExciteStrategy) e decaimento (veja: DecayStrategy).

Ativação e Estratégias

Um Node, Link, coalizão, codelet, esquema (scheme) ou comportamento (behavior) possui uma relevância (activation), tem sua utilidade. A ativação é representada como um número real entre 0.0 e 1.0, inclusive. Os elementos mencionados têm ativação corrente, que mede a relevância naquele momento. Outros elementos possuem uma ativação adicional chamada base-level activation, que é usada para implementar aprendizado. O framework LIDA fornece as interfaces Activatible e Learnable para a implementação de elementos com essas funcionalidades.

• Um elemento Activatible possui métodos excite e decay que regulam sua ativação (se a ativação do elemento fica abaixo de um certo limite ele é removido). Para configurar os níveis de excitação e decaimento de um elemento basta recorrer a algumas das estratégias em  ElementFactory: linear excitation, sigmoid excitation, linear decay and sigmoid decay (veja também a classe ActivatibleImpl).
• Um elemento Learnable é uma extensão de Activatible (é um elemento que possui base-level activation para implementar aprendizagem). Um exemplo de elemento Learnable é um PamNode, onde o base-level activation corresponde à utilidade que conceito representado pelo PamNode proporcionou. OBS.: O framework LIDA v1.2 Beta não contém algoritmos de aprendizagem implementados.

Framework Tools

Neste tópico apresentamos brevemente dois recursos do framework LIDA: o ElementFactory e o Graphical User Interface (GUI).

• A criação de instâncias de muitos elementos no framework LIDA (nós, arestas, estratégias) pode ser feita a partir do ElementFactory (que é uma utility: uma classe na qual todos os valores e atributos pertencem à classe, mas não às suas instâncias). A ElementFactory segue o padrão de projeto singleton (garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto) e factory (método que permite definir uma interface para criação de um objeto e delegar a instanciação para as subclasses). Isso possibilita a adição de novos tipos de elementos usando diferentes classes, como, os tipos nó (Node), aresta (Link), tasks (que incluem detetores (feature detectors), codelets de atenção, etc), e estratégias (que incluem excite, decay, etc). Por exemplo, o tipo  Node pode definir que todos usem a classe NodeImpl, porém com estratégias distintas para excite, decay e ativações iniciais. O tipo do elemento produzido por ElementFactory pode ser configurado usando um arquivo XML: factoryData.xml (vide exemplo nos trechos de código acima: Exemplo A e B). Definições de tipo incluem o nome (que é utilizado para requisitar uma nova instância (do mesmo tipo) em  ElementFactory), classe e valores de parâmetros que definem cada tipo de elemento.
• The Graphical User Interface (GUI): O framework LIDA fornece uma GUI customizável. A GUI fornece um display em tempo real (real-time display) do conteúdo dos módulos, valores dos parâmetros, algoritmos em execução, e de outras variáveis que sejam de intersse durante a execução de uma simulação.  A aparência e as propriedades do painel da GUI pode ser configurada a partir da classe lida.framework.gui.

Inicialização do Framework

O pacote de inicialização do framework LIDA, initialization, contém as classes envolvidas na configuração para a execução da simulação. A classe AgentStarter fornece os métodos para a execução da simulação. O método start (em AgentStarter) executa os seguintes passos: (1) carrega as definições dos tipos de elementos encontrados no arquivo de configuração secundária (factoryData.xml) especificado em lida.elementfactory.data, no arquivo de configuração primária (o nome usual, como já vimos, é lidaConfig.properties); (2) uma instância da classe  Agent é criada com base no conteúdo do arquivo de especifica o agent. Este arquivo está especificado em lida.agentdata (vide exemplo nos trechos de código acima: Exemplo A e B), propriedade definida no arquivo de configuração primária; (3) se a propriedade lida.gui.enable, no arquivo de configuração primária, está definido como true, uma GUI é criada com base nas informações fixadas no arquivo de configuração (especificado em lida.gui.panel e lida.gui.commands); (4) carrega as propriedades do arquivo de configuração primária; (5) carrega o agente; (6) carrega e exibe a GUI.

Arquivo de especificação do agente (The Agent Declaration File)

O nome do arquivo é declarado em lida.agentdata no arquivo de configuração primária (conhecido como arquivo de declaração do agente - vide exemplo nos trechos de código acima: Exemplo A e B).  É um arquivo XML contendo a root tag, <lida>, e tags (no primeiro nível) como (o arquivo LidaXMLSchema.xsd contém as especificações das tags):

• <globalparams> — opcional, contém parâmetros a serem usados na inicialização;
• <taskmanager> — contém parâmetros para configurar o TaskManager;
• <taskspawners> — contém subtags <taskspawner> que declaram tipos TaskSpawner nos módulos do agente
• <submodules> — contém subtags <module> que especificam as classes e parâmetros para criar os módulos que compõem o agente. A subtag <module> pode conter tags do tipo: <associatedmodule>, <initialtasks>, <initializerclass> ou  <submodules> (permite a declaração de módulos aninhados)
• <listeners> — contém subtags <listener> que declaram os listener  entre os módulos que compõem o agente.

AgentXMLFactory

A classe AgentXMLFactory carrega o arquivo de declaração do agente, executa o parser, cria as componentes declaradas no arquivo e faz a montagem do objeto Agent. O método getAgent executa a seguinte seqüência de passos: (1) Adiciona os parâmetros globais na classe GlobalInitializer; (2) cria o  TaskManager; (3) cria os TaskSpawners; (4) cria os módulos - o método init é chamado à cada módulo criado; (5) as conexões em ModuleListener são estabelecidas; (6) os módulos sao associados (se for o caso: é necessário especificar na declaração do módulo); (7) re-inicialização de cada módulo usando a classe esepecificada (se for o caso: é necessário ter especificado uma classe de inicialização); (8) é criada uma task inicial para cada módulo que contém a especificação dessa task em sua declaração. É é feito o escalonamento dos  TaskSpawner para a respectiva execução.

The Factory Data Definition File

O arquivo especificado em lida.elementfactory.data contém as definições de Strategy, Node , Link e tipos de task a serem adicionadas em ElementFactory (conhecido como factory data definition file). ElementFactory contém tipos padrões não especificados, como, "NodeImpl", "PamNodeImpl", "noDecayPamNode", "LinkImpl", "PamLinkImpl", "noDecayPamLink", "defaultDecay", "defaultExcite", "noDecay" e "noExcite". O arquivo XML com root tag, <LidaFactories>, contém as seguintes tags (em seu primeiro nível).

• <strategies> — contém subtags  <strategy> que definem os tipos Strategy a serem carregadas em ElementFactory
• <nodes> — contém subtags <node>  que definem o tipos do Node  a serem carregadas em ElementFactory
• <links> — contém subtags <link> que definem o tipos do Link a serem carregadas em ElementFactory
• <tasks> — contém subtags <task> que definem os tipos da task a serem carregadas em ElementFactory

Interface inicializável (The Initializable Interface)

Diversos elementos do framework LIDA implementam a interface Initializable, por exemplo, Node, Link e Strategy; isso é um modo uniforme de inicializar elementos com parâmetros. Para modificar a inicialização de um elemento basta substituir (via override) o método init, o método getParam permite capturar os parâmetros definidos nos arquivos de configuração. A interface FullyInitializable estende a interface Initializable e permite a associação dos módulos usando o método setAssociatedModule. Os módulos FrameworkModule e FrameworkTask são exemplos de elementos FullyInitializable.

Implementações de módulos do LIDA (Framework v.1.2 Beta)

O framework atual conta com os seguinte módulos:

• Environment

Contém as classes que ajudam o usuário a definir uma interface para a produção do ambiente em que o agente irá habitar (o mundo onde o agente irá atuar). A Figura 14 mostra um exemplo de ambiente onde um agente LIDA poderia atuar. 

• Sensory Memory

Contém as classes relacionadas ao módulo que define a memória sensorial no modelo LIDA. A Figura 15 mostra o diagrama da memória sensorial no modelo LIDA: 

No esquema do modelo LIDA, a memória sensórial  armazena os estímulos sensoriais captados. Os estímulos podem ter origem externa (gerados pelo meio ambiente) ou interna (gerados por própriocepção). A memória sensorial também possui detectores de características que iniciam o processo de significação dos estímulos capturados. A memória sensorial fornece informação para a memória associativa perceptual (Perceptual Associative Memory - PAM) que está no caminho para a consciência. Numa escala de tempo muito curta a memória sensorial também se instrui múltiplas vezes a cada execução do automatismo sensório-motor (que opera sem a interferência da consciência). 

• Perceptual Associative Memory

Contém classes relacionadas à definição do módulo da memória perceptual associativa (PAM) e sua respectiva implementação. A Figura 16 mostra o diagrama da memória associativa perceptual no modelo LIDA.

No modelo cognitivo LIDA, a memória associativa perceptual equivale à percepção baseada em conhecimento. Computacionalmente a PAM assume a forma de uma rede semântica ativada pela Slipnet. Nós da Slipnet fazem o papel de detectores de características, de objetos individuais, de categorias, de situações, etc. A PAM atua como um filtro, deixa passar apenas as informações relevantes da memória sensorial. As informações relevantes contém a percepção corrente e são repassadas para a memória de trabalho (o workspace). Esse processo todo é pré-consciente.

Na Figura 16, a seta azul mostra que a seleção de uma ação dispara um processo de percepção (influenciada por experiências recentes - priming) de como interpretar um evento ou situação (esperando os eventos ou situações mais propensos de acordo com a ação selecionada (preafference). Os resultados esperados dessa ação são preparadas na PAM (as ativações correntes são aumentados, isso faz com que os nós mais prováveis estejam no próximo percepto.

• OBS1.: O termo aferente é aplicado às vias sensitivas que levam os estímulos detectados pelas terminações nervosas e receptores periféricos até as áreas específicas do cérebro, onde são decodificadas, modificadas, integrados, e produzem uma resposta.
• OBS 2.: O termo "preafference" tem a seguinte definição: The preafference precedes feedback by proprioception and interoception loops from the sensory receptors in the muscles and joints to the spinal column, cerebellum, thalamus, and somatosensory cortex. The corollary discharges convey information about what is to be sought by looking, listening, and sniffing, and the returning afferent discharges convey the current state of the search. When an expected stimulus is present, we experience it. When not, we imagine it. (Ref. página 108  [ aqui ]).
   
• Episodic Memory  (Transient e Declarative)

Contém as classes relacionadas ao módulo que define a memória episódica no modelo LIDA. A Figura 17 mostra o diagrama da memória episódica no modelo LIDA. 

Como já mencionado anteriormente, a memória episódica (dividida em trasiente e declarativa) trata de eventos: o quê, onde e quando. A memória transiente é implementada computationalmente no modelo LIDA como uma memória de conteúdo-endereçável, tecnicamente conhecida como memória esparsa distribuída (ou memória esparsamente distribuída). A memória declarativa, ver diagrama na Figura 18, refere-se à memória episódica de longo prazo.

O conteúdo da memória episódica transiente é consolidado na memória declarativa. A memória declarativa está dividida em autobiográfica (eventos autobiográficos: p.ex., última festa de aniversário) e semântica (de fatos: p.ex., "Paris é a capital da França" - a recordação de um fato não necessariamente está ligado a um "quando" e a um "onde"). 

• Workspace    

O workspace implementa o buffer de pré-consciência da memória de trabalho. A Figura 19 mostra o diagrama com o workspace e o global workspace no modelo LIDA.

Num dado moemento, o workspace irá conter o percepto corrente, os perceptos anteriores não removidos (o decaimento não atingiu o limite mínimo) e as estruturas corrente sendo construídas (pelas structure-building codelets) para o entendimento dos conceitos de alto-nível (relações, situações, idéias, etc). OBS.: é um dos tópicos de pesquisa o "como construir tais estruturas". O workspace também deverá conter as associações locais da memória transiente e da memória declarativa.

• Structure-Building Codelets: A estrutura interna do workspace é composta por vários buffers de entrada e três módulos: o Current Situational Model, o Scratchpad e o Conscious Contents Queue (Ref.:  [ aqui ]). O Current Situational Model é o local de armazenamento das estruturas que representam os eventos currentes interno e externo. Os structure-building codelets são responsávei pela criação dessas estruturas usando elementos de vários sub-módulos do workspace. O Scratchpad é uma área auxiliar (localizada no workspace) onde os  structure-building codelets podem construir previamente possíveis estruturas para depois movê-los para o Current Situational Model. O Conscious Contents Queue mantém o conteúdo dos últimos broadcasts e permite o "entendimento" e manipulação de conceitos. (Ref.:  [ aqui ]).

• Attention Codelets

Os codelets de atenção são uma classe especial de codelets, são os codelets que trazem informação para a consciência. Cada codelet de atenção tem seu próprio conjunto de preferências das informações que deseja trazer à consciência. A Figura 20 mostra o diagrama com o módulo de codelets de atenção no modelo LIDA.

• Procedural Memory

A memória procedural é o local de armazenagem dos procedimentos. A Figura 21  mostra o diagrama com a memória procedural no modelo LIDA.

No modelo LIDA os procedimentos (rotinas) são mantidos na forma de esquema (schema). Cada esquema consiste de um contexto, uma ação e um resultado. Com alguma confiabilidade, o resultado de uma dada ação num dado contexto já está previsto. 

• Action Selection

Contém as classes relacionadas a seleção de ação, um sub-sistema que determina os comportamentos do agente cognitivo LIDA. A Figura 22  mostra o diagrama do módulo de seleção de ação (behavior net) no modelo LIDA.

Este mecanismo escolhe a ação apropriada (num dado contexto) em resposta à situação corrente (de acordo com o conteúdo da consciência). A seleção é feita a partir da instanciação de vários esquemas (que não decaíram). A seleção de ação depende fortemente da situação corrente (no ambiente externo) e dos broadcasts recentes. A meta corrente também influencia fortemente a seleção de ação. Uma única ação é escolhida a cada ciclo cognitivo.

• Sensory-Motor Memory

A memória sensorial capta o que resulta dos estímulos, que podem ser gerados pelo meio ambiente ou por processos internos (como a propriocepção).. A Figura 23  mostra o diagrama com a memória sensório-motora no modelo LIDA.

Para finalizar, algumas observações:

• O módulo Environment foi concebido para o usuário that the user provides. The framework provides a basic abstract class, EnvironmentImpl, which should be extended  implementing either an environment for the agent in Java or serving as an interface between a non-Java environment implementation and the agent. Users’ Environment module implementations should, at a minimum, implement the methods getState and processAction, which allow the environment to be sensed and process agent actions respectively.
• O módulo SensoryMemory, apresentado na forma de uma classe abstrata,  as sensory memories typically vary greatly from domain to domain. Thus users should extend from the default implementation, SensoryMemoryImpl, and implement the domain-specific parts. Em versões futuras do framework, o módulo deverá contar com algoritmos de reconhecimento de objetos.
• A implementação da seleção de ação (versão 1.0 beta) não implementa todas as features descritas no modelo LIDA.
• Uma versão melhorada da Behavior Network (vide Maes) está sendo planejada para a próxima versão do framework.
• As memórias episódica transiente e declarativa descritas no modelo LIDA foram implementadas usando uma memória distribuída esparsa (episodicmemory.sdm) - vide textos de Kanerva e Snaider.
• Vários algoritmos especificados no modelo LIDA ainda não foram implementados  (não constam no framework LIDA v1.2 Beta.