Interface com o Kernel Cognitivo.

Visao Geral

O kernel cognitivo e o modulo que, em presenca da descricao
dos desejos e crencas do agente, delibera e determina suas 
intencoes. Nas crencas, incluem-se o conhecimento previo do
agente (modelado pelo projetista) e tudo aquilo que o agente
adquire durante sua atividade (incluindo-se dados que ele
percebe, acoes que ele excuta, ...).

No caso particular do MCOE, o modulo com os agentes reativos
e a simulacao do ambiente servem tanto como sensores que 
passam informacao ao modulo cognitivo, bem como atuadores
que recebem planos de acao do kernel e as executam (fazendo
o feedback das acoes que foram executadas de volta para o kernel).


Comunicacao via socket

- a comunicacao com o kernel e feita via sockets tipo
"stream" (canais bi-direcionais por onde fluem strings
de caracteres).

- o kernel nunca inicia a comunicacao. Ele fica sempre
ouvindo a porta a espera que alguem estabeleca a ligacao.
Para tanto, o aplicacao que usara o kernel deve criar
um socket e iniciar uma conexao. O endereco do kernel
(IP ou dominio mais porta) e configuravel. No caso do MCOE,
o kernel e o ambiente devem residir (em principio) no 
mesmo servidor. A porta sendo escutada, por default, e
a 6999.

- os dados enviados de e para o kernel seguem a sintaxe
do prolog. Assim, seram enviados termos (simbolos predicativos
aplicados a seus argumentos) em uma lista.
    Ex.: [cur_time(100), happens(ev1,ac)]
 Assim, o kernel recebe listas com predicados que serao colo-
cados em suas crencas (fazendo a revisao e mantendo a
consistencia) e envia listas de acoes a serem executadas.
Convem re-lembrar que a cada acao executada, o kernel deve
ser avisado (mais sobre isto adiante).

- No caso do MCOE, o ambiente deve enivar as seguintes
informacoes:


   .sense(predicado_informacao) - toda informacao a ser passada
para o kernel (e que sera acrescentada as suas crencas) deve ser
um argumento do predicado sense. Por exemplo

         [sense(ecometro(70))]
        informa que o ambiente sensorou uma mudanca no ecometro
        para 70 (nao sei se e assim que funciona o ecometro,
        foi so para dar um exemplo :-)) )

    Em particular, a seguinte informacao e reservada do kernel
e deve ser fornecida pelo ambiente:

            . cur_time(Tempo) - o tempo corrente. No MCOE, assume-se
         que cada interacao com o usuario determina um instante de tempo.
         O tempo pode ser um numero comecando em 1, e que e incrementado;

   . happens(Evento,Tempo)
     act(Evento,Acao)
         - a cada acao executada, o ambiente
deve fornecer este   par   para o kernel. Tempo e o tempo em que
a acao ocorreu; Evento e um descritor de ocorrencia de cada acao:
todo acao executada da origem a um evento atomico instantaneo
em um determinado tempo (este descritor deve ser criado pelo
ambiente e e livre, deve apenas comecar com letra minuscula -
sugiro algo simples, como e1, e2, e3 ...); Acao e o nome da
acao executada (no caso do MCOE, deveser uma unica acao - enviar
mensagem - e isto, Lucia?? - o termo que descreve a acao a
deve ser como esta descrito nas crencas do agente - Lucia,
aqui tu dizes como e!!!)

   Ex.: [happens(e1,1),act(e1,envia_msg(tutor, aluno1, "XXX"))]
   
         o par happens/act, neste contexto, pode ser lido assim:
"o evento e1 aconteceu no tempo 1 e sua acao foi envia_..."


- No MCOE, o kernel envia as seguintes informacoes:

    . happens(evento, tempo)
      act(evento, acao)
      uma lista de pares happens/act, que formam uma sequencia
 de acoes a serem executadas (um plano). Ha, ainda, na sequencia,
 algo do tipo t1<t2, t2<t3 ... onde t1, t2, t3 ...
 sao descritores de tempo que o ambiente deve instanciar res-
 peitando a ordenacao. No caso do MCOE, no entanto, os planos sao
 (se nao todos, na maioria) unitarios (uma unica acao), logo 
 esta questao da ordenacao nao deve ocorrer.

   No caso geral, ainda, ao receber um novo plano, o anterior
deve ser descartado. Novamente, como os planos no MCOE sao uni-
tarios, isto nao deve ocorrer.

