domingo, 23 de dezembro de 2012

Case-based reasoning Part IV


O texto é basedo no tutorial:
* Recio-Garcia , Díaz-Agudo , González-Calero (2008).
*Learning in Non-Stationary Environments - Methods and Applications (2012)
* Material de aula de Inteligência Artificial - Hugo Pedro Proença, (2007/2008)

Case-based reasoning (CBR) - Parte IV

Chegamos na parte prática desse tutorial. Usando a biblioteca JColibri  e a ferramenta eclipse INDIGO vamos entender um pouco mais como funciona CBR.

Para ilustrar as capacidades da biblioteca, nós implementaremos uma clássica aplicação CBR para determinar se devemos jogar tênis hoje conforme as experiências anteriores.

Antes de iniciar o desenvolvimento desse sistema inteligente, é necessário instalar a biblioteca JColibri no eclipse. Para fazer isso vá no menu help>>Install New Software. A seguinte janela(Figura 1) deve abrir:

Figura 1
Digite o endereço http://colibricbrstudio.net/update na caixa de texto work with. Selecione o item "COLIBRIStudio" e clique em next até instalar.

Para habilitar a visuliazação do Jcolibri no eclipse, vá no menu Windows>>Open Perspective>> Other. Selecione a opção COLIBRI. Agora podemos dar início ao desenvolvimento!

Vamos detalhar em passos o desenvolvimento:

1)  Vá no menu File>>New>> New k-NN CBR Project. A tela seguinte deve ser aberta (Figura 2):

Figura 2

Vamos dar uma pausa para entender o que é "k-NN". k-NN é um método de aprendizagem supervisionada.
[Sayed-Mouchaweh,2012].  O kNN segue a seguinte abordagem, para classificar x =(x1, x2, ...xn) encontra-se os k exemplos de treino mais próximos de "x", e o classifica com a classe moda nesses exemplos. 

Vejamos o seguinte exemplo que contém 3 classes, sendo necessário classificar "xu". … Usando k=5 , encontramos 4 dos vizinhos mais próximos na classe 1 e 1 exemplo na classe 3.… Atribui-se a observação xu à classe 1, uma que esta é a classe predominante. A Figura 3 ilustra esse exemplo:


Figura 3

Usando o kNN o aplicativo CBR deve tomar a decisão se joga tênis ou não. Deve-se observar que o algoritmo kNN não é muito eficiente para os casos em que o tamanho da base de treino é muito importante e k não é muito bem escolhido. [Sayed-Mouchaweh,2012]

No próximo tutorial de CBR continuamos o desenvolvimento do sistema. 



quarta-feira, 12 de dezembro de 2012

TUTORIAL PROTÉGÉ - PARTE 5

baseado no guia prático para construir ontologias OWL usando Protégé dos autores Horridge & Knublauch et al
Apostila de matemática discreta da Universidade de Caxias do Sul (2003)


PARTE 5: Relações (propriedades) inversas

É importante ter um noção básica sobre teoria de conjuntos campo de estudo da matemática discreta, antes de iniciar esse tutorial.

Então dados dois conjuntos A e B, uma relação binária R de A em B é um subconjunto de um produto cartesiano AXB , ou seja R está contido em AXB. Nesse caso R pode ser caracterizada como inversa, funcional, ou qualquer outra relação. 
*A é o domínio, origem ou conjunto de partida de R
*B é o contra-domínio, destino ou conjunto de chegada de R
Para R está contido em A|X|B , se <a,b> pertece a R , então afirmamos que "a relaciona-se com b". Podemos denotar uma relação R da seguinte forma: R : A-> B e, para um elemento <a,b> pertence a R , podemos denota-lo como aRb.


Simplificando a ideia, as propriedades inversas permitem um enrriquecimento nas descrições dos objetos e das classes.   Se alguma propriedade liga um indivíduo a ao indivíduo b então sua propriedade inversa deve unir b ao indivíduo a. Por exemplo: a propriedade temPai e sua propridade inversa temFilho - se Mateus temPai Jean, então pela propriedade inversa podemos inferir que Jean temFilho Mateus.

Dando continuidade a nossa ontologia de Pizza no Protégé e para fixar o conteúdo, vamos aos seguintes passos para adicionar a propriedade inversa.

(1) User o botão "add object property"  da aba "Object proprietis" para criar uma nova relação chamada isIngredientOf ( Essa se tornará a relação inversa de hasIngredient).
(2) Crie outra relação chamada hasIngredient.
(3) Selecione a relação isIngredientOf
(4) Clique no ícone "Add" próximo a " Inverse properties". Veja na figura 1

Figura 1 - Janela de tipos de relações da relação isIngredientOf

(5) Clique no ícone "Add" próximo a " Inverse properties". A seguinte janela será apresentada (Veja na figura 2). Selecione a relação hasIngredient e clique em Ok. A propriedade "hasIngredient" deve ser mostrado na janela "Inverse Property".

Figura 2 - janela de seleção de relação inversa
(6) Crie 2 novas relações "hasBase" e "IsBaseOf". Selecione a relação "hasBase".

(7) Clique no botão Add próximo a " Inverse properties". Selecione a relação "isBaseOf" e clique em OK. Observe que a relação "hasBase" agora tem a propriedade inversa "isBaseOf". Você pode opcionalmente colocar a relação "isBaseOf" como sub-relação de "isIngredientOf". (OBSERVE A DIFERENÇA AO APLICAR A MÁQUINA DE INFERÊNCIA - tema dos próximos capítulos.)
 

(8) Crie 2 novas relações "hasTopping" e "isToppingOf".  Inclua a relação "isToppingOf" como inversa de "hasTopping".

GALERA, preste atenção ao fato que ao descrevermos os conceitos do mundo com a matemática nos livramos principalmente da AMBIGUIDADE da linguagem natural.

No próximo tutorial espero falar sobre relações FUNCIONAIS. GOOD LOCK!!

segunda-feira, 3 de dezembro de 2012

Case-based reasoning Part III

O texto é basedo no tutorial:
* Recio-Garcia , Díaz-Agudo , González-Calero (2008).
* AquaStress Technical Instruments (2007).


Case-based reasoning (CBR) - Parte III

 

Antes de inicarmos o desenvolvimento de uma aplicação prática usando o JColibri, vale a pena mostrar uses cases. O AquaStress é um framework inteligente construído a partir dos conceitos do CBR.

Contextualizando o problema do Aquatress. Há muitas regiões da Europa expostas ao problema de falta de água devido a demanda excessiva, que desencadeia medidas sérias de mitigação. Esse tipo de problema e as regiões afetadas podem ser comparáveis entre si. Isso portanto é útil para pesquisar por "casos" similares e (re)utilizar as experiências em situações problemáticas e medidas de mitigação observadas em outros lugares.

A metodologia CBR é muito apropriada para comparação de casos complexos onde a informação é imcompleta. O AquaStress é baseado no jCOLIBRI (um framework que gera código CBR) e consiste de vários componentes, a saber: um construtor, um publicador, um banco de dados, serviços e uma interface web.

Para mais informações sobre o Aquastress: http://i3s.aquastress.net

Existem outras situações práticas do CBR:

Otimização da eficiência energética: http://www.ami-moses.eu/
Classificação do câncer de mama maligno/benigno: http://proceedings2010.imcsit.org/pliks/192.pdf

terça-feira, 20 de novembro de 2012

Case-based reasoning Part II

O texto é basedo no tutorial Recio-Garcia , Díaz-Agudo , González-Calero (2008).


Case-based reasoning (CBR) - Parte II

 

Em nível maior de generalidade, uma aplicação CBR pode ser descrita por ciclo composto dos seguintes 4 processos:

* RECUPERAR o mais comum dos casos ou caso.
* REUTILIZAR a informação e conhecimento no caso para solução de um problema.
* REVISAR a solução proposta.
* RETER parte da experiência provavél para ser útil na solução futura de um problema.

Um novo problema é solucionado pela recuperação de um ou mais casos experienciados anteriormente, reutilizando o caso, revisando a solução baseada na reutilização de casos anteriores, e retendo a nova experiência pela incorporação na base de conhecimento existente (base de casos). A figura 1 ilustra o ciclo.

Figura 1


Uma descrição inicial do problema define a consulta. Esse novo CASO é usado para RECUPERAR o caso a partir da coleção de casos anteriores.  O caso recuperado é combinado com um novo caso - por meio do REUSO - na solução de casos, ou seja, uma solução proposta  para o problema inicial. Por meio do processo de REVISÃO esta solução é testada com sucesso, por exemplo: ao ser aplicado em um ambiente do mundo real, ou avaliado por um professor, ou reparação de uma falha. Durante a RETENÇÃO (ou RECORDAR/RELEMBRAR), experiências úteis são retidas para futuros reusos, e a base de casos é atualizada por novos casos aprendidos, ou pela modificação de alguns casos existentes.

Como indicado na figura 1, o conhecimento geral usualmente desempenha uma parte neste ciclo, pelo apoio dos processos do CBR. Esse apoio pode ter um alcance muito fraco (ou nenhum) a muito forte, dependendo do tipo de método CBR. Por conhecimento geral, entendemos geral por conhecimento dependente do domínio, ao contrário do conhecimento específico embutidos nos casos. Por exemplo, no diagnóstico de um paciente pela recuperação e reuso do caso de pacientes anteriores, um modelo de anatomia junto com relacionamento causal entre estados patológicos pode constituir o conhecimento geral utilizado por um sistema CBR. Um conjunto de regras pode ter a mesma função.

O próximo tutorial do CBR tentarei disponibilizar o conceito aplicado. Usarei a biblioteca jColibri e implementarei algo. É possível que utilize ontologias nesse desenvolvimento.

terça-feira, 13 de novembro de 2012

TUTORIAL PROTÉGÉ - PARTE 4

baseado no guia prático para contruir ontologias OWL usando Protégé dos autores Horridge & Knublauch et al

PARTE 4: HIERARQUIA DE CLASSES

 É muito comum criar taxonomias ou classificações(hierarquias) com o fim de organizar a ontologia. Entenda bem , apenas a criação de uma taxonomia não significa que criamos uma ontologia. Muitos mais formalismos são necessários para expressar e descrever o mundo. Hoje falaremos apenas de como criar hierarquias no Protegé.

Há 2 formas de criar hierarquias. A primeira é ilustrada na Figura 1, na qual destacamos em vermelho os botões responsáveis pela criação das classes hierárquicas.

Figura 1

A outra forma é muito útil se você possui grande quantidade de classes para criar. Para fazer isso clique em TOOLS >> CREATE CLASS HIERARCHY. Uma janela deve ser aberta conforme ilustrada na figura 2.



Figura 2




Tenha em mente que tudo que estamos criando são relações matemáticas. A Figura 3 esclarece esse ponto de vista ilustrado como conjuntos:

Figura 3


No próximo tutorial falaremos sobre outras relações entre classes.

terça-feira, 6 de novembro de 2012

Case-based reasoning Part I

Intercalaremos os tutoriais do Protégé com os estudos sobre raciocínio baseado em casos (Case-based reasoning), que pode ser muito bem integrado a ontologias.

O texto é basedo no tutorial Recio-Garcia , Díaz-Agudo , González-Calero (2008).


Case-based reasoning (CBR) - Parte I


Raciocínio baseado em casos é um paradigma para resolução de problemas e aprendizagem. CBR é baseado na intuição que os problemas tendem a se repetir. Isso significa que novos problemas são frequentemente similares ao problemas encontrados anteriormente e , portanto, que soluções do passado podem ser usados na situação atual [12]. CBR está enrraizado no trabalho de Roger Schank sobre memória dinâmica e  o papel central que lembrando de episódios anteriores (casos) e scripts ( situações padrões) tem na resolução de problemas e aprendizagem [48].

CBR é particularmente aplicável a problemas onde casos anteriores estão acessíveis, mesmo quando o domínio não é suficientemente bem entendido para um profundo modelo do domínio. Helpdesk, disgnósticos ou sistemas de classificação tem sido as áreas mais bem sucedidas de aplicação, ou seja, para determinar falhas ou diagnosticar uma doença por meio de atributos observados, ou para determinar se ou não certos tratamentos ou reparos são necessários dado um conjunto de casos resolvidos no passado [54].

As tarefas centrais que todos os métodos CBR têm de lidar são[2]: "Identificar a atual situação do problema, encontrar no passado casos similares ao novo, nesse caso sugerir uma solução para o problema atual, avaliar a proposta da solução, e atualizar o sistema para aprendenter a partir desta experiência. Como isto é feito, qual parte do processo que é focado, quais tipos de problemas que acionam métodos, etc. múltiplas questões que variam consideravelmente".


No próximo post sobreCBR falaremos sobre o ciclo de vida. A intenção futura é desenvolver algo usando Jcolibri2.  See you some other day!!!

[12] E. by David Leake.
Case Based Reasoning. Experiences, Lessons and Future Directions. AAAI Press. MIT Press, USA, 1997.


[48] R. C. Schank.
Dynamic Memory. Cambridge Univ. Press, 1983.


[54] I. Watson.
Applying case-based reasoning: techniques for enterprise systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1998.


[2] A. Aamodt and E. Plaza. Case-based reasoning: Foundational issues, methodological variations, and system approaches.
AI Communications, 7(i), 1994.

terça-feira, 30 de outubro de 2012

TUTORIAL PROTÉGÉ - PARTE 3

baseado no guia prático para construir ontologias OWL usando Protégé dos autores Horridge & Knublauch et al 

PARTE 3: CLASSES

As classes definem um grupo de indivíduos que partilham as mesmas propriedades. No Protégé a edição de classes é realizada usando a "Classes Tab", como mostrado na Figura 1. Toda ontologia contém uma classe chamada Thing. A classe Thing representa um conjunto de todos os indivíduos. Todas as classes são subclasses de Thing. Vamos adicionar a classe "Pizza" a nossa ontologia.

Figura 1 - Classes TAB

A Figura 2 ilustra a barra de ferramenta para trabalhar com adição/exclusão de classes.

Figura 2 - Barra de ferramenta


Adicione as classes PizzaTopping e PizzaBase. Embora não seja obrigatório , é recomendado que todas as classes devem iniciar com letra maícula e não deve conter espaços. Alternativamente pode ser usado underline "_" para unir palavras, por exemplo Pizza_Topping.

Depois de adicionar essas 3 classes na ontologia, precisamos dizer que as classes são DISJUNTAS, para que um indivíduo ( instâncias ou objetos) não possa ser instânciado por mais de uma das 3 classes. Para isso selecione a classe Pizza. Depois clique em Disjoint Pizza. A janela ilustrada na Figura 3 abrirá. Selecione PizzaBase e PizzaTopping e por final clique em OK.




Figura 3 - Disjoint Pizza


As classes OWL são consideradas "sobrepostas" (Como conjuntos que há interseção) Portanto não podemos assumir que um indíviduo não é um membro de uma classe particular simplesmente porque não tem sido afirmada como membro da classe. A fim de "separar" um grupo de classes deve explicitá-las como disjuntas. Isso assegura que um indivíduo é membro de apenas uma classe. Não faz sentido no mundo real um indivíduo pertencer a classe Pizza e PizzaBase.

Existe um atalho no protegé que torna mais rápido a criação de classes e a disjunção de clases. Clique no menu edita para " Remove ou Add Disjoint classe".


No próximo curso falaremos sobre hierarquia de classes, ou melhor criaremos uma taxonomia para nossa ontologia. Na literatura muitos autores denominam como ontologias lightweight.