wiki:Guias/HowTo/ProjetoPAPPEEugenio
Last modified 8 years ago Last modified on 06/14/11 16:37:17

17 de março

Foi apresentado o projeto e detalhado o seu estágio atual. Começei a estudar conceitos de semântica computacional, ontologias, e iniciei o estudo do NEPOMUK, que traz um conceito através de metodologias e soluções técnicas para a tecnologia semântica, e pelo qual vamos nos basear. Também pesquisei conceitos de RDF (linguagem para representação de informações na internet), SPARQL (linguagem de consulta em arquivos RDF) e OWL (Web Ontology Language)que são utilizados pelo NEPOMUK. Artigo Sobre o Framework Jena, que utiliza os conceitos de RDF e OWL.

18 de março

Leitura e Detalhamento dos principais pontos de Arquitetura Final do NEPOMUK

Um dos conceitos mais importantes é o Mapa Mental do Usuário, que é dividido em 3 modelos:

  • Annotation Model (AM) - É o modelo genérico para anotar os recursos.
  • Information Element Model (IEM) - Fornece um vocabulário para descrever os recursos.
  • Information Model (PIM) - Permite que usuários representem o seu próprio modelo mental de uma forma estruturada.

Estes três modelos são realizados como ontologias:


O Annotation Model (AM) é representado pela anotação NEPOMUK Ontologia (NAO), e prevê vocabulário para definição de propriedades comuns (descrições, por exemplo) e relações entre os recursos na área de trabalho semântica.

O Information Element Model (IEM) é implementado pelo conjunto de NEPOMUK Ontologias Information Element (NIE), que fornece classes e propriedades para descrever objetos encontrados na área de trabalho (por exemplo, arquivos, entradas do catalogo de endereço, e-mails)

O Personal Information Model (PIM) do usuário é modelado pelo Personal Information Model Ontology (PIMO), que prevê o vocabulário para a representação do modelo das informações pessoais individuais dos usuários no ambiente de trabalho.

A Modelagem do projeto não só utilizou a engenharia tradicional, que se inicia com a análise das necessidades do estudo de caso, como também a engenharia reversa, que inicia com a análise dos componentes existentes.

Para implementar a visão do SSD, foi criado um plano que sugere um conjunto de serviços para fornecem as funcionalidades do SSD. Esses serviços podem ser divididos em duas categorias. Primeiro, os serviços que se concentram na área de trabalho local. Estes serviços abordam a questão do PIM (Personal Information Model) e a interligação de aplicações. Em segundo lugar, serviços que se concentram nos aspectos sociais de compartilhamento de dados e troca de dados através da rede.

Foi introduzido um roteiro que especifica as ontologias e suas inter-dependências em camadas, de cima para baixo. As três camadas são a camada representacional (RDF, RDFS NRL), camada de nível superior (NAO, NIE E PIMO) e camada de nível inferior(grupos de usuários).

Foram criados alguns serviços que provém funcionalidades para o armazenamento e recuperação de metadados RDF: Data Wrapper, PIM Service, Local Storage (Apache Lucene, RDF, SPARQL, SERQL) e Local Search.

21 de março

Fazendo a leitura de Arquitetura Intermediária NEPOMUK

Ele detalha a metodologia para a construção da arquitetura do NEPOMUK, e considera dois aspectos importantes:
• A extração dos metadados do sistema proposto;
• A pesquisa de usabilidade nos estudos de caso propostos e realizada através de entrevistas com os potenciais utilizadores do SSD.

Funcionalidades do SSD:

  • Desktop;
  • Search (usa as relações semânticas, bem como as relações sociais para recuperar itens relevantes, e uma vez que um item for encontrado um usuário também pode encontrar itens relacionados.);
  • Social (Oferece diferentes meios de interação social, por exemplo, a incorporação de informação semântica em e-mails ou mensagens de texto, ou a habilidade para anotar os recursos dos outros usuários.);
  • Profiling (Registra a atividade do usuário para detectar o contexto do usuário atual e prever comportamentos do usuário);
  • Data Analysis (Raciocínio, a extração de palavras-chave, classificação e agrupamento).

Alguns dos principais aspectos da arquitetura são:
• A arquitetura é baseada em uma abordagem de mediadora para integração de componentes;
• A arquitetura é orientada a serviços para apoiar a integração de novos componentes independentes baseados em técnicas de comunicação padrão;
• A arquitetura é baseada em ontologias para apoiar a utilização da tecnologia semântica.

Realização da introdução do item Modelo Arquitetural do Modelo de arquitetura para solução de busca semântica no Expresso (definição, criadores, empresas envolvidas, objetivos, referência do projeto)

22 de março

Leituras complementares sobre a arquitetura do NEPOMUK.

Estudo do Processo de Desenvolvimento de Software da Prognus Software Livre e inicio da criação do primeiro DFD para o projeto, que se baseia em usuário com conhecimentos básicos e registrar uma ou mais DFD que atendam o usuário. 

23 de março

Criação das DFDS para os 3 tipos de Persona (Usuário Básico, Intermediário e Avançado) descrevendo a definição da demanda, os objetivos e as principais necessidades dos usuários.

24 de março

Ínicio da criação das DFDs baseadas em cada necessidade do usuário. Foi observado que para cada necessidade dos vários tipos de usuários, precisariam ser criadas novas DFDs:

-Realizar uma consulta básica -Visualizar a informação dos recursos relacionados -Marcar a informação dos recursos -Desmarcar a informação dos recursos -Salvar a consulta -Realizar uma consulta avançada.

E cada uma dessas DFDs podem gerar novas DFDs.

25 de março

Término da criação das DFDs baseadas nas necessidades dos usuários.

Início do detalhamento da arquitetura do NEPOMUK.

28 de março

Reunião pelo início da manhã para definir o planejamento do projeto com a redefinição das personas.

Auxiliei o adir na redefinição das personas (básicos, intermediários, avançados

Voltei para o detalhamento da arquitetura NEPOMUK.

29 de março

Término do detalhamento da arquitetura do NEPOMUK. concluiu-se que:

A arquitetura é baseada em um conjunto de serviços que fornecem as principais funcionalidades para o mapa mental do usuário. Esses serviços são divididos em duas categorias, a dos serviços de ajuda e a dos serviços de núcleo.

Os serviços de ajuda fornecem as funcionalidades para o processamento e manipulação dos dados semânticos e estão divididos em:

-Serviço de Recomendação;
-Alinhamento de Dados Local;
-Serviço de Análise de Texto;
-Contexto de Elicitação;
-Informação Integrada.

Os serviços de núcleo são necessários para a construção do desktop semântico e estão divididos em:

-Extrator de Dados;
-Pesquisa Local;
-Banco Semântico;
-Serviço PIM;
-Notificação.

Entendimento (leitura dos documentos e pesquisas) e Auxílio ao adir no Mapeamento das Funções do Expresso (email, contatos e compromissos. inicialmente não será feito o mapeamento do mensageiro instantâneo.)

30 de março

Esquema das telas do sistema com as novas funcionalidades. Para um usuário intermediário eu criei o protótipo de cada tela de mensagens, contatos e compromissos, para o usuário marcar com tags.

31 de março

Início detalhamento dos mapas mentais do usuário.

01 de abril

Término do detalhamento dos mapas mentais do usuário. Discussão sobre o planejamento do projeto com a definição das etapas. Correção de alguns pontos do Modelo Arquitetural no NEPOMUK. Pesquisas sobre indexação de dados e Apache Lucene.

Artigo interessante sobre a indexação de arquivos com Apache Lucene: Parte 1 e Parte 2

04 de abril

Pesquisas e Leituras sobre frameworks para pesquisa e indexação com ontologias - Solr, Nutch, Ontology Plugin

Correção da Elicitação de Contexto no Modelo Arquitetural

Leitura do PDF "A Semantic Web Application Framework" que propõe um framework para o desenvolvimento de aplicações para a Web Semântica.

Início do estudo de alguns projetos iniciados pelo adir em java.

05 de abril

Estudo da prova de conceito, do banco Virtuoso e execução de Queries SPARQL.

06 de abril

Leitura de alguns links:

07 de abril

Alteração das DFDs com base na nova definição das personas (Usuários com conhecimentos básicos, intermediários e avançados).

08 de abril

Criação do relatório sobre anotação semântica:

  • definição;
  • associação dos metadados com ontologias;
  • tipos (manuais, automáticas, hibrídas);
  • wikis semânticos;
  • conclusão sobre a utilização de anotações no projeto semântico do Expresso;

11 de abril

Revisão do Detalhamento das DFDs baseadas na definição das personas. Algumas das funcionalidades observadas e que geram uma nova DFD estão:

  • Suporte a consulta integrada dos recursos de comunicação
  • Suporte a visualização das informações relacionadas
  • Suporte a rotúlos para os recursos do Expresso
  • Suporte a remoção dos rotúlos para os recursos do Expresso
  • Suporte a criação de rotúlos
  • Suporte a consulta e recuperação de rotúlos
  • Suporte a manutenção de rotúlos (alterar e excluir)
  • Suporte a Armazenamento manual de consultas
  • Suporte a remoção dos itens dos resultados de uma consulta manual
  • Suporte a recuperação de consultas salvas
  • Suporte a consulta avançada

12 de abril

Continuação revisão DFDs. Observou-se que algumas funcionalidades precisam ser avaliadas:

  • Suporte a navegação entre os resultados da consulta dos recursos de comunicação do Expresso (?)
  • Suporte para desfazer a remoção da informação da consulta (?)
  • Suporte a classificação com estrelas (?)
  • Suporte a agrupamento de mensagens respondidas relacionadas a um mesmo assunto (?)

Avaliar as funcionalidades e a forma que serão executadas.

Início da correção do relatório sobre anotação semântica após revisão Edney. Criar Avaliação no relatório do Wiki Semântico.

13 de abril

Continuação correção do relatório sobre anotação semântica

  • Pesquisa sobre anotações em diferentes aplicações (modelo proposto por DAVIES E STUDIER NO LIVRO, através da avaliação de diferentes ferramentas para anotação como o KIM, aeroDAML, Amilcare, MnM e S-Cream - Avaliação do Parser PALAVRAS - Linked Open Data - Rich Snippers)
  • Conclusão com os objetivos a serem alcançados com o projeto e avaliação do wiki semântico como forma de anotação

14 de abril

Detalhamento do documento "Modelo de Telas", inicialmente separando, e depois descrevendo cada modelo de tela de acordo com a sua proposta.

As telas foram separadas nas seguintes categorias:

  • Telas de consulta unificada dos recursos
  • Telas para o suporte a rotúlos dos recursos
  • Telas para o armazenamento manual de consultas
  • Telas para a classificação dos recursos

18 de abril

Reunião com Edney e Adir e discussão sobre o detalhamento das DFDs.

Início do detalhamento das DFDS, com a criação de classes e métodos necessários.

  • DFD1 - Implementar o suporte ao usuário com conhecimentos básicos
  • DFD1 - Implementar o suporte para o armazenamento semântico
  • DFD2 - Implementar o espaço de descrição
  • DFD3 - Implementar a ativação do recurso semântico
  • DFD4 - Implementar a geração de carga semântica
  • DFD5 - Implementar o motor de busca
  • DFD6 - Implementar consulta unificada
  • DFD7 - Implementar o suporte a ontologias

19 de abril

Leitura dos artigos:

O artigo a “Conceptual Data Structures (CDS) Tools” do NEPOMUK traz a idéia de Estruturas de Dados Conceitual (CDS), que é um modelo de dados unificado para representação e gestão das informações pessoais dos usuários. Este modelo consiste em duas camadas: Camada de modelo de dados (SWCM), que descreve as entidade, e Camada de Ontologia, que que descreve as ontologias entres as relações, agrupando as relações estruturais entre os elementos de informação.

Como a ontologia CDS é representada em um modelo SWCM, a API do CDS é realizada como uma extensão da API SWCM (swecr.core), que oferece acesso para outras partes da persistência. A API swecr.core requer três serviços: Um mecanismo para armazenamento RDF com triplas, um mecanismo de pesquisa de texto completo e um mecanismo para armazenamento de dados binários. Existem duas implementaçoões da API do do swecr.core: A primeira implementação é baseada em Sesame, Lucene e BinStore?. A segunda implementação é baseada em RDF2GoRepository que se conecta via HTTP para um servidor em execução.

HKW (Hypertext-based Knowledge Workbench) é um protótipo desenvolvido por NEPOMUK, totalmente baseado nas idéias do CDS. HKW expõe todas as ideias do CDS para o usuário, e o protótipo visual iMapping estrutura as informações através de objetos visuais. O protótipo HKW foi projetado com base no feedback recolhido através da avaliação de alguns protótipos de wiki semântica: Semantic Pad, Kaukolu e Semantic MediaWiki? (SMW).

IMapping é a ferramenta para visualizar o conteúdo das informações estruturadas de uma forma intuitiva, através de objetos visuais. Os princípios fundamentais do design iMapping deduz um conjunto de critérios que devem ser satisfeitos, através de mapeamento cognitivo e instrumentos adequados, como por exemplo: Arrastar e colocar itens, Relações livres com a definição de links, Anotações, Macro Estrutura com visão geral do tema para pesquisa, Hypelinks, Edição Fácil, Integração de detalhes e contextos, e outros.

Muitas idéias do CDS partem de conceitos de wikis, que são editores rápidos para o conteúdo. O objetivo para uma próxima versão do CDS é integrar o Wiki sintaxe, que será usado para inserir texto, as estruturas e as declarações formais. O WikiModel?, um componente de código aberto desenvolvido pela Cognium Systems, é o modelo que será adotado como referência.

WikiModel? é um modelo de dados que define a estrutura de documentos wiki, com os elementos e suas regras de contenção (como um esquema XML para documentos XML). Contém uma API de acesso que fornece controle sobre a estrutura de documentos wiki. A utilização desta API garante que os documentos wiki acessados respeitem a estrutura definida pelo modelo. O WikiModel? pode ser usado como um motor de renderização para transformar várias sintaxes wiki para o conteúdo formatado (PDF, HTML, TEXT), ou analisador de anotações semânticas.

O artigo “Task Management Model” do NEPOMUK destaca diversas metodologias para o desenvolvimento de um modelo de gerenciamento de tarefas pessoais, que ajudam a entender melhor os problemas. Entre as várias metodologias estão a Teoria da Atividade (TA), que se centra na determinação da atividade entre sujeito e objeto. Sujeito geralmente é o usuário de um sistema de gerenciamento de tarefas que trabalha em conjunto com outros usuários em tarefas. Objeto geralmente é o resultado de uma atividade em determinados casos, com serviços relacionados. A Teoria da Coordenação (CT) destaca a gestão de dependências entre as atividades e mecanismos para a sua coordenação, com uma série de atores e interações. Por exemplo, uma tarefa padrão pode conter representações de dependências, as relações entre seus recursos (documentos, e-mails), sub-tarefas e atores que executarão as sub-tarefas. Teege (1996) caracterizou a atividade em três componentes: Sub-estrutura de atividades: uma atividade possui uma estrutura hierárquica de sub-atividades; Ator executor: Uma atividade é executada por um ator, que pode ser uma pessoa ou um grupo delas; Contexto: O contexto de uma atividade, por exemplo, contém informações necessárias, ou objetos que são alterados ou produzidos. Definiu ainda três tipos de apoio por parte do sistema de instâncias de atividades: Estruturação: contém a manutenção da estrutura da atividade, como as sub-atividades; História: recolhe informações sobre a atividade, que ajudam como proceder com a mesma; Execução: Execução de passos para apoio a execução das atividades;

Requisitos para o Modelo de Gestão de Tarefas

Foram realizados estudos de caso nos pacotes de trabalho WP8000 e WP11000, que definem o domínio de aplicação do projeto NEPOMUK. Este estudo tem por objetivo encontrar os requisitos funcionais necessários para criar o modelo de gestão de tarefas. Ambos os pacotes focam na gestão de tarefas, principalmente no contexto de gerenciamento de projetos.

Alguns requisitos funcionais em WP8000 foram considerados:

  • Marcação Semântica: Atribuição de metadados a um objeto, e marcação de imagens, web páginas, e-mails, para a Atribuição de palavras, frases ou seções do documento;
  • Marcação semi-automática: extração automática de metadados para as informações disponíveis;
  • Informação compartilhada e Notificação automática: Notificar automaticamente sobre alterações relevantes na informação compartilhada;
  • Representação, Visualização e análise: Relatório para geração de projetos, baseado na estrutura semântica do conteúdo, com análise dos documentos, geração de rascunhos e publicação de notas de pesquisa, gestão de workflows (Acompanhamento de tarefas, as experiências, projetos, pessoas e as relações entre eles), Disponibilidade de informações em dispositivos móveis;
  • Proteção a propriedade intelectual: Auditoria, sendo necessário saber quem modificou, e quando. Isso é importante para edição colaborativa e de proteção da propriedade intelectual cientifica.

WP11000 define diversos casos de uso para a gestão de tarefas, e baseado nestes casos de uso, requisitos funcionais são derivados para o sistema de NEPOMUK:

  • Apoio a e-mails: O sistema fornece suporte aos usuários estruturando sua caixa de correio eletrônico, bem como a criação de novos e-mails;
  • Nucleo de gestão de tarefas: A execução das tarefas é apoiada por um gerenciador de tarefas que ajuda a distribuir o trabalho entre os usuários da rede e que fomenta a comunicação entre eles.
  • Suporte para as tarefas do calendário: A execução das tarefas exige períodos de tempo em que isso pode acontecer
  • Suporte para tipos específicos de tarefas: A execução de tarefas específicas que se repetem regularmente pode ser suportado pela oferta de modelos que descrevem um padrão segundo o qual uma tarefa pode ser executada para orientar o usuário
  • Suporte Off-line para tarefas
  • Administração do Tempo: O tempo disponível dos usuários tem um papel central para a delegação de trabalho. O sistema verifica se o usuário tem tempo suficiente para trabalhar em uma tarefa;
  • Monitoramento de tarefas: monitorar o status das tarefas delegadas;
  • Comparar Informações Estruturadas: Os usuários podem comparar as estruturas relacionadas com certos tipos de informação para encontrar sobreposições. O objetivo é encontrar uma estrutura comum para ambas as partes.
  • Tarefas Colaborativas: A execução de determinadas tarefas exige a cooperação de vários usuários que trabalham em conjunto.

Foram definidas uma série de exigências em matéria de gestão de tarefas:

  • Suporte ao fluxo de trabalho pessoal: um serviço deve oferecer um assistente gráfico que permite aos usuários definir tarefas automatizadas que ele quer executar no computador. Essas tarefas devem ser emitida pelo usuário ou quando um determinado evento ocorre;
  • Suporte ao padrão de tarefas: o usuário deve ser capaz de definir padrões de tarefas para uma determinada atividade e para armazená-las no sistema para uso futuro;
  • Notificação de Requisitos: o usuário deverá ser capaz de expressar a notificação de requisitos que quer receber através de regras avançadas;
  • Recomendação contextual: Ao escrever algum documento, o sistema deverá propor recursos relacionados (documentos ou pessoas) que podem ser de interesse para o utilizador no contexto de sua atividade atual.

Requisitos funcionais relevantes

Baseado nos requisitos coletados em WP8000 e WP11000, foram definidas as principais funcões que são consideradas relevantes para um primeiro nivel de implementação para o modelo de gestão de tarefas: Criação de tarefas, Decomposição (definir sub-tarefas), Suporte a execução de tarefas, Padrões de tarefas (cria um modelo padrão que poderá ser seguido depois), Gestão de tempo (priorizar tarefas mais importantes), Monitoramento de tarefas, Histórico da tarefa/ auditoria, Suporte Offline. Os requisitos a seguir trazem algumas funções estendidas que não são consideradas como principais funções do gerenciamento de tarefas: Acesso a Tarefa (dispositivos moveis), Notificação automática e de regras, Recomendação contextual, Fornecimento de conteúdo e comparação, Anotação semântica, Suporte ao fluxo de trabalho pessoal e Integração dos processos organizacionais.

Modelo Conceitual para Gestão de Tarefas

Atividade/Ação?: Similar a Teoria da atividade (AT). Uma atividade possui um conjunto de ações a serem executadas, com um objetivo especifico no inicio. A ação possui uma duração fixa, está relacionada a um ator, que a executa, é mediada por ferramentas para executá-la, e é baseada em planos, que descrevem com os objetivos devem ser alcançados;

Tarefa: O conceito de tarefa é derivado do conceito de atividade. No entanto considerando que a ação centra-se na execução, a tarefa descreve uma ação projetada, ou seja, uma ação a ser executada.

Estrutura da tarefa: Uma tarefa que não é elementar, possui um elemento estrutural formado por um regime de sub-tarefas. A execução destas sub-tarefas faz parte da execução da tarefa.

O gerenciamento de tarefas é muitas vezes relacionado com uma troca de informações e recursos. Para este fim, a distinção entre:

  • unidades de informação (UI) - são tratados como entidades internas
  • unidades de recursos (RU) - são geralmente externos ao gerenciamento de tarefas, por exemplo, documentos formatados, modelos, etc

O TMO contém as definições das classes e relações, que são usados para construir o modelo de gestão de tarefas individuais. Assim, o TMO define a linguagem completa para ser utilizada para informações relacionadas às tarefas do NEPOMUK. Para representar a ontologia do modelo de tarefas foi utilizada a representação de linguagem do NEPOMUK (NRL), que é baseada em RDFS e introduz elementos adicionais, gráficos nomeados e definições de exibição. O TMO não existe isoladamente. Ele co-existe com as outras ontologias no SSD. PIMO reflete o domínio de um usuário SSD. O TMO é uma parte natural do PIMO, como o usuário está livre para representar, documentar e anotar, como informações sobre a tarefa da forma que achar adequada. No entanto, algumas das conceituações vão além do interesse pessoal.

Outras atividades:

Criação de classes e métodos necessários para gravação de dados semânticos de e-mails, contatos e compromissos.

20 de abril

Discussão sobre quais tecnologias utilizar para a criação das ontologias e extração dos metadados. Sugestão do framework Open Structs, que possuí o pacote structWSF para serviços web, com soporte a criação de ontologias, mecanismos de indexação (sorl) e armazenamento de dados RDF, mas o melhor de tudo é a implementação em PHP.

25 de abril

Leitura do artigo: “An integration site for Semantic Web metadata”, que apresenta o projeto e a implementação de SECO, um aplicativo que reúne e agrega dados da Web Semântica. Ele provem uma interface de consulta para consultar dados RDF, e atua como um mediador, agregando dados RDF e criando uma interface de usuário em HTML. O repositório de dados é composto por quatro diferentes conjuntos de dados RDF: O MetaModelo? contém os metadados extraídos sobre os arquivos, o SourceModel? contém as triplas RDF dos arquivos RDF na Web, o TargetModel? contém os dados limpos, e os UsageModel? contém os dados utilizados na interface do usuário. Os dados no MetaModel?, UsageModel?, e TargetModel? são especificados como ontologias São necessárias três etapas para criar código HTML baseado em RDF: Primeiro, uma ou mais consultas RDQL para os dados da interface do usuário são executadas. O resultado da consulta é formatado como um documento XML. Finalmente, este documento XML é transformado em uma página HTML usando uma orientação de estilo XSLT.

Leitura da documentação do StructWSF disponível neste link.

26 de abril

Criação do primeiro teste unitário da classe WebServiceQuerier?.php, utilizando o PHPUnit. O objetivo do teste foi verificar se a classe se conectava com o servidor corretamente, fazendo a leitura de um dataset e satisfazendo a determinados code retornados, que identificam possíveis excessões que podem ser tratados dentro de um domínio expecífico do problema, além de retornar também uma string com uma descrição. Para o início da realização desses Testes Unitários, foi necessário estudar a documentação do PHPUnit

27 de abril

Continuação dos testes unitários, agora para verificar primeiramente se a classe WebServiceQuerier?.php cria corretamente um dataset através dos parâmetros passados, não retornando nenhum code não desejado. Depois disso foi realizado outro teste para verificar se é realizada a operação CRUD create corretamente, avaliando os resultados através dos code retornados.

28 de abril

Leitura sobre a Ontologia Pimo, que explica que PIMO é tanto um vocabulário RDF para expressar o modelo mental do usuário, quanto uma ontologia superior para definição de classes e propriedades básicas para utilização. A Ontologia NRL (Representacional Layer) constrói a camada de representação e cria os metadados semânticos usados ​​para expressar PIMO (Personal Information Model). Um PIMO é um modelo de informações pessoais de uma pessoa, com a representação formal de algumas partes do Modelo Mental de usuário. Cada conceito no modelo mental pode ser representado usando uma Thing ou uma sub-classe dessa classe em RDF. Recursos encontrados no Workspace pessoal podem ser classificados, então eles são ocorrências de uma Thing. O NEPOMUK Expressa as ontologias (NIE) através de classes, propriedades, etiquetas e tags. A NIE descreve elementos de informação do desktop do usuário como contatos, documentos, e-mails e arquivos diversos. Subdivide-se em: NFCAL (Calendário), NCO (Contatos), NMO (E-mails) e NFO (Documentos). Segundo o modelo PIMO existem alguns passos para a sua implementação: Os mais importantes são a criação do espaço pessoal de cada usuário, com uma uri exclusiva, e a representação do modelo de informações pessoais do usuário, conectado ao usuário através de uma relação.

29 de abril

Início da criação das primeiras classes para a prova de conceito: DatasetConstructor? e ResourceConstructor?, baseadas no modelo DFD criado. O objetivo principal é a criação um dataset para o usuário e gravar um arquivo rdf ou n3. Leitura da documentação do n3 e turtle, para converter as declarações de turtle para rdf ou n3 (notation 3). Para validar o RDF utilizou-se o link.

Estrutura do arquivo rdf gerado:

<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:pimo="http://www.semanticdesktop.org/ontologies/pimo#" xmlns:nco="http://www.semanticdesktop.org/ontologies/nco#">

<pimo:Person rdf:about="ldap://ou=com.br,dc=prognus/eugenio@prognus.com.br#Eugenio">

<pimo:isDefinedBy rdf:resource="http://www.semanticdesktop.org/ontologies/pimo#" /> <nco:EmailAddress>eugenio@…</nco:EmailAddress>

</pimo:Person> <nco:EmailAddress rdf:about="http://www.semanticdesktop.org/ontologies/nco#hasEmailAddress" />

</rdf:RDF>

02 de maio

Terminei as classes DatasetRead? e DatasetConstructor?, conseguindo criar o dataset (ex_users):

<resultset> <prefix entity="wsf" uri="http://purl.org/ontology/wsf#"/> <prefix entity="void" uri="http://rdfs.org/ns/void#"/> <prefix entity="rdf" uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> <prefix entity="sioc" uri="http://rdfs.org/sioc/ns#"/> <prefix entity="dcterms" uri="http://purl.org/dc/terms/"/> <prefix entity="rdfs" uri="http://www.w3.org/2000/01/rdf-schema#"/> <subject type="void:Dataset" uri="ex_users"> <predicate type="dcterms:title"> <object type="rdfs:Literal">dataset_users_teste</object> </predicate> <predicate type="dcterms:description"> <object type="rdfs:Literal">dataset_users_teste</object> </predicate> <predicate type="dcterms:created"> <object type="rdfs:Literal">2011-05-3</object> </predicate> <predicate type="dcterms:creator"> <object type="sioc:User" uri="http://192.168.0.59/wsf/datasets/user-dataset/&amp;title=Edney&amp;description=Edney"/> </predicate> </subject> </resultset>

O arquivo RDF gravado no dataset (ex_users):

<resultset> <prefix entity="owl" uri="http://www.w3.org/2002/07/owl#"/> <prefix entity="rdf" uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> <prefix entity="rdfs" uri="http://www.w3.org/2000/01/rdf-schema#"/> <prefix entity="wsf" uri="http://purl.org/ontology/wsf#"/> <subject type="http://www.semanticdesktop.org/ontologies/pimo#Person" uri="ldap://ou=com.br,dc=prognus/edney@prognus.com.br#Edney"> <predicate type="http://www.semanticdesktop.org/ontologies/pimo#isDefinedBy"> <object type="rdfs:Literal">http://www.semanticdesktop.org/ontologies/pimo#</object> </predicate> <predicate type="http://www.semanticdesktop.org/ontologies/nco#EmailAddress"> <object type="rdfs:Literal">edney@…</object> </predicate> </subject> </resultset>

03 de maio

Documentação baseando em PhpDoc e tratamento de exceptions das Classes DatasetConstructor?, ResourceConstructor?, WSQDatasetCreateTest, WSQDatasetCrudCreateTest e WSQDatasetReaderTest.

04 de maio

Tentativa de consultar os dados do dataset crud, através do dataset/read. Ao passar os parametros para a classe WebServiceQuerier? obtém-se uma mensagem de erro: This dataset doesn't exist in this WSF. Tentativa em obter ajuda no grupo Open Semantic Framework.

05 de maio

Correção do bug do dataset/read (DatasetConstructor?) e crud/read (ResourceContructor?) que retornava a mensagem e erro: 400 Bad Request WS-DATASET-READ-304 /ws/dataset/read/ This dataset doesn't exist in this WSF. A solução foi mudar a passagem de paramêtros de array para uma string e no crud/read fazer um url encode na uri do recurso, como a seguir:

$parameters="uri=".urlencode("ldap://ou=com.br,dc=prognus/edney@prognus.com.br#Edney")."&dataset=ex_users&include_linksback=true&include_reification=true&registered_ip=$ip";

Foi feita a leitura do StructWSF Web Services Tutorial, que demonstra através de um caso de uso o registro de um endereço IP para acesso a determinados serviços WSF como browse, search, crud create etc. Uma vez que a instância structWSF está configurada, o administrador do sistema pode então começar a criar novas contas de usuário usando o AuthRegistrar?: http://192.168.0.59/ws/auth/wsf_indexer.php?action=create_user_full_access&user_address=192.168.0.64&server_address=http://192.168.0.59

Para setar os serviços da Web que ele pode ter acesso e liberar as permissões CRUD:

curl -H "Accept: application/json" "http://localhost/ws/auth/registrar/access/" -d "registered_ip=192.168.0.1&crud=False;True;False;False&ws_uris=http://localhost/wsf/ws/search/;http://localhost/wsf/ws/browse/;http://localhost/wsf/ws/crud/read/&dataset=http://localhost/wsf/datasets/1/&action=create" -v

Esboco de um novo modelo de datasets baseado nas sugestões de Mike Bergman e Frederick Giasson, do grupo Open Semantic Framework. A abordagem sugere que um dataset é semelhante a uma tabela de um banco de dados relacional, com uma chave primária exclusiva, que neste caso irá ser a uri. Cada recurso do expresso seria descrito em um dataset, então haveria:

  • dataset para e-mails;
  • dataset para contatos;
  • dataset para compromissos;
  • dataset para documentos;
  • dataset para usuários;
  • dataset para pimos(relacionamentos entre todos os recursos do usuário).

Outra sugestão foi para definir três conjuntos de dados diferentes: um privado, uma para colegas e um público. Esse acesso ao conjunto de dados pode ser definido através dos serviços do structWSF Auth Registrar: Access e Auth: Validator.

06 de maio

Definição da arquitetura do Expresso semântico com a integração do módulo de autenticação (Auth Express), que irá fazer o acesso ao banco de dados Postgress e verificar as permissões do usuário (phpgw_acl).

09 de maio

Definição do diagrama de sequência da prova de conceito, e alteração das classes DatasetConstructor? e ResourceConstructor?, com o objetivo de permitir a modelagem do usuário.

10 de maio

Solr utiliza Tika para fazer upload de arquivos e extrai-los, para depois indexar.

-Tika automaticamente tentará determinar o tipo de documento de entrada (pdf, palavra, etc) e extrair o conteúdo de forma adequada.

-Tika faz tudo por produzir um fluxo de XHTML que alimenta a um ContentHandler? SAX.

  • Solr então reage aos eventos do SAX Tika e cria os campos de índice.

-Tika produz Metadados da informação, tais como Título, Assunto, Autor e, de acordo com especificações como DublinCore?

-Todo o texto extraído é adicionado ao campo "content"

-Campos de metadados Tika podem ser mapeados aos campos Solr

Extrair um arquivo:

curl "http://localhost:8983/solr/update/extract?literal.id=doc1&commit=true" F "myfile = @ tutorial.html"

literal.id=doc1 : fornece a única identificação necessária para o documento a ser indexado

commit=true : faz um commit após a indexação do documento, tornando ele imediatamente procurável.

Consultar: http://localhost:8983/solr/select?q=tutorial

Exemplo de configuração:

<requestHandler name="/update/extract" class="org.apache.solr.handler.extraction.ExtractingRequestHandler?">

<lst name="defaults">

<str name="fmap.Last-Modified">last_modified</str>

<str name="uprefix">ignored_</str>

</lst>

<!--Optional. Specify a path to a tika configuration file. See the Tika docs for details.-->

<str name="tika.config">/my/path/to/tika.config</str>

<!-- Optional. Specify one or more date formats to parse. See DateUtil?.DEFAULT_DATE_FORMATS for default date formats -->

<lst name="date.formats">

<str>yyyy-MM-dd</str>

</lst>

</requestHandler>

tika.config -> contem informacoes sobre parsers, mime type, etc

solr.xml -> configurações do Solr

Além dos metadados Tika, o Solr acrescenta os seguintes metadados (definido no ExtractingMetadataConstants?):

"STREAM_NAME" - O nome do ContentStream? como enviados para Solr.

"Stream_source_info" - Qualquer informação sobre a origem do fluxo. (ContentStream?).

"Stream_size" - O tamanho do fluxo de bytes (?)

"Stream_content_type" - O tipo de conteúdo do fluxo, se disponível.

Mapeamento, captura e Boost:

curl "http://localhost:8983/solr/update/extract?literal.id=doc3&captureAttr=true&defaultField=text&capture=div&fmap.div=foo_txt&boost.foo_txt=3" -F "tutorial=@tutorial.pdf" curl "http://localhost:8983/solr/update/extract?literal.id=doc3&captureAttr=true&defaultField=text&capture=div&fmap.div=foo_txt&boost.foo_txt=3" F "tutorial = @ tutorial.pdf"

Esta é a implementação completa de uma classe que usa ContentStreamUpdateRequest? para enviar dados para o ExtractingRequestHandler?:

ContentStreamUpdateRequestExample

11 de maio

Apresentação da arquitetura do Expresso pela parte da manhã, com discussão sobre o Datawapper, e quais a melhores formas de realizar a sua otimização, a fim de evitar um over-read (definir um algoritmo que execute tantas requisições possíveis em determinados horários).

12 de maio

Estudo do Chapter 2: Schema and Text Analysis do tutorial Solr 1.4 Enterprise Search Server. Explica como mapear as tabelas do banco de dados de metadados de música do projeto MusicBrainz?, para o arquivo schema.xml e descreve todas a propriedades e atributos utilizadas para montar o schema.

13 de maio

Estudo de Email Entity Processor e Data Import Handler, com o objetivo de indexar e-mails do protocolo IMAP, e usar um arquivo RDF para isso.

16 de maio

Alteração da classe MailEntityProcessor?, com o objetivo de criar um arquivo RDF através da biblioteca JENA com os dados disponíveis pelo IMAP. Além disso criou a classe Nmo, que define o modelo de ontologias para e-mails do NEPOMUK.

Principal função alterada:

public void addPartToDocument(Part part, Map<String, Object> row,

boolean outerMost) throws Exception {

LOG.info("addPartToDocument()"); if (part instanceof Message) {

LOG.info("part instanceof Message"); addEnvelopToDocument(part, row);

} Logger logger = LoggerFactory?.getLogger(MailEntityProcessor?.class); Model m = ModelFactory?.createDefaultModel();

Resource res = m.createResource(row.get(MESSAGE_ID).toString(), Nmo.Email);

res.addProperty(Nmo.from, row.get(FROM).toString()); res.addProperty(Nmo.to, row.get(TO_CC_BCC).toString()); res.addProperty(Nmo.cc, m.createLiteral("prognus@…")); res.addProperty(Nmo.messageSubject, row.get(SUBJECT).toString()); res.addProperty(Nmo.plainTextMessageContent, m.createLiteral("Bom dia a todos eu gosto muito de voces!")); res.addProperty(Nmo.receivedDate, m.createLiteral("2011-05-17")); res.addProperty(Nmo.sentDate, row.get(SENT_DATE).toString()); Nmo.from.getLocalName();

try {

RDFWriter w = m.getWriter(); w.setProperty("allowBadURIs", "true"); LOG.error("GRAVANDO ARQUIVO RDF"); w.write(m, new FileWriter?("xuripinha.rdf"), null); LOG.info(m.getGraph().toString());

} catch(Exception e) {

e.printStackTrace();

}

17 de maio

Debugging e Logger da classe MailEntityProcessor? através do ant dist. Correção de alguns problemas.

18 de maio

Definição do modelo para DataWrapper?, com os comandos da fila armazenados em uma tabela semantic_queue do PGSQL com os seguintes campos:

  • id
  • command
  • priority
  • date (datetime)
  • pct_completed
  • error

Para a Extração dos E-mails, Contatos e Compromissos serão criados plugins específicos para cada caso.

19 de maio

Construção da classe DataWrapper?, que faz a comunicação com a fila e plugins do expresso, para posteriormente enviar o arquivo RDF gerado ao StructsWSF.

Principais métodos:

  • writeCommand($fields) - Responsável por gravar o comando na fila
  • readCommand() - Responsável por ler o comando e fazer a chamada ao método callPlugin
  • updateCommand($id, $code) - Método responsável por atualizar comandos na fila.
  • deleteCommand($id) - Método responsável por excluir comandos na fila.
  • callPlugin($command, $id) - Método responsável por por identificar e instanciar a classe responsavel por tratar os dados de emails, contatos, compromissos.
  • saveRDFData($id, $document, $datasetName) - Métodos responsável por enviar o RDF para o StructsWSF.

20 de maio

Realização de Testes na classe criada e correção dos erros encontrados.

23 de maio

Teste Unitário e utilização do code coverage para a classe TestDataWrapper?.

24 de maio

Criação da classe ProcessConfig? através da utilização do framework Zend, para a leitura do arquivo config.xml, onde serão armazenados os dados de configuração do Expresso Semântico.

25 de maio

Adapatação da classe DataWrapper? para instaciar a classe ProcessConfig? e realização de testes unitários.

26 de maio

Início da criação do plugin para extração de contatos do Postgress e Ldap (classe ContactWrapper). Foram feitos os relacionamentos das tabelas do banco, recuperando os atributos necessários para realizar a extração

27 de maio

Início da descrição dos dados recuperados dos contatos através da ontologia do NEPOMUK. Utilização das classes criadas através da biblioteca Arc2.

30 de maio

Continuação da descrição através da ontologia.

31 de maio

Término do plugin para contatos e realização de Testes Unitários.

01 de junho

Início da criação do plugin para extração de compromissos do Postgress (classe CalendarWrapper), e descrição dos dados através da ontologia.

02 e 03 de junho

Continuação e Término do plugin para compromissos e realização de Testes Unitários.

06 a 14 de junho

Ajustes nos plugins para Contatos e Compromissos (Classes ContactWrapper e CalendarWrapper):

  • Estudo as Ontologias Nco e Ncal
  • Recuperação de um e vários usuários do Ldap
  • ajuste na SQL das tabelas de contatos, para recuperar um contato caso o mesmo não tenha endereço, email, telefone ou grupos.
  • descrição de imagens do contato (nexif:Photo)
  • descrição de endereço do contato através da ontologia (nco:PostalAddress)
  • descrição de grupos do contato através da ontologia (nco:ContactGroup)
  • descrição do sexo do contato (nco:Gender)
  • descrição de um participante do Calendario (ncal:Attendee)
  • Descrição dos usuários do Ldap (Person) como um contato (nco:Contact)
  • realização de testes unitários e covegare para as classes descritas (classes TestContactWrapper e TestCalendarWrapper).
  • Documentação das classes descritas.

Ao instanciar as classes ContactWrapper e CalendarWrapper deve-se chamar o método init(ID_USER_LDAP) passando como parâmetro o id do usuário no LDAP. Este método chama a função getAllCalendarsFromDb(ID_USER_LDAP) para Calendar e getAllContactsFromDb(ID_USER_LDAP) pra contacts. O retorno dessas funções são um array contendo as linhas do banco de dados, que serão passadas através da função describeCalendar(ARRAY_LINHAS_BD, ID_USER_LDAP, URI_USER_PIMO) para calendars e describeContact(ARRAY_LINHAS_BD, ID_USER_LDAP) para contacts, com o objetivo de descreve-los através da ontologia e gerar o arquivo RDF a ser persistido pelo BD Virtuoso.

Observações:

  • Algumas partes do código deverão ser modificadas futuramente.
    • (1) A descrição da PIMO do usuário, que atualmente encontrasse no método init() das classes ContactWrapper e CalendarWrapper deverá ser colocada junto com a funcionalidade de ativar semântica para o usuário.
    • (2) Os usuários do Expresso existentes até o momento, deverão ser descritos uma unica vez, na inicialização semântica (executada provavelmente pelo administrador)
    • (3) Os usuários do Expresso existentes até o momento, deverão também ser descritos como um contato, (utiliza-se método getAllContactsFromLdap).
    • (4) Após isso, cada usuário descrito deverá ser ligado ao seu contato através de um GroundingOcurrence? com a uri. Isso atualmente também é feito no metodo init() da classe.

(1)

$this->userUri = $this->userUri . $userID . "#";

$this->userPrefix = $this->userPrefix.md5($userID);

$userPerson = $this->model->resource($this->userUri.'User', 'pimo:Person');

$userPIMO = $this->model->resource($this->userUri.'PIMO', 'pimo:PersonalInformationModel');

$userPerson->addStatement('pimo:isDefinedBy', $userPIMO);

$userPIMO->addStatement('pimo:creator', $userPerson);

$userPIMO->addStatement('nao:hasDefaultNamespace', $this->userUri);

$userPIMO->addStatement('nao:hasDefaultNamespaceAbbreviation', $this->userPrefix);

(2) e (3)

require_once("ContactWrapper.php");

$cw = new ContactWrapper();

$rsContact = $cw->getAllContactsFromLdap();

if($rsContact){

foreach($rsContact as $key=>$linha){

$userContact->addStatement('nco:contactUID', $linha[uid][0]);

$userContact->addStatement('nco:nameGiven', $linha[givenname][0]);

$userEmail = $this->model->resource(, 'nco:EmailAddress');

$userEmail->addStatement('nco:emailAddress', $linha[mail][0]);

$userContact->addStatement('nco:hasEmailAddress', $userEmail);

$userPerson = $this->model->resource( $linha[uidNumber][0].'User', 'pimo:Person');

}

}

(4)

$userPerson->addStatement('pimo:groundingOccurrence', $uriContact);

Sugestões:

  • Quebrar ontologias em metodos especializados, como por exemplo no método describeContact da classe ContactWrapper, que descreve todos os dados de um contato, incluido e-mails, endereços e grupos. A sugestão é quebrar o método em outros métodos para descrever e-mails, endereços e grupos.
  • Deve-se verificar os atributos descritos no ldap para descrever o usuario e que não estão presentes no Ldap expressodev, como por exemplo, dados de telefone.

Attachments