Modelo de Markov X Modelo Bayesiano

Resolvi escrever comparando os modelos de Markov e o Bayesiano, pois no meu processo de aprendizagem escrever amadurece as ideias aprendidas. Minha intenção não é falar o que é cada modelo, mas apenas falar sobre as diferenças entre os modelos.



Gostaria de começar com a seguinte frase,que talvez tenha sentido ao final da leitura desse artigo:


" Modelos gráficos são um casamento entre teoria da probabilidade e modelos gráficos. Eles fornecem uma ferramenta natural para lidar com dois problemas que ocorrem na matemática aplicada e engenharia -- incerteza e complexidade -- e em particular desempenham de modo crescente um papel importante no projeto e análise de algoritmos de machine learning. A ideia fundamental do modelo gráfico é a noção de modularidade -- um sistema complexo é construído pela combinação de partes simples. A teoria da probabilidade fornece pistas por meio de quais partes são combinadas, assegurando um sistema consistente, e fornecendo maneiras de modelar dados. A modelagem gráfica fornece tanto para uma interface intituitiva para o ser humano (a interação dos conjuntos de variáveis) , bem como uma estruturada de dados usada para projetar de forma eficiente algoritmos." (Kevin Murphy, 1998)

Modelos gráficos probabilísticos são grafos cujos nós representam variáveis aleatórias, e os vértices (a falta) representam hipóteses de independência condicional. Assim, fornecem um representação compacta das distribuições das probabilidades conjuntas(joint). Modelos gráficos não dirigidos cíclicos, chamados de rede de Markov, tem uma definição de independência: dois (conjuntos de) nós A e B são condicionalmente independentes dado um terceiro conjunto C, se todos os caminhos entre os nós em A e B são separados pelos nó C. Em contrate, modelos de grafos dirigidos também chamados de Bayesianos , tem uma noção mais complicada de independêcia, na qual leva em conta a direção dos vértices.

Embora modelos dirigidos tem uma noção mais complicada de indepêndencia que os modelos não dirigidos, os modelos dirigidos levam vantagens sobre o outro modelo. A mais importante é que um pode considerar um vértice de A para B como indicativo de que A causou B ( conceito de causalidade). Isso pode ser usado como um guia para construir grafos estruturados. Além disso, modelos dirigidos podem codificar relações determinísticas, e são mais facéis de aprender (ajustar dados).

Para um modelo dirigido, podemos especificar a distribuição condicional das probabilidades para cada nó, conforme Figura 1. Se as variáveis são discretas, isso pode ser representado em tabelas, com a lista de probablidade que cada nó e a combinação de possibilidades. Vamos considerar o seguinte exemplo, na qual todos os nós são binários, ou seja, temos dois valores possíveis: V (verdadeiro) e F (Falso).

Figura 1

A relação de indepência condicional é codificada na rede bayesiana e indica o seguinte: o nó é independente de seus ancentrais se seu pai é determinado.


Pela regra da probabilidade , então a probabilidade conjunta de todos nós no grafo acima é:
P(C, S, R, W) = P(C) * P(S|C) * P(R|C,S) * P(W|C,S,R)

Usando regra de indepêndencia condicional podemos reescrever como:
P(C, S, R, W) = P(C) * P(S|C) * P(R|C) * P(W|S,R)



A tarefa mais comum usando em redes bayesianas é inferência probabilística. Por exemplo, supomos que observamos o fato que a grama está molhada. Há duas possibilidades: ou choveu ou irrigador disparou. Qual é mais provável? Nós podemos usar a regra de Bayes para calcular as probabilidades:


P(irrigadoraAutomático = V/ gramaMolhada=V) = 0.2781/0.6471 = 0.430

P(choveu = V/gramaMolhada=V) = 0.4581/0.6471 =0.708


Assim é mais provável que a grama esteja molhada por causa da chuva. Com o modelo de Markov não é possível realizar esse tipo de inferência , pois o modelo é sem memória. O objetivo do modelo é: "dado o presente o futuro é independe do passado." Markov adiciona uma nova camada ao modelo que é não observável.

Figura 2

Agora podemos observar apenas os y's, que são relacionados aos não observáveis x's. Por exemplo, Se você está cego e não pode observar o céu ou sentir a chuva cair,os y's são " a grama está molhada em um especifico dia.", e os x's são "Está chovendo em um específico dia".


O processo de decisão Markoviano são fundamentalmente diferentes, porque envolve "controle". Você, o agente, tem poder de influenciar o sistemas. Por exemplo, Você está decidindo se liga o irrigador em determinado dia. Cada dia, você se baseia no estado do mundo observável. Então, você só pode ligar o irrigador se você observar se a grama está seca. Não permite ligar o irrigador baseado no estado da grama de ontem.

A seguir uma tabela relacionando as diferenças:

Esse artigo foi baseado no artigo: A Brief Introduction to Graphical Models and Bayesian Networks





Sugiro a leitura dos seguintes textos:

1) http://setosa.io/blog/2014/07/26/markov-chains/

2)Artigo An Introduction to Conditional Random Fields By Charles Sutton and Andrew McCallum Contents

TUTORIAL PROTÉGÉ - PARTE 7

TUTORIAL PROTÉGÉ - PARTE 7

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

PARTE 7: RELAÇÕES (PROPRIEDADES) FUNCIONAIS INVERSAS

Olá pessoal,

Fiquei um tempo afastada, por causa do trabalho e também por encontar uma coisa que tem me fascinado. Eu andei nadando em outras águas. Descobri a linguagem R e o poder de data analysis. Daqui alguns dias publicarei alguma coisa sobre isso. Acredito que o data analysis possa nos ajudar nos experimentos. Mas vamos falar hoje sobre relações funcional inversa .

O que é propriedade funcional inversa? Primeiro, vamos nos lembrar da relação funcional olhando para os seguintes exemplos:

Relação 1) Jean temNasceudaMãe Peggy

Relação 2) Jean temNaceudaMãe Margaret

Se temNaceudaMãe é uma relação funcional isso indica que Peggy e Margaret são a mesma pessoa. Nesse contexto, Jean pode nascer de apenas 1 mãe. Na relação inversa funcional os exemplos são:

Relação 3) Peggy éMãeDe Jean

Relação 4) Margaret éMãeDe Jean

Perceba que para um único indivídio há dois associados. Esses 2 indivíduos continuam sendo a mesma pessoa neste contexto. Um relação inversa pode ser funcional,  mas o contrário não é válido.

Wordnet - bibliotecas

Achei umas bibliotecas interessantes para acessar a Wordnet  por meio de programação Java:

1) http://projects.csail.mit.edu/jwi/

2) http://sourceforge.net/apps/mediawiki/jwordnet/index.php?title=Main_Page

3) http://yawni.sourceforge.net/wiki/index.php

Qual abordagem de aprendizagem de máquina usar?

Existem várias abordagens de aprendizagem de máquina, mas qual devo usar por exemplo para meu sistema question answering??  O grafo ilustrado na Figura 1 pode responder a essa pergunta.

Figura 1 (Fonte: http://peekaboo-vision.blogspot.com.br/2013/01/machine-learning-cheat-sheet-for-scikit.html )

ACHADO

Primeiramente, desculpe por tantos dias sem postar nada. Estou trabalhando em um projeto e continuarei sem tempo para postar.


Só que nessas minha andanças,  achei um plugin para o PROTÉGÉ muito interessante:

http://protege.stanford.edu/plugins/psmtab/PSMTab.html

Esse plugin apoia a construção de sistemas baseados em conhecimento a partir de componentes reutilizáveis de conhecimento, conhecidos como PSM (Problem-Solving Methods). PSMs são algoritmos genéricos que codificam estratégias independentes de domínio para realizar tarefas cognitivas comuns (exemplo: classificação diagnóstico, projeto, etc.) pelo processamento de conhecimento do domínio.

TUTORIAL PROTÉGÉ - PARTE 6

TUTORIAL PROTÉGÉ - PARTE 6

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

PARTE 6: RELAÇÕES (PROPRIEDADES) FUNCIONAIS

Se a propriedade é funcional para um determinado indivíduo, pode existir mais de 1 indivíduo que é relacionado ao indivíduo por meio da propriedade. A Figura 1 mostra um exemplo de propriedade funcional temNasceuDaMãe - Alguém tem apenas 1 mãe de sangue. Se dizemos que o indivíduo Jean temNasceuDaMãe Peggy e também dizemos Jean temNasceuDaMãe Margaret, então  temNasceuDaMãe é uma propriedade funcional, podemos inferir que Peggy e Margaret são os mesmos indivíduos (É isso que uma máquina de inferência, como o Pellet, gera). Entretanto deve ser observado que se Peggy e Margaret foram explicitamente indicados para ser dois indivíduos diferentes então as sentenças acima levaria a uma inconsistência.

Figura 1

As propriedades funcionais são também conhecidas como propriedades de valores únicos ou características.

Próximo posting do tutorial será propriedades Propriedade Funcionais Inversas. Até a próxima.

Uma nova abordagem para um sistema question-answering

baseado no artigo Template-based Question Answering over RDF Data dos autores Unger et al.

Uma nova abordagem para um sistema 

question-answering

O artigo tema desse post é muito rico, por isso vale a pena depois baixar e ler por inteiro. Vou tentar resumi-lo. A maioria dos sistemas de question-answering que utilizam RDF (http://www.w3.org/RDF/) mapeiam a pergunta (linguagem natural) em uma representação de triplas RDF . Dessa forma obtém-se a resposta à pergunta por meio de um consulta a uma base de dados RDF. Alguns dos famosos sistemas que usam essa solução: Aqualog, PowerAqua, NLP-Reduce, FREyA, etc. Será que essa solução funciona em todos os casos?

Essas abordagens são muito boas para os casos em que o significado da consulta pode ser recuperado facilmente.Em muitos outros casos a estrutura semântica original da pergunta não pode ser fielmente capturada usando triplas, como por exemplo a pergunta: "Qual a cidade que tem mais de 3 universidades?". Consultas que usam agregação, filtros com quantidade específicas e intervalares não são fielmente capturados usando triplas.

A proposta desse sistema é gerar templates SPARQL que se aproximem da semântica da pergunta. Por exemplo: Quantos filmes Leonardo Dicaprio estrelou? Pode ser visto na figura 1 um dos templates proposto para a pergunta.

Figura 1

Para chegar no template SPARQL, alguns processos de PLN foram realizados. A arquitetura geral do sistema está ilustrada na Figura 2:

Figura 2

Nesse mesmo artigo fala sobre BOotstrapping linked datA.Você já ouviu falar sobre isso??? Vou preparar um posting sobre isso. até a próxima.

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. 

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!!

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

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.

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.

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.

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.

TUTORIAL PROTÉGÉ - PARTE 2

Continuação do curso de protégé. Esse curso é baseado nas seguintes literaturas:
1) Revolutionizing Knowledge Discovery in the life sciences. Autores: Baher e Cheung. Ano: 2007
2) Handbook on Ontologies. Autores: Staab e Studer. Ano: 2009
3) A Pratical Guide To Building OWL Ontologies Using Protégé 4. Autores: Horridge e Matthew et al.

PARTE 2: Expressividade 

No curso anterior falamos sobre a aba "DL metrics" do Protégé. Essa aba exibe a expressividade DL (Lógica de Descrição) da ontologia. Por exemplo: A ontologia permite propriedades inversas da lógica de descrição? Mas o que é expressividade de uma linguagem? É a habilidade da linguagem exprimir ou descrever algo.

Muitas pessoas argumentam que o principal benefício de usar ontologias para modelar o conhecimento torna-se mais evidentes em aplicações baseadas em raciocínio. Inferir novos conhecimentos e extrair conclusões além das afirmações explícitas é um aspecto de aplicações "inteligentes". Entretanto, o poder do raciocínio depende da expressividade da representação do conhecimento formalizado.

À luz de um equilíbrio entre a expressividade alta e o custo computacional, destacamos a alta expressividade manifestada em linguagens baseadas em lógica de primeira ordem (FOL), OWL FULL etc. Enfatizamos também linguaguens que minimizam o custo computacional, tais como: OWL-Lite, OWL-DL e outras de lógica descritiva.

Qualquer avaliação de uma ontologia leva em consideração a expressividade da linguagem. Uma forma de avaliar é transformar a ontologia em uma linguagem canônica(Que segue a estrutura mais usual ou mais neutra na língua). A figura 1 ilustra essa transformação:

Figura 1

Voltemos ao Protégé que é o alvo do curso. No Protégé a janela DL metrics (Figura 2) exibe a expressividade. A medida que novos construtos são adicionados a ontologia , o Protégé atualiza o DL metrics. Cada letra do DL metrics possui um significado.

Figura 2

Por exemplo a letra F simboliza que está sendo utilizado propriedades funcionais na ontologia.

No próximo curso falaremos sobre criação de classes e classes disjuntas. see you soon!

TUTORIAL PROTÉGÉ - PARTE 1

Vamos iniciar um mini-curso de criação de ontologia utilizando o Protégé 4.2 como apoio. o mini-curso será baseado no guia prático para contruir ontologias OWL usando Protégé dos autores Horridge & Knublauch et al. Nesse tutorial trataremos do básico até ao avançado. As postagens não serão regulares, ou seja, pode ser que a próxima postagem seja de outro assunto e não consecutiva ao tutorial.

PARTE 1: Construindo uma ontologia OWL 

Neste tutorial descreveremos a criação de uma ontologia de Pizzas. Vamos usar a ontologia de Pizza porque encontramos muitos exemplos úteis, entretanto apresentaremos ao longo desse tutorial outros exemplos.

Exercício 1 : Criar uma nova ontoologia OWL
1-  Iniciar o Protégé 4.2;
2 - Escolha a opção "Create new OWL ontology";
3 - Substitua a IRI default pela http://www.semanticweb.org/ontologies/pizza.owl e clique no botão Continue;
4 - Selecione o caminho local do computador onde que salvar sua ontologia e depois clique em continue;
5 - Selecione o formato da sua ontologia RDF/XML;
6 - Clique no botão Finish;
7- Será aberta uma nova janela com uma aba chamada "Active Ontology".

--------------------------------INÍCIO NOTA EXPLICATIVA-----------------------------------------
Vamos entender melhor o que é IRI e o que é o formato RDF/XML.

A URI(Uniform Resource Identifier)  é um conjunto de caracteres usado para identificar um nome ou recurso. Essa identificação permite a interação com outros recursos da rede (ou da WWW) usando protocolo específicos.

Na internet o IRI (Internationalized Resource Identifier) é a generalização da URI. Enquanto URI é limitado ao subconjunto de caracteres ASCII, a IRI pode conter um conjunto de caracteres universais (Unicode/ISO 10646), incluindo Chinês ou Japonês, entre outros. Para ampliar seus conhecimentos em URI acessa a página da W3C (http://www.w3.org/International/O-URL-and-ident.html).

Existe bastante variabilidade de como os dados são formatados. Por exemplo, existe 6 trechos de códigos e todos significam a mesma coisa:

<!-- 1 -->
<foaf:Person rdf:ID="bob" foaf:name="Bob" />

<!-- 2 -->
<foaf:Person rdf:about="#bob">
  <foaf:name>Bob</foaf:name>
</foaf:Person>

<!-- 3 -->
<rdf:Description rdf:ID="bob" rdf:type="http://xmlns.com/foaf/0.1/Person">
  <foaf:name>Bob</foaf:name>
</rdf:Description>

<!-- 4 -->
<rdf:Description rdf:ID="bob" rdf:type="http://xmlns.com/foaf/0.1/Person" />
<rdf:Description rdf:about="#bob" foaf:name="Bob" />

<!-- 5 -->
<rdf:Description rdf:about="#bob" foaf:name="Bob">
  <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person" />
</rdf:Description>

<!-- 6 -->
<rdf:Description rdf:about="#bob">
  <foaf:name>Bob</foaf:name>
  <rdf:type>
    <rdf:Description rdf:about="http://xmlns.com/foaf/0.1/Person" />
  </rdf:type>
</rdf:Description>

Os formatos mais utilizados são:RDF/XML, OWL/XML e RDF/XML-ABBREV. O OWL/XML não pode ser serializado em um grafo. O formato RDF/XML-ABBREV é mais compacto e portanto menos eficaz que o formato RDF/XML format.

--------------------------------FIM DA NOTA EXPLICATIVA-----------------------------------------

Vamos usar em nossa ontologia o formato RDF/XML.

A seguinte tela ilustra o protégé com aba ativa "Active Ontology"

Clicando em annotations você adiciona um comentário explicativo a sua ontologia. Veja na tela seguinte:



A janela DL metrics mostra a expressidade de sua ontologia. No próximo curso continuaremos nessa janela. Explicaremos em mais detalhes o que é expressividade de uma ontologia e como é medido no protégé.

METAS

NOVA METAS

Nós próximos artigos falarei mais sobre:

1) Raciocínio baseado em casos (case-based  reasoning) que usam ontologia. Para isso busquei o framework JColibri e vou implementar algo.

2) Lógica e raciocício lógico

3) Uso do protegé 4.2.

4) Recuperação da informação

Aguardem novidades em breve. Boas ideias são bem vindas.

O que é uma ontologia? segundo McGuinness & Noy

baseado no artigo McGuinness & Noy - Um guia para criar sua primeira Ontologia.

O que é uma ontologia?

A literatura de inteligência artificial contém muitas definições de uma ontologia, e muitas  se contradizem. Para o propósito deste artigo uma ontologia é uma descrição formal explicíta dos conceitos do domínio do discurso (classes (algumas vezes chamadas de conceitos)), propriedades de cada conceito descrevendo várias características e atributos do conceito (slots (algumas vezes chamados de roles ou propriedades)), e restrições nos slots ( facets ( algumas vez chamado de restrições aos role)). Uma ontologia juntamente com um conjunto de instâncias das classes constituem uma base de conhecimento. Na realidade, existe uma linha tênue onde termina a ontologia e inicia a base de conhecimento.

As classes são o foco da maioria das ontologias. Classes descrevem conceitos do domínio. Por exemplo: classes de vinhos representam todos os vinhos. Vinhos específicos são instâncias das classes. O copo de vinho Bordeaux é uma instância da classe vinho Bordeaux. Uma classe pode ter subclasses que representam conceitos que são mais específicos que uma superclasse. Por exemplo, podemos dividir as classes de todos os vinhos em tinto, branco e rosé. Alternativamente, podemos dividir em uma classe de vinhos espumante e não espumantes.

Slots descrevem propriedades das classes e instâncias: O vinho  Château Lafite Rothschild Pauillac é muito encorpado; é produzido pela vinícula Château Lafite Rothschild. Temos 2 slotes descrevendo o vinho desse exemplo: o slot encorpado com os valores muito e o slote produtor com o valor vinícula Château Lafite Rothschild. Ao nível de classes, podemos dizer que as instâncias das classes Vinho terão slots descrevendo seus  sabor, corpo,nível de açúcar, o produtor do vinho e assim por diante.

Todas as instâncias da classe Vinho, e suas subclasses Pauillac, tem um slot da qual é uma instância da classe Vinícula (Figura 1). Todas as instâncias da classe Vinícula tem um slot produtor que refere-se a todos o vinhos (instâncias das classe Vinho e suas subclasses) que são produzidos por um vinícula. 

Em termos práticos, desenvolver um ontologia inclui:

·

Definir as classes na ontologia.

· Organizar as classes em uma taxonomia (subclasse-superclasses).

·

Definir e descrever valores permitidos para os slots. 

· Preencher valores para slotes instanciados

Figura 1

Não existe uma forma ou metodologia correta para desenvolver ontologias. Descreveremos uma abordagem iterativa para desenvolvimento de ontologia: Iniciamos com um primeiro passo:

Primeiro, gostaríamos de enfatizar algumas regras fundamentais no projeto de ontologias.  Essas regras podem parecer dogmáticas.Entranto podem ajudar em muitas decisões de projeto:

1) Não existe uma maniera correta para modelar o domínio - Existem várias alternativas. A melhor solução quase sempre depende das necessidades da ontologia e do que você pretende fazer.

2) O desenvolvimento de ontologia é necessariamente um processo iterativo.

3) Os Conceitos devem ser próximos a objetos(físicos ou lógicos) e relacionamento do domínio de interesse. Esses serão muito provavelmente  substantivos (objetos) ou verbos (relacionamento) em frases que descrevem o domínio.

O primeiro passo é determinar o domínio e escopo da ontologia. As seguintes perguntas podem ser feitas:

·

Qual é o domínio que a ontologia deverá cobrir?

· Para que iremos usar essa ontologia?

· Para quais tipos de pergunta a ontologia deve fornecer resposta?

· Quem usará e manterá a ontologia?

Uma maneira de determinar o escopo da ontologia é esboçar uma lista de perguntas na qual uma ontologia deve estar apta a responder, também chamada de questões de competência (Gruninger and Fox 1995). Estas questões servirão de teste a ontologia criada. 

Por que desenvolver uma ontologia?

baseado no artigo McGuinness & Noy - Um guia para criar sua primeira Ontologia.

Por que desenvolver uma ontologia?

Nos últimos anos o desenvolvimento de ontologia - especificações formais e explicitas dos conceitos do domínio e relações entre os conceitos (Gruber, 1993) - foi movido da esfera dos laboratórios de Inteligência Artificial para os computadores de especialistas do domínio. Ontologias tem se tornado comum na Web. As ontologias na Web variam em categorizar grandes taxonomias em sites na Web (tais como Yahoo!) para categorização de produtos de vendas(tais como Amazon.com). O consórcio WWW (W3C) está desenvolvendo RDF (Resource Descriptions Framwework ), uma linguagem para codificação do conhecimento nas páginas Web para tornar compreensível a agentes eletrônicos em busca de informações.A DARPA (Agência Americana de Pesquisas) em conjunto com a W3C está desenvolvendo o DAML pela extensão do RDF com mais expressividades do construtos visando facilitar a interações de agentes na Web.  Atualmente muitas disciplinas desenvolvem ontologias padronizadas que especialistas do domínio podem usar para compartilhar e anotar informação. Por exemplo: Na medicina tem produzido vasto, padronizado, vocabulário estruturado como o SNOMED  (Price and Spackman 2000) e a rede semântica da UMLS (Unified Medical Language System) (Humphreys and Lindberg 1993). Outros amplos propósitos para as ontologias estão surgindo. Por exemplo: Programa de desenvolvimento das Nações Unidas e Dun & Bradstreet uniram esforços para desenvolver o UNSPSC, que é uma ontologia na qual fornece terminologia para produtos e serviços (www.unspsc.org).
Uma ontologia define um vocabulário comum para pesquisadores que precisam compartilhar informação de um domínio. Isso inclui definições que são interpretáveis por máquinas. Essas definições são conceitos básicos do domínio e relações entre os conceitos
Por que alguém desenvolveria uma ontologia?Algumas razões são:
* Para compartilhar entendimento comum da estrutura da informação entre as pessoas ou agentes de software.
* Permitir o reuso do domínio do conhecimento.
* Para tornar explicita hipóteses do domínio.
* Para analisar conhecimento do domínio.

Compartilhar entendimento comum da estrutura da informação entre pessoas ou agentes de software é uma dos mais comuns objetivos no desenvolvimento de ontologias(Musen 1992; Gruber 1993).  Por exemplo,
imagine vários web sites diferentes que contém informação médica ou fornecem serviços de e-commerce. Se esses sites compartilham e publicam fundamentalmente a mesma ontologia dos termos, então os agentes de software podem extrair e agregar informações dos diferentes sites. Os agentes podem usar essa informação agregada para responder consultas dos usuário ou como dados de entrada para outras aplicações.
Permitir reutilizar conhecimento do domínio foi uma das forces motrizes da recentes onda da pesquisa de ontologia. Por exemplo, modelos de domínios muito diferentes precisam representar a noção de tempo. Essas representação inclui a noção de intervalos de tempo, pontos nos tempo, medidas relativas do tempo, e assim por diante. Se um grupo de pesquisadores desenvolvem uma ontologia em detalhes, outras podem ser reutilizadas em outros domínios. Adicionalmente, se precisamos construir um ontologia grande, podemos integrar muitas ontologias existentes. Podemos também reutilizar ontologias gerais, tais como a ontologia UNSPSC, e estende-la para descrever seu domínio de interesse.

Tornar explicito as hipóteses fundamentais do domínio - Em uma implementação é possível mudar essas hipóteses facilmente se nosso conhecimento do domínio mudar. A codificação das hipóteses sobre o mundo usando uma linguagem de programação torna essas hipóteses não apenas difícil de verificar e entender , mas também é difícil de mudar para alguém sem conhecimento em programação e lógica. Além disso, especificação explícita do conhecimento do domínio são úteis para novos usuários que devem aprender o que os termos do domínio significam.

O que é ontologia segundo Guarino

Texto baseado no artigo Formal Ontology and Information Systems de Nicola Guarino

O que é ontologia

Podemos agora esclarecer o papel de uma ontologia, considerado como um conjunto de axiomas lógicos concebidos para explicar o significado de um vocabulário pretendido. Dada uma linguagem L com compromisso ontológico K, uma ontologia para L é um conjunto de axiomas de forma que o conjunto de seus modelos se aproxima da melhor forma possível do conjunto de modelos pretendidos de L de acordo com K (Fig. 1). Em geral, não é fácil (nem sempre conveniente)  encontrar o correto conjunto de axiomas, de modo que uma ontologia irá admitir outros modelos, além dos que se pretendiam. Portanto, uma ontologia pode "especificar" uma conceituação de forma indireta, desde vez que i) tenha um conjunto aproximado dos modelos pretendidos; ii) um conjunto desses modelos é apenas uma fraca caracterização de um conceitualização. Diremos que uma ontologia O para uma linguagem L aproxima de uma conceituação C se existe um compromisso ontológico K = <C,a> , de tal forma que os modelos pretendidos de L segundo K são incluídas nos modelos de O. Uma ontologia comprometida com C deve ser i)  concebida com o objetivo de caracterizar C, e ii) se aproxima de C. Uma linguagem L compromete-se com uma ontologia O que se compromete  com uma conceituação C, tal que O concorda com C. Com esses esclarecimentos, chegamos à seguinte definição, que refina a definição de Gruber, fazendo uma clara diferença entre uma ontologia e uma conceituação:

Uma ontologia é uma teoria lógica que representa o significado pretendido de um vocabulário formal, isto é, o seu comprometimento ontológico com uma conceituação particular do mundo. Os modelos pretendidos de uma linguagem lógica são limitados por seu compromisso ontológico. Uma ontologia reflete indiretamente esse compromisso (E conceituação fundamental). Pela aproximação destes modelos pretendidos.

As relações entre o vocabulário, conceituação, o compromisso ontológico e a ontologia são ilustrados na fig. 1. É importante salientar que uma ontologia é uma linguagem dependente, enquanto a conceituação é independente de linguagem. 

Figura 1: O modelo pretendido de uma linguagem lógica reflete o seu compromisso de uma conceituação.