Usando Objetos de Conhecimento para Compartilhar 

Conhecimento na plataforma SemantiCorei

Ana Paula Lemke e Marcelo Blois Ribeiro 

Programa de Pós­Graduação em Ciência da Computação – Faculdade de Informática – Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) – 

Av. Ipiranga, 6681 – 90619­900 – Porto Alegre, RS – Brasil 

{ana.lemke, marcelo.blois}@pucrs.br 

Abstract.  Agent­based  platforms  and  toolkits  have  been  proposed  to  help developers to create agent­based applications, but there is a visible separation between theory and practice. Agent­based applications promise many modern capabilities,  including  proactivity,  social  ability  and  autonomy,  but  the platforms  still  need  to  address  some  challenges,  such  as  representing  the knowledge used by software agents in a structure suitable for it to be reused and  shared. This paper describes  the main  features of  the SemantiCoreK, an agent  infrastructure  to  develop multi­agent  systems  in which  the  agents  can manage their knowledge and perform in a Semantic Web context. 

Resumo. Muitos  kits  de  ferramentas  e  plataformas  já  foram  propostos  para auxiliar  os  desenvolvedores  a  criar  aplicações  baseadas  em  agentes,  mas ainda há uma grande diferença entre a teoria e a prática. Enquanto a teoria cita  aplicações  com  habilidades  avançadas,  como  pró­atividade,  habilidade social  e  autonomia,  as  plataformas  disponíveis  para  o  desenvolvimento  das aplicações ainda apresentam certas limitações, como a ausência de estruturas para representar o conhecimento utilizado pelos agentes, o que permitiria seu reuso  e  compartilhamento.  Neste  sentido,  este  artigo  descreve  as  principais características do framework SemantiCoreK, uma infra­estrutura desenvolvida para  a  criação  de  agentes  capazes  de  gerenciar  seus  conhecimentos  e executar na Web Semântica. 

1. Introdução 

Com a grande quantidade de informação já disponível na Web, surge a necessidade de desenvolver sistemas  inteligentes, capazes de auxiliar no processamento e recuperação de  informações pertinentes, diminuindo assim o esforço dos usuários. Todavia, para o desenvolvimento desses sistemas, é necessário codificar as informações disponíveis na Web de forma que essas possam ser lidas e interpretadas por sistemas computacionais. A  Web  Semântica  é  uma  iniciativa  que  busca  a  definição  de  formatos  padrão  para exprimir informações em uma forma processável pela máquina e, segundo Berners­Lee e co­autores (2001), cria um ambiente onde agentes de software podem realizar tarefas sofisticadas para os usuários. De fato, muitas descrições da Web Semântica citam o uso 

i  Estudo desenvolvido pelo Intelligent Systems Engineering Group da PUCRS, financiado pela Dell Computadores do  Brasil  Ltda.  com  recursos  da  Lei  8.248/91  e  pelo  Conselho  Nacional  de  Desenvolvimento  Científico  e Tecnológico – CNPq. 

V Workshop on Software Engineering for Agent-oriented Systems

59

de  agentes  de  software  como  uma  das  tecnologias  que  possibilita  a  apresentação  de diferentes serviços aos usuários [Kagal et al. 2002]. 

  Na Web Semântica, é através do uso de ontologias que o domínio é representado de  forma  semântica  e  é utilizando essas ontologias  que os agentes conseguem agir de forma cooperativa. Sendo assim, as infra­estruturas para o desenvolvimento de agentes deveriam  apoiar  a  criação  de  agentes  capazes  de  coletar  conteúdo Web  de  diferentes fontes,  processar  as  informações  coletadas  e  compartilhar  os  resultados  com  outros agentes.  Outro  problema  encontrado  na  implantação  de  sistemas  abertos  e  flexíveis usando  a  infra­estrutura Web  é  a  ausência  de  plataformas  que  ofereçam mecanismos para apoiar o gerenciamento do conhecimento dos agentes. Uma maneira promissora de aprimorar  o  comportamento  dos  agentes  é  representar,  de  forma  explícita,  seus conhecimentos, tornando­os acessíveis aos outros agentes do sistema. 

  Organizações  empresariais  já  perceberam  a  necessidade  de  explicitar  e disponibilizar  o  conhecimento  de  seus  colaboradores  há  muito  tempo  ­  para permanecerem  competitivas,  elas  precisam  ser  capazes  de  gerenciar  seus  recursos  de conhecimento de forma eficiente e eficaz [Mathi 2004]. Essas organizações costumam utilizar  preceitos  da  área  de Gestão  de Conhecimento  (GC)  para  auxiliar  nesta  tarefa. Para Macintosh et al. (1998), GC pode ser definida como a identificação e análise dos recursos de conhecimento disponíveis e requeridos e também dos recursos relatados em processos.  Essa  definição  implica  que  é  necessário  para  a  organização  [Stader  e Macintosh  1999]:  (i)  ser  capaz  de  identificar  e  representar  seus  recursos  de conhecimento;  (ii)  compartilhar  e  reusar  esses  recursos  por  diferentes  aplicações  e usuários;  e  (iii)  criar  uma  cultura  que  encoraje  o  compartilhamento  e  reuso  de conhecimento. 

  Mapear  um  processo  de GC  em  uma  arquitetura  de  software  pode  auxiliar  os agentes a compartilhar conhecimento, mas para a realização desse mapeamento devem ser respeitadas as características dos SMAs.  Neste  sentido,  este  artigo  irá  apresentar  o framework  SemantiCoreK,  uma  infra­estrutura  desenvolvida  para  a  criação  de  agentes capazes de auto­gerenciar seus recursos de conhecimento. O  framework SemantiCoreK

é, na verdade, o resultado da integração das funcionalidades do framework Ontowledge [Lemke  et  al.  2007]  na  arquitetura  do  SemantiCore  [Blois  et  al.  2007].  Enquanto  a arquitetura  do  SemantiCore  dispõe  de  primitivas  para  a  criação  de  aplicações organizadas em um conjunto de agentes que realizam suas tarefas no ambiente Web, o Ontowledge agrega habilidades de Gestão de Conhecimento aos agentes.  

  A habilidade de se adaptar para alcançar um determinado objetivo é essencial em domínios  reais  por  várias  razões.  Em  primeiro  lugar,  o  conhecimento  disponível  no agente  pode  ser  insuficiente  para  alcançar  um  objetivo.  Também,  os  recursos necessários para executar um plano de ação podem estar temporariamente indisponíveis. E, por mais que se tente prever as situações que ocorrerão, o ambiente é imprevisível e incerto, o que acaba tornando impossível a tarefa de predizer o futuro. 

  O  restante  deste  artigo  está  organizado  da  seguinte  forma:  na  Seção  2  são apresentados  os  requisitos  que  uma  plataforma  deve  atender  para  possibilitar  o compartilhamento  de  conhecimento  entre  agentes;  na  Seção 3  é descrito o  frameworkSemantiCoreK; na Seção 4 discorre­se sobre trabalhos relacionados e, por fim, na Seção 5 são apresentadas as considerações finais e os trabalhos futuros. 

V Workshop on Software Engineering for Agent-oriented Systems

60

  

2. Requisitos para o compartilhamento de conhecimento 

Agentes  de  software  deveriam  ser  capazes  de  adquirir  novos  conhecimentos,  seja através  da  cooperação  com  outros  agentes  ou  através  da  criação  de  novos conhecimentos,  para  aprender  ou  se  adaptar  a  novas  situações.  Considerando­se  a primeira alternativa, a seguir são apresentados alguns requisitos que as plataformas para desenvolvimento de SMAs deveriam atender para permitir o compartilhamento/troca de conhecimento entre os agentes do sistema. 

Requisito  1. A  plataforma  deve  fornecer  algum  tipo  de  representação  de conhecimento para a representação do conhecimento dos agentes. O conhecimento dos agentes deve ser codificado usando uma linguagem formal, o que possibilita aos agentes interpretar e inferir novos conhecimentos com base no conhecimento existente. 

Requisito 2. A plataforma deve definir um modelo para a criação de “pacotes de  conhecimento�.  Cada  pacote  de  conhecimento  deve  conter  todo  o  conhecimento necessário  para  que  um  agente  possa  executar  ações  de  forma  a  alcançar  um determinado  objetivo.  Alguns  pesquisadores,  como  Ancona  e  Mascardi  (2003), investigam  o  compartilhamento  de  planos  de  ação  entre  os  agentes.  Acredita­se,  no entanto,  que  um  plano  de  ação  representa  apenas  um  fragmento  do  conhecimento necessário para um agente atingir um objetivo. 

Requisito 3. A plataforma deve oferecer meios para os agentes compartilharem pacotes  de  conhecimento  entre  si.  Para  gerenciar  o  conhecimento  dos  agentes, permitindo a recuperação e o uso de conhecimento, os agentes precisam ser capazes de identificar  uma  necessidade  de  conhecimento,  selecionar  o  conhecimento  mais apropriado  de  acordo  com  a  situação  e  o  objetivo  a  ser  atingido,  interpretar  e  usar  o conhecimento recebido de outros agentes, entre outros. 

  No SemantiCoreK,  o  conhecimento  dos  agentes  é  representado com ontologias (requisito  1),  é  definida  a  noção  de  objetos  de  conhecimento  (requisito  2),  e  são definidos  métodos  para  permitir  que  os  agentes  usem  e  compartilhem  objetos  de conhecimento (requisito 3). 

3. O framework SemantiCoreK

O  SemantiCoreK  é  um  framework  desenvolvido  em  Java  que,  entre  outras funcionalidades, permite o desenvolvimento de agentes capazes de localizar, interpretar e  usar  objetos  de  conhecimento.  Um  objeto  de  conhecimento  encapsula  todos  os elementos  requeridos  para  resolver  determinado  problema,  definição  similar  a “knowledge  source�  dada  por  Ferber  em  [Ferber  1999].  Sempre  que  um  agente desenvolvido com o SemantiCoreK não possui o conhecimento necessário para atingir um  objetivo,  um  objeto  de  conhecimento  é  recuperado  e  o  seu  conteúdo  (o conhecimento  encapsulado  no  objeto)  é  automaticamente  adicionado  a  arquitetura  do agente.  A  busca  e  o  compartilhamento  de  conhecimento  não  são  procedimentos apresentados pela maioria das plataformas para desenvolvimento de SMAs disponíveis. 

  Através  da  verificação  da  satisfação  alcançada  com  o  uso  de  um  objeto  de conhecimento,  agentes  SemantiCoreK  também  são  capazes  de  avaliar  seus  próprios desempenhos. Assim,  os  agentes  podem  identificar  quando  o  conhecimento  atual  não 

V Workshop on Software Engineering for Agent-oriented Systems

61

está sendo satisfatório para atingir determinado objetivo e adquirir novos conhecimentos para a substituição do conhecimento obsoleto. 

  O  processo  de Gestão  de Conhecimento  integrado  à  arquitetura  do  framework(sintetizado  a  partir  de  [Kucza  2005,  Lee  e  Lee  2003]),  conta  com  cinco  atividades dispostas em três diferentes fluxos. O Fluxo 1 (criar, organizar e armazenar) possibilita que os agentes criem novos objetos de conhecimento. O Fluxo 2 (distribuir) permite que diferentes  agentes  compartilhem  objetos  de  conhecimento  de  acordo  com  um  dado objetivo. Por último, o Fluxo 3 (capturar, aplicar e armazenar) permite que um agente sinalize  uma  necessidade  de  conhecimento,  aplique  e  armazene  o  conhecimento mais similar  recebido. Os  fluxos  1  e  3  terminam  com  a  execução  da  atividade armazenar,pois  ambos  envolvem  a  aquisição  de  novos  conhecimentos.  No  Fluxo  3,  não  é necessária  a  organização  do  conhecimento  recebido,  visto  que  o  conhecimento compartilhado já deve estar encapsulado em um objeto de conhecimento. 

  A  realização  das  atividades  do  processo  de  GC  é  garantida  por  diferentes mecanismos  presentes  na  arquitetura.  Por  exemplo,  para  a  distribuição  de  objetos  de conhecimento,  foi  desenvolvido  o mecanismo  de  compartilhamento  de  conhecimento. Os mecanismos  desenvolvidos  são  controlados  por  diferentes  componentes  do  agente SemantiCoreK, como descrito na próxima seção. 

3.1. Visão geral dos componentes de um agente SemantiCoreK

Basicamente, agentes SemantiCoreK são formados por cinco componentes: o Sensorial, o Decisório, o Executor, o Efetuador e o Organizador (que surgiu a partir da integração do framework Ontowledge no SemantiCore).  O componente Sensorial é responsável por sentir o ambiente ­ através de seus sensores são capturados diversos tipos de objetos do ambiente.  O  componente  Decisório  gerencia  as  regras  e  fatos  que  formam  o modelo mental de um agente SemantiCoreK. Embora o mecanismo decisório seja um ponto de flexibilidade do  framework, o SemantiCoreK possui uma integração nativa com o Jena [Jena  2009],  possibilitando  o  uso  de  máquinas  de  inferência  para  a  comparação  de regras e fatos. O componente decisório também controla a execução dos objetivos dos agentes. Agentes  SemantiCoreK  possuem  objetivos  (representados  por  uma  ontologia) cujo alcance está relacionado à execução de um plano de ação. 

  As  ações  e  planos  de  ação  são  armazenados  no  componente  Executor,  que trabalha  com  o  mecanismo  de  workflow.  As  ações  mapeiam  todos  os  possíveis comandos que um agente deve entender para trabalhar de forma apropriada. Executando determinadas ações os agentes podem, inclusive, mandar mensagens para outros agentes através do ambiente. São os efetuadores do componente Efetuador os responsáveis por encapsular as mensagens em diferentes formatos para serem transmitidos no ambiente. 

  O  componente  Organizador  permite  ao  agente  recuperar,  interpretar  e  usar objetos  de  conhecimento.  Objetos  de  conhecimento  são  armazenados  na  base  de conhecimento  local do agente e podem ser adquiridos através da interação com outros agentes. A aquisição de novos objetos de conhecimento é realizada pelo mecanismo de aquisição e aplicação de conhecimento. Os agentes podem compartilhar seus objetos de conhecimento  com  outros  agentes  utilizando  o  mecanismo  de  compartilhamento  de conhecimento.  Registros  de  execução  são  utilizados  para  iniciar  o  mecanismo  de aquisição de conhecimento de forma pró­ativa. 

V Workshop on Software Engineering for Agent-oriented Systems

62

  

  A  Figura  1  mostra,  de  forma  geral,  como  os  componentes  de  um  agente SemantiCoreK interagem entre si. Como pode ser observado na figura, o ciclo de vida de um agente SemantiCoreK é composto por quatro operações básicas (linhas cheias): sentir o ambiente, decidir o que fazer de acordo com as informações sentidas, executar ações, e publicar informações no ambiente.  O  componente  Organizador  filtra  a  comunicação entre os outros componentes do agente de forma a recuperar mensagens relacionadas a gestão  de  conhecimento  do  agente.  As  linhas  tracejadas  da  Figura  1  indicam  que  o componente Organizador recebe mensagens do componente Sensorial (mensagens cujo assunto inclui as strings “knowledge delivery� ou “knowledge request�), do componente Decisório (é esse componente que sinaliza as necessidades de conhecimento do agente), e  do  componente  Executor  (para  receber  informações  sobre  a  execução  de  um determinado plano – o que permite avaliar o nível de satisfação atingido). Além disso, o componente  Organizador  pode  requisitar  ao  componente  Efetuador  a  transmissão  de mensagens a outros agentes do sistema (mensagens de requisição de conhecimento). 

Figura 1. Ciclo de vida básico de um agente SemantiCoreK. 

  As ações executadas por um agente a cada nova mensagem recebida podem ser visualizadas, de forma mais detalhada, no diagrama de atividades apresentado na Figura 2  (as  ações  ou  sub­atividades  executadas  pelo  componente  Organizador  estão  com preenchimento). De acordo com a figura, mensagens relacionadas ao compartilhamento de conhecimento são diretamente enviadas aos mecanismos apropriados do componente Organizador. As demais mensagens recebidas são adicionadas a base de fatos do agente, que é então avaliada para verificar se novos objetivos devem ser perseguidos. Caso um novo objetivo deva ser alcançado e o agente saiba como fazê­lo (há um plano de ação associado  ao  objetivo),  o  componente  Executor  se  encarrega  de  executar  as  ações  do plano de  ação  apropriado. Caso  hajam objetivos  a  serem  atingidos, mas o  agente não disponha de conhecimento para tanto, outros mecanismos do componente Organizador são  sinalizados  para  que  o  conhecimento  necessário  seja  localizado  e  adicionado  ao agente. Os principais conceitos e mecanismos relacionados ao componente Organizador, que possibilitam a realização das ações citadas, serão detalhados a seguir. 

3.2. Estruturas internas do componente Organizador 

3.2.1. Cenário de exemplo 

Nas  próximas  seções  será  utilizado  um  cenário  relacionado  ao  domínio  de  vendas  de veículos  online  para  ilustrar  os  conceitos  e  mecanismos  propostos.  O  cenário  foi desenvolvido  na  linguagem  Java  Standard  Edition  utilizando  o  ambiente  de desenvolvimento Eclipse. Para a criação e edição das ontologias, foi utilizada a API do Jena (versão 2.4). Outro exemplo de uso desenvolvido com o framework proposto pode ser encontrado em [Lemke et al. 2007]. 

Organizador (Compartilhar/Adquirir 

conhecimento) 

Decisório (Decidir) 

Executor (Executar) 

Efetuador (Publicar) 

Sensorial (Sentir) 

[Requisição de conhecimento interna]

[Sinal de final de execução] 

[Mensagens de requisição ou compartilhamento de 

conhecimento]

V Workshop on Software Engineering for Agent-oriented Systems

63

Figura 2. Fluxo de ações executadas pelo agente a cada mensagem recebida. 

  No  domínio  de  vendas  de  veículos  há,  basicamente,  dois  atores:  o  cliente  e  o vendedor. Clientes interagem com os vendedores para encontrar carros que atendam as suas necessidades. Vendedores procuram identificar carros de acordo com as exigências dos clientes e, ao concluir uma venda, recebem uma comissão sobre o valor negociado. Os  clientes  podem  comprar  ou  não  um  dos  carros  sugeridos.  Os  vendedores  podem oferecer descontos aos clientes, mas isto impacta negativamente no valor da comissão. Para  concluir  mais  vendas,  os  vendedores  costumam  utilizar  diferentes  estratégias: alguns procuram vender carros a um preço mais alto (maior lucro por venda), e outros oferecerem carros a um preço menor (lucro dissipado em um maior número de vendas). A utilização de uma ou outra estratégia está  relacionada às  flutuações do mercado, ou seja, os vendedores precisam estar atentos às mudanças do mercado para adaptar suas estratégias de venda de forma a atingir seus objetivos de maneira satisfatória. 

  Características  como a necessidade de avaliar os  resultados obtidos em vendas anteriores (para verificar se uma estratégia de venda está sendo satisfatória) e a possível necessidade de aquisição e aplicação de novas estratégias de venda durante a execução, tornam o desenvolvimento de agentes SemantiCoreK adequado para o domínio descrito. Nos  exemplos  que  serão  utilizados  nas  próximas  seções,  tanto  vendedores  quanto clientes  possuem  agentes  pessoais  SemantiCoreK  para  auxiliar  na  execução  de  suas tarefas.  Todo  agente  representando  um  cliente  (chamado  de  AgCliente)  possui  um objetivo chamado “Solicitar Carro� que pode ser atingido com a execução do plano de ação “Comprar Carro� (composto pelas ações seqüenciais “Solicitar carros disponíveis�, “Selecionar  carro�  e  “Apresentar  resultado�).  No  exemplo,  considera­se  que  um AgCliente sempre irá utilizar esse plano de ação para atingir seu objetivo. 

V Workshop on Software Engineering for Agent-oriented Systems

64

  

  Um  AgCliente,  ao  mandar  suas  preferências  a  um  AgVendedor  (agente  que representa um vendedor), faz com que esse tente alcançar o objetivo “Vender Carro�. O objetivo  “Vender  Carro�  pode  ser  atingido  utilizando  diferentes  objetos  de conhecimento  (na  tentativa  de  maximizar  os  lucros  com  diferentes  estratégias).  O comportamento  apresentado  por  um  AgVendedor  ao  longo  de  sua  execução  permite ilustrar boa parte dos mecanismos do componente Organizador. 

3.2.2. Objetos de conhecimento 

Os  objetos  de  conhecimento  são  compostos  por  itens  que  podem  ser  agrupados  em quatro partes básicas, que são:  (i) a descrição do problema;  (ii) a  lista de meta­dados; (iii) o  restritor de acesso; e  (iv) a  solução para o problema descrito. As  três primeiras partes são representadas pelos itens GoalITEM, DescriptorITEM e RestrictionITEM. A solução para o problema descrito é representada por uma série de itens vinculados aos diferentes elementos que compõem a arquitetura interna do agente SemantiCoreK (esses itens  são  adicionados  a  arquitetura  do  agente  quando  o  objeto  de  conhecimento  é utilizado para alcançar um objetivo). A Figura 3 ilustra como é constituído um objeto de conhecimento. Os itens com preenchimento são obrigatórios (multiplicidade igual a 1). 

Figura 3. Itens de um objeto de conhecimento.  

  Todo  item  de  um  objeto  de  conhecimento  possui  dois  atributos:  element,  que representa  o  elemento  encapsulado  pelo  item;  e  elementSchema,  que  contém  uma ontologia  com  todas  as  informações  necessárias  para  se  recriar  o  elemento  em  outro contexto  (outro  agente).  No  momento  em  que  há  transferência  de  conhecimento,  a ontologia  (elementSchema)  é  instanciada  com  as  informações  capturadas  no  elemento indexado pelo atributo element e apenas o modelo com as instâncias é transmitido.

  O  item  GoalITEM  encapsula  o  objetivo  do  objeto  de  conhecimento  (classe KOGoal).  O  objetivo  é  representado  por  uma  ontologia  que  descreve  os  conceitos envolvidos no problema cujo conhecimento encapsulado no objeto almeja solucionar. É com o uso dessa ontologia que são feitas as verificações de similaridade entre os objetos de  conhecimento  disponíveis  e  as  necessidades  de  conhecimento. O  objetivo  também está  associado  a  uma  ou mais  sentenças,  que  possibilitam  a  verificação  da  satisfação alcançada com o uso do objeto de conhecimento. Para fazer a avaliação da satisfação, é necessário:  (i)  recuperar  as  informações  sobre  a  execução  do  agente;  (ii)  recuperar os critérios  para  verificação  da  realização  do  objetivo;  (iii)  calcular  a  classificação  da execução  através  da  comparação  dos  valores  obtidos  durante  a  realização  do  objetivo com os valores indicados nas sentenças. 

V Workshop on Software Engineering for Agent-oriented Systems

65

  Para o desenvolvimento do cenário de exemplo,  foram criados dois objetos de conhecimento  com diferentes  estratégias  de  venda  para o objetivo “Vender Carro�. O objetivo de um dos objetos de conhecimento (que será chamado “OC1�) está ilustrado na Figura 4 (a ontologia está  representada em notação UML, conforme o especificado em  [OMG  2006]).  A  verificação  da  satisfação  alcançada  com  o  uso  desse  objeto  de conhecimento é feita através da verificação de duas sentenças, conforme código abaixo. 

  kogoal.addVerificationSentence("carroVendido", "=", true); 

  kogoal.addVerificationSentence("valor", ">=", 10);

  O critério utilizado para a verificação das sentenças atribui um valor entre 1 e 5 para  o  alcance  do  objetivo  considerando  a  porcentagem  de  sentenças  verdadeiras (quanto maior a porcentagem de sentenças verdadeiras, mais favorável é o resultado da execução). Assim, se um carro é vendido a um valor maior ou igual a seu valor mínimo acrescido de 10%, o objetivo “Vender Carro� é considerado plenamente satisfeito e, na escala de 1 a 5 considerada, atribui­se o valor 5 para o  seu alcance.  Já  se a compra é concluída  com  um  valor  menor  do  que  o  valor  mínimo  do  carro  acrescido  de  10%, atribuí­se  o  valor  3  ao  alcance  do  objetivo. No  caso  de  compra não concluída  (o que torna as duas sentenças falsas), é atribuído o valor 1. O segundo objeto de conhecimento criado  (“OC2�)  possui  um  objetivo  semelhante  ao  de  “OC1�,  mas  define  outra especialização para o conceito “Estratégia�. 

Figura 4. Estrutura ontológica do objetivo do objeto de conhecimento “OC1”.  

  O DescriptorITEM  apresenta  informações  sobre o objeto de  conhecimento  (ou meta­dados). Para a seleção dos meta­dados foi utilizado o material desenvolvido pela iniciativa Dublin Core Metadata (www.dublincore.org/). O agente pode usar esses meta­dados como informação adicional para selecionar um objeto de conhecimento para usar ou  compartilhar.  O  RestrictionITEM  descreve  as  restrições  de  compartilhamento  que devem ser verificadas antes da distribuição de um objeto de conhecimento. As restrições de compartilhamento do objeto são também pontos de flexibilidade da arquitetura.  

  Os demais itens de um objeto de conhecimento estão relacionados à arquitetura interna dos agentes SemantiCoreK.  Para  representar  os  elementos  que  compõem  um agente, foram definidos os itens: SensorITEM, FactITEM, RuleITEM, ActionPlanITEM,e  EffectorITEM.  Um  objeto  de  conhecimento  deve  conter,  obrigatoriamente,  um  (e apenas um) item do tipo ActionPlanITEM (que encapsula um plano de ação). 

  Os dois objetos de conhecimento criados para a aplicação de vendas de veículos online  encapsulam  um  sensor  do  tipo  “OWLSensor�  para  capturar  mensagens  cujo conteúdo  esteja  representado  usando  a  linguagem  OWL  (forma  de  representação utilizada para o envio das preferências de um AgCliente).   Além  desse  item,  os  objetos 

V Workshop on Software Engineering for Agent-oriented Systems

66

  

de  conhecimento  possuem um plano  de  ação  composto  por  duas  ações:  executando  a ação  “Sugerir  carros�  os  agentes  são  capazes  de  criar  uma  lista  com  os  carros disponíveis  de  acordo  com  as  exigências  dos  clientes;  já  a  ação  “Avaliar  proposta� permite que os agentes avaliem as propostas recebidas, concluindo ou não uma venda. As ações possuem implementações diferentes em cada objeto de conhecimento. 

3.2.3. Gerenciamento dos registros de execução 

Cada  vez  que  um  objeto  de  conhecimento  é  utilizado  para  atingir  um  objetivo,  um registro de execução é criado para armazenar os resultados alcançados com o seu uso. Os registros de execução permitem que o  framework verifique o quão satisfatório está sendo o uso de um objeto de conhecimento para  atingir  um objetivo  e,  se necessário, que sinalize a necessidade de um novo conhecimento. A política de troca define como os registros de execução são avaliados. Por exemplo, no cenário de vendas de veículos online, o AgVendedor procura por novos conhecimentos depois de executar o objetivo “Vender Carros� por 10 vezes com avaliação menor ou igual a 3. 

   Para ilustrar os benefícios do uso do histórico de execução, a Figura 5 mostra a comissão média obtida por um AgVendedor utilizando os dois objetos de conhecimento criados. O eixo vertical  indica a média de comissão obtida ao  longo de um dia  (valor total  de  comissão  sobre  vendas  realizadas  dividido  pelo  número  de  clientes  que solicitaram  carros).  O  eixo  horizontal  indica  as  propostas  de  compra  recebidas  dos clientes.  Empregando  o  conhecimento  encapsulado  em  “OC1�  (linha  cheia),  o  agente começa com bons resultados, mas seu desempenho diminui ao longo do tempo. 

  Utilizando os registros de execução, o AgVendedor pode identificar este tipo de situação  e  substituir  o  conhecimento  obsoleto.  No  exemplo  ilustrado  na  Figura  5,  o agente apresenta um melhor desempenho após começar a utilizar o segundo objeto de conhecimento (linha tracejada). É preciso salientar que, assim como os agentes podem aperfeiçoar  suas  habilidades  utilizando diferentes  objetos  de  conhecimento,  também é possível que eles obtenham resultados insatisfatórios. Entretanto, agentes SemantiCoreK

avaliam  seus  resultados  continuamente  e,  enquanto  um  objeto  de  conhecimento satisfatório não for encontrado, eles continuarão buscando por conhecimento melhor. 

Figura 5. Comissão obtida utilizando diferentes objetos de conhecimento. 

V Workshop on Software Engineering for Agent-oriented Systems

67

3.2.4. Mecanismo de aquisição e aplicação de conhecimento 

O mecanismo de aquisição de conhecimento é acionado sempre que um agente precisa procurar por novos conhecimentos para atingir os seus objetivos. De maneira resumida, as atividades executadas para solicitar conhecimento são: (1) recuperar a representação ontológica do objetivo sem conhecimento associado  (ou com conhecimento obsoleto); (2)  definir  a  lista  de  destinatários da mensagem de  requisição de  conhecimento;  e  (3) enviar uma mensagem de requisição de conhecimento para todos os agentes da lista. 

  Depois de transcorrido um  determinado  tempo  (indicado  pelo  atributo waitingTime), é iniciado o processo de análise das respostas recebidas para a solicitação. A análise dos objetos de conhecimento recebidos começa com a utilização de critérios para  a  verificação  da  similaridade  entre  duas ontologias  (a ontologia que  representa  a demanda  e  a  ontologia  que  representa  o  objetivo  de  cada  um  dos  objetos  de conhecimento).  Depois  de  aplicados  os  critérios,  um  objeto  de  conhecimento  é selecionado  para  uso.  Essa  seleção  é  feita  de  acordo  com  uma  política  de  aplicação(ponto de flexibilidade da arquitetura). Como exemplos de políticas de aplicação citam­se:  aplicar  o  objeto  de  conhecimento  com  a  maior  similaridade,  aplicar  o  objeto  de conhecimento com maior similaridade e enviado por um agente confiável, entre outros. Para  finalizar,  os  itens  do  objeto  de  conhecimento  selecionado  são  adicionados  a arquitetura do agente, que passa então a  ter as habilidades necessárias para alcançar o objetivo  cuja  falta  de  conhecimento  desencadeou  o  mecanismo  de  aquisição  de conhecimento. 

3.2.5. Mecanismo de compartilhamento de conhecimento

Cada  vez  que  um  agente  recebe  uma  solicitação  de  conhecimento  é  feita  uma verificação  de  similaridade  entre  a  solicitação  e  todos  os  objetos  de  conhecimento disponíveis  em  sua  base  de  conhecimento  local.  Os  agentes  possuem  uma  lista  de critérios  para  verificar  a  similaridade  entre  os  objetos  de  conhecimento  disponíveis  e uma dada solicitação de conhecimento. Como resultado desta verificação, é gerada uma lista com as “notas� atribuídas a cada objeto de conhecimento. Com base nessa lista e, considerando­se as  restrições de compartilhamento dos objetos  (RestrictionITEM),  são selecionados  os  objetos  de  conhecimento  para  envio  ao  agente  solicitante.  A  rotina usada  para  selecionar  os  objetos  de  conhecimento  que  serão  enviados  ao  agente solicitante é também um ponto de flexibilidade da arquitetura. 

4. Trabalhos relacionados 

Na maioria das plataformas para o desenvolvimento de SMAs disponíveis, quando um agente  não  consegue  lidar  com um evento  desconhecido  ou  não  possui  conhecimento para atingir determinado objetivo, o evento ou objetivo é simplesmente descartado.  

  De  qualquer  forma,  a  abordagem  com  características  mais  similares  ao SemantiCoreK  é  apresentada  por Ancona  e Mascardi  (2003). Em  [Ancona  e Marcardi 2003] é descrita a Coo­BDI, uma abordagem desenvolvida para programar agentes que modificam  seus  comportamentos  dinamicamente  através  da  cooperação  com  outros agentes  (“cooperação�  significa  recuperar  planos  externos  ao  agente  para  atingir determinados desejos). Ainda que essa abordagem apresente algumas similaridades com o framework  descrito  neste  artigo,  há  importantes  diferenças  entre  as  propostas. 

V Workshop on Software Engineering for Agent-oriented Systems

68

  

Primeiro,  acredita­se  que  um  plano  de  ação  representa  apenas  um  fragmento  do conhecimento  necessário  para  um  agente  agir  de  forma  a  alcançar  um  objetivo.  Pode haver casos onde, para um agente executar um plano (e, consequentemente, atingir um objetivo),  seja necessária  a  existência de  certas  crenças,  que precisam ser  recuperadas junto  com  o  plano  (considerando  um  agente  com  arquitetura  BDI).  Outra  diferença substancial  entre  as  propostas  é  a  utilização  do  histórico  de  execução.  A  abordagem Coo­BDI  não  verifica  os  resultados  obtidos  com  os  planos  recuperados  de  outros agentes. Para finalizar, na abordagem Coo­BDI, a similaridade entre um plano de ação e um objetivo  é verificada  através de uma comparação  entre strings. No SemantiCoreK,como  ambos  objetivos  dos  agentes  e  objetos  de  conhecimento  possuem  um representação ontológica, a  similaridade entre eles é verificada através da comparação entre duas ontologias. 

  Outras propostas  investigam, de forma parcial, a  integração de um processo de Gestão de Conhecimento em organizações multiagentes. Entre as propostas encontradas na  literatura  que  contemplam  ao  menos  uma  das  atividades  do  processo  de  GC sintetizado, destaca­se a descrita em [Rybinski e Ryzko 2003]. Rybinski e Ryzko (2003) descrevem soluções para as atividades capturar (os agentes solicitam conhecimento aos outros membros da comunidade) e distribuir  (onde o  conteúdo da solicitação deve ser comparado com o conhecimento local do agente e há verificação do nível de confiança do agente solicitante antes da distribuição). 

5. Considerações 

Considerando­se  a  importância  da Gestão  de Conhecimento  para  prover  um ambiente em  que  exista  compartilhamento  de  conhecimento  com  suporte  ao  armazenamento  e recuperação de informações, esse artigo apresentou os principais aspectos do frameworkSemantiCoreK  que  possibilita  aos  agentes,  entre  outras  funcionalidades,  o  reuso  do conhecimento  existente,  visto  que  o  conhecimento  pode  ser  compartilhado  entre  os agentes  e  utilizado  em  diferentes  situações  e  contextos,  e  a  substituição  do conhecimento ineficiente, através da análise do histórico de execução. O conhecimento dos  agentes  é  encapsulado  em  unidades  chamadas  objetos  de  conhecimento,  que  são representados como ontologias para o compartilhamento. 

  Com o  uso do SemantiCoreK, os desenvolvedores podem  indicar uma  série de objetivos  para  os  agentes  sem  necessariamente  indicar  como  eles  serão  atingidos. No momento  em  que  um  determinado  objetivo  precisa  ser  alcançado,  o  conhecimento necessário  pode  ser  localizado  e  carregado  automaticamente  através  da  execução  das atividades  do  processo  de  GC  integrado  a  arquitetura  do  framework.  Também,  a existência  de  pontos  de  flexibilidade  para  a  avaliação  e  seleção  dos  objetos  de conhecimento  possibilita  que  esses  sejam  avaliados  e  selecionados  de  acordo  com  os mais diferentes critérios. 

  Acredita­se  que  a  habilidade  de  compartilhar  conhecimento  para  atingir  um objetivo  representa  um  considerável  avanço  no  desenvolvimento  de  SMAs.  Os benefícios  da  arquitetura  proposta  também  podem  ser  visualizados  em  um  ambiente pervasivo.  Uma  exigência  imprescindível  nesses  ambientes  é  a  capacidade  de  re­configuração  e  adaptação  de  comportamentos  de  forma  a  reagir  dinamicamente  às 

V Workshop on Software Engineering for Agent-oriented Systems

69

mudanças ocorridas no ambiente. Para satisfazer esse requisito, é necessária uma infra­estrutura que permita a gestão do conhecimento. 

  Como trabalho futuro, cita­se o desenvolvimento de uma ferramenta visual para o  desenvolvimento  dos  agentes.  Essa  ferramenta  deverá  também apoiar  na  criação  de ontologias, assim os fatos e regras podem ser definidos e testados diretamente. Um IDE como  o  Eclipse  também  deverá  ser  adaptado  para  auxiliar  na  criação  dos  objetos  de conhecimento juntamente com o código da aplicação. 

Referências 

Ancona,  D.  and  Mascardi,  V.  (2003).  “Coo­BDI:  Extending  the  BDI  model  with cooperativity�. In: Proc. of DALT­03, 2003. 

Berners­Lee,  T.,  Hendler,  J.  and  Lassila,  O.  (2001).  The  Semantic  Web.  Scientific American Magazine, May 2001. 

Blois,  M.,  Escobar,  M.  and  Choren,  R  (2007).  Using  Agents  and  Ontologies  for Application Development on the Semantic Web. Journal of the Brazilian Computer Society, v. 1, p. 1­15, 2007. 

Ferber,  J.  (1999)  Multi­agent  systems:  an  introduction  to  distributed  artificial Intelligence. Boston: Addison­Wesley, 1999, 528p. 

JENA ­ A Semantic Web Framework for Java. http://jena.sourceforge.net/, July 2009. 

Kagal,  L.  et  al.  (2002)  “Agents Making  Sense  of  the  Semantic Web�.  In:  Proc.  First GSFC/JPL Workshop on Radical Agent Concepts, 2002, pp. 417­433. 

Kucza,  T.  (2005)  “Knowledge  management  process  model�. citeseer.ist.psu.edu/576298.html, April 2005. 

Lee, D. and Lee, G. (2003) Knowledge management for computational problem solving. Journal of Universal Computer Science, vol. 9(6), 2003, pp. 563–570. 

Lemke, A., Blois, M. and Choren, R.  (2007) “A Knowledge Management Framework for  Semantic  Multi­Agent  Systems�.  In:  Seventeenth  International  Workshop  on Agent­Oriented Information Systems (AOIS), 2007, Trondheim, pp. 683­696. 

Macintosh, A., Filby, I. and Tate, A. (1998) “Knowledge Asset Road Maps�. In: Proc. of PAKM98, Basel, 1998. 

Mathi,  K.  (2004)  “Key  Success  Factors  for  knowledge management�,  Dissertação  de Mestrado, University of Applied Sciences/ Fh Kempten, Alemanha, 2004. 

OMG (2006), Ontology Definition Metamodel, Sixth Revised Submission; June 2009. 

Rybinski,  H.  and  Ryzko,  D.  (2003)  “Knowledge  sharing  in  default  reasoning  based multiagent systems�. In: IEEE/WIC IAT’03, Halifax, 2003, pp. 576­579. 

Stader, J. and Macintosh, A. (1999). Capability modelling and knowledge management. Applications  and  Innovations  in  Intelligent  Systems VII,  Springer­Verlag,  1999,  pp 33­50. 

V Workshop on Software Engineering for Agent-oriented Systems

70