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.

Ontologia e ontologias

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

Ontologia e ontologias

Uma vez que este papel é deliberadamente dirigido a um público interdisciplinar, é aconselhável atenção para alguns esclarecimentos preliminares terminológicos, especialmente porque alguns termos parecem ser utilizados com sentidos diferentes em diferentes comunidades. Vamos primeiro considerar a distinção entre "Ontologia" (com "O" maiúsculo), como na declaração "Ontologia é uma disciplina fascinante" e "ontologia" (com letra "o" minúsculo ), como na expressão "ontologia de Aristóteles" ou "ontologia do CYC".  Enquanto a primeira interpretação se refere a uma disciplina filosófica particular, a segunda  é usada pela comunidade da Inteligência Artificial (em geral, toda comunidade de ciência da computação).

No sentido filosófico, pode se referir a uma ontologia como um sistema particular de categorias responsável por uma certa visão do mundo. Esse sistema não depende de uma linguagem particular. a ontologia de Aristóteles é sempre a mesma, independentemente da língua usada para descrevê-la. Por outro lado, no seu uso mais predominante na IA (Inteligência Artificial), uma ontologia se refere a um artefato de engenharia, constituído de um vocabulário específico usado para descrever uma certa realidade, além de ser um conjunto de hipóteses explícitas sobre o significado pretendido das palavras de um vocabulário. Esse conjunto de hipóteses são normalmente na forma de uma teoria de lógica de primeira ordem, onde as palavras do vocabulário aparecem como nomes de predicado unário ou binário, respectivamente chamados conceitos e relações. No simples caso, uma ontologia descreve uma hierarquia de conceitos relacionados pelas relações subsunção, em casos mais sofisticados, axiomas apropriados são adicionados para expressar outras relações entre conceitos e restringir sua interpretação pretendida.

As duas interpretações de “ontologia” como descrita acima são relacionadas entre si, mas a fim de resolver o impasse terminológico precisamos escolher uma das interpretações. Vamos adotar a interpretação de IA, com a conceituação da palavra para se referir à interpretação filosófica. Assim, duas ontologias podem ser diferentes no vocabulário utilizado (Usando palavras em Inglês ou Italiano, por exemplo), enquanto partilham a mesma conceituação. A noção de conceituação apresentada acima exige, todavia, uma formalização adequada, uma vez que pode gerar algumas confusões. Com efeito, uma conceituação foi definida em um livro de IA conhecido como uma estrutura <D,R>, onde D é um domínio e R é um conjunto ou relações relevantes em D6. Essa definição foi depois usado por Tom Gruber, que definiu uma ontologia como "uma especificação de uma conceituação" [21]. 

O problema com a noção de conceituação de Genesereth e Nilsson é que se refere as relações matemáticas simples em D, isto é, as relações preocupada com a realidade. Essas relações refletem um determinado estado de coisas: Por exemplo, em um mundo de blocos,  pode refletir uma organização especial dos blocos sobre a mesa. Precisamos ao invés de se concentrar no significado dessas relações, independentemente de um estado das coisas: por exemplo, o significado da relação “acima”, encontra-se na forma como a relação se refere a certos conjuntos de blocos de acordo com sua organização espacial. Precisamos, portanto, para falar das relações intencionais vamos chamá-los de relações conceituais, reservando-se o simples termo "relação" de relações matemáticas simples.

A forma padrão para representar intenções (e, portanto, as relações conceituais), é considerar como funções de mundos possíveis em conjuntos. Isso tem algumas desvantagens, mas funciona muito bem para os nossos propósitos. Embora as relações normais sejam definidas em um determinado domínio, relações conceituais são definidas em um espaço de domínio. Vamos definir um espaço de domínio como uma estrutura <D, W>, onde D é um domínio e W é um conjunto máximo de estados do objeto de tal domínio (também chamados de mundos possíveis). Por exemplo, D pode ser um conjunto de blocos em uma tabela e W pode o conjunto de todos os possíveis organizações espaciais destes blocos. Podemos dizer, portanto, que uma conceituação é um conjunto de relações conceituais definidas em um espaço de domínio.

Consideremos agora a estrutura <D, R> . Uma vez referido a um mundo particular (ou estado de coisas), vamos chamá-lo de uma organização (estrutura) do mundo. É fácil ver que uma conceituação contém muitas organizações (estruturas) do mundo.

Seja C = <D, W, a> ser uma conceituação. Para cada mundo possível w pertence a W, a estrutura pretendida de w de acordo com C é a estrutura S_wc = <D, R_wc>, onde R_wc = {p (w) | p pertece a R} é o conjunto de extensões (em relação à w) dos elementos de R. Iremos denotar com S_c o conjunto (S_wc | w pertence a W) de todas as estruturas do mundo pretendido de C. 

Dada uma linguagem L com um vocabulário V, e um compromisso ontológico K = <C, a> para L, um modelo <S, I> será compatível com K se: i)S pertence S_c ii) para cada constante c , I(c) = a(c) ; iii) existe um mundo w tal que , para cada símbolo de predicado p, I tais mapas predicados dentro de um admissível extensão de a(p), ou seja, existe uma relação conceitual r tal que a(p) = p ^ p(w) = I(p). O conjunto I_k (L) de todos os modelos de L que são compatíveis com K será chamado o conjunto de modelos pretendidos de L de acordo com K.

Em geral, não haverá maneira de reconstruir o compromisso ontológico de uma linguagem

a partir de um conjunto de seus modelos pretendidos, uma vez que um modelo não reflete, necessariamente, um determinado mundo: na verdade, uma vez que as relações relevantes não podem ser consideradas completamente suficientes para caracterizar um estado de coisas, e um modelo pode realmente descrever uma situação comum em muitos estados de coisas. Isso significa que é impossível reconstruir a correspondência das relações entre os mundos e relação de extensão estabelecida pela conceituação base. Um conjunto de modelos pretendidos, portanto, apenas uma fraca caracterização de uma concepção: apenas exclui algumas interpretações absurdas, sem realmente descrever o "sentido" do vocabulário.

Ontologia e Sistemas de Informação by Guarino

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

Ontologia e Sistemas de Informação

Investigação sobre a ontologia está se tornando cada vez mais difundida na comunidade de ciência da computação. Embora esse termo tem sido bastante limitado à esfera filosófica do passado, agora está ganhando um papel específico em Inteligência Artificial, Lingüística Computacional e Banco de Dados. Em particular, a sua importância é reconhecida em diversos campos de pesquisa como engenharia do conhecimento [20,45,15,18], na representação do conhecimento [23,2,42], modelagem qualitativa [19,9,13], a engenharia da linguagem [31,5], o projeto de banco de dados [11,47], as modelagem de informações [3,53], a integração da informação [55,7,35], a análise orientada a objetos [51,39], em recuperação de informações, e extração de informações [24,6,34,54], gestão e organização do conhecimento [40], os projetos de sistemas baseados em agentes. Em áreas de diferentes aplicações, incluindo integração empresarial, tradução da linguagem natural, medicina , engenharia mecânica, a padronização do conhecimento do produto, comércio eletrônico, sistemas de informação geográfico, sistema informações jurídicos, sistemas de informações biológico. Vou usar o termo genérico para o termo sistemas de informação, em seu sentido mais amplo, para coletivamente referenciar este campos e área de aplicação.

Em alguns casos, o termo "ontologia" é apenas um nome fantasia que denota o resultado de atividades familiares, como análise conceitual e modelagem de domínio, realizado por meio de normas metodológicas. Em muitos casos, no entanto, ontologias supostamente apresenta as suas próprias metodologias e peculiaridades arquitetônicas. No lado metodológico, a principal particularidade é a adoção de uma abordagem altamente interdisciplinar, onde a filosofia e a lingüística desempenham um papel fundamental na análise da estrutura de uma determinada realidade em um alto nível de generalidade e na formulação de um vocabulário claro e rigoroso. Do lado da arquitetura, o aspecto mais interessante é a centralidade do papel que uma ontologia pode desempenhar em um sistema de informação, levando à perspectiva dos sistemas de informação dirigidos a ontologia. Chamei a atenção para outras [23,24] a importância de uma abordagem interdisciplinar na prática da engenharia ontológica, subjacente, em particular o papel desempenhado pela ontologia formal. Uma vez que este tema vai ser abordado com mais detalhe mais para frente [41,50], vou evitar aqui qualquer comentário adicional.

Em vez disso , vou primeiro propor a elaboração do mais recente trabalho esclarecimentos sobre a forma a termo "ontologia" é utilizado em ciência da computação originalmente apresentado em [27]. Apesar de alguns progressos, Eu acredito que há ainda uma boa quantidade de terminologias e confusão conceitual, e eu vou tentar, assim, esclarecer melhor - em relação ao trabalho passado - as noções de ontologia, o compromisso ontológico e conceituação. E então introduzir a perspectiva de sistemas de informação dirigidos a ontologias, mostrando como ontologias pode desempenhar um papel central, afetando os principais componentes de uma informação sistema: os recursos de informação, interfaces de usuário e programas aplicativos.

[20] Gruber, T. R. 1993. A translation approach to portable ontology specifications. Knowledge Acquisition,5: 199-220.

[45] Uschold, M. and Gruninger, M. 1996. Ontologies: Principles, Methods and Applications. The Knowledge Engineering Review, 11(2): 93-136.

[15] Gaines, B. 1997. Editorial: Using Explicit Ontologies in Knowledge-based System Development.International Journal of Human-Computer Systems, 46: 181.

[18] Gómez-Pérez, A. K. 1997. Knowledge Sharing and Reuse. In Liebowitz (ed.) The Handbook on Expert Systems. CRC Press.

[23] Guarino, N. 1995. Formal Ontology, Conceptual Analysis and Knowledge Representation. International Journal of Human and Computer Studies, 43(5/6): 625-640.

[2] Artale, A., Franconi, E., Guarino, N., and Pazzi, L. 1996. Part-Whole Relations in Object-Centered Systems: an Overview. Data and Knowledge Engineering, 20(3): 347-383.

[42] Sowa, J. F. 1998. Knowledge Representation: Logical, Philosophical, and Computational Foundations. PWS Publishing Co. (forthcoming), Boston.

[19] Gotts, N. M., Gooday, J. M., and Cohn, A. G. 1996. A Connection Based Approach to Commonsense Topological Description and Reasoning. The Monist: An International Journal of General Philosophical Inquiry, 79(1).

[9] Borgo, S., Guarino, N., and Masolo, C. 1997. An Ontological Theory of Physical Objects. In Proceedings of Qualitative Reasoning 11th International Workshop. Cortona, Italy, IAN-CNR, Pavia: 223-231.

[13] Casati, R. and Varzi, A. 1997. Spatial Entities. In O. Stock (ed.) Spatial and Temporal Reasoning. Kluwer, Dordrecht.

[31] Lang, E. 1991. The LILOG Ontology from a Linguistic Point of View. In O. Herzog and C. R. Rollinger (eds.), Text Understanding in LILOG. Springer-Verlag, Berlin.

[5] Bateman, J. A. 1995. On the Relationship Between Ontology Construction and Natural Language: aSocio-Semiotic View. International Journal of Human-Computer Studies, 43: 929-944.

[11] Burg, J. F. M. 1997. Linguistic Instruments in Requirements Engineering. IOS Press.

[47] Van de Riet, R., Burg, H., and Dehne, F. 1998. Linguistic Issues in Information Systems Design. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[55] Wiederhold, G. (ed.) 1996. Intelligent Integration of Information. Kluwer Academic Publishers, Boston, MA.

[7] Bergamaschi, S., Castano, S., De Capitani di Vimercati, S., Montanari, S., and Vincini, M. 1998. An Intelligent Approach to Information Integration. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[35] Mena, E., Kashyap, V., Illarramendi, A., and Sheth, A. 1998. Domain Specific Ontologies for Semantic Information Brokering on the Global Information Infrastructure. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[51] Wand, Y. 1989. A Proposal for a Formal Model of Objects. In W. Kim and F. H. Lochovsky (eds.), Object-Oriented Concepts, Databases, and Applications. Addison Wesley, Reading, MA: 537-559.

[39] Pazzi, L. 1998. Three Points of View in the Characterization of Complex Entities. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[24] Guarino, N. 1997. Semantic Matching: Formal Ontological Distinctions for Information Organization, Extraction, and Integration. In M. T. Pazienza (ed.) Information Extraction:

[6] Benjamins, V. R. and Fensel, D. 1998. The Ontological Engineering Initiative (KA)2. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[34] McGuinness, D. 1998. Ontological Issues for Knowledge-Enhanced Search. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[54] Welty, C. 1998. The Ontological Nature of Subject Taxonomies. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[40] Poli, R. 1996. Ontology and Knowledge Organization. In Proceedings of 4th Conference of the International Society of Knowledge Organization (ISKO 96). Washington.

[23] Guarino, N. 1995. Formal Ontology, Conceptual Analysis and Knowledge Representation. International Journal of Human and Computer Studies, 43(5/6): 625-640.

[24] Guarino, N. 1997. Semantic Matching: Formal Ontological Distinctions for Information Organization, Extraction, and Integration. In M. T. Pazienza (ed.) Information Extraction: A Multidisciplinary Approach to an Emerging Information Technology. Springer Verlag: 139-170.

[41] Smith, B. 1998. Basic Tools of Formal Ontology. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[50] Varzi, A. 1998. Basic Problems of Mereotopology. In N. Guarino (ed.) Formal Ontology in Information Systems. IOS Press (this volume).

[27] Guarino, N. and Giaretta, P. 1995. Ontologies and Knowledge Bases: Towards a Terminological Clarification. In N. Mars (ed.) Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing 1995. IOS Press, Amsterdam: 25-32.