terça-feira, 6 de janeiro de 2015

Metodologias do Conhecimento - K-Aspects

O Knowledge Aspects é uma abordagem para a implementação de sistemas de conhecimento em linguagens orientadas a objetos usando o paradigma orientado a aspectos e anotações de metadados. Essa abordagem:
  • define uma forte correspondência entre o Modelo de Conhecimento (MC) e sua implementação no paradigma da orientação a objetos (OO)[61].
  • Fornece um conjunto de anotações documentacionais para facilitar a leitura da associação entre o modelo de implementação e o modelo conceitual do conhecimento.
  • Um conjunto de anotações para facilitar a separação de interesses na implantação de Sistemas de Conhecimento usando orientação a aspectos (
  • K-Annotations).
  • Um conjunto de bibliotecas para realizar a interpretação das anotações e sua execução em aspectos (Biblioteca K-Aspects).
  • E uma ferramenta para geração de documentação do Modelo de Conhecimento a partir das anotações no código (KA-DocGen).

A abordagem busca atender tanto os engenheiros de conhecimento quanto os engenheiros de desenvolvimento em projetos de SC. Os engenheiros de conhecimento tem ao seu alcance um modo adequado para elaborar a especificação do MC que resulta em uma especificação em uma linguagem orientada a objetos, permitindo aos engenheiros de desenvolvimento implementarem o sistema preservando a estrutura do modelo conceitual e mantendo clara distinção entre os requisitos associados ao MC dos demais requisitos. A abordagem mostra-se bastante produtiva e utilizada em conjunto com a metodologia XP.K, posto ambas serem complementares.

K-Annotations adicionam recursos de OA ao modelo conceitual do conhecimento OO, oferecendo facilidades de tratamento separado de diversas funcionalidades transversais de um SC, através do particionamento do sistema em aspectos que implementam funcionalidades específicas, ativadas através das anotações inseridas no componente do modelo conceitual. Anotações distinguem, clara e visualmente, no código, os elementos do MC em relação ao restante do código do programa, facilitando a leitura do código pelos engenheiros de conhecimento. A função principal das anotações é prover as informações necessárias para a interpretação dos elementos de conhecimento durante a execução do programa. Anotações identificam as funcionalidades transversais relativas aos construtos do modelo e são gerenciadas pela biblioteca de aspectos.

Processo de Uso de K-Annotations

O processo de uso de k-annotations define os passos necessários para que a implementação OO do componente do modelo conceitual seja gerada com sucesso. Esse processo é definido para ser reutilizado em diferentes projetos de SCs, independente do domínio de aplicação.

O processo, figura a seguir, inicia quando o engenheiro de desenvolvimento recebe uma especificação do modelo conceitual. É necessária a implementação da especificação usando OO acrescido de k-annotations. Após a implementação do componente do modelo conceitual, o interpretador de aspectos recebe como entrada a implementação elaborada pelo engenheiro de desenvolvimento, a biblioteca de anotações, a biblioteca de aspectos e a biblioteca para tratamento de facets, axiomas e regras (as bibliotecas são reusáveis em diferentes projetos). Se o código não apresentar nenhum problema, o interpretador gera o byte-code (código intermediário usado por linguagens interpretadas), esse código intermediário da implementação do modelo e dos aspectos é então costurado pelo weaver (fornecido junto com o interpretador de aspectos) para a implementação da semântica associada às anotações via aspectos. O resultado da interpretação é a implementação executável do componente conceitual em uma máquina virtual (Java ou C#). Além da implementação do componente conceitual, o compilador também invoca a ferramenta KA-DocGen, que gera a documentação da implementação do componente conceitual, para que mais facilmente seja possível realizar revisões entre a especificação e a implementação.



Figura Processo de Uso de K-Annotations

MIKE(Model-based and Incremental Knowledge Engineering)



A metodologia MIKE (Model-based and Incremental Knowledge Engineering) na visão dos autores fornece métodos para o desenvolvimento de sistemas baseados em conhecimento, cobrindo todos os passos, desde a elicitação inicial até a implementação do projeto. Essa abordagem propõe a integração formal e semi-formal de especificações técnicas e de prototipagem para uma engenharia baseada em quadros (framework). O que distingue as metodologias MIKE e CommonKADS, é o fato da primeira integrar a prototipagem e o suporte incremental e reversível ao processo de desenvolvimento de sistemas :

·MIKE utiliza o modelo de especialista do CommonKADS como seu padrão de modelo geral e fornece uma suave transição entre a representação semi-formal, Modelo de Estrutura, e a representação formal, o Modelo KARL, além de uma implementação orientada a representação, o Modelo de Projeto. As suaves transições entre diferentes níveis de representação é essencial para permitir a prática de desenvolvimento incremental e reversível.

·Na metodologia MIKE a executabilidade do Modelo KARL permite a validação do Modelo de Especialista pela prototipação. A prototipação por sua vez melhora a integração do especialista no processos de desenvolvimento. As diferentes atividades de desenvolvimento da metodologia MIKE e os documentos resultantes dessas atividades estão dispostos na figura abaixo. Nessa metodologia o processo inteiro de desenvolvimento encontra-se dividido no números de sub-atividades.

A seguir serão apresentadas as atividades da metodologia MIKE, onde cada uma delas lida com diferentes aspectos do desenvolvimento do sistema. Estas atividades são: Elicitação, Interpretação, Formalização/Operacionalização, Projeto e Implementação.

A atividade de Elicitação é responsável pela aquisição de conhecimento. Utiliza-se o método de entrevista pra adquirir conhecimento do especialista sobre determinado domínio. O conhecimento resultante dessa fase é armazenado em linguagem natural no chamado Protocolos de Conhecimento.

A fase de Interpretação a estrutura de conhecimento que será identificada nos Protocolos de Conhecimento são representadas semi-formalmente pelo Modelo do Especialista: O modelo de Estrutura. Essa representação inicial fornece uma descrição da estrutura do conhecimento emergente e pode auxiliar na comunicação entre o engenheiro do conhecimento e o especialista.

A base para a Formalização/Operacionalização é o Modelo de Estrutura. Esse processo resulta no formal Modelo de Especialista: o Modelo KARL. KARL permite ser diretamente mapeado por uma representação operacional, pois, este é uma linguagem executável.

No Modelo de Projeto todos os requisitos, funcionais e não-funcionais, são propostos para o KBS (Knowlegde Based System ou Sistema Baseado em Conhecimento (SBC)).

Por fim no Modelo de Implementação o processo exposto no Modelo de Projeto é colocado em prática, implementando os requisitos de hardware e software previstos em um determinado ambiente.

Fonte:http://www.egc.ufsc.br/wiki/index.php/Processo_de_Engenharia_do_Conhecimento#RapidOWL

Web Semantica: Tags e Ontologias

Uma pesquisa muito interessante realizada por Leandro Miranda mostra alguns métodos aplicados para o uso da web semantica, ontologia e TAGs. Abaixo temos um trecho do que foi produzido por ele:
   A web 2.0 tem se popularizado largamente desde sua criação. Sites como o Flicker e Del.icio.us permitem que o usuário final publique conteúdo por meio de tags. Tags podem ser tomadas como referência para o conteúdo em questão, e usados amplamente como metadados descritivos, e ainda como metadados administrativos e estruturais. Infelizmente, perdem-se as vantagens de se usar dados a partir de tags quando se tenta recuperar os dados. Para solucionar tal problema, recomenda-se o implemento de semântica as tags.Até o momento, pouco se tem estudado sobre representação de tags no nível de Web Semântica. Infelizmente, seriam necessários estudos mais concretos para poder-se analisar o fenômeno das folksonomias*. A semântica das tags, trata primordialmente do compartilhamento de opiniões entre pessoas que freqüentam um mesmo espaço dentro da rede.Modelo Conceitual de GruberGruber (2007) descreve as tags como uma relação entre: um objeto (fotos, artigo de blog, etc.), o próprio recurso a ser marcado; uma tag associada a um recurso; um criador de tags (geralmente uma pessoa) que faz um link entre a tag e o objeto; a fonte, o espaço onde foi criada a tag (Flicker, del.icio.us, etc.).Ao contrário do modelo de Gruber, o modelo de triplas (usuário, recurso, tag) de Newman (2005) não apresenta a fonte de onde vieram os tags. Nota-se em ontologia de tags a instanciação de tags:Tags class que é assinada por rótulos de strings enviadas pelo usuário. Sendo instâncias de uma classe, implica que são assinadas por uma URI, que forma as bases da Web Semântica, podendo ligar semanticamente as similaridades entre as tags.SCOTA ontologia SCOT (nuvem social semântica de tags) procura descrever a estrutura e a semântica de marcação de dados por tags, para oferecer interoperabilidade entre dados de diferentes fontes. Ambas, Tagcloud e Tag são aptas a representar contexto social e semânticos em tags, pois ambas as classes incluem usuários, tags e recursos. A classe scot:Tag é uma subclasse de tags:Tag. Esta classe possui diversas propriedades para resolver ambigüidades, e ainda pode descrever a freqüência de uma tag. Até agora, a ontologia SCOT tem sido usada nos web site int.ere.st promovendo buscas, favoritos e integrando dados de tags entre diferentes, usuários, fontes e aplicações.MOATO objetivo dos MOATs (significado de uma tag) é dar um significado as tags que as máquina possam entender. Para tal, ela define: significado global para as tags, onde todos os significados de uma tag são listados dentro de uma folksonomia; e local de significado de uma tag, ou seja, o significado de uma tag em sua ação particular.O MOAT “inclui” uma parte no modelo tri-particionado (usuário, recurso, tag, significado). Ao incluir uma função sobre a ação do significado o problema de ambigüidade de nomes resolve-se. MOATs também podem permitir as pessoas de compartilhar suas tags introduzindo um aspecto social.

*Folksonomias: compartilhamento social de documentos. Diferentemente das ontologias as Foksonomias são conceitualizações não formalizadas de um determinado assunto ou campo do conhecimento, fruto da atribuição de palavras chave por parte dos usuários.

Fonte:  
MIRANDA, L. G. WEB SEMÂNTICA E WEB SOCIAL EM ENGENHARIA DO CONHECIMENTO. Disponível em  <http://www.abepro.org.br/biblioteca/enegep2009_TN_WIC_098_664_13224.pdf>

XP.K - metodologia para sistemas baseados em conhecimento


É uma metodologia ágil para o desenvolvimento de sistemas baseados em conhecimento, desenvolvida a partir da tese doutorado de Knublauch (2002)24. O XP.K estende o XP (eXtreme Programming) para trabalhar com modelagem ágil de sistemas de conhecimento.Assim como o XP, o XP.K auxilia a desenvolver sistemas com requisitos vagos e em constante mudança, como também são os sistemas baseados em conhecimento (como o conhecimento possui a característica de ser de "difícil captura", um processo cíclico, e não em cascata, auxilia no processo de sua elicitação e representação). Exige constante acompanhamento e permite vários pequenos ajustes durante seu desenvolvimento, envolvendo os principais atores (especialistas de domínio, engenheiros do conhecimento e implementadores de sistema) durante seus ciclos. Assim como o XP, possui as seguintes diretrizes :

1.comunicação;

2.simplicidade;

3.feedback;

4.coragem;

5.respeito.

O XP.K é desta forma um modelo de ciclo de vida em espiral, com resumidamente duas fases:

1.Aquisição de conhecimento;

2. Desenvolvimento do sistema.


Aquisição de conhecimento: nesta fase o engenheiro do conhecimento e o especialista de domínio definem os requisitos no chamados "Story Cards" e "Knowledge Protocols".Uma ontologia inicial é definida utilizando UML.


Desenvolvimento do Sistema:nesta fase, a implementação deste sistema de conhecimento é feita Java, utilizando K-Beans (Knowledge Java Beans).Estes têm a função de adicionar elementos semânticos (regras, axiomas ...) a sistemas implementados com orientação a objetos.Porém, segundo Eduardo Castro, devido à convenção de código adotado, uma classe pode representar tanto regras (cardinalidades) como axiomas (range, domain ...), o que pode tornar difícil a separação destes conceitos.O K-Aspects, além de apontar outras críticas e melhorias, propõe a utilização de anotações para separar devidamente estes elementos.

A grande vantagem do XP.K é aceitar as mudanças no projeto de um SBC em tempo real. Por ser relativamente recente possui um baixo nível de adoção.


Fonte:http://www.egc.ufsc.br/wiki/index.php/Processo_de_Engenharia_do_Conhecimento#RapidOWL

Metodologia Engenharia do Conhecimento: NeOn



É uma Metodologia de engenharia de ontologias baseada em cenários, cujo foco é o desenvolvimento de ontologias em rede. A metodologia Neon visa a reutilização, a reengenharia e a mesclagem de recursos ontológicos e não ontológicos de forma colaborativa e dinâmica. A figura a seguir ilustra os 9 cenários que essa metodologia se baseia:





Cenário 1 - Da especificação para implementação: A rede de ontologia é desenvolvida a partir do zero, não utilizando qualquer recurso existente. Os desenvolvedores especificam neste cenário os requisitos da ontologia. Depois disso, são analisados os recursos necessários para que esta ontologia possa ser reutilizada futuramente. Então deve ser realizado o agendamento das atividades da metodologia e os desenvolvedores devem seguir com a implementação.


Cenário 2 - Reuso e Reengenharia dos recursos não ontológicos: Um recurso não ontológico (NOR) é um recurso de conhecimento consciente cuja semântica ainda não foi formalizada através de uma ontologia. Porém, neste cenário, esses recursos são utilizados para criar ou aprimorar uma rede de ontologias, através de um processo de reengenharia, que irá adaptar os recursos não ontológicos dentro de uma determinada ontologia, dando semântica a este recurso.


Cenário 3 - Reuso de recursos ontológicos: neste cenário os desenvolvedores usam recursos ontológicos já existentes, por exemplo: ontologias já definidas ou partes de ontologias para a construção ou aprimoramento de uma rede de ontologias.


Cenário 4 - Reuso e reengenharia de recursos ontológicos: Neste cenário os desenvolvedores utilizam as ontologias existentes através de um processo de reconstrução gerando novas redes de ontologias.


Cenário 5 - Reuso e mesclagem de recursos ontológicos: este cenário surge quando vários recursos ontológicos do mesmo domínio são selecionados para reutilização, sendo que os desenvolvedores podem criar um novo recurso ontológico, mesclando os recursos selecionados.


Cenário 6 - Reuso, mesclagem, e reprojeto de recursos ontológicos: Este cenário é semelhante ao cenário 5, porém, com a diferença de que aqui os desenvolvedores reprojetam um conjunto de recursos ontológicos já mesclados.


Cenário 7 - Reuso de padrões de projeto de ontologia: para o desenvolvimento de novas ontologias, os desenvolvedores utilizam padrões de projeto existentes encontrados em repositórios.


Cenário 8 - Reestruturação de recursos ontológicos: Nesse cenário, os desenvolvedores da ontologia reestruturam recursos ontológicos que serão integrados na rede de ontologias, por exemplo: o modulo de uma ontologia poderá ser podado, ampliado ou sofrer uma especialização para posteriormente ser integrado a rede de ontologias.


Cenário 9 - Localizando recursos ontológicos: neste cenário, os desenvolvedores adaptam uma ontologia para outras línguas e outras comunidades culturais, obtendo assim uma ontologia multilíngue.

Fonte: http://www.egc.ufsc.br/wiki/index.php/NeOn

Camadas da Web Semântica 3

Finalizando a série sobre as camadas da Web Semântica falaremos sobre as camadas Rules, Logic, Proof, e Trust.



Como de costume começaremos da mais baixa para a mais alta. Portanto começaremos pela camada Rules:    
    Nesta camada encontramos descrição de regras para a Web Semântica. As linguagens Rule Markup Language (RuleML) e Semantic Web Rule Language (SWRL) são exemplos de linguagens propostas para a descrição dessas regras. Nesse sentido, o W3C iniciou o trabalho sobre o Rule Interchange Format (RIF) para fornecer suporte ao intercâmbio das diversas tecnologias baseadas em regras (RIBEIRO, 2008). Atualmente, esforços têm se concentrado na especificação desta camada, principalmente tendo como ponto de partida cenários e requisitos na área de e-commerce, pois se trata de um segmento com uma aplicabilidade direta com relação a regras de negócios (HALLE, 2002).

 A próxima é a camada Logic (Lógica):
    A camada denominada Lógica fornece suporte para a descrição de regras para expressar relações sobre os conceitos de uma ontologia, as quais não podem ser expressas com a linguagem de ontologia utilizada.

 Iremos falar sobre a camadas Proof(prova) e Trust (confiança) em um único parágrafo:  
     As camadas denominadas de Prova e Confiança fornecem o suporte para a execução das regras, além de avaliar a correção e a confiabilidade dessa execução. Considerando que a internet não possui nenhum controle obrigatório de autenticidade bem formulado, pode-se assumir que qualquer um pode falar qualquer coisa, independente de qualquer que seja o assunto na web. A liberdade de expressão nem sempre tem um tom positivo quando se trata de confiabilidade nas fontes de geração de informação, pois todo e qualquer tipo de informação pode ser disponibilizado na web (SMITH e ALESSO, 2005). Uma solução possível para tal problema, segundo Leuf (2006) é a utilização de assinaturas digitais, entre outros recursos, para prover a prova que realmente certa pessoa escreveu um determinado documento, por exemplo. Nesse caso, usuários poderão decidir em quem confiar e o nível de confiança de cada entidade na, também chamada, web of trust.


Abaixo temos o link para acesso ao artigo onde pode-se ler o conteúdo acima.


Fonte:  
MIRANDA, L. G. WEB SEMÂNTICA E WEB SOCIAL EM ENGENHARIA DO CONHECIMENTO. Disponível em  <http://www.abepro.org.br/biblioteca/enegep2009_TN_WIC_098_664_13224.pdf>

Ferramentas de Gestão de Conhecimento

Nesta seção, apresento uma visão geral das ferramentas e sistemas baseados em TI que podem ajudar a gestão do conhecimento (KM) cumprir as suas metas.

O escopo desta seção é fornecer ao leitor uma visão geral dos tipos de ferramentas de GC disponíveis no mercado hoje e para ganhar uma compreensão de qual é seu papel no processo de KM. Este é o passo mais importante, uma vez que existem literalmente milhares de opções para escolher. No entanto, no futuro, pretendo também dar uma olhada em algumas ferramentas de GC reais e apresentar alguns comentários.

Para recapitular, eu tenho lidado com ferramentas de GC durante toda a seção sobre as iniciativas de gestão táticos, destacando seu papel na descoberta de conhecimento, organização, partilha, etc. Na seção sobre a estratégia de gestão do conhecimento, eu apresentei um artigo sobre o conhecimento de implementação de sistemas de gestão, onde eu declarou que as ferramentas baseadas, em sua maior parte, se enquadram em uma das seguintes categorias (adaptado de Gupta e Sharma 2005 em Bali et al 2009):

Sistemas de groupware e KM 2.0
A intranet e extranet
Armazenamento de dados, mineração de dados, e OLAP
Sistemas de Apoio à Decisão
Sistemas de gerenciamento de conteúdo
Sistemas de gestão de documentos
Ferramentas de inteligência artificial
As ferramentas de simulação
redes semânticas


Por enquanto, nas subseções que se seguem, vou discutir os primeiros seis categorias de ferramentas KM nesta lista, como eles são geralmente o que as pessoas referem-se ao falar de ferramentas de GC. As ferramentas de simulação é muito ampla a categoria para o escopo deste site, e sistemas de inteligência artificial são de utilidade questionável e estão fora da minha área de especialização. No entanto, no (não muito perto) futuro, eu pretendo adicionar um segmento em redes semânticas e inteligência artificial.

Uma breve nota sobre a inteligência artificial: Embora tenha havido muita emoção sobre isso há alguns anos atrás, no meu entender, não tem viveu até suas expectativas (ainda). Os sistemas especialistas, por exemplo, projetado para capturar a tomada de decisão humana e para tomar as decisões corretas em determinadas circunstâncias, não teria sido tão bem sucedida devido a requisitos em constante mudança (Botha et al 2008). Para saber mais sobre isso, temas de pesquisa, tais como redes neurais, sistemas de apoio à decisão inteligentes e sistemas especialistas.

Mais uma vez, eu gostaria de lembrar ao leitor que KM não é uma disciplina tecnológica; é mais sobre gestão de pessoas, a cultura e as práticas e estruturas organizacionais. Iniciativas eficazes de GC são, portanto, nunca de base tecnológica, e nunca se deve buscar uma KM total de "solução". Na verdade, gostaria de alertar contra qualquer sistema que coloca reivindicações às esse título. Fazer isso implica que tanto os desenvolvedores têm nenhum problema prometendo muito mais do que eles podem oferecer, ou eles não têm idéia do que uma ferramenta KM pode e não pode fazer. Também não é um bom cenário.

No entanto, se for utilizado direita - como um mecanismo de apoio e reforço para o som, as práticas de GC existente - pode ser uma ferramenta muito valiosa, de fato.


Alan Geada M.Sc. de 2010 - Atualizado em 2013

Leia mais:
http://www.knowledge-management-tools.net/knowledge-management-tools.html#ixzz3O5bTdIxA