CRISTIANO EXPEDITO RIBEIRO MÓDULOS DE INFERÊNCIA NA NUVEM DE DADOS LIGADOS PARA APOIAR O DESENVOLVIMENTO DE APLICAÇÕES RIO DE JANEIRO

Tamanho: px
Começar a partir da página:

Download "CRISTIANO EXPEDITO RIBEIRO MÓDULOS DE INFERÊNCIA NA NUVEM DE DADOS LIGADOS PARA APOIAR O DESENVOLVIMENTO DE APLICAÇÕES RIO DE JANEIRO"

Transcrição

1 CRISTIANO EXPEDITO RIBEIRO MÓDULOS DE INFERÊNCIA NA NUVEM DE DADOS LIGADOS PARA APOIAR O DESENVOLVIMENTO DE APLICAÇÕES RIO DE JANEIRO 2012

2 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

3 R484 Ribeiro, Cristiano Expedito Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. / Cristiano Expedito Ribeiro 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

4

5 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.

6 Resumo RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações 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, 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

7 Abstract RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações 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, 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

8 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 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 Figura 3. Diagrama de Venn mostrando a validade da fórmula C D C D = Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações imprevistas no TBox Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005) Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003) 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 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) Figura 9. Diagrama de atividades do módulo de inferência Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader Figura 13. Hierarquia mais externa dos elementos XML de configuração Figura 14. Elementos XML para configuração de carregadores e substituidores de variáveis (binders) Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD Figura 17. Lista de Resultados na aplicação protótipo desenvolvida Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o mapeamento entre conceitos Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o mapeamento entre conceitos Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento

9 Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas Figura 23. Diagrama das ontologias de tempo e eventos utilizadas 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 Figura 26. Ontologia de transporte por ônibus Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus Figura 28. Rede social dos usuários do endpoint USNLE Figura 29. Estrutura interna do endpoint BLE 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) Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b) Figura 33. Histogramas das respostas globais Figura 34. Resultados do teste presencial com alunos Figura 35. Teste remoto com alunos em pesquisa de tese Figura 36. Resultados do teste remoto com alunos da disciplina 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) Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita) Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath Figura 40. Estrutura interna do endpoint BLE Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto

10 Lista de Quadros e Tabelas Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN, C., 2004) Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010) Quadro 3. Lista de expressividade de diversas DLs atuais Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam Quadro 6. Comparativo das arquiteturas Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008) Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011) Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos Tabela 11. Exemplos de resultados da consulta ao M4: atraso pequeno (acima) e pouco mais significativo (abaixo) Quadro 12. Datas comemorativas utilizadas no endpoint CDE com as respectivas classes e datas Quadro 13. Localização atual e destino desejado dos usuários do USNLE Quadro 14. Consultas e regras removidas em cada módulo; competências testadas e grau de dificuldade para cada etapa Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em RAs (2010)

11 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

12 Sumário 1 Introdução Motivação Contextualização do Problema Problema específico Objetivo Contribuição Estrutura da dissertação Referencial Teórico Computação ubíqua e contexto: definições Aquisição, classificação e modelagem de contexto Aquisição de contexto: perfis, sensores, interpretadores e provedores Classificações de contexto Classificações de aplicações cientes de contexto Comparações entre modelos de contexto Ontologias de modelagem de contexto Web Semântica e Dados Ligados Conceitos básicos Lógica de Descrição (DL) Web Ontology Language (OWL) Trabalhos de publicação em LOD Trabalhos relacionados Frameworks para aplicações cientes de contexto Arquiteturas para integração de dados na Web LOUD Linked Open Ubiquitous Data Introdução Arquitetura LOUD Objetivos Estrutura Escopo do trabalho: o Módulo de Inferência Estrutura... 73

13 3.3.2 Implementação Configuração Cenários de Aplicação Cenário 1: informação sobre hidrantes durante um incêndio Modelagem e construção da camada de dados Camada de inferência para integração das bases Aplicação de consumo e considerações Cenário 2: alertas sobre chuvas e escorregamento de terra Domínio da aplicação e modelagem Camada de dados e sensoriamento Camada de inferência Discussão Cenário 3: notificação sobre eventos sociais e chegadas de ônibus Domínio da aplicação e modelagem Camada de dados e sensoriamento Camada de inferência Visualização das notificações em navegador Web Experimentos e Resultados Formato do experimento Avaliações dos alunos Alguns dados quantitativos Avaliações qualitativas Considerações finais Retrospectiva Estudo de viabilidade e experimentos realizados Contribuições e aspectos positivos Problemas e limitações Trabalhos futuros Referências Apêndices Apêndice A Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE)

14 Apêndice B Cenário 2: implementação da geração de coordenadas e mapeamento D2R para User Locations Endpoint (ULE) Apêndice C Cenário 2: implementação da configuração dos módulos Apêndice D Cenário 3: implementação, mapeamento e configuração dos módulos para Bus Locations Endpoint (BLE) Apêndice E Cenário 3: Configuração dos módulos da camada de inferência Apêndice F Questionário passado aos alunos e respostas na íntegra

15 15 1 Introdução 1.1 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 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 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 (LOD 1 ) 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 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 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 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 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 Mobilidade baixa Computação Pervasiva Computação Pessoal tradicional Computação Ubíqua Computação Móvel Mobilidade alta 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 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. por Naudet: (BECKER; NICKLAS, 2004) Uma outra definição recente encontrada na literatura para ciência de contexto é dada 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 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 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 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 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 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 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 27 Tipo Primário Secundário Localização, Identidade, Atividade, Tempo Obtidos dos primários Obtenção Direto Indireto Sensed (sensores físicos) Defined (definido pelo usuário) Deduced (interpretadores de contexto) Contexto Visibilidade Pública Privada Obtido por qualquer pessoa Necessário permissão para acessar Alta Fornecido por sensores Taxa de atualização Média Fornecido por humanos Baixa Perfis, mapas e guias 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 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 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 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 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 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 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 Abordagens e requisitos Heterogeneidade Mobilidade Relacionamentos Temporalidade Imperfeição Raciocínio Usabilidade Eficiência 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. Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010) Object-role + ~ ~ + ~ ~ + ~ Espacial ~ + ~ + ~ - ~ + Ontológico ~ - 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 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 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 FOAF 2, 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:

35 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 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 PIM 4 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: 4 W3C PIM: 5 RELATIONSHIP A vocabulary for describing relationships between people:

37 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 Internet 6, este trabalho utilizará um subconjunto dela na seção (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:

38 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 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: 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 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 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: foaf: <http://xmlns.com/foaf/0.1/>. greco: <http://greco.ppgi.ufrj.br/resource/professor/>. 3 greco:adrianavivacqua 4 foaf:name "Adriana Santarosa Vivacqua" ; 5 foaf:homepage <http://dcc.ufrj.br/~avivacqua/>. 1 <?xml version="1.0" encoding="utf-8"?> 2 <rdf:rdf 3 xmlns:foaf="http://xmlns.com/foaf/0.1/" 4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 5 <rdf:description 6 rdf:about= 7 "http://greco.ppgi.ufrj.br/resource/professor/adrianavivacqua"> 8 <foaf:name>adriana Santarosa Vivacqua</foaf:name> 9 <foaf:homepage rdf:resource="http://dcc.ufrj.br/~avivacqua/"/> 10 </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 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 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 Update 8 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 8 SPARQL Update -

41 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 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 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 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 ALUE 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 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 I = (C D) = C I D I I ( r.c) = {x Δ I Existe algum y Δ I tal que (x, y) r I e y C I } I ( r.c) = {x Δ I Para todo y Δ I, se (x, y) r I então y C I } 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 C I D I, 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 a I C I, e um modelo de um ABox se é um modelo de todos

44 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, 1 I ), onde: Δ1 I = {JOHN I, MARY I } 1 I = { Person1 I = {JOHN I, MARY I }, Male1 I = {JOHN I }, Father1 I = {JOHN I }, haschild1 I = {(JOHN I, MARY I )} } é um modelo para a base de conhecimento formada pelo TBox: Father Person Male haschild.person e pelo ABox: Person(JOHN) Person(MARY) Male(JOHN) haschild(john, MARY) Esta outra interpretação I 2 = (Δ 2I, 2 I ) também é um modelo para este mesmo KB: Δ2 I = {JOHN I, MARY I } 2 I = { Person2 I = {JOHN I, MARY I }, Male2 I = {JOHN I }, Father2 I = {JOHN I }, haschild2 I = {(MARY I, MARY I )} } 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 Problemas de inferência Na seção 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 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 C I (I é um modelo de C em relação a K ) e escreve-se K C ; Subsumption 9 : C é subconjunto de D (C D) em relação a K se C I D I 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, C I = D I 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 C I D I = 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 a I C I 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 (a I,b I ) 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: (i) C D C D (subsumption) (ii) C D (C D) e ( C D) (equivalência) (iii) (C D) C D (disjunção) 9 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 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 = 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 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 (E), 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. funções: A composição de relações permite fazer um processo similar ao de composição de 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 ALUE e S é equivalente à ALC R+, Portanto SROIQ é ALC R+ 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 48 Quadro 3. Lista de expressividade de diversas DLs atuais. Descrição Notação Nomenclatura Tipo Conceito universal AL Construto Conceito vazio AL Construto Negação atômica 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 E Construto Negação ou complemento C C Construto União de conceitos C D U Construto Transitividade de relação Tr(r), r + r R + Axioma Restrições de número n r, n r N Construto Restrições de número qualificadas n r.c, n r.c Q Construto Propriedades funcionais 1 r F Construto Inversibilidade de relação r I Construto Equivalencia entre relações r s, r s s r H Axioma Hierarquia de relações r s H Axioma Inclusão de relações complexas (cadeia ou composição de relações) r 1 r 2 s R Axioma Reflexividade local r.self R Construto Reflexividade global r.self R Construto Nominals (indivíduos no TBox) {a 1, a 2,..., a n} O Construto Tipos de dados - (D) -

49 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(t 1,..., t n ), onde t 1 a t n 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 B 1 a B n são átomos; H é dita a cabeça ou consequente da regra e B 1 a B n é 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) (ii) hasaunt(x, y) hasparent(x, z), hassibling(z, y), Female(y) 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 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 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) (b) father(abel, ADAM) father.{cain}(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 KB 10 : 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

52 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ão- DL-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 53 a { } a { R.{c}, C, R.B, A } R R b { R.{c}, C } R b { R.{c}, C } { R.B, A } R R R R y { C, R.{c}, R.B, A } c { R.B, A } R c { R.B, A } C A R R R x { 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) 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 Z X como o conjunto de construtos/axiomas suportados por uma dada versão X da OWL, pode-se dizer que Z OWL-Lite Z OWL-DL Z OWL2-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 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: : <http://exemplo.com/>. rdfs: <http://www.w3.org/2000/01/rdf-schema#>. owl:<http://www.w3.org/2002/07/owl#>. 4 5 :Person a owl:class. 6 :Male a owl:class. 7 :haschild a owl:objectproperty. 8 9 :Father a owl:class ; 10 owl:equivalentclass [ 11 a owl:class ; 12 owl:intersectionof ( :Person :Male [ 13 a owl:restriction ; 14 owl:onproperty :haschild ; 15 owl:somevaluesfrom :Person 16 ] ) 17 ]. 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 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 C 1... C n [] rdf:type owl:class ; owl:intersectionof (C1... Cn). C 1... C n [] rdf:type owl:class ; owl:unionof (C1 Cn). C [] rdf:type owl:class ; owl:complementof C. {a 1, a n} [] rdf:type owl:class ; oneof (a1 an). OWL DL/Lite* OWL DL OWL DL OWL DL P.C P.C P.{a} n P n P n P.C n P.C n P.D n P.D [] rdf:type owl:restriction; owl:onproperty P ; owl:allvaluesfrom C. [] rdf:type owl:restriction; owl:onproperty P ; owl:somevaluesfrom C. [] rdf:type owl:restriction; owl:onproperty P ; owl:hasvalue a. [] rdf:type owl:restriction; owl:onproperty P ; owl:mincardinality n. [] rdf:type owl:restriction; owl:onproperty P ; owl:maxcardinality n. [] rdf:type owl:restriction; owl:onproperty P ; owl:minqualifiedcardinality n ; owl:onclass C. [] rdf:type owl:restriction; owl:onproperty P ; owl:maxqualifiedcardinality n ; owl:onclass C. [] rdf:type owl:restriction; owl:onproperty P ; owl:minqualifiedcardinality n ; owl:ondatarange D. [] rdf:type owl:restriction; owl:onproperty P ; owl:maxqualifiedcardinality n ; owl:ondaterange D. OWL Lite OWL Lite OWL DL OWL DL OWL Lite (n=0,1) OWL DL OWL Lite (n=0,1) OWL 2 DL OWL 2 DL OWL 2 DL OWL 2 DL R [] owl:inverseof R. OWL Lite owl:thing OWL Lite owl:nothing OWL Lite

56 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 C 1 C 2 C1 rdfs:subclassof C2. OWL DL/Lite* C 1 C 2 C1 owl:equivalentclass C2. OWL DL/Lite* P 1 P 2 P1 rdfs:subpropertyof P2. OWL DL/Lite* P 1 P 2 P1 owl:equivalentproperty P2. OWL DL/Lite* C 1 C 2, C 1 C 2 C1 owl:disjointwith C2. OWL DL C 1... C n [] rdf:type owl:alldisjointclasses ; owl:members ( C1.. Cn). P 1... P n [] rdf:type owl:alldisjointproperty ; owl:members ( P1.. Pn). OWL 2 DL OWL 2 DL C C 1... C n e C i C k, 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 P 1... P n P P owl:propertychainaxiom (P1... Pn). OWL 2 DL P 1 P 2 P1 owl:equivalentproperty P2. OWL Lite {a 1} {a 2} ou a 1 = a 2 a1 owl:sameas a2. OWL Lite {a 1} {a 2} ou a 1 a 2 ou {a 1} {a 2} a1 owl:differentfrom a2. OWL Lite C(a) a rdf:type C. OWL Lite P(a,b) a P b. OWL Lite

57 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), GeoNames 11 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 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 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 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 Context- Aware 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 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 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 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 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 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 65 Quadro 6. Comparativo das arquiteturas. Arquitetura Hydrogen Hofer et al. (2002) CASS Fahy & Clarke (2004) CMF Korpipaa et al. (2003) CORTEX Biegel & Cahill (2004) SOCAM Gu et al. (2005) CoBra Chen, H. et al. (2004) Padrões abertos W3C? Apenas XML Não Apenas RDF Não RDF(S), OWL RDF(S), OWL Disponível na Web? Não, mas troca informações via TCP/IP Não, mas troca informações via redes sem fio Não, pois não é focado na infraestrutura Não Não, comunicação via API RMI do Java. Não menciona Organização Três camadas; peerto-peer Centralizado Centralizado Em rede, hierárquica e descentralizado Três camadas; servidor centralizado Agentes (brokers); federação de brokers Modelagem e processamento de contexto Orientado a objetos; interpretação e agregação de dados Banco relacional para dados e regras; motor de inferência RDF, lógica fuzzy e crisp, redes Bayesianas Banco relacional; redes Bayesianas, CLIPS RDF, ontologias e regras de inferência RDF, ontologias e regras de inferência Descoberta de recursos Não Não Sim Sim Sim Não Dados de contexto históricos Não Sim Não Sim Sim Sim itransit Lee, Meier (2009) Almeida et al. (2009) COSAR Riboni & Bettini (2011) LOUD RDF, OWL RDF, OWL RDF, OWL RDF(S), OWL, SPARQL Sim, API própria Sim, OSGi Não, comunicação apenas entre módulos Sim, com protocolos HTTP e SPARQL Arquiteturas para integração de dados na Web Camadas, federação Camadas, centralizado Camadas, centralizado Camadas, em rede, hierárquica e descentralizado RDF, ontologias, orientado a objetos RDF, ontologias e regras de inferência dinâmicas RDF, ontologia OWL-DL e estatística RDF, ontologias e regras de inferência (outros serão possíveis) Não Sim Não Não, mas possível futuramente Não Não Sim Sim 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

66 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 67 3 LOUD Linked Open Ubiquitous Data 3.1 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 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 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 Observe que as

68 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 mashups também poderiam compor esta camada. Aplicação Aplicação Aplicação Aplicação Legenda: Fluxo de dados (exceto de configuração): Inferência Publicação Armazenamento Processamento Consumo Publicação Armazenamento Processamento Consumo Publicação Armazenamento Processamento Consumo Publicação Armazenamento Processamento Consumo Consultas no sentido inverso das setas Dados de resposta no sentido direto Dados Endpoint Base LOD Endpoint Base LOD Sensoriamento 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 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 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 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 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 é 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 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 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 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 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 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 Linked Data Cloud -

74 74 Interface Web Motor de Inferência Ontologias & Regras SPARQL Endpoint Base de Armazenamento Legenda: Direção do fluxo de triplas RDF 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) 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 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 O resultado das consultas de cada carregador é guardado por cada um para posterior inserção na base de armazenamento intermediário 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 76 inferências. Por este motivo apenas bases em memória principal estão sendo consideradas neste trabalho 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 ) 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 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 C 2n, onde C i é equivalente a C j, 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 C 1 a C 3n, com C i equivalente a C i+1 equivalente a C i+2, e i = {1, 4, 7,... } tem-se 3n regras contra 2n axiomas 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 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 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 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 (G PUB ), que é vazio na primeira iteração, e retorna o grafo inicial (G 0 ) construído conforme a política de atualização. Em seguida, a segunda atividade reúne os resultados das consultas dos carregadores (G RC [i]) em um grafo G RC, onde a quantidade de operações de união depende da quantidade de carregadores existentes e, por fim, G 0 é adicionado a G RC. A próxima atividade constrói o chamado grafo antes da inferência (G AInf ) a partir dos grafos G PUB e G RC, 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 (G PUB ) a partir de G PUB, G RC e G INF e, finalmente, a atualização do endpoint. O algortimo pode ser visto a seguir: 1 G 0 := get_initial_graph(g PUB ) 2 G RC := {} 3 Para cada carregador i faça G RC := G RC G RC [i] 4 G RC := G RC G 0 5 G AInf := get_graph_before_reasoning(g PUB, G RC ) 6 G INF := do_reasoning(g AInf ) 7 G PUB := get_publishing_graph(g PUB, G RC, G INF ) 8 update_endpoint(g PUB ) Nota-se que, se a política de atualização for eficiente, como por exemplo, sempre retornar um grafo vazio ou já existente (G PUB, G RC e G INF, nas etapas grafo inicial, grafo antes

80 80 da inferência e grafo para publicação, respectivamente), os pontos que poderiam gerar gargalos são: a) Criação do G RC (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 G PUB. O fator determinante é a forma escolhida para atualização do endpoint (discutida na seção ) 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 e ). 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 SNORQL 13. 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 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 : getinitialgraph(g PUB ) retorna o grafo inicial (linha 1); getprereasoninggraph(g PUB, G RC ) retorna o grafo que será passado ao motor de inferência (linha 5); e getpublishinggraph(g PUB, G RC e G INF ) 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 G PUB. 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 G PUB (vide seção ). 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 G INF, respectivamente.

82 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 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/ que representam as linhas 1, 2-4, 5, 6, 7 e 8 do algoritmo da seção , 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. 84

85 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 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 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 Descrição Origem Regra curtime(?tm) Coloca xsd:datetime atual em?tm. InfMod Regra makenearestdatetime(?dtin,?dtout) Calcula próxima ocorrência da data de entrada, ou seja, mantém dia e mês e ajusta o ano. InfMod Regra datesum(?date_in,?days,?date_out) Adiciona?days dias à data de entrada, colocando o valor na data de saída. InfMod Regra datediff(?date1,?date2,?days) Subtrai?date1 -?date2 retornando a diferença em dias em?days. InfMod Regra novalue(?s,?p,?o) Retorna true se a tripla não está presente na base. Jena Regra notequal(?x,?y) Retorna true se?x!=?y Jena Regra le(?x,?y) Retorna true se?x <=?y Jena Regra ge(?x,?y) Retorna true se?x >=?y Jena Regra localname(?uri,?lname) Coloca o localname de?uri em?lname. Ex. => Fulano InfMod Regra makenamednode(?new_node, <strlist>) 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)?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 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 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 usando o protocolo SPARQL sobre HTTP. Uma 14 Protégé: a free, open source ontology editor and knowledge-base framework

89 89 interface web SNORQL sempre estará disponível em 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> <name> : texto <prefixes> <Prefix> <prefix> : texto <namespace> : URI <Prefix>... <clock baseuri= url > <resourcebaseuri> : URI <updatepolicy class= ClearDataPolicy /> <loaders> <PullLoader> <PullLoader>... <inference> <reasoner> : PELLET/JENA <ontology> : arquivo/url... <rules> : regras do Jena <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 90 <PullLoader> <description> : texto <endpoint> : URL <queryconfigs> QueryData <query> : SPARQL <description> : texto <interval> : número <binder class=... > QueryData... <binder class= DefaultQueryParameterBinder > <binder class= SelectQueryParameterBinder > <description> : texto <endpoint> : URL <query> : SPARQL <binder class= TimeFrameQueryBinder > <framemillis> : número <binder class= OffsetSplitterQueryParameterBinder > <description> : texto <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 <query> 2 <![CDATA[ 3 PREFIX a: <http://dominio/resource/> 4 CONSTRUCT {... } 5 WHERE { FILTER (?y >= 18 &&?t <= 70) 8 } 9 ]]> 10 </query> 11 <query> 12 PREFIX a: <http://dominio/resource/> 13 CONSTRUCT {... } 14 WHERE { FILTER (?y >= 18 &&?t <= 70) 17 } 18 </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 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> <query> 10 <![CDATA[ # PREFIX omitido 11 CONSTRUCT {... } 12 WHERE {... } 13 ]]> 14 </query> </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 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 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 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 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 , também conhecida como Kettle, tanto por ser uma ferramenta popular e aberta quanto por já existirem plugins específicos, desenvolvidos no projeto LinkedDataBR 17, 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 Virtuoso 18, 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 Pentaho Data Integration LinkedDataBR Virtuoso -

95 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 LinkedGeoData 20 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) LinkedGeoData.org: Adding a spatial dimension to the Web of Data Basic Geo (WGS84 lat/long) Vocabulary -

96 96 foaf:organization lgdo:firehydrant geo:spatialthing geo:lat, geo:long hid:obm hid: obmresponsavel hid:hidrantedecoluna hid:vazao xsd:float lgdo:firestation owl:equivalentclass hid:datadocadastro hid:endereco xsd:datetime xsd:string lgdo:locality hid:situacaooperacional hid:situacaooperacional hid:bairro hid:bairro hid:cidade hid:cidade hid:operante owl:equivalentclass yago: Neighbourhoods InRio_(city) owl: equivalentclass lgdo:city 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 OpenStreetMap 22, 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 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 DESCRIBE?s?s1 2 FROM <http://www.viconsaga.com.br/cbmerj/pgorh/graph> 3 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 -

97 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 Offset- SplitterQueryParameterBinder (veja seções e 3.3.3) utilizando as consultas Qcontagem (contagem total de resultados) e Qamenity a seguir: 1 # Qcontagem: contagem do total de resultados 2 SELECT (count(?uri) as?c) 3 FROM <http://linkedgeodata.org> 4 WHERE { 5?uri a lgdo:amenity ; 6 geo:lat?lat ; 7 geo:long?lng ; 8 rdfs:label?nome ; 9 a?c. 10 # Delimita um retângulo na superfície 11 FILTER (?lat < &&?lat > &&?lng > &&?lng < &&?C!= lgdo:amenity &&?C!= lgdo:node) 14 } # Qamenity: executada várias vezes alterando apenas valor do?offset 17 CONSTRUCT { 18?uri a lgdo:amenity ; 19 geo:lat?lat ; 20 geo:long?lng ; 21 rdfs:label?nome ; 22 a?c. 23 } 24 FROM <http://linkedgeodata.org> 25 WHERE { 26?uri a lgdo:amenity ; 27 geo:lat?lat ; 28 geo:long?lng ; 29 rdfs:label?nome ; 30 a?c. 31 # Delimita um retângulo na superfície 32 FILTER (?lat < &&?lat > &&?lng > &&?lng < &&?C!= lgdo:amenity &&?C!= lgdo:node) 35 } 36 ORDER BY?uri 37 OFFSET?offset 38 LIMIT?limit

98 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 <InferenceModule> 2 <name>rio Maps</name> 3 <prefixes>...</prefixes> 4 <resourcebaseuri> </resourcebaseuri> <loaders> 7 <PullLoader> 8 <description>carrega hidrantes e seus recursos</description> 9 <endpoint>...</endpoint> 10 <queryconfigs> 11 <QueryData> 12 <query>qhid</query> 13 <interval>60*60*1000</interval> 14 <binder class="defaultqueryparameterbinder" /> 15 </QueryData> 16 </queryconfigs> 17 </PullLoader> 18 <PullLoader> 19 <description>carrega lgdo:amenity de LGD</description> 20 <endpoint>http://linkedgeodata.org/sparql</endpoint> 21 <queryconfigs> 22 <QueryData> 23 <query>qamenity</query> 24 <interval>60*60*1000</interval> 25 <binder class="offsetsplitterqueryparameterbinder"> 26 <description>contagem de lgdo:amenity</description> 27 <limit>100</limit> 28 <endpoint>http://linkedgeodata.org/sparql</endpoint> 29 <query>qcontagem</query> 30 </binder> 31 </QueryData> 32 </queryconfigs> 33 </PullLoader> 34 </loaders> 35 <inference> 36 <reasoner>pellet</reasoner> 37 <ontology>hidracol.owl.xml</ontology> 38 </inference> 39 <sparqlserver> 40 <path>/ds/</path> 41 <port>32000</port>

99 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 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 SELECT?x?l?r 2 WHERE { 3 { SELECT DISTINCT?x?l (sfn:maxmatch(?l, "Casas Pedro") AS?r) 4 WHERE { 5?x a lgdo:amenity ; rdfs:label?l

100 100 6 } 7 ORDER BY DESC(?r) 8 } 9 FILTER (?r > 0) 10 } O URI encontrado é <http://linkedgeodata.org/triplify/node > 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/node > 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 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 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 e 24

103 Domínio da aplicação e modelagem Neste cenário utilizaram-se medidas pluviométricas provenientes do Alerta-Rio 25, um sistema de alerta mantido pela prefeitura da cidade do Rio de Janeiro através da Fundação Geo-Rio desde 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 Fundação Instituto de Geotécnica (Geo-Rio) -

104 104 Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008) 27 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 PLUVIOMETRICO-E-REDUCAO-DE-DESASTRES-21069_2011_5_12_8_42.pdf, que usou uma revista sobre o GEO- RIO como fonte mas esta não foi encontrada.

105 105 Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011) Nível de alerta Quantidade de chuva acumulada por tempo 1 hora 24 horas 96 horas Moderado mm mm mm Alto mm mm 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) d v ( t) 1 d d d 1 v 2 2 ( t) 2 d 1 d v ( t) 3 Equação I. Cálculo da quantidade de chuva acumulada num ponto. Onde d i 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, v (t) i 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 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, 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 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 D2RQ 28 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 -

107 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:datetime a:measuredate a:begindate a:enddate a:measurevalue xsd:decimal a:station a:measure a:station measure id (PK) : INT station_id (FK) : INT date : DATETIME value : DOUBLE xsd:decimal xsd:decimal xsd:string a:latitude a:longitude 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 108 respondidas foi criada uma visão atualizada a cada 5 segundos que engloba apenas as últimas 96 horas de medição 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:localizacao usr:usuario user id (PK) : INT nome : VARCHAR(60) xsd:decimal xsd:decimal xsd:datetime usr:ponto usr:latitude usr:longitude 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 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 109 não. 29 As bordas dos polígonos dos bairros foram obtidas do Portal Geo da Prefeitura do Rio de Janeiro 30 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 PREFIX mapa: 2 DESCRIBE?b 3 WHERE { 4?b a mapa:bairro. # rdfs:label contém o nome do bairro 5 FILTER(geo:nb_contains(?b, , )) 6 } 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 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 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 users = SELECT?uid?location 2 WHERE { 3?uid a User ; location?location } 4 FOR u IN users DO 5 l = u.location 6 d = SELECT?sid 7 (geo:distance(?slat,?slon, 29 O algoritmo utilizado pode ser encontrado em 30 Portal Geo -

110 8 l.lat, l.lon) as?dist) 9 WHERE { 10?sid a Station ; 11 location [ 12 latitude?slat ; 13 longitude?slon ] } 14 ORDER BY?dist 15 LIMIT dtot = 0 18 FOR e IN d DO dtot = dtot + 1 / e.dist ^ avg15 = avg60 = avg24 = avg96 = 0 21 FOR e IN d DO 22 w = ((1 / e.dist ^ 2) / dtot) 23 avg15 += w * acc_rain(e.sid, 15min) 24 avg60 += w * acc_rain(e.sid, 60min) 25 avg24 += w * acc_rain(e.sid, 24h) 26 avg96 += w * acc_rain(e.sid, 96h) slv60 = map(avg60, [10 : Attention, : Moderate, : High], 31 VeryHigh) 32 slv24 = map(avg24, [50 : Attention, : Moderate, : High], 35 VeryHigh) 36 slv96 = map(avg96, [100 : Attention, : Moderate, : High], 39 VeryHigh) 40 u.sliplevel = max(slv60, slv24, slv96) rlv15 = map(avg15, [0.28 : HeavyDrizzle, : LightRain, : ModerateRain, : HeavyRain], 46 VeryHeavyRain) 47 rlv60 = map(avg60, [0.00 : Dry, : LightDrizzle, : ModerateDrizzle, : HeavyDrizzle, : LightRain, : ModerateRain, : HeavyRain], 54 VeryHeavyRain) 55 u.rainlevel = max(rlv15, rlv60)

111 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) } 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 (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 é calcula a soma das medições de uma estação durante o intervalo de tempo fornecido no parâmetro range. Finalmente, as linhas 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 v i (t) ponderadas por um peso w i ; em (b) calcula-se o peso w i da estação i e, em (c) calcula-se o denominador do peso w i. Examinando o algoritmo, verifica-se que as linhas calculam a Equação IIc, a linha 22 calcula Equação IIb e, as linhas 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 112 v ( t) d ( P) w i total 3 i 1 1 d d 2 i total 3 j 1 w v d i 1 2 j ( t ) i (a) (b) (c) Equação II. Desmembramento da Equação I em três equações separadas 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 113 Applicação Applicação Contexto de bairro Qapp M4 Suposta quantidade de chuva + classificação da intensidade de chuva e dos níveis de alerta de escorregamento M3 Qchuva Seleciona estações mais próximas M2 Qdist Qacc2 Chuva acumulada por estação + Localização das estações ativas NBE ULE Quser M1 RSE Qacc Qstloc consulta primária consulta secundária (binder) Módulo Legenda: - 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 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:updatetime x:rainlevel x:rainlevel x:location x:latitude x:longitude xsd:decimal x:accrain15 x:accrain01h x:accrain24h x:accrain96h x:low, x:moderate, x:high, x:veryhigh x:name x:user xsd:string x:sliplevel x:currentlocation x:inferencelocation x:name x:locatedat x:sliplevel x:neighborhood x:location x:station x:neareststations x:userlocation x:distance x:station 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 x:updatetime?horalocinf; 17 x:sliplevel?sliplevel; 18 x:rainlevel?rainlevel 19 ] ; 20 } 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 M1- M2-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 bairroatual horalocatual bairroinf horalocinf dist classchuva probescrg Camille Moraes Ramos T00:15:13 Olaria T00:14:31 913,39 ModerateRain Moderate Mateus Veiga Jacarepagua T00:15:13 Jacarepagua T00:14:31 933,56 LightRain Moderate John Alcantara Jacarepagua T00:15:13 Jacarepagua T00:14:31 933,40 LightRain Moderate Jeane Murta Pca Bandeira T00:15:13 Pca Bandeira T00:14:31 934,52 HeavyRain Moderate usuario bairroatual horalocatual bairroinf horalocinf dist classchuva probescrg Camille Moraes Copacabana T01:43:09 Gavea T01:40: ,48 LightRain High Mateus Veiga Barra da Tijuca T01:43:09 Camorim T01:40: ,75 ModerateRain Moderate John Alcantara Vila Militar T01:43:09 Realengo T01:40: ,04 HeavyRain Moderate Jeane Murta Vasco da Gama T01:43:09 Jacarezinho T01:40: ,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 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. 2 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 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 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 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 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 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 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 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 Relationship 31 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:

120 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:romanticallyinvolved- With) 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 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 122 double geo:lat geo:long double bus:bus bus:number integer geo: SpatialThing rdfs:subclassof bus:stop bus:startstop string bus:name bus:finalstop bus:stop domain bus: RouteStop property bus:sequence Legenda range integer bus:distancefromorigin float bus:nextstop bus:previousstop bus:traveledtime integer float bus:traveleddistance bus:route bus:route bus:belongstoroute bus:name bus:belongstoline bus:code bus:line bus:servingline string string Figura 26. Ontologia de transporte por ônibus 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 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 124 Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus 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 é utilizado por eles, com apenas algumas particularidades que serão descritas ao longo das demais subseções juntamente com sua implementação.

Computação Sensível ao Contexto

Computação Sensível ao Contexto Computação Sensível ao Contexto Percepção de Contexto em Ambientes Domiciliares Modelagem de Contexto Modelagem de Contexto + Modelagem de Usuário Fabrício J. Barth novembro de 2004 Sumário O que já foi

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

3 OOHDM e SHDM 3.1. OOHDM 32 3 OOHDM e SHDM Com a disseminação em massa, desde a década de 80, de ambientes hipertexto e hipermídia, principalmente a Web, foi identificada a necessidade de elaborar métodos que estruturassem de

Leia mais

4 Trabalhos Relacionados

4 Trabalhos Relacionados 4 Trabalhos Relacionados Os trabalhos apresentados nesta seção são os que buscam de alguma forma resolver as questões levantadas nos capítulos 1 e 2 e possuem alguma semelhança entre si. Eles serão comparados

Leia mais

Introdução 17. 1 Introdução

Introdução 17. 1 Introdução Introdução 17 1 Introdução O volume de informações que gerenciamos tem crescido a cada dia. Realizamos milhões de pesquisas na Web, postamos mensagens em blogs, enviamos mensagens de correio eletrônico,

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Web Semântica e Matching de Ontologias: Uma Visão Geral

Web Semântica e Matching de Ontologias: Uma Visão Geral Web Semântica e Matching de Ontologias: Uma Visão Geral Hélio Rodrigues de Oliveira Departamento de Computação Universidade Federal do Ceará heliorodrigues@lia.ufc.br Bernadette Farias Lóscio Departamento

Leia mais

Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro de Banco de Dados

Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro de Banco de Dados U NIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA 2 0 1 2. 2 Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Os trabalhos relacionados podem ser classificados em três categorias: abordagens baseadas em metamodelos para a definição de formalismos, uso de metamodelos em editores de diagrama

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini

Banco de Dados. Conceitos e Arquitetura de Sistemas de Banco de Dados. Profa. Flávia Cristina Bernardini Banco de Dados Conceitos e Arquitetura de Sistemas de Banco de Dados Profa. Flávia Cristina Bernardini Relembrando... Vantagens da Utilização de SGBD Redundância controlada Consistência dos dados armazenados

Leia mais

3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica

3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica 3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica Este trabalho tem o objetivo de integrar o controle de acesso no projeto de aplicações na web semântica. Uma arquitetura de software

Leia mais

Protótipo de sistema de consultas utilizando a linguagem SPARQL

Protótipo de sistema de consultas utilizando a linguagem SPARQL Protótipo de sistema de consultas utilizando a linguagem SPARQL Aluno(a): André Luiz Nunes Orientador: Roberto Heinzle Roteiro Introdução Objetivos Web semântica Tecnologias para web semântica Trabalhos

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Uma Arquitetura de Armazenamento de Informações de Contexto para Aplicações Ubíquas

Uma Arquitetura de Armazenamento de Informações de Contexto para Aplicações Ubíquas Uma Arquitetura de Armazenamento de Informações de Contexto para Aplicações Ubíquas Vinícius Maran 1, Iara Augustin 2 1 DCEEng Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUI)

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Computação Aula 01-02: Introdução 2o. Semestre / 2014 Prof. Jesus Agenda da Apresentação Definição e surgimento de Sistemas Distribuídos Principais aspectos de Sistemas Distribuídos

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil

Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Integração da Informação e do Conhecimento no Contexto da Copa do Mundo e os Jogos Olímpicos no Brasil Ivan Guilherme 1, Jonas Queiroz 1, Caio Marques 2 1 Universidade Estadual Paulista, IGCE, DEMAC, Caixa

Leia mais

Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica

Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica Visual Library: Uma Biblioteca para Criação de Ferramentas de Modelagem Gráfica Tiago A. Gameleira 1, Raimundo Santos Moura 2, Luiz Affonso Guedes 1 1 Universidade Federal do Rio Grande do Norte (UFRN)

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

SABiO: Systematic Approach for Building Ontologies

SABiO: Systematic Approach for Building Ontologies SABiO: Systematic Approach for Building Ontologies Ricardo de Almeida Falbo Engenharia de Ontologias Departamento de Informática Universidade Federal do Espírito Santo Agenda Preocupações Principais do

Leia mais

CAPÍTULO 1 INTRODUÇÃO

CAPÍTULO 1 INTRODUÇÃO CAPÍTULO 1 INTRODUÇÃO A atuação do homem no meio ambiente, ao longo da história, fornece provas de suas ações em nome do progresso. Esta evolução tem seu lado positivo, pois abre novos horizontes, novas

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

ONTOLOGIA DE DOMÍNIO PARA ANÁLISE DE BLOGS

ONTOLOGIA DE DOMÍNIO PARA ANÁLISE DE BLOGS Centro Universitário Feevale ONTOLOGIA DE DOMÍNIO PARA ANÁLISE DE BLOGS Fernando Mertins Prof. Orientador: Rodrigo Rafael Villarreal Goulart Dezembro de 2007 Roteiro da Apresentação Introdução Objetivos

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

7 Utilização do Mobile Social Gateway

7 Utilização do Mobile Social Gateway 7 Utilização do Mobile Social Gateway Existem três atores envolvidos na arquitetura do Mobile Social Gateway: desenvolvedor do framework MoSoGw: é o responsável pelo desenvolvimento de novas features,

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica

Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica Mairon de Araújo Belchior Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

3 Trabalhos Relacionados

3 Trabalhos Relacionados 35 3 Trabalhos Relacionados Alguns trabalhos se relacionam com o aqui proposto sob duas visões, uma sobre a visão de implementação e arquitetura, com a utilização de informações de contexto em SMA, outra

Leia mais

O padrão RDF na descrição de imagens

O padrão RDF na descrição de imagens O padrão RDF na descrição de imagens Edeilson Milhomem da Silva 1, Parcilene Fernandes de Brito 1 1 Sistemas de Informação Centro Universitário Luterano de Palmas (CEULP/ULBRA) Cx. Postal 160 77054-970

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software

O que é software? Software e Engenharia de Software. O que é software? Tipos de Sistemas de Software. A Evolução do Software O que é software? Software e Engenharia de Software Programas de computador Entidade abstrata. Ferramentas (mecanismos) pelas quais: exploramos os recursos do hardware. executamos determinadas tarefas

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID

MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID MAPEAMENTO E LOCALIZAÇÃO DE REGIÕES DE INTERESSE UTILIZANDO REALIDADE AUMENTADA EM DISPOSITIVOS MÓVEIS COM PLATAFORMA ANDROID Alessandro Teixeira de Andrade¹; Geazy Menezes² UFGD/FACET Caixa Postal 533,

Leia mais

Desenvolvendo aplicações móveis integradas a redes sociais para o suporte de turistas no Brasil

Desenvolvendo aplicações móveis integradas a redes sociais para o suporte de turistas no Brasil Desenvolvendo aplicações móveis integradas a redes sociais para o suporte de turistas no Brasil Rossana M. C. Andrade 1,2, *, Márcio E. F. Maia 1,3, Paulo Henrique M. Maia 1 1 Grupo de Redes de Computadores,

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Desenvolvimento de um Framework de Jogos 3D para Celulares

Desenvolvimento de um Framework de Jogos 3D para Celulares Desenvolvimento de um Framework de Jogos 3D para Celulares Fabrício Brasiliense Departamento de Informática e Estatística(INE) Universidade Federal de Santa Catarina (UFSC) Campus Universitário Trindade-

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados

Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Dublin Core e MARC 21 : um estudo de correspondência de elementos de metadados Maria das Dores Rosa Alves¹, Marcia Izabel Fugisawa Souza¹ ¹Embrapa Informática Agropecuária Caixa postal 6014 Campinas, SP

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial

Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Aplicação de um Metamodelo de Contexto a uma Tarefa de Investigação Policial Lucas A. de Oliveira, Rui A. R. B. Figueira, Expedito C. Lopes Mestrado em Sistemas e Computação Universidade de Salvador (UNIFACS)

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

EMENTAS DO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

EMENTAS DO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS EMENTAS DO CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS INTRODUÇÃO À COMPUTAÇÃO 60 h 1º Evolução histórica dos computadores. Aspectos de hardware: conceitos básicos de CPU, memórias,

Leia mais

Representação e Visualização de dados estatísticos: os desafios dos dados abertos ligados

Representação e Visualização de dados estatísticos: os desafios dos dados abertos ligados Representação e Visualização de dados estatísticos: os desafios dos dados abertos ligados Alan Tygel 1 1 Programa de Pós-Graduação em Informática Universidade Federal do Rio de Janeiro (UFRJ) Caixa Postal

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

CAMobile: Um Framework para Sistemas Sensíveis ao Contexto na plataforma ios

CAMobile: Um Framework para Sistemas Sensíveis ao Contexto na plataforma ios CAMobile: Um Framework para Sistemas Sensíveis ao Contexto na plataforma ios 1. Introdução Matheus Matos de Farias Universidade do Estado da Bahia, Bahia, Brasil Resumo: A computação ubíqua é um paradigma

Leia mais

PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis

PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis PLATAFORMA URBANMOB Aplicativo para captura de trajetórias urbanas de objetos móveis Gabriel Galvão da Gama 1 ; Reginaldo Rubens da Silva 2 ; Angelo Augusto Frozza 3 RESUMO Este artigo descreve um projeto

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Uso de Padrões Web. maio/2009

Uso de Padrões Web. maio/2009 Uso de Padrões Web maio/2009 Internet e Web, passado, presente e futuro 2 Internet e Web, passado, presente e futuro 3 A Evolução da Web Pré Web Passado web 1.0 Presente web 2.0 Futuro web 3.0 4 A Evolução

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

Modelagem do Conhecimento para a Gestão de Processos e Projetos. Modelagem do Conhecimento para a Gestão de Processos e Projetos Prof.

Modelagem do Conhecimento para a Gestão de Processos e Projetos. Modelagem do Conhecimento para a Gestão de Processos e Projetos Prof. Modelagem do Conhecimento para a Gestão de Processos e Projetos 1 Objetivo Apresentação de modelo conceitual para a integração e recuperação de informações, disponíveis em ambientes internos ou externos,

Leia mais

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Diretoria de Sistema - DS Superintendência de Arquitetura de Sistemas - SAS Gerência de Arquitetura de Informação - GAAS

Leia mais

Uma Extensão da Disciplina de Requisitos do OpenUP/Basic para a Construção de Ontologias Aplicadas à Web Semântica

Uma Extensão da Disciplina de Requisitos do OpenUP/Basic para a Construção de Ontologias Aplicadas à Web Semântica SEMINÁRIO DE PESQUISA EM ONTOLOGIA NO BRASIL 11 e 12 de Agosto Universidade Federal Fluminense Departamento de Ciência da Informação Niterói Rio de Janeiro Brasil [X] Tema 2 Técnicas e Ferramentas em Ontologias

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Banco de Dados I. Introdução Conceitos

Banco de Dados I. Introdução Conceitos Banco de Dados I Introdução Conceitos Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Ementa Conceitos Fundamentais de Banco de Dados; Características

Leia mais

Relatório Individual Sumarizado para bolsa Fapesp de Treinamento Técnico TT-4A

Relatório Individual Sumarizado para bolsa Fapesp de Treinamento Técnico TT-4A Relatório Individual Sumarizado para bolsa Fapesp de Treinamento Técnico TT-4A 23/02/2013 Título do Projeto: Desenvolvimento de um sistema de informações integrado para pesquisas sobre políticas públicas.

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

1 Introdução. 1.1. Motivação

1 Introdução. 1.1. Motivação 1 Introdução A adoção do Ginga-NCL como middleware declarativo do SBTVD (Sistema Brasileiro de Televisão Digital) estabeleceu um marco no desenvolvimento de aplicações interativas para TV Digital terrestre

Leia mais

Análise estruturada de sistemas

Análise estruturada de sistemas Análise estruturada de sistemas Prof. Marcel O que é Engenharia de software Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de

Leia mais

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software

JOSÉ AUGUSTO FABRI. Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação e a Organização de Processos de Produção em um Contexto de Fábrica de Software São Paulo 2007 JOSÉ AUGUSTO FABRI Uma Proposta de Modelo para a Criação

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Mapserver Servidor de Mapas. João Araujo

Mapserver Servidor de Mapas. João Araujo Mapserver Servidor de Mapas João Araujo Por que fazer mapas? Mapas têm tido papel prepoderante nas atividades humanas por milhares de anos. Desde o início, mapas eram usados para mostrar onde as coisas

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

GUIA RÁPIDO DE UTILIZAÇÃO DO APLICATIVO RDB2LOD

GUIA RÁPIDO DE UTILIZAÇÃO DO APLICATIVO RDB2LOD GUIA RÁPIDO DE UTILIZAÇÃO DO APLICATIVO RDB2LOD Em sua versão inicial, o aplicativo RDB2LOD foi desenvolvido para instalação e execução em ambiente de máquina virtual Java, e oferece suporte aos SGBDs

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

Reuso. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reuso Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Reutilização de Software Na maioria das áreas de engenharia de software, sistemas são desenvolvidos

Leia mais

Recuperação de Informações em Documentos Anotados Semanticamente na Área de Gestão Ambiental

Recuperação de Informações em Documentos Anotados Semanticamente na Área de Gestão Ambiental 1 Recuperação de Informações em Documentos Anotados Semanticamente na Área de Gestão Ambiental Celso Araújo Fontes (IME) celsowm@gmail.com Maria Claudia Cavalcanti (IME) yoko@ime.eb.br Ana Maria de Carvalho

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

Cadernos UniFOA. Web Semântica: Uma Rede de Conceitos. Semantic Web: A Network of ConceptsONCEPTS

Cadernos UniFOA. Web Semântica: Uma Rede de Conceitos. Semantic Web: A Network of ConceptsONCEPTS 23 Web Semântica: Uma Rede de Conceitos Semantic Web: A Network of ConceptsONCEPTS Professor Especialista José Maurício dos Santos Pinheiro Artigo Original Original Paper Palavras-chaves: Internet Semântica

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Luiz Cláudio Hogrefe Orientador: Prof. Roberto Heinzle, Doutor Roteiro Introdução Fundamentação teórica

Leia mais

Visualização de Dados Estatísticos em LOD

Visualização de Dados Estatísticos em LOD Visualização da Informação Professora: Adriana Vivaqua Período: 2012/3 Visualização de Dados Estatísticos em LOD Alan Tygel Daniele Palazzi Linked Open Data - LOD "Linked Data é um conjunto das melhores

Leia mais

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt INTRODUÇÃO E CONCEITOS BÁSICOS Prof. Ronaldo R. Goldschmidt Hierarquia Dado - Informação - Conhecimento: Dados são fatos com significado implícito. Podem ser armazenados. Dados Processamento Informação

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Integração de Sistemas de Gerenciamento de Redes de Telecomunicações Utilizando GML

Integração de Sistemas de Gerenciamento de Redes de Telecomunicações Utilizando GML Integração de Sistemas de Gerenciamento de Redes de Telecomunicações Utilizando GML Novembro/2003 Agenda Introdução Contexto Problema Objetivo Solução Integração de Sistemas de Telecom Rede Externa de

Leia mais

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.

Consumindo um Web Service através de uma Aplicação Comercial em Android. Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com. Consumindo um Web Service através de uma Aplicação Comercial em Android Alex Malmann Becker www.alex.porthal.com.br alex@porthal.com.br 08/2014 Agenda Introdução Conceitos Web Service Por que utilizar

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

CONSTRUÇÃO DE SOFTWARE

CONSTRUÇÃO DE SOFTWARE CONSTRUÇÃO DE SOFTWARE Náthilla Tavares Fagundes, Pablo Galvão, Wytor Venancio Rodrigues Faculdade de Tecnologia SENAC Goiânia/GO (SENAC/GO) Av. Independência número 1002 - CEP 74645-010 Setor Leste Vila

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

CURSO TECNOLÓGICO 2008/01 1º SEMESTRE. Programação e Estruturas de Dados Fundamentais

CURSO TECNOLÓGICO 2008/01 1º SEMESTRE. Programação e Estruturas de Dados Fundamentais 1º SEMESTRE Programação e Estruturas de Dados Fundamentais 8 Créditos Desenvolver a lógica de programação através da construção de algoritmos utilizando português estruturado Representar a solução de problemas

Leia mais

Gerenciamento de Rede Baseado em Políticas

Gerenciamento de Rede Baseado em Políticas Gerenciamento de Rede Baseado em Políticas (Policy-Based Networking) Ademir José de Carvalho Junior Recife, Fevereiro de 2007 Resumo: A complexidade das redes baseadas em IP atualmente segue crescendo

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

PRnet/2013. Linguagem de Programação Web

PRnet/2013. Linguagem de Programação Web Linguagem de Programação Web Linguagem de Programação Web Prnet/2013 Linguagem de Programação Web» Programas navegadores» Tipos de URL» Protocolos: HTTP, TCP/IP» Hipertextos (páginas WEB)» HTML, XHTML»

Leia mais

X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB

X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB Augusto Francisco Ferbonink¹, Willian Barbosa Magalhães 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil aferbonink@gmail.com wmagalhães@unipar.com Resumo.

Leia mais

linguagem técnica de informática; Perceber os sinais de pontuação e identificar sua função no texto; Ler siglas e identificar seus significados;

linguagem técnica de informática; Perceber os sinais de pontuação e identificar sua função no texto; Ler siglas e identificar seus significados; PLANO DE CURSO Disciplina Competências Habilidades Bases Tecnológicas INGLÊS TÉCNICO Aumentar e consolidar o seu vocabulário ativo e passivo, através da fixação de novas palavras e expressões contidas

Leia mais

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD)

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD) Pós-graduação em Ciência da Computação CCM-202 Sistemas de Banco de Dados Introdução Profa. Maria Camila Nardini Barioni camila.barioni@ufabc.edu.br Bloco B - sala 937 2 quadrimestre de 2011 Motivação

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais