módulos de inferência na nuvem de dados ligados
Transcrição
módulos de inferência na nuvem de dados ligados
CRISTIANO EXPEDITO RIBEIRO MÓDULOS DE INFERÊNCIA NA NUVEM DE DADOS LIGADOS PARA APOIAR O DESENVOLVIMENTO DE APLICAÇÕES RIO DE JANEIRO 2012 CRISTIANO EXPEDITO RIBEIRO Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Informática da Universidade Federal do Rio de Janeiro, como requisito parcial à obtenção do título de Mestre em Informática. Orientadora: Prof.ª Dr.ª Adriana Santarosa Vivacqua Rio de Janeiro 2012 R484 Ribeiro, Cristiano Expedito Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. / Cristiano Expedito Ribeiro. – 2012. 203 f.: il. Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti, Programa de Pós-Graduação em Informática. Orientadora: Adriana Santarosa Vivacqua 1. Módulos de Inferência. 2. Nuvem de Dados. 3. Nuvem para Apoio e Desenvolvimento de Aplicações – Teses. I. Vivacqua, Adriana Santarosa (Orient.). II. Universidade Federal do Rio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti, Programa de Pós-Graduação em Informática. III. Título CDD Agradecimentos Agradeço à minha mãe Tania, à minha avó Zenith (in memoriam) e ao meu tio Sérgio que me estimularam em minha formação acadêmica, e à minha irmã Christina. À minha orientadora Adriana S. Vivacqua, expresso meu profundo agradecimento por seu empenho e pelos conselhos nos momentos mais críticos do trabalho. Aos professores Daniel Schwabe (DI-PUC-Rio) e Maria Luiza Machado Campos (PPGI-UFRJ) pela gentileza de comporem a banca examinadora e pelas estimadas contribuições. Meus agradecimentos especiais aos professores do PPGI, Jonice Oliveira, João Carlos e Marcos Borges pelas suas colaborações pontuais, mas extremamente úteis nos seminários. Aos meus colegas e amigos de mestrado e laboratório, Augusto, Biancas Lima e Pereira, Bruno Nascimento, Diego, Evelyn, Fábio, Fabrício Firmino, Inês Boscá, João Vítor, Patrícia, Rafael Escalfoni, Rogers Reiche, Ruben Perorazio e Tiago Marino, pelo auxílio, companheirismo e descontração em diversos momentos desta trajetória, e também aos meus amigos da graduação, chefes e colegas de trabalho. Finalmente, deixo meus agradecimentos à Universidade Federal do Rio de Janeiro (UFRJ) e ao Programa de Pós-Graduação em Informática (PPGI) que me receberam em suas dependências, e ao CNPq (Conselho Nascional de Desenvolvimento Científico e Tecnológico) pelo suporte financeiro oferecido para apoiar o desenvolvimento desta dissertação. Resumo RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012. Computação ubíqua e pervasiva se caracterizam por sistemas computacionais embarcados no ambiente, capazes de interagir amigavelmente com o usuário, reconhecendo e se adaptando ao meio. Contudo, para isto se tornar realidade, é necessário entender o contexto no qual estas interações ocorrem. Alguns middlewares para auxiliar o desenvolvimento de aplicações cientes de contexto (CC) foram propostos, mas ainda não surgiu um realmente efetivo quanto à aplicabilidade no mundo real. Além disso, dados de contexto devem ser representados em um formato reutilizável e interoperável que permita compartilhamento, comunicação e reuso, pois aplicações CC precisam integrar informações oriundas de sensores locais e remotos, bases de dados e de contexto. O objetivo deste trabalho é aproveitar tecnologias padronizadas da Web Semântica e de Linked Open Data (LOD) como formatos, ontologias e linguagens de consultas para atender estas necessidades. Para tanto, propomos a arquitetura LOUD e neste trabalho enfocamos o módulo de inferência, capaz de ser facilmente configurado para consumir, processar e publicar triplas RDF, fazendo consultas a SPARQL endpoints e gerando seu próprio endpoint com novos dados que são produzidos por inferência OWL-DL e/ou regras. Estes módulos podem ser organizados hierarquicamente ou em rede para produzir contextos com níveis mais altos de abstração. Para mostrar a viabilidade de se produzir aplicações utilizando este módulo, foram implementados três cenários e, posteriormente, um deles foi levado para experimentos com alunos que configuraram uma pequena rede de módulos e fizeram uma avaliação através de um questionário. Os resultados foram satisfatórios, pois apesar de alguns alunos apresentarem dificuldades, foi relatada que a configuração é simples, detalhada e flexível, a execução é fácil e consultas são simplificadas para o consumidor final. Palavras-chaves: Linked Open Data, Web Semântica, contexto, ciência de contexto, inferência, ontologias Abstract RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012. Ubiquitous and pervasive computing are characterized by computational systems embedded into the environment, able to interact with the user friendly, recognizing and adapting to the environment. However, for this to become reality, it is necessary to understand the context in which these interactions occur. Some middleware to support the development of context-aware applications (CC) have been proposed, but no one has emerged as really effective with respect to the applicability in the real world. Moreover, context data should be represented in a reusable and interoperable format that allows sharing, communication and reuse as CC applications need to integrate information from local and remote sensors, bases of data and context. Our objective is to leverage standard technologies of the Semantic Web and Linked Open Data (LOD) like formats, ontologies and query languages to meet these needs. To this end, we propose the LOUD architecture and we focus on the inference module, which is able to be easily configured to consume, process and publish RDF triples, making queries to SPARQL endpoints and generating its own endpoint with the new data that are produced by inference using OWL-DL and/or rules. These modules can be organized hierarchically or as a network to produce contexts with higher levels of abstraction. To show the feasibility of producing applications using this module, three scenarios were implemented and, later, one was led to experiments with students who have set up a small network of modules and made an assessment using a questionnaire. The results were satisfactory, because although some students had presented difficulties, it was reported that the configuration is simple, comprehensive and flexible, execution is easy and queries are simplified for the end consumer. Keywords: Linked Open Data, Semantic Web, context, context awareness, inference, ontologies Lista de Figuras Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior uma notação de conjuntos e na inferior as dimensões grau de mobilidade e de embarcamento em eixos ortogonais. ............................................................................ 21 Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação, à forma de obtenção, à visibilidade e à taxa de atualização. ......................................... 27 Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅. ........ 46 Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações imprevistas no TBox. ..................................................... 53 Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005). ........................................... 60 Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003) ..................... 61 Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como produtores e consumidores. Entradas para configuração dos módulos foram omitidas. ..................................................................................................................... 68 Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação bidirecional) é representada para fins didáticos, pois a base pode conter triplas virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a leitura sobre Jena e Pellet na seção 2.3.2). .............................................................................. 74 Figura 9. Diagrama de atividades do módulo de inferência ................................................... 78 Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado. ............................................................................................................ 82 Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule. ........... 84 Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader. ................................................................................................................. 85 Figura 13. Hierarquia mais externa dos elementos XML de configuração. ............................ 89 Figura 14. Elementos XML para configuração de carregadores e substituidores de variáveis (binders)....................................................................................................... 90 Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD. ..................................................................................... 93 Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD....................................................................... 96 Figura 17. Lista de Resultados na aplicação protótipo desenvolvida. .................................. 101 Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) ....................... 104 Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o mapeamento entre conceitos. ........................................ 107 Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o mapeamento entre conceitos ......................................... 108 Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento. ............ 113 Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas. ............... 114 Figura 23. Diagrama das ontologias de tempo e eventos utilizadas. .................................... 119 Figura 24. Diagrama de classes da ontologia de relações entre pessoas. .............................. 120 Figura 25. Diagrama de hierarquia de propriedades da ontologia de relações entre pessoas...................................................................................................................... 120 Figura 26. Ontologia de transporte por ônibus. ................................................................... 122 Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus. ...................................................................................................................... 124 Figura 28. Rede social dos usuários do endpoint USNLE. .................................................. 128 Figura 29. Estrutura interna do endpoint BLE. ................................................................... 130 Figura 30. Rede de módulos de inferência para notificações sobre eventos (números ao lados de módulos indica quantidade de regras usadas). .............................................. 131 Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações. ......... 132 Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b). .................... 134 Figura 33. Histogramas das respostas globais. .................................................................... 138 Figura 34. Resultados do teste presencial com alunos. ........................................................ 139 Figura 35. Teste remoto com alunos em pesquisa de tese. .................................................. 140 Figura 36. Resultados do teste remoto com alunos da disciplina. ........................................ 141 Figura 37. Mediana das respostas das três primeiras partes do questionário conforme valores atribuídos a cada resposta (quanto mais próximo do valor máximo melhor). .................................................................................................................... 142 Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita) ..................................................................................................................... 170 Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath. .................... 173 Figura 40. Estrutura interna do endpoint BLE .................................................................... 185 Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto. ......................................................................................... 186 Lista de Quadros e Tabelas Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN, C., 2004) ..................................................................................................................... 29 Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010) .......................... 32 Quadro 3. Lista de expressividade de diversas DLs atuais. ................................................... 48 Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam. ........................................................................................................... 55 Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam ............................................................................................................ 56 Quadro 6. Comparativo das arquiteturas. .............................................................................. 65 Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas. .............................. 87 Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008) ...................................... 104 Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011) ........................................................................................ 105 Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos .............. 106 Tabela 11. Exemplos de resultados da consulta ao M4: atraso pequeno (acima) e pouco mais significativo (abaixo). ....................................................................................... 115 Quadro 12. Datas comemorativas utilizadas no endpoint CDE com as respectivas classes e datas. .......................................................................................................... 126 Quadro 13. Localização atual e destino desejado dos usuários do USNLE. ......................... 128 Quadro 14. Consultas e regras removidas em cada módulo; competências testadas e grau de dificuldade para cada etapa. .......................................................................... 134 Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em RAs (2010) ............................................................................................................... 171 Lista de Siglas API Application Programming Interface CBMERJ Corpo de Bombeiros Militar do Estado do Rio de Janeiro CC Ciente de Contexto CML Context Modelling Language DL Description Logic ETL Extraction, Transformation, Loading FOAF Friend Of A Friend GEO-RIO Fundação Instituto de Geotécnica do Município do Rio de Janeiro GPS Global Positioning System HTTP(S) Hypertext Transfer Protocol (Secure) KML Keyhole Markup Language LD Lógica de Descrição LOD Linked Open Data / Dados Abertos Ligados LOV Linked Open Vocabularies MVO Mapeamento Vocabulário-Ontologia MIO Mapeamento Inter-Ontologias N3 Notation 3 OD Ontologia de Domínio ORM Object-Role Modelling OWL Web Ontology Language RA Região Administrativa REST Representational State Transfer RCC Region Connection Calculus RDF Resource Description Framework SWRL Semantic Web Rule Language UBICOMP Ubiquitous Computing / computação ubíqua URI/L Uniform Resource Identifier/Locator W3C World Wide Web Consortium WGS84 World Geodetic System 1984 WS Web Semântica Sumário 1 2 Introdução ..................................................................................................................... 15 1.1 Motivação ............................................................................................................ 15 1.2 Contextualização do Problema ............................................................................. 15 1.3 Problema específico ............................................................................................. 17 1.4 Objetivo ............................................................................................................... 18 1.5 Contribuição ........................................................................................................ 19 1.6 Estrutura da dissertação ........................................................................................ 19 Referencial Teórico ....................................................................................................... 20 2.1 Computação ubíqua e contexto: definições ........................................................... 20 2.2 Aquisição, classificação e modelagem de contexto ............................................... 23 2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores ....... 23 2.2.2 Classificações de contexto ........................................................................ 25 2.2.3 Classificações de aplicações cientes de contexto ....................................... 27 2.2.4 Comparações entre modelos de contexto ................................................... 28 2.2.5 Ontologias de modelagem de contexto ...................................................... 33 2.3 Web Semântica e Dados Ligados ......................................................................... 37 2.3.1 Conceitos básicos ..................................................................................... 38 2.3.2 Lógica de Descrição (DL) ......................................................................... 41 2.3.3 Web Ontology Language (OWL) .............................................................. 53 2.3.4 Trabalhos de publicação em LOD ............................................................. 57 2.4 Trabalhos relacionados......................................................................................... 58 2.4.1 Frameworks para aplicações cientes de contexto ....................................... 58 2.4.2 Arquiteturas para integração de dados na Web .......................................... 65 3 LOUD – Linked Open Ubiquitous Data ........................................................................ 67 3.1 Introdução ............................................................................................................ 67 3.2 Arquitetura LOUD ............................................................................................... 67 3.2.1 Objetivos .................................................................................................. 67 3.2.2 Estrutura ................................................................................................... 67 3.3 Escopo do trabalho: o Módulo de Inferência ........................................................ 73 3.3.1 Estrutura ................................................................................................... 73 3.3.2 Implementação ......................................................................................... 80 3.3.3 Configuração ............................................................................................ 87 4 Cenários de Aplicação ................................................................................................... 92 4.1 Cenário 1: informação sobre hidrantes durante um incêndio ................................. 92 4.1.1 Modelagem e construção da camada de dados ........................................... 93 4.1.2 Camada de inferência para integração das bases ........................................ 96 4.1.3 Aplicação de consumo e considerações ..................................................... 99 4.2 Cenário 2: alertas sobre chuvas e escorregamento de terra .................................. 102 4.2.1 Domínio da aplicação e modelagem ........................................................ 103 4.2.2 Camada de dados e sensoriamento .......................................................... 106 4.2.3 Camada de inferência.............................................................................. 109 4.2.4 Discussão ............................................................................................... 116 4.3 Cenário 3: notificação sobre eventos sociais e chegadas de ônibus ..................... 117 4.3.1 Domínio da aplicação e modelagem ........................................................ 118 4.3.2 Camada de dados e sensoriamento .......................................................... 124 4.3.3 Camada de inferência.............................................................................. 130 4.3.4 Visualização das notificações em navegador Web ................................... 132 5 Experimentos e Resultados.......................................................................................... 133 5.1 Formato do experimento .................................................................................... 133 5.2 Avaliações dos alunos ........................................................................................ 135 5.2.1 Alguns dados quantitativos ..................................................................... 136 5.2.2 Avaliações qualitativas ........................................................................... 143 6 Considerações finais.................................................................................................... 147 6.1 Retrospectiva ..................................................................................................... 147 6.2 Estudo de viabilidade e experimentos realizados ................................................ 148 6.3 Contribuições e aspectos positivos ..................................................................... 150 6.4 Problemas e limitações ....................................................................................... 151 6.5 Trabalhos futuros ............................................................................................... 153 Referências ........................................................................................................................ 155 Apêndices .......................................................................................................................... 165 Apêndice A – Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE) ......... 165 Apêndice B – Cenário 2: implementação da geração de coordenadas e mapeamento D2R para User Locations Endpoint (ULE) ................................................................................. 167 Apêndice C – Cenário 2: implementação da configuração dos módulos ....................... 174 Apêndice D – Cenário 3: implementação, mapeamento e configuração dos módulos para Bus Locations Endpoint (BLE) .......................................................................................... 185 Apêndice E – Cenário 3: Configuração dos módulos da camada de inferência ............. 190 Apêndice F – Questionário passado aos alunos e respostas na íntegra .......................... 199 15 1 1.1 Introdução Motivação O surgimento de celulares menores, mais leves e baratos vem proporcionando aumento de acessibilidade e maior facilidade de comunicação. Mais recentemente, a disseminação de dispositivos móveis que utilizam formas variadas de comunicação sem fio (Bluetooth e Wi-Fi, por exemplo) e o surgimento dos Smartphones (que permitem expansão de suas funcionalidades) fornecem grandes oportunidades tanto para usuários quanto para fabricantes e desenvolvedores. Esta evolução traz novas questões, pois o usuário passa a requisitar conteúdo (inclusive da Web) que satisfaça suas necessidades momentâneas e de forma imediata (RICCI, 2011). Nestas circunstâncias, surge a necessidade de um modelo ciente de contexto (CC) o que remete às ideias de Computação Ubíqua de Mark Weiser (WEISER, 1991). No entanto, a área de computação ciente de contexto ainda enfrenta grandes desafios para o desenvolvimento de tais aplicações. Paralelamente, iniciativas de tornar a Web Semântica (WS) uma realidade vêm ganhando força (BIZER, 2009), e acredita-se que podem ser de grande utilidade no cenário da computação ubíqua. A WS tem por objetivo atribuir significado ao conteúdo da Web, tornando-a manipulável por máquinas. Para isso, usa vocabulários, ontologias e regras que sigam um padrão de fato (BERNERS-LEE et al., 2001). A adoção destes padrões parece resolver muitos dos problemas que serão descritos nas próximas seções. 1.2 Contextualização do Problema Apesar de o desenvolvimento de aplicações CC ser uma área pesquisada há bastante tempo e várias arquiteturas ou middlewares terem sido propostos para tentar facilitar e agilizar este processo, nenhuma delas foi efetiva quanto à aplicabilidade no mundo real, necessitando de mais pesquisas científicas (YU et al., 2010). Além disso, a maioria destas arquiteturas foi construída para domínios específicos não podendo ser usada de forma corriqueira (HU et al., 2009). Adicionalmente, a maioria das pesquisas em computação ubíqua tem focado em ambientes ad hoc com protocolos e infraestruturas proprietárias e serviços CC não costumam focar na interoperabilidade entre sistemas, dispositivos e serviços (LU et al., 2012). 16 É necessário que dados de contexto sejam representados em um formato sintatica e semanticamente reutilizável e interoperável para permitir compartilhamento e reuso (PERTTUNEN et al., 2009). Esta necessidade decorre do fato de que aplicações CC frequentemente precisam integrar informações oriundas de sensores, bases de dados e fontes de contextos externos, que ao adotarem variados formatos, protocolos, esquemas, taxonomias e vocabulários, dificultam a interoperabilidade e, consequentemente, o reaproveitamento (reutilização) de informações úteis já existentes. Serviços CC geralmente não permitem que aplicações CC sejam interoperáveis por meio de tais modelos de contextos comuns (HERVÁS; BRAVO, 2011). Contudo, esta interoperabilidade entre dispositivos e serviços é um importante e difícil desafio em ambientes pervasivos, incluindo cientes de contexto, porque dependem de diferentes modelos de interação e informação (BRØNSTED et al., 2010). Todos estes fatores prejudicam a produtividade destas aplicações. A interoperabilidade desejada pode ser obtida com tecnologias da Web Semântica (HERVÁS; BRAVO, 2011). O uso de ontologias para criação de modelos de contexto é promissor para atender estes requisitos (STRANG; LINNHOFF-POPIEN, C., 2004). Contudo, até modelos e arquiteturas de contexto baseados em ontologias apresentam dificuldades em reaproveitá-las para permitir interoperabilidade entre módulos de sistemas distintos. Cada uma das arquiteturas pesquisadas, como SOCAM (GU et al., 2005), CoBrA (CHEN, HARRY et al., 2003), iTransIT (LEE; MEIER, 2009) e COSAR (RIBONI; BETTINI, 2011a), entre outras, utiliza sua própria ontologia e, em geral, não utilizam um protocolo de comunicação comum. Segundo os autores do CoBrA, a maior deficiência de sua abordagem é a “inabilidade de reusar outras ontologias consensuais” que “requer maior sobrecarga no projeto e engenharia de ontologias” e que “pode reduzir a interoperabilidade”. Mesmo que houvesse uma ontologia unificada para tratamento de contexto ou que todas as existentes tivessem mapeamento entre si, o modelo ontológico não é eficaz nem eficiente para todas as necessidades da computação CC (BETTINI et al., 2010). Muitas delas requerem outras técnicas de inteligência articial ou estatística, inclusive para tratamento de dados de sensores, que geralmente são incertos, ambíguos e até mesmo conflitantes. Desta forma, ontologias são geralmente usadas para descoberta de conhecimento implícito em um nível mais alto e para validação de bases de conhecimento por utilizarem processos mais formais quanto à semântica. Surge, então, a questão sobre como permitir interoperabilidade entre estes sistemas heterogêneos, ou seja, com diversos tipos de modelos de contexto. 17 Resumidamente, se for necessário que, ao construir uma aplicação, o projetista crie seu próprio modelo de contexto, por exemplo, ontologias e regras (pouca reutilização), e/ou o desenvolvedor precise construir conversores para comunicação e interoperabilidade com módulos externos (que utilizem modelos de contexto ontológicos ou não) há um prejuízo à produtividade. Além do mais, mesmo adotando padrões da WS, as bases de dados e fontes de contexto podem utilizar vocabulários e ontologias distintos que podem ainda prejudicar a interoperabilidade se não houver uma forma padronizada de comunicação e de mapeamento entre seus elementos. Portanto, faz-se necessário a criação de uma arquitetura distribuída na Web que forneça mecanismos de comunicação entre diversas fontes de dados e de inclusão de regras tanto para mapeamento de conceitos quanto para inferência de contexto. Estes mecanismos precisam ser interoperáveis e reutilizáveis para proporcionar melhoras na produtividade no desenvolvimento de aplicações CC. Assim, o problema geral concentra-se em três conceitos interligados: interoperabilidade, reutilização e produtividade. 1.3 Problema específico Neste trabalho, pretende-se tratar tanto a interoperabilidade entre bases que provêem dados contextuais, quanto reutilização de suas ontologias, regras de inferência e dados. Como discutido na seção anterior, usar padrões e princípios da WS parece ser uma possível solução por diversos motivos. A possibilidade de criação de ligações entre recursos Web de diferentes bases de dados vista na iniciativa de Linked Data (LOD1) parece viabilizar parte da interoperabilidade entre bases de dados contextuais, pois estabelecem mapeamentos entre tais dados. A padronização de formato (triplas RDF) e linguagem de consulta (SPARQL) estabelecida pela W3C parece viabilizar tanto interoperabilidade quanto reutilização, tanto de fontes de dados estáticos (que não mudam com freqüência) quanto de sensores físicos. A padronização de linguagens para representação de ontologias na Web (OWL) e para criação de regras definidas pelo usuário (como SWRL) também parece viabilizar a reutilização de modelos de contexto (taxonomias, ontologias e inferências). No entanto, o uso de LOD traz diversos desafios que devem ser pesquisados. Um deles é determinar quais bases e ligações são úteis e/ou confiáveis para serem utilizadas. Outro desafio reside na disponibilização de dados de sensores físicos para acesso via SPARQL 1 Será utilizada a sigla LOD, mesmo para bases não abertas, para evitar confusão com lógica descritiva (LD). 18 endpoints. Isso vai desde a obtenção dos dados não-tratados de sensores físicos (termômetros, GPS, pluviômetros, etc.) e a forma de atualização do SPARQL endpoint quando ocorre alguma atualização, até fusão e agregação destes dados. Este último pode necessitar de diversas técnicas de tratamento de dados incertos (lógica Fuzzy, redes bayesianas, Hidden Markov Models, etc.). Nenhum destes desafios será pesquisado aqui. O problema específico a ser tratado neste trabalho está relacionado a propor e testar um módulo que permita inferências, incuindo de contexto, usando OWL-DL, que provê construtos de lógica descritiva, e regras definidas pelo usuário. Este módulo pode ser classificado como um sensor lógico ou interpretador de contexto segundo a literatura CC ou como um dataset de dados derivados segundo os conceitos de LOD. Além de efetuar inferência, é necessário que tais dados sejam disponibilizados na nuvem LOD, em um formato comum que permita interoperabilidade para serem usados por diversas aplicações (CC ou não) e até mesmo por outros módulos. Por fim, o framework precisa ser configurado facilmente, desde que o domínio já tenha sido previamente definido. Assim, o problema é enunciado da seguinte forma: “Necessidade de um ferramental configurável, capaz de realizar inferências, incluindo contexto, usando formatos de dados interoperáveis, e também de disponibilizar seus dados para consumo seguindo princípios da Web Semântica.” 1.4 Objetivo Este trabalho tem por objetivo apresentar a arquitetura, a implementação e validação do Módulo de Inferência proposto como parte de um framework mais geral, que se propõe a ser um módulo facilmente configurável que permita inferência de contextos em níveis, do mais geral ao mais específico. Contudo, esta pesquisa se limita a inferências usando o padrão OWL 2 DL (Web Ontology Language 2 Description Logic) do W3C e regras IF-THEN sobre instâncias de uma base. Portanto, não está no escopo qualquer outro método como Lógica Fuzzy ou de Primeira Ordem, Redes Bayesianas, etc. A etapa de validação compreenderá a descrição de alguns cenários onde dados contextualizados são necessários e a explicação das etapas necessárias (modelagem do domínio, construção da ontologia OWL, regras e consultas) para se chegar a uma base que 19 possa ser consultada diretamente por uma suposta aplicação. Por fim, acredita-se que, no futuro, tais módulos poderiam ser disponibilizados na Web com diferentes tipos de informações para que desenvolvedores de aplicações pudessem consumir seus dados. 1.5 Contribuição A principal contribuição deste trabalho é um framework facilmente configurável para auxiliar a construção da parte inteligente de aplicações cientes de contexto (inferência de contexto e geração de notificações e/ou ações) utilizando formatos e padrões abertos da Web Semântica. O uso destas tecnologias mostra que o framework também é útil para aplicações genéricas para Web Semântica que necessitem de inferência com ontologias OWL e regras. O framework mostra habilidade em fazer inferência modularizada e distribuída na Web, ou seja, dividir o processamento de ontologias e regras em módulos distintos que podem executar em máquinas distintas para posterior integração. Para mostrar a viabilidade três cenários foram propostos e implementados. A facilidade de configuração proporcionada pelo framework permite que pessoas sem grandes conhecimentos de linguagens de programação possam configurar o módulo e disponibilizar seus dados na Web rapidamente. O framework reduz a necessidade de programação, mas não substitui as necessidades de conhecimento do domínio, levantamento de requisitos e modelagem como em qualquer desenvolvimento de aplicações. 1.6 Estrutura da dissertação Este trabalho é dividido em outros cinco capítulos. O capítulo 2 apresenta o referencial teórico sobre contexto, web semântica e alguns trabalhos relacionados. O capítulo 3 descreve uma arquitetura geral em camadas sugerida para o problema descrito na seção 1.2 e depois aprofunda a discussão para uma parte da arquitetura denominada Módulo de Inferência que visa abordar o problema específico da seção 1.3. O capítulo 4 mostra cenários de aplicação e as respectivas provas de conceito através de implementações utilizando o módulo sugerido, mostrando que é factível. O capítulo 5 apresenta um experimento feito com alunos de mestrado e seus resultados a fim de verificar o grau de dificuldade em se entender e configurar módulos para uma das aplicações do capítulo 4. Por fim, o capítulo 6 destaca análises críticas quanto às contribuições, limitações e oportunidades futuras. 20 2 Referencial Teórico A área de computação ubíqua (UBICOMP) e pervasiva está cada vez mais relacionada à Web, pois à medida que esta se torna cada vez mais presente na vida das pessoas, mais útil ela demonstra ser como um ferramenta para tarefas cruciais da computação ubíqua e pervasiva. Este capítulo apresentará conceitos de computação ubíqua, pervasiva e ciente de contexto, e Web Semântica (WS), e como esta tem sido empregada nessas áreas. Como é cada vez mais difícil falar de UBICOMP sem falar das tecnologias da WS, e uma ordem deve ser seguida, decidiu-se por falar primeiramente de UBICOMP (seções 2.1 e 2.2) reduzindo ao máximo o uso de termos técnicos da WS, para depois introduzir conceitos de WS (seção 2.3). A priori, caso o leitor não esteja familiarizado com WS, tenha em mente a seguinte analogia entre WS, grafos, linguagens de programação e bancos de dados relacionais: RDF é uma representação de informação usando nós e arestas, onde um nó pode ser um URI ou um valor literal (número, texto, data). Um URI possui a forma de um endereço na Internet e é equivalente à chave primária, identificando, portanto, um registro de tabela. Um literal equivale a um campo de tabela que não seja chave estrangeira. Um URI, por ser um identificador, pode representar um nó não literal ou um tipo de aresta. RDFS e OWL representam ontologias sendo semelhante ao esquema do banco, ou seja, definem as relações e restrições permitidas entre nós. Regras assemelham-se ao comando IF..THEN ou triggers, e também permitem chamada de funções. Por fim, SPARQL é análogo à linguagem SQL. 2.1 Computação ubíqua e contexto: definições Em 1991, Mark Weiser lança os princípios da Computação Ubíqua, onde introduz o termo computação invisível (WEISER, 1991). Segundo ele, “As mais profundas tecnologias são aquelas que desaparecem”. Sua proposta não era de eliminar ou ocultar máquinas, mas de proporcionar interações mais amigáveis, tirando o foco de atenção das máquinas e direcionando para as tarefas dos usuários. Embora ainda não exista um consenso, os conceitos computação ubíqua e computação “pervasiva” não serão, apesar de parecidos, considerados sinônimos neste trabalho. A palavra “ubíquo” significa, segundo o dicionário Aurélio, “que está ao mesmo tempo em todo lugar”, enquanto que a palavra “pervasive” vem do inglês, não existindo na língua portuguesa, e 21 significa difundido, embarcado ou penetrante. Segundo (ARAUJO, 2003) a computação ubíqua é construída pela união das capacidades da computação pervasiva e móvel. Segundo ela, na computação pervasiva “(...) o computador está embarcado no ambiente de forma invisível para o usuário”. Ela diz também que: “(...) o computador tem a capacidade de obter informação do ambiente (...) e utilizá-la para (...) controlar, configurar e ajustar a aplicação para melhor atender as necessidades do dispositivo ou usuário.” No que se refere à computação ubíqua, ela afirma que: “a computação ubíqua beneficia-se dos avanços da computação móvel e da computação pervasiva” e “a justificativa de (...) diferenciação desses termos é que um dispositivo que está embutido em um ambiente, não necessariamente é móvel”. Desta forma, estes três conceitos além do conceito de computação tradicional podem ser simplificadamente ilustrados conforme a Figura 1 a seguir (LYYTTINEN; YOO, 2002): Computação Pervasiva Computação Ubíqua Computação Móvel Alto grau de “embarcamento” Computação Pervasiva Computação Ubíqua Mobilidade baixa Mobilidade alta Computação Pessoal tradicional Computação Móvel Baixo grau de “embarcamento” Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior uma notação de conjuntos e na inferior as dimensões grau de mobilidade e de embarcamento em eixos ortogonais. Contudo, para caminhar na direção da computação ubíqua, é necessário entender e conhecer o contexto no qual as interações ocorrem. Schilit et al. (SCHILIT et al., 1994) foram os primeiros a usar o conceito de contexto e aplicações cientes de contexto na computação. Em seu trabalho, definiram softwares cientes de contexto (CC) como aqueles capazes de 22 “adaptar-se à localização de uso, ao conjunto de pessoas e dispositivos próximos, assim como, às mudanças destes ao longo do tempo”. Menciona também o que chamou de aspectos de contexto como “where you are, who you are with and what resources are nearby”. Além disso, categorizou aplicações CC como uma combinação de duas dimensões. A primeira delas divide a tarefa em obtenção de informações ou execução de um comando. A segunda determina se a tarefa é realizada manual ou automaticamente. Dey e Abowd (DEY, A. K.; ABOWD, 1999) relatam que contexto foi definido usando sinônimos, como por exemplo ambiente ou situação do usuário ou da aplicação, o estado das coisas em torno da aplicação. Também relatam definições usando exemplos (localização, data e hora, temperatura, nível de ruído, etc.) que são incompletas, pois é difícil aplicá-las diante de novas informações. Devido a essas definições abstratas e/ou incompletas, eles definiram os conceitos de contexto, ciência de contexto e aplicações cientes de contexto: "contexto é qualquer informação que pode ser usada para caracterizar a situação de uma entidade. Entidade é uma pessoa, lugar ou objeto que é considerado relevante para a interação entre um usuário e uma aplicação, incluindo usuário e a aplicação." “um sistema é ciente de contexto se ele usa contexto para prover informações relevantes e/ou serviços ao usuário, onde relevância depende da tarefa do usuário.” (DEY, A. K.; ABOWD, 1999) Mais tarde, Becker e Nicklas (BECKER; NICKLAS, 2004) refinam as definições de Dey e Abowd adicionando o termo adaptação e substituindo os termos interação com usuário e serviços para o usuário por comportamento: “contexto é a informação que pode ser usada para caracterizar a situação de uma entidade. Entidades são pessoas, locais, ou objetos considerados relevantes para o comportamento de uma aplicação. A própria entidade é considerada como parte de seu contexto.” “uma aplicação é ciente de contexto se ela adapta seu comportamento conforme o contexto.” (BECKER; NICKLAS, 2004) Uma outra definição recente encontrada na literatura para ciência de contexto é dada por Naudet: “ciência de contexto é a habilidade de um sistema, conhecendo seu estado e seu ambiente, sentir, interpretar e reagir a mudanças em seu estado ou no ambiente em que está situado.” (NAUDET, 2011) 23 Note-se que esta última definição usa os termos estado e ambiente, onde tanto estado quanto ambiente dizem respeito às configurações num determinado momento, contudo a primeira refere-se ao próprio sistema e o segundo ao que o rodeia (estado externo). Esta definição também destaca a habilidade de sentir ou reconhecer o seu estado e o ambiente, a interpretação da nova configuração e a reação à esta mudança. 2.2 Aquisição, classificação e modelagem de contexto Além das definições de contexto apresentadas na seção anterior, vários outros aspectos devem ser considerados. Esta seção abordará a aquisição de contexto (sensores, entradas do usuário e interpretadores), classificações de contexto e de aplicações cientes de contexto existentes na literatura e, por fim, modelagem de contexto. 2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores A obtenção de dados de contexto é feita por meio dos chamados sensores. Indulska e Sutton (INDULSKA, JADWIGA; SUTTON, 2003) definem o termo sensor como “um sistema que provê informação” e Baldauf et al. (BALDAUF et al., 2007) dizem que sensor “não se refere apenas a hardware, mas também a toda fonte de dados que possa prover informação de contexto utilizável”. Segundo ambos os trabalhos, sensores podem ser classificados, conforme sua natureza, em físicos, virtuais e lógicos: sensores físicos são aqueles baseados em hardwares capazes de capturar diversas propriedades físicas do ambiente como temperatura, aceleração, luminosidade, áudio, posição geográfica, data e hora, entre outros; sensores virtuais são aqueles que utilizam softwares ou serviços para fornecer informação de contexto, como por exemplo, obter localização do usuário a partir de sua agenda ou sistema de reservas de viagens; ou obter atividade do usuário a partir da movimentação do mouse, entradas de teclado ou modificações no sistema de arquivos do computador; sensores lógicos também são baseados em softwares mas descobrem contextos de mais alto nível a partir de inferências sobre contextos oriundos de sensores físicos ou virtuais e também de bases de dados. Por exemplo, descobrir que o usuário está em show de rock usando microfone, posição geográfica, a data e agenda. 24 Du & Wang (DU; WANG, L., 2008) utilizam ainda os termos sensor de hardware e sensor de software e os termos sensor local e sensor remoto. Os dois primeiros são autoexplicativos e os dois últimos são explicados a seguir: Sensores locais são sensores físicos localizados na mesma máquina ou dispositivo do usuário e cuja comunicação com aplicações é feita via chamadas ao sistema operacional ou através de uma API (ex. o microfone de um smartphone). Sensores remotos são aqueles externos ao dispositivo e que se comunicam com a aplicação por meio do protocolo IP, podendo até mesmo ser organizados numa rede de sensores. Um exemplo simples é um termômetro que mede a temperatura da casa do usuário enquanto ele está no trabalho e se comunica com seu Smartphone via Internet. Uma questão que pode ser feita é o que Du & Wang quiseram dizer com sensor físico, visto que sensores virtuais e lógicos também podem estar localizados no dispositivo do usuário e até mesmo utilizar chamadas nativas. Sendo assim, eles não seriam nem locais nem remotos. Outro trabalho mais recente de Bettini et al. (BETTINI et al., 2010) nem chega a citar classificações, dizendo que “algumas informações de contextos são sentidas” e que “sensores podem observar certos estados do mundo físico e prover acesso rápido quase em tempo real”. As expressões “estados do mundo físico” e “quase em tempo real” parecem representar apenas sensores físicos visto que sensores virtuais podem capturar dados de agenda (mundo não físico) e sensores lógicos podem precisar de bastante tempo de processamento (tempo não real). Mas Baldauf et al. diz que sensor não é apenas hardware (sensor físico) mas qualquer fonte de dados que possa prover contexto. Sendo assim, um simples sistema que armazena o perfil do usuário seria um sensor para Baldauf et al. e não seria para Bettini et al.. Pode-se também considerar que Bettini et al. usaram o verbo “podem” para não se comprometer, mas este parece não ser o caso pois na sequência eles falam sobre dados inseridos pelo usuário sem qualquer relação com o termo sensor. Estas discussões mostram que estes conceitos ainda não estão claramente definidos na literatura e, como este trabalho não pretende discutí-los nem utilizá-los, decidiu-se por utilizar conceitos mais simples. Assim, o termo sensor físico será usado para fontes que fornecem características físicas do ambiente. O termo sensor virtual não será utilizado por se considerar que estão numa região indefinida entre os físicos e lógicos. Para o conceito de sensor lógico será usado o termo interpretador de contexto, retirado do trabalho de Gu et al. (GU et al., 2005). Para fontes de dados pessoais inseridos diretamente pelo usuário será utilizado o termo 25 perfil de usuário. O termo bases de dados será utilizado para fontes de dados não associados a uma entidade específica, mas que podem vir a se tornar contexto após processamento por parte de interpretadores de contexto. Finalmente, o termo provedor de contexto, será utilizado como um termo genérico para sensores físicos, perfis, bases de dados e interpretadores de contexto, diferentemente da classificação de Gu et al. 2.2.2 Classificações de contexto Dey e Abowd (DEY, A. K.; ABOWD, 1999) dividiram contexto em dois tipos: primário e secundário. O contexto primário é divido em: localização – responde onde (where) uma entidade está; identidade – responde quem (who) é a entidade; tempo – responde quando (when). atividade – responde o que está ocorrendo ou o que o usuário está fazendo (what); Atividade e tempo não foram consideradas por Schilit et al. (SCHILIT et al., 1994), além disso, Ryan et al. (RYAN et al., 1998) tinham chamado atividade de ‘ambiente’, mas por considerar um sinônimo de contexto Dey modificou para atividade. Já o contexto secundário seria qualquer outro derivado destes, como por exemplo, previsão do tempo a partir de localização e data ou endereço a partir da identidade da entidade. O trabalho de Gu et al. (GU et al., 2005) apresenta uma divisão de contexto conforme a forma de obtenção do contexto em: contexto direto – que são obtidos diretamente do que ele designou provedores de contexto e que podem ser ainda divididos em sensed e defined; contexto indireto – onde são usados interpretadores de contextos que se aproveitam de contextos já conhecidos para inferir novos. Também descrito como deduced context. Assim, os sensed contexts seriam obtidos de sensores físicos; os defined contexts seriam aqueles fornecidos diretamente pelo usuário via formulários e praticamente constantes (perfis do usuário; ex. preferências pessoais) e os deduced contexts seriam obtidos de interpretadores de contexto. Henricksen et al. (HENRICKSEN, K. et al., 2004) apresenta denominações semelhantes: sensed, derived (=deduced), profiled (=defined) e static (semelhante ao defined mas de caráter impessoal). Esta classificação de Henricksen et al. é interessante pois separa informações de contexto provenientes de bases de dados em duas 26 partes: uma fornecida pelo usuário representando suas informações pessoais (profiled contexts) e outra fornecida por especialistas ou até mesmo usuários, mas representando informações de caráter coletivo ou impessoal (static contexts). Note que a divisão entre contexto primário e secundário é diferente da divisão entre contexto direto e indireto, pois a primeira se refere ao tipo da informação de contexto e, a segunda, à sua forma de obtenção. Como exemplo, considere que localização é sempre um contexto primário, mas pode ser direto no caso de coordenadas geográficas obtidas de um GPS, ou indireto no caso de lugares (ex. escola, praia) descobertos a partir de uma agenda ou de geocode reverso (endereço a partir de coordenadas). Korpipaa et al. (KORPIPAA et al., 2003) mencionam dois bons exemplos de contextos indiretos inferidos usando redes bayesianas. Um destes exemplos é descobrir se usuário está dentro de um local fechado ou em um local aberto utilizando intensidades sonora e luminosa, temperatura e posição do dispositivo móvel. Outro exemplo dado em seu trabalho é utilizar vários dados de áudio para determinar o tipo de som do ambiente (carro, elevador, conversa, música, entre outros). Existem diversas outras classificações. Por exemplo, contextos podem ser públicos, quando podem ser facilmente obtidos por qualquer pessoa (ex. tempo, guia de ruas, pontos de interesse) ou privados, quando requerem proteção (ex. localização e preferências do usuário); ou podem ter frequências de atualização alta (ex. sensores físicos), média (ex. aqueles modificados por humanos como eventos sociais e culturais) ou baixa (ex. preferências pessoais). A Figura 2 esquematiza estas divisões de contexto e associa aos provedores de contexto (sensores, interpretadores, etc.) quando aplicável, porém não há qualquer intenção de exaurir todas as possíveis classificações existentes na literatura. Note ainda que a classificação de Dey não foi associada a fontes de contextos visto que isso não possui uma regra. Por exemplo, a localização pode ser representada por coordenadas geográficas obtidas de um GPS (sensor físico) ou ser uma informação de alto nível, como universidade ou show de rock, inferida por um interpretador de contexto. Por fim, relembre que este trabalho não utilizará os termos sensor virtual e lógico para fontes de contexto, mas sim os termos sensor físico, perfil de usuário, base de dados e interpretador de contexto. 27 Primário Localização, Identidade, Atividade, Tempo Secundário Obtidos dos primários Direto Sensed (sensores físicos) Defined (definido pelo usuário) Indireto Deduced (interpretadores de contexto) Pública Obtido por qualquer pessoa Privada Necessário permissão para acessar Alta Fornecido por sensores Média Fornecido por humanos Baixa Perfis, mapas e guias Tipo Obtenção Contexto Visibilidade Taxa de atualização Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação, à forma de obtenção, à visibilidade e à taxa de atualização. 2.2.3 Classificações de aplicações cientes de contexto Em relação às aplicações cientes de contexto, Dey e Abowd (DEY, A. K.; ABOWD, 1999) classificaram-nas em três tipos: Apresentação de informações e serviços ao usuário Execução automática de serviços Marcação de contexto à informação para recuperação posterior Segundo Becker e Nicklas (BECKER; NICKLAS, 2004), o primeiro tipo (apresentação) representa, na verdade, dois tipos: seleção e apresentação. O primeiro ocorre quando uma aplicação escolhe uma informação ou serviço baseado no contexto. O segundo relaciona-se à forma como algo é apresentado ao usuário dependendo do contexto como, por exemplo, uma notificação motora e visual no cinema e notificação sonora quando usuário estiver dirigindo. As demais classificações são equivalentes. A execução de Dey e Abowd é denominada ação por Becker e Nicklas, mas ambas representam a execução automática de algum serviço como, por exemplo, reservar um livro na biblioteca ou comprar um numa livraria. Por último, a marcação inclui aplicações que apenas retem uma informação para que o usuário recupere posteriormente como, por exemplo, anotar nome da livraria, local e preço do livro para que o usuário consulte posteriormente e decida o que fazer. 28 Para Chen (CHEN, H. L., 2004) as aplicações podem ser classificadas ainda conforme sua arquitetura de aquisição de contexto em três formas: acesso direto aos sensores – a aplicação cliente obtém os dados dos sensores diretamente, sem qualquer camada de abstração o que torna difícil o uso perante grande concorrência de acesso ou uma vastidão de diferentes tipos de sensores. infra-estrutura de middleware – usa uma camada de abstração que permite extensibilidade e simplifica a reusabilidade, no entanto, consome mais recursos de processamento que podem levar a uma redução de desempenho em dispositivos menos potentes como smartphones. servidor de contexto – utiliza uma máquina rica em recursos computacionais responsável por obter dados dos sensores e disponibilizá-los de forma distribuída. Note que cada um dos métodos pode ser aplicado dependendo das características dos sensores e da aplicação. Por exemplo, se ambos estão em um único dispositivo móvel, não é necessário um servidor de contexto, mas se a aplicação está num smartphone e obtém dados de uma rede de sensores o servidor de contexto é de grande utilidade. 2.2.4 Comparações entre modelos de contexto Diversas abordagens para modelagem de contexto, ou seja, formas de representação que permitam processamento por máquinas já foram utilizadas (POSLAD, 2009; STRANG; LINNHOFF-POPIEN, C., 2004). As abordagens mais antigas não eram genéricas, ou seja, eram específicas para o domínio da aplicação sendo desenvolvida; enquanto que abordagens seguintes, apesar de não serem tão atreladas à aplicação, ainda eram limitadas (STRIMPAKOU, M. A. et al., 2006). Estes modelos englobam desde o simples modelo chave-valor até ontologias, passando por modelos hierárquicos (SGML e XML), modelos gráficos (UML e ORM), orientação a objetos e lógica. Strang e Linnhoff-Popien (STRANG; LINNHOFF-POPIEN, C., 2004) fizeram uma comparação entre estes modelos avaliando-os conforme os seguintes requisitos: Composição distribuída (dc) – capacidade de lidar com o dinamismo requerido pela computação ubíqua por meio de uso móvel e distribuído. Validação parcial (pv) – capacidade de descobrir erros e inconsistências na estrutura do modelo e nas suas instâncias. 29 Riqueza e qualidade da informação (qua) – dados oriundos de sensores podem apresentar variações conforme o tipo e o fabricante do sensor e até mesmo durante o funcionamento do mesmo sensor. Portanto, tal modelo deveria suportar tais informações. Incompletude e ambiguidade (inc) – o conjunto de informações de contexto que caracterizam uma entidade em algum momento pode ser ambíguo e/ou incompletas, inclusive quando provêm de uma rede de sensores. Portanto, mecanismos para filtrar e tratar estes dados são desejados. Nível de formalidade (for) – é importante que o modelo de contexto permita compartilhar a mesma interpretação dos dados e significados entre os agentes envolvidos (shared understanding). Aplicabilidade a ambientes já existentes (app) – é importante que um modelo de contexto seja factível, ou seja, sua implementação seja possível usando infraestruturas existentes. Dentre estes modelos, as ontologias foram consideradas as mais adequadas aos requisitos da computação ubíqua, conforme pode ser observado no Quadro 1. Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN, C., 2004) Abordagem/requisitos dc pv qua inc for app Modelos chave-valor - - -- -- -- Modelos de marcação (XML) + ++ - - + ++ Modelos gráficos -- - + - + + Modelos orientados a objetos ++ + + + + + Modelos baseados em lógica ++ - - - ++ -- Modelos baseados em ontologia ++ ++ + + ++ + + Mas tarde, Bettini et al. (BETTINI et al., 2010) fizeram uma comparação entre o modelo ontológico e outros dois modelos não discutidos pelo trabalho anterior. Este trabalho mais recente estabeleceu os seguintes requisitos que modelos de contexto devem viabilizar: Heterogeneidade – ser capazes de lidar com uma grande variedade de fontes de contexto (sensores físicos, contextos derivados de informações de contexto já existentes, bases de dados). 30 Mobilidade – ser capazes de se adaptar a mudanças frequentes de ambiente seja por parte de sensores que se movimentem seja por parte de aplicações que executem em dispositivos móveis. Relacionamentos e dependências – expressar variados tipos de relações entre informações de contexto, incluse dependências onde uma mudança em uma propriedade pode afetar outras. Temporalidade – permitir que aplicações acessem estados passados e até mesmo futuros (previsões); além disso, quando as atualizações tiverem frequência alta a ponto de não poderem ser armazenadas individualmente é necessário que haja possibilidade de se sumarizar tais informações. Imperfeição – dados de sensores possuem qualidade muito variável, podendo se tornar rapidamente obsoletos ou fornecer medidas conflitantes ou até mesmo incorretas; assim, é necessário que modelos de contexto sejam capazes de expressar a qualidade destes dados. Raciocínio – muitas vezes é necessário que aplicações utilizem técnicas de inferência para tomar certas decisões de adaptação a mudanças; além disso, é preciso que haja checagem de consistência do modelo de contexto e que isso seja computacionalmente eficiente. Usabilidade – modelos de contexto devem apresentar facilidade para que modeladores consigam traduzir conceitos do mundo real para seus construtos e aplicações possam utilizar manipular estas informações. Eficiência – deve permitir acesso eficiente às informações de contexto, mesmo diante de modelos enormes e muitos objetos; para isso, deve haver índices e caminhos de acesso que permitam a recuperação eficiente destes dados. O primeiro modelo avaliado é chamado Object-role Model, que utiliza Context Modeling Language (CML), uma linguagem com notação gráfica para apoiar análise e especificação de requisitos de contexto utilizando fatos e relações (HENRICKSEN, K; INDULSKA, J, 2004, 2006). CML é uma extensão do Object-Role Modelling (ORM) para modelagem conceitual de bancos de dados (HALPIN, 2001). Construiu-se um procedimento denominado Rmap para mapear CML para um esquema de banco de dados relacional (HENRICKSEN, K, 2003). CML é capaz de representar contextos estáticos, sentidos, fornecidos via perfil de usuário, derivados, assim como temporalidade e ambiguidade. Este último é realizado usando os chamados fatos alternativos e uma lógica trivalorada 31 (verdadeiro, falso e possivelmente verdadeiro) de maneira que, se uma propriedade de um indivíduo possui mais de um valor, ao se perguntar sobre a veracidade de apenas um destes valores a resposta é possivelmente verdadeiro, visto que não se pode determinar se apenas uma ou ambas as respostas são verdadeiras (por exemplo, valores sobre localização do usuário podem ser equivalentes como casa e cozinha ou conflitantes como casa e supermecado). Contudo, CML não permite representação de hierarquia, todos os tipos de contexto são fatos atômicos e não suporta interoperabilidade. Modelos espaciais se baseiam no fato de que muitas interações requerem alguma proximidade espacial que pode ser física ou virtual. Proximidade física pode ser representada por coordenadas geométricas ou simbólicas. A primeira representa pontos e áreas em sistemas métricos como o datum WGS84 (DECKER, B. L., 1984) utilizado por GPS e permite cálculo de distâncias e sobreposição numericamente. Coordenadas simbólicas usa identificadores para pontos e regiões e conceitos como sobreposição, tangenciamento, inclusão, etc. para relacioná-los, sendo conhecido como Region Connection Calculus (RCC) (RANDELL et al., 1992). Proximidade virtual representa informação de contexto não física, ou seja, associa localização a objetos virtuais que não estão presentes no mundo real, exemplo pode ser visto em (LEONHARDI et al., 1999). Inferências permitidas por estes modelos dizem respeito às relações espaciais entre objetos que permitem consultas relativas à posição de um objeto, objetos dentro de uma área e objetos próximos a um objeto, portanto, sua indicação é limitada a aplicações baseadas em localização ou que permitam tal analogia. Um problema deste modelo é o esforço necessário para obter dados de localização da informação de contexto e mantê-los atualizados (BETTINI et al., 2010). Modelos baseados em ontologias usam lógica de descrição (DL) que tenta contrabalançar expressividade da linguagem e complexidade da inferência usando ferramentas automatizadas. Bettini et al. diz que ao usar esta teoria, a linguagem OWL-DL permite (a) expressar dados de contexto complexos não representados por outros modelos; (b) compartilhar e/ou integrar contextos de diferentes fontes devido à sua alta formalidade semântica (interoperabilidade e heterogeneidade); (c) checar consistência da base e descobrir contextos implícitos. Apesar de modelos espaciais serem os mais indicados para dados geográficos, o modelo ontológico também pode tratar tal informação usando RCC (HAAV et al., 2009). Bettini et al. mostram ainda a falta de construtos para fazer composição de relações, que, foi adicionado na OWL 2. Eles também destacam que, apesar de OWL-DL ser decidível, a inferência é computacionalmente custosa para ser feita em tempo real e não 32 escalável para grandes quantidades indivíduos, além disso, a adição de regras pode torná-la indecidível. Adicionalmente, eles comentam que existe pouco suporte para tratar temporalidade. Realmente, não há suporte direto para dados temporais, contudo há abordagens sobre isso na literatura. Batsakis & Petrakis (BATSAKIS; PETRAKIS, 2010), por exemplo, apresentam uma extensão OWL e SPARQL para representar tanto dados temporais, usando as relações temporais de Allen (ALLEN, 1984), quanto RCC. O Quadro 2 resume as conclusões de Bettini et al. quanto aos modelos e requisitos, de modo que os sinais “+” e “–” representam, respectivamente, cumprimento ou não do requisito enquanto “~” representa cumprimento parcial do requisito. Mobilidade Relacionamentos Temporalidade Imperfeição Raciocínio Usabilidade Eficiência ~ ~ + ~ ~ + ~ Espacial ~ + ~ + ~ - ~ + Ontológico + - + - - + ~ - requisitos + e Object-role Abordagens Heterogeneidade Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010) Devido ao fato de todos os modelos apresentarem fraquezas, Bettini et al. sugerem um modelo híbrido em três camadas que deve ser o futuro dos middlewares cientes de contexto. A primeira captura e funde dados de sensores, a segunda efetua integração de dados de diversas fontes (sensores da primeira camada, bases relacionais ou de triplas) e inferência com vocabulários simples podendo tratar dados incertos, ambíguos e, inclusive, conflitantes. A terceira camada usaria inferência com ontologias para checagem de consistência em um nível mais alto de abstração. Aplicações se comunicariam apenas com a segunda camada que seria responsável por se comunicar com as duas outras camadas. Neste trabalho apenas ontologias com regras serão utilizadas, mas devido ao carater distribuído da arquitetura proposta tal modelo híbrido pode ser concretizado em abordagens futuras. Além disso, este trabalho visa mostrar que estas camadas podem ser formadas por pequenos módulos espalhados pela Web que se comunicam usando uma linguagem de comunicação padronizada (RDF/SPARQL). 33 2.2.5 Ontologias de modelagem de contexto Ontologia é um termo oriundo da filosofia para referir-se ao assunto de existência. Nas ciências da computação e da informação, ontologias são usadas para expressar o conhecimento sobre conceitos, seus atributos e também as relações entre eles (STRANG et al., 2003). De forma mais detalhada, é uma representação formal e explícita de uma conceitualização compartilhada. Esta conceitualização compartilhada refere-se a algum domínio do conhecimento cujos conceitos e relações sejam consensuais, ou seja, aceitas por um grupo e não apenas por um indivíduo. Os termos explícita e formal dizem, respectivamente, que esta representação deve (1) ser explicitamente definida e (2) entendida por máquinas, o que exclui o uso linguagem natural. (PERTTUNEN et al., 2009) Uma ontologia é usada, então, para definir um domíno e para raciocinar sobre este domínio (PATNI et al., 2010). Atualmente, a linguagem OWL, fundamentada na lógica de descrição, é usada para representar e instanciar ontologias na Web e ambas serão discutidos na seção 2.3. Diversas ontologias de contexto já foram utilizadas na literatura e algumas delas serão comentadas aqui por ordem cronológica, mas antes, vale ressaltar que uma informação de contexto tem diversas propriedades atribuídas a ela. Segundo (BALDAUF et al., 2007) as mais triviais são: Tipo é sua categoria ou classe como temperatura, localização, preferência pessoal, e pode ser organizado numa hierarquia em árvore; Valor representa o dado propriamente dito obtido por um sensor; Marca de tempo identifica quando o contexto foi obtido; Fonte identifica quem ou qual sensor obteve tal informação; Confiança define o grau de incerteza do dado de contexto entre 0 e 1. Uma das primeiras ontologias de contexto foi a CoOL (Context Ontology Language) baseada no modelo Aspect-Scale-Context (ASC) (STRANG et al., 2003). Cada aspecto reúne escalas e cada escala reune informações de contexto. Portanto, aspecto é um conjunto de uma ou mais escalas, escala é um conjunto de objetos que definem o intervalo de informações de contexto válidas para esta escala. Por exemplo, o aspecto GeographicCoordinateAspect permite as escalas WGS84 e GaussKrueger, e infomação de contexto é um valor numa dada escala como GaussKruegerCorrinate(367032,533074) para GaussKrueger, e “10” para MeterScale. Uma informação de contexto A por ter outras infomaçoes de contexto caracterizando a qualidade desta informação A, que podem ser intríssecas como erro mínimo, 34 erro médio e marca de tempo ou genéricas através da relação hasQuality. O conceito de IntraOperation permite criar funções de mapeamento entre escalas de um mesmo aspecto (ex. conversão entre WGS84 e GaussKrueger). Para mapear escalas de diferentes aspectos existe o conceito de InterOperation (ex. KilometerPerHourScale de SpeedAspect representado como SpatialDistanceAspect e DurationAspect). Observa-se assim que CoOL é falha em expressar contextos abstratos como atividade do usuário (STRIMPAKOU, M. A. et al., 2006). A ontologia CONON (CONtext ONtology) descreve uma ontologia genérica de contexto (upper ontology) e uma específica para o domínio residencial (WANG, X. H.; ZHANG, D. Q. et al., 2004). A ontologia genérica basicamente se restringe em definir uma hierarquia do conceito chamado entidade de contexto que se especializa em entidade computacional, localização, pessoa e atividade. Uma entidade computacional pode ser serviço, aplicação, dispositivo, rede e agente. Localização pode ser interna (indoor) ou ao ar livre (outdoor). Atividade pode ser deduzida ou agendada. Resumidamente, a ontologia específica de domínio para residências inclui as classes televisão e celular (dispositivos), festa e aniversário (atividades agendadas), cozinhar e tomar banho (atividades deduzidas), jardim (espaço ao ar livre), sala ou cozinha (espaço fechado), entre outros; e propriedades, como localização de uma entidade computacional ou usuário, estado de portas e janelas como aberto ou fechado, entre outras. As ontologias SOUPA (Standard Ontology for Ubiquitous and Pervasive Applications) (CHEN, H.; PERICH; et al., 2004) utilizam conceitos de modelos, ontologias e vocabulários anteriores como FOAF2, OWL-Time (PAN; HOBBS, 2003), OpenCyc (LENAT, 1995), RCC, CoBrA-ONT(CHEN, HARRY et al., 2003) e BDI (BRATMAN, 1999; RAO; GEORGEFF, 1991), e é divida em dois subconjuntos: SOUPA-Core e SOUPAextension. A primeira define vocabulários genéricos para: Pessoas – informações de contato e perfil; Políticas e ações – políticas de privacidade e segurança com uma lógica de descrição para gerar ações a serem executadas por agente baseadas nestas políticas; Agentes e BDI – agentes e seus estados mentais: belief-desire-intention (crenças, desejos e intenções); 2 The Friend of a Friend Vocabulary: http://www.foaf-project.org/ 35 Tempo – define conceitos para expresar tempo (instante e intervalo) e relações temporais (antes, depois, inicia antes de, etc.); Espaço – representa medidas geográficas, relações entre regiões espaciais, mapeamento entre coordenadas geográficas e simbólicas; Eventos – define eventos temporais (eventos que ocorrem em um instante ou que duram um intervalo de tempo) e espaciais (que ocorrem em algum lugar conhecido); SOUPA-extension estende SOUPA-Core para certos tipos de aplicação e abrange domínios como reuniões e agendas, descrição de documentos, captura de imagem e RCC. Para maiores detalhes consulte (CHEN, H.; PERICH; et al., 2004). A ontologia COMANTO (COntext MAnagement oNTOlogy) é semelhante à CONON com algumas extensões. Também estabelece uma classe entidade de contexto que se especializa em diversos outros como atividade, pessoa, etc. Atividade do usuário por ser física como assistindo televisão ou uma atividade de serviço, ou seja, relacionada a um serviço onde pessoas podem se registrar para usufruir. Tempo representa um instante de tempo e uma atividade possui um tempo inicial e final. Objeto físico pode ser uma mesa ou celular, mas se especializa em dispositivo que pode ter sensores atrelados e estar conectado a um rede. Um smartphone é um dispositivo e, portanto, um objeto físico, mas o mesmo não ocorre com a mesa que é apenas um objeto físico. Objeto físico, pessoa e atividade podem estar associados a um lugar que representa uma localização simbólica ou geográfica. Preferências do usuário se especializam em quatro outras classes que são relacionadas a dispositivos, rede, serviços ou outra coisa que não se relacione a nenhum destes. (ROUSSAKI, I. et al., 2006; STRIMPAKOU, M. A. et al., 2006) Ontonym é um conjunto de ontologias que tenta representar as necessidades mais comuns das aplicações cientes de contexto: tempo, espaço, pessoas (ou identidades) e eventos (ou atividades) (STEVENSON et al., 2009). Para representar tempo e eventos, ela se utiliza da OWL-Time (PAN; HOBBS, 2003) da mesma forma que a ontologia SOUPA. Para modelagem espacial utiliza um modelo bastante elaborado (YE et al., 2007) que reúne representação geométrica (ou geográfica) e simbólica de trabalhos anteriores (HIGHTOWER; BORRIELLO, 2001; JIANG; STEENKISTE, 2002) e adiciona representações de relação espacial como continência, adjacência e conectividade, este útlimo um caso especial de adjacência onde é possível cruzar duas regiões. Para modelagem de pessoas, os autores descrevem que, excluindo-se dados específicos das aplicações, é necessário representar 36 identidade, posse de dispositivos, detalhes pessoais e relações sociais. Para isso consideram uso de URIs para identificar pessoas, versões adaptadas das ontologias vCard 3 e PIM4 do W3C para detalhes pessoais e a ontologia Relationship 5 para descrever relacionamentos interpessoais. Ontonym inclui ainda ontologias para representação de (1) sensores e suas medições (observações) com respectiva taxa de atualização, precisão e acurácia; (2) dados de proveniência como autoria e data de criação ou modificação; (3) dispositivos e ligação com seu possuidor visto que eles funcionam como uma ponte para o usuário que geralmente está carregando o aparelho; e (4) recursos na Web como formato de arquivo, idioma, direitos de acesso, e nomes legíveis para humanos. O trabalho de Naudet (NAUDET, 2011) apresenta uma ontologia com uma visão um pouco diferente, centrada nos conceitos de entidade (Entity), elemento de contexto (Context Element) e situação (Situation). Um elemento de contexto (CE) é “qualquer coisa desde um simples valor numérico ou amostra de sinal (...) até uma afirmação ontológica (...) útil para determinar a situação de uma entidade” e contexto é “um conjunto de elementos de contexto disponíveis num dado momento, que será usado como base de conhecimento para determinar a situação de uma entidade”. A motivação para sua abordagem é que ontologias anteriores são dedicadas apenas a elementos de contexto (SOUPA e Ontonym) ou entidades de contexto (CONON e COMANTO) e ele pretende reunir estes conceitos em uma ontologia de contexto genérica unificante. Para isso, além dos conceitos já descritos, ele define atividade (Activity), estado (State) e ambiente (Environment). Ambiente é tudo que rodeia um sistema e o influencia sendo a entidade parte dele, estado refere-se à estrutura da entidade e atividade refere-se ao seu comportamento, ou seja, suas ações. Além disso, CE = <CI, t, vp, loc, r, obs, src> onde CI é a informação carregada (carried information), t é o instante de tempo em que a informação foi obtida, vp é o período de validade da informação, loc é a localização onde a informação é valida, r é um fator de confiabilidade, obs é a observação de onde a informação se originou, e src é outro CE que porventura tenha gerado/deduzido este CE. Alguns destes valores podem ser omitidos, por exemplo, a ausência de vp ou loc indica que a informação é válida independentemente do tempo ou localização, e a ausência de obs indica que a informaçao não foi obtida de um sensor. Existem ligações com outros vocabulários e ontologias: Semantic Sensors Network Ontology do W3C para representação de observações e 3 vCard ontology: http://www.w3.org/2006/vcard/ 4 W3C PIM: http://www.w3.org/2000/10/swap/pim/contact 5 RELATIONSHIP – A vocabulary for describing relationships between people: http://vocab.org/relationship 37 sensores, FOAF para especializar o conceito de entidade usando os conceitos de agente e pessoa, Ontonym Location para localização de entidade e CE, OWL-Time para instante de medição e validade de um CE. Com base nos diversos trabalhos aqui apresentados, deve-se ressaltar que apesar de estas ontologias descreverem medições de sensores, tais dados podem rapidamente atingir grandes quantidades e inviabilizar inferências OWL usando a ontologia em questão. Portanto, neste caso, tais ontologias deveriam ser utilizadas apenas para representação na troca de informação e outros mecanismos devem ser usados para tratar estes grandes volumes de dados. Outro importante aspecto a ser considerado é a pouca quantidade de informação e documentação, quase inexistente, da maioria delas. Como a Ontonym foge a esta regra, possuindo alguma documentação na Internet6, este trabalho utilizará um subconjunto dela na seção 4.3.1.1 (página 118). Apesar de fora do escopo do trabalho, ao modelar ontologias mais complexas é importante considerar aspectos abordados pelas ontologias de fundamentação como princípio de identidade e aspectos temporais como fases e papéis de uma entidade. Isso pode ser visto em trabalhos como a Unified Foundational Ontology (UFO) (GUIZZARDI; WAGNER, 2010). 2.3 Web Semântica e Dados Ligados A Web atualmente conhecida (Web de Documentos) é projetada apenas para entendimento humano, ou seja, não expressa o significado de forma que possa ser acessado e processado por máquinas em qualquer parte da Web. Desta forma, dados, metadados e regras estão confinados em pequenos conjuntos, geralmente dentro de servidores, e podem ser processados apenas por softwares especificamente desenvolvidos para obter e interpretar estes dados. Vendo este cenário, Tim Berners-Lee introduziu, em 2001, os conceitos da Web Semântica (WS) como uma extensão da Web então existente (BERNERS-LEE et al., 2001). Assim, segundo ele, uma vez que tais dados e metadados estejam disponíveis na Web é possível criar agentes que são “programas que coletam conteúdo da Web de diversas fontes, processam a informação e trocam os resultados com outros programas” de forma que “mesmo agentes que não foram explicitamente desenvolvidos para trabalhar junto possam transferir dados entre si quando estes dados vêm com semântica”. 6 ONTONYM – Ontologies for pervasive computing: http://ontonym.org 38 Apesar de a WS ser apenas uma visão, conceito ou ideia, conforme descrito no parágrafo anterior, este trabalho não tratará do ponto de vista filosófico e, portanto, não diferenciará WS e as tecnologias atuais que a implementam (RDF, OWL, SPARQL). As próximas seções descreverão os conceitos básicos da WS e uma pequena parte da teoria por trás dela, além de um pouco do que vem sendo feito com a iniciativa da Web de Dados ou Dados Ligados. 2.3.1 Conceitos básicos Assim como a Web de Documentos, a WS propõe o uso de identificadores, formatos e protocolos padronizados para descrever e interligar recursos disponibilizados na Web. Isto quer dizer que assim como existem as linguagens HTML, CSS e Javascript e os protocolos HTTP e HTTPS novas linguagens e protocolos também serão padronizados e passarão a ser adotados. Observe, contudo, que como a nova Web deve ser uma extensão da Web atual, todas estas linguagens devem coexistir. Os elementos mais básicos da Web Semântica são os identificadores ou URIs (Uniform Resource Identifiers) e as triplas. URIs identificam recursos enquanto as triplas provêm informações sobre estes recursos. URI são bem semelhantes aos endereços eletrônicos usados para acessar páginas na Web, mas não precisam ser derreferenciáveis como as URLs, ou seja, não precisam retornar uma página HTML quando digitadas em um navegador. Um exemplo de URI que representasse a professora Adriana Vivacqua dentro do PPGI poderia ser: http://greco.ppgi.ufrj.br/resource/Professor/AdrianaVivacqua Adicionalmente, é possível definir um prefixo que represente a parte inicial do URI para escrever o URI em uma forma compacta. Por exemplo, se o prefixo greco for definido como http://greco.ppgi.ufrj.br/resource/Professor/, o URI acima pode ser escrito como greco:AdrianaVivacqua. Triplas são compostas por três partes: sujeito, predicado e objeto. Sujeito e predicado sempre são identificadores. O primeiro identifica um recurso qualquer na Web (como a professora) e o segundo identifica um recurso especial chamado propriedade. O objeto pode ser um URI para um recurso ou um literal (número, texto, data, etc.). O exemplo de tripla a seguir informa o nome completo da professora Adriana Vivacqua (parte do URI do sujeito omitido para caber na linha): 39 <http://.../AdrianaVivacqua> foaf:name “Adriana Santarosa Vivacqua”. O prefixo foaf representa o URI do vocabulário FOAF para descrever redes sociais ou de informação. Assim foaf:name representa a propriedade <http://xmlns.com/foaf/0.1/name>. Ao escrever uma tripla, as formas longas devem usar os símbolos de menor e maior como delimitadores. O nome entre aspas é denominado literal. Um conjunto de triplas forma um grafo, de maneira que os vértices representam sujeitos e objetos, e as arestas representam predicados. O padrão RDF (Resource Description Framework) aplica estes conceitos para representar informações na Web por meio de notações XML, Turtle, N3 e NTriplas. A seguir pode-se observar um exemplo utilizando as notações Turtle e XML: 1 2 3 4 5 @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix greco: <http://greco.ppgi.ufrj.br/resource/Professor/> . greco:AdrianaVivacqua foaf:name "Adriana Santarosa Vivacqua" ; foaf:homepage <http://dcc.ufrj.br/~avivacqua/> . 1 2 3 4 5 6 7 8 9 10 11 12 <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about= "http://greco.ppgi.ufrj.br/resource/Professor/AdrianaVivacqua"> <foaf:name>Adriana Santarosa Vivacqua</foaf:name> <foaf:homepage rdf:resource="http://dcc.ufrj.br/~avivacqua/"/> </rdf:Description> </rdf:RDF> Como se pode observar uma sequência de triplas que compartilham o mesmo sujeito pode ter sua escrita simplificada por meio da separação usando ponto-e-vírgula (;) e omissão deste sujeito. O mesmo ocorre quando ambos o sujeito e o predicado se repetem, mas utilizase a vírgula como separador. O RDF por si só permite apenas descrever recursos na Web, ou seja, não provê mecanismos para descrever um esquema a ser obedecido, como é comum em bancos de dados relacionais e linguagens de programação. Para este fim, foi criado o padrão RDF Schema (RDFS) que permite definir classes (conceitos) e suas propriedades, hierarquias entre classes e propriedades, além dos tipos aceitos no sujeito (rdfs:domain) e intervalos de valores aceitos no objeto (rdfs:range) das triplas. 40 Adicionalmente uma linguagem para representação de ontologias foi proposta. Originalmente usada em filosofia como a disciplina que estuda “a natureza da existência” e “quais tipos de coisas existem”, pesquisadores de IA e da Web adotaram esta palavra para a descrição formal da relação entre termos (conceitos, classes, propriedades) e regras que permitam processos de inferência (deduções lógicas) sobre estes termos (BERNERS-LEE et al., 2001; RUSSELL; NORVIG, 1995). Entre 2001 e 2004 o W3C manteve um grupo de trabalho para desenvolver uma linguagem (e também uma sintaxe baseada em RDF) para descrever ontologias que culminou com a criação da OWL (Web Ontology Language). A OWL se tornou o padrão para representação de ontologias que permite, entre outras funcionalidades, descrever (a) características de simetria, reflexividade e transitividade de propriedades; (b) equivalência e diferença entre classes e instâncias; e (c) operações de interseção, união e complemento sobre classes (que são análogas a conjuntos). A ferramenta capaz de processar ontologias e regras de forma automatizada é denominada motor (ou máquina) de inferência ou reasoner. Há motores de inferência para lógica de descrição (teoria base da OWL), para sistemas de regras ou híbridos. Maiores detalhes sobre DLs e regras serão apresentados na seção 2.3.2 a seguir. SPARQL é a linguagem de consulta para bases de triplas, que tem alguma similaridade com SQL. SPARQL permite a execução de quatro tipos de consulta: SELECT, ASK, DESCRIBE e CONSTRUCT. O primeiro gera resultados no formato de tabelas; o segundo responde uma pergunta com verdadeiro ou falso; o terceiro responde um conjunto de triplas (grafo) sobre determinado recurso (URI); o último utiliza modelos (templates) de triplas e retorna um grafo contendo a união de todos os resultados, funcionando assim, como uma forma de mapeamento. Bases de triplas podem ser consultadas via HTTP por meio do uso de serviços REST que implementem o protocolo SPARQL do W3C (CLARK et al., 2008)7. Tais serviços são conhecidos como SPARQL Endpoints. Há também o SPARQL Update8 para realizar inserções e remoções em bases de triplas, mas ela está fora do escopo deste trabalho. 7 O protocolo para SPARQL 1.0 é uma recomendação e foi citado como referência. A versão para SPARQL 1.1 ainda é um rascunho de trabalho e pode ser encontrada em http://www.w3.org/TR/sparql11-protocol. 8 SPARQL Update - http://www.w3.org/Submission/SPARQL-Update/ 41 2.3.2 Lógica de Descrição (DL) As DLs são formalismos para representação do conhecimento (KR – Knowledge Representation) que sucederam os sistemas de frames e redes semânticas que falhavam em apresentar uma semântica formal (BAADER et al., 2008). Uma semântica formal permite definir uma linguagem ou conjunto de símbolos e operações com interpretações lógicas para conceitos e relações existentes no mundo. A lógica de predicados estuda tais representações formais, através da lógica proposicional, lógica de primeira ordem, entre outras. DL é um subconjunto da lógica de primeira ordem que tenta conciliar expressividade com complexidade e decibilidade, pois parte do princípio que do ponto de vista computacional não adianta ter uma lógica com alta capacidade de expressão se o sistema precisar de quantidades de tempo e espaço astronômicas para responder perguntas, ou nem ser capaz de respondê-las (NARDI; BRACHMAN, 2003). As próximas subseções tentarão apresentar conceitos básicos de DL utilizados na OWL, fazendo analogias para facilitar a compreensão sempre que possível. 2.3.2.1 Conceitos de TBox, ABox e KB Assim como na matemática existem conjuntos, elementos e funções, e na programação orientada a objetos existem classes, instâncias e métodos, DL também possui seus equivalentes. A terminologia, ou seja, o vocabulário do domínio da aplicação consiste de conceitos e relações ou papéis (roles) que podem ser combinados para representar descrições mais complexas. Esta terminologia é denominada TBox (terminological box). Ao especificar os elementos ou indíviduos existentes na aplicação, cria-se o chamado ABox (assertion box) ou conjunto de afirmações sobre fatos do mundo. A união do TBox com o ABox é chamada base de conhecimento ou KB (knowledge base). Desta forma sistemas DL usam o TBox e o conhecimento explícito do ABox para descobrir conhecimento implícito e responder perguntas. (BAADER; NUTT, 2003) Para exemplificar, considere o conceito pai (Father) como uma pessoa (Person) do sexo masculino (Male) que possui pelo menos um filho (hasChild). Isto pode ser representado na notação DL como (TBox): Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person Aqui, o símbolo ⊓ representa a interseção entre conjuntos e a expressão ∃hasChild.Person representa o conjunto de indivíduos que possuem pelo menos uma relação 42 hasChild com algum individuo do conceito pessoa. Suponha agora que o ABox possua as seguintes afirmações dizendo que JOHN e MARY são pessoas, JOHN é do sexo masculino e JOHN tem filha MARY: Person(JOHN) Male(JOHN) Person(MARY) hasChild(JOHN, MARY) Com base nisso alguém poderia perguntar ao KB se JOHN é pai e a resposta seria sim, pois JOHN é Person e Male (interseção) e tem um filho que é Person, satisfazendo a definição de Father. Se a afirmação Male(JOHN) fosse retirada, seria impossível responder à pergunta, mas neste caso surge a questão sobre que resposta deveria ser data pelo sistema: (1) JOHN não é pai, (2) não sei se JOHN é pai. Esta é a grande diferença entre os bancos de dados relacionais e bases de representação de conhecimento. Enquanto o primeiro reponde (1), o segundo responde (2). A primeira forma é dita mundo fechado (closed world assumption), pois considera que toda a informação sobre o mundo está presente na base, e as segunda é dita mundo aberto (open world assumption), pois considera que a base de conhecimento não é completa, ou seja, não possui toda a informação sobre o mundo. DL e OWL usam a hipótese do mundo aberto. Considere agora a adição das seguintes afirmações ao ABox: Father(MARY) ¬Male(MARY) Isto diz que MARY é pai e não é do sexo masculino, mas o TBox diz que todo pai é do sexo masculino, tornado o KB inconsistente. Neste caso foi fácil observar este problema mas conforme a quantidade de indivíduos no KB aumenta se torna impossível descobrir inconsistências sem métodos automatizados. Inconsistência é um dos tipos de problemas de inferência tratados pelos motores de inferência e que serão apresentados na seção 2.3.2.3. 2.3.2.2 Nomenclatura, síntaxe e semântica As DLs são nomeadas conforme os contrutos que oferecem. A DL mais básica é chamada AL (Attributive Language) e conforme mais construtos são adicionados, adicionamse letras ao nome da DL (BAADER; NUTT, 2003). A linguagem ALC (Attribute Language with Complements), por exemplo, é a adição de negação (complementos) à AL. Muitas vezes uma mesma linguagem possui mais de um nome, por exemplo, ALC é equivalente a ALUℰ e S é equivalente à ALC R+. A partir daqui será usada uma convenção de letras: A e B serão usadas para representar conceitos atômicos ou primitivos, C e D para descrições de conceitos 43 (definidos com base em outros), r e s para relações atômicas. Um conceto-ALC é definido como: ⊤ – conceito universal (contém todos os indivíduos); ⊥ – conceito vazio (não contém indivíduos); C ⊓ D – interseção dos indivíduos dos conceitos C e D C ⊔ D – união dos indivíduos dos conceitos C e D ¬C – indivíduos que não estão em C ∃r.C – indivíduos que possuem pelo menos uma relação r com um indivíduo de C (quantificação existencial completa) ∀r.C – indivíduos que se possuírem uma relação r esta é apenas com indivíduos de C (restrição de valor) Uma interpretação I = (ΔI, •I) consiste de um conjunto de indivíduos ΔI (domínio da interpretação) e uma função •I que mapeia todo conceito-ALC a um subconjunto de ΔI e todo nome de relação a um subconjunto de ΔI × ΔI (BAADER et al., 2008). Desta forma, pode-se escrever a interpretação matemática de qualquer conceito-ALC. Veja alguns exemplos: ⊤I = ΔI ⊥I = ∅ (C ⊓ D) I = CI ∩ DI (∃r.C) I = {x ∈ ΔI | Existe algum y ∈ ΔI tal que (x, y) ∈ rI e y ∈ CI } (∀r.C) I = {x ∈ ΔI | Para todo y ∈ ΔI, se (x, y) ∈ rI então y ∈ CI } Um axioma é uma afirmação sobre o mundo e pode ser terminológico ou assertivo, dependendo se tratam de conceitos ou indivíduos. O axioma terminológico pode ser: Inclusão de conceitos (hierarquia): C ⊑ D Inclusão de relações (hierarquia): r ⊑ s Equivalência de conceitos: C ≡ D Equivalência de relações: r ≡ s Já o axioma assertivo ou fato pode ser da forma C(a), r(a, b), a = b e a ≠ b. O TBox é o conjunto de axiomas terminológicos e o ABox o conjunto de axiomas assertivos. Uma interpretação I é um modelo de um axioma C ⊑ D se CI ⊆ DI, e um modelo de um TBox se é um modelo de todos os axiomas deste TBox. Uma interpretação I é um modelo de um axioma assertivo C(a) se aI ∈ CI, e um modelo de um ABox se é um modelo de todos 44 os axiomas deste ABox. Analogamente, uma interpretação I é um modelo para uma base de conhecimento se é um modelo tanto do seu TBox quanto do seu ABox. Desta forma, aproveitando o exemplo anterior, uma interpretação I 1 = (Δ1I, •1I), onde: Δ1I = {JOHNI, MARYI} •1I = { Person1I = {JOHNI, MARYI}, Male1I = {JOHNI}, Father1I = {JOHNI}, hasChild1I = {(JOHNI, MARYI)} } é um modelo para a base de conhecimento formada pelo TBox: Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person e pelo ABox: Person(JOHN) Male(JOHN) Person(MARY) hasChild(JOHN, MARY) Esta outra interpretação I 2 = (Δ2I, •2I) também é um modelo para este mesmo KB: Δ2I = {JOHNI, MARYI} •2I = { Person2I = {JOHNI, MARYI}, Male2 I = {JOHNI}, Father2I = {JOHNI}, hasChild2I = {(MARYI, MARYI)} } contudo não deveria, pois MARY é filha dela mesma. Isto ocorre porque não há um axioma restritivo que diga que a propriedade hasChild é irreflexiva. Este é um problema gerado pela falta de expressividade da linguagem utilizada (ALC). Existem inúmero outros problemas semelhantes que foram resolvidos a partir de DLs mais expressivas. Algumas desteas extensões serão apresentadas na seção 2.3.2.4. 2.3.2.3 Problemas de inferência Na seção 2.3.2.1 foi mostrado um exemplo de incosistência do KB. O algoritmo de Tableau resolve este e outros problemas comuns. Nesta seção estes problemas serão 45 apresentados com base nos conceitos de interpretação e modelo. Para isso considere um KB K = (T, A) onde T é um TBox e A um ABox, conceitos C e D, indivíduos a e b e uma relação r. Consistência: K é consistente se ele possui um modelo; Satisfatibilidade: C é satisfatível em relação a K se existe um modelo I de K com CI ≠ ∅ (I é um modelo de C em relação a K ) e escreve-se K ⊨ C ≢ ⊥; Subsumption9: C é subconjunto de D (C ⊑ D) em relação a K se CI ⊆ DI para todos os modelos I de K (escreve-se K ⊨ C ⊑ D, ou seja, C ⊑ D é provável a partir de K); Equivalência: C e D são equivalentes em relação a K se um é subconjunto do outro, ou seja, CI = DI para todos os modelos de I de K (escreve-se K ⊨ C ≡ D); Disjunção: C e D são disjuntos em relação a K se CI ∩ DI = ∅ para todos os modelos I de K e escreve-se K ⊨ C ⊓ D ≡ ⊥; Instância: a é instância de C em relação a K se aI ∈ CI para todos os modelos I de K e escreve-se K ⊨ C(a). Analogamente, (a,b) é instância de r em relação a K if (aI,bI) ∈ r para todos os modelos I de K e escreve-se K ⊨ r(a,b). Trabalhos mostram que estes problemas podem ser reduzidos a apenas um deles (BAADER; NUTT, 2003; HORROCKS, I et al., 2006). Por exemplo, a redução à subsunção (reduction to subsumption) apresenta as seguintes transformaçoes: (i) C ≡ ⊥ ⇔ C ⊑ ⊥; (insatisfatibilidade) (ii) C ≡ D ⇔ C ⊑ D e D ⊑ C; (equivalência) (iii) C ⊓ D ≡ ⊥ ⇔ (C ⊓ D) ⊑ ⊥. (disjunção) Há também a redução à insatisfatibilidade (reduction to unsatisfiability) que é utilizada no algoritmo Tableau: 9 (i) C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥ (subsumption) (ii) C ≡ D ⇔ (C ⊓ ¬D) ≡ ⊥ e (¬C ⊓ D) ≡ ⊥ (equivalência) (iii) (C ⊓ D) ⊑ ⊥ ⇔ C ⊓ D ≡ ⊥ (disjunção) Subsumption significa, na filosofia, ato de um objeto cair sob um conceito. Nada mais é que a relação de subconjunto, contudo, decidiu-se por não criar uma tradução para o termo. 46 Qualquer um destes pode ser reduzido à consistência do KB. Para isso, considere que se queira saber se C é um subconjunto de D com relação a K (K ⊨ C ⊑ D). Usando a redução à insatisfatibilidade (i), sabe-se que C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥ (veja Figura 3). Portanto, isto equivale a verificar se um KB K’ = (T, A ⋃ { (C ⊓ ¬D)(x) }) é inconsistente para algum indivíduo x. Para isso, o algoritmo tenta construir um modelo para K’ utilizando regras de expansão para lidar com os construtos da linguagem, verificação de condições conflitantes para descobrir inconsistência e bloqueios para impedir aplicações infinitamente repetitivas das regras de expansão. Se um modelo for obtido significa que a interseção não é vazia, logo C não é subconjunto de D; caso contrário, C é subconjunto de D. O algoritmo deve considerar que C e D podem ser descrições de conceitos complexas com quantificação existencial, negação, união, interseção ou quaisquer outros construtos existentes em linguagens mais expressivas que a ALC. Um problema investigado antes de aumentar a expressividade (i.e. adicionar um novo construto) de uma DL é verificar se a linguagem continua decidível, ou seja, se é possível adicionar regras de expansão e bloqueios ao algoritmo de forma que ele sempre termine. Para maiores detalhes recomenda-se ler (BAADER et al., 2008; BAADER; NUTT, 2003). C ⊓ ¬D ≢ ⊥ C⊑D ⇔ C ⊓ ¬D ≡⊥ ¬D D C ¬D C D Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅. 2.3.2.4 Extensões da linguagem ALC Conforme já discutido, a linguagem ALC possui baixa expressividade para representação de conhecimento. Por este motivo vários trabalhos com o intuito de prover novas funcionalidades mantendo decidibilidade foram feitos, chegando-se ao que é apresentado no Quadro 3 que resume construtos e axiomas existentes em diversas DLs e que são usados em OWL-DL. O quadro apresenta descrição, notação, nomenclatura e se é um axioma ou construto. Pode-se verificar que AL contém os conceitos universal e vazio, assim 47 como negação atômica, interseção, restrição de valor, quantificação existencial limitada e equivalência e hierarquia de conceitos. Expressividades adicionais incluem quantificação existencial completa (ℰ), complemento (C ), união de conceitos (U), restrições de número qualificadas (Q ) ou não (N ), transitividade (R+), inversibilidade (I), equivalência e hierarquia (H) de relações, e inclusão de relações complexas para composição de relações (R ). Dentre elas podem-se destacar as restrições de número a composição de relações. As primeiras representam subconjuntos de ΔI cujos indivíduos devem possuir uma quantidade mínima ou máxima de ocorrências numa dada relação. Estas restrições podem ser qualificadas ou não. Exemplo: 1. Parent ≡ ≥1hasChild 2. Orphan ≡ ≥1hasParent.Dead ⊓ ≤2hasParent.Dead A primeira é uma restrição de número não qualificada pois diz que para um indivíduo (p.ex. JOHN) ser pai/mãe basta que ele tenha ao menos um par na relação hasChild. Assim, para uma afirmação hasChild(JOHN, MARY) não há exigência de que MARY pertença a qualquer conceito. O segundo exemplo é uma relação qualificada pois diz que para um indivídio ser órfão deve existir uma ou duas afirmações do tipo hasParent cujo segundo elemento é falecido. A composição de relações permite fazer um processo similar ao de composição de funções: 1. hasParent ∘ hasParent ≡ hasGrandParent 2. owns ∘ hasPart ≡ owns A primeira mostra relação hasGrandParent como a composição da relação hasParent e a propriedade owns como composição entre a relação owns e hasPart. Na primeira, se o ABox tiver hasParent(JOHN, MARY) e hasParent(MARY, ANNA) pode-se inferir a relação hasGrandParent(JOHN, ANNA). A segunda é semelhante: owns(PETER, CAR) e hasPart(CAR, ENGINE) então owns(PETER, ENGINE). Assim como existe o TBox para os conceitos e o ABox para indivíduos, na linguagem SROIQ existe o RBox que contém os axiomas para relaçõs, como estes dois descritos. Por fim, cabe relembrar que a nomenclatura ALC é equivalente a ALUℰ e S é equivalente à ALCR+, Portanto SROIQ é ALCR+ com nominais (O), inversibilidade de relação (I) e restrição de número qualificada (Q). Uma extensão importante é a adição de tipos de dados (inteiro, string, data, etc.) e representada pela adição de (D) ao nome da linguagem (HORROCKS, I et al., 2001). 48 Quadro 3. Lista de expressividade de diversas DLs atuais. Descrição Notação Nomenclatura Tipo Conceito universal ⊤ AL Construto Conceito vazio ⊥ AL Construto ¬A AL Construto Interseção de conceitos C⊓D AL Construto Restrição de valor ∀r.C AL Construto Quantificação existencial limitada ∃r.⊤ AL Construto Hierarquia de conceitos C⊑D AL Axioma Equivalência entre conceitos C≡D AL Axioma Quantificação existencial completa ∃r.C ℰ Construto Negação ou complemento ¬C C Construto C⊔D U Construto Tr(r), r+ ⊑ r R+ Axioma ≥n r, ≤n r N Construto ≥n r.C, ≤n r.C Q Construto ≤1 r F Construto r¯ I Construto r ≡ s, r ⊑ s ⊓ s ⊑ r H Axioma r⊑s H Axioma r1 ∘ r2 ⊑ s R Axioma Reflexividade local ∃r.Self R Construto Reflexividade global ⊤ ⊑ ∃r.Self R Construto {a1, a2, ..., an} O Construto - (D) - Negação atômica União de conceitos Transitividade de relação Restrições de número Restrições de número qualificadas Propriedades funcionais Inversibilidade de relação Equivalencia entre relações Hierarquia de relações Inclusão de relações complexas (cadeia ou composição de relações) Nominals (indivíduos no TBox) Tipos de dados 49 2.3.2.5 Regras DL-seguras DLs, apesar de possuírem um relativamente rico conjunto de construtos para conceitos, possuíam grandes limitações com respeito à expressividade de propriedades. Estas limitações eram maiores antes das DLs SROIQ (D), pois não permitiam representação de composição nem reflexividade de relações. Por outro lado, sistemas de processamento de regras (cláusulas de Horn) permitem estabelecer os mais variados tipos de relações (propriedades) entre indivíduos. Sendo assim, surgiram propostas para adicionar regras a motores de inferência DL, contudo, estas abordagens tornavam a linguagem resultante indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004). Propostas posteriores passaram a utilizar as chamadas regras DL-seguras (DL-safe rules) que garantem decidibilidade do processo de inferência. A seguir, apresentar-se-á a definição geral de regra, regras DL e DL-seguras. Um termo é uma constante (a, b, c) ou uma variável (x, y, z). Um átomo tem a forma P(t1, ... , tn), onde t1 a tn são termos. Um literal é um átomo ou um átomo negado. Assim, uma regra ou cláusula de Horn segue a forma H ← B1, ..., Bn ou B1, ..., Bn → H onde H e B1 a Bn são átomos; H é dita a cabeça ou consequente da regra e B1 a Bn é o corpo ou cauda ou antecedente da regra. Regras podem ser vistas como IF-THEN (SE antecedente ENTÃO consequente), ou seja, o antecedente representa uma condição e o consequente as informações que serão adicionadas ao KB quando a condição é satisfeita. Um conjunto finito de regras é chamado um programa. Uma regra-DL é obtida restringindo átomos para os chamados átomos-DL que podem ser da forma C(t) ou R(s, t). Um conjunto de regras-DL forma um programa-DL. (KOLOVSKI et al., 2006) Como esta definição é possível expressar necessidades de modelagem não permitidas nas DLs convencionais, como apresentado nos dois exemplos a seguir: (i) hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y), Female(y) (ii) hasCurrentActivity(x, MeetingSupervisor) ← Person(x), Person(y), Location(z), hasSupervisor(x, y), hasOffice(y, z), hasCurrentLocation(x, z) A regra (i) diz que se um indivíduo x tem um ancestral direto (pai ou mãe) z que possui uma irmã y então y é tia de x (MOTIK et al., 2005). A regra (ii) apresenta um exemplo de inferência de contexto da atividade de uma pessoa, pois diz que se uma pessoa x é 50 supervisionada por uma pessoa y e x se encontra no mesmo local que o escritório de y, então x está praticando a atividade “reunião com seu supervisor” (WANG, X.; DONG, J. S. et al., 2004). OWL 1 DL (SHOIN ) não possui construtos nativos para nenhuma das duas regras, enquanto OWL 2 DL (SROIQ ) possui construtos apenas para a regra (i) (RIBONI; BETTINI, 2011b). Isto mostra a importância da extensão de DLs com regras. Tanto DLs quanto linguagens de regras (LP e RETE) são fragmentos decidíveis da lógica de primeira ordem, contudo a simples união de ambas torna a linguagem resultante indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004; MOTIK et al., 2005). A decidibilidade de DLs é mantida pela propriedade modelo de árvore, que diz que um conceito tem um modelo se, e somente se, suas propriedades definem um grafo direcionado na forma de árvore (GROSOF et al., 2003). Esta propriedade é comprometida quando surgem árvores com ramos que possuam cadeias infinitas. Veja o seguinte KB: Person ⊑ ∃father.Person Person(JOHN) isto resulta em uma cadeia infinita de pais desconhecidos (indivíduos anônimos), pois diz que toda pessoa possui um pai que é uma pessoa, logo este pai também tem um pai que é uma pessoa, e assim sucessivamente. Transitividade de relações também compromete este modelo, contudo ambos os casos são resolvidos com bloqueios que impedem aplicações repetitivas de regras de expansão. Ao adicionar regras esta propriedade das DLs é perdida, além disso, como reasoners DL tipicamente produzem indivíduos anônimos dentro de um domínio possivelmente infinito (ex. Person ⊑ ∃father.Person) e regras são universalmente quantificadas (i.e., aplicam-se a todos os indivíduos do domínio) isto dificulta a inferência e torna o KB indecidível (KRISNADHI et al., 2011). Para evitar problemas causados pelo uso de regras-DL, foi criado o conceito de regras-DL-seguras. Uma regra-DL-segura é uma regra-DL tal que todas as suas variáveis ocorrem em um átomo não-DL no corpo da regra. Assim, as regras (i) e (ii) não são regras-DL-seguras, mas se tornam DL-seguras ao adicionar (a) um átomo unário não-DL, O(x), ao corpo da regra para cada variável existente na regra e (b) um fato O(a) para cada indivíduo existente no KB e no programa. Exemplificando, a regra (i) ficaria da seguinte forma: 51 (i) hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y), Female(y), O(x), O(y), O(z) O reflexo na expressividade e semântica desta restrição pode ser facilmente verificado com o exemplo a seguir. Considere o seguinte KB: father ∘ father¯ ⊑ sibling ∃father.(∃father¯.{CAIN})(ABEL) O primeiro axioma diz que indivíduos com o mesmo pai são irmãos (ignore o fato de o axioma permitir que uma pessoa seja irmã dela mesma) e o segundo diz que CAIN e ABEL possuem o mesmo pai. Ao questionar se CAIN e ABEL são irmãos, o motor de inferência diria que sim. Agora considere trocar o primeiro axioma pela regra: sibling(x,y) ← father(x, z), father(y, z), O(x), O(y), O(z) A mesma pergunta teria resposta “não sei”, pois o motor de inferência não criaria um indivíduo anônimo representando o pai de CAIN e ABEL para casar com a variável z da regra. Para que tal regra funcionasse como desejado, seria necessário explicitar quem é o pai de ambos, que poderia ser feito apenas desmembrando o segundo axioma ou substituindo-o por relações father entre ABEL, CAIN e ADAM: (a) ∃father.{ADAM}(ABEL) ∃father¯.{CAIN}(ADAM) (b) father(ABEL, ADAM) father(CAIN, ADAM) Apesar de esta restrição parecer incoveniente ela evita que regras propaguem relações indesejadas, que resultariam numa possível alteração desconhecida do TBox. Considere o KB10: A ≡ ∃R.B A(c) C ≡ ∃R.{c} R(a, b) R(b, c) A Figura 4 mostra um grafo (à esquerda) representando este KB. Note que o indivíduo c foi classificado como uma instância de C, pois há uma propriedade R que relaciona b e c. O ABox diz que o indivíduo c pertence ao conceito A, logo infere-se que existe um indivíduo 10 Adaptado de http://weblog.clarkparsia.com/2007/08/27/understanding-swrl-part-2-dl-safety/ 52 anônimo x pertencente ao conceito B que se relaciona com c através da relação R. Considere agora a adição de uma regra não-DL-segura para transitividade da relação R: R(x, y) ← R(x, z), R(z, y) Isto leva ao grafo na parte direita de figura que mostra que a, b, c e um possível x se relacionam por R. Além diso, b passa a ser também instância de A, e a passa a ser instância de A e C. Contudo, não apenas a e b se tornam instâncias de A e C, mas também todas as possíveis instâncais de C. Veja, por exemplo, que adição de um indivíduo y do tipo C resulta nas arestas tracejadas e classifica y também como instância de A (≡ ∃R.B). Logo, tem-se um novo axioma C ⊑ A não existente no TBox. Este é apenas um exemplo e o uso de regras nãoDL-seguras pode gerar muitos outros problemas. Assim, a aplicação das regras restringe-se aos indivíduos explicitamente existentes no KB (neste caso a, b e c). O reasoner Pellet implementa o algoritmo de Tableau para SROIQ (D) e o estende para aceitar regras SWRL DL-seguras usando um subconjunto decidível da SWRL (KOLOVSKI et al., 2006). O reasoner Jena não é um motor de inferência OWL DL, mas sim um sistema de processamento de regras que podem ser forward- ou backward-chaining, ou ambos (híbrido). Forward-chaining parte da condição (corpo) para então adicionar de forma concreta estes novos fatos na base utilizando o algoritmo RETE (FORGY, 1982). Backwardchaining descobre nova informação baseado em objetivo, ou seja, procura regras que possuam um dado objetivo no consequente e cujo antecedente seja confirmado pelos dados do KB, utilizando algoritmo de programação lógica (Logic Programming) como resolução (também aplicada em Prolog). Portanto, a primeira materializa os novos dados e a segunda aguarda uma pergunta sobre um consequente para então verificar se os dados da base o confirmam. (EITER et al., 2008) 53 a {} a R b { ∃R.{c}, C, ∃R.B, A } R { ∃R.{c}, C } R ⇒ R b { ∃R.{c}, C } ∪ { ∃R.B, A } R R y { C, ∃R.{c}, ∃R.B, A } R c { ∃R.B, A } R c { ∃R.B, A } C⊑A R x R R {B} x {B} Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações imprevistas no TBox. Apesar de este trabalho utilizar apenas os motores de inferência Jena e Pellet, existem inúmeros outros. Dentre os disponíveis para OWL, pode-se mencionar FaCT++, HermiT, RacerPro, JESS, Hoolet, KAON2, OWLIM. Jena, JESS e OWLIM são baseados em regras; Hoolet utiliza um algoritmo de prova para lógica de primeira ordem; Pellet, FaCT++ e RacerPro são baseados em Tableau mas enquanto os dois primeiros suportam SROIQ(D), o último suporta apenas SHIQ(D); KAON2 usa resolução para SHIQ(D); HermiT utiliza o algoritmo Hypertableau, uma variante do Tableau, também para SROIQ(D). (DENTLER et al., 2011; LIANG; KIFER, 2009; SINGH; KARWAYUN, 2010) 2.3.3 Web Ontology Language (OWL) A linguagem OWL, cuja sigla foi construída de forma invertida, nada mais é que uma lógica de descrição com uma sintaxe variante, ou seja, mapeia os construtos e axiomas apresentados na coluna “Notação” do Quadro 3 para uma sintaxe RDF. OWL Lite é uma DL com expressividade SHIF (D), OWL DL é SHOIN (D) e OWL 2 DL é SROIQ (D) (HORROCKS, I et al., 2006; HORROCKS, IAN et al., 2003). Portanto, considerando-se ZX como o conjunto de construtos/axiomas suportados por uma dada versão X da OWL, pode-se dizer que ZOWL-Lite ⊂ ZOWL-DL ⊂ ZOWL2-DL. Os Quadros 4 e 5 mostram como construtos da notação DL padrão são mapeados para sintaxe OWL e foram montadas por meio de consultas a diversos artigos e recomendações do 54 W3C (ANTONIOU; HARMELEN, FRANK VAN, 2009; EITER et al., 2008; GOLBREICH; WALLACE, 2009; MCGUINNESS; HARMELEN, FRANK VAN, 2004; MOTIK et al., 2009). Os construtos e axiomas que contém OWL Lite marcado com asterisco permitem apenas classes ou restrições nomeadas, ou seja, não permite expressões usando construtos como C ⊓ D. Para facilitar o entendimento do quadro, o KB apresentado anteriormente será transformado para OWL. Assim, o conceito Father do TBox: Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person é a interseção entre três conceitos e pode ser escrito em Turtle como: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 @prefix : <http://exemplo.com/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl:<http://www.w3.org/2002/07/owl#> . :Person a owl:Class . :Male a owl:Class . :hasChild a owl:ObjectProperty . :Father a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:intersectionOf ( :Person :Male [ a owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] ) ] . onde as linhas 5 e 6 definem que os termos Person e Male são classes e a linha 7 define que o termo hasChild é um propriedade. As linhas 9 a 17 definem a equivalência entre um novo conceito Father e a interseção entre os dois conceitos anteriores (Person e Male) e uma restrição de quantificação existencial completa ∃hasChild.Person. Os fatos do ABox são definidos da seguinte forma: 18 :JOHN rdf:type :Person , 19 :Male ; 20 :hasChild :MARY . 21 :MARY rdf:type :Person . 55 Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam. Construtos Notação DL Sintaxe OWL Versão OWL C1 ⊓ ... ⊓ Cn [] rdf:type owl:Class ; owl:intersectionOf (C1 ... Cn) . OWL DL/Lite* C1 ⊔ ... ⊔ Cn [] rdf:type owl:Class ; owl:unionOf (C1 … Cn) . OWL DL ¬C [] rdf:type owl:Class ; owl:complementOf C . OWL DL {a1, … an} [] rdf:type owl:Class ; oneOf (a1 … an) . OWL DL ∀P.C [] rdf:type owl:Restriction; owl:onProperty P ; owl:allValuesFrom C . OWL Lite ∃P.C [] rdf:type owl:Restriction; owl:onProperty P ; owl:someValuesFrom C . OWL Lite ∃P.{a} [] rdf:type owl:Restriction; owl:onProperty P ; owl:hasValue a . OWL DL ≥n P [] rdf:type owl:Restriction; owl:onProperty P ; owl:minCardinality n . OWL DL OWL Lite (n=0,1) ≤n P [] rdf:type owl:Restriction; owl:onProperty P ; owl:maxCardinality n . OWL DL OWL Lite (n=0,1) ≥n P.C [] rdf:type owl:Restriction; owl:onProperty P ; owl:minQualifiedCardinality n ; owl:onClass C . OWL 2 DL ≤n P.C [] rdf:type owl:Restriction; owl:onProperty P ; owl:maxQualifiedCardinality n ; owl:onClass C . OWL 2 DL ≥n P.D [] rdf:type owl:Restriction; owl:onProperty P ; owl:minQualifiedCardinality n ; owl:onDataRange D . OWL 2 DL ≤n P.D [] rdf:type owl:Restriction; owl:onProperty P ; owl:maxQualifiedCardinality n ; owl:onDateRange D . OWL 2 DL R¯ [] owl:inverseOf R . OWL Lite ⊤ owl:Thing OWL Lite ⊥ owl:Nothing OWL Lite 56 Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam Axiomas Notação DL Sintaxe OWL Versão OWL C1 ⊑ C2 C1 rdfs:subClassOf C2 . OWL DL/Lite* C1 ≡ C2 C1 owl:equivalentClass C2 . OWL DL/Lite* P1 ⊑ P2 P1 rdfs:subPropertyOf P2 . OWL DL/Lite* P1 ≡ P2 P1 owl:equivalentProperty P2 . OWL DL/Lite* C1 ⊓ C2 ≡ ⊥, C1 ⊑ ¬C2 C1 owl:disjointWith C2 . OWL DL C1 ⊓ ... ⊓ Cn ≡ ⊥ [] rdf:type owl:AllDisjointClasses ; owl:members ( C1 .. Cn) . OWL 2 DL P1 ⊓ ... ⊓ Pn ≡ ⊥ [] rdf:type owl:AllDisjointProperty ; owl:members ( P1 .. Pn) . OWL 2 DL C ≡ C1 ⊔ ... ⊔ Cn e Ci ⊓ Ck ≡ ⊥, onde 1≤i,k≤n e i≠k C owl:disjointUnionOf (C1 ... Cn) . OWL 2 DL ⊤ ⊑ ∀P¯.C P rdfs:domain C . OWL Lite ⊤ ⊑ ∀P.C P rdfs:range C . OWL Lite P ≡ P¯ P rdf:type owl:SymmetricProperty . OWL Lite ⊤ ⊑ ≤1 P P rdf:type owl:FunctionProperty . OWL Lite ⊤ ⊑ ≤1 P¯ P rdf:type owl:InverseFunctionProperty . OWL Lite Tr(P) ou P+ ⊑ P P rdf:type owl:TransitiveProperty . OWL Lite ∃P.Self P rdf:type owl:ReflexiveProperty . OWL 2 DL P1 ∘ ... ∘ Pn ⊑ P P owl:propertyChainAxiom (P1 ... Pn) . OWL 2 DL P1 ≡ P2 P1 owl:equivalentProperty P2 . OWL Lite {a1} ≡ {a2} ou a1 = a2 a1 owl:sameAs a2 . OWL Lite {a1} ≢ {a2} ou a1 ≠ a2 ou {a1} ⊑ ¬{a2} a1 owl:differentFrom a2 . OWL Lite C(a) a rdf:type C . OWL Lite P(a,b) a P b . OWL Lite 57 2.3.4 Trabalhos de publicação em LOD Muitos trabalhos têm explorado o uso das tecnologias da Web Semântica para descrever e publicar tanto dados de sensores quanto dados estáticos. Redes de sensores vêm sendo utilizadas como fontes de dados de temperatura, umidade, pressão, etc. (GONG et al., 2011; SZEWCZYK et al., 2004) e, uma vez inseridas na Web Semântica, podem ser largamente utilizadas como fonte de dados de contexto. O W3C, por exemplo, abriu um grupo de trabalho que estudou várias ontologias e produziu a Semantic Sensors Networks (SSN) Ontology para descrever estas redes (COMPTON et al., 2009; NEUHAUS; COMPTON, 2009). Dois grandes esforços de publicação de dados em RDF/SPARQL são o Linked Open Data (LOD) e o Linked Stream Data (LSD). O primeiro é uma iniciativa para publicar dados ligados e abertos (BIZER, 2009), que podem ser estáticos ou semi-estáticos (mudam com baixa frequência). Dentre os dados publicados, pode-se destacar DBPedia.org (dados da Wikipédia), LinkedGeoData.org (do OpenStreetMaps), GeoNames11 e Linked Movie Database (do Internet Movie Database). O termo LOD pode ser simplificado para Linked Data quando se tratar de dados privados (por exemplo, dados sigilosos de uma empresa acessíveis apenas por aplicações usadas por funcionários). Neste trabalho, a sigla LOD continuará sendo usada para evitar confusão com o termo lógica descritiva (LD). A iniciativa LSD foi introduzida por Sequeda e Corcho (SEQUEDA; CORCHO, 2009) e propõe uma forma de identificar e acessar streams de dados oriundos de redes de sensores. Uma implementação é mostrada por Le-Phuoc et al. (LE-PHUOC et al., 2011) que apresenta o Linked Stream Middleware (LSM), capaz de publicar dados provenientes de uma grande quantidade de sensores. A maioria das publicações ainda é feita ad hoc por meio de programas e scripts, mas arquiteturas começam a aparecer, como mostrado em Cordeiro et al. (CORDEIRO et al., 2011), que apresenta uma arquitetura de publicação baseada na ferramenta de ETL Kettle. Apesar da quantidade de acervos publicados estar aumentando significativamente desde o início das iniciativas, ainda há diversas questões em aberto (JAIN et al., 2010). Contudo, esta alta atividade sugere que estas questões serão abordadas em breve e que bases de dados maiores e de melhor qualidade irão, em breve, prover informação útil, aberta e de forma padronizada para aplicações cientes de contexto. No âmbito nacional, o fato que 11 GeoNames – geonames.org 58 corrobora esta afirmação é a assinatura por parte da Presidenta Dilma Roussef, em setembro de 2011 (DOU 16/09/2011), do decreto que institui o “Plano de Ação Nacional sobre Governo Aberto” (SCHULZE, 2011), fortalecendo ainda mais a crescente tendência de publicação de dados públicos em prol de um governo mais transparente. Em condições ideais, órgãos do governo (Bombeiro, Polícia, Defesa civil, etc.) publicam os seus dados de domínio público, permitindo assim seu consumo automatizado, seja por outras agências do governo ou por cidadãos. 2.4 Trabalhos relacionados 2.4.1 Frameworks para aplicações cientes de contexto Diversas abordagens para modelagem e inferência de contexto já foram propostas na literatura. As primeiras utilizavam pares chave-valor, linguagem de marcação (ex. XML) e modelos relacionais e/ou orientados a objetos. Alguns trabalhos se valeram de Object Role Mapping (ORM), outros de ontologias (OWL) e outros construíram modelos híbridos (BETTINI et al., 2010). Nesta seção, algumas destas arquiteturas serão descritas e comparadas. A arquitetura Hydrogen (HOFER et al., 2002) propõe um modelo de contexto orientado a objetos, dividido em três camadas onde contextos de diversos dispositivos são compartilhados usando um modelo P2P dispensando o uso de servidores remotos. A camada Adapter é responsável por ler dados dos sensores físicos e passar para o ContextServer que armazena e possibilita leituras concorrentes por parte de diversas aplicações que podem estar no mesmo dispositivo ou não (via P2P). Context-Aware Sub-Structure (CASS) é uma arquitetura para dispositivos móveis baseada em um servidor centralizado (FAHY; CLARKE, 2004). Eles separam código da aplicação e inferência de contexto com o objetivo de simplificar o código e evitar recompilação a cada modificação de regras (extensibilidade). Segundo esta arquitetura, sensores são anexados a nós (dispositivos móveis ou estáticos) que se comunicam com servidores via redes sem fio. Utiliza um banco de dados relacional para armazenamento de dados e regras. Context Management Framework é apresentado por Korpipaa et al. (KORPIPAA et al., 2003). Ele é capaz de reconhecer contexto em tempo real na presença de incerteza, ruído e informações dinâmicas, e roda em um dispositivo móvel com Symbiam OS. Os valores 59 obtidos dos diversos sensores são quantizados (fuzzy ou crisp) e contextos de baixo nível são descobertos baseado numa ontologia em RDF predefinida. Contextos de mais alto nível são derivados usando classificadores Bayesianos. Como resultado, reconhecem mais de 80 contextos com acuraria de 96% em ambientes controlados e 87% no mundo real. A arquitetura CORTEX utiliza bases relacionais, redes Bayesianas e o sistema CLIPS para construção do motor de inferência (BIEGEL; CAHILL, 2004). Diferentemente dos demais, nesta arquitetura cada componente pode ser consumidor e produtor de informação além de poderem ser organizados de forma descentralizada e em uma rede hierárquica, como na arquitetura aqui proposta. Contudo, todas estas arquiteturas apresentam a desvantagem de não poderem ser facilmente integradas no ambiente Web, devido a não utilização de padrões abertos do W3C. As duas abordagens a seguir, embora não foquem em disponibilidade na Web, merecem maior destaque por adotarem padrões da Web Semântica. Gu et al. (GU et al., 2005) apresenta a arquitetura SOCAM (Service-Oriented ContextAware Middleware) que é organizada em três camadas (Figure 5): Context Application Layer, Context Middleware Layer e Context Sensing Layer. Na última, localizam-se sensores físicos e virtuais e na de aplicação os agentes, serviços e aplicações que utilizam contextos obtidos da camada intermediária. A camada intermediária, Context Middleware Layer, é o núcleo da arquitetura, funcionando como um servidor centralizado capaz de deduzir contexto de mais alto nível. Mais precisamente, é composta pelos Provedores de Contexto internos e externos que obtém dados dos sensores físicos e virtuais respectivamente e os converte em representações RDF/OWL para serem compartilhadas e reusadas. Também possui o Interpretador de Contexto composto por uma base de conhecimento (KB) e um motor de inferência responsável por processar os dados de contexto de baixo nível oriundos dos Provedores de Contexto e inferir contexto de alto nível (com base nas ontologias e em regras do usuário) assim como detectar inconsistências no KB. A comunicação entre seus componentes é feita por meio de uma API que usa Java RMI (Remote Method Invocation). Sua modelagem de contexto utiliza ontologias em dois domínios específicos: veículos e smart home. Os autores apresentam a ideia de ontologia genérica e específica, onde a primeira estaria sempre em memória e a segunda seria carregada e descarregada conforme necessário. Assim, a ontologia de smart home não é carregada enquanto o usuário estiver em seu carro. A inferência é baseada em lógica de primeira ordem e implementada usando a ferramenta Jena2. Eles analisaram a desempenho da inferência usando Jena e concluíram que 60 o processo é bastante intensivo computacionalmente e pode ser um gargalo em computação “pervasiva”, no entanto, é aceitável para aplicações onde o tempo não é crítico. Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005). Por fim, a arquitetura CoBrA (Context Broker Architecture) pretende apoiar a aquisição, inferência e compartilhamento de conhecimento de contexto em ambientes inteligentes (CHEN, H.; FININ, T. et al., 2004). Ela está baseada nos conceitos de agente e broker. Agente é uma entidade capaz de executar alguma tarefa, como aplicações de usuários, serviços providos por dispositivos, e serviços Web. Nesta arquitetura, o context broker é um agente especial capaz de gerenciar partes de um espaço inteligente e compartilhar modelos contextuais entre diversos agentes seguindo uma política de privacidade. O broker é um dispositivo rico em recursos computacionais capaz de processar as informações dos agentes ao seu redor. Para aplicações em larga escala como um campus universitário é possível usar múltiplos brokers para formar uma federação de brokers organizados numa forma P2P ou hierárquica. Assim como no SOCAM, foi desenvolvida uma ontologia específica para seu domínio, neste caso, uma sala de reuniões inteligente capaz de representar locais, agentes e seus contextos. Não aborda disponibilização na Web, comentando apenas, sobre a linguagem de consulta RDQL, que é predecessora do SPARQL e não mais mantida nem recomendada. A arquitetura do Context Broker é dividida em quatro componentes conforme apresentado a seguir (estes e os possíveis agentes ao seu redor podem ser visto na Figura 6): Context Knowledge Base (Base de Conhecimento de Contexto): uma área para armazenamento das informações de contexto do espaço inteligente. 61 Context Reasoning Engine (Motor de Inferência de Contexto): responsável por “raciocinar” sobre a base tanto para inferir novas informações quanto para manter a consistência do KB. Context Acquisition Module (Módulo de Aquisição de Contexto): responsável por adquirir informações de fontes externas como sensores físicos, serviços Web, bancos de dados, dispositivos e agentes. Privacy Management Module (Módulo de Gerenciamento de Privacidade): responsável por aplicar regras de privacidade definidas pelo usuário a fim de evitar compartilhamento de informações indesejadas. Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003) O trabalho apresentado por Lee & Meier (LEE; MEIER, 2009) apresenta uma arquitetura baseada em um modelo híbrido de contexto que permite organização descentralizada, em forma de rede para o domínio de transporte. Para isso, propõem uma mesclagem entre um modelo de contexto orientado a objetos e outro ontológico, de forma que há um mapeamento direto entre ambos. Modelos orientados a objetos oferecem herança, modularidade, polimorfismo, encapsulamento, enquanto modelos ontológicos oferecem um formalismo semântico que permite entendimento compartilhado e inferências. O primeiro foi denominado PCM (Primary-Context Model) e o segundo PCOnt (Primary-Context Ontology). Ambos os modelos se baseiam nos contextos primários, onde há um objeto espacial que 62 possui identidade (URI), localização (simbólica ou absoluta), tempo (criação e última modificação) e qualidade de serviço (confiança, latência e tempo de vida). Para acessar estes objetos espaciais foi criada uma interface orientada a objetos (Spatial API). PCOnt é dividida em Upper PCOnt (genérica) e Extended PCOnt (específica). A primeira define os conceitos supracitados (identidade, tempo, etc.) enquanto a segunda permite expandí-los. Esta técnica permite distribuir o gerenciamento de ontologias, evitando a manutenção de uma ontologia única e extensa. Desta forma, propõem o iTransIT framework, uma arquitetura distribuída, seguindo o modelo em camadas, para facilitar compartilhamento de dados entre sistemas de transporte que usam iTransIT e outros legados. O framework adotas camadas Legacy (sistemas legados), iTransIT (sistemas novos) e Application (aplicações que consomem os dados). A camada iTansIT é uma federação de sistemas que suportam a API nativamente e wrappers (conversores) para os sistemas legados. O framework não provê comunicação usando SPARQL, apenas uma API específica criada por eles e também não menciona tratamento de dados históricos nem descoberta de recursos e/ou serviços. O SmartLab middleware (ALMEIDA et al., 2009) possui uma arquitetura em quatro camadas que utiliza tecnologias da Web Semântica para representar, compartilhar e inferir contexto de diversas fontes e OSGi para comunicação. Diferentemente de outras abordagens que precisam que a modelagem da ontologia seja feita na etapa de projeto, este middleware tem a habilidade de expandir sua ontologia (adicionando conceitos e regras) dinamicamente ao passo que novos dispositivos se tornam disponíveis no ambiente, fazendo com que sistemas possam se adaptar aos novos dispositivos em tempo de execução. A camada Sensing and Actuation possui os diversos dispositivos como câmeras, sensores, VoIP, etc., e a camda Service Abstration encapsula as funcionalidades de dispositivos em pacotes OSGi (bundles) que podem ser descobertos pela camada Semantic Context and Service Management, cuja responsabilidade é gerenciar e raciocinar sobre contexto usando a ontologia corrente. Esta ontologia é incrementada por esta última camada que possui módulos para procurar por novos dispositivos, adicioná-los à ontologia (novos conceitos e regras) e verificar consistência da nova ontologia. A última camada, Management and Interaction Layer, possui as aplicações que utilizam as informações da camada anterior. Para que seja possível a descoberta e uso de um dispositivo, é necessário que seu serviço implemente uma interface (ISmartLabService) que possui métodos para obter metadados, conceitos, regras e indivíduos necessários para que o novo dispositivo funcione no 63 ambiente SmartLab. A ontologia nesta arquitetura é modelada usando RDF/XML e possui quatro conceitos principais que são estendidos pelas ontologias de domínio: espaço, tempo, evento, ator (dispositivos e pessoas). Estes representam pontos, áreas, salas ou construções; instante, intervalo e relações temporais; ou uma reação a uma mudança de contexto (evento). Eventos são representados por regras de domínio, que descrevem o comportamento de aplicações. As regras de elicitação de contexto podem ser semânticas, ou seja, descrever os modelos RDF e OWL (o framework não aceita DLs) ou podem ser heurísticas que inferem conhecimento espaçal e temporal. Infelizmente, o trabalho peca em não se aprofundar na apresentação de como a interação entre os módulos funciona. Além disso, não provê comunicação usando SPARQL nem menciona tratamento de dados históricos. O sistema COSAR (RIBONI; BETTINI, 2011a) utiliza inferência híbrida para reconhecer atividades humanas. Ontologia é usada para validar atividades reconhecidas estatisticamente e para reconhecer atividades complexas impossíveis para métodos puramente estatísticos. Assim, definiram uma ontologia de atividades e outros conceitos assim como suas relações para representar e reconhecer tais atividades simples e complexas. Basicamente, inferência estatística é usada para pegar dados de sensores e predizer as atividades mais prováveis, dando probabilidades. Estas são filtradas por inferência ontológica (simbólica) através da seleção das atividas permitidas baseadas na localização do usuário. A arquitetura do sistema possui quatro camadas e é um sistema centralizado que utiliza um dispositivo móvel e servidores para processamento pesado que se comunicam via rede sem-fio. Na camada mais inferior estão os sensores que coletam dados de sensores nas roupas do usuário ou no ambiente. A seguir, na camada no dispositivo móvel do usuário encontra-se o módulo COSAR que captura as medições da camada de sensores via Wi-Fi e faz a fusão destes. Dados de localização podem ser obtidos diretamente via GPS do dispositivo ou via RFID ou triangularização GSM quando dados de GPS não estão disponíveis ou são inacurados (locais fechados). Estes (RFID e GSM) são gerados pelo chamado Location Server que se encontra na camada de infraestrutura (terceiro nível). Um sistema GIS efetua a conversão de localização física para simbólica. A camada de infraestrutura roda em servidores que efetuam classificação estatística e inferência ontológica, separadamente e possui ainda um provedor de rede para a quarta camada (serviços). Esta quarta não é bem esclarecida, sendo que na implementação ela encontra-se no próprio dispositivo móvel. 64 O módulo de classificação estatística é responsável por gerar um vetor com a probabilidade de cada atividade estar sendo executada pelo usuário a partir dos dados dos sensores usando um modelo previamente treinado. Para o módulo de inferência ontológica foi construída uma ontologia OWL 2 DL que modela atividades, artefatos (objetos), pessoas, localização simbólica (sala, hospital, etc.) e tempo, contendo 35, 43, 4, 30 e 11 subclasses, respectivamente. Com base nesta ontologia, derivam atividades permitidas em cada local, pela geração de uma matriz cujas linhas representam localizações simbólicas e colunas representam atividades, onde o valor corresponde é 1 se uma atividade pode ocorrer em uma dada localização, e 0 caso não possa. Para detectar a atividade final de um usuário o módulo COSAR pega a atividade com maior probabilidade em um vetor de atividades modificado. Este vetor modificado é obtido de duas formas: (1) casando-o com a linha da matriz referente a localização do usuário, quanto esta é certa, ou (2) unindo linhas da matriz que representam as possíveis localizações e então casando o vetor com esta linha unida. O casamento é feito pegando os valores do vetor cuja atividade é permitida pela matriz (possui valor 1). Atividades complexas são inferidas adicionando-se um ABox contendo atividades mais simples sendo conhecidamente executadas pelos usuários e suas localizções. Um comparativo entre as arquiteturas descritas pode ser visto no Quadro 6. Estas arquiteturas visam auxiliar desenvolvedores a construir de aplicações CC. Contudo, apesar de fora do escopo deste trabalho, arquiteturas para auxiliar usuários finais (com vários níveis de conhecimento) a desenvolver estes tipos de aplicações também foram propostas. Elas aplicam interfaces visuais como iCAP (DEY, A. et al., 2006), máquinas de estados como UbiPlay (MATTILA; VÄÄTÄNEN, 2006) ou objeto tangíveis como StoryRoom (MONTEMAYOR et al., 2004). Uma pesquisa sobre estas abordagens pode ser encontrada em (TANG et al., 2011). Recentemente, (GUO et al., 2011) apresenta uma arquitetura com a intenção de permitir que tanto desenvolvedores quanto usuários possam contribuir colaborativamente a desenvolver aplicações CC. Para isso, dispõe de três modos de programação (incremental, de composição e de parametrização) que permitem editar desde ontologias e regras (desenvolvedores) até a instanciação das variáveis nestas regras (usuários iniciantes). 65 Quadro 6. Comparativo das arquiteturas. Modelagem e Dados de Descoberta processamento de contexto de recursos contexto históricos Orientado a objetos; Três camadas; peerinterpretação e agregação Não Não to-peer de dados Banco relacional para Centralizado dados e regras; motor de Não Sim inferência Padrões abertos W3C? Disponível na Web? Apenas XML Não, mas troca informações via TCP/IP Não Não, mas troca informações via redes sem fio Apenas RDF Não, pois não é focado na infraestrutura Não Não RDF(S), OWL Não, comunicação via API RMI do Java. CoBra Chen, H. et al. (2004) RDF(S), OWL Não menciona iTransIT Lee, Meier (2009) RDF, OWL Sim, API própria Camadas, federação RDF, OWL Sim, OSGi RDF, OWL Não, comunicação apenas entre módulos RDF(S), OWL, SPARQL Sim, com protocolos HTTP e SPARQL Arquitetura Hydrogen Hofer et al. (2002) CASS Fahy & Clarke (2004) CMF Korpipaa et al. (2003) CORTEX Biegel & Cahill (2004) SOCAM Gu et al. (2005) Almeida et al. (2009) COSAR Riboni & Bettini (2011) LOUD 2.4.2 Arquiteturas para integração de dados na Web Organização RDF, lógica fuzzy e crisp, redes Bayesianas Sim Não Banco relacional; redes Bayesianas, CLIPS Sim Sim RDF, ontologias e regras de inferência Sim Sim Agentes (brokers); RDF, ontologias e regras de federação de inferência brokers Não Sim RDF, ontologias, orientado a objetos Não Não Camadas, centralizado RDF, ontologias e regras de inferência dinâmicas Sim Não Camadas, centralizado RDF, ontologia OWL-DL e estatística Não Sim Centralizado Em rede, hierárquica e descentralizado Três camadas; servidor centralizado Camadas, em rede, RDF, ontologias e regras de Não, mas hierárquica e inferência (outros serão possível descentralizado possíveis) futuramente O framework deste trabalho, apesar de ter sido planejado para prover dados para aplicações CC, também se apresenta como um módulo para integração de dados de diversas bases na Web. Portanto, alguns trabalhos com este intuito são apresentados nesta seção. O projeto Active XML, apresenta um framework onde arquivos XML contendo chamadas a serviços Web permitem integrar informação externa através de uma arquitetura P2P (ABITEBOUL et al., 2007). Um framework conceitual para integrar dados geográficos usando ontologias de domínio e de aplicação e mapeamentos entre elas é apresentado por Vidal et al. (VIDAL et al., 2009). O primeiro trabalho não usa padrões da Web Semântica (WS) e o segundo não chega a experimentar a proposta. Em Omitola et al. (OMITOLA et al., 2010), é relatada a experiência de converter dados governamentais do Reino Unido dos formatos HTML, XML e planilhas para LOD, e a junção destes dados com dados geográficos já existentes na nuvem LOD. A aplicação desenvolvida consome dados do SPARQL endpoint gerado e permite que o usuário visualize as informações pertinentes à sua localização Sim 66 geográfica. Não provêm ferramentas para publicação de bases nem para integração, sendo o processo feito por meio de scripts. Integração na Web Semântica pode ser obtida por meio de consultas SPARQL federadas que podem ser de três formas: repositório central, múltiplos repositórios usando suas API nativas e múltiplos repositórios via SPARQL endpoints (HAASE et al., 2010). Esta última é implementada por Langegger et al. (LANGEGGER, 2008; LANGEGGER et al., 2008) no Semantic Web Integrator and Query Engine (SemWIQ), um endpoint virtual onde diversos endpoints podem se registrar para serem consultados de forma transparente. Com ele, um cliente pode executar uma consulta neste endpoint virtual que se encarrega de construir consultas para cada endpoint registrado. Segundo Haase et al. (HAASE et al., 2010) esta forma apresenta altos tempos de execução de consultas devidos ao atraso da rede, enquanto a primeira apresenta os melhores. Contudo, a principal vantagem de usar um repositório central é a possibilidade de executar inferências, recurso que os trabalhos citados não permitem. Quanto ao uso de inferência, Winkels et al. (WINKELS et al., 2010) apresenta um trabalho que utiliza dados geográficos para verificar o cumprimento de normas quanto ao uso de terras. Apresentam uma ontologia OWL com conceitos região e região conflitante, permitindo identificar descumprimento de uma norma. Porfim, apresenta um mashup que consome SPARQL e apresenta informações em um mapa. Em Della Valle et al. (DELLA VALLE et al., 2009), apresenta-se um framework para disponibilizar dados geográficos como grafos RDF virtuais visando aproveitar algoritmos já existentes através de um conversor de SPARQL para SQL configurado por uma linguagem de mapeamento. Obtenção de dados adicionais limita-se a consultas à DBPedia e ao Flickr. Permite realização limitada de inferências usando Jena. Em Koutsomitropoulos et al. (KOUTSOMITROPOULOS et al., 2010), um framework para inferência descentralizada e distribuída usando uma API Java que opera remotamente é apresentado. Contudo, não provê um SPARQL endpoint para acesso por parte de aplicações. Mostra que em processamentos pesados como classificação, o tempo de processamento supera o atraso da rede, comprovando o benefício de ter um servidor dedicado à inferência, enquanto o cliente apenas se comunica com o servidor. Percebe-se que existem trabalhos que se assemelham com essa proposta. No entanto, este trabalho se diferencia pelo módulo descentralizado, facilmente configurável que consome dados de bases LOD, executa inferência sobre estes dados e disponibiliza dados derivados como um novo SPARQL endpoint. 67 3 3.1 LOUD – Linked Open Ubiquitous Data Introdução Este capítulo apresentará o Módulo de Inferência proposto para resolver o problema específico descrito na seção 1.3 e um esboço da arquitetura LOUD (Linked Open Ubiquitous Data) proposta para solucionar o problema mais amplo descrito na seção 1.2. A arquitetura LOUD ainda se encontra em estado inicial de idealização devido ao fato de ser bastante ampla e não poder ser completamente desenvolvida em uma única dissertação de Mestrado. Assim, a seção 3.2 apresentará a arquitetura LOUD, e a seção 3.3 descreverá o Módulo de Inferência, parte que será desenvolvida de fato neste trabalho. 3.2 Arquitetura LOUD 3.2.1 Objetivos A arquitetura visa utilizar as técnicas e padrões da Web Semântica e Dados Ligados para facilitar o desenvolvimento de aplicações cientes de contexto. Pretende-se disponibilizar módulos de informação contextual descentralizados para acesso por parte destas aplicações. Estes módulos devem ser capazes de consultar bases de triplas que contenham dados estáticos, de sensores e/ou de contexto de mais alto nível existentes na nuvem e processar estas informações usando os mais variados mecanismos. Ao permitir variados mecanismos de processamento, um em cada módulo independente, a arquitetura mostra-se coerente com modelos híbridos. Tudo isso deve ser feito de forma a facilitar tanto a reutilização de vocabulários, ontologias e regras de inferência de contexto, quanto o mapeamento entre conceitos e relacionamentos. Por fim, pretende-se impulsionar a produtividade de tais aplicações a partir da especificação de passos a serem seguidos pelo desenvolver. 3.2.2 Estrutura A versão inicial da arquitetura é organizada em três camadas conforme apresentado na Figura 7. Elas serão mais bem detalhadas nas subseções a seguir, contudo cabe ressaltar que cada módulo, representado por uma caixa, recebe configurações, mas estas foram omitidas da figura e, no caso da camada intermediária serão apresentadas na seção 3.3.3. Observe que as 68 setas entre componentes da figura mostram o fluxo de dados (exceto de configuração) de modo que consultas (requisições por dados) circulam no sentido inverso das setas enquanto que os dados de resposta circulam no sentido direto. Segue uma breve descrição de cada camada: Camada de dados e sensoriamento – responsável por obter, armazenar e fornecer dados de sensores físicos, bases de dados e perfis do usuário. Camada de Inferência – composta por uma rede de módulos responsáveis por consumir informações da camada de dados e sensoriamento ou de outros módulos da camada de inferência e realizar inferência de contextos, ações e notificações. Camada de Aplicação – consome dados das camadas anteriores e é responsável por interagir com o usuário podendo gerar regras para a camada de inferência conforme solicitações do usuário; agentes computacionais (não-humanos) e Legenda: Aplicação Aplicação Aplicação Fluxo de dados (exceto de configuração): Publicação Publicação Armazenamento Processamento Armazenamento Processamento Consumo Consumo Consultas no sentido inverso das setas Dados de resposta no sentido direto Publicação Publicação Armazenamento Processamento Armazenamento Processamento Consumo Consumo Endpoint Endpoint Base LOD Base LOD Sensoriamento Dados Inferência Aplicação mashups também poderiam compor esta camada. Endpoint Sensor Físico Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como produtores e consumidores. Entradas para configuração dos módulos foram omitidas. 3.2.2.1 Camada de dados e sensoriamento Esta camada é formada por módulos que devem disponibilizar SPARQL Endpoints para consulta, mas que podem diferir complemente na forma como obtém seus dados. Sendo assim, são classificados em módulo de dados e módulo de sensoriamento. 69 O módulo de sensoriamento adquire dados de sensores físicos heterogêneos, que podem ser locais ou remotos. No caso de sensores locais, o dispositivo do usuário deve estar executando um módulo de sensoriamento ou inserir seus dados em um existente na nuvem. Os módulos desta camada podem utilizar técnicas estatísticas, redes Bayesianas, lógica nebulosa, etc. para tratamento de dados, que reduzam a incerteza antes de disponibilizá-los à camada de inferência. O módulo na parte inferior direita da Figura 7 poderia ter, por exemplo, um classificador que filtraria amostras obtidas de um microfone (sensor físico). O módulo de dados executa a função de publicar dados estáticos ou que mudam com baixa frequência, adquiridos de bases de dados e perfis de usuário. Sendo assim, fornecem dados de guias de ruas, serviços públicos, pontos de interesse, preferências do usuário, etc. Estes dados podem ser mapeados diretamente de bancos de dados relacionais ou armazenados em repositórios de triplas. Note que estes módulos não precisam ser construídos do zero, pois já vem sendo implementados na iniciativa de Dados Ligados. 3.2.2.2 Camada de Inferência Esta camada é a mais próxima do foco deste trabalho. Ela se organiza como uma rede de módulos, a saída de um é ligada à entrada de outro, capazes de realizar inferência sobre dados de outras fontes com base em procedimentos (como ontologias, regras, programas imperativos, etc.) definidos pelo desenvolvedor. Basicamente, cada módulo carrega dados de um ou mais SPARQL Endpoints (módulos da camada de dados e sensoriamento ou da camada de inferência), processa estes dados e disponibiliza os resultados através de seu próprio endpoint (Figura 7). Assim, podem-se identificar três etapas realizadas: carregamento, processamento e publicação. A etapa de carregamento de dados é realizada por meio de consultas SPARQL. Já nesta etapa é possível algum processamento utilizando consultas SPARQL Construct. As consultas e suas configurações (URL de acesso dos endpoints, a frequência com que as consultas devem ser executadas, etc.) devem ser facilmente definidas pelo desenvolvedor. Os dados obtidos são armazenados em uma base intermediária. A etapa de processamento permite utilizar os dados armazenados na base intermediária, e seguindo algum algoritmo de processamento descobrir novas informações e adicioná-las à base intermediária ou modificar informações existentes. No estágio atual, almeja-se apenas inferência usando ontologias OWL e/ou regras definidas pelo desenvolvedor. Atualmente, identificam-se quatro tipos de tarefas de processamento: 70 Mapeamento vocabulário-ontologia (MVO) Mapeamento inter-ontologias (MIO) Inferência de contexto de mais alto nível (ICAN) Geração de recomendação (GR) Ontologias devem seguir os padrões RDFS e/ou OWL e precisam ser cuidadosamente desenvolvidas para atender os requisitos de expressividade do domínio em questão. Por esta razão serão denominadas ontologias de domínio (ODs). Regras também podem ser utilizadas, visto que OWL ainda possui carências de expressividade. Contudo ao desenvolver ontologias e regras deve-se atentar para manutenção da consistência e decidibilidade (veja seção 2.3.2). Retornando às tarefas de processamento, o MVO é necessário quando vocabulários de bases externas não são adequados para inferência, mapeando, assim, conceitos destes vocabulários para ODs. O MIO permite reutilizar ODs existentes, através da definição de relações entre conceitos e propriedades. Assim, caso exista mais de uma OD, a mais adequada pode ser adotada e conceitos das demais mapeados para conceitos da OD utilizada. A ICAN permite deduzir contexto de mais alto nível pela combinação de contextos de mais baixo nível, dados de bases, de perfis de usuário e de sensores físicos. Exemplos são descobrir bairro ou cidade a partir das coordenadas geográficas do usuário ou se uma pessoa tem algum amigo ou parente fazendo aniversário em determinada data. Na seção 2.3.2.5 é apresentado um exemplo de ICAN utilizando regras (não representável em OWL 2 DL) para deduzir a atividade de um usuário (MeetingSupervisor). Já a GR é responsável pela geração de recomendações, que podem ser ações para a aplicação ou notificações ao usuário. Exemplos seriam notificar usuário sobre aniversário de um amigo, executar a ação de comprar um livro quando determinadas condições definidas pelo usuário acontecem (disponibilidade de um título, preço, etc.), ou executar a ação de colocar o celular em estado vibratório ao entrar em uma sala de cinema ou de reunião. O processamento mais elaborado é feito usando ontologias e regras, mas é possível, logo no carregamento, usar SPARQL Construct para fazer alguns mapeamentos (MVO e MIO) e até mesmo ICAN e GR. Uma vez concluído este processo, a etapa de publicação disponibiliza um SPARQL endpoint na nuvem de LOD com os dados derivados gerados na etapa de processamento. Por fim, esta camada poderia ser expandida ou uma quarta camada poderia ser adicionada para contemplar outras possíveis necessidades. 71 3.2.2.3 Camada de Aplicação Como o nome sugere, as aplicações estão nesta camada. Ela interage diretamente com o usuário final, sendo responsável por fornecer a interface de comunicação com o usuário e também de obter seu perfil (gostos, interesses, e outras informações que sejam úteis para a aplicação) sendo, portanto, pouco generalizável. Os dados sobre o perfil do usuário podem estar nesta camada caso o perfil seja armazenado pela aplicação, ou podem estar na camada de dados caso o perfil fique em um endpoint remoto. Espera-se que o desenvolvedor da aplicação precise apenas criar a interface com o usuário, algumas consultas a módulos da camada anterior e controlar a interação. Necessidades do usuário e da aplicação podem ser expressas por tais consultas ou regras dentro de módulos de inferência externos, ou seja, não manipuláveis diretamente pela aplicação. Neste caso, é necessário usar regras parametrizadas nestes módulos. Exemplificando, considere uma regra para geração de uma ação de compra de livros (GR) que considera assunto e preço. Neste caso, pode-se ter uma única regra genérica que dispara a ação “comprar” quando assunto e preço (oriundos do perfil do usuário) coincidem com bases de livrarias. Desta forma, nem assunto nem preço podem ser fixados na regra, pois podem variar drasticamente ao longo do tempo. Sendo assim, o módulo que contém esta regra precisa realizar consultas que obtenham estes dados de perfis do usuário situados na camada de dados. No final, a aplicação precisa apenas atualizar o endpoint que armazena tais dados e o módulo se encarrega de obtê-los. Em um estágio futuro, regras poderão ser passadas diretamente à camada de inferência por meio de uma biblioteca fornecida pela arquitetura que gerencie as transferências e a comunicação entre as duas camadas, tornando-as mais dinâmicas. Adicionalmente, agentes computacionais e mashups também poderiam participar desta camada, mas isto não está no escopo deste trabalho. O conceito de agente foi discutido no início da seção 2.3 e na arquitetura CoBra na seção 2.4.1. 3.2.2.4 Discussão quanto aos requisitos do problema O uso de serviços Web convencionais exige que o desenvolvedor construa conversores de formato e tradutores para entendimento do significado das respostas do serviço, de forma a casá-las com os conceitos usados por sua(s) ontologia(s) de domínio, quando há tais ontologias. Portanto, a pura adoção de formatos e protocolos padronizados pelo W3C para comunicação já parece beneficiar a interoperabilidade, mas, o descasamento semântico ainda prejudica este requisito. No entanto, uma vez que os formatos sejam comuns, técnicas 72 de mapeamento entre os conceitos (MVO e MIO) se tornam mais simples. Acredita-se também, que a utilização de módulos previamente configurados e/ou de mapeamentos evite a criação ou modificação desnecessária de ontologias e vocabulários permitindo seu reuso. Apesar de tudo, não se deve impedir programação quando necessário. O uso de camadas fracamente acopladas e componentes descentralizados permite que estes rodem em máquinas e dispositivos distintos. Isto é importante para o uso de dispositivos móveis, necessários para atender os requisitos da Computação Ubíqua. Assim, uma aplicação em um dispositivo móvel pode ter o processamento pesado executado em servidores na nuvem de forma descentralizada e até mesmo distribuída. Aplicações mais simples podem ficar autocontidas no próprio dispositivo móvel. Com esta arquitetura, espera-se que não seja necessário que o desenvolvedor de aplicações CC defina e implemente tudo que precise (desde fontes de sensores e formatos de dados até ontologias e processadores). Assim, ao desenvolver uma aplicação ele pode aproveitar conjuntos de dados da nuvem LOD, consultas, ontologias e regras já existentes para seu domínio de aplicação e até mesmo módulos que já estejam funcionando na nuvem. Caso não exista um módulo disponível na nuvem que atenda todas as suas necessidades, o desenvolvedor de aplicação poderia se concentrar em: 1. Determinar ontologia(s) de domínio utilizada(s) na camada de inferência (ODs); 2. Determinar os endpoints que sirvam como fontes de dados (LOD, sensores ou módulos que atendam parcialmente), seus vocabulários e ontologias, e consultas SPARQL para obter os dados; 3. Mapeamento entre os vocabulários/ontologias das fontes e as ontologias de domínio (MVO e MIO); 4. Regras para inferência de contexto (ICANs) e geração de recomendações (GR); 5. Se concentrar na interface com o usuário da aplicação. Consequentemente, estes fatores (reuso, interoperabilidade e poucas etapas) devem levar a um aumento de produtividade se comparados às técnicas abordadas na literatura (criação de modelo de contexto e ontologias específicos para a aplicação). Esta arquitetura está em estado inicial e deverá sofrer modificações, como adição de novos módulos, componentes e até camadas. 73 3.3 Escopo do trabalho: o Módulo de Inferência Esta seção apresentará detalhadamente o Módulo de Inferência, foco deste trabalho, como possível solução para o problema específico descrito na seção 1.3. Este módulo é parte da camada de inferência da arquitetura LOUD. O módulo pode ser configurado para ser capaz de carregar dados de várias fontes via SPARQL, processar estes dados usando OWL e regras definidas pelo usuário e prover seus dados a outros por meio de um SPARQL endpoint. Instâncias deste módulo na nuvem poderiam ser representadas na nuvem de LOD 12 como um quadrado em vez de um círculo para mostrar que há processamento de inferência. As camadas de aplicação e de dados e sensoriamento não estão no escopo deste trabalho, sendo assim, apenas o necessário para experimentos será construído: prover SPARQL Endpoints e aplicações para visualização sem aprofundamento. Módulos de sensoriamento serão simulados, isto é, não serão utilizados sensores de fato, mas apenas dados crus (raw data) históricos que tenham sido obtidos de sensores reais ou dados simulados de sensores fictícios. Estes dados servirão de base, juntamente com dados provenientes de módulos de dados para inferências de contexto de mais alto nível. Os módulos de dados conterão triplas de dados oriundos de bancos de dados relacionais (triplas virtuais) ou de repositórios de triplas (triplas materializadas). Aplicações que possam porventura ser construídas servirão apenas para visualização de dados das camadas inferiores, nunca voltados para interação com o usuário. As subseções a seguir apresentarão o estrutura interna do Módulo de Inferência, sua implementação e configuração. 3.3.1 Estrutura Este módulo é dividido em quatro componentes conforme apresentados na Figura 8 e descritos nas próximas subseções. Maiores detalhes sobre etapas internas e iterações entre componentes serão abordadas na seção 3.3.1.5. 12 Linked Data Cloud - http://lod-cloud.net/ 74 Interface Web SPARQL Endpoint Legenda: Direção do fluxo de triplas RDF Motor de Inferência Ontologias & Regras Base de Armazenamento Comunicação bidirecional: motor de inferência lê dados da base e adiciona novas triplas RDF na base Carregadores de Dados Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação bidirecional) é representada para fins didáticos, pois a base pode conter triplas virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a leitura sobre Jena e Pellet na seção 2.3.2). 3.3.1.1 Carregadores de dados O componente de carregamento é, na verdade, um conjunto de subcomponentes que rodam paralelamente, de forma que cada um encarrega-se de executar consultas SPARQL e obter dados de um único endpoint externo de forma síncrona ou assíncrona. O primeiro método é também conhecido como pull de forma que o carregador envia uma consulta SPARQL e permanece bloqueado até que o endpoint consultado retorne a resposta. Pode-se configurá-lo de maneira que cada carregador tenha o endereço do endpoint externo, as consultas a serem executadas contra este endpoint, a frequência de cada uma delas e possíveis substituições de variáveis. O segundo método é denominado push (ou publish/subscribe) e pode ser encontrado em (PASSANT; MENDES, 2010). Basicamente, ele funciona de forma a não bloquear o carregador até receber a resposta de uma consulta, ou seja, o carregador é acionado por eventos assíncronos. Para isso, o carregador se registra no servidor SPARQL fornecendo o evento, a consulta a ser executada quando este evento ocorrer no servidor e um ponto de retorno que receberá os resultados. Este segundo método pode ser usado para lidar com dados dinâmicos de sensores ou redes de sensores, de forma que os dados oriundos do sensoriamento podem ser recebidos de forma assíncrona, ou seja, sem intervalos de tempo pré-definidos. Esta funcionalidade é importante, pois comunicações assíncronas são comuns em redes de sensores que são comumente utilizadas para monitorar eventos físicos. O método também pode ser aplicado ao consumir dados de outros módulos de inferência, ou seja, o módulo de inferência fonte geraria um evento ao, por exemplo, deduzir um novo contexto. Atualmente, apenas operações síncronas são possíveis, mas operações assíncronas deverão ser permitidas no futuro. 75 A substituição de variáveis (variable binding) permite a construção de consultas parametrizadas, ou seja, que podem ter parâmetros com valores definidos dinamicamente. Assim, pode-se ter uma consulta com uma variável que é substituída, por exemplo, com a data e hora do momento de execução da mesma, ou com dados provenientes de outras consultas. O elemento responsável por fazer estas substituições é aqui denominado binder. Desta forma, antes de um carregador executar uma consulta, ele aciona o binder associado a ela que pode retornar até mesmo mais que uma consulta a ser executada pelo carregador. Neste caso, a consulta funciona como um modelo para a geração de várias consultas semelhantes, mas com valores diferentes nas variáveis substituíveis. O uso de binders poderia, em parte, ser substituído por SPARQL federado, mas devido ao pouco suporte atualmente, problemas de travamento durante testes e de estar fora do escopo isto não foi implementado. Dois tipos de consultas SPARQL são permitidos: DESCRIBE e CONSTRUCT. Ambas podem ter variáveis substituídas. A primeira descreve um ou mais recursos, ou seja, retorna todas as triplas tais que estes recursos são sujeitos, exatamente como estão na base consultada. A segunda forma permite mudar o padrão do grafo de resultado da consulta sem alterar o grafo da base consultada e, por este motivo, pode ser utilizada para certos mapeamentos conforme citado na seção 3.2.2.2. O resultado das consultas de cada carregador é guardado por cada um para posterior inserção na base de armazenamento intermediário. 3.3.1.2 Base de armazenamento intermediário O componente de armazenamento é um conjunto de grafos RDF independentes usados em várias fases. Primeiramente, armazena as triplas obtidas pelo componente de carregamento, a seguir o processo de inferência é feito sobre estes dados e, finalmente, o endpoint publica esta base. A criação de grafos intermediários é tratada pelas aqui denominadas políticas de atualização. Por exemplo, uma política “limpe e insira” poderia usar uma base vazia na fase pré-carregamento (grafo inicial) e eliminar dados intermediários após a inferência e antes de publicar. Outra política poderia manter alguns dados anteriormente publicados como grafo inicial e manter os dados intermediários gerados durante a inferência para publicação. Esta base pode ser armazenada em memória principal, em disco local ou até mesmo em cluster ou na nuvem conforme a necessidade, e também numa combinação destes. Mas é importante salientar que o segundo e terceiro casos são mais comuns para bases maiores e podem ser insatisfatórios, com respeito a desempenho e tempo de resposta, para executar 76 inferências. Por este motivo apenas bases em memória principal estão sendo consideradas neste trabalho. 3.3.1.3 Motor de Inferência ou Reasoner O componente de inferência permite processar o grafo de dados pós-carregamento (grafo inicial mais grafo com resultado das consultas) com base em ontologias OWL e regras definidas pelo projetista/desenvolvedor. Uma nova inferência é executada quando algum carregador detecta novos dados. Neste trabalho não haverá distinção formal entre os tipos de processamento que podem ser efetuados (MVO, MIO, ICAN e GR, vide seção 3.2.2.2) visto que do ponto de vista do módulo de inferência a distinção está apenas na forma de construção utilizada: SPARQL Construct, ontologias OWL e regras IF-THEN. Assim, é possível dizer, por exemplo, que Pessoa e Person são classes equivalentes (MIO) de três formas distintas, mas com igual significado: 1. CONSTRUCT { ?uri a x:Pessoa ; a y:Person . } WHERE { ?uri a x:Pessoa . } 2. x:Pessoa owl:equivalentClass y:Person . 3. ?uri a x:Pessoa ?uri a y:Person . Na primeira forma, utiliza-se SPARQL Construct no componente de carregamento, de forma que a existência de um recurso do tipo x:Pessoa na base consultada, determina que este recurso também será uma instância de y:Person na base do módulo que consulta. A segunda utiliza a propriedade simétrica e transitiva owl:equivalentClass da linguagem OWL (seção 2.3.3). A terceira utiliza uma regra IF-THEN, similar a primeira forma usando SPARQL, mas que não requer repetição da afirmação que o recurso é instância de x:Pessoa, visto que esta afirmação já se encontra na base. Pode-se notar também que, a segunda forma difere das demais por não relacionar instâncias diretamente sendo perfeitamente compatível com reasoners DL. Contudo, se for usado um sistema de inferência baseado em regras e sem regras para os axiomas OWL, é necessário tratar as instâncias adicionando-se as seguintes regras (prefixo owl omitido): 2.1. ?c1 equivalentClass ?c2 ?c2 equivalenteClass ?c1 2.2. ?c1 equivalentClass ?c2 , ?c2 equivalentClass ?c3 ?c1 equivalenteClass ?c3 2.3. ?c1 equivalentClass ?c2 . ?x a ?c1 . ?x a ?c2 77 A regra 2.1 fornece a simetria e a regra 2.2 garante a transitividade, enquanto a regra 2.3 é a forma genérica da regra expressa na terceira forma. Desta forma, estas três regras genéricas reduzem significativamente a quantidade de regras a serem escritas quando há muitas classes. Exemplo: considerando classes C 1 a C2n, onde Ci é equivalente a Cj, com i ímpar e j = i + 1, seriam necessárias 2n regras usando instâncias, e nenhuma regra adicional usando 2.1, 2.2 e 2.3. Neste segundo caso seria necessário, contudo, definir os n axiomas owl:equivalentClass. Para C1 a C3n, com Ci equivalente a Ci+1 equivalente a Ci+2, e i = {1, 4, 7, ... } tem-se 3n regras contra 2n axiomas. 3.3.1.4 SPARQL Endpoint O Sparql Endpoint é o quarto e último componente do Módulo de Inferência e permite que a aplicação e/ou outros módulos da camada de inferência acessem o conteúdo da base local usando o protocolo SPARQL do W3C. Assim, o módulo mantém um protocolo padronizado tanto na entrada (componente de carregamento) quanto na saída, permitindo que diversos módulos de inferência formem uma rede sendo cada um responsável por uma pequena parte de todo processamento. Uma interface para navegadores Web (página HTML) também é disponibilizada para navegação básica e executação de consultas. Após dados serem carregados e o motor de inferência ser acionado, o endpoint é atualizado. Para que estes novos dados estejam disponíveis para consulta por terceiros, duas formas de atualização foram planejadas. A primeira publica a mesma base usada pelo sistema de inferência. A segunda copia toda a base usada pelo sistema de inferência para uma segunda base contendo as triplas materializadas. Enquanto no primeiro caso há o benefício da publicação de novos dados mais rapidamente, no segundo há o benefício de se poder aproveitar de índices construídos pelo banco de triplas. No entanto, no primeiro caso, toda consulta pode provocar algum processamento lógico parcial, e no segundo caso, a cópia pode ser bastante demorada visto que todo o processo de inferência precisa ser executado de uma vez, podendo ser uma péssima escolha quando a atualização da base é muito frequente. Devido ao fato de ambos possuírem prós e contras, a definição de qual método adotar é definida pelo desenvolvedor no arquivo de configuração. 3.3.1.5 Estrutura de funcionamento Nas seções anteriores, cada componente foi apresentado separadamente. Nesta seção, as iterações e as etapas internas serão mais detalhadas. 78 A Figura 9 apresenta um diagrama de atividades do funcionamento do módulo. Primeiramente, o arquivo de configuração é lido e processado, para então se iniciar o endpoint e os carregadores de dados. A partir deste momento, tanto o fluxo principal (à esquerda) quanto os fluxos dos carregadores (no centro) ocorrem paralelamente. Apesar de a figura apresentar apenas um fluxo de carregador, vários podem executar paralelamente em suas respectivas threads. Quando um carregador obtém novos dados, ele ativa um sinal que pode ser percebido pelo fluxo principal e este executa o motor de inferência registrado. Em vez de o fluxo do carregador gerar um evento que dispara o reasoner diretamente, é o fluxo principal que percebe a ativação do sinal e executa o reasoner. Assim, se dois sinais forem gerados por diferentes carregadores num pequeno intervalo de tempo, a inferência executa apenas uma vez com os dados de ambos. Consequentemente, se durante uma inferência outros carregadores ativarem o sinal, nenhuma inferência adicional será executada em paralelo. Isto é particularmente útil no caso em que o tempo de inferência é maior que o intervalo entre consultas, evitando maior sobrecarga na máquina executante. Isto pode ocorrer devido a uma configuração equivocada (intervalo muito pequeno), devido à sobrecarga do processador da máquina ou mau dimensionamento de recursos. Quando a inferência termina, o endpoint é atualizado conforme a forma de atualização definida na configuração. Figura 9. Diagrama de atividades do módulo de inferência 79 Em relação a um carregador, o fluxo central da Figura 9 apresenta três etapas. Na primeira, as consultas podem ter suas variáveis substituídas (variable binding) por valores conforme configuração fornecida. Isto pode gerar uma ou mais consultas que são executadas em sequência e seus resultados unidos em um único grafo. Uma vez que todos os dados foram obtidos, o carregador ativa seu sinal de aviso de modificação. Por fim, as etapas internas da atividade de inferência (à esquerda) são detalhadas no fluxo à direita (ligadas por um linha tracejada). Este fluxo está estreitamente relacionado às políticas de atualização anteriormente citadas, responsáveis por criar os grafos intermediários conforme pode ser visto nas atividades de obtenção do grafo inicial ou pré-carregamento, do grafo pré-inferência ou pós-carregamento e, por fim, do grafo para publicação. A atividade de obtenção do grafo pré-carregamento recebe o grafo atualmente publicado (GPUB), que é vazio na primeira iteração, e retorna o grafo inicial (G0) construído conforme a política de atualização. Em seguida, a segunda atividade reúne os resultados das consultas dos carregadores (GRC[i]) em um grafo GRC, onde a quantidade de operações de união depende da quantidade de carregadores existentes e, por fim, G0 é adicionado a GRC. A próxima atividade constrói o chamado grafo antes da inferência (G AInf) a partir dos grafos GPUB e GRC, permitindo, assim, adicionar ou remover triplas antes da execução da inferência. A quarta atividade, finalmente, realiza a inferência sobre os dados do G AInf utilizando as ontologias e regras definidas, produzindo então o grafo da inferência (G INF). Apesar de já haver pesquisas em inferência incremental, ou seja, aquela que não requer processamento para toda a base de dados, apenas para a parte modificada, as ferramentas que a fazem ainda estão em estágio inicial, e por isso, o assunto não entrou no escopo deste trabalho (GESSLER et al., 2009; SIRIN, EVREN et al., 2007). As duas últimas etapas são a construção do grafo para publicação (GPUB) a partir de GPUB, GRC e GINF e, finalmente, a atualização do endpoint. O algortimo pode ser visto a seguir: 1 2 G0 := get_initial_graph(GPUB) GRC := {} 3 Para cada carregador i faça GRC := GRC ∪ GRC[i] 4 5 6 7 8 GRC := GRC ∪ G0 GAInf := get_graph_before_reasoning(GPUB, GRC) GINF := do_reasoning(GAInf) GPUB := get_publishing_graph(GPUB, GRC, GINF) update_endpoint(GPUB) Nota-se que, se a política de atualização for eficiente, como por exemplo, sempre retornar um grafo vazio ou já existente (GPUB, GRC e GINF, nas etapas grafo inicial, grafo antes 80 da inferência e grafo para publicação, respectivamente), os pontos que poderiam gerar gargalos são: a) Criação do GRC (linhas 2, 3 e 4 do algoritmo); b) Inferência (linha 6) e; c) Atualização do endpoint (linha 8). O ponto (a) tende a ser linear conforme a quantidade de triplas. No caso (b), o sistema de inferência geralmente executa apenas um rápido pré-processamento, sendo a inferência (que pode ter complexidade polinomial ou exponencial conforme a ontologia) executada, de fato, na atualização do endpoint (c) ou após a sua publicação quando houver uma consulta ao grafo GPUB. O fator determinante é a forma escolhida para atualização do endpoint (discutida na seção 3.3.1.4). 3.3.2 Implementação O Módulo de Inferência foi implementado usando a linguagem Java e as bibliotecas Jena e Pellet. Jena é capaz de processar RDF e OWL programaticamente e inclui reasoners baseados em sistemas de regras para RDF e OWL. Pellet é um reasoner OWL-DL implementado em Java que aceita ontologias que sigam a especificação OWL 2 DL e regras DL-seguras escritas usando a sintaxe SWRL (detalhes na seção 2.3.2 e 2.3.2.5). ARQ é um motor SPARQL que suporta SPARQL 1.0 e 1.1 além de um conjunto de extensões. Fuseki é um servidor SPARQL compatível com protocolo SPARQL sobre HTTP que também aceita SPARQL 1.0, 1.1 e extensões do ARQ. Ambos ARQ e Fuseki são parte da biblioteca Jena. Para permitir exploração do endpoint via navegadores Web foi usada uma aplicação Ajax chamada SNORQL13. Como a configuração dos módulos é feita via XML foi usado a biblioteca XStream para carregar XML e converter em objetos Java. Antes de entrar nos detalhes de implementação cabe informar a existência de duas classes e uma interface da biblioteca Jena largamente utilizadas. A interface Model representa um Grafo RDF que pode ser manipulado programaticamente pois permite leituras, inserções e remoções de triplas RDF sem necessitar de escrita de consultas SPARQL. A interface Reasoner representa um motor de inferência genérico que é especilizada tanto pelo reasoner baseado em sistemas de regras quanto pelo reasoner Pellet. A classe Query representa uma 13 SNORQL: an AJAXy front-end for exploring RDF SPARQL endpoints – https://github.com/kurtjx/SNORQL 81 consulta SPARQL e é capaz de parsear um texto descrevendo uma consulta e armazenar numa forma intermediária para posterior utilização dentro de motores SPARQL. A Figura 10 apresenta o diagrama das principais classes que compõem o Módulo de Inferência. A utilidade da maioria das classes e interfaces já foi apresentada em alto nível na seção anterior. As interfaces UpdatePolicy, QueryParameterBinder, SparqlExecutor e Loader representam políticas de atualização, substituidor de variáveis, executante de consultas SPARQL e carregadores respectivamente. Esta última é especializada em PullLoader, que são os carregadores síncronos já descritos, e cada instância desta classe é capaz de enviar múltiplas consultas a um endpoint e estas consultas são executadas em sequência. A classe SparqlExecutor possibilita a execução dos quatro tipos de consulta SPARQL existentes e se especializa em SparqlGraphExecutor e SparqlEndpointExecutor (não mostrados no diagrama) que são capazes de executar consultas a um grafo (interface Model do Jena) e a um endpoint remoto respectivamente. Classes que realizam QueryParameterBinder, ou seja, que implementam esta interface, são capazes de fazer a substituição de variáveis conforme já mencionado e serão detalhadas mais adiante. A interface UpdatePolicy é composta por três métodos que são equivalentes aos métodos apresentados no algoritmo da seção 3.3.1.5: getInitialGraph(GPUB) – retorna o grafo inicial (linha 1); getPreReasoningGraph(G PUB, GRC) – retorna o grafo que será passado ao motor de inferência (linha 5); e getPublishingGraph(GPUB, GRC e GINF) – retorna o grafo a ser publicado no SPARQL endpoint (linha 7). isCurrentModelChanged(mask) – retorna true caso o(s) método(s) definido(s) por mask alterem o grafo GPUB. O parâmetro mask representa um ou mais dentre os três métodos anteriores de UpdatePolicy. Este método é usado apenas na fase de leitura do XML e caso algum método retorne true o endpoint será atualizado por cópia para evitar alterações concorrentes no grafo GPUB (vide seção 3.3.1.4). Isto dá uma grande liberdade para a construção de diversos tipos de políticas de atualização, contudo apenas a classe ClearDataPolicy foi implementada neste trabalho e da forma mais simples possível: os métodos retornam um grafo inicial vazio, G RC e GINF, respectivamente. 82 Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado. A classe SparqlServer encapsula uma instância do servidor Fuseki e permite inicialização e término e, principalmente, atualização do grafo disponibilizado pelo endpoint. As classes QueryConfig e QueryData, esta uma classe interna à classe PullLoader, guardam as consultas e suas configurações (binder e intervalo entre consultas) para cada um dos carregadores (um QueryData para cada consulta e um ou mais QueryData’s para cada carregador PullLoader). Quando um QueryConfig é adicionado a um Loader ele é selado, ou seja, não pode mais ser modificado. Qualquer tentativa de chamar métodos setX provoca o lançamento de uma exceção. A classe QueryConfig pode ser especializada ao se criar outros carregadores que necessitem de parâmetros adicionais (como o push loader) mas mantendo este comportamento. A classe InferenceModule orquestra o funcionamento de todas estas classes como será mostrado no próximo parágrafo. Disjunta a todas está a interface InfModReasonerFactory que é utilizada para instanciar um Reasoner antes da inicialização da classe InferenceModule. Observe que há uma fábrica para motor de inferência Jena e outra para Pellet. Após a leitura do XML de configuração, que será explicado na próxima seção, o conjunto de classes apresentado no diagrama da Figura 10 é instanciado e o processo apresentado no diagrama de atividades da Figura 9 é iniciado. Tanto por questão de espaço 83 quanto de visibilidade, o diagrama de sequência das classes foi dividido em dois conforme mostrado nas Figuras 11 e 12. A primeira foca na classe InferenceModule e será identificado por DS.IM (Diagrama de Sequência da classe InferenceModule) e a segunda na classe PullLoader (identificado por DS.PL). Primeiramente, o método start() da classe InferenceModule é chamado (DS.IM/1), e então o servidor SPARQL (DS.IM/1.1) e os carregadores registrados também são iniciados (DS.IM/1.2). Todos executam independentemente em seus próprios threads. A partir deste momento, cada carregador entra em um laço composto pelas mensagens DS.PL/1.x, que fazem a substituição de variáveis (messagens 1.1 e 1.1.1), e executam cada consulta resultante desta substituição conforme seu tipo (1.2 ou 1.3) e finalmente guardam seu resultado e sinalizam modificação (1.4). Enquanto o módulo deve permenecer executando ele verifica alguma alteração nos dados dos carregadores (DC.IM/1.3) e em caso afirmativo executa as mensagens DS.IM/1.4-1.9 que representam as linhas 1, 2-4, 5, 6, 7 e 8 do algoritmo da seção 3.3.1.5, respectivamente. O término da execução do módulo é disparado pela chamada ao método stop() (mensagem DS.IM/2) que desencadeia as mensagens DS.IM/2.1 (a mesma que DS.PL/2), DS.PL/2.1, DS.PL/2.2 e DS.IM/2.2. Do ponto vista do desenvolvedor este processo é atualmente iniciado ao pressionar as teclas Ctrl+C no terminal de execução. 84 Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule. 85 Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader. A interface QueryParameterBinder merece destaque adicional por possuir quatro classes que a realizam. Conforme apresentado na fig, esta interface possui o método bind que recebe uma consulta, efetua as substituições de variáveis cabíveis e retorna uma ou mais 86 consultas resultantes na forma de lista. A classe DefaultQueryParameterBinder implementa o comportamento mais simples: retorna uma lista com um elemento, sendo este a mesma consulta inicial. A classe SelectQueryParameterBinder executa uma consulta SPARQL SELECT e substitui as varíaveis resultantes na consulta inicial. Como um SPARQL SELECT produz um resultado tabular, cada linha do resultado gera uma consulta como resposta. A classe TimeFrameQueryBinder computa um intervalo de tempo cujo término é o instante de execução da consulta e cujo inicio é o instante de término menos um intervalo definido na configuração deste binder (valor fixo). Ambos os instantes são substituídos nas variáveis ?startDate e ?finalDate. Por fim, tem-se a classe OffsetSplitterQueryParameterBinder que permite que consultas cujo endpoint fonte limite o tamanho das respostas sejam executadas e retornem todos os resultados desejados. Assim, este binder executa uma consulta que informa a quantidade de resultados (consulta de contagem), então, a consulta que obtém todos estes resultados é quebrada em várias consultas que contém as cláusulas OFFSET e LIMIT definidas. A consulta de contagem e o valor do LIMIT são definidas na configuração do binder. Tanto o sistema de regras do Jena quando o motor de processamento SPARQL do ARQ permitem a criação de funções personalizadas. Algumas são fornecidas juntamente com a biblioteca por padrão, outras foram criadas para serem adicionadas ao Módulo de Inferência via um sistema de plugins que são definidos na linha de comando. As funções do sistema de regras do Jena são conhecidas como regras embutidas (rule built-ins). Em linhas gerais, uma função personalizada do ARQ ou de regras é construída via realização de uma interface (Function e Builtin, respectivamente), ou mais facilmente no caso do ARQ, via especialização de uma dentre diversas classes de mais alto nível da biblioteca. Funções do ARQ e built-ins do Jena diferenciam-se pelo fato de que as primeiras recebem uma lista de valores (literais) e retornam outro valor, enquanto que os built-ins podem receber literais e variáveis e retornam sempre um booleano ou nada. Quando estes built-ins são chamados no corpo (antecedente) de uma regra o retorno é um booleano e quando chamados na cabeça (consequente) da regra não há retorno. Isto ocorre pois o corpo da regra define se a cabeça da regra será executada ou não via expressão booleana, ou seja, se todos os itens do antecedente são verdadeiros então o consequente será executado. Como o consequente apenas executa comandos não há necessidade de retorno. Nesta implementação apenas funções ARQ e built-ins de antecedente precisaram ser construídos. O Quadro 7 a seguir apresenta estas funções com uma pequena descrição, o tipo (função ARQ/SPARQL ou built-in de regras) e a origem (se já fornecida 87 pela biblioteca ou criada para o Módulo de Inferência por meio de plugins). Seus usos serão apresentados no Capítulo 4 e apêndices conforme necessário. Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas. Tipo Assinatura Regra curTime(?tm) Descrição Coloca xsd:dateTime atual em ?tm. Regra makeNearestDateTime(?dtin, ?dtout) Calcula próxima ocorrência da data de entrada, InfMod ou seja, mantém dia e mês e ajusta o ano. Regra dateSum(?date_in, ?days, ?date_out) Regra dateDiff(?date1, ?date2, ?days) Regra noValue(?s, ?p, ?o) Regra notEqual(?x, ?y) Regra le(?x,?y) Regra ge(?x,?y) Regra localname(?uri, ?lname) makeNamedNode( ?new_node, <strlist>) Regra SPARQL localname(?uri) SPARQL maxMatch(?a, ?b) SPARQL distanceFromDegrees( ?lat1, ?lon1, ?lat2, ?lon2) SPARQL nb_contains(?b, ?lat, ?lon) SPARQL concat(?a, ?b, ...) SPARQL sha1sum(?x) SPARQL sumTime(?dt, ?days, ?secs) Origem InfMod Adiciona ?days dias à data de entrada, InfMod colocando o valor na data de saída. Subtrai ?date1 - ?date2 retornando a diferença InfMod em dias em ?days. Retorna true se a tripla não está presente na Jena base. Retorna true se ?x != ?y Jena Retorna true se ?x <= ?y Jena Retorna true se ?x >= ?y Jena Coloca o localname de ?uri em ?lname. InfMod Ex. http://example.org/res/Fulano => “Fulano” ?new_node recebe um novo nó cujo URI é dado pela concatenação dos demais parâmetros. Retorna um literal string contendo o localname de ?uri Retorna a similaridade entre duas strings ?b e ?b Retorna a distância em metros entre as coordenadas geográficas (?lat1, ?lon1) e (?lat2, ?lon2). Retorna true se o ponto (?lat, ?lon) se encontra dentro do polígono com URI ?b. Retorna um literal string contendo a conctenação dos parâmetros. Calcula o SHA1 de ?x e retorna como um literal string. Retorna um xsd:dateTime que representa ?dt somados a ?days dias e ?secs segundos. InfMod ARQ InfMod InfMod InfMod ARQ ARQ InfMod 3.3.3 Configuração Para a correta configuração de um módulo deve-se primeiro planejar o que deverá ser feito antes de escrever o arquivo XML de configuração. Este planejamento inclui escolher SPARQL endpoints cujos dados sejam adequados à aplicação a ser desenvolvida assim como possíveis ontologias que possam ser usadas. Este procedimento é complexo, pois requer levantamento e pesquisa de endpoints e ontologias existentes. Contudo, acredita-se que no 88 futuro isto não seja mais um problema conforme a tecnologia da Web Semântica se difunda. Quando não se encontram ontologias/regras prontas referentes ao domínio da aplicação tornase necessário construí-las. No capítulo seguinte serão apresentados alguns exemplos onde ontologias e regras foram construídas e também os próprios endpoints. O restante desta seção apresenta a estrutura e significado do arquivo XML. Inicialmente pretendia-se construir uma ontologia OWL para descrever o arquivo de configuração, contudo não foram encontrados ganhos no escopo deste trabalho e ainda poderia complicar a fase de experimentos com alunos não familiarizados, decidiu-se utilizar apenas XML. A Figura 13 apresenta a hierarquia mais externa de elementos XML. Os elementos loaders, inference e sparqlServer configuram o carregador, o motor de inferência e o servidor SPARQL (endpoint) respectivamente. Outros elementos também importantes são name que define o nome do módulo, prefixes que permite associar diversos namespaces a prefixos (rdf, owl, etc.), clock que aceita um atributo baseUri com o URL do simulador de relógio (desenvolvido especialmente para o módulo), resourceBaseUri que define a URI base para recursos específicos do módulo (atualmente apenas o recurso adicionado automaticamente com os horários de atualização utilizam esta URI), updatePolicy define a política de atualização e apenas ClearDataPolicy é aceita no momento. O elemento inference permite dizer qual motor de inferência deve ser utilizado (PELLET ou JENA) e com qual(is) ontologia(s) e regras. O elemento ontology pode ocorrer diversas vezes e cada ocorrência determina o nome do arquivo contendo uma ontologia que pode estar na mesma máquina do módulo (caminho para um arquivo local) ou na Internet (URL). Esta pode estar escrita tanto em Turtle quando em RDF/XML. O elemento rules recebe regras JENA e é incompatível com PELLET, sendo ignorado caso este seja selecionado pelo elemento reasoner. Para usar regras com Pellet devem-se construir regras SWRL e adicionar à ontologia (para facilitar este processo pode-se usar a ferramenta Protégé14 ou escrever em Turtle, pois RDF/XML é mais verboso e torna a construção mais complexa). O elemento sparqlServer contém três elementos filho. O elemento path determina como acessar o grafo RDF publicado pelo módulo e port diz em qual porta o endpoint estará acessível. Assim, se o módulo utilizar path=/graph/ e port=3333, é possível acessar o endpoint em http://dominio:3333/graph/sparql usando o protocolo SPARQL sobre HTTP. Uma 14 Protégé: a free, open source ontology editor and knowledge-base framework – http://protege.stanford.edu/ 89 interface web SNORQL sempre estará disponível em http://dominio:3333/snorql. Finalmente, o elemento fastUpdate informa ao módulo se o endpoint deverá ser atualizado rapidamente ou não. Quando seu conteúdo for true o endpoint publica o mesmo grafo gerado pelo motor de inferência, e caso contrário (false) toda a inferência é processada e adicionada a um grafo com triplas materializadas (cópia). <InferenceModule> <loaders> <PullLoader> <name> : texto <prefixes> <Prefix> <PullLoader> ... <inference> <prefix> : texto <reasoner> : PELLET/JENA <namespace> : URI <ontology> : arquivo/URL <Prefix> ... ... <rules> : regras do Jena <clock baseUri=”url”> <resourceBaseUri> : URI <updatePolicy class=”ClearDataPolicy” /> <sparqlServer> <path> : caminho <port> : número <fastUpdate> : booleano Figura 13. Hierarquia mais externa dos elementos XML de configuração. O elemento loaders, como o nome sugere configura carregadores. Cada endpoint fonte a ser usado deve ser especificado com o elemento PullLoader que representa o carregador síncrono já descrito. A Figura 14 detalha esta etapa da configuração. Como pode-se observar, dentro do elemento PullLoader define-se o endpoint e uma descrição pertinente através dos elementos homônimos, e uma lista de QueryData’s com informações de cada consulta a ser executada dentro do elemento queryConfigs. Cada QueryData contém uma consulta (elemento query), uma descrição textual, um intervalo de tempo em milissegundos entre execuções (que pode ser uma expressão aritmética) e um elemento binder para configurar possíveis substituições de variáveis. Os quatro possíveis binders são mostrados no lado direito da Figura 14. SelectQueryParameterBinder aceita um endpoint e uma consulta SPARQL SELECT. TimeFrameQueryBinder aceita o tamanho da janela de tempo (milissegundos a retroagir) no elemento frameMillis. OffsetSplitterQueryParameterBinder aceita um endpoint, uma consulta que deve ser um SELECT COUNT e um limite para o tamanho da janela (elemento limit). 90 <binder class=”DefaultQueryParameterBinder”> <PullLoader> <description> : texto <endpoint> : URL <queryConfigs> QueryData <query> : SPARQL <binder class=”SelectQueryParameterBinder”> <description> : texto <endpoint> : URL <query> : SPARQL <binder class=”TimeFrameQueryBinder”> <frameMillis> : número <description> : texto <binder class=”OffsetSplitterQueryParameterBinder”> <interval> : número <description> : texto <binder class=”...”> QueryData ... <limit> : número <endpoint> : URL <query> : SPARQL Figura 14. Elementos XML para configuração de carregadores e substituidores de variáveis (binders). Os elementos que recebem um texto podem utilizar o CDATA do XML quando existem caracteres especiais dentro do texto. Caracteres especiais são “<” e “&” que representam início de elemento e de entidade, respectivamente. Eles podem ser encontrados em qualquer texto, mas muito mais facilmente em consultas SPARQL, sendo recomendado utilizar CDATA sempre que houver necessidade de utilizar os caracteres. As entidades “<” e “&” podem ser utilizadas para representar estes caracteres, contudo isto prejudica a legibilidade do texto. Veja dois exemplos de consulta com e sem CDATA, respectivamente: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <query> <![CDATA[ PREFIX a: <http://dominio/resource/> CONSTRUCT { ... } WHERE { ... FILTER (?y >= 18 && ?t <= 70) } ]]> </query> <query> PREFIX a: <http://dominio/resource/> CONSTRUCT { ... } WHERE { ... FILTER (?y >= 18 && ?t <= 70) } </query> Os prefixos definidos dentro do elemento prefixes são válidos em todo arquivo XML, tanto nas regras do elemento rules quanto nas consultas principais (elemento 91 QueryData/query) e secundárias (elemento binder/query). Assim, aproveitando o exemplo de consulta acima, poderia-se omitir a primeira linha contendo o prefixo e adicionar um elemento Prefix, como mostrado a seguir: 1 <InferenceModule> 2 <prefixes> 3 <Prefix> 4 <prefix>a</prefix> 5 <namespace>http://dominio/resource/</namespace> 6 </Prefix> 7 </prefixes> 8 ... 9 <query> 10 <![CDATA[ # PREFIX omitido 11 CONSTRUCT { ... } 12 WHERE { ... } 13 ]]> 14 </query> 15 ... 16 </InferenceModule> Uma vez completado o arquivo XML basta executar o módulo chamando-o em um terminal java –jar InferenceModule.jar config.xml. Por fim, para executar o plugin que possui funções adicionais para SPARQL e regras Jena apresentadas no Quadro 7 (coluna Origem igual a “InfMod”) deve-se adicionar um parâmetro, e o comando fica como mostrado a seguir: java -Dinfmod.function.path=plugin.jar –jar InferenceModule.jar config.xml 92 4 Cenários de Aplicação Para verificar a aplicabilidade do framework, foram elaborados três cenários que poderiam ser aplicados no mundo real, porém sem considerar toda sua complexidade, visto que a elicitação e análise de requisitos está fora do escopo deste trabalho por demandar um tempo adicional que impediria seu término no prazo. Mas especificamente, também considerando o fator tempo, foram consideradas situações simplificadas para viabilizar a modelagem e construção de ontologias, regras e consultas. Neste capítulo será apresentado o processo utilizado para a construção da rede de módulos de inferência para cada cenário. Eventuais endpoints construídos para simular dados de sensores e bases LOD também são apresentados, porém de forma bastante superficial no capítulo e um pouco mais detalhada nos apêndices. A criação de endpoints simulados nos cenários decorre da atual carência de bases RDF realmente úteis no âmbito brasileiro. O terceiro e último cenário foi utilizado para que alunos com alguns conhecimentos das tecnologias atuais de Web Semântica (RDF, OWL e SPARQL) avaliassem o módulo. Antes de apresentar os cenários, é importante mencionar que um endpoint especial foi desenvolvido para ser usado em todos os experimentos: simulador de relógio. Conforme o nome indica, ele é capaz de simular um relógio, possibilitando definir horário de início e fim de uma simulação e a velocidade com que o relógio simulado correrá. Assim, é possível usar janelas de tempo quando necessário sem precisar modificar o relógio da máquina hospedeira. Além disso, a taxa de velocidade do relógio permite definir quantos segundos simulados ocorrem para cada segundo real. Por exemplo, uma taxa de 20x significa que quando decorre um segundo na máquina real decorrem 20 segundos no endpoint de relógio. Já uma taxa de 0,25 determina que um segundo real representa um quarto de segundo no endpoint. 4.1 Cenário 1: informação sobre hidrantes durante um incêndio Este cenário foi sugerido pelo aluno de doutorado Tiago Marino que ajudou na sua construção. Situações de emergência possuem as mais variadas necessidades de informação, que se constituem, entre outras, de dados de saúde, segurança, geologia, logística, etc. Numa situação de emergência surgem diversas perguntas que precisam ser respondidas. Exemplos de tais perguntas são: Qual hospital possui a especialidade de ortopedia, mais próximo à 93 localidade do resgate? Quantas casas existem e quem são seus proprietários em determinada região soterrada por um deslizamento? Onde estão localizados os hidrantes de coluna no raio de 500 metros do foco de um incêndio? Estas questões são levantadas durante uma emergência e demandam resposta rápida para tomada de decisão e gerência da situação. Muitas dessas respostas existem, mas estão armazenadas em bancos desorganizados, não padronizados e não integrados. Para fins demonstrativos, apenas a última pergunta será abordada neste cenário. O objetivo deste cenário é utilizar apenas uma instância do framework proposto para mostrar integração de bases de triplas, inferência e checagem da consistência destes dados usando uma ontologia especialmente desenvolvida, que integra conceitos de vocabulários existentes. A implementação deste cenário requer diversos procedimentos para publicação, integração e consumo, ilustrados na Figura 15 que será explicada ao longo das próximas subseções. Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD. O restante desta seção discute a modelagem e construção das camadas de dados e inferências e uma pequena aplicação para consulta e apresentação em mapas. 4.1.1 Modelagem e construção da camada de dados O Corpo de Bombeiros do Estado do Rio de Janeiro (CBMERJ) é o órgão responsável por operações de controle de incêndio no Estado do Rio de Janeiro. Eles utilizam informações 94 do Sistema de Informações Geográficas Vigilância e Controle (ViconWeb 15), que inclui diversas iniciativas de trabalhos que auxiliam o processo de tomada de decisão do órgão. Seu cadastro de recursos hídricos contém informações referentes aos hidrantes de coluna (coordenadas de posicionamento, endereço, batalhão responsável, vazão e condições de funcionamento) existentes na cidade do Rio de Janeiro. Por se tratar de dados restritos ao CBMERJ, uma autorização para a extração do banco para fins de experimentação foi solicitada junto à Instituição. Contudo, para a utilização por parte do módulo de inferência seria necessário ainda a publicação de tais dados em algum SPARQL endpoint. Esta publicação foi feita por meio de um processo de ETL (Extraction, Transformation & Loading) utilizando-se a ferramenta Pentaho Data Integration 4.1.0 16, também conhecida como Kettle, tanto por ser uma ferramenta popular e aberta quanto por já existirem plugins específicos, desenvolvidos no projeto LinkedDataBR17, para se trabalhar com LOD. O projeto disponibiliza quatro plugins: entrada de dados via SPARQL, geração de propriedades de dados e de objetos (object e datatype properties do OWL), saída de dados usando SPARQL Update. Para o armazenamento e disponibilização das triplas, foi utilizado o software Virtuoso18, que é um repositório de triplas que disponibiliza interfaces para consultas SPARQL (SPARQL endpoint). O processo de ETL, superficialmente mostrado na Figura 15, é composto por cinco grandes etapas. A primeira delas é a extração dos dados da base de hidrantes do sistema ViconWeb e sua importação no Kettle. Os dados utilizados são descritos por uma ontologia criada para este cenário e que será discutida mais a frente. Estes dados são tratados para remover valores nulos ou inválidos. O próximo passo é a geração de URIs que consiste em, para cada recurso, utilizar um URL base pré-definido e acrescentar o nome da classe a que o recurso pertence e um identificador. O terceiro passo consiste na geração de campos sujeito, predicado e objeto, onde o predicado pode ser tanto DatatypeProperty quanto ObjectProperty da OWL. Na quarta etapa, os campos gerados anteriormente são convertidos para um único campo NTriplas. Finalmente, as triplas geradas são inseridas no Virtuoso usando SPARQL Update. Uma vez criado o processo, este pode ser executado diversas vezes, conforme necessário, a fim de atualizar a base do Virtuoso. 15 Vicon Web - http://www.viconsaga.com.br 16 Pentaho Data Integration - http://sourceforge.net/projects/pentaho/files/Data%20Integration/4.1.0-stable/ 17 LinkedDataBR - http://greco.ppgi.ufrj.br/gtlinkedbr 18 Virtuoso - http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/ 95 A ontologia para descrever a base de hidrantes é apresentada na Figura 16 que também mostra os relacionamentos com conceitos de vocabulários existentes na nuvem LOD. Para descobrir conceitos relacionados, foram realizadas pesquisas nas páginas do Linked Open Vocabularies (LOV)19 que reúne descrições e referências para diversos vocabulários e ontologias utilizados na nuvem LOD, do LinkedGeoData20 e DBPedia. Como resultado resolveu-se utilizar as classes: foaf:Organization do vocabulário FOAF (uma organização qualquer); geo:SpatialThing e suas propriedades geo:lat e geo:long do vocabulário “WGS84 Geopositioning”21 (objetos geolocalizados com latitude e longitude conforme o WGS84); lgdo:FireHydrant, lgdo:FireStation, lgdo:City e lgdo:Locality da Linked Geo Data Ontology; e yago:Neighbourhoods_inRio_(city) da DBPedia (bairros do município do Rio de Janeiro). O conceito central é hid:HidranteDeColuna que é uma especialização de geo:SpatialThing e de lgdo:FireHydrant (um hidrante qualquer). Ao conceito central, são relacionadas as propriedades (data properties) hid:vazão, hid:dataDoCadastro, hid:endereço que representam, respectivamente, a vazão em litros por minuto, a data que o hidrante foi cadastrado no sistema e um endereço textual. O hidrante também é relacionado ao bairro (hid:Bairro) e à cidade (hid:Cidade) em que se localiza, ao batalhão (hid:OBM equivalente a lgdo:FireStation) responsável pela manutenção e atualização de seus dados e, principalmente, à sua situação operacional que permite identificar quais hidrantes podem ser utilizados em determinado momento. Esta ontologia foi construída obedecendo ao padrão OWL 2 DL. 19 Linked Open Vocabularies (LOV) - http://labs.mondeca.com/dataset/lov/index.html 20 LinkedGeoData.org: Adding a spatial dimension to the Web of Data - http://linkedgeodata.org 21 Basic Geo (WGS84 lat/long) Vocabulary - http://www.w3.org/2003/01/geo/ 96 lgdo:FireHydrant foaf:Organization xsd:float hid: obmResponsavel hid:OBM hid:vazao hid:HidranteDeColuna hid:dataDoCadastro owl:equivalentClass hid:endereco lgdo:FireStation xsd:dateTime xsd:string hid:situacaoOperacional lgdo:Locality hid:Bairro geo:lat, geo:long geo:SpatialThing hid:SituacaoOperacional hid:bairro owl:equivalentClass yago: Neighbourhoods InRio_(city) hid:cidade hid:Cidade owl: equivalentClass lgdo:City hid:OPERANTE hid:PRECARIO hid:INOPERANTE Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD Além da base de hidrantes, foi utilizada a base LinkedGeoData.org (LGD), que disponibiliza dados georreferenciados na nuvem LOD (ruas, bairros, cidades, estados) existentes na base OpenStreetMap22, um serviço para criação de mapas colaborativo. Desta base foram extraídas todas as triplas da classe lgdo:Amenity existentes na cidade do Rio de Janeiro. Após consulta em sua ontologia, verificou-se que esta classe agrega subclasses de localidades geográficas do tipo: Aeroporto, Shopping Center, Hotel, Comércios, Escolas, Hospitais, etc. Estas entidades serão disponibilizadas para consulta na aplicação do caso de exemplo deste trabalho. 4.1.2 Camada de inferência para integração das bases Nesta seção será mostrada a configuração do módulo para integrar as duas bases RDF apresentadas na seção anterior. Da base de hidrantes foram extraídas informações relacionadas aos hidrantes através da consulta SPARQL DESCRIBE apresentada a seguir e identificada por Qhid: 1 2 3 DESCRIBE ?s ?s1 FROM <http://www.viconsaga.com.br/cbmerj/pgorh/graph> WHERE { ?s a hid:HidranteDeColuna ; ?p ?s1 . } Esta consulta descreve todas as triplas de hid:HidranteDeColuna, hid:Cidade, hid:Bairro e hid:OBM e é atualizada (executada novamente) em intervalos de uma hora. 22 OpenStreetMap - http://www.openstreetmap.org/ 97 Da base LGD obtém-se todas as instâncias de lgdo:Amenity, suas coordenadas geográficas (geo:lat e geo:long) e seu rótulo (rdfs:label). Para reduzir a quantidade de resultados utilizou-se um filtro de coordenadas, ou seja, escolheu-se um retângulo imaginário na superfície da Terra que englobasse uma grande região do município do Rio de Janeiro. Como, o endpoint da LGD limita a quantidade de resultados, foi utilizado o binder OffsetSplitterQueryParameterBinder (veja seções 3.3.2 e 3.3.3) utilizando as consultas Qcontagem (contagem total de resultados) e Qamenity a seguir: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 # Qcontagem: contagem do total de resultados SELECT (count(?uri) as ?c) FROM <http://linkedgeodata.org> WHERE { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . # Delimita um retângulo na superfície FILTER (?lat < -22.898474 && ?lat > -22.959342 && ?lng > -43.272572 && ?lng < -43.142624 && ?C != lgdo:Amenity && ?C != lgdo:Node) } # Qamenity: executada várias vezes alterando apenas valor do ?offset CONSTRUCT { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . } FROM <http://linkedgeodata.org> WHERE { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . # Delimita um retângulo na superfície FILTER (?lat < -22.898474 && ?lat > -22.959342 && ?lng > -43.272572 && ?lng < -43.142624 && ?C != lgdo:Amenity && ?C != lgdo:Node) } ORDER BY ?uri OFFSET ?offset LIMIT ?limit 98 A realização de inferência sobre estes dados reunidos usando a ontologia criada permitiu relacionar as instâncias hid:HidranteDeColuna com a classe lgdo:FireHydrant, e de forma semelhante hid:OBM com foaf:Organization e lgdo:FireStation. As partes mais relevantes do arquivo XML de configuração são apresentadas a seguir: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 <InferenceModule> <name>Rio Maps</name> <prefixes>...</prefixes> <resourceBaseUri> http://derived.viconsaga.com.br/cbmerj/pgorh/resource/ </resourceBaseUri> ... <loaders> <PullLoader> <description>Carrega hidrantes e seus recursos</description> <endpoint>...</endpoint> <queryConfigs> <QueryData> <query>Qhid</query> <interval>60*60*1000</interval> <binder class="DefaultQueryParameterBinder" /> </QueryData> </queryConfigs> </PullLoader> <PullLoader> <description>Carrega lgdo:Amenity de LGD</description> <endpoint>http://linkedgeodata.org/sparql</endpoint> <queryConfigs> <QueryData> <query>Qamenity</query> <interval>60*60*1000</interval> <binder class="OffsetSplitterQueryParameterBinder"> <description>Contagem de lgdo:Amenity</description> <limit>100</limit> <endpoint>http://linkedgeodata.org/sparql</endpoint> <query>Qcontagem</query> </binder> </QueryData> </queryConfigs> </PullLoader> </loaders> <inference> <reasoner>PELLET</reasoner> <ontology>hidracol.owl.xml</ontology> </inference> <sparqlServer> <path>/ds/</path> <port>32000</port> 99 42 </sparqlServer> 43 </InferenceModule> Para viabilizar consultas por parte da aplicação, duas funções foram construídas e adicionadas ao módulo por meio de plug-ins: maxMatch(texto1, texto2) – retorna o grau de similaridade, entre 0 e 1, entre os textos identificados por texto1 e texto2. Os parâmetros de entrada podem ser textos constantes entre aspas ou variáveis contendo um texto. distanceFromDegrees(lat1, lon1, lat2, lon2) – retorna a distância, em metros, entre dois pontos geográficos. Os parâmetros de entrada podem ser números constantes fornecidos diretamente ou passados por variáveis. A primeira função permite comparar nomes digitados pelo usuário da aplicação com os nomes das entidades geográficas existentes na base integrada, a fim de encontrar aquelas que o usuário está provavelmente se referindo. Já a segunda função é usada para retornar a distância entre uma entidade geográfica e cada hidrante de coluna, permitindo descobrir hidrantes próximos a ela. A próxima seção mostrará consultas utilizadas pela aplicação que aplicam estas funções. 4.1.3 Aplicação de consumo e considerações Com o término de todo processo descrito, os dados de hidrantes de coluna do sistema ViconWeb foram triplificados, integrados com dados da LinkedGeoData e disponibilizados em um endpoint provido pelo módulo de inferência. Para fins de demonstração, uma interface de consulta Web foi elaborada pelo mesmo aluno Tiago Marino de forma a receber como entrada uma localidade geográfica da cidade do Rio de Janeiro (existente na classe lgdo:Amenity da base LGD) e o raio de busca. A aplicação recebe os parâmetros de entrada do usuário, cria consultas SPARQL considerando estes parâmetros, as envia para o endpoint e recebe os resultados em formato JSON. Por exemplo, para consultar “Todos os hidrantes de coluna operantes no raio de 500 metros do comércio Casas Pedro”, duas consultas (e consequentemente duas requisições) são enviadas ao endpoint. A primeira delas visa buscar o URI que representa a Casas Pedro: 1 2 3 4 5 SELECT ?x ?l ?r WHERE { { SELECT DISTINCT ?x ?l (sfn:maxMatch(?l, "Casas Pedro") AS ?r) WHERE { ?x a lgdo:Amenity ; rdfs:label ?l 100 6 7 8 9 } ORDER BY DESC(?r) } FILTER (?r > 0) 10 } O URI encontrado é <http://linkedgeodata.org/triplify/node633485277> que é então passado para a segunda consulta que busca todos os hidrantes de coluna operantes a uma distância inferior a 500 metros das coordenadas (?lat, ?lon) da Casas Pedro. Esta consulta é apresentada a seguir: 1 SELECT * 2 WHERE { 3 { SELECT ?label ?hyd ?hlat ?hlon 4 (gfn:distanceFromDegrees(?hlat, ?hlon, ?lat, ?lon) as ?dist) 5 ?endereco ?sit ?vazao 6 WHERE { 7 <http://linkedgeodata.org/triplify/node633485277> 8 geo:lat ?lat ; 9 geo:long ?lon . 10 ?hyd a lgdo:FireHydrant ; 11 geo:lat ?hlat ; 12 geo:long ?hlon ; 13 hid:endereco ?endereco ; 14 hid:situacaoOperacional ?sit ; 15 hid:vazao ?vazao . 16 FILTER (?sit = hidres:OPERANTE) 17 } 18 ORDER BY ?dist 19 } 20 FILTER (?dist < 500) 21 } Como retorno, a aplicação apresenta um mapa do Google Maps, centrado na localidade buscada, traça um círculo com o raio definido pelo usuário na entrada, e todos os hidrantes de coluna com situação operacional igual a “OPERANTE” (podem existir hidrantes em más condições) dentro do raio de busca (Figura 17). 101 Figura 17. Lista de Resultados na aplicação protótipo desenvolvida. Algumas considerações devem ser feitas a respeito deste cenário. Primeiramente, buscou-se apresentar os procedimentos básicos que envolvem o processo de extração, transformação, publicação e integração a partir de dados armazenados nos formatos tradicionais para o padrão RDF, tornando-os disponíveis em um padrão legível por máquinas na Web e com semântica definida por uma ontologia. O ganho de se utilizar este padrão é seu caráter interoperável, que possibilita a integração entre bases provenientes de distintas fontes, como demonstrado na consulta apresentada. Outra observação importante é que os atributos descritores do objeto “Hidrante de coluna”, utilizados como base para a montagem e pesquisa dos vocabulários, foram elaborados pelos próprios membros do Corpo de Bombeiros, sendo estas pessoas as mais indicadas para modelar um objeto desta natureza por lidarem diretamente com este tipo de entidade. Quanto aos dados do LGD, verificou-se que a quantidade de entidades geográficas da cidade era pequena, o que mostra que ainda há um grande caminho a se percorrer até que existam bases realmente completas. Contudo, acredita-se que num futuro próximo, com a crescente demanda e adesão pela publicação de dados abertos no padrão LOD, os dados disponibilizados para a resposta a situações de emergência, saúde, trânsito, segurança pública serão mais confiáveis e atualizados, transformados em informação para apoio à decisão. 102 4.2 Cenário 2: alertas sobre chuvas e escorregamento de terra Este cenário foi inspirado pelas tragédias que ocorreram no Estado do Rio de Janeiro entre 2010 e 2012, principalmente na região serrana e nos municípios de Niterói e Rio de Janeiro. Diversos óbitos ocorreram devido a enchentes e soterramentos, estes ocorridos após o deslizamento de terras em encostas ocupadas irregularmente por casas em comunidades carentes. Após os fatos ocorridos, o então prefeito do município do Rio de Janeiro, Eduardo Paes, ordenou a implantação de sirenes para alertar a população de diversas localidades sobre possíveis riscos de deslizamentos.23 Esta iniciativa incorre em gastos de recursos com implantação e manutenção que poderiam ser redirecionados para outras necessidades como treinamento da população e de pessoal caso infraestruturas já existentes fossem aproveitadas. Assim, o objetivo deste cenário é utilizar o framework apresentado neste trabalho para mostrar uma possível abordagem para notificação de usuários sobre a condição e possíveis riscos existentes no local em que ele se encontra. Geralmente estes locais são encostas de morros ou áreas carentes. Celulares convencionais poderiam ser utilizados para enviar mensagens de texto a números previamente cadastrados, contudo Smatphones oferecem serviços mais sofisticados como localização corrente e acesso à Internet sem fio. Apesar de parecer absurdo que usuários das classes C e D tenham acesso a dispositivos móveis de alta tecnologia, pesquisas de mercados mostram que tais pessoas desejam adquiri-los e não se importam em pagar inúmeras prestações.24 Desta forma, Smartphones ultrapassam a barreira de meros dispositivos de entretenimento e status social, para serem também de utilidade pública. Limitou-se a utilizar a localização corrente do usuário, mas outras localizações, fornecidas manualmente ou capturadas de dados históricos, poderiam ser utilizadas em um cenário mais realista. Um objetivo técnico adicional deste cenário foi verificar a capacidade de se usar comparações, iterações e cálculos matemáticos simples como agregações (redução dos valores de uma lista a um único valor, como por exemplo, soma e média). Nas próximas seções apresentar-se-á o domínio do cenário descrito, sua modelagem e implementação usando o framework proposto nesta dissertação. 23 Mais informações em http://oglobo.globo.com/rio/paes-afirma-que-todas-as-comunidades-mapeadas-pelageorio-receberao-sirenes-de-alerta-ate-fim-do-ano-2791735 e http://oglobo.globo.com/rio/mais-35-favelasdo-rio-terao-sirene-de-alerta-de-chuva-3730766 24 http://www.omelhordomarketing.com.br/desejos-dos-consumidores-classe-cd/ 103 4.2.1 Domínio da aplicação e modelagem Neste cenário utilizaram-se medidas pluviométricas provenientes do Alerta-Rio25, um sistema de alerta mantido pela prefeitura da cidade do Rio de Janeiro através da Fundação Geo-Rio desde 1997. A Fundação Instituto de Geotécnica (Geo-Rio) é um órgão da Secretaria Municipal de Obras da Prefeitura do Rio de Janeiro responsável por avaliar e mapear as encostas da Cidade do Rio de Janeiro.26 O sistema é composto por 33 estações pluviométricas distribuídas sobre a área geográfica da cidade. A concentração das estações varia estrategicamente (AZEVEDO, 2011) e sua distribuição atual pode ser vista na Figura 18, extraída da página Web do sistema Alerta-Rio. A medição pluviométrica é feita em milímetros com resolução de 0,2 mm e medida a cada 15 minutos, sendo os dados de cada estação transmitidos a uma estação central via rádio (SILVA, 2008). A intensidade, frequência e duração das chuvas contribuem, juntamente com a instabilidade do solo e a gravidade, para a movimentação de massas de terra e rochas ao longo de uma encosta (AZEVEDO, 2011; SILVA, 2008). Tais movimentos são denominados movimentos de massa e, apesar de a literatura apresentar diversas classificações para tais movimentos este trabalho apresentará apenas a definição do termo escorregamento, utilizado pelo Alerta Rio. Assim, escorregamentos são “movimentos rápidos, de duração relativamente curta, de massas de solo ou rocha geralmente bem definidas quanto ao seu volume” (SILVA, 2008) ou “deslocamento rápido de (...) massa de rocha, solo residual ou sedimentos existentes em uma encosta, possuindo um centro de gravidade que se desenvolve seguindo para frente e para baixo” (AZEVEDO, 2011). 25 Sistema Alerta Rio - http://obras.rio.rj.gov.br/alertario.htm 26 Fundação Instituto de Geotécnica (Geo-Rio) - http://portalgeo.rio.rj.gov.br 104 Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) 27 Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008) Classificação Intensidade pluviométrica (mm/h) da chuva Chuvisco Chuva Leve <= 0,25 1,1 a 5,0 Moderada 0,25 a 0,5 5,1 a 25 Forte > 0,5 25,1 a 50 Muito Forte --- > 50,0 A partir das medições pluviométricas é possível definir a intensidade da chuva em cada estação conforme apresentado no Quadro 8. No entanto, a intensidade da chuva em mm/h apenas não é suficiente para detectar a probabilidade de escorregamento, sendo necessário considerar o histórico de chuvas. Assim, a quantidade de água acumulada durante 96 horas seguidas de chuva leve de 2,0 mm/h em média representa uma probabilidade muito alta de haver algum deslizamento. O Quadro 9 mostra os níveis de alerta (ou probabilidade) de escorregamento de terra definidos pelo sistema Alerta-Rio (AZEVEDO, 2011). 27 Coluna sobre chuviscos retirada de http://www.bibliotecapolicial.com.br/upload/documentos/ESTUDO- PLUVIOMETRICO-E-REDUCAO-DE-DESASTRES-21069_2011_5_12_8_42.pdf, que usou uma revista sobre o GEORIO como fonte mas esta não foi encontrada. 105 Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011) Quantidade de chuva acumulada por tempo Nível de alerta 1 hora 24 horas 96 horas Moderado 10-30 mm 50-100 mm 100-175 mm Alto 30-50 mm 100-175 mm 175-250 mm Muito Alto > 50 mm > 175 mm > 250 mm A partir das medidas provenientes das estações pluviométricas pretende-se calcular a suposta quantidade de chuva incidindo sobre a localização do usuário. Para isto, será usada uma interpolação baseada no método de inverso do quadrado da distância usando as três estações mais próximas. Isto é equivalente à média ponderada pelo inverso do quadrado das distâncias entre as estações e o usuário. Assim, a suposta quantidade de chuva acumulada num ponto geográfico P=(x,y), onde o usuário se localiza, será dada pela seguinte fórmula: v (t ) ( P) 1 (t ) 1 (t ) 1 (t ) v v v 2 1 2 2 2 3 d1 d2 d3 1 1 1 2 2 2 d1 d2 d3 Equação I. Cálculo da quantidade de chuva acumulada num ponto. Onde di determina a distância em linha reta, na Terra, entre P e a localização da iésima estação mais próxima de P, vi(t) representa a soma das t últimas medições da i-ésima estação. Desta forma, t é igual a 4 para a última hora, 96 para as últimas 24 horas e 384 para as últimas 96 horas. Uma vez calculados tais valores, utiliza-se o Quadro 9 para descobrir a probabilidade de escorregamento no ponto P. No caso de haver diferentes resultados para cada valor de t será utilizado o pior nível de alerta. A intensidade de chuva (Quadro 8) será sempre calculada com base no v(1) e no v(4), ou seja, 15 minutos (última medição) e uma hora (quatro últimas medições) respectivamente. Para o último caso, serão usados os dados do quadro (mm/h) e, para o primeiro caso, estes valores serão divididos por 4 para se obter em mm/15min. Como a divisão de medidas de chuvisco por 4 resulta em valores menores que 0,28 e a resolução dos hidrômetros é de 0,2 mm, apenas a coluna do Quadro 8 com intensidades de chuva serão utilizadas para classificação de 15 minutos. Portanto 0,2 mm/15min será considerado como sem chuva e 0,4 mm/15min como chuva leve (0,4 × 4 = 106 1,6 mm/h). O Quadro 10 apresenta estes valores utilizados. Novamente, em caso de divergências entre mm/h e mm/15min a classificação de maior intensidade será utilizada. A metodologia de geração dos valores do ponto P será descrita na próxima seção. Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos Classificação da chuva Intensidade pluviométrica (mm/15min) Ausente < 0,28 Leve 0,28 a 1,25 Moderada 1,25 a 6,25 Forte 6,25 a 12,5 Muito Forte > 12,5 4.2.2 Camada de dados e sensoriamento Para este cenário, três SPARQL endpoints simulados foram criados. O primeiro deles, denominado Rain Stations Endpoint (RSE), provê dados históricos de medidas do Alerta-Rio. O segundo, denominado User Locations Endpoint (ULE) simula movimentação de usuários na cidade. Ambos podem ser classificados como sensores físicos, pois provêm dados capturados do ambiente (pluviômetro e GPS). O terceiro, chamado Neighborhood Endpoint (NBE), é um endpoint adicional apenas para permitir descobrir se um ponto pertence a um polígono (um interpretador de contexto) usado para fornecer contexto a nível de bairro. Modelagem e implementação deles serão descritas nas próximas subseções e apêndices referenciados conforme necessário. 4.2.2.1 Rain Stations Endpoint (RSE) Para sua construção foi necessário obter previamente os dados históricos de chuva. O Alerta-Rio os disponibiliza para download no site, contudo, é necessário selecionar o ano a que as medições se referem para cada estação. Para automatizar este processo um script Python que constrói as URLs e baixa os arquivos foi construído. Estes dados obtidos foram inseridos em um banco de dados MySQL e mapeados para RDF utilizando o software D2RQ28 que faz mapeamento em tempo real, pois quando recebe uma consulta SPARQL gera uma consulta SQL e retorna o resultado conforme o protocolo SPARQL. 28 D2RQ Platform: Accessing Relational Databases as Virtual RDF Graphs - http://d2rq.org/ 107 O diagrama de entidade-relacionamento para estes dados é composto pelas tabelas measure e station conforme apresentado à direita da Figura 19. A tabela station possui atributos para identificar a estação (chave primária), nome da estação, sua latitude e longitude, e datas de início e final de operação (uma estação ativa precisa ter data final posterior à data atual). A tabela measure possui atributos para identificar a medida (chave primária), identificar a estação medidora (chave estrangeira), além de data e valor da medição. O vocabulário RDF (à esquerda da Figura 19) é semelhante, contendo as classes Station e Measure e os datatype properties stationName, latitude, longitude, beginDate e endDate para Station e measureValue e measureDate para Measure. Por fim, cada medição é ligada à estação medidora por meio da object property station. Por ser bastante simples e também ser usado apenas no endpoint, não foi criado um vocabulário RDF Schema, sendo tudo isso apresentado diretamente nas instâncias pelo mapeamento. Isto será importante para demonstrar um endpoint sem ontologia ou vocabulário explícitos sendo mapeado para os elementos (classes e propriedades) da ontologia de domínio que será apresentada posteriormente. xsd:decimal xsd:dateTime a:measureValue a:measureDate a:beginDate a:endDate xsd:decimal a:Measure a:station id (PK) : INT station_id (FK) : INT date : DATETIME value : DOUBLE a:Station a:latitude a:longitude xsd:decimal xsd:string measure a:stationName station id (PK) : INT name : VARCHAR(40) latitude : DOUBLE longitude : DOUBLE begin_date : DATETIME end_date : DATETIME Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o mapeamento entre conceitos. O mapeamento usando D2R entre banco de dados e vocabulário é apresentado no Apêndice A. O URI de cada recurso segue o padrão <http://alertario.rio.rj.gov.br:2020/ resource/CLASSE/ID>, onde CLASSE é Station ou Measure e ID é o respectivo valor da coluna id do recurso. Como a tabela measure possui mais de 15 milhões de registros e consultas equivocadas como “recupere todas a medidas” demorariam muito tempo para serem 108 respondidas foi criada uma visão atualizada a cada 5 segundos que engloba apenas as últimas 96 horas de medição. 4.2.2.2 User Locations Endpoint (ULE) Este endpoint simula a obtenção das coordenadas de usuário por meio de um GPS. Foram criadas duas maneiras de se gerar tais coordenadas. A primeira, usada para testes iniciais, utiliza dois cenários de movimentação de usuários (um usuário por cenário) cujas rotas foram geradas no Google Maps e exportadas para KML (Keyhole Markup Language) manualmente. A segunda, usada para simular mais de dois usuários, é feita aleatoriamente através de um gerador de coordenadas e rotas automático. Para ambas as informações são armazendas em um banco de dados MySQL e o software D2R efetua o mapeamento como no endpoint anterior. A figura apresenta o diagrama do banco de dados, o vocabulário RDF e o mapeamento entre tabelas e classes. A separação entre o usuário e sua localização foi feita porque a tabela location fica em memória para ter uma atualização mais rápida. O URI dos recursos também segue o padrão <http://users.com.br:2026/resource/CLASSE/ID>. Para detalhes sobre a estrutura do KML exportado pelo Google Maps e os algoritmos de geração das coordenadas consulte o Apêndice B. xsd:string usr:nome usr:Usuario usr:localizacao user id (PK) : INT nome : VARCHAR(60) usr:Ponto xsd:decimal usr:latitude usr:longitude xsd:decimal xsd:dateTime usr:atualizacao location id (PK) : INT latitude : DOUBLE longitude : DOUBLE instant : DATETIME user_id : INT Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o mapeamento entre conceitos 4.2.2.3 Neighborhood Endpoint (NBE) Este endpoint é o mais simples e foi adicionado apenas para mostrar a possibilidade de obter contextos adicionais. Ele utiliza um módulo de inferência que armazena URIs e nomes de bairros em RDF e contém uma função nb_contains adicionada por meio de plugin. Esta função detecta se um ponto está dentro do polígono do bairro (identificado por seu URI) ou 109 não.29 As bordas dos polígonos dos bairros foram obtidas do Portal Geo da Prefeitura do Rio de Janeiro30 e são carregadas de um arquivo KML e armazenados internamente, i.e, não disponíveis em RDF. O uso da função (em negrito) é apresentado a seguir, onde também se pode observar o pequeno vocabulário criado (conceitos mapa:Bairro e propriedade rdfs:label): 1 2 3 4 5 6 PREFIX mapa: http://mapa.rio.rj.gov.br:25070/ontology# DESCRIBE ?b WHERE { ?b a mapa:Bairro . # rdfs:label contém o nome do bairro FILTER(geo:nb_contains(?b, -43.258041, -22.995279)) } 4.2.3 Camada de inferência Nesta seção apresentar-se-á o algoritmo, a ontologia e a disposição dos módulos de inferência necessários para atingir o objetivo de emissão dos alertas apresentados na seção 4.2.1. Uma vez que os endpoints simulados apresentados na seção anterior foram colocados à disposição, o ambiente necessário está pronto para ser usado. Na sequência serão apresentados (1) o algoritmo de cálculo dos níveis de alerta na posição do usuário, e (2) a organização dos módulos de inferência e a ontologia utilizada. A configuração detalhada da rede de módulos será apresentada no Apêndice C. 4.2.3.1 Algoritmo para cálculo de níveis de alerta Antes de apresentar o algoritmo, cabe relembrar o método, primeiramente precisa-se obter a posição dos usuários, e a seguir, para cada um deles calcular a suposta quantidade de chuva (Equação I) nos últimos 15 minutos, 1 hora, 24 horas e 96 horas (períodos), e classificá-las conforme os níveis de alerta dos quadros 8, 9 e 10. O algoritmo a seguir apresenta como isto seria feito utilizando um único programa: 1 2 3 4 5 6 7 users = SELECT ?uid ?location WHERE { ?uid a User ; location ?location } FOR u IN users DO l = u.location d = SELECT ?sid (geo:distance(?slat, ?slon, 29 O algoritmo utilizado pode ser encontrado em http://alienryderflex.com/polygon 30 Portal Geo - http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm 110 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 l.lat, l.lon) as ?dist) WHERE { ?sid a Station ; location [ latitude ?slat ; longitude ?slon ] } ORDER BY ?dist LIMIT 3 dtot = 0 FOR e IN d DO dtot = dtot + 1 / e.dist ^ 2 avg15 = avg60 = avg24 = avg96 = 0 FOR e IN d DO w = ((1 / e.dist ^ 2) / dtot) avg15 += w * acc_rain(e.sid, 15min) avg60 += w * acc_rain(e.sid, 60min) avg24 += w * acc_rain(e.sid, 24h) avg96 += w * acc_rain(e.sid, 96h) slv60 = map(avg60, [10 : Attention, 30 : Moderate, 50 : High], VeryHigh) slv24 = map(avg24, [50 : Attention, 100 : Moderate, 175 : High], VeryHigh) slv96 = map(avg96, [100 : Attention, 175 : Moderate, 250 : High], VeryHigh) u.slipLevel = max(slv60, slv24, slv96) rlv15 = map(avg15, [0.28 : HeavyDrizzle, 1.25 : LightRain, 6.25 : ModerateRain, 12.5 : HeavyRain], VeryHeavyRain) rlv60 = map(avg60, [0.00 : Dry, 0.25 : LightDrizzle, 0.50 : ModerateDrizzle, 1.10 : HeavyDrizzle, 5.00 : LightRain, 25.0 : ModerateRain, 50.0 : HeavyRain], VeryHeavyRain) u.rainLevel = max(rlv15, rlv60) 111 57 FUNCTION acc_rain(sid, range) 58 RETURN SELECT (SUM(?v) AS ?acc) 59 WHERE { 60 ?m station sid ; 61 measureValue ?v ; 62 measureDate ?t . 63 FILTER (?t >= TIMEDIFF(NOW, range) 64 && ?t <= NOW) } 65 66 FUNCTION map(v, m, default) 67 FOR e IN m DO 68 IF v <= e.key THEN RETURN e.value 69 RETURN default Apesar de parecer um algoritmo pequeno, seria um pouco complexo implementá-lo com as bibliotecas Java existentes. Note que, para facilitar a compreensão, as consultas SPARQL foram colocadas como parte do próprio código e sem informação dos endpoints consultados. Resumidamente, obtém-se uma lista com URIs e localizações dos usuários (linhas 1-3) e, ao iterar sobre a lista (linhas 4-55), obtém-se as três estações mais próximas (linhas 5-15), calcula-se a suposta quantidade de chuva, nos quatro períodos, dada pela fórmula da seção 4.2.1 (linhas 17-26) e, por fim, é feita a classificação dos níveis de alerta conforme dados dos quadros 8, 9 e 10 (linhas 28-55). Nas linhas 57-64 é calcula a soma das medições de uma estação durante o intervalo de tempo fornecido no parâmetro range. Finalmente, as linhas 66-69 mostram a função que mapeia um valor v para um nível de alerta conforme a tabela m fornecida. O algoritmo desmembra a Equação I em três outras confome pode ser visto na Equação II a seguir. Em (a) calcula-se a suposta quantidade de chuva como soma das medições acumuladas vi(t) ponderadas por um peso wi; em (b) calcula-se o peso wi da estação i e, em (c) calcula-se o denominador do peso wi. Examinando o algoritmo, verifica-se que as linhas 17-18 calculam a Equação IIc, a linha 22 calcula Equação IIb e, as linhas 23-26 calculam a Equação IIa para t igual a 1, 4, 96 e 384. Desta forma, ao término do laço da linha 21, as variáveis avg15, avg60, avg24 e avg96 possuem os valores v(1)(P), v(4)(P), v(96)(P) e v(384)(P), respectivamente. 112 3 (t ) wi vi(t ) v ( P) (a) i 1 wi 1 2 di d total 3 d total j 1 2 1 dj (b) (c) Equação II. Desmembramento da Equação I em três equações separadas. 4.2.3.2 Organização dos módulos e ontologia Esta seção apresentará a organização dos módulos para implantar o algoritmo discutido e a ontologia construída para validar a consistências dos dados. Para implementar este algoritmo, precisa-se primeiramente avaliar como distribuir as consultas e regras de forma que se encaixe na estrutura atual do framework: carregamento, processamento com ontologias e regras, e publicação. A primeira separação é simples, bastando separar a função acc_rain em um módulo que calcula a chuva acumulada em cada estação pluviométrica. Este poderia ser até mesmo um endpoint fornecido pelo próprio sistema Alerta-Rio. Outra separação possível é nas linhas 1-15, onde um módulo pode calcular e guardar as distâncias entre usuários e estações. Finalmente, um terceiro módulo pode fazer consultas para cálculo da suposta quantidade de chuva (linhas 17-26) e processar regras para classificação (linhas 28-55). Estes módulos serão doravante denominados M1, M2 e M3, respectivamente. Para ilustrar o acréscimo de obtenção do contexto de bairro do usuário utilizando o endpoint NBE, mais um módulo foi adicionado e será chamado M4. A Figura 21 ilustra a configuração da rede que será detalhada nos próximos parágrafos. As setas indicam a direção das respostas às consultas SPARQL, as linhas contínuas representam consultas primárias e as tracejadas representam consultas secundárias realizadas por binders do tipo SelectQueryParameterBinder. Os textos próximos às setas são os nomes atribuídos às consultas cujo Apêndice C explicará em detalhes. Por fim, as linhas com tracejado diferenciado ligam cada módulo a um pequeno resumo descritivo sobre ele. 113 Applicação Contexto de bairro Applicação Suposta quantidade de chuva + classificação da intensidade de chuva e dos níveis de alerta de escorregamento Qapp M4 M3 Seleciona estações mais próximas Qchuva Chuva acumulada por estação + Localização das estações ativas M2 Qdist Quser Qacc2 Qacc Qstloc NBE ULE Legenda: M1 RSE consulta primária consulta secundária (binder) Módulo - Sentido inverso: consultas SPARQL - Sentido direto: respostas RDF Descrição resumida Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento. Neste cenário, a tarefa descrita no algoritmo será realizada apenas com consultas (responsáveis por mapear conceitos usando SPARQL Construct) e regras Jena (apenas no M3 para fazer classificação). Contudo uma ontologia foi construída apenas para validar a consistência dos dados usando o reasoner Pellet (módulos M1, M2 e M4). A Figura 22 apresenta a ontologia OWL composta por oito classes que foi validada como OWL-DL pelo Pellet. A classe Station representa uma estação pluviométrica e a classe User o usuário, de forma que ambas possuem uma localização associada. A primeira é associada com Location através da propriedade location e, a segunda, associada a uma subclasse desta denominada UserLocation através das propriedades currentLocation e inferenceLocation. Estas duas propriedades para localização do usuário são adotadas, pois a localização corrente do usuário pode, e geralmente é, diferente da posição utilizada na inferência. Isto ocorre porque apesar de a primeira ser obtida tanto por M2 quanto por M4, quando o processamento de M3 termina e disponibiliza a localização obtida por M2, esta pode não ser mais a mesma da disponibilizada atualmente pelo ULE. Portanto, M4 pode ler duas localizações: a atual disponibilizada por ULE e a usada na inferência que pode ser mais antiga. A propriedade updateTime informa data e hora de atualização das coordenadas (latitude e longitude) do usuário. Sendo assim, seria possível verificar o atraso aproximado gerado pela inferência. Adicionalmente, uma localização contém as propriedades accRainX, que apresentam a quantidade de chuva acumulada nos últimos 15 minutos (X=15), 1 hora (X=01h), 24 horas (X=24h) ou 96 horas (X=96h) medida por um estação ou calculada com base na Equação I; rainLevel e slipLevel, 114 que representam as classificações de intensidade de chuva e probabilidade de escorregamento; e por fim, locatedAt que informa a qual bairro a localização pertence (classe Neighborhood). A classe UserLocation adiciona a propriedade nearestStations que associa a localização do usuário com a classe StationDistanceInfo que representa uma das estações mais próximas (station) com a respectiva distância (distance). Finalmente, as classes RainLevel e SlipLevel correspondem ao rdfs:range das propriedades rainLevel e slipLevel, respectivamente. Seus possíveis valores (instâncias) são fixos, pois seguem as classificações dos Quadros 8, 9 e 10, e sua ligação à respectiva classe são representadas por uma linha tracejada. (Figura 22) x:Dry, x:LightDrizzle, x:ModerateDrizzle, x:HeavyDrizzle, x:LightRain, x:ModerateRain, x:HeavyRain, x:VeryHeavyRain xsd:dateTime x:latitude x:longitude x:RainLevel x:rainLevel x:Low, x:Moderate, x:High, x:VeryHigh x:locatedAt x:name xsd:string x:name x:location x:Neighborhood x:Station x:UserLocation x:nearestStations x:station x:currentLocation x:inferenceLocation x:accRain15 x:accRain01h x:accRain24h x:accRain96h x:Location x:slipLevel x:SlipLevel x:User xsd:decimal x:updateTime x:distance xsd:double x:StationDistanceInfo Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas. No final, uma aplicação poderia fazer a seguinte consulta ao endpoint M4: 1 SELECT ?usuario ?bairroAtual ?horaLocAtual ?bairroInf ?horaLocInf 2 (geo:distanceFromDegrees(?lat1, ?lon1, ?lat2, ?lon2) as ?dist) 3 (afn:localname(?rainLevel) as ?classChuva) 4 (afn:localname(?slipLevel) as ?probEscrg) 5 WHERE { 6 ?u a x:User ; 7 x:name ?usuario ; 8 x:currentLocation [ 9 x:locatedAt [ x:name ?bairroAtual ]; 10 x:latitude ?lat1; x:longitude ?lon1; 11 x:updateTime ?horaLocAtual 12 ] ; 13 x:inferenceLocation [ 14 x:locatedAt [ x:name ?bairroInf ]; 15 x:latitude ?lat2; x:longitude ?lon2; 115 16 17 18 19 20 } x:updateTime ?horaLocInf; x:slipLevel ?slipLevel; x:rainLevel ?rainLevel ] ; As infomações retornadas são apresentadas na Tabela 11. As colunas com o prefixo “horaLoc” indicam o horário de quando as coordenadas da localização do usuário foram medidas pelo GPS, e as colunas “bairro” informam o bairro a qual estas coordenadas pertencem. As colunas com sufixo “Atual” foram capturadas diretamente de ULE por M4 e as colunas com sufixo “Inf” foram capturadas indiretamente de ULE através do caminho M1M2-M3-M4. A coluna “dist” informa a distância entre a posição “Atual” e a posição “Inf”, enquanto que as duas últimas colunas contêm as classificações de intensidade de chuva e probabilidade de escorregamento para a posição “Inf”. Tabela 11. Exemplos de resultados da consulta ao M4: atraso pequeno (acima) e pouco mais significativo (abaixo). usuario Camille Moraes Mateus Veiga John Alcantara Jeane Murta bairroAtual Ramos Jacarepagua Jacarepagua Pca Bandeira horaLocAtual 2010-04-06T00:15:13 2010-04-06T00:15:13 2010-04-06T00:15:13 2010-04-06T00:15:13 bairroInf Olaria Jacarepagua Jacarepagua Pca Bandeira horaLocInf 2010-04-06T00:14:31 2010-04-06T00:14:31 2010-04-06T00:14:31 2010-04-06T00:14:31 dist classChuva probEscrg 913,39 ModerateRain Moderate 933,56 LightRain Moderate 933,40 LightRain Moderate 934,52 HeavyRain Moderate usuario Camille Moraes Mateus Veiga John Alcantara Jeane Murta bairroAtual Copacabana Barra da Tijuca Vila Militar Vasco da Gama horaLocAtual 2010-04-06T01:43:09 2010-04-06T01:43:09 2010-04-06T01:43:09 2010-04-06T01:43:09 bairroInf Gavea Camorim Realengo Jacarezinho horaLocInf 2010-04-06T01:40:47 2010-04-06T01:40:47 2010-04-06T01:40:47 2010-04-06T01:40:47 dist classChuva probEscrg 4393,48 LightRain High 3133,75 ModerateRain Moderate 3156,04 HeavyRain Moderate 3155,34 ModerateRain High Para finalizar a seção, dois exemplos de notificações que uma aplicação poderia fazer usando estes resultados são mostrados a seguir. Para o primeiro suponha que o horário do informe seja 00h16min41s e para o segundo 01h45min50s. 1 2 “Camille Moraes, dados pluviométricos baseados na sua localização no bairro Olaria há 2min10s apontam chuva de intensidade moderada e probabilidade de escorregamento moderada. Uma posição mais recente foi obtida há 1min28s a 910 m de distância no bairro Ramos mas ainda não foi processada.” “Camille Moraes, dados pluviométricos baseados na sua localização no bairro Gávea há 5min03s apontam chuva de intensidade leve e probabilidade de escorregamento alta. Uma posição mais recente foi obtida há 2min41s a 4,4 km de distância no bairro Copacabana. Apesar de agora a chuva estar fraca, o acumulado mostra que lugares sucetíveis a escorregamento de terra estão arriscados.” 116 4.2.4 Discussão Ainda em relação à Tabela 11, observa-se que horaLocInf <= horaLocAtual, conforme esperado. Esta diferença pode ser mais ou menos significativa (tabelas inferior e superior), pois depende dos intervalos entre consultas definidos em cada um dos módulos do caminho, da velocidade de conexão da rede e capacidade de processamento. Uma melhor avaliação destes atrasos e possíveis formas de contorná-los (como uso de push loaders) deve ser alvo de trabalhos futuros. Uma difículdade adicional encontrada na implementação deste cenário foi a necessidade de construir três endpoints para simular um mundo onde dados de sensores físicos (ULE, RSE) e bases de dados provedoras de contexto (NBE) estivessem disponíveis. Vantagens e desvantagens podem ser verificadas. Primeiramente, a quantidade de chuva acumulada por estação é calculada por M1 de uma vez a cada 2,5 minutos evitando repetição de consultas como o algoritmo sugere. Contudo, uma implementação convencional do algoritmo (via programação) poderia fazer cache destes valores e atualizar (a) em intervalos de tempo predefinidos (como na rede detalhada aqui) ou (b) quando houvesse modificação. Neste segundo caso, quando novos dados fossem gerados pelo RSE, alguma consulta seria executada e os resultados enviados ao cache. Um problema desta abordagem é a possibilidade de que tais dados fossem gerados em sequência e em intervalos de tempo muito curtos (ordem de milissegundos) o que acarretaria na abertura de muitas conexões TCP, sendo necessário considerar medidas como conexões persistentes ou enviar respostas em rajada (acumular até que uma certa quantidade fosse atinginda e/ou que algum intervalo de tempo expirasse). Esta abordagem recai nos já discutivos push loaders (carregadores assíncronos) que devem ser estudados em trabalhos futuros. Outra vantagem é que apesar de ser necessário construir ontologias, consultas e regras, que se apresenta como um trabalho longo e cansativo, após tais elementos estarem definidos, a construção dos arquivos XML de configuração é muito simples. Além disso, tais elementos precisariam ser construídos mesmo em uma implementação envolvendo programação convencional. A configuração via XML reduz a necessidade de programação, deixando a implementação do cerne da solução para modeladores e também para especialistas nas tecnlogias padronizadas da Web Semântica (RDF, OWL, SPARQL e futuramente uma linguagem para regras). A consulta Qchuva é complexa (veja Apêndice C), mas a implementação do algoritmo usando programação também o é, sendo difícil concluir sem experimentos que comparem ambas as abordagens. 117 Observando as consultas construídas, verifica-se também que o sistema poderia ser expandido facilmente para considerar outras localizações, e não apenas a atual medida pelo GPS, como casa, trabalho, destinos de viagens, etc. com poucas mudanças. Na verdade bastaria haver mais instâncias de usr:Ponto na base ULE e criar um propriedade base para inferenceLocation e currentLocation ou tornar location esta propriedade base. Poderia-se também criar, por exemplo, propriedades homeLocation, workingLocation, entre outras, mas o uso de uma propriedade base seria mais simples. Uma nova propriedade de usr:Ponto poderia ser responsável por manter a informação sobre o que significa aquele ponto (casa, posição atual, trabalho, etc.) ou poderia-se também criar subclasses. Por fim, pequenas alterações seriam feitas nas consultas Quser e Qchuva. Outro aspecto interesante é que a expansão da Equação I para qualquer valor constante N de estações mais próximas pode ser atingido modificando apenas o valor do LIMIT no Sub-SELECT da consulta Qdist. Veja Apêndice C para detalhes das consultas. Assim, a partir da implementação deste cenário, verificou-se que apesar de alguns problemas terem sido encontrados, há indícios de que a abordagem pode ser boa devido a redução da necessidade de programação e da possibilidade de validar a base sendo disponibilizada. 4.3 Cenário 3: notificação sobre eventos sociais e chegadas de ônibus Devido à agitação diária nos dias atuais é cada vez mais difícil para as pessoas gerenciar compromissos (reuniões de trabalho, aniversários de casamento, etc.) sem utilizar meios eletrônicos que auxiliem a armazenar e lembrar a ocorrência destes eventos. Além disso, nem todos os eventos podem ser determinados com antecedência e adicionados a uma agenda, mesmo que eletrônica, como é o caso de chegadas de um ônibus ou metrô no ponto ou estação onde um usuário se localiza. Neste segundo caso um atraso na chegada de um metrô ou ônibus deixaria o usuário aguardando, provavelmente parado e entediado, enquanto que a ciência do atraso permitiria que ele adiantasse outras possíveis tarefas que não dependessem daquele transporte naquelo momento. Este cenário tem por objetivo ilustrar o uso de ontologias, consultas e regras dispostas em módulos do framework para gerar notificações aos usuários sobre alguns dos eventos discutidos acima. Além disso, o cenário não deve ser muito complexo para possibilitar entendimento por parte das pessoas que irão testar e avaliar o framework. Este cenário é, 118 justamente, o escolhido para que alunos de Web Semântica testem o framework e forneçam suas avaliações via questionário (próximo capítulo). Por fim, mas não menos importante, este cenário ilustrará o consumo de dados de três SPARQL endpoints independentes que são integrados por meio de ontologias comuns, diferentemente do cenário anterior que apresentava uma ontologia para cada endpoint que eram mapeadas para a ontologia de domínio via SPARQL Construct. As próximas subseções apresentarão maiores detalhes sobre o domínio, incluindo as ontologias e os endpoints criados para serem usados como exemplo e a implementação da rede de módulos. Maiores detalhes técnicos são abordados no Apêndice D e no Apêndice E. 4.3.1 Domínio da aplicação e modelagem Para gerar notificações sobre eventos foi montado um conjunto de ontologias que pudesse representar os aspectos dos domínios das relações sociais e dos transportes por ônibus necessários para a construção do cenário. Sendo assim, ontologias para os tópicos tempo, eventos e relacionamento entre pessoas foram adaptadas de outras existentes, e uma ontologia de transporte rodoviário por ônibus foi construída. Nas próximas subseções serão detalhadas estas ontologias e uma ontologia específica da aplicação que expande as ontologias de eventos e transporte por ônibus com o objetivo de mostrar como ontologias de aplicação podem estender ontologias já existentes. 4.3.1.1 Ontologia de tempo e eventos (TEvOnto) Para descrever eventos e suas ocorrências no tempo foram definidas duas ontologias. A ontologia de tempo é uma versão simplificada da OWL Time (PAN; HOBBS, 2003) e a ontologia de eventos é um subconjunto da Ontonym Event Ontology (STEVENSON et al., 2009). Eventos podem possuir datas de início e fim bem definidas como datas ou festas de aniversários, reuniões de trabalho, etc. ou podem ser ocorrências pontuais no tempo cujo intervalo não pode ser facilmente caracterizado como chegadas de ônibus em um ponto. Para isso, são definidos eventos de intervalo e de instante, que se baseiam nos conceitos de intervalo e instante da OWL Time. Na Figura 23 pode-se observar estas ontologias. A classe TemporalEntity é a superclasse para representação do tempo. Esta se especializa em Interval e Instant que representam um intervalo de tempo com início e fim e um instante pontual no tempo, respectivamente. A classe Event é a superclasse das classes IntervalEvent e InstantEvent que 119 representam eventos de intervalo e de instante, respectivamente. As propriedades hasBeginning e hasEnd representam início e fim de um intervalo e a propriedade hasDateTime representa um ponto no tempo. As três propriedades possuem um xsd:dateTime como rdfs:range que armazena ano, mês, dia, hora, minuto e segundo. As propriedades timeSpan e atTime relacionam um evento com o respectivo objeto de tempo. Por fim, existe uma classe Role (papel), cujas instâncias são indivíduos que desempenham algum papel em um evento. Role e Event são ligados por meio da propriedade playsRole indicando que o primeiro tem participação no segundo. A maior parte das classes e propriedades foi aproveitada das ontologias OWL Time e Ontonym Event. Contudo, propriedades de Instant foram removidas para dar lugar a hasDateTime e as propriedades hasBeginning e hasEnd de Interval tiveram seus ranges modificados para xsd:dateTime. Figura 23. Diagrama das ontologias de tempo e eventos utilizadas. 4.3.1.2 Ontologia de relações sociais (SoROnto) Para representar as relações sociais foi desenvolvida uma ontologia que usa o conceito foaf:Person e cria outros conceitos baseados nas ontologias Relationship31 e Ontonym Person Ontology (STEVENSON et al., 2009). A Figura 24 apresenta o diagrama de classes que é formado pelos conceitos foaf:Person, rel:Woman e rel:Man, que representam pessoas como a união disjunta (owl:disjointUnionOf) de mulheres e homens e os conceitos rel:Relationship, rel:Marriage e rel:Courtship que representam relacionamentos genéricos, casamentos e namoros respectivamente. Os participantes são sempre pessoas e, embora possível, nenhum outro tipo de relacionamento precisou ser criado para o cenário. Uma pessoa é uma entidade 31 RELATIONSHIP – A vocabulary for describing relationships between people: http://vocab.org/relationship 120 geográfica (geo:SpatialThing) pois possui dados de localização (latitude e longitude). Esta mesma figura apresenta o domínio e a imagem das propriedades que relacionam pessoas. Na Figura 25 pode-se observar a hierarquia das propriedades que representam as relações parente (rel:relativeOf), ancestral e descendente (rel:ancestorOf e rel:descendantOf), pai e mãe (rel:parentOf, rel:motherOf, rel:fatherOf), filho(a) (rel:childOf), irmão e irmã (rel:siblingOf, rel:sisterOf, rel:brotherOf), conhecido (foaf:knows), amigo(a) (rel:friendOf), vizinho(a) (rel:neighborOf) e relacionamentos amorosos genéricos (rel:romanticallyInvolvedWith) e mais específicos como matrimônio (rel:spouseOf, rel:husbandOf, rel:wifeOf) e namoro (rel:courts, rel:boyfriendOf, rel:girlfriendOf). Na mesma figura aparecem alguns detalhes: do lado direito a propriedade sobre a data de aniversário de uma pessoa, e do lado esquerdo mostra que propriedades ligados por seta dupla são inversas uma da outra e uma seta dupla ligando a mesma propriedade indica que está é simétrica. Figura 24. Diagrama de classes da ontologia de relações entre pessoas. Figura 25. Diagrama de hierarquia de propriedades da ontologia de relações entre pessoas. 121 4.3.1.3 Ontologia de transporte por ônibus (BusOnto) A terceira ontologia foi desenvolvida para representar ônibus, paradas e linhas de ônibus e itinerários destas linhas. Sua construção não se baseou em nenhuma ontologia existente, sendo, portanto, fruto deste trabalho. Na Figura 26 é possível ver que ela se baseia em cinco classes principais: bus:Stop, bus:Line, bus:Route, bus:RouteStop e bus:Bus. A primeira representa uma parada ou ponto de ônibus possuindo um nome além de um par de coordenadas geográficas provenientes da classe geo:SpatialThing. A segunda representa uma linha de ônibus possuindo um código, um nome e uma rota (ou itinerário). O código é uma sequencia de números e letras que identifica a linha, por exemplo, no município do Rio de Janeiro, linhas convencionais são identificadas por três números: 485, 497, 910. A terceira classe representa um itinerário com sentido, portanto linhas com caminhos de ide e volta possuem duas rotas e linhas circulares possuem apenas uma rota. Esta classe apresenta um ponto inicial e um ponto final que podem ser os mesmos para o caso de linhas circulares. Contudo estes pontos não são representados pela mesma classe bus:Stop, mas pela classe bus:RouteStop que indica o ponto de uma rota de ônibus. Para entender melhor esta distinção repare que um bus:Stop não necessariamente é seguido por um outro ponto de ônibus em todos os itinerários, assim é necessária uma classe que permita manter esta sequência. Desta forma, um bus:RouteStop possui as propriedades bus:nextStop e bus:previousStop (que são inversas entre si) para formar a sequência de paradas e também a propriedade bus:belongsToRoute para determinar a qual itinerário pertence. Adicionalmente, há um atributo bus:sequence que permite saber numericamente qual o índice desta parada na rota e um atributo bus:distanceFromOrigin que apresenta a distância em metros desde o ponto inicial da rota até a respectiva parada seguindo todo o caminho do itinerário. Por fim, a última classe é a bus:Bus que representa um ônibus que circula na cidade e, consequentemente, possui coordenadas geográficas da sua posição atual, uma rota e uma linha associadas além dos atributos bus:number, bus:traveledTime e bus:traveledDistance. O primeiro é apenas o número do carro, também conhecido como número de ordem. O segundo e terceiro indicam o tempo decorrido e a distância percorrida deste a saída do carro do ponto inicial. 122 Legenda double domain geo:lat geo: SpatialThing double property range bus:sequence string geo:long integer bus:name rdfs:subClassOf bus:Bus bus:number bus:distanceFromOrigin bus:stop bus:Stop bus:startStop bus:nextStop bus:previousStop integer bus:finalStop bus:traveledTime integer float bus: RouteStop bus:Route bus:belongsToRoute bus:route bus:name string bus:belongsToLine bus:code float bus:traveledDistance bus:Line string bus:servingLine Figura 26. Ontologia de transporte por ônibus. 4.3.1.4 Ontologia específica da aplicação (AppOnto) A última ontologia a ser apresentada é a ontologia específica da aplicação. Ela estende as ontologias TEvOnto e BusOnto através da adição de classes que representam eventos de datas comemorativas e de chegadas de ônibus, papéis de aniversariante, de amigo de aniversariante e de passageiro, além das notificações. A Figura 27 apresenta a ontologia da aplicação juntamente com partes relevantes das ontologias bases (TEvOnto e BusOnto). As classes evt:IntervalEvent e evt:InstantEvent são especializadas em app:CommemorativeDate e app:BusArrival que representam uma data comemorativa e uma chegada de ônibus, respectivamente. Datas comemorativas podem ser eventos genéricos como dia dos namorados (app:ValentinesDay) e feriado (app:Holiday), eventos pessoais individuais (que dependem apenas de uma pessoa para ocorrer) como aniversário (app:Birthday), ou eventos pessoais em dupla (ocorrência dependente de duas pessoas) como aniversário de namoro ou casamento (app:CourtshipDay e app:WeddingDay). Um feriado pode ser especializado em Dia das Mães (app:MothersDay). Estas classificações de evento genérico e pessoal poderiam ter sido explicitadas na ontologia assim como outros tipos de evento poderiam ter sido construídos, mas decidiu-se por não poluir a ontologia com informações desnecessárias e facilitar entendimento por partes do leitor. No lado direito da 123 figura pode-se observar as relações entre alguns destes novos eventos e três novos papéis criados (subclasses de evt:Role). Todos estes novos papéis são também subclasses de foaf:Person. Assim, app:Passenger representa um possível passageiro (poderia ser likely passenger), app:BirthdayPerson representa um aniversariante e app:BirthdayPersonsFriend um amigo de aniversariante (birthday person’s friend). O primeiro papel é associado ao evento chegada de ônibus por meio da propriedade app:isPassengerOf, ou seja, diz que uma pessoa é um possível passageiro do ônibus prestes a chegar, ou seja, do ônibus associado ao evento de chegada. O segundo e terceiro papéis são associados ao evento aniversário por meio das propriedades app:isBirthdayPersonOf e app:isBirthdayPersonsFriendOf. Todas as três propriedades são especializações da propriedade evt:playsRole que representa uma participação em um evento (canto inferior esquerdo da figura). Na região superior direita observa-se um maior detalhamento do evento app:BusArrival que relaciona um ônibus com o ponto de ônibus onde ele está prestes a chegar. Apesar de não ter sido ilustrado, este evento herda a propriedade evt:atTime de evt:InstantEvent como visto na Figura 23. Nesta mesma região do diagrama aparece a classe app:BusStopRecommendation que representa uma recomendação sobre qual dentre os pontos de ônibus mais próximos do usuário está no caminho de uma certa rota de linha de ônibus de maneira que esta rota irá posteriormente passar num ponto cujo nome foi especificado pelo usuário através da propriedade app:desiredDestination. Desta maneira, a propriedade app:stop representa tal parada de ônibus, a propriedade app:route representa a rota e o atributo app:distance representa a distância entre a posição atual do usuário e a posição do ponto de ônibus. A propriedade app:recommendedBusStop liga um usuário a uma recomendação. Ainda com respeito a Figura 27, observa-se no canto superior esquerdo a classe app:Notification que representa uma notificação a um usuário sobre a ocorrência de um evento. O usuário é dito o alvo da notificação e relacionado através da propriedade app:target, e o evento é relacionado pela propriedade app:event. Apesar de o alvo sempre ser um usuário neste cenário, decidiu-se por deixar a classe owl:Thing como o range da propriedade app:target, pois acredita-se que notificações não necessariamente precisam ser enviadas apenas a pessoas. Os atributos app:remainingTime e app:remainingDays indicam quanto tempo falta para o evento ocorrer em segundos e dias respectivamente. As consultas e regras associadas à criação de eventos, participações, recomendações e notificações serão apresentadas na seção sobre a camada de inferência. 124 Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus. 4.3.2 Camada de dados e sensoriamento Para este cenário, três SPARQL endpoints simulados foram criados. O primeiro deles, denominado Commemorative Dates Endpoint (CDE), fornece datas comemorativas que sejam eventos gerais (independentes da existência de uma pessoa). O segundo, denominado User’s Social Networks and Locations Endpoint (USNLE), armazena a rede social, localização e destino desejado dos usuários. O terceiro, chamado Bus Locations Endpoint (BLE), armazena tanto informações estáticas como rotas e pontos de ônibus quanto informações dinâmicas sobre a localização geográfica de cada carro. Para facilitar a compreensão por parte dos experimentadores apenas BLE sofre atualizações frequêntes e as demais bases são estáticas, logo, as localizações dos usuários e seus destinos nunca se alteram. BLE é um provedor de contexto que fornece dados de uma rede de sensores físicos e de bases de dados, pois provêm dados que seriam capturados pelos dispositivos GPS dos ônibus e também informações estáticas e impessoais de rotas, linhas, etc. USNLE é um provedor de contexto como perfis de usuário e sensores físicos. Estes endpoints não possuem ontologias específicas como no Cenário 2, logo o mesmo conjunto de ontologias descrito na seção 4.3.1 é utilizado por eles, com apenas algumas particularidades que serão descritas ao longo das demais subseções juntamente com sua implementação. 125 4.3.2.1 Commemorative Dates Endpoint (CDE) Este endpoint estático armazena informações sobre datas comemorativas que independem da uma ou mais pessoas para ocorrer. Estas datas se enquadram em um dos eventos genéricos app:ValentinesDay, app:Holiday e app:MothersDay, que por serem eventos de intervalo possuem uma data fixa de início e fim. O Quadro 12 apresenta os eventos adicionados à base com as respectivas classes e datas de início e término, todos com intervalo de um único dia. Por questões de espaço a coluna “Recurso” contém apenas a parte final do URI do evento, de forma que a URI do evento é obtida pela concatenação do URI base <http://commemorative_days.org/resource/> com o respectivo valor da coluna. Utilizando os valores do quadro descreve-se um evento usando a seguinte sequência de triplas: 1 2 3 4 5 6 7 :ConfUniv2012 a app:Holiday ; rdfs:label "Feriado do Dia da Confraternizacao Universal"@pt ; evt:timeSpan [ a time:Interval ; time:hasBeginning "2012-01-01T00:00:00Z"^^xsd:dateTime ; time:hasEnd "2012-01-02T00:00:00Z"^^xsd:dateTime ] . Para colocar o endpoint funcionando utilizou-se o próprio Módulo de Inferência, pois, neste caso, ele apresenta duas vantagens em relação a bases de triplas tradicionais: (a) uso de uma consulta simples para gerar dados, e (b) configuração simples da ontologia AppOnto. Devido à obrigatoriedade de se especificar um endpoint como fonte de dados, esta consulta utiliza o próprio endpoint gerado pelo módulo, porém a cláusula WHERE é vazia e todas as triplas estão estaticamente presentes na cláusula CONSTRUCT. Devido a esta estaticidade a consulta pode ter intervalo entre execuções bastante longo. O uso da AppOnto permite inferência imediata das superclasses de cada evento e das classes dos blank nodes representando cada intervalo de tempo além da checagem da consistência dos dados. Na configuração do módulo apresentada a seguir observe o uso do mesmo endereço para servidor SPARQL e endpoint de consulta (localhost na porta 50000), o intervalo de 24 horas entre execuções da consulta e a configuração do Pellet para utilizar a ontologia AppOnto: 1 2 3 4 5 6 7 8 <InferenceModule> <name>Base de dados de datas comemorativas</name> ... <loaders> <PullLoader> <endpoint>http://localhost:50000/graph/sparql</endpoint> <queryConfigs> <QueryData> 126 9 <query> 10 CONSTRUCT { 11 :ConfUniv2012 a apv:Holiday ; 12 rdfs:label "Feriado da Confraternizacao Universal"@pt ; 13 evt:timeSpan [ 14 a time:Interval ; 15 time:hasBeginning "2012-01-01T00:00:00Z"^^xsd:dateTime ; 16 time:hasEnd "2012-01-02T00:00:00Z"^^xsd:dateTime 17 ] . 18 # Demais eventos aqui... 19 } 20 WHERE { } 21 </query> 22 <interval>24*60*60*1000</interval> 23 <binder class="DefaultQueryParameterBinder" /> 24 </QueryData> 25 </queryConfigs> 26 </PullLoader> 27 </loaders> 28 <inference> 29 <reasoner>PELLET</reasoner> 30 <ontology>AppOnto.owl</ontology> 31 </inference> 32 <sparqlServer> 33 <path>/graph/</path> 34 <port>50000</port> 35 <fastUpdate>false</fastUpdate> 36 </sparqlServer> 37 </InferenceModule> Quadro 12. Datas comemorativas utilizadas no endpoint CDE com as respectivas classes e datas. Recurso Classe Início Fim ConfUniv2012 apv:Holiday 2012-01-01T00:00:00Z 2012-01-02T00:00:00Z Tiradentes2012 apv:Holiday 2012-04-21T00:00:00Z 2012-04-22T00:00:00Z Trabalho2012 apv:Holiday 2012-05-01T00:00:00Z 2012-05-02T00:00:00Z Independencia2012 apv:Holiday 2012-09-07T00:00:00Z 2012-09-08T00:00:00Z DiaNamorados2012 apv:ValentinesDay 2012-06-12T00:00:00Z 2012-06-13T00:00:00Z DiaDasMaes2012 apv:MothersDay 2012-05-13T00:00:00Z 2012-05-14T00:00:00Z 127 4.3.2.2 User’s Social Networks and Locations Endpoint (USNLE) Este endpoint contempla informações da rede social dos usuários, suas localizações e também os destinos desejados por eles. A rede social é apresentada na Figura 28 e as demais informações no Quadro 13. Pela figura pode-se observar que existem 12 usuários no endpoint e eles se relacionam de diversas formas, contudo as informações estão incompletas e as relações implícitas são descobertas com base na ontologia SoROnto. Algumas datas de aniversário, casamento e namoro foram definidas para Carlos Silva, Julia Silva, Ana Lins Silva e alguns outros. O quadro de Carlos Silva, por exemplo, que contém sua data de aniversário (1970-09-15) que é representa pela propriedade rel:dateOfBirth. Outro exemplo é a relação de casamento entre Carlos e Julia (rel:Marriage) que pode ser construída com base na afirmação de que Carlos é marido de Julia e se casaram em 1992-07-05 (conforme apresentado no inferior da relação rel:husbandOf). Este casamento pode ser escrito usando as triplas a seguir que definem, além da propriedade rel:husbandOf, o recurso CarlosAndJuliaMarriage que é instância do conceito rel:Marriage e tem Carlos como participante (rel:participantIn). O processo de inferência pode descobrir que este recurso também é uma instância de evt:IntervalEvent através da propriedade evt:timeSpan. 1 2 3 4 5 6 :CarlosSilva rel:husbandOf :JuliaLins ; rel:participantIn :CarlosAndJuliaMarriage . :CarlosAndJuliaMarriage a rel:Marriage ; evt:timeSpan :CarlosAndJuliaMarriageTime . :CarlosAndJuliaMarriageTime a time:Interval ; time:hasBeginning "1992-07-05T00:00:00Z"^^xsd:dateTime . 128 Paulo Lins Pedro rel:brotherOf rel:fatherOf Rodrigo rel:friendOf Manoel Silva rel:brotherOf Carlos Silva (1970-09-15) Julia Silva (1971-04-08) rel:husbandOf (1992-07-05) rel: childOf Marcelo rel: friendOf rel:friendOf rel:girlfriendOf (2011-06-15) Vitor Ana Lins Silva (1994-05-08) rel: friendOf Mariana rel:motherOf rel:boyfriendOf (2010-04-17) Felipe foaf:knows Joana rel:neighborOf Figura 28. Rede social dos usuários do endpoint USNLE. O Quadro 13 apresenta os usuários cuja localização geográfica é conhecida e um texto representando o destino deles. Note que este texto simula uma digitação feita pelo próprio usuário. Os dados do quadro são facilmente convertidos em triplas que obedecem as ontologias criadas conforme apresentado a seguir para o usuário Pedro: 1 2 3 4 :Pedro geo:lat -22.860754 ; geo:long -43.227124 ; rdfs:comment "Localizado no ponto da Letras"@pt ; app:desiredDestination "alojamento" . Quadro 13. Localização atual e destino desejado dos usuários do USNLE. Usuário Destino desejado latitude longitude Descrição do local Pedro alojamento -22,860754 -43,227124 Ponto da Letras AnaLinsSilva penha -22,858565 -43,232525 Vermelhinho Felipe general -22,858565 -43,232525 Vermelhinho Marcelo vila -22,857799 -43,232585 Sala do CCMN Mariana hospital -22,858900 -43,230620 Bloco A do CT 129 Vitor penha -22,842834 -43,234262 Estacionamento do CCS em frente ao BB Por também ser uma base estática que necessita de inferência foi aplicada a mesma ideia do CDE de usar um módulo de inferência. Foi escrita uma consulta com triplas descrevendo as informações dos usuários e as ontologias TEvOnto e SoROnto foram definidas para inferência. Consulta e o arquivo XML de configuração não serão mostrados para evitar repetições desnecessárias. 4.3.2.3 Bus Locations Endpoint (BLE) Este endpoint necessita tanto simular movimentação dos ônibus quanto fazer inferência com respeito à ontologia BusOnto. A simulação de movimentação foi feita de forma similar ao endpoint ULE do Cenário 2 (seção 4.2.2.2), utilizando uma aplicação Java que atualiza um banco de dados relacional e o D2R que mapeia os dados do banco relacional para triplas e as disponibiliza em um SPARQL endpoint. Para processamento das ontologias decidiu-se utilizar o módulo de inferência pelo mesmo motivo dos endpoints CDE e USNLE (seções 4.3.2.1 e 4.3.2.2): facilidade de alimentação de dados e configuração das ontologias e do endpoint. Observando-se a Figura 26 (pág. 122), verifica-se que a ontologia inclui dados com alta e baixa taxa de atualização. Apenas a classe bus:Bus está relacionada a dados com alta taxa, enquanto que as demais classes possuem dados raramente atualizados, apenas quando há mudanças em itinerários, linhas e pontos de ônibus (durante a execução deste cenário estes dados nunca são modificados de fato). A montagem real deste endpoint é apresentada na Figura 29. O endpoint BusD2R fornece dados sobre instâncias das classes bus:Stop, bus:Line, bus:Route, bus:RouteStop e bus:Bus correspondendo a uma parte da ontologia BusOnto para evitar a escrita de longos arquivos de mapeamento do D2R. As triplas publicadas com este vocabulário são expandidas e validadas através de inferências feitas pelos demais módulos apresentados na figura. Optouse por utilizar dois módulos para evitar processamento repetitivo e desnecessário dos dados estáticos. Assim, o módulo BusStatic consome os dados estáticos do endpoint BusD2R (paradas, linhas, rotas e paradas de rotas) e o módulo BusDyn consome os dados dinâmicos de ônibus (classe bus:Bus). Mas especificamente, BusStatic envia uma consulta DESCRIBE ao endpoint BusD2R para listar e descrever as instâncias das classes bus:Stop, bus:Line, bus:Route e bus:RouteStop a cada hora e usa Pellet para inferência da ontologia BusOnto. O módulo BusDyn envia uma consulta ao endpoint BusStatic para recuperar todas as triplas a 130 cada 10 minutos e outra consulta ao endpoint BusD2R para descrever as instâncias de bus:Bus a cada segundo, combinando todas estas triplas através do motor de inferência do Jena. Concluindo, o endpoint BLE agrupa estes três elementos (BusD2R, BusStatic e BusDyn) transformando-se em uma caixa preta que é acessada pela interface SPARQL do módulo BusDyn. Maiores detalhes são descritos no Apêndice D. BusDyn Rotas, linhas, etc. (10min) bus:Bus (10s) Legenda: BusStatic Módulo descrição Sentido inverso: consultas SPARQL Sentido direto: respostas RDF Rotas, linhas, etc. (1h) + Pellet BusD2R Figura 29. Estrutura interna do endpoint BLE. 4.3.3 Camada de inferência Nesta seção será apresentada a organização dos módulos para gerar as notificações utilizando as ontologias descritas na seção 4.3.1 e algumas regras. A configuração detalhada, com consultas e regras usadas, é apresentada no Apêndice E, sendo assim, esta seção fornece explicações menos técnicas. A camada de inferência é organizada em cinco módulos que são apresentados na Figura 30. Os nomes nas arestas representam consultas utilizadas e os números ao lado de alguns módulos informam a quantidade de regras utilizadas por ele. Os retângulos ligados aos módulos com uma seta tracejada descrevem suas funções. O módulo A1 obtém eventos genéricos de CDE (app:ValentinesDay, app:Holiday e app:MothersDay) e dados dos perfis de usuários com suas relações interpessoais (SoROnto) para gerar outros eventos e participações. No tocante aos eventos pessoais (apv:Birthday, apv:WeddingDay e apv:CourtshipDay) estes são criados a partir da propriedade rel:dateOfBirth de foaf:Person e relações entre indivíduos (rel:participantIn com objeto pertencente a um dos conceitos rel:Marriage ou rel:Courtship). As participações de usuários em eventos são geradas tanto para os eventos pessoais quanto para os genéricos (de CDE). 131 Legenda: Applicação consulta primária Gera notificações sobre eventos aos usuários consulta secundária (binder) NEvt 3 Módulo Gera recomendações de pontos próximos aos usuários com linhas úteis 1 Gera eventos pessoais e participações de usuários em eventos genéricos e pessoais B3 Qrec2 A1 Qcmdate 7 B2 Qurel Qrec CDE USNLE Descrição resumida Qlow Qhigh Qall Qall - Sentido inverso: consultas SPARQL - Sentido direto: respostas RDF Qarrival2 Gera possíveis participações de usuários nas chegadas de ônibus utilizando as recomendações B1 Qarrival1 BLE Gera eventos de chegadas de ônibus em pontos de ônibus Figura 30. Rede de módulos de inferência para notificações sobre eventos (números ao lados de módulos indica quantidade de regras usadas). A tríade B1-B2-B3 constrói as possíveis participações em eventos referentes a chegadas de ônibus. B1 gera apenas os eventos de chegadas (classe app:BusArrival) dizendo quais carros chegarão em quais pontos de ônibus e o horário estimado da chegada. B2 gera recomendações sobre qual dentre os pontos de ônibus mais próximos de cada usuário está no caminho de uma certa rota de linha de ônibus de maneira que esta rota irá posteriormente passar num ponto cujo nome foi especificado pelo usuário como destino desejado. Para tal, B2 obtém de USNLE as coordenadas geográficas atuais dos usuários e os destinos desejados por eles, assim como as coordenadas geográficas de pontos de ônibus e as rotas de BLE. B3 reúne os eventos de chegada de B1 e as recomendações de B2 e gera possíveis participações dos usuários nestes eventos (propriedade app:isPassengerOf). Por fim, NEvt agrupa as participações criadas por A1 e B3 e gera notificações sobre todos estes eventos utilizando três regras: (a) notificação de participações em eventos genéricos e pessoais (feriados, aniversário de casamento, etc., exceto aniversários de nascimento); (b) notificação a amigos de aniversariantes, que é uma evento pessoal, mas cujo aniversariante (que também é um participante) não precisa ser notificado; e (c) notificação sobre chegadas de ônibus provavelmente úteis. 132 4.3.4 Visualização das notificações em navegador Web Para visualizar as notificações foi construída uma pequena página Web. Ela plota ícones estáticos referentes aos pontos de ônibus (oriundos de BLE) e às localizações dos usuários (oriundos de USNLE) num mapa usando da API do Google Maps. A movimentação dos ônibus também é apresentada juntamente com notificações. A Figura 31 mostra os ícones espalhados no mapa e as notificações partindo do canto superior direito. A página foi construída usando JavaScript e Ajax no lado do cliente e Java no lado do servidor. O uso de Java se tornou imprescindível devido à facilidade de se portar para os alunos rodarem em seus micros sem precisar instalar servidores HTTP. Além disso, a especificação do objeto XMLHttpRequest usado em chamadas Ajax proíbe chamadas fora do domínio da página, assim, não seria possível executar as consultas aos endpoints USNLE e BLE, o que resultaria em cada aluno ter que executar todos estes endpoints em suas máquinas. As notificações para um usuário são exibidas ao clicar no respectivo ícone. Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações. 133 5 Experimentos e Resultados O teste com alunos visa receber comentários, críticas e sugestões sobre a eficiência do framework em cobrir os objetivos de reutilização e facilidade de configuração. No restante desta seção serão apresentados o formato do experimento e a avaliação dada pelos alunos. 5.1 Formato do experimento O experimento passado aos alunos consistiu na montagem da rede do cenário 3. Contudo, como a montagem desde o início seria algo muito complexo e o intuito não era de que os alunos escrevessem consultas e regras, mas sim que entendessem o funcionamento do módulo e como configurá-lo, de modo que pudessem ser capazes de pegar consultas e regras prontas e colocar na região certa do XML correto, decidiu-se solicitar que apenas completassem os arquivos XML. Sendo assim, algumas consultas e regras dos módulos foram retiradas, desordenadas e colocadas em um arquivo de texto separado. Antes de ser repassada aos alunos, a rede de módulos foi dividida em duas partes. A primeira parte consiste na criação de uma rede A1-A2, onde A2 é a parte de NEvt apenas com gerações de notificações sobre os eventos sociais. A segunda parte consiste em construir a rede completa através da complementação da rede A1-A2 da primeira parte. Esta complementação consiste na construção da rede B1, B2 e B3 e expansão de A2 até fazer o mesmo que NEvt. O exercício consistiu, então, em (1) completar cinco arquivos XML, um para cada módulo (A1, A2, B1, B2 e B3), que foram fornecidos propositalmente incompletos e; (2) estender o XML de A2 até ficar equivalente ao NEvt. O Quadro 14 apresenta quais consultas e regras foram removidas de cada um dos módulos (para detalhes sobre elas veja seção 4.3 e Apêndice E), qual o suposto nível de dificuldade e quais competências testadas em cada etapa. Note que foram apenas movidas dos XML para o arquivo texto sem qualquer modificação adicional. Quanto à configuração das portas, isto consiste em colocar o número da porta corretamente conforme a Figura 32, que ilustra as duas partes em que a rede foi dividida e também a sua organização. O grau de dificuldade foi classificado em três grupos: maior, médio e menor. A1 e A2x são considerados mais complexos por ser o primeiro contato com XML, consultas e regras, e por ser necessário expandir o XML e criar uma consulta, respectivamente. As etapas A2 e B3 foram classificadas como média, pois exigem a 134 configuração das portas, e isto não é informado, sendo necessário que o aluno perceba a ausência destas informações no XML inicial. De menor dificuldade são B1 e B2 que exigem competências já testadas nas etapas anteriores. Quadro 14. Consultas e regras removidas em cada módulo; competências testadas e grau de dificuldade para cada etapa. Consultas removidas Módulo A1 A2 Regras removidas Qcmdate - Competências testadas Dificuldade R3; R_EG3 Contato inicial com o XML; Adição de consultas e regras. Maior, por ser o primeiro Média R2 de NEvt Adição de regra; Configuração da porta do endpoint deste módulo. Menor Menor B1 Qarrival1 - Adição de consulta; Configuração da porta do endpoint deste módulo. B2 Qrec - Adição de consulta. Regra única Adição de regra; Média Configuração da porta dos endpoints consultados. B3 - A2x (NEvt) Qall de B3(criar); R3 de NEvt Qlow; Qhigh Expansão do XML para adição de consultas e regras; Criação de uma consulta simples. A2 NEvt Porta 45000 Porta 45000 Maior, por ser necessário expandir o XML B3 Porta 43000 A1 Porta 40000 A1 B2 B1 Porta 40000 Porta 41000 Porta 42000 Dates Users Dates Users Bus Porta 50000 Porta 51000 Porta 50000 Porta 51000 Porta 52000 (a) (b) Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b). Assim, o material entregue incluía o arquivo JAR do módulo de inferência, os cinco arquivos XMLs incompletos, o arquivo texto com as consultas e regras removidas dos XMLs, 135 um JAR contendo a página Web de visualização e uma apresentação em PDF. Esta apresentação foi construída com o intuito de ser uma pequena documentação que excluísse a necessidade de treinamentos presenciais. A apresentação foi dividida em quatro partes. A primeira parte faz um resumo das tecnologias RDF, OWL e SPARQL. A segunda, uma pequena motivação para o cenário. A terceira explica o módulo de inferência. A quarta explica o domínio do cenário e passa o exercício a ser feito de forma independente (com pouco ou nenhum auxílio) e individual. Antes de solicitar que os alunos fizessem estes exercícios, foi feito um teste piloto presencial com dois alunos separadamente. Assim, a apresentação foi mostrada e solicitou-se que eles completassem os XMLs. Suas dúvidas foram esclarecidas no mesmo momento da execução do teste. Algum tempo depois foi solicitado que respondessem a um questionário. Esse teste foi útil tanto para verificar se eles conseguiriam concluir a rede quanto para fazer algumas melhorias na apresentação. O tempo dispendido com cada um dos dois alunos foi de aproximadamente duas horas. Resultados serão apresentados na sessão seguinte. O teste remoto e independente foi feito com 14 alunos, dos quais 12 cursavam a disciplina de Web Semântica existente do Programa de Pós-Graduação em Informática (PPGI) e os demais eram alunos também do PPGI, mas já em fase de pesquisa de tese, que tivessem algum conhecimento prévio da tecnologia da Web Semântica. Para os alunos da disciplina foi feita uma apresentação rápida em sala de aproximadamente 15 minutos para explicar o que deveriam fazer no exercício, mas sem entrar em detalhes. Após uma semana houve uma sessão de laboratório de aproximadamente duas horas para esclarecimento de dúvidas, ou seja, não foi aula nem treinamento. Os alunos apresentavam algumas dificuldades encontradas e algumas diretrizes que levassem à solução eram apresentadas de volta. A seção seguinte apresentará os resultados. 5.2 Avaliações dos alunos Uma vez que os alunos terminavam a construção da rede eles respondiam um questionário para avaliar o experimento. A primeira parte do questionário consistiu em solicitar que o aluno dissesse qual o nível de conhecimento que ele considerava ter em relação à Programação, Web (HTTP e HTML), XML, Web Services, Grafos, URI e RDF, SQL, SPARQL, Lógica. Possíveis respostas eram Nenhum (0), Baixo (1), Moderado (2) ou Alto (3). A segunda parte consistiu-se em que dissessem como foi a compreensão das tecnologias, 136 do domínio da aplicação e do funcionamento do módulo e a facilidade de configuração e execução do módulo. Possíveis respostas eram Não entendi (0), Difícil (1), Moderado (2) e Fácil (3). A terceira parte consistiu em dizer quanto tempo, aproximadamente, foi gasto em cada etapa (A1, A2, B1, B2, B3 e A2x) e as possíveis respostas eram Não consegui (0), mais que 40 minutos (1), entre 25 e 40 minutos (2), 10 a 25 minutos (3), e menos que 10 minutos 4). A última parte era composta por questões abertas que perguntavam: a que o aluno atribuía a demora na etapa que ele perdeu mais tempo; se a documentação foi suficiente para entender o módulo e o domínio da aplicação; se achavam que o módulo atendia o objetivo de permitir reuso de consultas, ontologias e regras ao prover dados derivados, e quais foram as dificuldades e pontos positivos e negativos observados. As perguntas das três primeiras partes visavam obter dados quantitativos, contudo devido ao pequeno tamanho da amostra (16 alunos), acredita-se que não sejam estatisticamente relevantes. Portanto, apenas histogramas e medianas das respostas serão apresentados e discutidos sob o ponto de vista quantitativo. Para outras análises por parte do leitor estas respostas foram disponibilizadas no Apêndice F. 5.2.1 Alguns dados quantitativos Considerando todos os 16 alunos, verifica-se que a maioria deles informou não possuir um bom conhecimento de RDF e SPARQL (Figura 33a). Os itens serviços Web e Grafos também tiveram baixo grau de conhecimento, porém não eram relevantes neste experimento. Felizmente nenhum disse não ter entendido o experimento, contudo três alegaram achar as tecnologias, o domínio e a configuração difíceis (Figura 33b). Ainda neste histograma, onze disseram que compreender o funcionamento do módulo foi difícil e isto é um dado negativo visto que é um ponto crucial para sua correta utilização. Isto foi relatado, inclusive, por um dos alunos que fez o teste presencial. Por outro lado, 13 alegaram que a configuração do módulo é fácil ou moderada e 14 tiveram a mesma opinião sobre a execução. Quanto ao tempo gasto para completar o arquivo XML de configuração, apresentado na Figura 33c, a maioria disse ter gasto menos de 25 minutos em cada uma das etapas A2, B1, B2 e B3. As etapas A1 e A2x apresentaram resultados piores, conforme esperado, onde 4 e 5 relataram ter gasto mais que 40 minutos. Adicionalmente, dois alunos não conseguiram concluir a etapa A2x. 137 As Figuras 34, 35 e 36 detalham melhor o comportamento para cada tipo de teste isoladamente. A primeira figura mostra que ambos os alunos do teste piloto presencial tinham conhecimento ou moderado ou alto de programação, XML e lógica, mas um deles possui baixo conhecimento de RDF e SPARQL (Figura 34a). Quanto à dificuldade no experimento, um deles disse achar a compreensão do funcionamento difícil, e ambos acharam a configuração moderada e a execução fácil a moderada. Em relação ao tempo, a etapa A1 foi a mais complexa, contudo, ninguém demorou mais que 40 minutos (Figura 34c). Comparando com os histogramas da Figura 35 (teste remoto com alunos em pesquisa de tese), observa-se que há bastante semelhança em (a), contudo, neste caso os alunos disseram ter conhecimento moderado ou alto em RDF e SPARQL. No histograma (b), ambos disseram que tanto configuração quanto execução são fáceis e que a compreensão do funcionamento é fácil a moderada. Os tempos (Figura 35c) também se apresentaram equilibrados sendo a primeira e a última etapa as mais demoradas novamente. Na Figura 36 (teste com alunos da disciplina), verifica-se que a maioria diz entender de programação, XML e lógica, mas pouco de RDF e SPARQL. Dez dos 12 tiveram dificuldade em compreender o funcionamento, três em configurar e dois em executar. Quanto aos tempos, os resultados foram consideram adequados para as etapas intermediárias e razoáveis para a primeira etapa e última. Esta última, contudo, não foi completada por dois alunos conforme já relatado. Comparando os graus de dificuldade do Quadro 14 e os tempos dispendidos nas etapas apresentados nos histogramas, pode-se verificar que realmente as etapas A1 e A2x apresentam maior complexidade, e B2 menor complexidade. As demais etapas tiveram grau de dificuldade bastante similares que podem ser considerados medianos, contudo, B3 foi um pouco mais fácil que B1 e A2 um pouco mais difícil que B1. Resumindo, pode-se observar que alunos com maior dificuldade nas tecnologias da Web Semântica apresentaram maior dificuldade no experimento, o que permite concluir que realmente é necessário conhecê-las para utilizar o módulo, mesmo que as consultas já estejam prontas e seja necessário apenas entendê-las. 138 Respostas globais 12 10 8 (a) Nível de conhecimento nas tecnologias 6 Nenhum 4 Baixo 2 Moderado 0 Alto 12 10 (b) Dificuldade no experimento 8 6 Não entendi 4 Difícil 2 Moderado 0 Fácil 9 8 7 (c) Tempo de configuração e execução de cada etapa 6 Não consegui 5 Mais que 40 min 4 25 a 40 min 3 10 a 25 min 2 Menos que 10 min 1 0 A1 A2 B1 B2 B3 A2x Figura 33. Histogramas das respostas globais. 139 Alunos do teste piloto (teste presencial) 3 (a) Nível de conhecimento nas tecnologias 2 Nenhum 1 Baixo 0 Moderato Alto 3 (b) 2 Dificuldade no experimento 1 Não entendi Difícil 0 Moderado Fácil 3 Não consegui (c) Tempo de 2 configuração e execução de 1 cada etapa 0 Mais que 40 min 25 a 40 min 10 a 25 min A1 A2 B1 B2 B3 A2x Figura 34. Resultados do teste presencial com alunos. Menos que 10 min 140 Alunos em pesquisa de tese (teste remoto) 3 (a) Nível de conhecimento nas tecnologias 2 Nenhum 1 Baixo 0 Moderato Alto 3 (b) 2 Dificuldade no experimento 1 0 Não entendi Difícil Moderado Fácil 3 Não consegui (c) 2 Tempo de configuração e execução de 1 cada etapa 0 Mais que 40 min 25 a 40 min 10 a 25 min A1 A2 B1 B2 B3 A2x Figura 35. Teste remoto com alunos em pesquisa de tese. Menos que 10 min 141 Alunos da disciplina (teste remoto com esclarecimentos) (a) Nível de conhecimento nas tecnologias 10 9 8 7 6 5 4 3 2 1 0 Nenhum Baixo Moderato Alto 11 10 9 8 7 (b) 6 Dificuldade no 5 experimento 4 3 2 1 0 Não entendi Difícil Moderado Fácil 7 6 (c) 5 Tempo de 4 configuração e 3 execução de 2 cada etapa 1 0 Não consegui Mais que 40 min 25 a 40 min 10 a 25 min Menos que 10 min A1 A2 B1 B2 B3 A2x Figura 36. Resultados do teste remoto com alunos da disciplina. 142 Medianas das respostas das três primeiras partes do questionário (a) Nível de conhecimento nas tecnologias (0-3) 3.5 3.0 2.5 2.0 1.5 1.0 0.5 0.0 Global Alunos da disciplina Teste piloto Alunos em pesquisa tese 3.5 3.0 (b) Dificuldade no experimento (0-3) Global 2.5 2.0 1.0 Alunos da disciplina 0.5 Teste piloto 1.5 0.0 Alunos em pesquisa tese 4.5 4.0 Global 3.5 (c) Tempo de configuração e execução de cada etapa (0-4) 3.0 Alunos da disciplina 2.5 2.0 Teste piloto 1.5 1.0 Alunos em pesquisa tese 0.5 0.0 A1 A2 B1 B2 B3 A2x Figura 37. Mediana das respostas das três primeiras partes do questionário conforme valores atribuídos a cada resposta (quanto mais próximo do valor máximo melhor). 143 Os gráficos das medianas são apresentados na Figura 37. Para cálculo da mediana das respostas foram utilizados os valores apresentados no primeiro parágrafo da seção 5.2 (página 135). No gráfico da Figura 37a verifica-se que os alunos da disciplina possuem conhecimento das tecnologias da Web Semântica menor que os demais alunos, fato que parece explicar o maior tempo gasto na configuração dos módulos (Figura 37c). Por outro lado, os alunos em pesquisa de tese e do teste piloto, que tinham conhecimento maior das tecnologias, apresentaram maior facilidade na execução do experimento. Novamente pode-se verificar que a compreensão do funcionamento foi aquém do esperado o que pode ter comprometido os demais itens avaliados (Figura 37b). O aspecto positivo visto nesta figura é a facilidade de configuração ter apresentado medianas entre 2,0 (grupos de alunos do teste piloto e da disciplina) e 3,0 (alunos em pesquisa de tese) que representam as respostas Moderado e Fácil do questionário. A facilidade de execução foi até um pouco superior variando entre 2,0 (alunos da disciplina) e 3,0 (alunos em pesquisa de tese), mas com um dos valores sendo 2,5 (alunos do teste piloto). Novamente observa-se maior dificuldade nas etapas A1 e A2x. 5.2.2 Avaliações qualitativas A parte qualitativa do questionário foi composta pelas três perguntas descritas no início desta seção. Em relação à primeira delas, que pergunta a que o aluno atribuía a demora na(s) etapa(s) que ele perdeu mais tempo, os alunos que tiveram maior demora na etapa A1 declararam como motivo principal o fato desta ser a primeira etapa prática e o entendimento do domínio e/ou tecnologia ainda não estar claro (citado por 5 alunos), outros citaram não ter lido os arquivos de ajuda, estar com a porta bloqueada no computador do aluno (que não contribui para o resultado), e não ter percebido que as consultas estavam prontas. Aqueles que demoraram mais na etapa A2x disseram que esta tinha maior nível de dificuldade (2 alunos), se confundiram ao usar as regras fornecidas (2 alunos), teve falta de atenção ao definir as portas (1 aluno), e não entendeu claramente o que deveria ser feito (2 alunos, sendo que um disse que isto não estava claro na apresentação). Alguns destes alunos se sobrepõem por terem demorado em ambas as etapas. Alunos que apresentaram demora em mais de duas etapas relataram dificuldade em entender as regras (1 aluno, etapas A1, B1 e B3), demora em perceber que cada etapa dependia das anteriores (1 aluno, A1, A2 e B1), e desconhecimento das tecnologias que o obrigou a ler e reler o material (1 aluno, etapas B1, B2, B3 e A2x). Dois alunos não conseguiram terminar a etapa A2x. Um deles não disse o porquê de não ter conseguido e o outro disse não ter conseguido completar a tempo de entregar (para alunos da disciplina foi necessário definir um tempo para entregar esta tarefa). 144 A segunda pergunta questionava se a documentação foi suficiente para entender o módulo e o domínio da aplicação e foi feita a apenas 14 alunos (os dois do teste presencial não responderam esta pergunta pois a documentação ainda estava em desenvolvimento). A maioria das respostas foi positiva, contendo afirmações como muito boa (3 alunos), bem completa (2 alunos) clara e concisa (3 alunos) e suficiente (4 alunos), contudo algumas destas afirmações foi feita pelo mesmo aluno, totalizando 10 respostas claramente positivas. Uma resposta já esperada e considerada neutra foi que houve necessidade de ler e reler, mas conforme praticava foi ficando mais fácil de entender. Ressalvas apresentadas por estes 11 alunos foram que um leigo na tecnologia não entenderia bem (1 dos alunos em pesquisa de tese), o módulo poderia ser melhor explicado (1 aluno), o domínio era muito complexo (1 aluno), o XML poderia ser melhor detalhado (1 aluno) e, poderia ter mais exemplos de regras e não foi muito fácil perceber quais modelos eram exemplos e quais representavam as bases RDF usadas no exercício (1 aluno). Acréscimos às respostas positivas foram que a documentação explica o módulo e contextualiza o exercício (1 aluno), o material ensinou bastante (1 aluno) e, os diagramas foram fundamentais para o entendimento (1 aluno). As outras 3 respostas foram consideradas negativas. Um disse que leigos encontrariam dificuldade e o objetivo de cada etapa não ficou muito claro além de o domínio ser complexo. Outro disse que para quem não entende as tecnologias seria necessário um treinamento. O último disse que o conteúdo sobre a disciplina estava claro, mas a explicação sobre o que fazer nos exercícios não, sendo necessário ler diversas vezes e mesmo assim perguntar pessoalmente. Sobre as reclamações de que o que deveria ser feito não estava claro nos slides e que não teria visto os arquivos de ajuda ou que as consultas estavam prontas, isto ocorreu apenas com poucos alunos da disciplina, e provavelmente por não terem comparecido ou prestado atenção à primeira apresentação onde foi informado o que deveria ser feito (completar os XML com consultas e regras existentes em um arquivo texto fornecido com o material). Realmente os slides não foram criados para explicar detalhes práticos do exercício, apenas estrutura e funcionamento do módulo e o domínio da aplicação. A parte da apresentação que passava o exercício apenas chamava atenção para a marcação de tempo e dizia para adicionar consultas e/ou regras aos arquivos XML, discrimando-os no exercício de cada etapa. Adicionalmente, os arquivos XML apresentavam comentários na forma “EXERCICIO A2: PEGAR REGRA DO ARQUIVO” em letras maiúsculas logo acima do trecho que deveria ser 145 completado. Por isso, estas reclamações podem até ter prejudicado um pouco o resultado do experimento, mas não para produzir falsos resultados positivos, mas sim o contrário. A terceira pergunta era (1) se achavam que o módulo atendia o objetivo de permitir reuso de consultas, ontologias e regras ao prover dados derivados, e (2) quais foram as dificuldades e pontos positivos e negativos observados. Por haver um único campo de resposta nem todos os alunos responderam ambos os itens. O primeiro item teve 15 respostas, onde quatro afirmaram que sim, o objetivo foi atendido e os outros onze dissem acreditar que sim. Dentre as dificuldades encontradas, citaram dificuldade inicial com: sintaxe (1 aluno), definição das regras do JENA (1 aluno) e análise dos dados gerados (1 aluno). Outros disseram que foi montar o XML devido à falta de conhecimento das tecnologias e não devido à sintaxe em si (1 aluno), dúvidas, não informadas, na manipulação do XML (1 aluno), entender o exercício por meio dos slides que não estavam claros, mas que após descobrir que as consultas e regras estavam prontas foi fácil completar (1 aluno) e entender como os endpoints se interligam (1 aluno). Novamente, estas observações se sobrepõem tendo sido relatadas por 6 alunos. Um sétimo aluno relatou ter dificuldade em aprender a estrutura da linguagem, identificar a estrutura de dados na aplicação e construir consultas e regras. O primeiro parece referir-se ao XML, o segundo ao consumo dos dados pela aplicação e o terceiro pode ser devido ao domínio e/ou baixo conhecimento das tecnologias. Dois alunos relataram a queda do endpoint no último dia do prazo de entrega, que foi resolvido poucas horas após percepção da ocorrência. Os pontos negativos identificados foram dependência de conhecimento sobre a tecnologia e domínio da aplicação (2 alunos), domínio sobre ferramenta requer mais tempo (1 aluno), que a curva de aprendizado é grande (1 aluno), ter de executar diversos programas no exercício (1 aluno), mensagens de erro ao executar o módulo não eram claras mesmo com erros de fácil resolução (1 aluno) e, ausência de uma interface gráfica para configurar o XML, que aumentaria a utilidade do módulo (1 aluno). Um dos alunos detalhou sua opinião sobre a necessidade de conhecimento das tecnologias: SPARQL (alto), RDF (alto), regras (alto), grafos (médio), modelagem conceitual/ontologia (médio). Quanto aos pontos positivos, diversas foram as respostas, umas relacionadas ao módulo e outras específicas do exercício. Esta segunda foi que os cenários de uso propostos foram apropriados e ilustraram a importância da abordagem e que o exercício de completar consultas e regras foi apropriado para o aprendizado. Os pontos positivos do módulo relatados foram sua capacidade de simplificar consultas para usuário final após configurado e executado; execução e 146 visualização simples e intuitivas; permissividade de reutilização de informações de forma transparente para que várias aplicações consultem a mesma informação independente da plataforma; facilidade de se entender, configurar o XML e alterar a configuração, e executar; e configuração é bastante detalhada e flexível. Um fato curioso ao comparar as repostas é que 11 dos 16 alunos, sendo 10 alunos da disciplina disseram ter tido dificuldade de compreensão do funcionamento do módulo, mas nenhuma das respostas discursivas abordou este tema. Elas se direcionaram para a complexidade de se entender as tecnologias e o domínio da aplicação e, em menor quantidade, algumas dificuldades em manipular o arquivo XML. Em resumo, o módulo realmente parece proporcionar reuso de dados derivados e a facilidade de configuração e execução foi considerada moderada a alta, contudo a necessidade de conhecimento médio ou alto de XML, RDF, SPARQL e programação podem comprometer estes aspectos positivos. E, apesar de XML e programção serem bastante difundidos no meio de desenvolvedores, as tecnologias RDF e SPARQL ainda são um entrave para uma avaliação mais efetiva do módulo, fato observado pela dificuldade em se conseguir pessoas que pudessem testar o framework. Estas tecnologias semânticas não são fáceis de serem entendidas quando se deseja atender objetivos mais complexos, ou seja, quando se requer compreensão mais avançada sobre elas. O conhecimento do domínio é uma dificuldade que existe seja qual for a tecnologia adotada. Talvez ela seja mais reforçada quando se utilizam ontologias, regras e consultas SPARQL em vez de programação convencional e bancos de dados relacionais. Por fim, o funcionamento não foi facilmente compreendido, sendo necessário um aprimoramento da apresentação ou treinamento. 147 6 Considerações finais Este capítulo apresenta uma retrospectiva do trabalho apresentado nos capítulos anteriores como problema tratado, proposta, prova de conceito e experimentos com alunos. Por fim, aborda as contribuições, problemas e limitações do framework e trabalho futuros. 6.1 Retrospectiva Este trabalho pretendeu abordar, inicialmente, o problema da dificuldade se utilizar informações oriundas de diversas bases de dados e fontes de contexto ao construir uma aplicação ciente de contexto. Devido ao fato de existirem diversos formatos e variadas formas de comunicação se torna difícil construir tais aplicações. Por isso, existe a necessidade de que contextos sejam representados em um formato reutilizável e interoperável (PERTTUNEN et al., 2009). Para tentar lidar com isto, foi proposta a arquitetura LOUD (Linked Open Ubiquitous Data), uma arquitetura em três camadas (dados e sensoriamento, inferência e aplicação) e descentralizada que utiliza padrões da Web Semântica para comunicação entre seus componentes. A primeira camada é responsável por obter, armazenar e fornecer dados de sensores físicos, bases de dados e perfis do usuário. Os chamados módulos de sensoriamento seriam capazes de obter dados brutos de sensores físicos, e os módulos de dados das demais fontes (bases de dados e perfis do usuário). Estes módulos armazenam estes dados obtidos podendo fazer algum pré-processamento. Por fim, fornecem estes dados através de SPARQL endpoints na nuvem LOD. A segunda camada é a camada de inferência, que é composta por uma rede de módulos de inferência responsáveis por consumir informações de outros módulos desta mesma camada ou da camada de dados e sensoriamento e realizar inferência de contextos, ações e notificações. Estes módulos de inferência identificam três etapas: carregamento, processamento e publicação. A primeira obtém informações através de consultas SPARQL feitas a um ou mais endpoints. A segunda permite, no estágio atual, realiza inferências usando ontologias OWL e regras IF-THEN, para mapear conceitos de diferentes ontologias, descobrir contexto de mais alto nível e gerar recomendações de notificações ou ações a serem executadas por uma aplicação ou agente. A publicação é a disponibilização destes dados na nuvem LOD através de um SPARQL endpoint criado pelo módulo. A camada de aplicação 148 contém as aplicações que interagem diretamente com o usuário final. Estas aplicações consomem dados de um ou mais módulos de inferência por meio de seu(s) SPARQL endpoint(s). Estas camadas formam a estrutura inicial da arquitetura LOUD, mas devido à complexidade não foi possível desenvolver todo o projeto nesta dissertação. Desta forma, resolveu-se construir o Módulo de Inferência da camada de inferência, com o objetivo de tratar o problema da inexistência de um ferramental configurável, capaz realizar inferências, incluindo contexto, usando formatos de dados interoperáveis disponíveis na Web Semântica e também de disponibilizar seus dados seguindo tais princípios. O módulo de inferência possui quatro componentes: carregador de dados, base de armazenamento intermediário, motor de inferência e SPARQL endpoint. O carregador de dados é formado por uma ou mais threads de execução, uma para cada endpoint fonte, de forma que cada thread envia consultas (DESCRIBE ou CONSTRUCT) sequencialmente a seu endpoint, podendo existir variáveis cujos valores sejam provenientes de outras fontes (substituições de variáveis). Os resultados obtidos das consultas de cada endpoint i são armazenados em grafos GRC[i] separadamente, reunidos em um grafo GRC, processados pelo motor de inferência (gerando GINF) até chegar ao grafo para publicação (GPUB) que é disponibilizado atráves do endpoint do módulo. O motor de inferência é um raciocinador baseado em regras (JENA) ou OWL-DL (Pellet), sendo necessário escolher um deles. A atualização do endpoint pode ser feita por cópia ou compartilhamento do grafo usado pelo raciocinador, ambas possuem prós e contras que foram discutidos na seção 3.3.1.4 (pág. 77). Estes componentes são configuráveis através de um arquivo XML, de maneira que se pode definir endpoints fonte, consultas e seus intervalos de execução, substituições de variáveis, ontologias, regras, raciocinador e forma de atualização. 6.2 Estudo de viabilidade e experimentos realizados Para mostrar a viabilidade de se construir aplicações cientes de contexto utilizando o módulo foram idealizados e constrúidos três cenários. O primeiro cenário visava suprir uma necessidade de informação muito comum do Corpo de Bombeiros do Estado do Rio de Janeiro (CBMERJ) sobre disponibilidade de hidrantes de coluna próximos a um foco de incêndio. Para isso, a base de recursos hídricos do Sistema de Informações Geográficas Vigilância e Controle (ViconWeb) foi disponibilizada como um SPARQL endpoint, uma 149 ontologia OWL foi desenvolvida e um módulo que reunia estas informações com outras provenientes do endpoint do projeto LinkedGeoData foi configurado. O segundo cenário foi inspirado nas tragédias ocasionadas pelas chuvas de 2010 a 2012 no Rio de Janeiro que resultou na instalação de sirenes por parte do prefeito. Assim, o objetivo do cenário era gerar notificações sobre intensidade de chuva e probabilidade de escorregamento à população, com base na precipitação existente na localização simulada de cada usuário. Como fonte de dados foi criado um endpoint contendo medições pluviométricas das 33 estações do Sistema AlertaRio. Para cada suposto usuário eram geradas notificações usando regras do Alerta-Rio. O terceiro cenário também envolveu geração de notificações para usuários, mas focando em eventos sociais e chegadas de ônibus. Para prover os dados necessários foram construídos três endpoints: simulação da movimentação de ônibus (restritos à área geográfica da cidade universitária da UFRJ), rede social de usuários (alguns supostos alunos da UFRJ, seus parentes e amigos) e, bases de datas comemorativas e feriados. Quatro ontologias e diversas regras foram desenvolvidas e distribuídas em cinco módulos de inferência com atribuições específicas. Como resultado, usuários eram notificados sobre a proximidade de aniversários, feriados e chegadas de ônibus em paradas próximas à sua localização. Como a facilidade de configuração é um ponto crucial para a difusão do uso, foi realizado um experimento com alunos do Programa de Pós-Graduação em Informática (PPGI) a fim de recolher avaliações positivas e negativas. O terceiro cenário foi escolhido para que os alunos tentassem configurar a rede de módulos, contudo, como não seria possível que os alunos construíssem todas as consultas e regras, decidiu-se por removê-las dos arquivos de configuração e colocá-las em um arquivo de texto. Assim, as estrutura dos XMLs foi mantida e os alunos deveriam entender o módulo e o domínio e, por fim, completar os arquivos XML. Isto foi importante para mostrar e/ou confirmar diversos aspectos positivos e limitações que serão discutidos nas próximas seções. Apesar de este experimento ter mostrado que alunos com maior conhecimento em programação tiveram maior facilidade, acredita-se que isto se deva ao raciocínio algoritmico utilizado e não necessariamente ao conhecimento de linguagens de programação, visto que nenhuma linguagem de programação é usada ao configurar o módulo, apenas linguagens de marcação (XML), consulta (SPARQL) e representação de conhecimento (RDF e OWL). 150 6.3 Contribuições e aspectos positivos A principal contribuição deste trabalho é permitir o processamento de informações para aplicações cientes de contexto utilizando formatos e padrões abertos da Web Semântica. Trazer tais tecnologias para estas aplicações é importante, pois a computação ciente de contexto não está mais restrita a um ambiente fechado e a sensores locais. Usuários estão cada vez mais conectados à Internet, e as aplicações, portanto, devem prover informações e serviços condizentes com suas expectativas utilizando todos os benefícios da conectividade global. O framework foi concebido inicialmente para auxiliar a construção da parte inteligente de aplicações cientes de contexto, ou seja, inferência de contexto e geração de recomendações (notificações e/ou ações) usando as tecnologias da Web Semântica. Contudo, por usar estas tecnologias, acabou se tornando também útil para a construção de aplicações genéricas, agentes e mashups que necessitem de inferência com ontologias OWL e regras. Outro aspecto positivo é a habilidade de ser fazer inferência modularizada e distribuída na Web, ou seja, dividir o processamento de ontologias e regras em módulos distintos que podem executar em máquinas distintas para posterior integração. Isto permite reduzir o tempo total gasto tanto em processamentos que devem ser executados em série (que possuem alguma relação de dependência) quanto daqueles que podem ser paralelizados (dados sem relação direta). Isto pode ser visto na implementação dos cenários. No cenário 3, por exemplo, o módulo NEvt que gerava notificações sobre eventos precisava consultar as participações em eventos geradas por outros módulos (A1 e B3) que operavam paralelamente devido ao fato de os seus dados não possuírem dependência entre si. Apesar de esta ideia não ser inédita, a facilidade de configuração proporcionada pelo framework permite que pessoas sem grandes conhecimentos de linguagens programação possam configurar o módulo e disponibilizar seus dados na Web rapidamente. Isto se deve ao fato de se utilizar um arquivo XML para configuração, que possui apenas os elementos essenciais para serem configurados. Se não fosse o módulo, pessoas que quisessem produzir tais dados para aplicações precisariam criar programas para realizar as consultas, carregar ontologias e regras, processar os dados com um motor de inferência e depois fazer a inserção de dados em uma base de triplas. O framework reduz a necessidade de programação, mas obviamente não exclui a necessidade de conhecer os endpoints fonte, suas ontologias ou vocabulários, nem de construir consultas, ontologias e regras, ou seja, não substitui as 151 necessidades de conhecimento do domínio, levantamento de requisitos e modelagem como em qualquer desenvolvimento. Aspectos positivos apresentados por alguns alunos foram (1) simplificação de consultas para o consumidor final depois de configurado e executado, (2) execução e visualização simples e intuitivas, (3) reutilização de informações por parte de aplicações independente de suas plataformas, (4) facilidade de entendimento, configuração e alteração da configuração e (5) configuração bastante detalhada e flexível. Outras vantagens que podem ser comentadas são (6) possibilidade de se validar a base de dados gerada, ou seja, verificar a consistência com base numa ontologia predefinida e, (7) independência de platarforma (linguagem de programação e sistemas operacional), pois foi implementado em Java e utiliza as tecnologias XML, RDF e SPARQL do W3C. 6.4 Problemas e limitações Os problemas e limitações encontrados neste trabalho podem ser divididos naqueles inerentes à tecnologia, ou seja, não diretamente relacionados ao framework e os inerentes ao framework. Quanto ao primeiro, apesar da inúmera quantidade de bases publicadas seguindo o padrão, ainda há uma carência de bases com informações úteis, confíaveis e atualizadas, inclusive no âmbito nacional. Além disso, muitos endpoints aceitam apenas SPARQL 1.0, linguagem limitada que dificulta a execução de consultas mais complexas. Adicionalmente, o tempo de processamento ainda é um gargalo, pois aumenta rapidamente conforme a quantidade de instâncias aumenta (BOCK, JURGEN et al., 2008) e os raciocinadores variam significativamente quanto às funcionalidades, sendo necessária uma avaliação crítica dos requisitos antes de escolher um para uma aplicação (DENTLER et al., 2011). Outra observação importante é que ainda não foi estabelecida uma ferramenta realmente fácil e intuitiva para edição de OWL e regras, visto que apesar de o software Protégé ser útil e funcionar de forma satisfatória, ainda não é muito amigável. Não é difícil se confundir com suas telas durante a edição. Isto poderia ser melhorado com a adição de uma área de edição visual semelhante ao UML, mas no momento apenas a visualização pode ser feita visualmente. Por este motivo, neste trabalho as ontologias necessárias foram desenvolvidas em editores de texto convencionais usando o formato Turtle e com checagem de consistência pela ferramenta Pellet. Contudo, para pessoas que não tenham amplo 152 conhecimento de Turtle e OWL é inevitável o uso do Protégé, proporcionando alguma dificuldade na manipulação de ontologias, que se espera diminuir no curto ou médio prazo. Por fim, a tecnologia ainda é pouco difundida ao público em geral, mesmo os mais capacitados. Isto ficou evidenciado pelo fato de que diversos alunos de mestrado, já cursando a disciplina, tiveram dificuldade em compreender as tecnologias durante o experimento. Conhecimento de alguns princípios da lógica de descrição também é útil ao desenvolver ontologias OWL-DL, ou as ontologias construídas podem não ser consistentes e gerar resultados não satisfatórios ou errados, mas isso pode ser contornado com ferramentas de checagem, como Pellet. O Protégé permite validação usando este e outros motores de inferência. No tocante a problemas e limitações do framework, alguns itens foram verificados. O uso de base de armazenamento em memória pode limitar a capacidade de armazenamento, mas a possibilidade de armazenar dados em disco deveria ser bem estudada, pois poderia trazer problemas tanto pela menor velocidade de acesso quanto pela permissividade em armazenar mais instâncias. Outra limitação do módulo é realizar apenas processamento de ontologias OWL-DL e regras IF-THEN que, apesar de proporcionar formalidade lógica, dificulta o processamento de dados incertos (BETTINI et al., 2010). Fusão básica de dados pode ser obtida por meio de funções de agregação em consultas SPARQL, contudo isto é muito limitado sendo necessário incorporar outros mecanismos como sugerido na seção 3.2 e na próxima. No atual estágio, apenas carregadores síncronos estão disponíveis e isto, apesar de eficaz, pode reduzir a eficiência da atualização, pois não há garantias de que o atraso na atualização é o mínimo possível e também aumenta o tráfego de informções (quando não há atualização o carregador recebe infomação repetida). Resumidamente, é praticamente impossível determinar o instante de tempo correto para obter uma informação, sem que a fonte desta informação envie um evento ao receptor. A distribuição dos módulos na rede precisa ser feita manualmente sem um mecanismo que propricie maior facilidade em depurar o processo de configuração do módulo. Nesta linha, um dos alunos que fez o experimento relatou que a utilidade do módulo seria aumentada se houvesse uma interface gráfica para configurar o XML. Por fim, também houve um relato sobre as mensagens de erro do módulo não serem claras, e realmente, não houve preocupação em desenvolver esta linha de comunicação. 153 6.5 Trabalhos futuros Dentre possíveis trabalhos futuros pode-se mencionar carregadores síncronos, inclusão de outros raciocinadores e interface visual de configuração. As vantagens que podem ser proporcionadas por carregadores assíncronos foram discutidas na seção anterior. O trabalho de (PASSANT; MENDES, 2010) discute o método e apresenta uma ferramenta feita em PHP que funciona como um proxy que recebe consultas, as registra e gera feeds RSS ou Atom que são registrados em um hub e também enviados de volta ao cliente. Quando novas triplas são inseridas via SPARQL Update, este proxy gera triggers que executam as consultas registradas e atualizam o hub com novos feeds. Por fim, o hub envia os novos feeds aos clientes. A adição desta funcionalidade seria de grande utilidade, porém possíveis impactos ainda precisam ser levantados e estudados. Dentre os repositórios atuais, o Virtuoso já possui esta funcionalidade32. A inclusão de outros raciocinadores OWL-DL, até mesmo com reasoning incremental, e a adição de mecanismos que permitam determinar o raciocinador mais apropriado para a ontologia em questão também seria de bastante utilidade. Em (BOCK, JÜRGEN et al., 2012) é apresentado um trabalho para seleçao de raciocinadores baseado em técnicas de aprendizado de máquina como redes bayesianas e SVM (Support Vector Machine). Além disso, outras formas de processamento para fusão de dados e/ou clusterizacao poderiam ser adotadas desde os mais simples como scripts (programas Javascript ou Python, por exemplo) até outros mais sofisticados como Hidden Markov Models (HMM), lógica probabilística ou fuzzy, com as devidas adaptações para RDF (BETTINI et al., 2010). A implementação de módulos que permitam tais técnicas é muito importante, tanto na camada de inferência quanto na camada de sensoriamento, e um aperfeiçoamento deste tipo na arquitetura LOUD permitirá tirar proveito do melhor que cada técnica pode oferecer (BETTINI et al., 2010). Mecanismos automáticos que permitam distribuir inferência e armazenamento por várias máquinas também seriam de grande utilidade, pois permitiriam que o processamento se tornasse escalável na Web sem necessidade da configurção manual de vários módulos independentemente, como ocorre atualmente. Trabalhos apresentados por Jacopo Urbani (URBANI, J; OREN, E; et al., 2009; URBANI, JACOPO; KOTOULAS; et al., 2009) apresentam uma abordagem para inferência RDFS e OWL usando o algoritmo MapReduce. Para RDFS, a abordagem se mostrou bastante efetiva, eficiente e escalável, sendo capaz de 32 http://ods.openlinksw.com/wiki/ODS/VirtPubSubHub 154 processar um bilhão de triplas em menos de uma hora. Contudo, para inferência OWL, o autor relata que os resultados foram lentos e frágeis, sendo necessário desativar algumas regras para se concluir a execução. Um trabalho também usando MapReduce, mas voltado a SPARQL distribuído, é apresentado em (KULKARNI, 2010) e apresentou bons resultados quanto à escalabilidade de grandes volumes de dados, mas o tempo de resposta não foi aceitável pois ainda é necessário investimentos em indexação distribuída. A descrição dos serviços providos por um módulo permite que aplicações e agentes sejam capazes de se adaptar a novos ambientes tirando proveito de serviços disponíveis na localidade. A quantidade de funcionalidades que um serviço pode oferecer é imensa, como a consulta de informações regionais, execução de algoritmos, localização de hardwares como impressoras, serviços de fax, etc. (MIAN et al., 2009). Apesar da associação com a localidade, é importante que tais descrições de serviços estejam disponíveis na Web, pois o consumidor não necessariamente está na mesma rede local ou área do serviço buscado. Um bom exemplo seria o caso de uma aplicação apresentar ao usuário um planejamento de ações relacionadas a um evento futuro. Acredita-se, portanto, que agregar contribuições do campo da descoberta de serviços seja uma funcionalidade útil, mas devem-se levar em consideração possíveis necessidades de um consumidor distante do local do serviço. Um ambiente de desenvolvimento visual para construção dos módulos permitiria que novatos pudessem iniciar o desenvolvimento sem grande conhecimento inicial, pois este ambiente auxiliaria no processo de configuração, testes e depuração, e consequente aprendizado prático. A construção das ontologias, regras e consultas poderiam também ser integradas neste ambiente. A efetividade deste ambiente poderia ser comparada com o processo manual atual de configuração, teste e depuração, e também com o desenvolvimento de aplicações cientes de contexto usando desenvolvimento por programação, para se verificar pontos em que há ganhos reais, e pontos indiferentes ou negativos. 155 Referências ABITEBOUL, S. ; BENJELLOUN, O. ; MILO, T. The Active XML project: an overview. The VLDB Journal, New York, v. 17, n. 5, p. 1019-1040, 2007. ALLEN, J. F. Towards a general theory of action and time. Artificial Intelligence, Amsterdam, v. 23, n. 2, p. 123-154, Jul. 1984. ALMEIDA, A. ; LÓPEZ-DE-IPIÑA, D. ; AGUILERA, U. et al. An Approach to dynamic knowledge extension and semantic reasoning in highly-mutable environments. In: CORCHADO, J. ; TAPIA, D. ; BRAVO, J. (Eds.). 3rd Symposium of Ubiquitous Computing and Ambient Intelligence 2008. Berlin / Heidelberg: Springer, 2009. p. 265273. (Advances in Intelligent and Soft Computing, v. 51). ANTONIOU, G. ; HARMELEN, F. VAN. Web ontology language: OWL. In: STAAB, S. ; RUDI STUDER, D. (Eds.). Handbook on ontologies. Berlin / Heidelberg, Springer, 2009. p. 91-110. ARAUJO, R. B. Computação ubíqua : princípios, tecnologias e desafios. In: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES, 21., 2003., Natal. Mini Curso … Natal: UFRN/SBC, 2003, p. 45-115. AZEVEDO, G. F. Análise da relação chuva-escorregamento em regiões tropicais montanhosas urbanas, caso de estudo. 2011. 120 f. Dissertação (Mestrado em Geotecnia) – Universidade de Brasília, Brásilia, 2011. BAADER, F. et al. Description logics. In: VAN HARMELEN, F. ; LIFSCHITZ, V. ; PORTER, BRUCE (Eds.). Handbook of knowledge representation. 1. ed. [S.l.]: Elsevier, 2008. v. 1. p. 135-179. (Foundations of Artificial Intelligence) BAADER, F. ; NUTT, W. Basic description logics. In: BAADER, F. ; CALVANESE, D. et al. (Eds.). The description logic handbook: theory, implementation and applications. Cambridge: Cambridge University Press, 2003. p. 43-95. BALDAUF, M. ; DUSTDAR, S. ; ROSENBERG, F. A survey on context-aware systems. International Journal of Ad Hoc and Ubiquitous Computing, Geneva, v. 2, n. 4, p. 263– 277, 2007. BATSAKIS, S. ; PETRAKIS, E. G. M. SOWL: spatio-temporal representation, reasoning and querying over the semantic web. In: INTERNATIONAL CONFERENCE ON SEMANTIC SYSTEMS, 6., 2010, Graz, Austria. Proceedings … New York: ACM, 2010. . Disponível em: <http://doi.acm.org/10.1145/1839707.1839726> Acesso em: 2010 BECKER, C. ; NICKLAS, D. Where do spatial context-models end and where do ontologies start? a proposal of a combined approach. In: INTERNATIONAL WORKSHOP ON ADVANCED CONTEXT MODELLING, REASONING AND MANAGEMENT, 1., 2004. Nottingham, Eng. Proceedings … New York: ACM, 2004. 156 BERNERS-LEE, T. ; HENDLER, J. ; LASSILA, O. The semantic web. Scientific American, New York, v. 284, n. 5, p. 34–43, 2001. BETTINI, C. et al. A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing, New York, v. 6, n. 2, p. 161-180, Apr. 2010. BIEGEL, G. ; CAHILL, V. A framework for developing mobile, context-aware applications. In: IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS, 2., 2004. Orlando. Proceedings ... Los Alamitos: IEEE, 2004. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1276875>. Acesso em: 31 jul. 2011. BIZER, C. Linked data - the story so far. International Journal on Semantic Web and Information Systems, Hershey, PA, v. 4, n. 2, p. 1-22, 2009. BOCK, J. et al. Benchmarking OWL reasoners. In: INTERNATIONAL WORKSHOP ON ADVANCING REASONING ON THE WEB: Scalability and Commonsense, 2008. Tenerife. Proceedings … [S.l.]: CEUR, 2008 BOCK, J. ; LÖSCH, U. ; WANG, H. Automatic reasoner selection using machine learning. In: INTERNATIONAL CONFERENCE ON WEB INTELLIGENCE, MINING AND SEMANTICS, 2., 2012, Craiova, Romania. Proceedings … New York: ACM. 2012. Disponível em: <http://doi.acm.org/10.1145/2254129.2254159>.Acesso em junl. 2012 BRATMAN, M. E. Intention, plans, and practical reason. Stanford: Center for the Study of Language and Information, 1999. (David Hume Series) BRØNSTED, J. ; HANSEN, K. M. ; INGSTRUP, M. Service composition issues in pervasive computing. IEEE Pervasive Computing, New York, v. 9, n. 1, p. 62-70, Jan./Mar. 2010. CHEN, H. An intelligent broker architecture for pervasive context-aware systems. 2004.Tese (Doutorado) – University of Maryland, Baltmore County, Baltimore County, 2004. CHEN, H. ; FININ, T. ; JOSHI, A. semantic web in the context broker architecture. In: IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS, 2., 2004. Orlando. Proceedings ... Los Alamitos: IEEE, 2004. p. 277-286. ________. An ontology for context-aware pervasive computing environments. The Knowledge Engineering Review, Cambridge, Eng., v. 18, n. 3, p. 197-207, Sept. 2003. CHEN, H. et al. SOUPA: standard ontology for ubiquitous and pervasive applications. In: MOBIQUITOUS 2004 - ANNUAL INTERNATIONAL CONFERENCE ON MOBILE AND UBIQUITOUS SYSTEMS: NETWORKING AND SERVICES, 1., 2004, Boston. Proceedings … New Yok: ACM, 2004. p. 258-267. CLARK, K. G. ; FEIGENBAUM, L. ; TORRES, E. SPARQL Protocol for RDF. Disponível em: <http://www.w3.org/TR/rdf-sparql-protocol/>. Acesso em: 21 out. 2012. COMPTON, M. et al. A Survey of the semantic specification of sensors. networks, In: INTERNATIONAL WORKSHOP ON SEMANTIC SENSOR NETWORKS, 2., 2009, Washington, DC. Proceedings … [S. l.]: CEUR, 2009. v. 522. 157 CORDEIRO, K. F. ; FARIA, F. F. ; PEREIRA, B. O. et al. An approach for managing and semantically enriching the publication of linked open governmental data. In: WCGE 2011 WORKSHOP DE COMPUTAÇÃO APLICADA EM GOVERNO ELETRÔNICO, 3., 2011, . Florianópolis. Anais... Porto Alegre: SBC, 2011. Disponível em: <http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:An+approach+for+manag ing+and+semantically+enriching+the+publication+of+Linked+Open+Governmental+Data#0 >. Acesso em: 20 nov. 2011. DECKER, B. L. World geodetic system 1984. Fourth INTERNATIONAL GEODETIC SYMPOSIUM ON SATELLITE POSITIONING, 4., 1986 Austin, TX. Proceedings … Austin, TX: Defense Mapping Agency, 1986. DELLA VALLE, E. ; QASIM, M. H. ; CELINO, I. Towards treating GIS as virtual RDF graphs. 1st In: WebMGS 2010 - INTERNATIONAL WORKSHOP ON PERVASIVE WEB MAPPING GEOPROCESSING AND SERVICES, 1., 2009, Como, Italy. Proceedings … Como, Italy: ISPRS, 2009. Disponível em: <http://www.isprs.org/proceedings/XXXVIII/4W13/ID_36.pdf>. Acesso em: nov.2011. DENTLER, K. et al. Comparison of reasoners for large ontologies in the OWL 2 EL profile. Semantic Web – Interoperability, UsabilityApplicability an IOS Press Journal, [S. l.], v. 2, n. 2, p. 71-87, 2011. DEY, A. K. ; ABOWD, G. D. Towards a better understanding of context and contextawareness. In: GELLERSEN, H-W (Ed.). Handheld and Ubiquitous Computing, First International Symposium, HUC'99, Karlsruhe, Germany, 1999. Berlin: Springer, 1999. p. 304-307. (Lecture Notes in Computer Science, V. 1707). DEY, A. et al. ICAP Interactive prototyping of context-aware applications. In: FISHKIN, K. P. et al.(Eds). Pervasive Computing, 4th International Conference PERVASIVE, Dublin, Ireland, 2006. Berlin: Springer, 2006. p. 254-271. (Lecture Notes in Computer Science, v. 3968). DU, W. ; WANG, L. Context-aware application programming for mobile devices. In: C3S2E'08 - C3S2E CANADIAN CONFERENCE ON COMPUTER SCIENCE & SOFTWARE, 2008, Montreal QC, Proceedings … New York, ACM, 2008. p. 215-217. EITER, T. et al. A. Rules and ontologies for the semantic web. In: BAROGLIO, C. et al. (Eds.). Reasoning Web. 4 th International Summer School 2008. Venice ,Italy, 2008. Berlin: Springer, 2008. p. 1-53. (Lecture Notes in Computer Science, v. 5224). FAHY, P. ; CLARKE, S. CASS – a middleware for mobile cotext-aware applications. In: MobiSys - WORKSHOP ON CONTEXT AWARENESS MOBISYS, 2., 2004, Boston. Proceedings … New York: ACM, 2004. Disponível em: <http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:CASS++Middleware+for+Mobile+Context-Aware+Applications#0>. Acesso em: 22 jan. 2011. FORGY, C. L. Rete: A fast algorithm for the many pattern/many object pattern match problem. Artificial Intelligence, Amsterdam, v. 19, n. 1, p. 17-37, 1982. GESSLER, D. D. et al. A Simple semantic web architecture and protocol for semantic web services. BMC Bioinformatics, London, v. 10, n. 1, p. 309, Sept. 2009. 158 GOLBREICH, C. ; WALLACE, E. K. OWL 2 web ontology language: new features and rationale. Disponível em: <http://www.w3.org/TR/owl-new-features/>. Acesso em: 20 out. 2012. GONG, S. et al. Design and Implementation of a low-power ZigBee wireless temperature humidity sensor network. In: LI, D. ; LIU, Y.; CHEN, Y. (Eds.). Computer and computing technologies in agriculture IV. 4Th IFIC TC Conference, CCTA 2010, Nanchang, China, 2010. Selected Papers, part IV. Berlin: Springer, 2011. p. 616-622. (IFIP Advances in Information and Communications Technology, v. 347). GROSOF, B. N. et al. Description logic programs: combining logic programs with description logic. In: WWW'03 - Proceedings of the 12th INTERNATIONAL CONFERENCE ON WORLD WIDE WEB, 12., 2003. Budapest. Proceedings … New York: ACM, 2003. p. 4857. Disponível em: <http://doi.acm.org/10.1145/775152.775160>. Aceso em jan. 2011. GU, T. ; PUNG, H. ; ZHANG, D. A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, London, v. 28, n. 1, p. 1-18, Jan 2005. GUIZZARDI, G. ; WAGNER, G. Using the Unified Foundational Ontology (UFO) as a Foundation for General Conceptual Modeling Languages. In: POLI, R. ; HEALY, M. ; KAMEAS, A. (Eds.). Theory and applications of ontology: computer applications. Dordrecht: Springer, 2010. p. 175-196. GUO, B.; ZHANG, D. ; IMAI, M. Toward a cooperative programming framework for context-aware applications. Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 221-233, Mar. 2011. HAASE, P. ; MATHÄS, T. ; ZILLER, M. An evaluation of approaches to federated query processing over linked data. INTERNATIONAL CONFERENCE ON SEMANTIC SYSTEMS, 6., 2010, Graz, Austria. Proceedings ... New York: ACM. 2010. Disponível em: <http://doi.acm.org/10.1145/1839707.1839713>. Acesso em: jan. 2011. HAAV, H.-M. et al. Ontology-based retrieval of spatially related objects for location based services. In: MEERSMAN, R. ; DILLON, T. ; HERRERO, P. (Eds.). On the move to meaningful internet systems: OTM 2009. Berlin: Springer, 2009. p. 1010-1024. (Lecture Notes in Computer Science, v. 5871). HALPIN, T. A. Information modeling and relational databases. San Francisco: Morgan Kaufmarm, 2001. HENRICKSEN, K. A framework for context-aware pervasive computing applications. 2003. PhD.Tesis -- University of Queensland, Brisbane, Australia, 2003. HENRICKSEN, K. ; LIVINGSTONE, S. ; INDULSKA, J. Towards a hybrid approach to context modelling, reasoning and interoperation. In: INTERNATIONAL WORKSHOP ON ADVANCED CONTEXT MODELLING, REASONING AND MANAGEMENT, 1., 2004. Nottingham, Eng. Proceedings … New York: ACM, 2004. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.70.2735&rep=rep1&typ e=pdf>. Acesso em: 21 ago. 2011. 159 HENRICKSEN, K ; INDULSKA, J. Modelling and using imperfect context information. In: IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS WORKSHOPS, 2., 2004, Orlando. Proceedings … Los Alamitos: IEEE, 2004 HENRICKSEN, K ; INDULSKA, J. Developing context-aware pervasive computing applications: models and approach. Pervasive and Mobile Computing, New York, v. 2, n. 1, p. 37-64, 2006. HERVÁS, R. ; BRAVO, J. COIVA: context-aware and ontology-powered information visualization architecture. Software: Practice and Experience, London, v. 41, n. 4, p. 403426, Apr. 2011. HIGHTOWER, J. ; BORRIELLO, G. Location systems for ubiquitous computing. Computer, Long Beach, v. 34, n. 8, p. 57-66, Aug. 2001. HOFER, T. ; SCHWINGER, W. ; PICHLER, M. et al. Context-awareness on mobile devices - the hydrogen approach. In: HICSS'03 – ANNUAL HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 36., 2003, Big Island. Proceedings … . Washington, DC: IEEE Computer Society. 2003. Track 9, v. 9. p. 292.1. Disponível em: <http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2003.1174831>. Acesso em: 2011. HORROCKS, I. ; KUTZ, O. ; SATTLER, U. The even more irresistible SROIQ. In: KR-2006 - INTERNATIONAL CONFERENCE ON PRINCIPLES OF KNOWLEDGE REPRESENTATION AND REASONING, 10., 2006, Lake District of the UK. Proceedings … Palo Alto, CA: AAAI Press, 2006. HORROCKS, I ; SATTLER, U. Ontology reasoning in the SHOQ (D) description logic. In: IJCAI 2001 - INTERNATIONAL JOINT CONFERENCE ON ARTIFICIAL INTELLIGENCE, 17., 2001, Seattle. Proceedings … San Francisco: Morgan Kaufmann, 2001. HORROCKS, I. ; PATEL-SCHNEIDER, P. F. A proposal for an owl rules language. In: INTERNATIONAL CONFERENCE ON WORLD WIDE WEB. 13., 2004, New Yok. Proceedings … Anais... New York: ACM, 2004. Disponível em: <http://doi.acm.org/10.1145/988672.988771>. Acesso em: jan. 2011. HORROCKS, I. ; PATEL-SCHNEIDER, P. F. ; HARMELEN, F. V. From SHIQ and RDF to OWL: the making of a web ontology language. Web Semantics: Science, Services and Agents on the World Wide Web, [S. l.], v. 1, n. 1, p. 7-26, 2003. HU, D. H. ; DONG, F. ; WANG, C.-L. A Semantic context management framework on mobile device.In: ICESS'09 - INTERNATIONAL CONFERENCE ON EMBEDDED SOFTWARE AND SYSTEMS, 6., 2009, Hangzhou, China. Proceedings... Los Alamitos: IEEE, 2009. p. 331-338, 2009. INDULSKA, J. ; SUTTON, P. Location management in pervasive systems. In: Proceedings of AUSTRALASIAN INFORMATION SECURITY WORKSHOP CONFERENCE ON ACSW FRONTIERS, 2003, Adelaide. Proceedings … Darlinghurst: Australian Computer Science, 2003. p. 143-141. Disponível em: <http://dl.acm.org/citation.cfm?id=827987.828003>. Acesso em: 2 jan. 2012. 160 JAIN, P. et al. Linked data is merely more data. In: AAAI SPRINGER SYMPOSIUM: LINKED DATA MEETS ARTIFICIAL, 2010, Stanford. Proceedings … Palo Alto, CA: AAAI Press, 2010. p. 82-86. JIANG, C.; STEENKISTE, P. A Hybrid Location Model with a Computable Location Identifier for Ubiquitous Computing. In: BORRIELLO, GAETANO; HOLMQUIST, L. (Eds.). UbiComp 2002: Ubiquitous Computing. [S.l.]: Springer Berlin / Heidelberg, 2002. v. 2498p. 307-313. KOLOVSKI, V. ; PARSIA, B. ; SIRIN, E. Extending the SHOIQ (D) tableaux with DL-safe rules: first r esults. In: DL 2006 - INTERNATIONAL WORKSHOP ON DESCRIPTION LOGICS , 2006, Lake District of the UK. Proceedings … Lake District of the UK: CEUR, 2006. (CEUR Workshop Proceedings, v. 189). KORPIPAA, P. et al. Managing context information in mobile devices. IEEE Pervasive Computing, New York, v. 2, n. 3, p. 42-51, Jul 2003. KOUTSOMITROPOULOS, D. et al. Developing distributed reasoning-based applications for the semantic web. In: IEEE INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION NETWORKING AND APPLICATIONS WORKSHOPS, 24., 2010, Perth, Australian. Proceedings … Los Alamitos: IEEE, 2010. p. 593-598. KRISNADHI, A. ; MAIER, F. ; HITZLER, P. OWL and rules. reasoning web. semantic technologies for the web of data. In: POLLERSES, A. et al. (Eds.). Reasoning web. Semantic technologies for the web data. 7Th International Summer School 2011. Galway, Ireland.Tutorial Lectures, Heidelberg: Springer, 2011. p. 382-415, 2011. KULKARNI, P. Distributed SPARQL query engine using MapReduce. 2010. Thesis (Master of Science Computer Science). School of Informatics University of Edinburgh, Edinburgh. 2010. LANGEGGER, A. Virtual data integration on the web: novel methods for accessing heterogeneous and distributed data with rich semantics. In: INTERNATIONAL CONFERENCE ON INFORMATION INTEGRATION AND WEB-BASED APPLICATIONS & SERVICES, 10., 2008. Linz, Austria. Proceedings … New York: ACM, 2008. Disponível em: <http://doi.acm.org/10.1145/1497308.1497410>. , 2008 LANGEGGER, A. ; WÖS, W. ; BLÖCHL, M. A Semantic web middleware for virtual data integration on the web. In: BECHHOFER, S. et al. (Eds.) The semantic web research and applications 5th European semantic web conference Tenerife. 2008. Berlin: Springer, 2008. p. 493-507. (Lecture Notes in Computer Science, v. 5021). LE-PHUOC, D. ; QUOC, H. ; PARREIRA, J. The linked sensor middleware — Connecting the real world and the Semantic Web. In: ISWC 2011 – INTERNATIONAL SEMANTIC WEB CONFERENCE, 2011, Bonn. Proceedings … Berlin: Elsevier, 2011. LEE, D. ; MEIER, R. A hybrid approach to context modelling in large-scale pervasive computing environments. In: INTERNATIONAL ICST CONFERENCE ON COMMUNICATION SYSTEM SOFTWARE AND MIDDLEWARE, 4., 2009, Dublin. Proceedings ... Anais... New York, ACM, 2009. Disponível em: <http://doi.acm.org/10.1145/1621890.1621909>. Acesso em: 2011. 161 LENAT, D. B. CYC: a large-scale investment in knowledge infrastructure. Communications of the. ACM, v. 38, n. 11, p. 33-38, Nov. 1995. LEONHARDI, A. et al. Virtual information towers-a metaphor for intuitive, location-aware information access in a mobile environment. Wearable Computers. In: INTERNATIONAL SYMPOSIUM ON. WEARABLE COMPUTERS, 3., 1999, San Francisco, CA. Digest of Papers ... Los Alamitos: IEEE, 1999 LIANG, S. et al. OpenRuleBench : an analysis of the performance of rule engines. In: WWW'09 - 2009. INTERNATIONAL CONFERENCE ON WORLD WIDE WEB,18., 2009, Madrid. Proceedings … New York: ACM, 2009. p. 601-610. LU, J. ; WANG, C. ; HWANG, R. Open framework for distributed context management in ubiquitous environments. International Journal of Ad Hoc and Ubiquitous Computing, Geneve, v. 9, n. 4, p. 199-210, 2012. LYYTTINEN, K. ; YOO, Y. Issues and challenges in ubiquitous computing (special section). Communication of the ACM, New York, v. 45, n. 12, p. 63–65, 67-96, Dec. 2002. MATTILA, J. ; VÄÄTÄNEN, A. UbiPlay: an interactive playground and visual programming tools for children. In: INTERNATIONAL CONFERENCE ON INTERACTION DESIGN AND CHILDREN, 5., 2006, Tampere. Proceedings … New York, ACM, 2006 MCGUINNESS, D. L. ; HARMELEN, F.V. OWL web ontology language overview. Disponível em: <http://www.w3.org/TR/owl-features/>. Acesso em: 20 out. 2012. MIAN, A. N. ; BALDONI, R. ; BERALDI, R. A Survey of service discovery protocols in multihop mobile ad Hoc networks. IEEE Pervasive Computing, New York, v. 8, n. 1, p. 6674, 2009. MONTEMAYOR, J. et al. Tools for children to create physical interactive storyrooms. CIE Computers in Entertainment, New York, v. 2, n. 1, p. 12, 2004. MOTIK, B. et al. OWL 2 web ontology language: direct semantics. 2012. (W3C Recommendation). Disponível em: <http://www.w3.org/TR/owl-direct-semantics/>. Acesso em: 20 out. 2012. MOTIK, B. et al. Query answering for OWL-DL with rules. Web Semantics: Science, Services and Agents on the World Wide Web, [S. l.], v. 3, n. 1, p. 41-60, 2005. NARDI, D. ; BRACHMAN, R. J. An introduction to description logics. In: BAADER, F. et al. (Eds.). The description logic handbook: theory, implementation and applications. Cambridge: Cambridge University Press, 2003. p. 1-40. NAUDET, Y. Reconciling context , observations and sensors in ontologies for pervasive computing. In: SMAP'11 – INTERNATIONAL WORKSHOP ON SEMANTIC MEDIA ADAPTATION AND PERSONALIZATION, 6., 2011, Vigo, Spain. Proceedings... Washington, DC: IEEE, 2011. NEUHAUS, H. ; COMPTON, M. The semantic sensor network ontology : a generic language to describe sensor assets. AGILE 2009 – PRE-CONFERENCEWORKSHOP CHALLENGES IN GEOSPATIAL DATA HARMONISATION, 2009. Havover. Proceedings … Hanover: ESDI, 2009. 162 OMITOLA, T. et al. Integrating public datasets using linked data: challenges and design principles. In: FUTURE INTERNET ASSEMBLY, Ghent, Belgium Proceedings … Ghent, Belgium: European Future Internet Portal, 2010. Disponível em: <http://eprints.soton.ac.uk/271955/>.Acesso em: 2012. PAN, F. ; HOBBS, J. R. Time in OWL-S. 2003. Disponível em: citeseerx.ist.psu.edu/.../download... Acesso em: 2012. PASSANT, A. ; MENDES, P. N. sparqlPuSH: proactive notification of data updates in RDF stores using PubSubHubbub. In: SCRIPTING FOR THE SEMANTIC WEB WORKSHOP SFSW2010 AT ESWC2010, 6., 2010, Crete Greece. Proceedings … [S. l.]: CEUR, 2010. Disponível em: <http://www.semanticscripting.org/SFSW2010/papers/sfsw2010_submission_6.pdf>.Acesso em: 2012. PATNI, H. ; HENSON, C. ; SHETH, A. Linked sensor data. In: 2010 INTERNATIONAL SYMPOSIUM ON COLLABORATIVE TECHNOLOGIES AND SYSTEMS, 2010, Chicago. Proceedings … Los Alamitos: IEEE. 2010. p. 362-370. Disponível em: <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5478492>. Acesso em: 22 mar. 2012. PERTTUNEN, M. ; RIEKKI, J. ; LASSILA, O. Context representation and reasoning in pervasive computing: a review. International Journal of Multimedia and Ubiquitous Engineering, [S. l.], v. 4, n. 4, p. 1-28, 2009. POSLAD, S. Ubiquitous computing: smart devices, environments and interactions. Chichester: John Wiley and Sons, 2009. 502p. RANDELL, D. A. ; CUI, Z. ; COHN, A. G. A spatial logic based on regions and connection. In: INTERNATIONAL CONFERENCE ON KNOWLEDGE REPRESENTATION AND REASONING, 3;, 1992. Proceedings … San Francisco: Morgan Kaufmann, 1992. RAO, A. S. ; GEORGEFF, M. P. Modeling rational agents within a BDI architecture. In: INTERNATIONAL CONFERENCE ON PRINCIPLES OF KNOWLEDGE REPRESENTATION AND REASONING, 2., 1991, [S. l]. Proceedings … San Mateo: Morgan Kaufmann Publishers, 1991. Disponível em: <http://jmvidal.cse.sc.edu/library/rao91a.pdf>.Acesso em: 2012. RIBONI, D. ; BETTINI, C. COSAR: hybrid reasoning for context-aware activity recognition. Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 271-289, 2011a. ________. OWL 2 modeling and reasoning with complex human activities. Pervasive and Mobile Computing, New York, v. 7, n. 3, p. 379-395, 1 jun 2011b. RICCI, F. Mobile recommender systems. Information Technology & Tourism, Putnam Valley, NY, v. 12, n. 3, p. 205-231, 1 Apr. 2011. ROUSSAKI, I. Et al. Hybrid context modeling: a location-based scheme using ontologies. In: PerCom 2006 Workshops – ANNUAL IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS WORKSHOPS, 4., Pisa. Proceedings … Los Alamitos: IEEE, 2006. RUSSELL, S. ; NORVIG, P. Artificial intelligence: a modern approach. Upper Saddler River: Prentice Hall, 1995. 932 p. 163 RYAN, N. S. ; PASCOE, J. ; MORSE, D. R. Enhanced reality fieldwork: the context-aware archaeological assistant. In: DINGWALL, l. et al. (Eds.). Archaeology in the Age of the internet. CAAA97 - Computer applications and quantitative methods in archaeology. Oxford: Archaeopress, 1999. (BAR International Series, 750.). Disponível em: <http://www.cs.kent.ac.uk/pubs/1998/616> Acesso em: 2012. SCHILIT, B. ; ADAMS, N. ; WANT, R. Context-aware computing applications. In: WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS, 1., 1994. Santa Cruz, CA. Proceedings … Los Alamitos: IEEE, 1994. p. 85-90. SCHULZE, C. J. Plano nacional sobre governo aberto. Disponível em: <http://jus.com.br/revista/texto/20268>. Acesso em: 10 abr. 2012. SEQUEDA, J. F. ; CORCHO, Ó. Linked stream data: a position paper. . Madri: Facultad de Informática – UPM, 2009. Disponível em: <http://oa.upm.es/5442/1/INVE_MEM_2009_64353.pdf>. Acesso em: 21 mar. 2012. SILVA, M. A. Aplicação de lógica nebulosa para previsão do risco de escorregamentos de taludes em solo residual. 2008. 150 f. Dissertação (Mestrado em Engenharia Civil) – Programa de Pós-Graduação em Engenharia Civil, Universidade do Estado do Rio de Janeiro Rio de Janeiro, 2008. SINGH, S.; KARWAYUN, R. A Comparative study of inference engines. In: ITNG - 2010 International Conference on Information Technology: New Generations, 7., 2010, Las Vegas. Proceedings … Los Alamitos: IEEE, 2010. p. 53-57. SIRIN, E. Pellet : a practical OWL-DL reasoner. World Wide Web Internet And Web Information Systems, [S. l.], v. 5, n.2, p. 51-53, Jun. 2007. STEVENSON, G. et al. Ontonym: a collection of upper ontologies for developing pervasive systems. In: CIAO'09 – WORKSHOP ON CONTEXT, INFORMATION AND ONTOLOGIES, 1., 2009, Heraklion Greece. Proceedings … New York: ACM, 2009. Article n. 9. STRANG, T. ; LINNHOFF-POPIEN, C. A context modeling survey. In: INTERNATIONAL WORKSHOP ON ADVANCED CONTEXT MODELLING REASONING AND MANAGEMENT AS PART OF UBICOMP,1., 2004, Nottigham, Eng. Proceedings … New York: ACM, 2004.[S.l.]: Citeseer. Disponível em: <http://www.mendeley.com/research/acontext-modeling-survey/>. Acesso em: 29 nov. 2011. STRANG, T. ; LINNHOFF-POPIEN, C. ; FRANK, K. CoOL: a context ontology language to enable contextual interoperability.In: STEFANI, J-B. ; DEMEURE, I. ; HAGIMONT, D. (Eds.). Distributed applications and interoperaable systems. .4 th IFIP WG 6.1 International Conference DAIS. Paris, France 2010. Proceedings. Berlin: Springer Verlag, 2003. (Lecture Notes in Computer Science, 2893). STRIMPAKOU, M. A. ; ROUSSAKI, I. G. ; ANAGNOSTOU, M. E. A Context ontology for pervasive service provision. In: AINA - INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION NETWORKING IN APLLICATIONS, 20., 2006, Viena. Proceedings … Los Alamitos: IEEE, 2006. V. 2. SZEWCZYK, R. et al. Habitat monitoring with sensor networks. Communications of the ACM, New York, v. 47, n. 6, p. 34–40, Jun 2004. 164 TANG, L. et al. Supporting rapid design and evaluation of pervasive applications: challenges and solutions. Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 253-269, Aug. 2011. URBANI, J. RDFS/OWL reasoning using the MapReduce framework. 2009. Master thesis, Dept. of Computer Science, Faculty of Sciences, Vrije Universiteit, Amsterdam, 2009. URBANI, J. et al. Scalable distributed reasoning using MapReduce. In: BERSTEIN, A. et al. (Eds.). The semantic web – ISWC 2009. 8 th International Semantic Web Conference, ISWC 2009, Chantily, VA, 2009 Proceedings. Berlin: Springer-Verlag, 2009. (Lecture Notes in Computer Science, v. 5823). Disponível em: <http://dx.doi.org/10.1007/978-3-642-049309_40>. Acesso em: 2011 VIDAL, V. Et al. An ontology-based framework for geographic data integration. In: HEUSER, C. A. ; PERNUL, G. (Eds.). Advances in c onceptual modeling hallenging perspectives. ER 2009 Workshop CoMoL, EttheCoM, FP-UML, MOST-ONISW, QoIS, RIGiM, SeCoGIS. Gramado Brasil, 2009, Proceedings. Berlin: Springer: 2009. (Lecture Notes in Computer Science, v. 5833. p. 337-346. WANG, X. H. et al. Ontology based context modeling and reasoning using OWL. In: IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTINGAND COMMUNICATIONS WORKSHOPS, 2., 2004, Orlando. Proceedings … los Alamitos: IEEE, 2004. p.18-22. Disponível em: <http://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=1276898>. Acesso em: 2011. WANG, X. et al. Semantic space: an infrastructure for smart spaces. IEEE Pervasive Computing, New York, v. 3, n. 3, p. 32-39, Jul./Sept. 2004. WEISER, M. The computer for the 21st century. Scientific American, New York, v. 265, n. 3, p. 94–104, 1991. WINKELS, R. ; HOEKSTRA, R. ; HUPKES, E. Normative reasoning with geo information. In: COMGeo 10 - INTERNATIONAL CONFERENCE AND EXHIBITION ON COMPUTING FOR GEOSPATIAL RESEARCH & APPLICATIONS, 1., 2010, San Jose, CA. Proceedings … New York: ACM, 2010. Article 16. Disponível em: <http://doi.acm.org/10.1145/1823854.1823874>. Acesso em: 2011. YE, J. et al. A unified semantics space model. In: HIGHTOWER, J. : SCHIELE, B. ; STRANG, T. (Eds.). Location-and context-awareness, Third International Symposium LoCA 2007, Oberpfaffenhofen, Germany, 2007 Proceedings. Berlin:Springer, 2007. p. 103120. (Lecture Notes in Computer Science, v. 4718). YU, Z. et al. Theme issue on context-aware middleware and applications. Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 219-220, Aug. 2010. 165 Apêndices Apêndice A – Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE) O mapeamento usando D2R é realizado através de um arquivo de mapeamento, cujo formato é definido pela própria plataforma D2RQ. A listagem a seguir apresenta alguns trechos deste arquivo usando a sintaxe Turtle. Basicamente é necessário definir as configurações do servidor D2R (linhas 1-6), da conexão com o banco de dados (linhas 8-13) e os mapeamentos de classes e propriedades (demais linhas). 1 2 3 4 5 6 7 8 9 10 11 # Configuração básica do servidor <> a d2r:Server; rdfs:label "Alerta Rio" ; d2r:baseURI <http://alertario.rio.rj.gov.br:2020/> ; d2r:port 2020 ; (...) # Configuração da conexao com o banco de dados map:database a d2rq:Database; d2rq:jdbcDriver "com.mysql.jdbc.Driver"; d2rq:jdbcDSN "jdbc:mysql://db.alertario.rio.rj.gov.br /rain_sensors"; 12 d2rq:username "alertario"; 13 (...) 14 15 # Table station 16 map:station a d2rq:ClassMap; 17 d2rq:dataStorage map:database; 18 d2rq:class a:Station; 19 d2rq:uriPattern "Station/@@station.id@@". 20 21 map:station_name a d2rq:PropertyBridge; 22 d2rq:belongsToClassMap map:station; 23 d2rq:property a:stationName; 24 d2rq:column "station.name". 25 26 map:station_lat a d2rq:PropertyBridge; 27 d2rq:belongsToClassMap map:station; 28 d2rq:property a:latitude; 29 d2rq:column "station.latitude"; 30 d2rq:datatype xsd:decimal . 31 (...) 32 33 # Table measure 166 34 35 36 37 38 39 40 41 42 43 44 45 46 map:measure a d2rq:ClassMap ; d2rq:dataStorage map:database ; d2rq:class a:Measure ; d2rq:uriPattern "Measure/@@measure_view.id@@" . # map:measure_date e map:measure_value omitidos ... # Mapeamento object property (measure -> station) map:measure_station a d2rq:PropertyBridge; d2rq:belongsToClassMap map:measure; d2rq:property a:station; d2rq:refersToClassMap map:station; d2rq:join "measure_view.station_id => station.id" . Na configuração do servidor pode-se definir a porta de escuta do servidor (no caso 2020) e o URI base a ser utilizado ao construir o URI das instâncias (registro) das classes (tabelas). Para a conexão configura-se driver, endereço de acesso ao banco de dados, login e senha. Os mapeamentos podem ser de dois tipos: d2rq:ClassMap e d2rq:PropertyBridge. O primeiro mapeia uma tabela com um conceito, neste caso, station com a:Station (linhas 1519) e measure com a:Measure (linhas 33-37). O segundo mapeia atributos das tabelas com propriedades (p.ex. station.latitude com a:latitude, apresentado nas linhas 26-31). O URI de cada instância das classes é definido pela propriedade d2rq:uriPattern, que permite a definição do padrão de formação, usando atributos da tabela do banco, a ser adicionado ao URI base. Na linha 19 é apresentado um uso desta propriedade. Neste caso, a estação 15 seria identificada por <http://alertario.rio.rj.gov.br:2020/resource/Station/15>. Adicionalmente, o tipo de dados diferentes de xsd:string para as propriedades podem ser definido conforme apresentado na linha 30. Por fim, para não estender desnecessariamente, vale destacar as linhas 41 a 46 que apresentam o mapeamento de uma object property relacionando uma medição com a estação que a mediu. Observe a propriedade d2rq:join que permite relacionar os atributos station_id e id das tabelas measure_view e station. Por falar nisso, measure_view não é uma tabela, mas sim uma visão da tabela measure que seleciona apenas uma janela com as medidas mais recentes e é atualiza a cada 5 segundos por um programa Java que é executado paralelamente ao D2R. A janela adotada foi de quatro dias para englobar a necessidade de se ter 96 horas de medição, equivalente a quatro dias. Isto foi feito apenas por questões de desempenho, evitando que consultas equivocadas, do tipo “recupere todas a medidas”, demorassem muito tempo para serem respondidas. E isto realmente demoraria bastante em função de a tabela measure conter mais de 15 milhões de registros, uma vez que os dados históricos compreendem os anos de 1997 a 2011. 167 Apêndice B – Cenário 2: implementação da geração de coordenadas e mapeamento D2R para User Locations Endpoint (ULE) Conforme apresentado na seção 4.2.2.2, este endpoint simula a obtenção das coordenadas de usuário de um GPS produzidas de duas maneiras: arquivos KML gerados pelo Google Maps (dois cenários) e gerador automático de coordenadas e rotas. As informações são armazenadas em um banco de dados MySQL e o software D2R efetua o mapeamento. Adiante o diagrama do banco de dados, o vocabulário RDF e o mapeamento entre eles serão sucintamente apresentados. Em seguida a estrutura do KML exportado pelo Google Maps e os algoritmos de geração das coordenadas serão discutidos com mais detalhes. O diagrama entidade-relacionamento é composto apenas pelas tabelas user e location (Figura 20 na página 108). A primeira possui um atributo identificador e o nome do usuário e, a segunda, contém um atributo identificador, as coordenadas geográficas e o horário de atualização. As tabelas possuem uma relação 1:1 porque a primeira é armazenada em disco contendo 150.000 usuários com nomes gerados automaticamente e, a segunda, é armazenada em memória contendo os dados de localização que são sempre gerados dinamicamente e descartadas após a execução. A Figura 20 apresenta ainda o vocabulário RDF, com os conceitos usr:Usuario e usr:Ponto, e o mapeamento através de uma linha tracejada. O arquivo de mapeamento é similar ao apresentado no Apêndice A e será omitido. Vale ressaltar, contudo, que o URI das instâncias é gerado pela concatenação de http://users.com.br:2026/resource/ com o nome do conceito e seu identificador na tabela. A construção dos dois cenários de movimentação de usuário começam por uma pequena história da atividade do usuário, apresentados textualmente a seguir: Cenário 1: “João de Deus mora na Cidade de Deus e trabalha como segurança em uma casa noturna na Lapa de terça a sábado. Ele sai de casa às 18h30 para chegar no trabalho por volta de 20h. Às 5h ele deixa o serviço e retorna para casa, chegando aproximadamente às 6h. Tanto na ida quanto na volta ele pode pegar dois caminhos dependendo do ônibus que passar primeiro: via Linha Amarela ou via Zona Sul. Contudo, 75% da vezes ele vai pela Linha Amarela”. Cenário 2: “Dona Maria mora na Rocinha e trabalha numa casa no Leblon de segunda a sexta das 7h às 13h. Ao sair, ela vai diretamente para o Andaraí às segundas e quartas onde ela faz curso de culinária das 14h30 às 15h30. Ela então vai para o Centro onde estuda Administração até 22h, quando então retorna para casa”. 168 A partir disto, foram geradas rotas usando o Google Maps. O processo foi realizado manualmente na página do serviço, ou seja, marcou-se o ponto inicial e final e exportou-se a rota para o formato KML. Assim, por exemplo, o trecho do cenário descrito por “Dona Maria mora na Rocinha e trabalha (...) no Leblon (...). Ao sair, ela vai diretamente para o Andaraí (...)” é convertido em duas rotas, uma Rocinha-Leblon e outra Leblon-Andaraí. Para descrever os dias e horários destas rotas foi feita uma extensão na estrutura base do KML. O formato KML33 é um arquivo XML, descrito basicamente pelos elementos kml, Placemark, ExtendedData e alguns outros que representam entidades geométricas. Um exemplo é apresentado a seguir: 1 <kml xmlns="http://www.opengis.net/kml/2.2"> 2 <Placemark id=”id_marcador”> 3 <name>Absolute Extruded</name> 4 <description>Transparent green wall...</description> 5 <LineString> 6 <coordinates> 7 -112.2550785337791,36.07954952145647,2357 8 -112.2549277039738,36.08117083492122,2357 9 ... 10 </coordinates> 11 </LineString> 12 </Placemark> 13 </kml> O element kml é o elemento raiz que pode ter um ou mais elementos Placemark (linha 2), usados para marcar uma posição na superfície da Terra. Tais marcadores podem conter um atributo identificador e os elementos name, description e uma geometria. A geometria é um nome genérico concretizado pelos elementos Point (ponto geográfico), LineString (segmentos de reta conectados), LinearRing (caminho fechado), Polygon (polígono que pode conter buracos) e alguns outros. Os três primeiros possuem, obrigatoriamente, um elemento coordinates que contém uma (para pontos) ou mais (para os demais) tuplas de dois ou três valores (latitude, longitude e, opcionalmente, altitude). As linhas 5 a 11 mostram a estrutura para um LineString. No caso de polígonos, há um elemento outerBoundaryIs contendo a borda externa do polígono e zero ou mais elementos innerBoundaryIs contendo os buracos. Ambos são definidos por um LinearRing. Adicionalmente, podem-se definir estilos para os marcadores e/ou organizá-los em diretórios (Folder) e documentos (Document). 33 Conteúdo para a explicação extraído de https://developers.google.com/kml/documentation/kmlreference 169 O elemento ExtendData permite adicionar dados personalizados a um recurso (Placemark, Folder ou Document). Assim, criou-se uma estrutura própria para definir um cenário com agendas e caminhos. Esta estrutura é apresentada a seguir: 1 <ExtendedData xmlns:a="http://user.com.br"> 2 <a:scenario> 3 <a:username>Joao de Deus</a:username> 4 <a:schedule> 5 <a:trigger> 6 <a:time>18:30:00+00:00</a:time> 7 <a:weekly> 8 TUESDAY 9 WEDNESDAY 10 ... 11 </a:weekly> 12 </a:trigger> 13 <a:path ref="amarela"> 14 <a:probability>0.7500</a:probability> 15 <a:velocity>40.0</a:velocity> 16 <a:way>FORWARD</a:way> <!-- backward --> 17 </a:path> 18 <a:path ref="zona_sul"> 19 <a:probability>0.2500</a:probability> 20 ... 21 </a:path> 22 </a:schedule> 23 ... 24 </a:scenario> 25 </ExtendedData> Note que é necessário definir um namespace (linha 1) no element ExtendedData e a seguir pode-se utilizar os elementos a:scenario, a:username, a:schedule e seus subelementos. O elemento a:scenario (linha 2) permite definir a agenda para o cenário, que é composta por sinais de ativação (a:trigger – linhas 5-12) e caminhos (a:path – linhas 13-22). Os sinais necessitam de um horário inicial e os dias da semana em que podem ser ativados (linhas 611). Os caminhos referenciam um Placemark (atributo ref – linhas 13 e 18) e possuem uma probabilidade de escolha (linhas 14 e 19), uma velocidade (linha 15) e uma direção (linha 16). Utiliza-se esta distribuição massa de probabilidade para, dado que um sinal de ativação foi disparado, determinar qual rota será escolhida. A velocidade determina, em km/h, qual seria a velocidade de deslocamento na execução de um caminho e, a direção define se o caminho será executado na ordem direta ou inversa dos pontos (elemento coordinates). 170 O carregamento de arquivos KML é feito em Java utilizando a biblioteca JAK (Java API for KML)34 para carregar os elementos do padrão KML e a biblioteca do padrão JAXB (Java Architecture for XML Binding)35 instalada juntamente com a plataforma Java para carregar o conteúdo XML do elemento ExtendedData. Ambos são capazes de transformar KML e XML em objetos Java (POJOs), sendo que a segunda utiliza Java annotations definidas pelo padrão JAXB. O diagrama de classes básico utilizado pela JAK é apresentado na Figura 38 (esquerda) e é de fácil entendimento visto que reflete a discussão dos parágrafos anteriores, sendo importante destacar apenas que AbstractObject é aquilo que possui um identificador. Para os dados personalizados, o conteúdo do elemento ExtendedData é convertido nos objetos Java apresentados também na Figura 38 (direita). Por fim, a classe Path é associada a um animador de caminho (uma instância da interface PathAnimator) que é capaz de interpretar as coordenadas do caminho estático (StaticPath) conforme a velocidade e a direção definidas e gerar pontos simulando o deslocamento no caminho. PathAnimator e StaticPath serão detalhadas posteriormente. Kml AbstractObject UserScenario 1 + username : String 1 Feature * Geometry * Container Placemark Point 1 * LineString Folder LinearRing Document Polygon MultiGeometry * * Schedule Coordinate Boundary * 1 Trigger Path + time: Calendar + weekly : List <Day> + pathId : String + probability : double + velocity : double + way : Way Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita) Além da geração de coordenadas usando o arquivo KML, foi também desenvolvido um método para gerar os pontos inicial e final de caminhos cujo traçado foi obtido do serviço Google Directions36. Este serviço é gratuito para uso não comercial, mas apesar de sua forma gratuita ter algumas limitações estas não atrapalharam o desenvolvimento. É um serviço Web que, resumidamente, recebe dois pontos (inicial e final) e retorna um arquivo JSON com os pontos da rota. De forma semelhante à conversão feita de XML para objetos Java, foi feita conversão de JSON para objetos Java usando anotações JAXB, contudo usando uma 34 Disponível em http://code.google.com/p/javaapiforkml/ 35 Mais informações em http://www.oracle.com/technetwork/articles/javase/index-140168.html 36 Documentação disponível em https://developers.google.com/maps/documentation/directions/ 171 biblioteca externa chamada Jersey37. Ao obter o arquivo JSON e construir os objetos Java, cria-se um caminho estático e um animador de caminho (StaticPath e PathAnimator). Quanto à geração dos pontos inicial e final de cada caminho é utilizada a densidade populacional das regiões administrativas (RAs) do município do Rio de Janeiro. Estes dados foram obtidos da tabela nº 2972 disponível na seção “Estatísticas > População” do Armazém de Dados de Prefeitura do Rio de Janeiro 38. A quantidade de habitantes residentes em cada RA foi colocada numa planilha do Excel e gerou-se sua distribuição acumulada conforme parcialmente apresentado no Quadro 15. Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em RAs (2010) Regiões Administrativas Jacarepaguá Campo Grande Bangu Méier Madureira Santa Cruz Barra da Tijuca Realengo ... Cidade de Deus Paquetá Soma População (hab.) 572.030 542.084 428.035 397.782 372.555 368.534 300.823 243.006 ... 36.515 3.361 6.320.446 % da população 9,05% 8,58% 6,77% 6,29% 5,89% 5,83% 4,76% 3,84% ... 0,58% 0,05% Prob. Acumulada 9,05% 17,63% 24,40% 30,69% 36,59% 42,42% 47,18% 51,02% ... 99,95% 100,00% Como base neste quadro, o algoritmo de geração de um ponto é apresentado a seguir: 1 2 3 4 # Algoritmo de geração de um ponto base na densidade populacional Gere um número pseudo-aleatório entre 0 e 1 usando a distribuição uniforme de probabilidade Descubra a qual região administrativa pertence consultando o quadro Use o método de Monte Carlo para gerar um ponto no polígono da RA Para gerar um ponto dentro de uma RA não basta apenas gerar um ponto, mas também conhecer as bordas dos polígonos de todas elas. Estas bordas foram obtidas da página do Portal Geo da Prefeitura do Rio de Janeiro 39, e como disponibilizam para download em formato Shapefile40 foi usado o conversor para KML Shape2Earth41. Com as bordas 37 Biblioteca Jersey para desenvolvimento de serviços Web: http://jersey.java.net/ 38 Armazém de Dados da Prefeitura do Rio de Janeiro: http://www.armazemdedados.rio.rj.gov.br/ 39 Portal Geo: http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm 40 Formato Shapefile: http://pt.wikipedia.org/wiki/Shapefile 172 conhecidas constrói-se o bounding box, que é o retângulo que envolve todos os pontos do polígono. Assim, dada uma RA gera-se, aleatoriamente, um ponto (x, y) interno ao retângulo envolvente e verifica-se se o ponto pertence ao polígono 42. Este método de sortear uma solução e verificar se atende uma função é bastante conhecido e denomina-se Método de Monte Carlo. Com base nestas informações, o seguinte algoritmo de geração de coordenadas e atualização no banco de dados foi usado: 1 # algoritmo de geração de caminhos 2 para cada usuario 3 se existe caminho associado ao usuario 4 gere proximo ponto do caminho 5 atualize BD com posicao do usuario e horario atual 6 se caminho terminou 7 desassocie o caminho do usuario 8 se gerador aleatorio 9 defina proximo horario de movimentacao 10 senao 11 se gerador aleatorio 12 se horario atual > proximo horario de movimentacao 13 obtenha posicao atual p e gere um ponto destino q 14 gere um caminho entre p e q 15 senao # usando cenarios 16 obtenha caminho conforme horario atual e agenda do usuario 17 18 se obteve caminho 19 associe o caminho ao usuario 20 inicie animacao do caminho 21 senao 22 atualize BD para marcar horario de medicao atual O algoritmo gera pontos aleatórios ou conforme cenários. A linha 4 utiliza o animador de caminho associado ao usuário para determinar sua posição atual. Este caminho é gerado na linha 14 ou 16. Nas linhas 11-14 é gerado um caminho a partir do ponto atual e de um ponto destino aleatório caso o próximo horário de movimetação tenha sido atingido. Este horário é definido aleatoriamente na linha 9. Nas linhas 15-16, o caminho para o horário atual é obtido diretamente do cenário no KML. Nas linhas 18-20 o caminho é associado ao usuário e a animação iniciada. Caso nenhum caminho seja criado o usuário continua no mesmo ponto com atualização apenas de sua data de medição (linha 22). 41 Disponível em http://shape2earth.com/ 42 O algoritmo por ser encontrado em http://alienryderflex.com/polygon/ 173 Para finalizar esta seção, falta falar de caminhos estáticos e animadores de caminho. Um caminho estático, classe StaticPath, contém um conjunto de pontos geográficos ordenados e a distância em metros referente a sua trajetória. Possui ainda um identificador e um nome. A sequência de pontos é dada na sua construção e é proveniente do KML ou do JSON do Google Directions. O comprimento da trajetória é calculado quando a sequência de pontos é passada ou atualizada quando um novo ponto é adicionado. Um animador de caminho é representado pela interface PathAnimator que declara métodos para retornar o caminho estático, iniciar animação e verificar se terminou, e calcular ponto e distância atuais da animação. A classe UniformVelocityPathAnimator implementa esta interface. Ela utiliza um caminho estático e uma direção neste caminho (direto ou inverso) e gera trajetórias em movimento uniforme (MU – velocidade constante). Permite definir a velocidade do movimento ou duração do trajeto utilizando um parâmetro passado no construtor. A Figura 39 apresenta o diagrama estático UML destas classes. PathAnimator <<interface>> + getPath() : StaticPath + getEstimatedDuration() : int + getFirstPoint() : Point + startAnimation() : boolean + isAnimationRunning() : boolean + getAnimationPoint() : Point + getTraveledDistance() : Float + getStartTime() : long Point + x : double + y : double * StaticPath UniformVelocityPathAnimator <<constructor>>(StaticPath, duration : int, direction : Way) <<constructor>>(StaticPath, velocity : int, direction : Way) 1 - id : String - name : String - distance : double Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath. 174 Apêndice C – Cenário 2: implementação da configuração dos módulos Este apêndice apresenta a configuração detalhada dos módulos do cenário 2. Contudo, para prosseguir a leitura recomenda-se primeiramente a leitura completa das seções 4.2.1 a 4.2.3, pois há referências a muitos conceitos e tabelas apresentados nestas seções. Conforme apresentada na Figura 21, M1 consulta apenas o endpoint RSE, logo necessita de apenas um carregador, mas como precisa calcular as chuvas acumuladas nos quatro intervalos de tempo para cada estação e também obter as localizaçõs das estações, são necessárias cinco consultas. A forma padrão das quatro primeiras consultas é dada a seguir. Observa-se que é obtida a soma das medições durante o intervalo de tempo definido pelas variáveis ?startDate e ?finalDate. Estas são substituídas durante a execução pelo intervalo de tempo desejado. O responsável por fazer estas substituições é o binder TimeFrameQueryBinder, sendo assim, a segunda variável será substituída pela data e hora do instante de execução da consulta, e a primeira, pela data e hora inicial, ou seja, aquela obtida por se subtrair o intervalo de tempo (em milissegundos) determinados pela janela de tempo. A chamada à função BIND cria um nó com URI para representar a instância da classe x:Location da estação. Um fato importante a se destacar foi observado ao usar o BIND com a versão 0.8.1 do D2RQ. A versão de consulta utilizando BIND no mesmo WHERE de um FILTER inutiliza o filtro, ou seja, é o mesmo que não colocar um filtro. Isto é destacado pelos trechos tachados (nas linhas 7 e 14). A solução utilizada para contornar esta falha é apresentada em sublinha na linha 18. Uma segunda solução seria não utilizar um BIND explícito, mas sim um implícito no final da projeção (SELECT na linha 7) contendo apenas a expressão URI...AS ?sloc entre parêntesis. Por fim, é construído um novo grafo que mapeia a ontologia do endpoint SER (prefixo a) para a ontologia usada nos módulos (prefixo x). Esta consulta é similar à função acc_rain do algoritmo apresentado (linhas 57-64) e será denominada Qacc até o final desta seção. 1 CONSTRUCT { 2 ?s a x:Station ; 3 x:location ?sloc . 4 ?sloc x:accRain15 ?acc . 5 } 6 WHERE { 7 { SELECT ?s (SUM(?v) as ?acc) ?sloc 8 WHERE { 9 ?s a a:Station . 10 ?m a:station ?s . 11 ?m a:measureValue ?v . 175 12 13 14 15 16 17 18 ?m a:measureDate ?t . FILTER (?t >= ?startDate && ?t <= ?finalDate) BIND(URI(...) AS ?sloc) } GROUP BY ?s ?sloc } BIND(URI(fn:concat( "http://infmod01.com.br/resource/stlocation/", afn:sha1sum(?s))) AS ?sloc) 19 } A consulta para obter as localizações das estações também é simples, obtendo, basicamente, latitude e longitude das estações cujo período de funcionamento (a:beginDate e a:endDate) está compreendido na janela de tempo definida pelas variáveis ?startDate e ?finalDate (também usando TimeFrameQueryBinder). Devido à falha da inutilização do filtro em conjunto com BIND foi necessário adicionar um Sub-SELECT (um binding implícito também seria possível). Esta consulta será denominada Qstloc até o final desta seção e é apresentada a seguir. 1 CONSTRUCT { 2 ?s a x:Station ; 3 x:location ?sloc . 4 ?sloc x:latitude ?slat ; 5 x:longitude ?slon . 6 } 7 WHERE { 8 { SELECT ?s ?slat ?slon 9 WHERE { 10 ?s a a:Station ; 11 a:latitude ?slat ; 12 a:longitude ?slon ; 13 a:beginDate ?t0 ; 14 a:endDate ?t1 . 15 FILTER (?t0 <= ?startDate && ?t1 > ?finalDate). 16 } 17 } 18 BIND(URI(fn:concat( "http://infmod01.com.br/resource/stlocation/", afn:sha1sum(?s))) AS ?sloc) 19 } Uma vez definidas as consultas, a configuração do XML do módulo M1 se torna simples conforme apresentada a seguir. Observa-se que a configuração do binder necessita de apenas um elemento <frameMillis> que informa q uantos milissegundos devem ser subtraídos da data e hora atual para determinar o valor de ?startDate (linhas 15, 22, 29, 36 e 176 43). Nas linhas 49-52 pode-se visualizar a configuração da inferência usando a ontologia apresentada para validar os dados usando Pelet Reasoner. 1 <InferenceModule> 2 <name>M1</name> 3 <prefixes>...</prefixes> 4 <resourceBaseUri>http://infmod01.com.br/resource/</resourceBaseUri> 5 <updatePolicy class="ClearDataPolicy" /> 6 <clock baseUri="http://localhost:3030/" endpoint="" /> 7 <loaders> 8 <PullLoader> 9 <endpoint>http://alertario.rio.rj.gov.br:2020/sparql</endpoint> 10 <queryConfigs> 11 <QueryData> <!-- Pega chuva dos ultimos 15 minutos --> 12 <query>Qacc</query> 13 <interval>2.5*60*1000</interval> <!-- Intervalo de 2.5 min --> 14 <binder class="TimeFrameQueryBinder"> 15 <frameMillis>15*60*1000</frameMillis> <!-- últimos 15 min --> 16 </binder> 17 </QueryData> 18 <QueryData> <!-- Pega chuva acumulada na última 01 hora --> 19 <query>Qacc</query> 20 <interval>2.5*60*1000</interval> <!-- Intervalo de 5 min --> 21 <binder class="TimeFrameQueryBinder"> 22 <frameMillis>1*60*60*1000</frameMillis> <!-- última 1 hora --> 23 </binder> 24 </QueryData> 25 <QueryData> <!-- Chuvas acumuladas nas últimas 24 horas --> 26 <query>Qacc</query> 27 <interval>2.5*60*1000</interval> 28 <binder class="TimeFrameQueryBinder"> 29 <frameMillis>24*60*60*1000</frameMillis> <!-- 24 horas --> 30 </binder> 31 </QueryData> 32 <QueryData> <!-- Chuvas acumuladas nas últimas 96 horas --> 33 <query>Qacc</query> 34 <interval>2.5*60*1000</interval> 35 <binder class="TimeFrameQueryBinder"> 36 <frameMillis>96*60*60*1000</frameMillis> <!-- 96 horas --> 37 </binder> 38 </QueryData> 39 <QueryData> <!-- Pega estacoes e suas localizações--> 40 <query>Qstloc</query> 41 <interval>60*60*1000</interval> 42 <binder class="TimeFrameQueryBinder"> 43 <frameMillis>96*60*60*1000</frameMillis> <!-- 96 horas --> 44 </binder> 45 </QueryData> 46 </queryConfigs> 177 47 </PullLoader> 48 </loaders> 49 <inference> 50 <reasoner>PELLET</reasoner> 51 <ontology>ontology.owl.ttl</ontology> 52 </inference> 53 <sparqlServer> 54 <path>/ds/</path> 55 <port>25001</port> 56 <fastUpdate>true</fastUpdate> 57 </sparqlServer> 58 </InferenceModule> O módulo M2 calcula as distâncias entre usuários e estações, associando a cada usuário as três estações mais próximas. Isto equivale às linhas 1-15 do algoritmo, que consistem em duas consultas e um laço. A primeira, Quser, obtém a lista de usuários do endpoint ULE, suas localizações e horários de obtenção. A segunda, Qdist, é executada dentro do laço que itera sobre a lista de usuários, e tira proveito da função geo:distanceFromDegrees do módulo M1 para cálculo da distância geográfica entre dois pontos (neste caso usuário e as estações), ordena estes resultados usando a cláusula ORDER BY e faz um corte nos três primeiros resultados usando a cláusula LIMIT, selecionando assim, as três estações mais próximas. Para executar a consulta Qdist para cada linha de resultado da Quser usando o Módulo de Inferência utiliza-se o binder SelectQueryParameterBinder. Ambas as consultas são listadas a seguir e as variáveis da consulta Quser substituídas na consulta Qdist estão destacadas com sublinhado: 1 2 3 4 5 6 7 8 SELECT ?u ?uloc ?ulat ?ulon ?utime WHERE { ?u a usr:User ; usr:location ?uloc . ?uloc usr:latitude ?ulat ; usr:longitude ?ulon ; usr:updateTime ?utime . } 1 2 3 4 5 6 7 8 9 CONSTRUCT { ?u a x:User ; x:inferenceLocation ?uloc . ?uloc x:latitude ?ulat ; x:longitude ?ulon ; x:updateTime ?utime ; x:nearestStations ?ns . ?ns x:station ?s ; x:distance ?dist . 178 10 } 11 WHERE { 12 { SELECT ?s (geo:distanceFromDegrees(?ulat, ?ulon, ?slat, ?slon) as ?dist) 13 WHERE { 14 ?s a x:Station ; 15 x:location [ 16 x:latitude ?slat ; 17 x:longitude ?slon ] . 18 } 19 ORDER BY ?dist 20 LIMIT 3 21 } 22 BIND (URI(fn:concat( "http://infmod02.com.br/resource/NearestStationsInfo/", afn:sha1sum(fn:concat(?u, ?s)))) as ?ns) 23 } Adicionalmente, uma consulta que obtém os valores de chuvas acumuladas de M1 foi adicionada ao módulo M2. Esta consulta funciona apenas para repassar estes valores para o endpoint de M2. Por ser um consulta simples e não acrescentar conhecimento será omitida e denominada Qacc2. O XML de M2 é apresentado a seguir: 1 <InferenceModule> 2 <name>M2</name> 3 <prefixes>...</prefixes> 4 <resourceBaseUri>http://infmod02.com.br/resource/</resourceBaseUri> 5 <updatePolicy class="ClearDataPolicy" /> 6 <clock baseUri="http://localhost:3030/" endpoint="" /> 7 <loaders> 8 <PullLoader> 9 <endpoint>http://infmod01.com.br:25001/ds/sparql</endpoint> 10 <queryConfigs> 11 <QueryData> 12 <interval>2*60*1000</interval> 13 <query>Qacc2</query> 14 <binder class="DefaultQueryParameterBinder" /> 15 </QueryData> 16 <QueryData> 17 <interval>2*60*1000</interval> 18 <query>Qdist</query> 19 <binder class="SelectQueryParameterBinder"> 20 <endpoint>http://users.com.br:2026/sparql</endpoint> 21 <query>Quser</query> 22 </binder> 23 </QueryData> 24 </queryConfigs> 25 </PullLoader> 179 26 </loaders> 27 <inference>...</inference> 28 <sparqlServer>...</sparqlServer> 29 </InferenceModule> <!-igual ao M1 --> <!-- semelhante ao M1 --> O modulo M3 é o mais complexo por implementar as linhas 17-55 do algoritmo. A Equação I é calculada através de uma consulta SPARQL e a classificação efetuada por meio de regras Jena. São usadas regras do Jena por dois motivos: (1) maior facilidade de se escrever regras por não haver necessidade de editores especiais devido a sua sintaxe simples; e (2) mostrar a possibilidade de se misturar dois diferentes motores de inferência na rede, desde que em diferentes módulos. Relembre que é necessário calcular o denominador do peso (dtot nas linhas 17-18) e o peso (linha 22) de cada estação no cálculo da suposta quantidade de chuva na posição do usuário (linhas 23 a 26). Portanto, a consulta SPARQL pode ser considerada complexa porque inclui quatro SELECTs distribuídos em três níveis de aninhamento (Sub-SELECTs), quatro junções (dois SELECTs e dois padrões de grafo), função de agregação SUM e expressões matemáticas (multiplicaçaõ e divisão). A consulta completa é mostrada a seguir (Qchuva): 1 CONSTRUCT { 2 ?u a x:User . 3 ?u x:inferenceLocation ?loc . 4 ?loc x:latitude ?lat ; 5 x:longitude ?lon ; 6 x:updateTime ?time ; 7 x:accRain15 ?avg15 ; 8 x:accRain01h ?avg60 ; 9 x:accRain24h ?avg24 ; 10 x:accRain96h ?avg96 ; 11 } 12 WHERE { 13 SELECT DISTINCT ?u ?loc ?lat ?lon ?time 14 (sum(?lv15) as ?avg15) # Calcula avg15 para 15 (sum(?lv60) as ?avg60) # Calcula avg60 para 16 (sum(?lv24) as ?avg24) # Calcula avg24 para 17 (sum(?lv96) as ?avg96) # Calcula avg96 para 18 WHERE { 19 SELECT DISTINCT ?u ?loc ?lat ?lon ?time 20 ((?w * ?v15) as ?lv15) # Calcula parcelas 21 ((?w * ?v60) as ?lv60) # Calcula parcelas 22 ((?w * ?v24) as ?lv24) # Calcula parcelas 23 ((?w * ?v96) as ?lv96) # Calcula parcelas 24 WHERE { 25 { 26 # Calcula denominador da fórmula (?dtot) cada cada cada cada usuario usuario usuario usuario para 15 min para 1 h para 24 h para 96 h 180 27 { SELECT DISTINCT ?u ?loc (sum(1 / (?d * ?d)) as ?dtot) 28 WHERE { 29 ?u a x:User ; 30 x:inferenceLocation ?loc . 31 ?loc x:nearestStations ?ns . 32 ?ns x:station ?s ; 33 x:distance ?d . 34 } 35 GROUP BY ?u ?loc 36 } 37 # Calcula numerador de cada peso w: 1/d^2 (?num_w) 38 { SELECT DISTINCT ?u ?loc (1 / (?d * ?d) as ?num_w) ?s 39 WHERE { 40 ?u a x:User . 41 ?u x:inferenceLocation ?loc . 42 ?loc x:nearestStations ?ns . 43 ?ns x:station ?s ; 44 x:distance ?d . 45 } 46 } 47 # Obtem chuva acumulada nas estações próximas ao usuário ?u 48 { ?s x:location [ 49 x:accRain15 ?v15 ; 50 x:accRain01h ?v60 ; 51 x:accRain24h ?v24 ; 52 x:accRain96h ?v96 ] . 53 } 54 # Obtem lat/long do usuário ?u e horário de atualização 55 { ?loc x:latitude ?lat ; 56 x:longitude ?lon ; 57 x:updateTime ?time . 58 } 59 } 60 # Calcula pesos (?w) 61 BIND ((?num_w / ?dtot) as ?w) 62 } 63 } 64 GROUP BY ?u ?loc ?lat ?lon ?time 65 } Os SELECTs mais internos calculam numerador e denominador dos pesos (1/d2 e Equação IIc) e são encontrados nas linhas 37-46 e 26-36, respectivamente. O cálculo do denominador utiliza a função de agregação SUM agrupada por usuário e localização. Existe apenas uma instância de x:UserLocation para cada propriedade x:inferenceLocation de usuário, mas outras poderiam ser adicionadas (como casa, trabalho, etc.) sem necessidade de alterações na consulta visto que ela já garante distinção. Uma vez que estes SELECTs retornam soluções nas variáveis ?u, ?loc, ?dtot, ?num_w, e ?s, estas são combinadas (produto 181 cartesiano ou junção) com os padrões de grafos das linhas 47-53 e 54-58 que capturam as chuvas acumuladas na estação ?s e latitude, longitude da localização ?loc do usuário ?u (e também horário de atualização destas coordenadas), respectivamente. O resultado desta junção é, então, utilizado no SELECT de segundo nível que calcula pesos (Equação IIb) na linha 61, e as parcelas wi vi(t) para os quatro períodos em questão preenchendo as variáveis ?lv15, ?lv60, ?lv24 e ?lv96 nas linhas 20-23. Estas parcelas são somadas no SELECT mais externo chegando-se ao resultado das variáveis ?avg15, ?avg60, ?avg24 e ?avg96 (Equação IIa). Por fim, é montado o grafo que armazenará estes resultados para posterior utilização através do CONSTRUCT. Baseado na suposta quantidade de chuva, a intensidade de chuva e a probabilidade de escorregamento definidas pelo Alerta-Rio são dadas por meio das seguintes regras Jena: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 # Intensidade de chuvas (15 min) r15a: (?p :accRain15 ?v) gt(?v, 12.50) r15b: (?p :accRain15 ?v) gt(?v, 6.25) r15c: (?p :accRain15 ?v) gt(?v, 1.25) r15d: (?p :accRain15 ?v) gt(?v, 0.28) r15e: (?p :accRain15 ?v) # Intensidade de chuvas (1h) r60a: (?p :accRain01h ?v) gt(?v,50.00) r60b: (?p :accRain01h ?v) gt(?v,25.00) r60c: (?p :accRain01h ?v) gt(?v, 5.00) r60d: (?p :accRain01h ?v) gt(?v, 1.10) r60e: (?p :accRain01h ?v) gt(?v, 0.50) r60f: (?p :accRain01h ?v) gt(?v, 0.25) r60g: (?p :accRain01h ?v) gt(?v, 0.00) r60h: (?p :accRain01h ?v) -> (?p :rainLevel15 le(?v, 12.50) -> (?p :rainLevel15 le(?v, 6.25) -> (?p :rainLevel15 le(?v, 1.25) -> (?p :rainLevel15 le(?v, 0.28) -> (?p :rainLevel15 (?p (?p (?p (?p (?p (?p (?p (?p :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h 7) 6) 5) 4) 3) 2) 1) 0) # Alerta de escorregamento (1h) s60a: (?p :accRain01h ?v) gt(?v,50.00) -> (?p s60b: (?p :accRain01h ?v) gt(?v,30.00) le(?v,50.00) -> (?p s60c: (?p :accRain01h ?v) gt(?v,10.00) le(?v,30.00) -> (?p s60d: (?p :accRain01h ?v) le(?v,10.00) -> (?p :slipLevel01h :slipLevel01h :slipLevel01h :slipLevel01h 3) 2) 1) 0) # Alerta de escorregamento (24h) s24a: (?p :accRain24h ?v) gt(?v,175.0) -> (?p s24b: (?p :accRain24h ?v) gt(?v,100.0) le(?v,175.0) -> (?p s24c: (?p :accRain24h ?v) gt(?v, 50.0) le(?v,100.0) -> (?p s24d: (?p :accRain24h ?v) le(?v, 50.0) -> (?p :slipLevel24h :slipLevel24h :slipLevel24h :slipLevel24h 3) 2) 1) 0) # Alerta de escorregamento (96h) s96a: (?p :accRain96h ?v) gt(?v,250.0) -> (?p s96b: (?p :accRain96h ?v) gt(?v,175.0) le(?v,250.0) -> (?p s96c: (?p :accRain96h ?v) gt(?v,100.0) le(?v,175.0) -> (?p s96d: (?p :accRain96h ?v) le(?v,100.0) -> (?p :slipLevel96h :slipLevel96h :slipLevel96h :slipLevel96h 3) 2) 1) 0) le(?v,50.00) le(?v,25.00) le(?v, 5.00) le(?v, 1.10) le(?v, 0.50) le(?v, 0.25) le(?v, 0.00) -> -> -> -> -> -> -> -> 7) 6) 5) 4) 0) 182 37 # Intensidade de chuvas (final) 38 r01: (?p :rainLevel15 ?x) (?p :rainLevel01h ?y) max(?x, ?y, ?z) -> (?p :rainLevelX ?z) 39 40 r02: (?p :rainLevelX 7) -> (?p :rainLevel :VeryHeavyRain) 41 r03: (?p :rainLevelX 6) -> (?p :rainLevel :HeavyRain) 42 r04: (?p :rainLevelX 5) -> (?p :rainLevel :ModerateRain) 43 r05: (?p :rainLevelX 4) -> (?p :rainLevel :LightRain) 44 r06: (?p :rainLevelX 3) -> (?p :rainLevel :HeavyDrizzle) 45 r07: (?p :rainLevelX 2) -> (?p :rainLevel :ModerateDrizzle) 46 r08: (?p :rainLevelX 1) -> (?p :rainLevel :LightDrizzle) 47 r09: (?p :rainLevelX 0) -> (?p :rainLevel :Dry) 48 49 # Alerta de escorregamento (final) 50 s01: (?p :slipLevel01h ?x) (?p :slipLevel24h ?y) (?p :slipLevel96h ?z) max(?x,?y,?w0) max(?w0,?z,?w) -> (?p :slipLevelX ?w) 51 52 s02: (?p :slipLevelX 3) -> (?p :slipLevel :VeryHigh) 53 s03: (?p :slipLevelX 2) -> (?p :slipLevel :High) 54 s04: (?p :slipLevelX 1) -> (?p :slipLevel :Moderate) 55 s05: (?p :slipLevelX 0) -> (?p :slipLevel :Low) As regras não são difíceis de se entender. Por exemplo, a regra r15a na linha 2 diz “se existe um localização cuja chuva dos últimos 15 minutos seja maior que 12.50 mm então adicione uma tripla afirmando que o nível para intensidade de chuva dos últimos 15 minutos é 7 (ou x:VeryHeavyRain)”. Maiores detalhes sobre cada regra e bloco de regras são dadas nos próximos parágrafos. Como apresentado nos Quadros 8 e 10, para a classificação do nível de intensidade de chuva, deve-se considerar os valores de medições em mm/h e mm/15min, respectivamente. Desta forma as regras r15a a r15e (linhas 2-6) verificam em qual faixa a propriedade x:accRain15 se encontra (mm/15min) e as regras r60a a r60h (linhas 9-16) verificam a faixa para a propriedade x:accRain01h. Estes dois conjuntos de regras produzem, respectivamente, triplas com predicados x:rainLevel15 e x:rainLevel01h cujos objetos são valores numéricos inteiros intermediários que representam o grau de gravidade do alerta (zero para sem chuva e sete para chuva muito forte). Para estas regras foram utilizadas duas funções (built-ins) do Jena: greaterThan (abreviada para gt) que retorna true se o primeiro argumento é maior que o segundo; e le que retorna true se o primeiro argumento é menor ou igual ao segundo. Conforme descrito na seção 4.2.1 sobre o domínio, escolheu-se utilizar o pior dos valores obtidos (máximo entre x:rainLevel15 e x:rainLevel01h), que corresponde a regra r01 (linha 38) e utiliza a função max. Este valor é então mapeado para instâncias de x:RainLevel por meio das regras r02 a r09 (linhas 40-49). 183 O processo é feito de forma semelhante para alertas de probabilidade de escorregamento (Quadro 9). As regras s60a a s60d (1 hora), s24a a s24d (24 horas) e s96a a s96d (96 horas) encontradas nas linha 19-22, 25-28 e 31-34, respectivamente, produzem triplas intermediárias com os predicados x:slipLevel01h, x:slipLevel24h e x:slipLevel96h que possuem os graus de gravidade do alerta (zero para baixa probabilidade de escorregamento, um para moderada, dois para alta e três para muito alta). Novamente, o valor mais crítico dentre estes três é obtido (regra s01 na linha 50) e mapeado para instâncias de x:SlipLevel (regras s02 a s05 nas linhas 52-55). Vários observações importantes devem ser destacadas aqui. Primeiramente, não haverá várias classificações (x:rainLevel e x:slipLevel) para uma mesma localização porque as propriedade x:accRainY são únicas para cada URI de localização (fato comprovado pelo GROUP BY mais externo da consulta Qchuva). Para ficar mais claro, veja que como existe no máximo uma tripla (?p x:accRain15 ?v) no grafo (para cada localização ?p) é garantido que no máximo uma tripla (?p x:rainLevel15 X) será criada e a regra r01 será disparada no máximo uma vez para cada localização (?p) gerando no máximo uma tripla (?p x:rainLevelX ?z) e consequentemente uma tripla com o predicado x:rainLevel. O mesmo ocorre para probabilidade de escorregamento. O segundo ponto diz respeito à consistência da base gerada por M3. As propriedades intermediárias x:rainLevel15, x:rainLevel01h, x:rainLevelX, x:slipLevel01h, x:slipLevel24h, x:slipLevel96h e x:slipLevelX não estão presentes na ontologia apresentada na Figura 22, logo uma validação nesta base resultaria em incosistência. Para resolver isto bastaria adicionar as propriedades à ontologia e configurar M3 para utilizá-la, mas optou-se por não realizar a validação que será feita no próximo módulo. Assim, este módulo é apenas baseado em regras sem validação OWL-DL. Outro ponto importante é que estas regras poderiam ser facilmente implementadas via programação convencional imperativa conforme apresentado no algoritmo completo (linhas 28-55 da seção 4.2.3.1), mas isto não é permitido pela arquitetura do Módulo de Inferência, sugerindo trabalhos futuros. Para concluir M3, o XML de configuração apenas com as partes mais importantes para evitar repetições é apresentado a seguir: 1 2 3 4 5 6 7 <InferenceModule> <name>M3</name> ... <loaders> <PullLoader> <endpoint>http://infmod02.com.br:25002/ds/sparql</endpoint> <queryConfigs> 184 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 <QueryData> <query>Qchuva</query> <interval>3*60*1000</interval> <binder class="DefaultQueryParameterBinder" /> </QueryData> </queryConfigs> </PullLoader> </loaders> <inference> <rules> [r15a: (?p x:accRain15 ?v) greaterThan(?v, 12.50) -> (?p x:rainLevel15 7) ] [r15b: (?p x:accRain15 ?v) greaterThan(?v, 6.25) -> (?p x:rainLevel15 6) ] ... </rules> </inference> <sparqlServer> ... </sparqlServer> </InferenceModule> le(?v, 12.50) As regras são adicionadas no interior do element <rules> (linhas 17-21). Pode-se observar que cada regra deve ser envolvida por colchetes que foram omitidos devido ao pequeno espaço ao mostrar todas as regras anteriormente. Até este momento, a localização de cada usuário já possui uma classificação para intensidade de chuva e probabilidade de escorregamento. Poderia-se até finalizar a rede neste ponto, mas para mostrar como um novo módulo pode ser adicionado facilmente, foi criado o módulo M4 para produzir contexto de bairro para o usuário. Assim, a tarefa de M4 é recuperar a posição atual de cada usuário e adicionar a informação do bairro à ela, fazendo o mesmo com a posição usada para geração dos alertas. Para isso é utilizado um carregador para o endpoint NBE contendo dois pares de consultas. O primeiro par obtém a posição atual do usuário consultando o endpoint ULE com uma consulta semelhante à Quser, de forma que um SelectQueryParameterBinder é usado para atribuir valores às variáveis de uma outra consulta disparada contra o endpoint NBE. Esta última utiliza a função nb_contains para descobrir o bairro que contém a coordenada geográfica dada. Estas informações são associadas ao usuário através da propriedade x:currentLocation. O segundo par de consultas executa um processo semelhante, com a diferença de determinar o bairro da posição utilizada na inferência (propriedade x:inferenceLocation oriunda de M3), e adicionalmente repassar os valores das propriedades x:slipLevel e x:rainLevel já computadas por M3. O XML não será apresentado aqui. 185 Apêndice D – Cenário 3: implementação, mapeamento e configuração dos módulos para Bus Locations Endpoint (BLE) Este apêndice abordará a implementação do endpoint BLE, que compreende um gerador de caminho de ônibus com base em arquivos KML contendo pontos de ônibus e rotas. As coordenadas geradas são armazenadas em um banco de dados relacional e mapeadas para RDF usando uma parte da ontologia BusOnto (seção 4.3.1.3 na página 121). As bibliotecas e ferramentas utilizadas são as mesmas descritas no Apêndice B, salvo quando expresso o contrário. Por fim, dois módulos de inferência são usados para (a) completar o que não é expresso pelo mapeamento e checar a consistência da base estática usando Pellet e (b) agregar a base estática e os dados dinâmicos usando Jena. Este último módulo é o endpoint final do BLE. A Figura 40 esquematiza este procedimento. BusDyn (Jena) bus:Bus (10s) Rotas, linhas, etc. (10min) BusStatic (Pellet) Rotas, linhas, etc. (1h) BusD2R (porta 5050) mapeamento para RDF Rotas (KML) Paradas (KML) Carregador de KML Algoritmo de geração de ônibus e caminhos atualiza SGBD Figura 40. Estrutura interna do endpoint BLE Como pode observar na figura, há dois tipos de arquivos KML (o formato é explicado no Apêndice B). O primeiro deles possui apenas paradas de ônibus, ou seja, dados estáticos sobre pontos geográficos rotulados (Placemark e Point). O segundo tipo de KML contém rotas de ônibus (Placemark e LineString) e o nome e código da linha. Apenas duas linhas de ônibus foram elaboradas, retratando uma linha interna (Alojamento – Vila Residencial) e uma linha externa (General Osório – Penha) que circulam no campus da Ilha do Fundão. Isto resultou em quatro arquivos KML. Para simplificar, considerou-se que ambas as linhas circulam todos os dias da semana, 24 horas por dia, a uma velocidade média de 50 km/h, com intervalos médios de 12 minutos e desvio padrão de 4 minutos seguindo a distribuição normal de probabilidade. As coordenadas geográficas que compõem ambos os tipos de KML foram 186 gerados usando o software Google Earth43 e retratam a realidade dentro do campus (paradas e rotas reais). Uma vez carregados, os dados dos arquivos KML são inseridos em um banco relacional cujo esquema é apresentado na FIGURA. De forma semelhante ao endpoint ULE, há tabelas em disco e em memória, dependendo da frequência de atualização de seus registros. Assim, a parte estática (tabelas stop, route_stop, route e line) fica em disco e a parte dinâmica (tabela bus_car) em memória. Todas as tabelas são análogas às classes apresentadas na ontologia da Figura 26 na página 122, ou seja, o mapeamento é direto, conforme pode ser visto na Figura 41. bus:RouteStop bus:Stop Disco bus:Bus route_stop id (PK) : INT route_id (FK) : INT stop_id (FK) : INT sequence : INT distance_origin : FLOAT Memória stop id (PK) : INT name : VARCHAR(40) latitude : DOUBLE longitude : DOUBLE bus_car id (PK) : INT order_num : INT latitude : DOUBLE longitude : DOUBLE route_id (FK) : INT traveled_distance : FLOAT traveled_time : INT route id (PK) : INT line_id (FK) : INT start_rs_id (FK) : INT final_rs_id (FK) : INT bus:Route line id (PK) : INT name : VARCHAR(60) code : VARCHAR(8) bus:Line Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto. A geração das coordenadas das rotas dos ônibus é feita usando caminhos com trajetória em velocidade constante (classe UniformVelocityPathAnimator na Figura 39). Antes de criar o animador de caminho, a rota lida do KML é transformada numa lista de pontos (StaticPath). O processo é mostrado no algoritmo a seguir. 1 2 3 4 43 # Inicialização mi := 12 sigma := 4 Para cada rota r Google Earth – http://www.google.com/earth/ 187 5 next_time(r) = cur_time() 6 7 Enquanto simulação estiver rodando 8 # Geracao de carros 9 Para cada rota r 10 Se cur_time() > next_time(r) então 11 Crie um animador de caminho p iniciando em origem(r) 12 Crie um ônibus c com um número de ordem aleatório 13 Adicione (c, p) à simulação 14 next_time(r) = cur_time() + normal(mi, sigma * sigma) 15 16 # Atualização de coordenadas 17 Para cada (c, p) na simulação 18 Se p terminou então 19 Remova (c, p) da simulação 20 Senão 21 P = cur_point(p) 22 latitude(c) = P.y 23 longitude(c) = P.x 24 traveled_distance(c) = traveled_distance(p) 25 traveled_time(c) = cur_time - start_time(p) 26 Atualize c na simulação Assim, a saída de carros segue a distribuição normal com média de 12 minutos e desvio padrão de 4 minutos (linha 14), sendo que cada carro possui um trajeto dado pelo animador de caminhos construído a partir da rota oriundo do KML (linhas 11-12). Uma vez que um par carro/caminho (c, p) é adicionado à simulação (linha 13) a tabela bus_car do banco de dados passa a ser frequentemente atualizada traçando o caminho do ônibus (linhas 21 a 26). Uma vez que KML foram carregados, trajetos estão sendo atualizados e o D2R foi configurado e iniciado, basta construir os arquivos XMLs de configuração dos dois módulos de inferência que completam e validam a base exportada pelo D2R. Eles já foram sucitamente descritos na seção 4.3.2.3 na página 129 e são reapresentados na parte superior da Figura 40. O módulo que obtém os dados estáticos (BusStatic) executa um SPARQL DESCRIBE dos recursos que sejam instâncias de bus:Stop, bus:Route, bus:Line e bus:RouteStop, e aciona o reasoner Pellet aplicando a ontologia BusOnto conforme mostra no XML a seguir: 1 2 3 4 5 6 7 8 <InferenceModule> <name>Bus Endpoint</name> <resourceBaseUri>http://bus.org/resource/</resourceBaseUri> ... <loaders> <PullLoader> ... <queryConfigs> 188 9 <QueryData> 10 <description>Populate dataset</description> 11 <query> 12 DESCRIBE ?bs ?route ?rs ?line 13 WHERE { 14 ?bs a bus:Stop . 15 ?route a bus:Route . 16 ?rs a bus:RouteStop . 17 ?line a bus:Line . 18 } 19 </query> 20 <interval>1*60*60*1000</interval> 21 <binder class="DefaultQueryParameterBinder" /> 22 </QueryData> 23 </queryConfigs> 24 </PullLoader> 25 </loaders> 26 <inference> 27 <reasoner>PELLET</reasoner> 28 <ontology>busonto.owl</ontology> 29 </inference> 30 <sparqlServer>...</sparqlServer> 31 </InferenceModule> O módulo que obtém os dados dinâmicos (BusDyn) executa um SPARQL DESCRIBE dos recursos que sejam instâncias de bus:Bus oriundos de BusD2R e um SPARQL CONSTRUCT com todas as triplas de BusStatic. Utiliza uma regra Jena para adicionar a propridade bus:servingLine que associa um ônibus a uma linha. Para finalizar, o XML a seguir mostra a configuração do módulo: 1 <InferenceModule> 2 ... 3 <loaders> 4 <PullLoader> ... 5 <queryConfigs> 6 <QueryData> 7 <query>DESCRIBE ?x WHERE { ?x a bus:Bus }</query> 8 <interval>10*1000</interval> 9 <binder class="DefaultQueryParameterBinder" /> 10 </QueryData> 11 </queryConfigs> 12 </PullLoader> 13 <PullLoader> ... 14 <queryConfigs> 15 <QueryData> 16 <query>CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }</query> 17 <interval>10*60*1000</interval> 18 <binder class="DefaultQueryParameterBinder" /> 189 19 20 21 22 23 24 25 26 27 28 29 30 31 32 </QueryData> </queryConfigs> </PullLoader> </loaders> <inference> <reasoner>JENA</reasoner> <rules> [r1: (?b rdf:type bus:Bus), (?l rdf:type bus:Line), (?r rdf:type bus:Route), (?b bus:route ?r), (?l bus:route ?r) -> (?b bus:servingLine ?l) ] </rules> </inference> <sparqlServer>...</sparqlServer> </InferenceModule> 190 Apêndice E – Cenário 3: Configuração dos módulos da camada de inferência Este apêndice apresenta a configuração detalhada dos módulos do cenário 3. Contudo, para prosseguir recomenda-se primeiramente a leitura completa das seções 4.3.1 a 4.3.3, pois há referências a muitos conceitos e tabelas apresentados nestas seções. O módulo A1 utiliza duas consultas, denominadas Qcmdate e Qurel, e um conjunto de sete regras. Ambas são apresentadas a seguir. A primeira consulta é um DESCRIBE que obtém todas as instâncias de app:CommemorativeDate de CDE que estão por chegar através da comparação da sua data inicial na variável ?beg (propriedade time:hasBeginning de evento de intervalo) com a data e hora atual na variável ?date usando um FILTER. Data e hora atuais são obtidas fazendo uma consulta ao endpoint do relógio e para isso utiliza-se um SelectQueryParameterBinder. A segunda consulta, feita ao USNLE, é um DESCRIBE das pessoas (variáveis ?u, ?x e ?y), das relações existentes entre pessoas (variável ?r) e dos intervalos de tempo em que estas relações ocorrem (variável ?t). Observe que ao descrever um usuário ?u todas as suas propriedades são retornadas (ex. rel:siblingOf, rel:husbandOf, etc.). Estas duas consultas não precisam ser atualizadas com muita frequência, por isso Qcmdate executa a cada 10 minutos e Qurel a cada 5 minutos. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # Qcmdate DESCRIBE ?x WHERE { ?x a apv:CommemorativeDate ; evt:timeSpan [ a time:Interval ; time:hasBeginning ?beg ] . FILTER (?date < ?beg) } # Qurel DESCRIBE ?u ?x ?r ?t WHERE { { ?u a foaf:Person . } { ?u foaf:knows ?x } UNION { ?u rel:relativeOf ?y } UNION { ?r rel:participant ?u ; evt:timeSpan ?t . } } As regras utilizadas dividem-se três grupos: (a) construção de eventos de aniversário de nascimento e participações; (b) construção de eventos de aniversário de casamento e 191 namoro e participações; (c) construção de participações em eventos genéricos provenientes de CDE. As regras R1 e R1a apresentadas a seguir pertencem ao grupo (a). R1 pega a data de nascimento de uma pessoa (?dt), calcula o instante inicial da próxima data de aniversário usando a função makeNearestDateTime (?beg), gera o instante final (?end) e constrói dois nós no grafo da base intermediária usando a função makeNamedNode: um para o evento aniversário a ser criado (?ebn) e outro para o intervalo de tempo deste evento (?tbn). No caso de sucesso de todos estes procedimentos, adiciona triplas para dizer que ?ebn e ?tbn são instâncias de evt:Event e time:Interval respectivamente, relaciona ambos com a propriedade evt:timeSpan e define os instantes de início e fim do intervalo de tempo. Por fim, gera as triplas de participação (propriedades evt:playsRole e app:isBirthdayPersonOf). A regra R1a utiliza os eventos app:Birthday e participações app:isBirthdayPersonOf criados por R1 e as triplas com predicado foaf:knows para gerar participações do tipo “amigo de aniversariante” nos eventos aniversário. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 # Regra para construir evento Birthday: proximo aniversario R1: (?x rel:dateOfBirth ?dt), makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end), makeNamedNode(?ebn, ?x, "/Birthday"), makeNamedNode(?tbn, ?x, "/Birthday/Time") -> (?ebn rdf:type apv:Birthday), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?x app:isBirthdayPersonOf ?ebn) # Regra para associar pessoas ao aniversario de seus # conhecidos (amigos, mae, namorado, irmao, etc.) R1a: (?ev rdf:type apv:Birthday), (?x apv:isBirthdayPersonOf ?ev), (?x foaf:knows ?f) -> (?f evt:playsRole ?ev), (?f apv:isBirthdayPersonsFriendOf ?ev) As regras R2 e R3 apresentadas a seguir fazem parte do grupo (b). R2 obtém os participantes de um casamento (?x e ?y), o instante de início do relacionamento (?beg), calcula o fim do dia do evento (?end), gera nós para o evento app:WeddingDay (?ebn) e o 192 intervalo de tempo de sua ocorrência (?tbn) e, em caso de sucesso, adiciona triplas sobre ?ebn e ?tbn e particapações evt:playsRole. R3 é análoga e não será explicada. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 # Regra para construir evento WeddingDay: proximo aniversario # da relacao Marriage R2: (?r rdf:type rel:Marriage), (?x rel:participantIn ?r), (?y rel:participantIn ?r), notEqual(?x, ?y), (?r evt:timeSpan ?t), (?t time:hasBeginning ?dt) makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end) makeNamedNode(?ebn, ?r, "/WeddingDay"), makeNamedNode(?tbn, ?r, "/WeddingDay/Time") -> (?ebn rdf:type apv:WeddingDay), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?y evt:playsRole ?ebn) # Regra para construir evento CourtshipDay: proximo aniversario # da relacao Courtship R3: (?r rdf:type rel:Courtship), (?x rel:participantIn ?r), (?y rel:participantIn ?r), notEqual(?x, ?y), (?r evt:timeSpan ?t), (?t time:hasBeginning ?dt) makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end) makeNamedNode(?ebn, ?r, "/CourtshipDay"), makeNamedNode(?tbn, ?r, "/CourtshipDay/Time") -> (?ebn rdf:type apv:CourtshipDay), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?y evt:playsRole ?ebn) O terceiro grupo (c) é representado pela regras R_EG a seguir. Neste grupo, como os eventos já existem, pois vieram de CDE, basta construir as participações. Assim, todos 193 participam em feriados nacionais (R_EG1), apenas mãe e filho(a) participam do dia das mães (R_EG2) e apenas casais de namorados participam do dia dos namorados (R_EG3). Isto conclui o módulo A1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # Regra para relacionar eventos Holiday existentes e # pessoas (eventos gerais) R_EG1: (?p rdf:type foaf:Person), (?ev rdf:type apv:Holiday), noValue(?ev, rdf:type, apv:MothersDay) -> (?p evt:playsRole ?ev) # Regra para relacionar eventos MothersDay e pessoas cuja # mae seja conhecida R_EG2: (?p1 rel:motherOf ?p2), (?ev rdf:type apv:MothersDay) -> (?p1 evt:playsRole ?ev), (?p2 evt:playsRole ?ev) # Regra para relacionar eventos ValentinesDay e pessoas # cujo(a) namorado(a) seja conhecido(a) R_EG3: (?p1 rel:courts ?p2), (?ev rdf:type apv:ValentinesDay) -> (?p1 evt:playsRole ?ev), (?p2 evt:playsRole ?ev) O módulo B1 gera eventos de chegadas de ônibus em pontos de ônibus e para isso é necessário apenas uma consulta, denominada Qarrival1, que é um CONSTRUCT com SubSELECTs em dois níveis na cláusula WHERE. Ela é apresentada a seguir: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # Qarrival1 CONSTRUCT { ?ev a apv:BusArrival , evt:InstantEvent , evt:Event ; apv:bus ?car ; apv:busStop ?stop ; rdfs:label ?label ; rdfs:comment "Estimated time for the bus arrival"@en ; evt:atTime ?evtm . ?evtm a time:Instant ; time:hasDateTime ?dateTime . ?car bus:route ?route . } WHERE { { SELECT ?car ?stop ?route (infmod:sumTime(?date, 0, ?est_time) as ?dateTime) (fn:concat("Onibus <", str(?car), 194 17 "> em direcao ao ponto '", 18 ?stopname, "'") as ?label) 19 WHERE { 20 { # Seleciona onibus e suas próximas paradas e calcula 21 # distancia entre ambos e tempo estimado até chegar 22 SELECT ?stop ?stopname ?route ?car 23 ((?dist1 - ?dist2) as ?remaining_dist) 24 ((?remaining_dist * (?time / ?dist2)) as ?est_time) 25 WHERE { 26 ?rs a bus:RouteStop ; 27 bus:stop ?stop ; 28 bus:belongsToRoute ?route ; 29 bus:distanceFromOrigin ?dist1 . 30 ?car a bus:Bus ; 31 bus:traveledDistance ?dist2 ; 32 bus:traveledTime ?time ; 33 bus:route ?route . 34 ?stop bus:name ?stopname . 35 FILTER (?dist1 >= ?dist2 ) 36 } 37 } 38 FILTER(?est_time > 15 && ?est_time < 1200) 39 } 40 } 41 BIND (URI(fn:concat(str(?car), 42 "/Stop", 43 afn:substr(str(?stop), 44 infmod:getLastIndexOf("/", str(?stop))), 45 "/Event")) as ?ev) 46 BIND (URI(fn:concat(str(?car), 47 "/Stop", 48 afn:substr(str(?stop), 49 infmod:getLastIndexOf("/", str(?stop))), 50 "/Event/Time")) as ?evtm) 51 } O SELECT mais interno (linhas 22-35) seleciona ônibus e suas próximas paradas (?car e ?stop nas linhas 22 e 26-35) e calcula distância entre ambos (?remaining_dist, linha 23) e tempo estimado até chegar (?est_time, linha 24). O SELECT externo (linhas 14-40) filtra apenas os resultados cujo tempo estimado esteja entre 15 e 1200 segundos (FILTER na linha 38) e seleciona ônibus, rotas e paradas e constrói colunas ?dateTime e ?label (linhas 14-18). A primeira retorna o instante de chegada estimado no formato do tipo xsd:dateTime usando a função infmod:sumTime e, a segunda coluna, cria um texto explicativo. No final do WHERE mais externo há dois BINDs que constróem nós para os eventos de chegada e para o instante de tempo que o evento ocorrerá (linhas 41-46). Por fim, o CONSTRUCT cria o grafo com 195 eventos app:BusArrival (linhas 2-11). Esta consulta é configurada para executar em intervalos de 30 segundos. O módulo B2 utiliza uma consulta principal ao endpoint BLE, denominada Qrec (apresentada a seguir), com um SelectQueryParameterBinder adicional para obter as coordenadas dos usuários (?ulat e ?ulon na linha 19) e os destinos desejados (?uDestName, linha 33). Como esta consulta secundária retorna várias linhas de resultado (uma para cada usuário ?u), a quantidade de vezes que a consulta principal será executada depende da quantidade de usuários na base USNLE. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 # Qrec CONSTRUCT { ?u a foaf:Person . ?stop a bus:Stop . ?route a bus:Route . ?u app:recommendedBusStop ?pstop . ?pstop a app:BusStopRecommendation ; app:stop ?stop ; app:distance ?dist ; app:route ?route . } WHERE { # Variáveis resultantes da junção: # ?stop = ponto de onibus proximo da posicao atual do usuario # ?dist = distancia entre usuario e ?stop # ?route = rota de onibus que passa em ?stop e no ponto de # destino do usuario { SELECT ?stop (geofn:distanceFromDegrees(?lat, ?lon, ?ulat, ?ulon) as ?dist) WHERE { ?stop a bus:Stop ; geo:lat ?lat ; geo:long ?lon . } ORDER BY ?dist LIMIT 3 } { ?rs bus:stop ?stop ; bus:nextStop* ?rs2 . ?rs2 bus:stop/bus:name ?stopName ; bus:belongsToRoute ?route . FILTER (CONTAINS(LCASE(?stopName), LCASE(?uDestName))) } FILTER (?dist < 500) 196 37 BIND (URI(fn:concat( 38 "http://user-bus-contexts.com/resource/BusStopRecommendation/", 39 afn:substr(str(?u), infmod:getLastIndexOf("/", str(?u))), 40 afn:substr(str(?stop), infmod:getLastIndexOf("/", str(?stop))) 41 )) as ?pstop) 42 } Observe que esta consulta faz um produto cartesiano entre (1) a lista de paradas (?stop) e distâncias entre cada parada e o usuário (?dist), limitando o resultado às três paradas mais próximas (linhas 18-27); e (2) a lista de paradas de rota ?rs2 seguintes (bus:nextStop) à parada de rota de cada ?stop da lista (1) de forma que nome da parada (?stopName) associada a ?rs2 case com o destino desejado do usuário (?uDestName) (linhas 28-34). O produto cartesiano é filtrado para manter apenas distâncias menores que 500 metros (linha 35), o que pode reduzir a quantidade de paradas para dois, um ou até mesmo zero para o usuário em questão. No final da cláusula WHERE é construído um nó para representar a instância da recomendação (BIND, linhas 37-41) cujas triplas são definidas na cláusula CONSTRUCT (linhas 2-10). Esta consulta foi configurada para executar a cada 5 minutos. O módulo B3 reúne as recomendações de B2 e as chegadas de ônibus de B1 e gera possíveis participações app:isPassegerOf de usuários nestas chegadas. A consulta a B1 (Qarrivel2) é apenas um SPARQL DESCRIBE das instâncias de app:BusArrival e dos objetos de suas triplas, enquanto a consulta a B2 (Qrec2) é apenas um DESCRIBE das instâncias de pessoas e recomendações a elas associadas. Qrec2 executa a cada 5 minutos e que Qarrival2 a cada 15 segundos. Ambas são mostradas a seguir: 1 2 3 4 5 6 7 8 9 10 11 # Qarrival2 DESCRIBE ?ev ?o WHERE { ?ev a apv:BusArrival ; ?p ?o . } # Qrec2 DESCRIBE ?u ?pstop ?o WHERE { ?u a foaf:Person ; app:recommendedBusStop ?pstop . ?pstop ?p ?o . } A geração das participações é feita com a regra mostrada a seguir. Ela liga eventos app:BusArrival a usuários (?ev e ?u nas linhas 9-10) usando paradas (?stop, linhas 2 e 6) e rotas (?route, linhas 4 e 7) existentes tanto nas recomendações (?b, linhas 5-7) quanto nos eventos (?ev, linhas 1-4). 197 1 (?ev rdf:type apv:BusArrival), 2 (?ev apv:busStop ?stop), 3 (?ev apv:bus ?bus), 4 (?bus bus:route ?route), 5 (?u app:recommendedBusStop ?b), 6 (?b app:stop ?stop), 7 (?b app:route ?route) 8 -> 9 (?u apv:isPassengerOf ?ev), 10 (?u evt:playsRole ?ev) O módulo NEvt fica no topo de rede pois é responsável por reunir as participações em A1 e B3 e gerar notificações. É composto por quatro consultas a três endpoints: A1, B3 e BLE. Observando a Figura 30 verifica-se que as consultas feitas a A1 e B3 são iguais. Para não tornar as coisas mais complexas, elas pegam o grafo inteiro dos respectivos módulos usando consultas CONSTRUCT. As demais consultas são Qlow e Qhigh que pegam dados de baixa e alta taxa de atualização. Qlow descreve linhas, paradas, rotas e paradas de rotas de BLE, e Qhigh descreve os ônibus. Quantos aos intervalos, Qall de A1 executa a cada 10 minutos, Qall de B3 a cada 10 segundos, Qlow a cada 10 minutos e Qhigh a cada 10 segundos. NEvt também utiliza as regras listadas a seguir. O antecedente de R1 seleciona eventos que não sejam aniversários (linha 3), pessoas que participem destes eventos (linha 4) e data de início destes eventos (linha 5); verifica se esta data de início está no intervalo entre 1 e 180 dias contados da data atual (linha 6) e constrói um nó de notificação (associa um evento a uma pessoa, portanto, o URI da notificação deve considerar ambos). O consequente de R1 instancia o nó (app:Notification na linha 9), define evento associado a esta notificação (linha 10), o seu alvo (linha 11) e quantos dias restam para o evento ocorrer (linha 12). Quanto à linha 6, note que os built-ins curTime, dateDiff, le e ge são usados para representar a expressao "0 <= ev.beginning - curTime <= 180 dias". A regra R2 é similar, mas para o evento aniversário e, portanto, a participação é representada pelo predicado app:isBirthdayPersonsFriendOf. Por fim, R3 é similar, mas para eventos de ônibus que precisam modificar a comparação de tempo (linha 34) para cálculo em segundos. 1 2 3 4 5 6 7 # Cria notificacoes para eventos proximos (exceto aniversarios) R1: (?ev rdf:type evt:Event), noValue(?ev, rdf:type, apv:Birthday), (?p rdf:type foaf:Person), (?p evt:playsRole ?ev), (?ev evt:timeSpan ?t), (?t time:hasBeginning ?beg), curTime(?tm), dateDiff(?beg, ?tm, ?d), le(?d, 180), ge(?d, 0), localname(?p, ?pln), 198 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 makeNamedNode(?ntf, ?ev, "/Notification/", ?pln, "/", ?beg) -> (?ntf rdf:type evt:Notification), (?ntf evt:event ?ev), (?ntf evt:target ?p), (?ntf evt:remainingDays ?d) # Birthday: uma notificacao para cada amigo de aniversariante # (aniversariante nao precisa ser notificado) R2: (?ev rdf:type apv:Birthday), (?friend rdf:type foaf:Person), (?friend apv:isBirthdayPersonsFriendOf ?ev), (?ev evt:timeSpan ?t), (?t time:hasBeginning ?beg), curTime(?tm), dateDiff(?beg, ?tm, ?d), le(?d, 300), ge(?d, 0), localname(?friend, ?fln), makeNamedNode(?ntf, ?ev, "/Notification/", ?fln, "/", ?beg) -> (?ntf rdf:type evt:Notification), (?ntf evt:event ?ev), (?ntf evt:target ?friend), (?ntf evt:remainingDays ?d) # Notificacao sobre eventos de chegada de onibus R3: (?ev rdf:type evt:Event) (?p rdf:type foaf:Person), (?p evt:playsRole ?ev), (?ev evt:atTime ?t), (?t time:hasDateTime ?beg), curTime(?tm), timeDiff(?beg, ?tm, ?d), le(?d, 1800), ge(?d, 0), localname(?p, ?pln), makeNamedNode(?ntf, ?ev, "/Notification/", ?pln, "/", ?beg) -> (?ntf rdf:type evt:Notification), (?ntf evt:event ?ev), (?ntf evt:target ?p), (?ntf evt:remainingTime ?d) Aluno Teste Piloto 1 Aluno Teste Piloto 2 Aluno Pesquisa de Tese 1 Aluno Pesquisa de Tese 2 Aluno da Disciplina 1 Aluno da Disciplina 2 Aluno da Disciplina 3 Aluno da Disciplina 4 Aluno da Disciplina 5 Aluno da Disciplina 6 Aluno da Disciplina 7 Aluno da Disciplina 8 Aluno da Disciplina 9 Aluno da Disciplina 10 Aluno da Disciplina 11 Aluno da Disciplina 12 Aluno / Critérios 2 3 3 3 3 3 3 3 2 1 2 2 2 3 2 1 Configuração 2 2 3 3 1 1 3 1 3 2 2 3 2 2 2 2 Funcionamento 1 2 3 2 1 1 2 1 1 1 1 2 1 1 1 1 Domínio 2 3 1 2 2 2 2 2 3 3 1 1 2 3 2 3 Tecnologias 2 3 2 2 1 2 2 2 2 2 1 1 2 3 2 2 Lógica 2 3 3 2 1 2 3 2 1 2 2 2 2 2 2 3 SPARQL 3 1 2 3 1 1 2 1 1 1 1 1 0 2 1 1 SQL 3 2 3 3 2 2 2 2 3 3 3 3 1 2 2 3 URI e RDF 3 1 2 3 1 1 3 2 1 2 0 1 0 2 1 0 Grafos 2 3 2 3 1 2 2 2 1 2 1 1 0 1 1 1 Web Services 3 1 1 3 1 1 1 2 2 2 1 0 0 1 1 1 XML 3 2 2 3 2 1 2 3 2 3 0 1 0 2 2 2 Web (HTTP e HTML) 3 2 2 3 3 2 3 3 3 3 2 1 0 2 2 3 Programação 3 3 3 3 3 2 2 3 3 3 2 3 1 2 2 3 Dificuldade no experimento (0-3) Execução Nível de conhecimento (0-3) A1 A2 B1 B2 B3 A2x 4 4 4 3 3 2 4 4 4 4 3 3 4 3 4 3 4 3 2 4 4 4 4 3 3 3 4 2 2 2 1 2 2 2 1 1 1 2 2 2 2 1 2 4 4 4 4 1 1 3 3 3 3 2 2 3 4 4 4 3 0 2 2 2 2 1 1 2 2 2 2 2 0 2 2 2 2 3 2 4 4 4 3 2 1 1 1 1 2 2 2 3 3 3 3 3 Tempo (0-4) 199 Apêndice F – Questionário passado aos alunos e respostas na íntegra O significado dos números é definido na seção 5.2 (página 135). 200 Aluno Aluno Teste Piloto 1 Aluno Teste Piloto 2 Aluno Pesquisa de Tese 1 Aluno Pesquisa de Tese 2 Aluno da Disciplina 1 Aluno da Disciplina 2 Aluno da Disciplina 3 Aluno da Disciplina 4 Aluno da Disciplina 5 Aluno da Disciplina 6 Aluno da Disciplina 7 Aluno da Disciplina 8 Aluno da Disciplina 9 Aluno da Disciplina 10 Aluno da Disciplina 11 Aluno da Disciplina 12 Considerando a etapa que você demorou mais, a que você atribui a demora? Entendimento sobre o domínio e sobre a tecnologia. Uma vez compreendido as outras etapas ficaram mais fáceis. A demora se deu por ser a primeira etapa prática de aplicação. A partir deste momento, os conceitos, sintaxe e aplicação ficaram claros e as outras etapas foram concluídas mais rapidamente. Entendimento de como funcionam as regras. Verificação do modelo para formular regras e consutas. A etapa que mais demorei foi o A2 estendido (28 min). Atribuo 2 motivos à demora: 1- Considero a etapa do experimento com maior nível de dificuldade. 2- Tive dúvidas no entendimento da regra a ser adicionada em r3 (devido à utilização da superclasse evt:Event e da superpropriedade evt:playsRole, em vez da classe apv:BusArrival e da propriedade apv:isPassengerOf). As etapas que demorei mais foram as primeiras porque estava menos familiarizada com a atividade e acabava não verificando endpoint e sparqlserver antes de iniciar. Além disso, não tinha entendido de início que para uma etapa executar dependia da etapa anterior estar executando. Eu fiquei um pouco insegura durante o exercício porque eu não consegui visualizar as classes do módulo B1. Por causa disso, eu parei o exercício após a execução do módulo B3. Como eu ainda não tinha feito o A2 estendido e não tinha usado todas consultas e regras do arquivo "ajuda.txt", achei que estava fazendo algumas coisa errada. A etapa A1, pois a porta 40000 deixou de funcionar e demorei para descobrir o que estava acontecendo. Acabei usando a porta 44000. Não tinha lido os txt de ajuda Configuração do ambiente não estava OK e falta de atenção para deixar ops endpoints mapeados (portas), executando da forma correta e síncrona. Ficou demorado porque tive que entender o que realmente era feito para fazer funcionar. A primeira etapa para mim foi a mais complicado por não conhecer bem o experimento. Apos avançar nas etapas pude entender melhor a proposta e tive que voltar para rever os exercicios anterios. Isto comprometeu a medição do tempo. Alem disso o servidor web começou a travar e não pude fazer mais testes para entender melhor a aplicação. Demora devido a nao entender as msgs de erro que sao emitidas após a execuçao do XML, apesar de perceber depois que os erros eram bobos. Como só consegui resolver o erro "bobo" do B3 no ultimo dia de entrega, nao consegui evoluir para tentar estender e testar o "A2 estendido", porque minhas execuções pararam no B1, sem acesso a http://expedit.dyndns.info:3030/sparql . Ainda tentarei resolver e enviar fora do prazo. Na etapa A1, demorei a entender que as consultas já estavam feita, era só copiar e colar. Mas isso foi bom, porque me forçou a pensar um pouco. Nas outros houve entendimento mais superficial. Na etapa A2 estendido, demorei mais para entender as modificações necessárias. A minha demora é diretamente proporcional ao meu desconhecimento destas tecnologias, ou seja tive de ler e reler o material para entender como as “coisas” se conectavam. Complexidade da etapa A2 estendido, pois havia necessidade de criar uma consulta que não estava contemplada na no arquivo ajuda.txt. Além disso, os slides não tinham nenhuma clareza sobre o que fazer nessa etapa. 201 Aluno Aluno Teste Piloto 1 Aluno Teste Piloto 2 Aluno Pesquisa de Tese 1 Aluno Pesquisa de Tese 2 Aluno da Disciplina 1 Aluno da Disciplina 2 Aluno da Disciplina 3 O Módulo de Inferência tem o objetivo de fornecer um endpoint de dados derivados para outros consumidores de forma que consultas, ontologias e regras possam ser reutilizadas de forma transparente, ou seja, não precisem ser reescritas toda vez que forem necessárias. Você acha que o objetivo foi atendido? Identifique dificuldades encontradas, pontos positivos e negativos. O objetivo foi entendido, entretanto a construção de regras depende não somente de conhecimento sobre a tecnologia como também sobre o domínio, seria necessário gastar algum tempo para ter domínio sobre a ferramenta e sobre o que é possível fazer. No meu conhecimento limitado sobre as tecnologias envolvidas (webservices, uri, RDF e SPARQL) acredito que o objetivo tenha sido atendido. Depois de configurado e executado, o módulo de inferência certamente é capaz de simplificar consultas para o usuário final, que de outra forma seriam complexas. As inferências também permitem que um modelo geral seja extendido automaticamente para casos mais específicos, sem retrabalho. Houve uma dificuldade inicial em entender a sintaxe, mas depois de apenas um exemplo já foi muito fácil prosseguir nas etapas. Os casos de uso propostos foram apropriados e certamente ilustraram a importância da abordagem. Visto minha pouca experiência com trabalhos relacionados ao tema, fica difícil apontar pontos positivos e negativos comparativos, mas a facilidade de utilização e resultado sugerem que a abordagem é funcional e efetiva. Sim. Existe a dificuldade inicial de entender e analisar os dados gerados. Porém o objetivo é atendido tornando a experiencia cada vez mais facil com a reutilização. Portanto existe a dificuldade inicial, porém o objetivo é atendido permitindo a reutilização. Acho que o objetivo foi atendido. O fácil entendimento, configuração e execução do XML são pontos positivos. Encontrei dificuldade na parte de definição das regras JENA, por falta de experiência no assunto, dificuldade esta que foi diminuindo durante a execução das etapas do experimento. Acho que foram atendidos sim. Também achei a execução dos módulos e a visualização bem simples e intuitiva. A parte mais crítica, na minha opinião, foi montar os arquivos xml, mas acredito que foi por falta de conhecimento meu, principalmente em turtle, rdf, jena, devido às configurações e termos que deveríamos saber do que pela sintaxe em si. Não entendi muito bem como os "endpoints" estão interligados. Sim, acho que o Módulo de Inferência pode ajudar na reutilização de consultas e regras de forma transparente. Dificuldades encontradas: - Dúvidas na manipulação do arquivo xml. Pontos Positivos: - Reutilização de informações de forma transparente, permitindo que várias aplicações consultem a mesma informação. Pontos Negativos: - As pessoas precisam ter conhecimento de RDF e SPARQL para que possam utilizar esses dados e manipular os arquivos. Acho que no início a curva de aprendizado é grande. Sim, acho que o objetivo foi atingido. Pontos positivos: - o módulo permite uma configuração bastante detalhada e flexível - não tenho como avaliar com precisão, mas aparentemente tem boa performance, é rápido - portabilidade, pois está implementado em Java - permite a criação de aplicações que utilizam as tecnologias da Web Semântica com os benefícios da programação modular Ponto negativo: - para criar uma aplicação é necessário ter conhecimentos de SPARQL (alto), RDF (alto), regras (alto), grafos (médio), modelagem conceitual/ontologia (médio) 202 Aluno da Disciplina 4 Aluno da Disciplina 5 Aluno da Disciplina 6 Aluno da Disciplina 7 Aluno da Disciplina 8 Aluno da Disciplina 9 Aluno da Disciplina 10 Aluno da Disciplina 11 Acredito que o objetivo foi atingido. Dentro do exercício proposto a única coisa ruim é ter que ficar executando diversos programas, mas acredito que em um cenário real estes endpoints sejam somente URLs diferentes em um mesmo sistema. Sim, foi atendido. Com a "topologia" distribuída e as execuções de forma modular foi fácil enxergar a reutilização que o Framework fornece. O Objetivo foi atingido. Qualquer mudança ou inserção basta alterar o xml e recarregar. A grande dificuldade e aprender a estrutura da linguagem. A segunda seria identificar a estrutura de dados na aplicação. Aprender a construir as consultas e regras para mim foi complicado. Pontos possitivos: O material está bem completo sobre o assunto . O exercicio de completar consultas e regras é muito legal aprendi bastante sobre o tema. Sim, parece que o objetivo foi atendido, mas não tenho grande experiencia sobre o tema o que me dificulta avaliar de uma forma mais crítica e contribuir mais para este experimento. Acho que foi atingido. As dificuldades encontrados já foram mencionadas nas respostas acima. Apesar de ainda não compreender a profundidade do problema, acho que o módulo cumpriu sua função. Mas acho que o passo fundamental seria uma interface gráfica para escrever as regras e configurar o xml, para que a ferramenta possa ser úportil a mais gente. Mesmo que isso prejudique a flexibilidade, aumentaria em muito a utilidade do módulo. Achei uma ótima ideia a reutilização de dados gerados. A minha dificuldade em resolver a proposta de unir os arquivos em um só que foi questionada. Acho que sim, como qualquer sistema deve ser testado e retestado em situação real. Sim, acredito que o objetivo foi atendido, pois esse endpoint pode ser utilizado por outras aplicações, ou até mesmo para versões da mesma aplicação para outras plataformas, como plataformas de Smartphones por exemplo. Aluno da Disciplina 12 A maior dificuldade foi entender o exercício por intermédio dos slides, que repito, não estavam nem um pouco claros. Depois de entendido o exercício, foi fácil adequar as consultas e regras do ajuda.txt à aplicação. 203 Aluno Aluno Pesquisa de Tese 1 Aluno Pesquisa de Tese 2 Aluno da Disciplina 1 Aluno da Disciplina 2 Aluno da Disciplina 3 Aluno da Disciplina 4 Aluno da Disciplina 5 Aluno da Disciplina 6 Aluno da Disciplina 7 Aluno da Disciplina 8 Aluno da Disciplina 9 Aluno da Disciplina 10 Aluno da Disciplina 11 Aluno da Disciplina 12 Você considera que a documentação (apresentação em PDF) foi suficiente para o entendimento do Módulo de Inferência e do domínio da aplicação? Comente sua resposta em poucas palavras, falando sobre os pontos positivos e/ou negativos que você tenha identificado. Sim. A documentação mostra uma visão geral das tecnologias mostrando exemplos simples e mais avançados de cada uma. Talvez para uma pessoa que não tenha nenhum conhecimento sobre sparql, rdf, owl seja necessária uma documentação mais explicativa que mostre o que é cada tecnologia e como funciona. Considero que a documentação foi suficiente. Há uma apresentação clara e concisa do fundamento teórico, da arquitetura do Módulo de Inferência e dos cenários/etapas da experimentação. O domínio da aplicação ficou bem claro pela documentação, porém acho que o Módulo de Inferência poderia ser um pouco mais explicado. Depois dos exercícios você tem uma noção geral do módulo, mas eu não acredito que tenha entendido ele por completo. Acredito que pra se entender por completo tem que ter um conhecimento mais sólido do que eu tenho em rdf, turtle, owl e afins. Acho que a documentação está bem completa. Pontos positivos: - Auxilia a realização das tarefas e contextualiza o exercício; e - Explica a estrutura e os componentes do Módulo de Inferência. Pontos negativos: - A existência de muitos conceitos associados ao módulo de inferência dificultou um pouco o entendimento do exercício. A apresentação está muito boa. Como não tinha utilizados raciocinadores, a parte das regras foi bastante complexa para mim. Talvez poderia ter mais exemplos de regras. Havia também muitos modelos conceituais e acabou ficando um pouco difícil saber quais eram meros exemplos e quais eram de fato modelos das bases RDF. Acredito que para uma pessoa que já conhece essas tecnologias fica fácil de usar. Porém leigos devem encontrar dificuldades. Não ficou muito claro o objetivo de cada etapa e o domínio me pareceu muito complexo para um "Hello World" A apresentação ficou muito boa, porém talvez fosse melhor abrir um dos arquivos XML mostrando onde cada coisa "acontece" (acesso às base, endpoints, consultas, regras, etc). Em relação aos conceitos a apresentação foi suficiente. O material é muito bom. Aprendi bastante sobre o assunto. A sugestão seria a inclusão de referencias bibliográficas sobre alguns temas trabalhados na apresentação. Para uma pessoa que não tem familiaridade com RDF, LOD, etc. esta documentação não seria suficente. Na verdade seria necessário um treinamento. Precise ler, reler, ler, reler, mas ao passo que testava os modulos a leitura ia tornando-se melhor compreensivel. Acredito que isto se deva ao fato da minha quase nula experiencia com os temas. Sim, a documentação está bem completa. Percebi duas coisas: em alguns grafos, onde se lê app: deveria estar apv: ; além disso, no slide 134, o primeiro users deve ser trocador por stop. O material foi suficiente sim, mas como o domínio é relativamente complexo, os diagramas foram fundamentais. Não. A parte de conteúdo sobre a disciplina estava claro. Porém, os exercícios não estavam claros nos slides. Os slides sobre o exercicio estavam muito confusos, não entendi o que fazer, mesmo lendo diversas vezes. Precisei perguntar pessoalmente para entender o que tinha que fazer no trabalho. Nos slides não está claro que temos que utilizar consultas e regras do arquivo ajuda.txt.
Documentos relacionados
Convenente: Fundação Padre Urbano Thiesen
ontologias OWL OWL (Web Ontology Language) é uma linguagem ontológica, composta por três versões com níveis de expressividade diferentes, desenvolvida pelo W3C (World Wide Web Consortium). A constr...
Leia maisRepresentação do conhecimento e modelagem conceitual de
Figura 6 – Arquitetura da Web Semântica ............................................................................................ 36 Figura 7 – Exemplo de código XML ...............................
Leia mais