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

CRISTIANO EXPEDITO RIBEIRO

MÓDULOS DE INFERÊNCIA NA NUVEM DE DADOS LIGADOS PARA APOIAR O DESENVOLVIMENTO DE APLICAÇÕES

RIO DE JANEIRO 2012

CRISTIANO EXPEDITO RIBEIRO

Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações

Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Informática da Universidade Federal do Rio de Janeiro, como requisito parcial à obtenção do título de Mestre em Informática.

Orientadora: Prof.ª Dr.ª Adriana Santarosa Vivacqua

Rio de Janeiro 2012

R484 Ribeiro, Cristiano Expedito Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. / Cristiano Expedito Ribeiro. – 2012. 203 f.: il. Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti, Programa de Pós-Graduação em Informática. Orientadora: Adriana Santarosa Vivacqua 1. Módulos de Inferência. 2. Nuvem de Dados. 3. Nuvem para Apoio e Desenvolvimento de Aplicações – Teses. I. Vivacqua, Adriana Santarosa (Orient.). II. Universidade Federal do Rio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti, Programa de Pós-Graduação em Informática. III. Título CDD

Agradecimentos

Agradeço à minha mãe Tania, à minha avó Zenith (in memoriam) e ao meu tio Sérgio que me estimularam em minha formação acadêmica, e à minha irmã Christina. À minha orientadora Adriana S. Vivacqua, expresso meu profundo agradecimento por seu empenho e pelos conselhos nos momentos mais críticos do trabalho. Aos professores Daniel Schwabe (DI-PUC-Rio) e Maria Luiza Machado Campos (PPGI-UFRJ) pela gentileza de comporem a banca examinadora e pelas estimadas contribuições. Meus agradecimentos especiais aos professores do PPGI, Jonice Oliveira, João Carlos e Marcos Borges pelas suas colaborações pontuais, mas extremamente úteis nos seminários. Aos meus colegas e amigos de mestrado e laboratório, Augusto, Biancas Lima e Pereira, Bruno Nascimento, Diego, Evelyn, Fábio, Fabrício Firmino, Inês Boscá, João Vítor, Patrícia, Rafael Escalfoni, Rogers Reiche, Ruben Perorazio e Tiago Marino, pelo auxílio, companheirismo e descontração em diversos momentos desta trajetória, e também aos meus amigos da graduação, chefes e colegas de trabalho. Finalmente, deixo meus agradecimentos à Universidade Federal do Rio de Janeiro (UFRJ) e ao Programa de Pós-Graduação em Informática (PPGI) que me receberam em suas dependências, e ao CNPq (Conselho Nascional de Desenvolvimento Científico e Tecnológico) pelo suporte financeiro oferecido para apoiar o desenvolvimento desta dissertação.

Resumo RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012.

Computação ubíqua e pervasiva se caracterizam por sistemas computacionais embarcados no ambiente, capazes de interagir amigavelmente com o usuário, reconhecendo e se adaptando ao meio. Contudo, para isto se tornar realidade, é necessário entender o contexto no qual estas interações ocorrem. Alguns middlewares para auxiliar o desenvolvimento de aplicações cientes de contexto (CC) foram propostos, mas ainda não surgiu um realmente efetivo quanto à aplicabilidade no mundo real. Além disso, dados de contexto devem ser representados em um formato reutilizável e interoperável que permita compartilhamento, comunicação e reuso, pois aplicações CC precisam integrar informações oriundas de sensores locais e remotos, bases de dados e de contexto. O objetivo deste trabalho é aproveitar tecnologias padronizadas da Web Semântica e de Linked Open Data (LOD) como formatos, ontologias e linguagens de consultas para atender estas necessidades. Para tanto, propomos a arquitetura LOUD e neste trabalho enfocamos o módulo de inferência, capaz de ser facilmente configurado para consumir, processar e publicar triplas RDF, fazendo consultas a SPARQL endpoints e gerando seu próprio endpoint com novos dados que são produzidos por inferência OWL-DL e/ou regras. Estes módulos podem ser organizados hierarquicamente ou em rede para produzir contextos com níveis mais altos de abstração. Para mostrar a viabilidade de se produzir aplicações utilizando este módulo, foram implementados três cenários e, posteriormente, um deles foi levado para experimentos com alunos que configuraram uma pequena rede de módulos e fizeram uma avaliação através de um questionário. Os resultados foram satisfatórios, pois apesar de alguns alunos apresentarem dificuldades, foi relatada que a configuração é simples, detalhada e flexível, a execução é fácil e consultas são simplificadas para o consumidor final.

Palavras-chaves: Linked Open Data, Web Semântica, contexto, ciência de contexto, inferência, ontologias

Abstract RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012. Ubiquitous and pervasive computing are characterized by computational systems embedded into the environment, able to interact with the user friendly, recognizing and adapting to the environment. However, for this to become reality, it is necessary to understand the context in which these interactions occur. Some middleware to support the development of context-aware applications (CC) have been proposed, but no one has emerged as really effective with respect to the applicability in the real world. Moreover, context data should be represented in a reusable and interoperable format that allows sharing, communication and reuse as CC applications need to integrate information from local and remote sensors, bases of data and context. Our objective is to leverage standard technologies of the Semantic Web and Linked Open Data (LOD) like formats, ontologies and query languages to meet these needs. To this end, we propose the LOUD architecture and we focus on the inference module, which is able to be easily configured to consume, process and publish RDF triples, making queries to SPARQL endpoints and generating its own endpoint with the new data that are produced by inference using OWL-DL and/or rules. These modules can be organized hierarchically or as a network to produce contexts with higher levels of abstraction. To show the feasibility of producing applications using this module, three scenarios were implemented and, later, one was led to experiments with students who have set up a small network of modules and made an assessment using a questionnaire. The results were satisfactory, because although some students had presented difficulties, it was reported that the configuration is simple, comprehensive and flexible, execution is easy and queries are simplified for the end consumer.

Keywords: Linked Open Data, Semantic Web, context, context awareness, inference, ontologies

Lista de Figuras

Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior uma notação de conjuntos e na inferior as dimensões grau de mobilidade e de embarcamento em eixos ortogonais. ............................................................................ 21 Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação, à forma de obtenção, à visibilidade e à taxa de atualização. ......................................... 27 Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅. ........ 46 Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações imprevistas no TBox. ..................................................... 53 Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005). ........................................... 60 Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003) ..................... 61 Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como produtores e consumidores. Entradas para configuração dos módulos foram omitidas. ..................................................................................................................... 68 Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação bidirecional) é representada para fins didáticos, pois a base pode conter triplas virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a leitura sobre Jena e Pellet na seção 2.3.2). .............................................................................. 74 Figura 9. Diagrama de atividades do módulo de inferência ................................................... 78 Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado. ............................................................................................................ 82 Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule. ........... 84 Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader. ................................................................................................................. 85 Figura 13. Hierarquia mais externa dos elementos XML de configuração. ............................ 89 Figura 14. Elementos XML para configuração de carregadores e substituidores de variáveis (binders)....................................................................................................... 90 Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD. ..................................................................................... 93 Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD....................................................................... 96 Figura 17. Lista de Resultados na aplicação protótipo desenvolvida. .................................. 101 Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) ....................... 104 Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o mapeamento entre conceitos. ........................................ 107 Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o mapeamento entre conceitos ......................................... 108 Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento. ............ 113

Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas. ............... 114 Figura 23. Diagrama das ontologias de tempo e eventos utilizadas. .................................... 119 Figura 24. Diagrama de classes da ontologia de relações entre pessoas. .............................. 120 Figura 25. Diagrama de hierarquia de propriedades da ontologia de relações entre pessoas...................................................................................................................... 120 Figura 26. Ontologia de transporte por ônibus. ................................................................... 122 Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus. ...................................................................................................................... 124 Figura 28. Rede social dos usuários do endpoint USNLE. .................................................. 128 Figura 29. Estrutura interna do endpoint BLE. ................................................................... 130 Figura 30. Rede de módulos de inferência para notificações sobre eventos (números ao lados de módulos indica quantidade de regras usadas). .............................................. 131 Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações. ......... 132 Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b). .................... 134 Figura 33. Histogramas das respostas globais. .................................................................... 138 Figura 34. Resultados do teste presencial com alunos. ........................................................ 139 Figura 35. Teste remoto com alunos em pesquisa de tese. .................................................. 140 Figura 36. Resultados do teste remoto com alunos da disciplina. ........................................ 141 Figura 37. Mediana das respostas das três primeiras partes do questionário conforme valores atribuídos a cada resposta (quanto mais próximo do valor máximo melhor). .................................................................................................................... 142 Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita) ..................................................................................................................... 170 Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath. .................... 173 Figura 40. Estrutura interna do endpoint BLE .................................................................... 185 Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto. ......................................................................................... 186

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

Lista de Siglas API

Application Programming Interface

CBMERJ

Corpo de Bombeiros Militar do Estado do Rio de Janeiro

CC

Ciente de Contexto

CML

Context Modelling Language

DL

Description Logic

ETL

Extraction, Transformation, Loading

FOAF

Friend Of A Friend

GEO-RIO

Fundação Instituto de Geotécnica do Município do Rio de Janeiro

GPS

Global Positioning System

HTTP(S)

Hypertext Transfer Protocol (Secure)

KML

Keyhole Markup Language

LD

Lógica de Descrição

LOD

Linked Open Data / Dados Abertos Ligados

LOV

Linked Open Vocabularies

MVO

Mapeamento Vocabulário-Ontologia

MIO

Mapeamento Inter-Ontologias

N3

Notation 3

OD

Ontologia de Domínio

ORM

Object-Role Modelling

OWL

Web Ontology Language

RA

Região Administrativa

REST

Representational State Transfer

RCC

Region Connection Calculus

RDF

Resource Description Framework

SWRL

Semantic Web Rule Language

UBICOMP

Ubiquitous Computing / computação ubíqua

URI/L

Uniform Resource Identifier/Locator

W3C

World Wide Web Consortium

WGS84

World Geodetic System 1984

WS

Web Semântica

Sumário 1

2

Introdução ..................................................................................................................... 15 1.1

Motivação ............................................................................................................ 15

1.2

Contextualização do Problema ............................................................................. 15

1.3

Problema específico ............................................................................................. 17

1.4

Objetivo ............................................................................................................... 18

1.5

Contribuição ........................................................................................................ 19

1.6

Estrutura da dissertação ........................................................................................ 19

Referencial Teórico ....................................................................................................... 20 2.1

Computação ubíqua e contexto: definições ........................................................... 20

2.2

Aquisição, classificação e modelagem de contexto ............................................... 23 2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores ....... 23 2.2.2 Classificações de contexto ........................................................................ 25 2.2.3 Classificações de aplicações cientes de contexto ....................................... 27 2.2.4 Comparações entre modelos de contexto ................................................... 28 2.2.5 Ontologias de modelagem de contexto ...................................................... 33

2.3

Web Semântica e Dados Ligados ......................................................................... 37 2.3.1 Conceitos básicos ..................................................................................... 38 2.3.2 Lógica de Descrição (DL) ......................................................................... 41 2.3.3 Web Ontology Language (OWL) .............................................................. 53 2.3.4 Trabalhos de publicação em LOD ............................................................. 57

2.4

Trabalhos relacionados......................................................................................... 58 2.4.1 Frameworks para aplicações cientes de contexto ....................................... 58 2.4.2 Arquiteturas para integração de dados na Web .......................................... 65

3

LOUD – Linked Open Ubiquitous Data ........................................................................ 67 3.1

Introdução ............................................................................................................ 67

3.2

Arquitetura LOUD ............................................................................................... 67 3.2.1 Objetivos .................................................................................................. 67 3.2.2 Estrutura ................................................................................................... 67

3.3

Escopo do trabalho: o Módulo de Inferência ........................................................ 73 3.3.1 Estrutura ................................................................................................... 73

3.3.2 Implementação ......................................................................................... 80 3.3.3 Configuração ............................................................................................ 87 4

Cenários de Aplicação ................................................................................................... 92 4.1

Cenário 1: informação sobre hidrantes durante um incêndio ................................. 92 4.1.1 Modelagem e construção da camada de dados ........................................... 93 4.1.2 Camada de inferência para integração das bases ........................................ 96 4.1.3 Aplicação de consumo e considerações ..................................................... 99

4.2

Cenário 2: alertas sobre chuvas e escorregamento de terra .................................. 102 4.2.1 Domínio da aplicação e modelagem ........................................................ 103 4.2.2 Camada de dados e sensoriamento .......................................................... 106 4.2.3 Camada de inferência.............................................................................. 109 4.2.4 Discussão ............................................................................................... 116

4.3

Cenário 3: notificação sobre eventos sociais e chegadas de ônibus ..................... 117 4.3.1 Domínio da aplicação e modelagem ........................................................ 118 4.3.2 Camada de dados e sensoriamento .......................................................... 124 4.3.3 Camada de inferência.............................................................................. 130 4.3.4 Visualização das notificações em navegador Web ................................... 132

5

Experimentos e Resultados.......................................................................................... 133 5.1

Formato do experimento .................................................................................... 133

5.2

Avaliações dos alunos ........................................................................................ 135 5.2.1 Alguns dados quantitativos ..................................................................... 136 5.2.2 Avaliações qualitativas ........................................................................... 143

6

Considerações finais.................................................................................................... 147 6.1

Retrospectiva ..................................................................................................... 147

6.2

Estudo de viabilidade e experimentos realizados ................................................ 148

6.3

Contribuições e aspectos positivos ..................................................................... 150

6.4

Problemas e limitações ....................................................................................... 151

6.5

Trabalhos futuros ............................................................................................... 153

Referências ........................................................................................................................ 155 Apêndices .......................................................................................................................... 165 Apêndice A – Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE) ......... 165

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

15

1 1.1

Introdução Motivação O surgimento de celulares menores, mais leves e baratos vem proporcionando

aumento de acessibilidade e maior facilidade de comunicação. Mais recentemente, a disseminação de dispositivos móveis que utilizam formas variadas de comunicação sem fio (Bluetooth e Wi-Fi, por exemplo) e o surgimento dos Smartphones (que permitem expansão de suas funcionalidades) fornecem grandes oportunidades tanto para usuários quanto para fabricantes e desenvolvedores. Esta evolução traz novas questões, pois o usuário passa a requisitar conteúdo (inclusive da Web) que satisfaça suas necessidades momentâneas e de forma imediata (RICCI, 2011). Nestas circunstâncias, surge a necessidade de um modelo ciente de contexto (CC) o que remete às ideias de Computação Ubíqua de Mark Weiser (WEISER, 1991). No entanto, a área de computação ciente de contexto ainda enfrenta grandes desafios para o desenvolvimento de tais aplicações. Paralelamente, iniciativas de tornar a Web Semântica (WS) uma realidade vêm ganhando força (BIZER, 2009), e acredita-se que podem ser de grande utilidade no cenário da computação ubíqua. A WS tem por objetivo atribuir significado ao conteúdo da Web, tornando-a manipulável por máquinas. Para isso, usa vocabulários, ontologias e regras que sigam um padrão de fato (BERNERS-LEE et al., 2001). A adoção destes padrões parece resolver muitos dos problemas que serão descritos nas próximas seções.

1.2

Contextualização do Problema Apesar de o desenvolvimento de aplicações CC ser uma área pesquisada há bastante

tempo e várias arquiteturas ou middlewares terem sido propostos para tentar facilitar e agilizar este processo, nenhuma delas foi efetiva quanto à aplicabilidade no mundo real, necessitando de mais pesquisas científicas (YU et al., 2010). Além disso, a maioria destas arquiteturas foi construída para domínios específicos não podendo ser usada de forma corriqueira (HU et al., 2009). Adicionalmente, a maioria das pesquisas em computação ubíqua tem focado em ambientes ad hoc com protocolos e infraestruturas proprietárias e serviços CC não costumam focar na interoperabilidade entre sistemas, dispositivos e serviços (LU et al., 2012).

16

É necessário que dados de contexto sejam representados em um formato sintatica e semanticamente reutilizável e interoperável para permitir compartilhamento e reuso (PERTTUNEN et al., 2009). Esta necessidade decorre do fato de que aplicações CC frequentemente precisam integrar informações oriundas de sensores, bases de dados e fontes de contextos externos, que ao adotarem variados formatos, protocolos, esquemas, taxonomias e vocabulários, dificultam a interoperabilidade e, consequentemente, o reaproveitamento (reutilização) de informações úteis já existentes. Serviços CC geralmente não permitem que aplicações CC sejam interoperáveis por meio de tais modelos de contextos comuns (HERVÁS; BRAVO, 2011). Contudo, esta interoperabilidade entre dispositivos e serviços é um importante e difícil desafio em ambientes pervasivos, incluindo cientes de contexto, porque dependem de diferentes modelos de interação e informação (BRØNSTED et al., 2010). Todos estes fatores prejudicam a produtividade destas aplicações. A interoperabilidade desejada pode ser obtida com tecnologias da Web Semântica (HERVÁS; BRAVO, 2011). O uso de ontologias para criação de modelos de contexto é promissor para atender estes requisitos (STRANG; LINNHOFF-POPIEN, C., 2004). Contudo, até modelos e arquiteturas de contexto baseados em ontologias apresentam dificuldades em reaproveitá-las para permitir interoperabilidade entre módulos de sistemas distintos. Cada uma das arquiteturas pesquisadas, como SOCAM (GU et al., 2005), CoBrA (CHEN, HARRY et al., 2003), iTransIT (LEE; MEIER, 2009) e COSAR (RIBONI; BETTINI, 2011a), entre outras, utiliza sua própria ontologia e, em geral, não utilizam um protocolo de comunicação comum. Segundo os autores do CoBrA, a maior deficiência de sua abordagem é a “inabilidade de reusar outras ontologias consensuais” que “requer maior sobrecarga no projeto e engenharia

de ontologias”

e que “pode reduzir a

interoperabilidade”. Mesmo que houvesse uma ontologia unificada para tratamento de contexto ou que todas as existentes tivessem mapeamento entre si, o modelo ontológico não é eficaz nem eficiente para todas as necessidades da computação CC (BETTINI et al., 2010). Muitas delas requerem outras técnicas de inteligência articial ou estatística, inclusive para tratamento de dados de sensores, que geralmente são incertos, ambíguos e até mesmo conflitantes. Desta forma, ontologias são geralmente usadas para descoberta de conhecimento implícito em um nível mais alto e para validação de bases de conhecimento por utilizarem processos mais formais quanto à semântica. Surge, então, a questão sobre como permitir interoperabilidade entre estes sistemas heterogêneos, ou seja, com diversos tipos de modelos de contexto.

17

Resumidamente, se for necessário que, ao construir uma aplicação, o projetista crie seu próprio modelo de contexto, por exemplo, ontologias e regras (pouca reutilização), e/ou o desenvolvedor precise construir conversores para comunicação e interoperabilidade com módulos externos (que utilizem modelos de contexto ontológicos ou não) há um prejuízo à produtividade. Além do mais, mesmo adotando padrões da WS, as bases de dados e fontes de contexto podem utilizar vocabulários e ontologias distintos que podem ainda prejudicar a interoperabilidade se não houver uma forma padronizada de comunicação e de mapeamento entre seus elementos. Portanto, faz-se necessário a criação de uma arquitetura distribuída na Web que forneça mecanismos de comunicação entre diversas fontes de dados e de inclusão de regras tanto para mapeamento de conceitos quanto para inferência de contexto. Estes mecanismos precisam ser interoperáveis e reutilizáveis para proporcionar melhoras na produtividade no desenvolvimento de aplicações CC. Assim, o problema geral concentra-se em três conceitos interligados: interoperabilidade, reutilização e produtividade.

1.3

Problema específico Neste trabalho, pretende-se tratar tanto a interoperabilidade entre bases que provêem

dados contextuais, quanto reutilização de suas ontologias, regras de inferência e dados. Como discutido na seção anterior, usar padrões e princípios da WS parece ser uma possível solução por diversos motivos. A possibilidade de criação de ligações entre recursos Web de diferentes bases de dados vista na iniciativa de Linked Data (LOD1) parece viabilizar parte da interoperabilidade entre bases de dados contextuais, pois estabelecem mapeamentos entre tais dados. A padronização de formato (triplas RDF) e linguagem de consulta (SPARQL) estabelecida pela W3C parece viabilizar tanto interoperabilidade quanto reutilização, tanto de fontes de dados estáticos (que não mudam com freqüência) quanto de sensores físicos. A padronização de linguagens para representação de ontologias na Web (OWL) e para criação de regras definidas pelo usuário (como SWRL) também parece viabilizar a reutilização de modelos de contexto (taxonomias, ontologias e inferências). No entanto, o uso de LOD traz diversos desafios que devem ser pesquisados. Um deles é determinar quais bases e ligações são úteis e/ou confiáveis para serem utilizadas. Outro desafio reside na disponibilização de dados de sensores físicos para acesso via SPARQL 1

Será utilizada a sigla LOD, mesmo para bases não abertas, para evitar confusão com lógica descritiva (LD).

18

endpoints. Isso vai desde a obtenção dos dados não-tratados de sensores físicos (termômetros, GPS, pluviômetros, etc.) e a forma de atualização do SPARQL endpoint quando ocorre alguma atualização, até fusão e agregação destes dados. Este último pode necessitar de diversas técnicas de tratamento de dados incertos (lógica Fuzzy, redes bayesianas, Hidden Markov Models, etc.). Nenhum destes desafios será pesquisado aqui. O problema específico a ser tratado neste trabalho está relacionado a propor e testar um módulo que permita inferências, incuindo de contexto, usando OWL-DL, que provê construtos de lógica descritiva, e regras definidas pelo usuário. Este módulo pode ser classificado como um sensor lógico ou interpretador de contexto segundo a literatura CC ou como um dataset de dados derivados segundo os conceitos de LOD. Além de efetuar inferência, é necessário que tais dados sejam disponibilizados na nuvem LOD, em um formato comum que permita interoperabilidade para serem usados por diversas aplicações (CC ou não) e até mesmo por outros módulos. Por fim, o framework precisa ser configurado facilmente, desde que o domínio já tenha sido previamente definido. Assim, o problema é enunciado da seguinte forma: “Necessidade de um ferramental configurável, capaz de realizar inferências, incluindo contexto, usando formatos de dados interoperáveis, e também de disponibilizar seus dados para consumo seguindo princípios da Web Semântica.”

1.4

Objetivo Este trabalho tem por objetivo apresentar a arquitetura, a implementação e validação

do Módulo de Inferência proposto como parte de um framework mais geral, que se propõe a ser um módulo facilmente configurável que permita inferência de contextos em níveis, do mais geral ao mais específico. Contudo, esta pesquisa se limita a inferências usando o padrão OWL 2 DL (Web Ontology Language 2 Description Logic) do W3C e regras IF-THEN sobre instâncias de uma base. Portanto, não está no escopo qualquer outro método como Lógica Fuzzy ou de Primeira Ordem, Redes Bayesianas, etc. A etapa de validação compreenderá a descrição de alguns cenários onde dados contextualizados são necessários e a explicação das etapas necessárias (modelagem do domínio, construção da ontologia OWL, regras e consultas) para se chegar a uma base que

19

possa ser consultada diretamente por uma suposta aplicação. Por fim, acredita-se que, no futuro, tais módulos poderiam ser disponibilizados na Web com diferentes tipos de informações para que desenvolvedores de aplicações pudessem consumir seus dados.

1.5

Contribuição A principal contribuição deste trabalho é um framework facilmente configurável para

auxiliar a construção da parte inteligente de aplicações cientes de contexto (inferência de contexto e geração de notificações e/ou ações) utilizando formatos e padrões abertos da Web Semântica. O uso destas tecnologias mostra que o framework também é útil para aplicações genéricas para Web Semântica que necessitem de inferência com ontologias OWL e regras. O framework mostra habilidade em fazer inferência modularizada e distribuída na Web, ou seja, dividir o processamento de ontologias e regras em módulos distintos que podem executar em máquinas distintas para posterior integração. Para mostrar a viabilidade três cenários foram propostos e implementados. A facilidade de configuração proporcionada pelo framework permite que pessoas sem grandes conhecimentos de linguagens de programação possam configurar o módulo e disponibilizar seus dados na Web rapidamente. O framework reduz a necessidade de programação, mas não substitui as necessidades de conhecimento do domínio, levantamento de requisitos e modelagem como em qualquer desenvolvimento de aplicações.

1.6

Estrutura da dissertação Este trabalho é dividido em outros cinco capítulos. O capítulo 2 apresenta o referencial

teórico sobre contexto, web semântica e alguns trabalhos relacionados. O capítulo 3 descreve uma arquitetura geral em camadas sugerida para o problema descrito na seção 1.2 e depois aprofunda a discussão para uma parte da arquitetura denominada Módulo de Inferência que visa abordar o problema específico da seção 1.3. O capítulo 4 mostra cenários de aplicação e as respectivas provas de conceito através de implementações utilizando o módulo sugerido, mostrando que é factível. O capítulo 5 apresenta um experimento feito com alunos de mestrado e seus resultados a fim de verificar o grau de dificuldade em se entender e configurar módulos para uma das aplicações do capítulo 4. Por fim, o capítulo 6 destaca análises críticas quanto às contribuições, limitações e oportunidades futuras.

20

2

Referencial Teórico A área de computação ubíqua (UBICOMP) e pervasiva está cada vez mais relacionada

à Web, pois à medida que esta se torna cada vez mais presente na vida das pessoas, mais útil ela demonstra ser como um ferramenta para tarefas cruciais da computação ubíqua e pervasiva. Este capítulo apresentará conceitos de computação ubíqua, pervasiva e ciente de contexto, e Web Semântica (WS), e como esta tem sido empregada nessas áreas. Como é cada vez mais difícil falar de UBICOMP sem falar das tecnologias da WS, e uma ordem deve ser seguida, decidiu-se por falar primeiramente de UBICOMP (seções 2.1 e 2.2) reduzindo ao máximo o uso de termos técnicos da WS, para depois introduzir conceitos de WS (seção 2.3). A priori, caso o leitor não esteja familiarizado com WS, tenha em mente a seguinte analogia entre WS, grafos, linguagens de programação e bancos de dados relacionais: RDF é uma representação de informação usando nós e arestas, onde um nó pode ser um URI ou um valor literal (número, texto, data). Um URI possui a forma de um endereço na Internet e é equivalente à chave primária, identificando, portanto, um registro de tabela. Um literal equivale a um campo de tabela que não seja chave estrangeira. Um URI, por ser um identificador, pode representar um nó não literal ou um tipo de aresta. RDFS e OWL representam ontologias sendo semelhante ao esquema do banco, ou seja, definem as relações e restrições permitidas entre nós. Regras assemelham-se ao comando IF..THEN ou triggers, e também permitem chamada de funções. Por fim, SPARQL é análogo à linguagem SQL.

2.1

Computação ubíqua e contexto: definições Em 1991, Mark Weiser lança os princípios da Computação Ubíqua, onde introduz o

termo computação invisível (WEISER, 1991). Segundo ele, “As mais profundas tecnologias são aquelas que desaparecem”. Sua proposta não era de eliminar ou ocultar máquinas, mas de proporcionar interações mais amigáveis, tirando o foco de atenção das máquinas e direcionando para as tarefas dos usuários. Embora ainda não exista um consenso, os conceitos computação ubíqua e computação “pervasiva” não serão, apesar de parecidos, considerados sinônimos neste trabalho. A palavra “ubíquo” significa, segundo o dicionário Aurélio, “que está ao mesmo tempo em todo lugar”, enquanto que a palavra “pervasive” vem do inglês, não existindo na língua portuguesa, e

21

significa difundido, embarcado ou penetrante. Segundo (ARAUJO, 2003) a computação ubíqua é construída pela união das capacidades da computação pervasiva e móvel. Segundo ela, na computação pervasiva “(...) o computador está embarcado no ambiente de forma invisível para o usuário”. Ela diz também que: “(...) o computador tem a capacidade de obter informação do ambiente (...) e utilizá-la para (...) controlar, configurar e ajustar a aplicação para melhor atender as necessidades do dispositivo ou usuário.”

No que se refere à computação ubíqua, ela afirma que: “a computação ubíqua beneficia-se dos avanços da computação móvel e da computação pervasiva” e “a justificativa de (...) diferenciação desses termos é que um dispositivo que está embutido em um ambiente, não necessariamente é móvel”.

Desta forma, estes três conceitos além do conceito de computação tradicional podem ser simplificadamente ilustrados conforme a Figura 1 a seguir (LYYTTINEN; YOO, 2002):

Computação Pervasiva

Computação Ubíqua

Computação Móvel

Alto grau de “embarcamento” Computação Pervasiva

Computação Ubíqua

Mobilidade baixa

Mobilidade alta Computação Pessoal tradicional

Computação Móvel

Baixo grau de “embarcamento” Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior uma notação de conjuntos e na inferior as dimensões grau de mobilidade e de embarcamento em eixos ortogonais.

Contudo, para caminhar na direção da computação ubíqua, é necessário entender e conhecer o contexto no qual as interações ocorrem. Schilit et al. (SCHILIT et al., 1994) foram os primeiros a usar o conceito de contexto e aplicações cientes de contexto na computação. Em seu trabalho, definiram softwares cientes de contexto (CC) como aqueles capazes de

22

“adaptar-se à localização de uso, ao conjunto de pessoas e dispositivos próximos, assim como, às mudanças destes ao longo do tempo”. Menciona também o que chamou de aspectos de contexto como “where you are, who you are with and what resources are nearby”. Além disso, categorizou aplicações CC como uma combinação de duas dimensões. A primeira delas divide a tarefa em obtenção de informações ou execução de um comando. A segunda determina se a tarefa é realizada manual ou automaticamente. Dey e Abowd (DEY, A. K.; ABOWD, 1999) relatam que contexto foi definido usando sinônimos, como por exemplo ambiente ou situação do usuário ou da aplicação, o estado das coisas em torno da aplicação. Também relatam definições usando exemplos (localização, data e hora, temperatura, nível de ruído, etc.) que são incompletas, pois é difícil aplicá-las diante de novas informações. Devido a essas definições abstratas e/ou incompletas, eles definiram os conceitos de contexto, ciência de contexto e aplicações cientes de contexto: "contexto é qualquer informação que pode ser usada para caracterizar a situação de uma entidade. Entidade é uma pessoa, lugar ou objeto que é considerado relevante para a interação entre um usuário e uma aplicação, incluindo usuário e a aplicação." “um sistema é ciente de contexto se ele usa contexto para prover informações relevantes e/ou serviços ao usuário, onde relevância depende da tarefa do usuário.” (DEY, A. K.; ABOWD, 1999) Mais tarde, Becker e Nicklas (BECKER; NICKLAS, 2004) refinam as definições de Dey e Abowd adicionando o termo adaptação e substituindo os termos interação com usuário e serviços para o usuário por comportamento: “contexto é a informação que pode ser usada para caracterizar a situação de uma entidade. Entidades são pessoas, locais, ou objetos considerados relevantes para o comportamento de uma aplicação. A própria entidade é considerada como parte de seu contexto.” “uma aplicação é ciente de contexto se ela adapta seu comportamento conforme o contexto.” (BECKER; NICKLAS, 2004) Uma outra definição recente encontrada na literatura para ciência de contexto é dada por Naudet: “ciência de contexto é a habilidade de um sistema, conhecendo seu estado e seu ambiente, sentir, interpretar e reagir a mudanças em seu estado ou no ambiente em que está situado.” (NAUDET, 2011)

23

Note-se que esta última definição usa os termos estado e ambiente, onde tanto estado quanto ambiente dizem respeito às configurações num determinado momento, contudo a primeira refere-se ao próprio sistema e o segundo ao que o rodeia (estado externo). Esta definição também destaca a habilidade de sentir ou reconhecer o seu estado e o ambiente, a interpretação da nova configuração e a reação à esta mudança.

2.2

Aquisição, classificação e modelagem de contexto Além das definições de contexto apresentadas na seção anterior, vários outros aspectos

devem ser considerados. Esta seção abordará a aquisição de contexto (sensores, entradas do usuário e interpretadores), classificações de contexto e de aplicações cientes de contexto existentes na literatura e, por fim, modelagem de contexto. 2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores A obtenção de dados de contexto é feita por meio dos chamados sensores. Indulska e Sutton (INDULSKA, JADWIGA; SUTTON, 2003) definem o termo sensor como “um sistema que provê informação” e Baldauf et al. (BALDAUF et al., 2007) dizem que sensor “não se refere apenas a hardware, mas também a toda fonte de dados que possa prover informação de contexto utilizável”. Segundo ambos os trabalhos, sensores podem ser classificados, conforme sua natureza, em físicos, virtuais e lógicos: sensores físicos são aqueles baseados em hardwares capazes de capturar diversas propriedades físicas do ambiente como temperatura, aceleração, luminosidade, áudio, posição geográfica, data e hora, entre outros; sensores virtuais são aqueles que utilizam softwares ou serviços para fornecer informação de contexto, como por exemplo, obter localização do usuário a partir de sua agenda ou sistema de reservas de viagens; ou obter atividade do usuário a partir da movimentação do mouse, entradas de teclado ou modificações no sistema de arquivos do computador; sensores lógicos também são baseados em softwares mas descobrem contextos de mais alto nível a partir de inferências sobre contextos oriundos de sensores físicos ou virtuais e também de bases de dados. Por exemplo, descobrir que o usuário está em show de rock usando microfone, posição geográfica, a data e agenda.

24

Du & Wang (DU; WANG, L., 2008) utilizam ainda os termos sensor de hardware e sensor de software e os termos sensor local e sensor remoto. Os dois primeiros são autoexplicativos e os dois últimos são explicados a seguir: Sensores locais são sensores físicos localizados na mesma máquina ou dispositivo do usuário e cuja comunicação com aplicações é feita via chamadas ao sistema operacional ou através de uma API (ex. o microfone de um smartphone). Sensores remotos são aqueles externos ao dispositivo e que se comunicam com a aplicação por meio do protocolo IP, podendo até mesmo ser organizados numa rede de sensores. Um exemplo simples é um termômetro que mede a temperatura da casa do usuário enquanto ele está no trabalho e se comunica com seu Smartphone via Internet. Uma questão que pode ser feita é o que Du & Wang quiseram dizer com sensor físico, visto que sensores virtuais e lógicos também podem estar localizados no dispositivo do usuário e até mesmo utilizar chamadas nativas. Sendo assim, eles não seriam nem locais nem remotos. Outro trabalho mais recente de Bettini et al. (BETTINI et al., 2010) nem chega a citar classificações, dizendo que “algumas informações de contextos são sentidas” e que “sensores podem observar certos estados do mundo físico e prover acesso rápido quase em tempo real”. As expressões “estados do mundo físico” e “quase em tempo real” parecem representar apenas sensores físicos visto que sensores virtuais podem capturar dados de agenda (mundo não físico) e sensores lógicos podem precisar de bastante tempo de processamento (tempo não real). Mas Baldauf et al. diz que sensor não é apenas hardware (sensor físico) mas qualquer fonte de dados que possa prover contexto. Sendo assim, um simples sistema que armazena o perfil do usuário seria um sensor para Baldauf et al. e não seria para Bettini et al.. Pode-se também considerar que Bettini et al. usaram o verbo “podem” para não se comprometer, mas este parece não ser o caso pois na sequência eles falam sobre dados inseridos pelo usuário sem qualquer relação com o termo sensor. Estas discussões mostram que estes conceitos ainda não estão claramente definidos na literatura e, como este trabalho não pretende discutí-los nem utilizá-los, decidiu-se por utilizar conceitos mais simples. Assim, o termo sensor físico será usado para fontes que fornecem características físicas do ambiente. O termo sensor virtual não será utilizado por se considerar que estão numa região indefinida entre os físicos e lógicos. Para o conceito de sensor lógico será usado o termo interpretador de contexto, retirado do trabalho de Gu et al. (GU et al., 2005). Para fontes de dados pessoais inseridos diretamente pelo usuário será utilizado o termo

25

perfil de usuário. O termo bases de dados será utilizado para fontes de dados não associados a uma entidade específica, mas que podem vir a se tornar contexto após processamento por parte de interpretadores de contexto. Finalmente, o termo provedor de contexto, será utilizado como um termo genérico para sensores físicos, perfis, bases de dados e interpretadores de contexto, diferentemente da classificação de Gu et al. 2.2.2 Classificações de contexto Dey e Abowd (DEY, A. K.; ABOWD, 1999) dividiram contexto em dois tipos: primário e secundário. O contexto primário é divido em: localização – responde onde (where) uma entidade está; identidade – responde quem (who) é a entidade; tempo – responde quando (when). atividade – responde o que está ocorrendo ou o que o usuário está fazendo (what); Atividade e tempo não foram consideradas por Schilit et al. (SCHILIT et al., 1994), além disso, Ryan et al. (RYAN et al., 1998) tinham chamado atividade de ‘ambiente’, mas por considerar um sinônimo de contexto Dey modificou para atividade. Já o contexto secundário seria qualquer outro derivado destes, como por exemplo, previsão do tempo a partir de localização e data ou endereço a partir da identidade da entidade. O trabalho de Gu et al. (GU et al., 2005) apresenta uma divisão de contexto conforme a forma de obtenção do contexto em: contexto direto – que são obtidos diretamente do que ele designou provedores de contexto e que podem ser ainda divididos em sensed e defined; contexto indireto – onde são usados interpretadores de contextos que se aproveitam de contextos já conhecidos para inferir novos. Também descrito como deduced context. Assim, os sensed contexts seriam obtidos de sensores físicos; os defined contexts seriam aqueles fornecidos diretamente pelo usuário via formulários e praticamente constantes (perfis do usuário; ex. preferências pessoais) e os deduced contexts seriam obtidos de interpretadores de contexto. Henricksen et al. (HENRICKSEN, K. et al., 2004) apresenta denominações semelhantes: sensed, derived (=deduced), profiled (=defined) e static (semelhante ao defined mas de caráter impessoal). Esta classificação de Henricksen et al. é interessante pois separa informações de contexto provenientes de bases de dados em duas

26

partes: uma fornecida pelo usuário representando suas informações pessoais (profiled contexts) e outra fornecida por especialistas ou até mesmo usuários, mas representando informações de caráter coletivo ou impessoal (static contexts). Note que a divisão entre contexto primário e secundário é diferente da divisão entre contexto direto e indireto, pois a primeira se refere ao tipo da informação de contexto e, a segunda, à sua forma de obtenção. Como exemplo, considere que localização é sempre um contexto primário, mas pode ser direto no caso de coordenadas geográficas obtidas de um GPS, ou indireto no caso de lugares (ex. escola, praia) descobertos a partir de uma agenda ou de geocode reverso (endereço a partir de coordenadas). Korpipaa et al. (KORPIPAA et al., 2003) mencionam dois bons exemplos de contextos indiretos inferidos usando redes bayesianas. Um destes exemplos é descobrir se usuário está dentro de um local fechado ou em um local aberto utilizando intensidades sonora e luminosa, temperatura e posição do dispositivo móvel. Outro exemplo dado em seu trabalho é utilizar vários dados de áudio para determinar o tipo de som do ambiente (carro, elevador, conversa, música, entre outros). Existem diversas outras classificações. Por exemplo, contextos podem ser públicos, quando podem ser facilmente obtidos por qualquer pessoa (ex. tempo, guia de ruas, pontos de interesse) ou privados, quando requerem proteção (ex. localização e preferências do usuário); ou podem ter frequências de atualização alta (ex. sensores físicos), média (ex. aqueles modificados por humanos como eventos sociais e culturais) ou baixa (ex. preferências pessoais). A Figura 2 esquematiza estas divisões de contexto e associa aos provedores de contexto (sensores, interpretadores, etc.) quando aplicável, porém não há qualquer intenção de exaurir todas as possíveis classificações existentes na literatura. Note ainda que a classificação de Dey não foi associada a fontes de contextos visto que isso não possui uma regra. Por exemplo, a localização pode ser representada por coordenadas geográficas obtidas de um GPS (sensor físico) ou ser uma informação de alto nível, como universidade ou show de rock, inferida por um interpretador de contexto. Por fim, relembre que este trabalho não utilizará os termos sensor virtual e lógico para fontes de contexto, mas sim os termos sensor físico, perfil de usuário, base de dados e interpretador de contexto.

27

Primário

Localização, Identidade, Atividade, Tempo

Secundário

Obtidos dos primários

Direto

Sensed (sensores físicos) Defined (definido pelo usuário)

Indireto

Deduced (interpretadores de contexto)

Pública

Obtido por qualquer pessoa

Privada

Necessário permissão para acessar

Alta

Fornecido por sensores

Média

Fornecido por humanos

Baixa

Perfis, mapas e guias

Tipo

Obtenção Contexto

Visibilidade

Taxa de atualização

Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação, à forma de obtenção, à visibilidade e à taxa de atualização.

2.2.3 Classificações de aplicações cientes de contexto Em relação às aplicações cientes de contexto, Dey e Abowd (DEY, A. K.; ABOWD, 1999) classificaram-nas em três tipos: Apresentação de informações e serviços ao usuário Execução automática de serviços Marcação de contexto à informação para recuperação posterior Segundo Becker e Nicklas (BECKER; NICKLAS, 2004), o primeiro tipo (apresentação) representa, na verdade, dois tipos: seleção e apresentação. O primeiro ocorre quando uma aplicação escolhe uma informação ou serviço baseado no contexto. O segundo relaciona-se à forma como algo é apresentado ao usuário dependendo do contexto como, por exemplo, uma notificação motora e visual no cinema e notificação sonora quando usuário estiver dirigindo. As demais classificações são equivalentes. A execução de Dey e Abowd é denominada ação por Becker e Nicklas, mas ambas representam a execução automática de algum serviço como, por exemplo, reservar um livro na biblioteca ou comprar um numa livraria. Por último, a marcação inclui aplicações que apenas retem uma informação para que o usuário recupere posteriormente como, por exemplo, anotar nome da livraria, local e preço do livro para que o usuário consulte posteriormente e decida o que fazer.

28

Para Chen (CHEN, H. L., 2004) as aplicações podem ser classificadas ainda conforme sua arquitetura de aquisição de contexto em três formas: acesso direto aos sensores – a aplicação cliente obtém os dados dos sensores diretamente, sem qualquer camada de abstração o que torna difícil o uso perante grande concorrência de acesso ou uma vastidão de diferentes tipos de sensores. infra-estrutura de middleware – usa uma camada de abstração que permite extensibilidade e simplifica a reusabilidade, no entanto, consome mais recursos de processamento que podem levar a uma redução de desempenho em dispositivos menos potentes como smartphones. servidor de contexto – utiliza uma máquina rica em recursos computacionais responsável por obter dados dos sensores e disponibilizá-los de forma distribuída. Note que cada um dos métodos pode ser aplicado dependendo das características dos sensores e da aplicação. Por exemplo, se ambos estão em um único dispositivo móvel, não é necessário um servidor de contexto, mas se a aplicação está num smartphone e obtém dados de uma rede de sensores o servidor de contexto é de grande utilidade. 2.2.4 Comparações entre modelos de contexto Diversas abordagens para modelagem de contexto, ou seja, formas de representação que permitam processamento por máquinas já foram utilizadas (POSLAD, 2009; STRANG; LINNHOFF-POPIEN, C., 2004). As abordagens mais antigas não eram genéricas, ou seja, eram específicas para o domínio da aplicação sendo desenvolvida; enquanto que abordagens seguintes, apesar de não serem tão atreladas à aplicação, ainda eram limitadas (STRIMPAKOU, M. A. et al., 2006). Estes modelos englobam desde o simples modelo chave-valor até ontologias, passando por modelos hierárquicos (SGML e XML), modelos gráficos (UML e ORM), orientação a objetos e lógica. Strang e Linnhoff-Popien (STRANG; LINNHOFF-POPIEN, C., 2004) fizeram uma comparação entre estes modelos avaliando-os conforme os seguintes requisitos: Composição distribuída (dc) – capacidade de lidar com o dinamismo requerido pela computação ubíqua por meio de uso móvel e distribuído. Validação parcial (pv) – capacidade de descobrir erros e inconsistências na estrutura do modelo e nas suas instâncias.

29

Riqueza e qualidade da informação (qua) – dados oriundos de sensores podem apresentar variações conforme o tipo e o fabricante do sensor e até mesmo durante o funcionamento do mesmo sensor. Portanto, tal modelo deveria suportar tais informações. Incompletude e ambiguidade (inc) – o conjunto de informações de contexto que caracterizam uma entidade em algum momento pode ser ambíguo e/ou incompletas, inclusive quando provêm de uma rede de sensores. Portanto, mecanismos para filtrar e tratar estes dados são desejados. Nível de formalidade (for) – é importante que o modelo de contexto permita compartilhar a mesma interpretação dos dados e significados entre os agentes envolvidos (shared understanding). Aplicabilidade a ambientes já existentes (app) – é importante que um modelo de contexto seja factível, ou seja, sua implementação seja possível usando infraestruturas existentes. Dentre estes modelos, as ontologias foram consideradas as mais adequadas aos requisitos da computação ubíqua, conforme pode ser observado no Quadro 1. Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN, C., 2004)

Abordagem/requisitos

dc

pv

qua

inc

for

app

Modelos chave-valor

-

-

--

-- --

Modelos de marcação (XML)

+

++

-

-

+

++

Modelos gráficos

--

-

+

-

+

+

Modelos orientados a objetos

++

+

+

+

+

+

Modelos baseados em lógica

++

-

-

-

++

--

Modelos baseados em ontologia

++ ++

+

+

++

+

+

Mas tarde, Bettini et al. (BETTINI et al., 2010) fizeram uma comparação entre o modelo ontológico e outros dois modelos não discutidos pelo trabalho anterior. Este trabalho mais recente estabeleceu os seguintes requisitos que modelos de contexto devem viabilizar: Heterogeneidade – ser capazes de lidar com uma grande variedade de fontes de contexto (sensores físicos, contextos derivados de informações de contexto já existentes, bases de dados).

30

Mobilidade – ser capazes de se adaptar a mudanças frequentes de ambiente seja por parte de sensores que se movimentem seja por parte de aplicações que executem em dispositivos móveis. Relacionamentos e dependências – expressar variados tipos de relações entre informações de contexto, incluse dependências onde uma mudança em uma propriedade pode afetar outras. Temporalidade – permitir que aplicações acessem estados passados e até mesmo futuros (previsões); além disso, quando as atualizações tiverem frequência alta a ponto de não poderem ser armazenadas individualmente é necessário que haja possibilidade de se sumarizar tais informações. Imperfeição – dados de sensores possuem qualidade muito variável, podendo se tornar rapidamente obsoletos ou fornecer medidas conflitantes ou até mesmo incorretas; assim, é necessário que modelos de contexto sejam capazes de expressar a qualidade destes dados. Raciocínio – muitas vezes é necessário que aplicações utilizem técnicas de inferência para tomar certas decisões de adaptação a mudanças; além disso, é preciso que haja checagem de consistência do modelo de contexto e que isso seja computacionalmente eficiente. Usabilidade – modelos de contexto devem apresentar facilidade para que modeladores consigam traduzir conceitos do mundo real para seus construtos e aplicações possam utilizar manipular estas informações. Eficiência – deve permitir acesso eficiente às informações de contexto, mesmo diante de modelos enormes e muitos objetos; para isso, deve haver índices e caminhos de acesso que permitam a recuperação eficiente destes dados. O primeiro modelo avaliado é chamado Object-role Model, que utiliza Context Modeling Language (CML), uma linguagem com notação gráfica para apoiar análise e especificação de requisitos de contexto utilizando fatos e relações (HENRICKSEN, K; INDULSKA, J, 2004, 2006). CML é uma extensão do Object-Role Modelling (ORM) para modelagem conceitual de bancos de dados (HALPIN, 2001). Construiu-se um procedimento denominado Rmap para mapear CML para um esquema de banco de dados relacional (HENRICKSEN, K, 2003). CML é capaz de representar contextos estáticos, sentidos, fornecidos via perfil de usuário, derivados, assim como temporalidade e ambiguidade. Este último é realizado usando os chamados fatos alternativos e uma lógica trivalorada

31

(verdadeiro, falso e possivelmente verdadeiro) de maneira que, se uma propriedade de um indivíduo possui mais de um valor, ao se perguntar sobre a veracidade de apenas um destes valores a resposta é possivelmente verdadeiro, visto que não se pode determinar se apenas uma ou ambas as respostas são verdadeiras (por exemplo, valores sobre localização do usuário podem ser equivalentes como casa e cozinha ou conflitantes como casa e supermecado). Contudo, CML não permite representação de hierarquia, todos os tipos de contexto são fatos atômicos e não suporta interoperabilidade. Modelos espaciais se baseiam no fato de que muitas interações requerem alguma proximidade espacial que pode ser física ou virtual. Proximidade física pode ser representada por coordenadas geométricas ou simbólicas. A primeira representa pontos e áreas em sistemas métricos como o datum WGS84 (DECKER, B. L., 1984) utilizado por GPS e permite cálculo de distâncias e sobreposição numericamente. Coordenadas simbólicas usa identificadores para pontos e regiões e conceitos como sobreposição, tangenciamento, inclusão, etc. para relacioná-los, sendo conhecido como Region Connection Calculus (RCC) (RANDELL et al., 1992). Proximidade virtual representa informação de contexto não física, ou seja, associa localização a objetos virtuais que não estão presentes no mundo real, exemplo pode ser visto em (LEONHARDI et al., 1999). Inferências permitidas por estes modelos dizem respeito às relações espaciais entre objetos que permitem consultas relativas à posição de um objeto, objetos dentro de uma área e objetos próximos a um objeto, portanto, sua indicação é limitada a aplicações baseadas em localização ou que permitam tal analogia. Um problema deste modelo é o esforço necessário para obter dados de localização da informação de contexto e mantê-los atualizados (BETTINI et al., 2010). Modelos baseados em ontologias usam lógica de descrição (DL) que tenta contrabalançar expressividade da linguagem e complexidade da inferência usando ferramentas automatizadas. Bettini et al. diz que ao usar esta teoria, a linguagem OWL-DL permite (a) expressar dados de contexto complexos não representados por outros modelos; (b) compartilhar e/ou integrar contextos de diferentes fontes devido à sua alta formalidade semântica (interoperabilidade e heterogeneidade); (c) checar consistência da base e descobrir contextos implícitos. Apesar de modelos espaciais serem os mais indicados para dados geográficos, o modelo ontológico também pode tratar tal informação usando RCC (HAAV et al., 2009). Bettini et al. mostram ainda a falta de construtos para fazer composição de relações, que, foi adicionado na OWL 2. Eles também destacam que, apesar de OWL-DL ser decidível, a inferência é computacionalmente custosa para ser feita em tempo real e não

32

escalável para grandes quantidades indivíduos, além disso, a adição de regras pode torná-la indecidível. Adicionalmente, eles comentam que existe pouco suporte para tratar temporalidade. Realmente, não há suporte direto para dados temporais, contudo há abordagens sobre isso na literatura. Batsakis & Petrakis (BATSAKIS; PETRAKIS, 2010), por exemplo, apresentam uma extensão OWL e SPARQL para representar tanto dados temporais, usando as relações temporais de Allen (ALLEN, 1984), quanto RCC. O Quadro 2 resume as conclusões de Bettini et al. quanto aos modelos e requisitos, de modo que os sinais “+” e “–” representam, respectivamente, cumprimento ou não do requisito enquanto “~” representa cumprimento parcial do requisito.

Mobilidade

Relacionamentos

Temporalidade

Imperfeição

Raciocínio

Usabilidade

Eficiência

~

~

+

~

~

+

~

Espacial

~

+

~

+

~

-

~

+

Ontológico

+

-

+

-

-

+

~

-

requisitos

+

e

Object-role

Abordagens

Heterogeneidade

Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010)

Devido ao fato de todos os modelos apresentarem fraquezas, Bettini et al. sugerem um modelo híbrido em três camadas que deve ser o futuro dos middlewares cientes de contexto. A primeira captura e funde dados de sensores, a segunda efetua integração de dados de diversas fontes (sensores da primeira camada, bases relacionais ou de triplas) e inferência com vocabulários simples podendo tratar dados incertos, ambíguos e, inclusive, conflitantes. A terceira camada usaria inferência com ontologias para checagem de consistência em um nível mais alto de abstração. Aplicações se comunicariam apenas com a segunda camada que seria responsável por se comunicar com as duas outras camadas. Neste trabalho apenas ontologias com regras serão utilizadas, mas devido ao carater distribuído da arquitetura proposta tal modelo híbrido pode ser concretizado em abordagens futuras. Além disso, este trabalho visa mostrar que estas camadas podem ser formadas por pequenos módulos espalhados pela Web que se comunicam usando uma linguagem de comunicação padronizada (RDF/SPARQL).

33

2.2.5 Ontologias de modelagem de contexto Ontologia é um termo oriundo da filosofia para referir-se ao assunto de existência. Nas ciências da computação e da informação, ontologias são usadas para expressar o conhecimento sobre conceitos, seus atributos e também as relações entre eles (STRANG et al., 2003). De forma mais detalhada, é uma representação formal e explícita de uma conceitualização compartilhada. Esta conceitualização compartilhada refere-se a algum domínio do conhecimento cujos conceitos e relações sejam consensuais, ou seja, aceitas por um grupo e não apenas por um indivíduo. Os termos explícita e formal dizem, respectivamente, que esta representação deve (1) ser explicitamente definida e (2) entendida por máquinas, o que exclui o uso linguagem natural. (PERTTUNEN et al., 2009) Uma ontologia é usada, então, para definir um domíno e para raciocinar sobre este domínio (PATNI et al., 2010). Atualmente, a linguagem OWL, fundamentada na lógica de descrição, é usada para representar e instanciar ontologias na Web e ambas serão discutidos na seção 2.3. Diversas ontologias de contexto já foram utilizadas na literatura e algumas delas serão comentadas aqui por ordem cronológica, mas antes, vale ressaltar que uma informação de contexto tem diversas propriedades atribuídas a ela. Segundo (BALDAUF et al., 2007) as mais triviais são: Tipo é sua categoria ou classe como temperatura, localização, preferência pessoal, e pode ser organizado numa hierarquia em árvore; Valor representa o dado propriamente dito obtido por um sensor; Marca de tempo identifica quando o contexto foi obtido; Fonte identifica quem ou qual sensor obteve tal informação; Confiança define o grau de incerteza do dado de contexto entre 0 e 1. Uma das primeiras ontologias de contexto foi a CoOL (Context Ontology Language) baseada no modelo Aspect-Scale-Context (ASC) (STRANG et al., 2003). Cada aspecto reúne escalas e cada escala reune informações de contexto. Portanto, aspecto é um conjunto de uma ou mais escalas, escala é um conjunto de objetos que definem o intervalo de informações de contexto válidas para esta escala. Por exemplo, o aspecto GeographicCoordinateAspect permite as escalas WGS84 e GaussKrueger, e infomação de contexto é um valor numa dada escala como GaussKruegerCorrinate(367032,533074) para GaussKrueger, e “10” para MeterScale. Uma informação de contexto A por ter outras infomaçoes de contexto caracterizando a qualidade desta informação A, que podem ser intríssecas como erro mínimo,

34

erro médio e marca de tempo ou genéricas através da relação hasQuality. O conceito de IntraOperation permite criar funções de mapeamento entre escalas de um mesmo aspecto (ex. conversão entre WGS84 e GaussKrueger). Para mapear escalas de diferentes aspectos existe o conceito de InterOperation (ex. KilometerPerHourScale de SpeedAspect representado como SpatialDistanceAspect e DurationAspect). Observa-se assim que CoOL é falha em expressar contextos abstratos como atividade do usuário (STRIMPAKOU, M. A. et al., 2006). A ontologia CONON (CONtext ONtology) descreve uma ontologia genérica de contexto (upper ontology) e uma específica para o domínio residencial (WANG, X. H.; ZHANG, D. Q. et al., 2004). A ontologia genérica basicamente se restringe em definir uma hierarquia do conceito chamado entidade de contexto que se especializa em entidade computacional, localização, pessoa e atividade. Uma entidade computacional pode ser serviço, aplicação, dispositivo, rede e agente. Localização pode ser interna (indoor) ou ao ar livre (outdoor). Atividade pode ser deduzida ou agendada. Resumidamente, a ontologia específica de domínio para residências inclui as classes televisão e celular (dispositivos), festa e aniversário (atividades agendadas), cozinhar e tomar banho (atividades deduzidas), jardim (espaço ao ar livre), sala ou cozinha (espaço fechado), entre outros; e propriedades, como localização de uma entidade computacional ou usuário, estado de portas e janelas como aberto ou fechado, entre outras. As ontologias SOUPA (Standard Ontology for Ubiquitous and Pervasive Applications) (CHEN, H.; PERICH; et al., 2004) utilizam conceitos de modelos, ontologias e vocabulários anteriores como FOAF2, OWL-Time (PAN; HOBBS, 2003), OpenCyc (LENAT, 1995), RCC, CoBrA-ONT(CHEN, HARRY et al., 2003) e BDI (BRATMAN, 1999; RAO; GEORGEFF, 1991), e é divida em dois subconjuntos: SOUPA-Core e SOUPAextension. A primeira define vocabulários genéricos para: Pessoas – informações de contato e perfil; Políticas e ações – políticas de privacidade e segurança com uma lógica de descrição para gerar ações a serem executadas por agente baseadas nestas políticas; Agentes e BDI – agentes e seus estados mentais: belief-desire-intention (crenças, desejos e intenções);

2

The Friend of a Friend Vocabulary: http://www.foaf-project.org/

35

Tempo – define conceitos para expresar tempo (instante e intervalo) e relações temporais (antes, depois, inicia antes de, etc.); Espaço – representa medidas geográficas, relações entre regiões espaciais, mapeamento entre coordenadas geográficas e simbólicas; Eventos – define eventos temporais (eventos que ocorrem em um instante ou que duram um intervalo de tempo) e espaciais (que ocorrem em algum lugar conhecido); SOUPA-extension estende SOUPA-Core para certos tipos de aplicação e abrange domínios como reuniões e agendas, descrição de documentos, captura de imagem e RCC. Para maiores detalhes consulte (CHEN, H.; PERICH; et al., 2004). A ontologia COMANTO (COntext MAnagement oNTOlogy) é semelhante à CONON com algumas extensões. Também estabelece uma classe entidade de contexto que se especializa em diversos outros como atividade, pessoa, etc. Atividade do usuário por ser física como assistindo televisão ou uma atividade de serviço, ou seja, relacionada a um serviço onde pessoas podem se registrar para usufruir. Tempo representa um instante de tempo e uma atividade possui um tempo inicial e final. Objeto físico pode ser uma mesa ou celular, mas se especializa em dispositivo que pode ter sensores atrelados e estar conectado a um rede. Um smartphone é um dispositivo e, portanto, um objeto físico, mas o mesmo não ocorre com a mesa que é apenas um objeto físico. Objeto físico, pessoa e atividade podem estar associados a um lugar que representa uma localização simbólica ou geográfica. Preferências do usuário se especializam em quatro outras classes que são relacionadas a dispositivos, rede, serviços ou outra coisa que não se relacione a nenhum destes. (ROUSSAKI, I. et al., 2006; STRIMPAKOU, M. A. et al., 2006) Ontonym é um conjunto de ontologias que tenta representar as necessidades mais comuns das aplicações cientes de contexto: tempo, espaço, pessoas (ou identidades) e eventos (ou atividades) (STEVENSON et al., 2009). Para representar tempo e eventos, ela se utiliza da OWL-Time (PAN; HOBBS, 2003) da mesma forma que a ontologia SOUPA. Para modelagem espacial utiliza um modelo bastante elaborado (YE et al., 2007) que reúne representação geométrica (ou geográfica) e simbólica de trabalhos anteriores (HIGHTOWER; BORRIELLO, 2001; JIANG; STEENKISTE, 2002) e adiciona representações de relação espacial como continência, adjacência e conectividade, este útlimo um caso especial de adjacência onde é possível cruzar duas regiões. Para modelagem de pessoas, os autores descrevem que, excluindo-se dados específicos das aplicações, é necessário representar

36

identidade, posse de dispositivos, detalhes pessoais e relações sociais. Para isso consideram uso de URIs para identificar pessoas, versões adaptadas das ontologias vCard 3 e PIM4 do W3C para detalhes pessoais e a ontologia Relationship 5 para descrever relacionamentos interpessoais. Ontonym inclui ainda ontologias para representação de (1) sensores e suas medições (observações) com respectiva taxa de atualização, precisão e acurácia; (2) dados de proveniência como autoria e data de criação ou modificação; (3) dispositivos e ligação com seu possuidor visto que eles funcionam como uma ponte para o usuário que geralmente está carregando o aparelho; e (4) recursos na Web como formato de arquivo, idioma, direitos de acesso, e nomes legíveis para humanos. O trabalho de Naudet (NAUDET, 2011) apresenta uma ontologia com uma visão um pouco diferente, centrada nos conceitos de entidade (Entity), elemento de contexto (Context Element) e situação (Situation). Um elemento de contexto (CE) é “qualquer coisa desde um simples valor numérico ou amostra de sinal (...) até uma afirmação ontológica (...) útil para determinar a situação de uma entidade” e contexto é “um conjunto de elementos de contexto disponíveis num dado momento, que será usado como base de conhecimento para determinar a situação de uma entidade”. A motivação para sua abordagem é que ontologias anteriores são dedicadas apenas a elementos de contexto (SOUPA e Ontonym) ou entidades de contexto (CONON e COMANTO) e ele pretende reunir estes conceitos em uma ontologia de contexto genérica unificante. Para isso, além dos conceitos já descritos, ele define atividade (Activity), estado (State) e ambiente (Environment). Ambiente é tudo que rodeia um sistema e o influencia sendo a entidade parte dele, estado refere-se à estrutura da entidade e atividade refere-se ao seu comportamento, ou seja, suas ações. Além disso, CE = onde CI é a informação carregada (carried information), t é o instante de tempo em que a informação foi obtida, vp é o período de validade da informação, loc é a localização onde a informação é valida, r é um fator de confiabilidade, obs é a observação de onde a informação se originou, e src é outro CE que porventura tenha gerado/deduzido este CE. Alguns destes valores podem ser omitidos, por exemplo, a ausência de vp ou loc indica que a informação é válida independentemente do tempo ou localização, e a ausência de obs indica que a informaçao não foi obtida de um sensor. Existem ligações com outros vocabulários e ontologias: Semantic Sensors Network Ontology do W3C para representação de observações e 3

vCard ontology: http://www.w3.org/2006/vcard/

4

W3C PIM: http://www.w3.org/2000/10/swap/pim/contact

5

RELATIONSHIP – A vocabulary for describing relationships between people: http://vocab.org/relationship

37

sensores, FOAF para especializar o conceito de entidade usando os conceitos de agente e pessoa, Ontonym Location para localização de entidade e CE, OWL-Time para instante de medição e validade de um CE. Com base nos diversos trabalhos aqui apresentados, deve-se ressaltar que apesar de estas ontologias descreverem medições de sensores, tais dados podem rapidamente atingir grandes quantidades e inviabilizar inferências OWL usando a ontologia em questão. Portanto, neste caso, tais ontologias deveriam ser utilizadas apenas para representação na troca de informação e outros mecanismos devem ser usados para tratar estes grandes volumes de dados. Outro importante aspecto a ser considerado é a pouca quantidade de informação e documentação, quase inexistente, da maioria delas. Como a Ontonym foge a esta regra, possuindo alguma documentação na Internet6, este trabalho utilizará um subconjunto dela na seção 4.3.1.1 (página 118). Apesar de fora do escopo do trabalho, ao modelar ontologias mais complexas é importante considerar aspectos abordados pelas ontologias de fundamentação como princípio de identidade e aspectos temporais como fases e papéis de uma entidade. Isso pode ser visto em trabalhos como a Unified Foundational Ontology (UFO) (GUIZZARDI; WAGNER, 2010).

2.3

Web Semântica e Dados Ligados A Web atualmente conhecida (Web de Documentos) é projetada apenas para

entendimento humano, ou seja, não expressa o significado de forma que possa ser acessado e processado por máquinas em qualquer parte da Web. Desta forma, dados, metadados e regras estão confinados em pequenos conjuntos, geralmente dentro de servidores, e podem ser processados apenas por softwares especificamente desenvolvidos para obter e interpretar estes dados. Vendo este cenário, Tim Berners-Lee introduziu, em 2001, os conceitos da Web Semântica (WS) como uma extensão da Web então existente (BERNERS-LEE et al., 2001). Assim, segundo ele, uma vez que tais dados e metadados estejam disponíveis na Web é possível criar agentes que são “programas que coletam conteúdo da Web de diversas fontes, processam a informação e trocam os resultados com outros programas” de forma que “mesmo agentes que não foram explicitamente desenvolvidos para trabalhar junto possam transferir dados entre si quando estes dados vêm com semântica”.

6

ONTONYM – Ontologies for pervasive computing: http://ontonym.org

38

Apesar de a WS ser apenas uma visão, conceito ou ideia, conforme descrito no parágrafo anterior, este trabalho não tratará do ponto de vista filosófico e, portanto, não diferenciará WS e as tecnologias atuais que a implementam (RDF, OWL, SPARQL). As próximas seções descreverão os conceitos básicos da WS e uma pequena parte da teoria por trás dela, além de um pouco do que vem sendo feito com a iniciativa da Web de Dados ou Dados Ligados. 2.3.1 Conceitos básicos Assim como a Web de Documentos, a WS propõe o uso de identificadores, formatos e protocolos padronizados para descrever e interligar recursos disponibilizados na Web. Isto quer dizer que assim como existem as linguagens HTML, CSS e Javascript e os protocolos HTTP e HTTPS novas linguagens e protocolos também serão padronizados e passarão a ser adotados. Observe, contudo, que como a nova Web deve ser uma extensão da Web atual, todas estas linguagens devem coexistir. Os elementos mais básicos da Web Semântica são os identificadores ou URIs (Uniform Resource Identifiers) e as triplas. URIs identificam recursos enquanto as triplas provêm informações sobre estes recursos. URI são bem semelhantes aos endereços eletrônicos usados para acessar páginas na Web, mas não precisam ser derreferenciáveis como as URLs, ou seja, não precisam retornar uma página HTML quando digitadas em um navegador. Um exemplo de URI que representasse a professora Adriana Vivacqua dentro do PPGI poderia ser: http://greco.ppgi.ufrj.br/resource/Professor/AdrianaVivacqua Adicionalmente, é possível definir um prefixo que represente a parte inicial do URI para escrever o URI em uma forma compacta. Por exemplo, se o prefixo greco for definido como http://greco.ppgi.ufrj.br/resource/Professor/, o URI acima pode ser escrito como greco:AdrianaVivacqua. Triplas são compostas por três partes: sujeito, predicado e objeto. Sujeito e predicado sempre são identificadores. O primeiro identifica um recurso qualquer na Web (como a professora) e o segundo identifica um recurso especial chamado propriedade. O objeto pode ser um URI para um recurso ou um literal (número, texto, data, etc.). O exemplo de tripla a seguir informa o nome completo da professora Adriana Vivacqua (parte do URI do sujeito omitido para caber na linha):

39

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 . Ao escrever uma tripla, as formas longas devem usar os símbolos de menor e maior como delimitadores. O nome entre aspas é denominado literal. Um conjunto de triplas forma um grafo, de maneira que os vértices representam sujeitos e objetos, e as arestas representam predicados. O padrão RDF (Resource Description Framework) aplica estes conceitos para representar informações na Web por meio de notações XML, Turtle, N3 e NTriplas. A seguir pode-se observar um exemplo utilizando as notações Turtle e XML: 1 2 3 4 5

@prefix foaf: . @prefix greco: . greco:AdrianaVivacqua foaf:name "Adriana Santarosa Vivacqua" ; foaf:homepage .

1 2 3 4 5 6 7 8 9 10 11 12

Adriana Santarosa Vivacqua

Como se pode observar uma sequência de triplas que compartilham o mesmo sujeito pode ter sua escrita simplificada por meio da separação usando ponto-e-vírgula (;) e omissão deste sujeito. O mesmo ocorre quando ambos o sujeito e o predicado se repetem, mas utilizase a vírgula como separador. O RDF por si só permite apenas descrever recursos na Web, ou seja, não provê mecanismos para descrever um esquema a ser obedecido, como é comum em bancos de dados relacionais e linguagens de programação. Para este fim, foi criado o padrão RDF Schema (RDFS) que permite definir classes (conceitos) e suas propriedades, hierarquias entre classes e propriedades, além dos tipos aceitos no sujeito (rdfs:domain) e intervalos de valores aceitos no objeto (rdfs:range) das triplas.

40

Adicionalmente uma linguagem para representação de ontologias foi proposta. Originalmente usada em filosofia como a disciplina que estuda “a natureza da existência” e “quais tipos de coisas existem”, pesquisadores de IA e da Web adotaram esta palavra para a descrição formal da relação entre termos (conceitos, classes, propriedades) e regras que permitam processos de inferência (deduções lógicas) sobre estes termos (BERNERS-LEE et al., 2001; RUSSELL; NORVIG, 1995). Entre 2001 e 2004 o W3C manteve um grupo de trabalho para desenvolver uma linguagem (e também uma sintaxe baseada em RDF) para descrever ontologias que culminou com a criação da OWL (Web Ontology Language). A OWL se tornou o padrão para representação de ontologias que permite, entre outras funcionalidades, descrever (a) características de simetria, reflexividade e transitividade de propriedades; (b) equivalência e diferença entre classes e instâncias; e (c) operações de interseção, união e complemento sobre classes (que são análogas a conjuntos). A ferramenta capaz de processar ontologias e regras de forma automatizada é denominada motor (ou máquina) de inferência ou reasoner. Há motores de inferência para lógica de descrição (teoria base da OWL), para sistemas de regras ou híbridos. Maiores detalhes sobre DLs e regras serão apresentados na seção 2.3.2 a seguir. SPARQL é a linguagem de consulta para bases de triplas, que tem alguma similaridade com SQL. SPARQL permite a execução de quatro tipos de consulta: SELECT, ASK, DESCRIBE e CONSTRUCT. O primeiro gera resultados no formato de tabelas; o segundo responde uma pergunta com verdadeiro ou falso; o terceiro responde um conjunto de triplas (grafo) sobre determinado recurso (URI); o último utiliza modelos (templates) de triplas e retorna um grafo contendo a união de todos os resultados, funcionando assim, como uma forma de mapeamento. Bases de triplas podem ser consultadas via HTTP por meio do uso de serviços REST que implementem o protocolo SPARQL do W3C (CLARK et al., 2008)7. Tais serviços são conhecidos como SPARQL Endpoints. Há também o SPARQL Update8 para realizar inserções e remoções em bases de triplas, mas ela está fora do escopo deste trabalho.

7

O protocolo para SPARQL 1.0 é uma recomendação e foi citado como referência. A versão para SPARQL 1.1 ainda é um rascunho de trabalho e pode ser encontrada em http://www.w3.org/TR/sparql11-protocol. 8

SPARQL Update - http://www.w3.org/Submission/SPARQL-Update/

41

2.3.2 Lógica de Descrição (DL) As DLs são formalismos para representação do conhecimento (KR – Knowledge Representation) que sucederam os sistemas de frames e redes semânticas que falhavam em apresentar uma semântica formal (BAADER et al., 2008). Uma semântica formal permite definir uma linguagem ou conjunto de símbolos e operações com interpretações lógicas para conceitos e relações existentes no mundo. A lógica de predicados estuda tais representações formais, através da lógica proposicional, lógica de primeira ordem, entre outras. DL é um subconjunto da lógica de primeira ordem que tenta conciliar expressividade com complexidade e decibilidade, pois parte do princípio que do ponto de vista computacional não adianta ter uma lógica com alta capacidade de expressão se o sistema precisar de quantidades de tempo e espaço astronômicas para responder perguntas, ou nem ser capaz de respondê-las (NARDI; BRACHMAN, 2003). As próximas subseções tentarão apresentar conceitos básicos de DL utilizados na OWL, fazendo analogias para facilitar a compreensão sempre que possível. 2.3.2.1 Conceitos de TBox, ABox e KB Assim como na matemática existem conjuntos, elementos e funções, e na programação orientada a objetos existem classes, instâncias e métodos, DL também possui seus equivalentes. A terminologia, ou seja, o vocabulário do domínio da aplicação consiste de conceitos e relações ou papéis (roles) que podem ser combinados para representar descrições mais complexas. Esta terminologia é denominada TBox (terminological box). Ao especificar os elementos ou indíviduos existentes na aplicação, cria-se o chamado ABox (assertion box) ou conjunto de afirmações sobre fatos do mundo. A união do TBox com o ABox é chamada base de conhecimento ou KB (knowledge base). Desta forma sistemas DL usam o TBox e o conhecimento explícito do ABox para descobrir conhecimento implícito e responder perguntas. (BAADER; NUTT, 2003) Para exemplificar, considere o conceito pai (Father) como uma pessoa (Person) do sexo masculino (Male) que possui pelo menos um filho (hasChild). Isto pode ser representado na notação DL como (TBox): Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person Aqui, o símbolo ⊓ representa a interseção entre conjuntos e a expressão ∃hasChild.Person representa o conjunto de indivíduos que possuem pelo menos uma relação

42

hasChild com algum individuo do conceito pessoa. Suponha agora que o ABox possua as seguintes afirmações dizendo que JOHN e MARY são pessoas, JOHN é do sexo masculino e JOHN tem filha MARY: Person(JOHN) Male(JOHN)

Person(MARY) hasChild(JOHN, MARY)

Com base nisso alguém poderia perguntar ao KB se JOHN é pai e a resposta seria sim, pois JOHN é Person e Male (interseção) e tem um filho que é Person, satisfazendo a definição de Father. Se a afirmação Male(JOHN) fosse retirada, seria impossível responder à pergunta, mas neste caso surge a questão sobre que resposta deveria ser data pelo sistema: (1) JOHN não é pai, (2) não sei se JOHN é pai. Esta é a grande diferença entre os bancos de dados relacionais e bases de representação de conhecimento. Enquanto o primeiro reponde (1), o segundo responde (2). A primeira forma é dita mundo fechado (closed world assumption), pois considera que toda a informação sobre o mundo está presente na base, e as segunda é dita mundo aberto (open world assumption), pois considera que a base de conhecimento não é completa, ou seja, não possui toda a informação sobre o mundo. DL e OWL usam a hipótese do mundo aberto. Considere agora a adição das seguintes afirmações ao ABox: Father(MARY)

¬Male(MARY)

Isto diz que MARY é pai e não é do sexo masculino, mas o TBox diz que todo pai é do sexo masculino, tornado o KB inconsistente. Neste caso foi fácil observar este problema mas conforme a quantidade de indivíduos no KB aumenta se torna impossível descobrir inconsistências sem métodos automatizados. Inconsistência é um dos tipos de problemas de inferência tratados pelos motores de inferência e que serão apresentados na seção 2.3.2.3. 2.3.2.2 Nomenclatura, síntaxe e semântica As DLs são nomeadas conforme os contrutos que oferecem. A DL mais básica é chamada AL (Attributive Language) e conforme mais construtos são adicionados, adicionamse letras ao nome da DL (BAADER; NUTT, 2003). A linguagem ALC (Attribute Language with Complements), por exemplo, é a adição de negação (complementos) à AL. Muitas vezes uma mesma linguagem possui mais de um nome, por exemplo, ALC é equivalente a ALUℰ e S é equivalente à ALC

R+.

A partir daqui será usada uma convenção de letras: A e B serão

usadas para representar conceitos atômicos ou primitivos, C e D para descrições de conceitos

43

(definidos com base em outros), r e s para relações atômicas. Um conceto-ALC é definido como: ⊤ – conceito universal (contém todos os indivíduos); ⊥ – conceito vazio (não contém indivíduos); C ⊓ D – interseção dos indivíduos dos conceitos C e D C ⊔ D – união dos indivíduos dos conceitos C e D ¬C – indivíduos que não estão em C ∃r.C – indivíduos que possuem pelo menos uma relação r com um indivíduo de C (quantificação existencial completa) ∀r.C – indivíduos que se possuírem uma relação r esta é apenas com indivíduos de C (restrição de valor) Uma interpretação I = (ΔI, •I) consiste de um conjunto de indivíduos ΔI (domínio da interpretação) e uma função •I que mapeia todo conceito-ALC a um subconjunto de ΔI e todo nome de relação a um subconjunto de ΔI × ΔI (BAADER et al., 2008). Desta forma, pode-se escrever a interpretação matemática de qualquer conceito-ALC. Veja alguns exemplos: ⊤I = ΔI

⊥I = ∅

(C ⊓ D) I = CI ∩ DI

(∃r.C) I = {x ∈ ΔI | Existe algum y ∈ ΔI tal que (x, y) ∈ rI e y ∈ CI } (∀r.C) I = {x ∈ ΔI | Para todo y ∈ ΔI, se (x, y) ∈ rI então y ∈ CI } Um axioma é uma afirmação sobre o mundo e pode ser terminológico ou assertivo, dependendo se tratam de conceitos ou indivíduos. O axioma terminológico pode ser: Inclusão de conceitos (hierarquia): C ⊑ D Inclusão de relações (hierarquia): r ⊑ s Equivalência de conceitos: C ≡ D Equivalência de relações: r ≡ s Já o axioma assertivo ou fato pode ser da forma C(a), r(a, b), a = b e a ≠ b. O TBox é o conjunto de axiomas terminológicos e o ABox o conjunto de axiomas assertivos. Uma interpretação I é um modelo de um axioma C ⊑ D se CI ⊆ DI, e um modelo de um TBox se é um modelo de todos os axiomas deste TBox. Uma interpretação I é um modelo de um axioma assertivo C(a) se aI ∈ CI, e um modelo de um ABox se é um modelo de todos

44

os axiomas deste ABox. Analogamente, uma interpretação I é um modelo para uma base de conhecimento se é um modelo tanto do seu TBox quanto do seu ABox. Desta forma, aproveitando o exemplo anterior, uma interpretação I 1 = (Δ1I, •1I), onde: Δ1I = {JOHNI, MARYI} •1I = { Person1I = {JOHNI, MARYI}, Male1I = {JOHNI}, Father1I = {JOHNI}, hasChild1I = {(JOHNI, MARYI)} } é um modelo para a base de conhecimento formada pelo TBox: Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person e pelo ABox: Person(JOHN)

Male(JOHN)

Person(MARY)

hasChild(JOHN, MARY)

Esta outra interpretação I 2 = (Δ2I, •2I) também é um modelo para este mesmo KB: Δ2I = {JOHNI, MARYI} •2I = { Person2I = {JOHNI, MARYI}, Male2 I = {JOHNI}, Father2I = {JOHNI}, hasChild2I = {(MARYI, MARYI)} } contudo não deveria, pois MARY é filha dela mesma. Isto ocorre porque não há um axioma restritivo que diga que a propriedade hasChild é irreflexiva. Este é um problema gerado pela falta de expressividade da linguagem utilizada (ALC). Existem inúmero outros problemas semelhantes que foram resolvidos a partir de DLs mais expressivas. Algumas desteas extensões serão apresentadas na seção 2.3.2.4. 2.3.2.3 Problemas de inferência Na seção 2.3.2.1 foi mostrado um exemplo de incosistência do KB. O algoritmo de Tableau resolve este e outros problemas comuns. Nesta seção estes problemas serão

45

apresentados com base nos conceitos de interpretação e modelo. Para isso considere um KB K = (T, A) onde T é um TBox e A um ABox, conceitos C e D, indivíduos a e b e uma relação r. Consistência: K é consistente se ele possui um modelo; Satisfatibilidade: C é satisfatível em relação a K se existe um modelo I de K com CI ≠ ∅ (I é um modelo de C em relação a K ) e escreve-se K ⊨ C ≢ ⊥; Subsumption9: C é subconjunto de D (C ⊑ D) em relação a K se CI ⊆ DI para todos os modelos I de K (escreve-se K ⊨ C ⊑ D, ou seja, C ⊑ D é provável a partir de K); Equivalência: C e D são equivalentes em relação a K se um é subconjunto do outro, ou seja, CI = DI para todos os modelos de I de K (escreve-se K ⊨ C ≡ D); Disjunção: C e D são disjuntos em relação a K se CI ∩ DI = ∅ para todos os modelos I de K e escreve-se K ⊨ C ⊓ D ≡ ⊥; Instância: a é instância de C em relação a K se aI ∈ CI para todos os modelos I de K e escreve-se K ⊨ C(a). Analogamente, (a,b) é instância de r em relação a K if (aI,bI) ∈ r para todos os modelos I de K e escreve-se K ⊨ r(a,b). Trabalhos mostram que estes problemas podem ser reduzidos a apenas um deles (BAADER; NUTT, 2003; HORROCKS, I et al., 2006). Por exemplo, a redução à subsunção (reduction to subsumption) apresenta as seguintes transformaçoes: (i)

C ≡ ⊥ ⇔ C ⊑ ⊥;

(insatisfatibilidade)

(ii)

C ≡ D ⇔ C ⊑ D e D ⊑ C;

(equivalência)

(iii)

C ⊓ D ≡ ⊥ ⇔ (C ⊓ D) ⊑ ⊥.

(disjunção)

Há também a redução à insatisfatibilidade (reduction to unsatisfiability) que é utilizada no algoritmo Tableau:

9

(i)

C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥

(subsumption)

(ii)

C ≡ D ⇔ (C ⊓ ¬D) ≡ ⊥ e (¬C ⊓ D) ≡ ⊥

(equivalência)

(iii)

(C ⊓ D) ⊑ ⊥ ⇔ C ⊓ D ≡ ⊥

(disjunção)

Subsumption significa, na filosofia, ato de um objeto cair sob um conceito. Nada mais é que a relação de subconjunto, contudo, decidiu-se por não criar uma tradução para o termo.

46

Qualquer um destes pode ser reduzido à consistência do KB. Para isso, considere que se queira saber se C é um subconjunto de D com relação a K (K ⊨ C ⊑ D). Usando a redução à insatisfatibilidade (i), sabe-se que C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥ (veja Figura 3). Portanto, isto equivale a verificar se um KB K’ = (T, A ⋃ { (C ⊓ ¬D)(x) }) é inconsistente para algum indivíduo x. Para isso, o algoritmo tenta construir um modelo para K’ utilizando regras de expansão para lidar com os construtos da linguagem, verificação de condições conflitantes para descobrir inconsistência e bloqueios para impedir aplicações infinitamente repetitivas das regras de expansão. Se um modelo for obtido significa que a interseção não é vazia, logo C não é subconjunto de D; caso contrário, C é subconjunto de D. O algoritmo deve considerar que C e D podem ser descrições de conceitos complexas com quantificação existencial, negação, união, interseção ou quaisquer outros construtos existentes em linguagens mais expressivas que a ALC. Um problema investigado antes de aumentar a expressividade (i.e. adicionar um novo construto) de uma DL é verificar se a linguagem continua decidível, ou seja, se é possível adicionar regras de expansão e bloqueios ao algoritmo de forma que ele sempre termine. Para maiores detalhes recomenda-se ler (BAADER et al., 2008; BAADER; NUTT, 2003). C ⊓ ¬D ≢ ⊥

C⊑D ⇔ C ⊓ ¬D ≡⊥ ¬D D C

¬D C D

Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅.

2.3.2.4 Extensões da linguagem ALC Conforme já discutido, a linguagem ALC possui baixa expressividade para representação de conhecimento. Por este motivo vários trabalhos com o intuito de prover novas funcionalidades mantendo decidibilidade foram feitos, chegando-se ao que é apresentado no Quadro 3 que resume construtos e axiomas existentes em diversas DLs e que são usados em OWL-DL. O quadro apresenta descrição, notação, nomenclatura e se é um axioma ou construto. Pode-se verificar que AL contém os conceitos universal e vazio, assim

47

como negação atômica, interseção, restrição de valor, quantificação existencial limitada e equivalência e hierarquia de conceitos. Expressividades adicionais incluem quantificação existencial completa (ℰ), complemento (C ), união de conceitos (U), restrições de número qualificadas (Q ) ou não (N ), transitividade (R+), inversibilidade (I), equivalência e hierarquia (H) de relações, e inclusão de relações complexas para composição de relações (R ). Dentre elas podem-se destacar as restrições de número a composição de relações. As primeiras representam subconjuntos de ΔI cujos indivíduos devem possuir uma quantidade mínima ou máxima de ocorrências numa dada relação. Estas restrições podem ser qualificadas ou não. Exemplo: 1. Parent ≡ ≥1hasChild 2. Orphan ≡ ≥1hasParent.Dead ⊓ ≤2hasParent.Dead A primeira é uma restrição de número não qualificada pois diz que para um indivíduo (p.ex. JOHN) ser pai/mãe basta que ele tenha ao menos um par na relação hasChild. Assim, para uma afirmação hasChild(JOHN, MARY) não há exigência de que MARY pertença a qualquer conceito. O segundo exemplo é uma relação qualificada pois diz que para um indivídio ser órfão deve existir uma ou duas afirmações do tipo hasParent cujo segundo elemento é falecido. A composição de relações permite fazer um processo similar ao de composição de funções: 1. hasParent ∘ hasParent ≡ hasGrandParent 2. owns ∘ hasPart ≡ owns A primeira mostra relação hasGrandParent como a composição da relação hasParent e a propriedade owns como composição entre a relação owns e hasPart. Na primeira, se o ABox tiver hasParent(JOHN, MARY) e hasParent(MARY, ANNA) pode-se inferir a relação hasGrandParent(JOHN, ANNA). A segunda é semelhante: owns(PETER, CAR) e hasPart(CAR, ENGINE) então owns(PETER, ENGINE). Assim como existe o TBox para os conceitos e o ABox para indivíduos, na linguagem SROIQ existe o RBox que contém os axiomas para relaçõs, como estes dois descritos. Por fim, cabe relembrar que a nomenclatura ALC é equivalente a ALUℰ e S é equivalente à ALCR+, Portanto SROIQ é ALCR+ com nominais (O), inversibilidade de relação (I) e restrição de número qualificada (Q). Uma extensão importante é a adição de tipos de dados (inteiro, string, data, etc.) e representada pela adição de (D) ao nome da linguagem (HORROCKS, I et al., 2001).

48

Quadro 3. Lista de expressividade de diversas DLs atuais.

Descrição

Notação

Nomenclatura

Tipo

Conceito universal

⊤

AL

Construto

Conceito vazio

⊥

AL

Construto

¬A

AL

Construto

Interseção de conceitos

C⊓D

AL

Construto

Restrição de valor

∀r.C

AL

Construto

Quantificação existencial limitada

∃r.⊤

AL

Construto

Hierarquia de conceitos

C⊑D

AL

Axioma

Equivalência entre conceitos

C≡D

AL

Axioma

Quantificação existencial completa

∃r.C

ℰ

Construto

Negação ou complemento

¬C

C

Construto

C⊔D

U

Construto

Tr(r), r+ ⊑ r

R+

Axioma

≥n r, ≤n r

N

Construto

≥n r.C, ≤n r.C

Q

Construto

≤1 r

F

Construto

r¯

I

Construto

r ≡ s, r ⊑ s ⊓ s ⊑ r

H

Axioma

r⊑s

H

Axioma

r1 ∘ r2 ⊑ s

R

Axioma

Reflexividade local

∃r.Self

R

Construto

Reflexividade global

⊤ ⊑ ∃r.Self

R

Construto

{a1, a2, ..., an}

O

Construto

-

(D)

-

Negação atômica

União de conceitos Transitividade de relação Restrições de número Restrições de número qualificadas Propriedades funcionais Inversibilidade de relação Equivalencia entre relações Hierarquia de relações Inclusão de relações complexas (cadeia ou composição de relações)

Nominals (indivíduos no TBox) Tipos de dados

49

2.3.2.5 Regras DL-seguras DLs, apesar de possuírem um relativamente rico conjunto de construtos para conceitos, possuíam grandes limitações com respeito à expressividade de propriedades. Estas limitações eram maiores antes das DLs SROIQ (D), pois não permitiam representação de composição nem reflexividade de relações. Por outro lado, sistemas de processamento de regras (cláusulas de Horn) permitem estabelecer os mais variados tipos de relações (propriedades) entre indivíduos. Sendo assim, surgiram propostas para adicionar regras a motores de inferência DL, contudo, estas abordagens tornavam a linguagem resultante indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004). Propostas posteriores passaram a utilizar as chamadas regras DL-seguras (DL-safe rules) que garantem decidibilidade do processo de inferência. A seguir, apresentar-se-á a definição geral de regra, regras DL e DL-seguras. Um termo é uma constante (a, b, c) ou uma variável (x, y, z). Um átomo tem a forma P(t1, ... , tn), onde t1 a tn são termos. Um literal é um átomo ou um átomo negado. Assim, uma regra ou cláusula de Horn segue a forma H ← B1, ..., Bn

ou

B1, ..., Bn → H

onde H e B1 a Bn são átomos; H é dita a cabeça ou consequente da regra e B1 a Bn é o corpo ou cauda ou antecedente da regra. Regras podem ser vistas como IF-THEN (SE antecedente ENTÃO consequente), ou seja, o antecedente representa uma condição e o consequente as informações que serão adicionadas ao KB quando a condição é satisfeita. Um conjunto finito de regras é chamado um programa. Uma regra-DL é obtida restringindo átomos para os chamados átomos-DL que podem ser da forma C(t) ou R(s, t). Um conjunto de regras-DL forma um programa-DL. (KOLOVSKI et al., 2006) Como esta definição é possível expressar necessidades de modelagem não permitidas nas DLs convencionais, como apresentado nos dois exemplos a seguir: (i)

hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y), Female(y)

(ii)

hasCurrentActivity(x, MeetingSupervisor) ← Person(x), Person(y), Location(z), hasSupervisor(x, y), hasOffice(y, z), hasCurrentLocation(x, z)

A regra (i) diz que se um indivíduo x tem um ancestral direto (pai ou mãe) z que possui uma irmã y então y é tia de x (MOTIK et al., 2005). A regra (ii) apresenta um exemplo de inferência de contexto da atividade de uma pessoa, pois diz que se uma pessoa x é

50

supervisionada por uma pessoa y e x se encontra no mesmo local que o escritório de y, então x está praticando a atividade “reunião com seu supervisor” (WANG, X.; DONG, J. S. et al., 2004). OWL 1 DL (SHOIN ) não possui construtos nativos para nenhuma das duas regras, enquanto OWL 2 DL (SROIQ ) possui construtos apenas para a regra (i) (RIBONI; BETTINI, 2011b). Isto mostra a importância da extensão de DLs com regras. Tanto DLs quanto linguagens de regras (LP e RETE) são fragmentos decidíveis da lógica de primeira ordem, contudo a simples união de ambas torna a linguagem resultante indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004; MOTIK et al., 2005). A decidibilidade de DLs é mantida pela propriedade modelo de árvore, que diz que um conceito tem um modelo se, e somente se, suas propriedades definem um grafo direcionado na forma de árvore (GROSOF et al., 2003). Esta propriedade é comprometida quando surgem árvores com ramos que possuam cadeias infinitas. Veja o seguinte KB: Person ⊑ ∃father.Person Person(JOHN) isto resulta em uma cadeia infinita de pais desconhecidos (indivíduos anônimos), pois diz que toda pessoa possui um pai que é uma pessoa, logo este pai também tem um pai que é uma pessoa, e assim sucessivamente. Transitividade de relações também compromete este modelo, contudo ambos os casos são resolvidos com bloqueios que impedem aplicações repetitivas de regras de expansão. Ao adicionar regras esta propriedade das DLs é perdida, além disso, como reasoners DL tipicamente produzem indivíduos anônimos dentro de um domínio possivelmente infinito (ex. Person ⊑ ∃father.Person) e regras são universalmente quantificadas (i.e., aplicam-se a todos os indivíduos do domínio) isto dificulta a inferência e torna o KB indecidível (KRISNADHI et al., 2011). Para evitar problemas causados pelo uso de regras-DL, foi criado o conceito de regras-DL-seguras. Uma regra-DL-segura é uma regra-DL tal que todas as suas variáveis ocorrem em um átomo não-DL no corpo da regra. Assim, as regras (i) e (ii) não são regras-DL-seguras, mas se tornam DL-seguras ao adicionar (a) um átomo unário não-DL, O(x), ao corpo da regra para cada variável existente na regra e (b) um fato O(a) para cada indivíduo existente no KB e no programa. Exemplificando, a regra (i) ficaria da seguinte forma:

51

(i)

hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y), Female(y), O(x), O(y), O(z)

O reflexo na expressividade e semântica desta restrição pode ser facilmente verificado com o exemplo a seguir. Considere o seguinte KB: father ∘ father¯ ⊑ sibling ∃father.(∃father¯.{CAIN})(ABEL) O primeiro axioma diz que indivíduos com o mesmo pai são irmãos (ignore o fato de o axioma permitir que uma pessoa seja irmã dela mesma) e o segundo diz que CAIN e ABEL possuem o mesmo pai. Ao questionar se CAIN e ABEL são irmãos, o motor de inferência diria que sim. Agora considere trocar o primeiro axioma pela regra: sibling(x,y) ← father(x, z), father(y, z), O(x), O(y), O(z) A mesma pergunta teria resposta “não sei”, pois o motor de inferência não criaria um indivíduo anônimo representando o pai de CAIN e ABEL para casar com a variável z da regra. Para que tal regra funcionasse como desejado, seria necessário explicitar quem é o pai de ambos, que poderia ser feito apenas desmembrando o segundo axioma ou substituindo-o por relações father entre ABEL, CAIN e ADAM: (a) ∃father.{ADAM}(ABEL)

∃father¯.{CAIN}(ADAM)

(b) father(ABEL, ADAM)

father(CAIN, ADAM)

Apesar de esta restrição parecer incoveniente ela evita que regras propaguem relações indesejadas, que resultariam numa possível alteração desconhecida do TBox. Considere o KB10: A ≡ ∃R.B

A(c)

C ≡ ∃R.{c}

R(a, b) R(b, c)

A Figura 4 mostra um grafo (à esquerda) representando este KB. Note que o indivíduo c foi classificado como uma instância de C, pois há uma propriedade R que relaciona b e c. O ABox diz que o indivíduo c pertence ao conceito A, logo infere-se que existe um indivíduo

10

Adaptado de http://weblog.clarkparsia.com/2007/08/27/understanding-swrl-part-2-dl-safety/

52 anônimo x pertencente ao conceito B que se relaciona com c através da relação R. Considere agora a adição de uma regra não-DL-segura para transitividade da relação R: R(x, y) ← R(x, z), R(z, y) Isto leva ao grafo na parte direita de figura que mostra que a, b, c e um possível x se relacionam por R. Além diso, b passa a ser também instância de A, e a passa a ser instância de A e C. Contudo, não apenas a e b se tornam instâncias de A e C, mas também todas as possíveis instâncais de C. Veja, por exemplo, que adição de um indivíduo y do tipo C resulta nas arestas tracejadas e classifica y também como instância de A (≡ ∃R.B). Logo, tem-se um novo axioma C ⊑ A não existente no TBox. Este é apenas um exemplo e o uso de regras nãoDL-seguras pode gerar muitos outros problemas. Assim, a aplicação das regras restringe-se aos indivíduos explicitamente existentes no KB (neste caso a, b e c). O reasoner Pellet implementa o algoritmo de Tableau para SROIQ (D) e o estende para aceitar regras SWRL DL-seguras usando

um subconjunto decidível da SWRL

(KOLOVSKI et al., 2006). O reasoner Jena não é um motor de inferência OWL DL, mas sim um sistema de processamento de regras que podem ser forward- ou backward-chaining, ou ambos (híbrido). Forward-chaining parte da condição (corpo) para então adicionar de forma concreta estes novos fatos na base utilizando o algoritmo RETE (FORGY, 1982). Backwardchaining descobre nova informação baseado em objetivo, ou seja, procura regras que possuam um dado objetivo no consequente e cujo antecedente seja confirmado pelos dados do KB, utilizando algoritmo de programação lógica (Logic Programming) como resolução (também aplicada em Prolog). Portanto, a primeira materializa os novos dados e a segunda aguarda uma pergunta sobre um consequente para então verificar se os dados da base o confirmam. (EITER et al., 2008)

53

a

{}

a

R b

{ ∃R.{c}, C, ∃R.B, A }

R { ∃R.{c}, C }

R

⇒

R

b

{ ∃R.{c}, C } ∪ { ∃R.B, A }

R

R

y

{ C, ∃R.{c}, ∃R.B, A }

R c

{ ∃R.B, A }

R

c

{ ∃R.B, A }

C⊑A R x

R

R {B}

x

{B}

Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações imprevistas no TBox.

Apesar de este trabalho utilizar apenas os motores de inferência Jena e Pellet, existem inúmeros outros. Dentre os disponíveis para OWL, pode-se mencionar FaCT++, HermiT, RacerPro, JESS, Hoolet, KAON2, OWLIM. Jena, JESS e OWLIM são baseados em regras; Hoolet utiliza um algoritmo de prova para lógica de primeira ordem; Pellet, FaCT++ e RacerPro são baseados em Tableau mas enquanto os dois primeiros suportam SROIQ(D), o último suporta apenas SHIQ(D); KAON2 usa resolução para SHIQ(D); HermiT utiliza o algoritmo Hypertableau, uma variante do Tableau, também para SROIQ(D). (DENTLER et al., 2011; LIANG; KIFER, 2009; SINGH; KARWAYUN, 2010) 2.3.3 Web Ontology Language (OWL) A linguagem OWL, cuja sigla foi construída de forma invertida, nada mais é que uma lógica de descrição com uma sintaxe variante, ou seja, mapeia os construtos e axiomas apresentados na coluna “Notação” do Quadro 3 para uma sintaxe RDF. OWL Lite é uma DL com expressividade SHIF (D), OWL DL é SHOIN (D) e OWL 2 DL é SROIQ (D) (HORROCKS, I et al., 2006; HORROCKS, IAN et al., 2003). Portanto, considerando-se ZX como o conjunto de construtos/axiomas suportados por uma dada versão X da OWL, pode-se dizer que ZOWL-Lite ⊂ ZOWL-DL ⊂ ZOWL2-DL. Os Quadros 4 e 5 mostram como construtos da notação DL padrão são mapeados para sintaxe OWL e foram montadas por meio de consultas a diversos artigos e recomendações do

54

W3C (ANTONIOU; HARMELEN, FRANK VAN, 2009; EITER et al., 2008; GOLBREICH; WALLACE, 2009; MCGUINNESS; HARMELEN, FRANK VAN, 2004; MOTIK et al., 2009). Os construtos e axiomas que contém OWL Lite marcado com asterisco permitem apenas classes ou restrições nomeadas, ou seja, não permite expressões usando construtos como C ⊓ D. Para facilitar o entendimento do quadro, o KB apresentado anteriormente será transformado para OWL. Assim, o conceito Father do TBox: Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person é a interseção entre três conceitos e pode ser escrito em Turtle como: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@prefix : . @prefix rdfs: . @prefix owl: . :Person a owl:Class . :Male a owl:Class . :hasChild a owl:ObjectProperty . :Father a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:intersectionOf ( :Person :Male [ a owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] ) ] .

onde as linhas 5 e 6 definem que os termos Person e Male são classes e a linha 7 define que o termo hasChild é um propriedade. As linhas 9 a 17 definem a equivalência entre um novo conceito Father e a interseção entre os dois conceitos anteriores (Person e Male) e uma restrição de quantificação existencial completa ∃hasChild.Person. Os fatos do ABox são definidos da seguinte forma: 18 :JOHN rdf:type :Person , 19 :Male ; 20 :hasChild :MARY . 21 :MARY rdf:type :Person .

55

Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam.

Construtos Notação DL

Sintaxe OWL

Versão OWL

C1 ⊓ ... ⊓ Cn

[] rdf:type owl:Class ; owl:intersectionOf (C1 ... Cn) .

OWL DL/Lite*

C1 ⊔ ... ⊔ Cn

[] rdf:type owl:Class ; owl:unionOf (C1 … Cn) .

OWL DL

¬C

[] rdf:type owl:Class ; owl:complementOf C .

OWL DL

{a1, … an}

[] rdf:type owl:Class ; oneOf (a1 … an) .

OWL DL

∀P.C

[] rdf:type owl:Restriction; owl:onProperty P ; owl:allValuesFrom C .

OWL Lite

∃P.C

[] rdf:type owl:Restriction; owl:onProperty P ; owl:someValuesFrom C .

OWL Lite

∃P.{a}

[] rdf:type owl:Restriction; owl:onProperty P ; owl:hasValue a .

OWL DL

≥n P

[] rdf:type owl:Restriction; owl:onProperty P ; owl:minCardinality n .

OWL DL OWL Lite (n=0,1)

≤n P

[] rdf:type owl:Restriction; owl:onProperty P ; owl:maxCardinality n .

OWL DL OWL Lite (n=0,1)

≥n P.C

[] rdf:type owl:Restriction; owl:onProperty P ; owl:minQualifiedCardinality n ; owl:onClass C .

OWL 2 DL

≤n P.C

[] rdf:type owl:Restriction; owl:onProperty P ; owl:maxQualifiedCardinality n ; owl:onClass C .

OWL 2 DL

≥n P.D

[] rdf:type owl:Restriction; owl:onProperty P ; owl:minQualifiedCardinality n ; owl:onDataRange D .

OWL 2 DL

≤n P.D

[] rdf:type owl:Restriction; owl:onProperty P ; owl:maxQualifiedCardinality n ; owl:onDateRange D .

OWL 2 DL

R¯

[] owl:inverseOf R .

OWL Lite

⊤

owl:Thing

OWL Lite

⊥

owl:Nothing

OWL Lite

56

Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam

Axiomas Notação DL

Sintaxe OWL

Versão OWL

C1 ⊑ C2

C1 rdfs:subClassOf C2 .

OWL DL/Lite*

C1 ≡ C2

C1 owl:equivalentClass C2 .

OWL DL/Lite*

P1 ⊑ P2

P1 rdfs:subPropertyOf P2 .

OWL DL/Lite*

P1 ≡ P2

P1 owl:equivalentProperty P2 .

OWL DL/Lite*

C1 ⊓ C2 ≡ ⊥, C1 ⊑ ¬C2

C1 owl:disjointWith C2 .

OWL DL

C1 ⊓ ... ⊓ Cn ≡ ⊥

[] rdf:type owl:AllDisjointClasses ; owl:members ( C1 .. Cn) .

OWL 2 DL

P1 ⊓ ... ⊓ Pn ≡ ⊥

[] rdf:type owl:AllDisjointProperty ; owl:members ( P1 .. Pn) .

OWL 2 DL

C ≡ C1 ⊔ ... ⊔ Cn e Ci ⊓ Ck ≡ ⊥, onde 1≤i,k≤n e i≠k

C owl:disjointUnionOf (C1 ... Cn) .

OWL 2 DL

⊤ ⊑ ∀P¯.C

P rdfs:domain C .

OWL Lite

⊤ ⊑ ∀P.C

P rdfs:range C .

OWL Lite

P ≡ P¯

P rdf:type owl:SymmetricProperty .

OWL Lite

⊤ ⊑ ≤1 P

P rdf:type owl:FunctionProperty .

OWL Lite

⊤ ⊑ ≤1 P¯

P rdf:type owl:InverseFunctionProperty .

OWL Lite

Tr(P) ou P+ ⊑ P

P rdf:type owl:TransitiveProperty .

OWL Lite

∃P.Self

P rdf:type owl:ReflexiveProperty .

OWL 2 DL

P1 ∘ ... ∘ Pn ⊑ P

P owl:propertyChainAxiom (P1 ... Pn) .

OWL 2 DL

P1 ≡ P2

P1 owl:equivalentProperty P2 .

OWL Lite

{a1} ≡ {a2} ou a1 = a2

a1 owl:sameAs a2 .

OWL Lite

{a1} ≢ {a2} ou a1 ≠ a2 ou {a1} ⊑ ¬{a2}

a1 owl:differentFrom a2 .

OWL Lite

C(a)

a rdf:type C .

OWL Lite

P(a,b)

a P b .

OWL Lite

57

2.3.4 Trabalhos de publicação em LOD Muitos trabalhos têm explorado o uso das tecnologias da Web Semântica para descrever e publicar tanto dados de sensores quanto dados estáticos. Redes de sensores vêm sendo utilizadas como fontes de dados de temperatura, umidade, pressão, etc. (GONG et al., 2011; SZEWCZYK et al., 2004) e, uma vez inseridas na Web Semântica, podem ser largamente utilizadas como fonte de dados de contexto. O W3C, por exemplo, abriu um grupo de trabalho que estudou várias ontologias e produziu a Semantic Sensors Networks (SSN) Ontology para descrever estas redes (COMPTON et al., 2009; NEUHAUS; COMPTON, 2009). Dois grandes esforços de publicação de dados em RDF/SPARQL são o Linked Open Data (LOD) e o Linked Stream Data (LSD). O primeiro é uma iniciativa para publicar dados ligados e abertos (BIZER, 2009), que podem ser estáticos ou semi-estáticos (mudam com baixa frequência). Dentre os dados publicados, pode-se destacar DBPedia.org (dados da Wikipédia), LinkedGeoData.org (do OpenStreetMaps), GeoNames11 e Linked Movie Database (do Internet Movie Database). O termo LOD pode ser simplificado para Linked Data quando se tratar de dados privados (por exemplo, dados sigilosos de uma empresa acessíveis apenas por aplicações usadas por funcionários). Neste trabalho, a sigla LOD continuará sendo usada para evitar confusão com o termo lógica descritiva (LD). A iniciativa LSD foi introduzida por Sequeda e Corcho (SEQUEDA; CORCHO, 2009) e propõe uma forma de identificar e acessar streams de dados oriundos de redes de sensores. Uma implementação é mostrada por Le-Phuoc et al. (LE-PHUOC et al., 2011) que apresenta o Linked Stream Middleware (LSM), capaz de publicar dados provenientes de uma grande quantidade de sensores. A maioria das publicações ainda é feita ad hoc por meio de programas e scripts, mas arquiteturas começam a aparecer, como mostrado em Cordeiro et al. (CORDEIRO et al., 2011), que apresenta uma arquitetura de publicação baseada na ferramenta de ETL Kettle. Apesar da quantidade de acervos publicados estar aumentando significativamente desde o início das iniciativas, ainda há diversas questões em aberto (JAIN et al., 2010). Contudo, esta alta atividade sugere que estas questões serão abordadas em breve e que bases de dados maiores e de melhor qualidade irão, em breve, prover informação útil, aberta e de forma padronizada para aplicações cientes de contexto. No âmbito nacional, o fato que

11

GeoNames – geonames.org

58

corrobora esta afirmação é a assinatura por parte da Presidenta Dilma Roussef, em setembro de 2011 (DOU 16/09/2011), do decreto que institui o “Plano de Ação Nacional sobre Governo Aberto” (SCHULZE, 2011), fortalecendo ainda mais a crescente tendência de publicação de dados públicos em prol de um governo mais transparente. Em condições ideais, órgãos do governo (Bombeiro, Polícia, Defesa civil, etc.) publicam os seus dados de domínio público, permitindo assim seu consumo automatizado, seja por outras agências do governo ou por cidadãos.

2.4

Trabalhos relacionados

2.4.1 Frameworks para aplicações cientes de contexto Diversas abordagens para modelagem e inferência de contexto já foram propostas na literatura. As primeiras utilizavam pares chave-valor, linguagem de marcação (ex. XML) e modelos relacionais e/ou orientados a objetos. Alguns trabalhos se valeram de Object Role Mapping (ORM), outros de ontologias (OWL) e outros construíram modelos híbridos (BETTINI et al., 2010). Nesta seção, algumas destas arquiteturas serão descritas e comparadas. A arquitetura Hydrogen (HOFER et al., 2002) propõe um modelo de contexto orientado a objetos, dividido em três camadas onde contextos de diversos dispositivos são compartilhados usando um modelo P2P dispensando o uso de servidores remotos. A camada Adapter é responsável por ler dados dos sensores físicos e passar para o ContextServer que armazena e possibilita leituras concorrentes por parte de diversas aplicações que podem estar no mesmo dispositivo ou não (via P2P). Context-Aware Sub-Structure (CASS) é uma arquitetura para dispositivos móveis baseada em um servidor centralizado (FAHY; CLARKE, 2004). Eles separam código da aplicação e inferência de contexto com o objetivo de simplificar o código e evitar recompilação a cada modificação de regras (extensibilidade). Segundo esta arquitetura, sensores são anexados a nós (dispositivos móveis ou estáticos) que se comunicam com servidores via redes sem fio. Utiliza um banco de dados relacional para armazenamento de dados e regras. Context Management Framework é apresentado por Korpipaa et al. (KORPIPAA et al., 2003). Ele é capaz de reconhecer contexto em tempo real na presença de incerteza, ruído e informações dinâmicas, e roda em um dispositivo móvel com Symbiam OS. Os valores

59

obtidos dos diversos sensores são quantizados (fuzzy ou crisp) e contextos de baixo nível são descobertos baseado numa ontologia em RDF predefinida. Contextos de mais alto nível são derivados usando classificadores Bayesianos. Como resultado, reconhecem mais de 80 contextos com acuraria de 96% em ambientes controlados e 87% no mundo real. A arquitetura CORTEX utiliza bases relacionais, redes Bayesianas e o sistema CLIPS para construção do motor de inferência (BIEGEL; CAHILL, 2004). Diferentemente dos demais, nesta arquitetura cada componente pode ser consumidor e produtor de informação além de poderem ser organizados de forma descentralizada e em uma rede hierárquica, como na arquitetura aqui proposta. Contudo, todas estas arquiteturas apresentam a desvantagem de não poderem ser facilmente integradas no ambiente Web, devido a não utilização de padrões abertos do W3C. As duas abordagens a seguir, embora não foquem em disponibilidade na Web, merecem maior destaque por adotarem padrões da Web Semântica. Gu et al. (GU et al., 2005) apresenta a arquitetura SOCAM (Service-Oriented ContextAware Middleware) que é organizada em três camadas (Figure 5): Context Application Layer, Context Middleware Layer e Context Sensing Layer. Na última, localizam-se sensores físicos e virtuais e na de aplicação os agentes, serviços e aplicações que utilizam contextos obtidos da camada intermediária. A camada intermediária, Context Middleware Layer, é o núcleo da arquitetura, funcionando como um servidor centralizado capaz de deduzir contexto de mais alto nível. Mais precisamente, é composta pelos Provedores de Contexto internos e externos que obtém dados dos sensores físicos e virtuais respectivamente e os converte em representações RDF/OWL para serem compartilhadas e reusadas. Também possui o Interpretador de Contexto composto por uma base de conhecimento (KB) e um motor de inferência responsável por processar os dados de contexto de baixo nível oriundos dos Provedores de Contexto e inferir contexto de alto nível (com base nas ontologias e em regras do usuário) assim como detectar inconsistências no KB. A comunicação entre seus componentes é feita por meio de uma API que usa Java RMI (Remote Method Invocation). Sua modelagem de contexto utiliza ontologias em dois domínios específicos: veículos e smart home. Os autores apresentam a ideia de ontologia genérica e específica, onde a primeira estaria sempre em memória e a segunda seria carregada e descarregada conforme necessário. Assim, a ontologia de smart home não é carregada enquanto o usuário estiver em seu carro. A inferência é baseada em lógica de primeira ordem e implementada usando a ferramenta Jena2. Eles analisaram a desempenho da inferência usando Jena e concluíram que

60

o processo é bastante intensivo computacionalmente e pode ser um gargalo em computação “pervasiva”, no entanto, é aceitável para aplicações onde o tempo não é crítico.

Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005).

Por fim, a arquitetura CoBrA (Context Broker Architecture) pretende apoiar a aquisição, inferência e compartilhamento de conhecimento de contexto em ambientes inteligentes (CHEN, H.; FININ, T. et al., 2004). Ela está baseada nos conceitos de agente e broker. Agente é uma entidade capaz de executar alguma tarefa, como aplicações de usuários, serviços providos por dispositivos, e serviços Web. Nesta arquitetura, o context broker é um agente especial capaz de gerenciar partes de um espaço inteligente e compartilhar modelos contextuais entre diversos agentes seguindo uma política de privacidade. O broker é um dispositivo rico em recursos computacionais capaz de processar as informações dos agentes ao seu redor. Para aplicações em larga escala como um campus universitário é possível usar múltiplos brokers para formar uma federação de brokers organizados numa forma P2P ou hierárquica. Assim como no SOCAM, foi desenvolvida uma ontologia específica para seu domínio, neste caso, uma sala de reuniões inteligente capaz de representar locais, agentes e seus contextos. Não aborda disponibilização na Web, comentando apenas, sobre a linguagem de consulta RDQL, que é predecessora do SPARQL e não mais mantida nem recomendada. A arquitetura do Context Broker é dividida em quatro componentes conforme apresentado a seguir (estes e os possíveis agentes ao seu redor podem ser visto na Figura 6): Context Knowledge Base (Base de Conhecimento de Contexto): uma área para armazenamento das informações de contexto do espaço inteligente.

61

Context Reasoning Engine (Motor de Inferência de Contexto): responsável por “raciocinar” sobre a base tanto para inferir novas informações quanto para manter a consistência do KB. Context Acquisition Module (Módulo de Aquisição de Contexto): responsável por adquirir informações de fontes externas como sensores físicos, serviços Web, bancos de dados, dispositivos e agentes. Privacy Management Module (Módulo de Gerenciamento de Privacidade): responsável por aplicar regras de privacidade definidas pelo usuário a fim de evitar compartilhamento de informações indesejadas.

Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003)

O trabalho apresentado por Lee & Meier (LEE; MEIER, 2009) apresenta uma arquitetura baseada em um modelo híbrido de contexto que permite organização descentralizada, em forma de rede para o domínio de transporte. Para isso, propõem uma mesclagem entre um modelo de contexto orientado a objetos e outro ontológico, de forma que há um mapeamento direto entre ambos. Modelos orientados a objetos oferecem herança, modularidade, polimorfismo, encapsulamento, enquanto modelos ontológicos oferecem um formalismo semântico que permite entendimento compartilhado e inferências. O primeiro foi denominado PCM (Primary-Context Model) e o segundo PCOnt (Primary-Context Ontology). Ambos os modelos se baseiam nos contextos primários, onde há um objeto espacial que

62

possui identidade (URI), localização (simbólica ou absoluta), tempo (criação e última modificação) e qualidade de serviço (confiança, latência e tempo de vida). Para acessar estes objetos espaciais foi criada uma interface orientada a objetos (Spatial API). PCOnt é dividida em Upper PCOnt (genérica) e Extended PCOnt (específica). A primeira define os conceitos supracitados (identidade, tempo, etc.) enquanto a segunda permite expandí-los. Esta técnica permite distribuir o gerenciamento de ontologias, evitando a manutenção de uma ontologia única e extensa. Desta forma, propõem o iTransIT framework, uma arquitetura distribuída, seguindo o modelo em camadas, para facilitar compartilhamento de dados entre sistemas de transporte que usam iTransIT e outros legados. O framework adotas camadas Legacy (sistemas legados), iTransIT (sistemas novos) e Application (aplicações que consomem os dados). A camada iTansIT é uma federação de sistemas que suportam a API nativamente e wrappers (conversores) para os sistemas legados. O framework não provê comunicação usando SPARQL, apenas uma API específica criada por eles e também não menciona tratamento de dados históricos nem descoberta de recursos e/ou serviços. O SmartLab middleware (ALMEIDA et al., 2009) possui uma arquitetura em quatro camadas que utiliza tecnologias da Web Semântica para representar, compartilhar e inferir contexto de diversas fontes e OSGi para comunicação. Diferentemente de outras abordagens que precisam que a modelagem da ontologia seja feita na etapa de projeto, este middleware tem a habilidade de expandir sua ontologia (adicionando conceitos e regras) dinamicamente ao passo que novos dispositivos se tornam disponíveis no ambiente, fazendo com que sistemas possam se adaptar aos novos dispositivos em tempo de execução. A camada Sensing and Actuation possui os diversos dispositivos como câmeras, sensores, VoIP, etc., e a camda Service Abstration encapsula as funcionalidades de dispositivos em pacotes OSGi (bundles) que podem ser descobertos pela camada Semantic Context and Service Management, cuja responsabilidade é gerenciar e raciocinar sobre contexto usando a ontologia corrente. Esta ontologia é incrementada por esta última camada que possui módulos para procurar por novos dispositivos, adicioná-los à ontologia (novos conceitos e regras) e verificar consistência da nova ontologia. A última camada, Management and Interaction Layer, possui as aplicações que utilizam as informações da camada anterior. Para que seja possível a descoberta e uso de um dispositivo, é necessário que seu serviço implemente uma interface (ISmartLabService) que possui métodos para obter metadados, conceitos, regras e indivíduos necessários para que o novo dispositivo funcione no

63

ambiente SmartLab. A ontologia nesta arquitetura é modelada usando RDF/XML e possui quatro conceitos principais que são estendidos pelas ontologias de domínio: espaço, tempo, evento, ator (dispositivos e pessoas). Estes representam pontos, áreas, salas ou construções; instante, intervalo e relações temporais; ou uma reação a uma mudança de contexto (evento). Eventos são representados por regras de domínio, que descrevem o comportamento de aplicações. As regras de elicitação de contexto podem ser semânticas, ou seja, descrever os modelos RDF e OWL (o framework não aceita DLs) ou podem ser heurísticas que inferem conhecimento espaçal e temporal. Infelizmente, o trabalho peca em não se aprofundar na apresentação de como a interação entre os módulos funciona. Além disso, não provê comunicação usando SPARQL nem menciona tratamento de dados históricos. O sistema COSAR (RIBONI; BETTINI, 2011a) utiliza inferência híbrida para reconhecer atividades humanas. Ontologia é usada para validar atividades reconhecidas estatisticamente e para reconhecer atividades complexas impossíveis para métodos puramente estatísticos. Assim, definiram uma ontologia de atividades e outros conceitos assim como suas relações para representar e reconhecer tais atividades simples e complexas. Basicamente, inferência estatística é usada para pegar dados de sensores e predizer as atividades mais prováveis, dando probabilidades. Estas são filtradas por inferência ontológica (simbólica) através da seleção das atividas permitidas baseadas na localização do usuário. A arquitetura do sistema possui quatro camadas e é um sistema centralizado que utiliza um dispositivo móvel e servidores para processamento pesado que se comunicam via rede sem-fio. Na camada mais inferior estão os sensores que coletam dados de sensores nas roupas do usuário ou no ambiente. A seguir, na camada no dispositivo móvel do usuário encontra-se o módulo COSAR que captura as medições da camada de sensores via Wi-Fi e faz a fusão destes. Dados de localização podem ser obtidos diretamente via GPS do dispositivo ou via RFID ou triangularização GSM quando dados de GPS não estão disponíveis ou são inacurados (locais fechados). Estes (RFID e GSM) são gerados pelo chamado Location Server que se encontra na camada de infraestrutura (terceiro nível). Um sistema GIS efetua a conversão de localização física para simbólica. A camada de infraestrutura roda em servidores que efetuam classificação estatística e inferência ontológica, separadamente e possui ainda um provedor de rede para a quarta camada (serviços). Esta quarta não é bem esclarecida, sendo que na implementação ela encontra-se no próprio dispositivo móvel.

64

O módulo de classificação estatística é responsável por gerar um vetor com a probabilidade de cada atividade estar sendo executada pelo usuário a partir dos dados dos sensores usando um modelo previamente treinado. Para o módulo de inferência ontológica foi construída uma ontologia OWL 2 DL que modela atividades, artefatos (objetos), pessoas, localização simbólica (sala, hospital, etc.) e tempo, contendo 35, 43, 4, 30 e 11 subclasses, respectivamente. Com base nesta ontologia, derivam atividades permitidas em cada local, pela geração de uma matriz cujas linhas representam localizações simbólicas e colunas representam atividades, onde o valor corresponde é 1 se uma atividade pode ocorrer em uma dada localização, e 0 caso não possa. Para detectar a atividade final de um usuário o módulo COSAR pega a atividade com maior probabilidade em um vetor de atividades modificado. Este vetor modificado é obtido de duas formas: (1) casando-o com a linha da matriz referente a localização do usuário, quanto esta é certa, ou (2) unindo linhas da matriz que representam as possíveis localizações e então casando o vetor com esta linha unida. O casamento é feito pegando os valores do vetor cuja atividade é permitida pela matriz (possui valor 1). Atividades complexas são inferidas adicionando-se um ABox contendo atividades mais simples sendo conhecidamente executadas pelos usuários e suas localizções. Um comparativo entre as arquiteturas descritas pode ser visto no Quadro 6. Estas arquiteturas visam auxiliar desenvolvedores a construir de aplicações CC. Contudo, apesar de fora do escopo deste trabalho, arquiteturas para auxiliar usuários finais (com vários níveis de conhecimento) a desenvolver estes tipos de aplicações também foram propostas. Elas aplicam interfaces visuais como iCAP (DEY, A. et al., 2006), máquinas de estados como UbiPlay (MATTILA; VÄÄTÄNEN, 2006) ou objeto tangíveis como StoryRoom (MONTEMAYOR et al., 2004). Uma pesquisa sobre estas abordagens pode ser encontrada em (TANG et al., 2011). Recentemente, (GUO et al., 2011) apresenta uma arquitetura com a intenção de permitir que tanto desenvolvedores quanto usuários possam contribuir colaborativamente a desenvolver aplicações CC. Para isso, dispõe de três modos de programação (incremental, de composição e de parametrização) que permitem editar desde ontologias e regras (desenvolvedores) até a instanciação das variáveis nestas regras (usuários iniciantes).

65

Quadro 6. Comparativo das arquiteturas. Modelagem e Dados de Descoberta processamento de contexto de recursos contexto históricos Orientado a objetos; Três camadas; peerinterpretação e agregação Não Não to-peer de dados Banco relacional para Centralizado dados e regras; motor de Não Sim inferência

Padrões abertos W3C?

Disponível na Web?

Apenas XML

Não, mas troca informações via TCP/IP

Não

Não, mas troca informações via redes sem fio

Apenas RDF

Não, pois não é focado na infraestrutura

Não

Não

RDF(S), OWL

Não, comunicação via API RMI do Java.

CoBra Chen, H. et al. (2004)

RDF(S), OWL

Não menciona

iTransIT Lee, Meier (2009)

RDF, OWL

Sim, API própria

Camadas, federação

RDF, OWL

Sim, OSGi

RDF, OWL

Não, comunicação apenas entre módulos

RDF(S), OWL, SPARQL

Sim, com protocolos HTTP e SPARQL

Arquitetura Hydrogen Hofer et al. (2002) CASS Fahy & Clarke (2004) CMF Korpipaa et al. (2003) CORTEX Biegel & Cahill (2004) SOCAM Gu et al. (2005)

Almeida et al. (2009) COSAR Riboni & Bettini (2011) LOUD

2.4.2 Arquiteturas para integração de dados na Web

Organização

RDF, lógica fuzzy e crisp, redes Bayesianas

Sim

Não

Banco relacional; redes Bayesianas, CLIPS

Sim

Sim

RDF, ontologias e regras de inferência

Sim

Sim

Agentes (brokers); RDF, ontologias e regras de federação de inferência brokers

Não

Sim

RDF, ontologias, orientado a objetos

Não

Não

Camadas, centralizado

RDF, ontologias e regras de inferência dinâmicas

Sim

Não

Camadas, centralizado

RDF, ontologia OWL-DL e estatística

Não

Sim

Centralizado Em rede, hierárquica e descentralizado Três camadas; servidor centralizado

Camadas, em rede, RDF, ontologias e regras de Não, mas hierárquica e inferência (outros serão possível descentralizado possíveis) futuramente

O framework deste trabalho, apesar de ter sido planejado para prover dados para aplicações CC, também se apresenta como um módulo para integração de dados de diversas bases na Web. Portanto, alguns trabalhos com este intuito são apresentados nesta seção. O projeto Active XML, apresenta um framework onde arquivos XML contendo chamadas a serviços Web permitem integrar informação externa através de uma arquitetura P2P (ABITEBOUL et al., 2007). Um framework conceitual para integrar dados geográficos usando ontologias de domínio e de aplicação e mapeamentos entre elas é apresentado por Vidal et al. (VIDAL et al., 2009). O primeiro trabalho não usa padrões da Web Semântica (WS) e o segundo não chega a experimentar a proposta. Em Omitola et al. (OMITOLA et al., 2010), é relatada a experiência de converter dados governamentais do Reino Unido dos formatos HTML, XML e planilhas para LOD, e a junção destes dados com dados geográficos já existentes na nuvem LOD. A aplicação desenvolvida consome dados do SPARQL endpoint gerado e permite que o usuário visualize as informações pertinentes à sua localização

Sim

66

geográfica. Não provêm ferramentas para publicação de bases nem para integração, sendo o processo feito por meio de scripts. Integração na Web Semântica pode ser obtida por meio de consultas SPARQL federadas que podem ser de três formas: repositório central, múltiplos repositórios usando suas API nativas e múltiplos repositórios via SPARQL endpoints (HAASE et al., 2010). Esta última é implementada por Langegger et al. (LANGEGGER, 2008; LANGEGGER et al., 2008) no Semantic Web Integrator and Query Engine (SemWIQ), um endpoint virtual onde diversos endpoints podem se registrar para serem consultados de forma transparente. Com ele, um cliente pode executar uma consulta neste endpoint virtual que se encarrega de construir consultas para cada endpoint registrado. Segundo Haase et al. (HAASE et al., 2010) esta forma apresenta altos tempos de execução de consultas devidos ao atraso da rede, enquanto a primeira apresenta os melhores. Contudo, a principal vantagem de usar um repositório central é a possibilidade de executar inferências, recurso que os trabalhos citados não permitem. Quanto ao uso de inferência, Winkels et al. (WINKELS et al., 2010) apresenta um trabalho que utiliza dados geográficos para verificar o cumprimento de normas quanto ao uso de terras. Apresentam uma ontologia OWL com conceitos região e região conflitante, permitindo identificar descumprimento de uma norma. Porfim, apresenta um mashup que consome SPARQL e apresenta informações em um mapa. Em Della Valle et al. (DELLA VALLE et al., 2009), apresenta-se um framework para disponibilizar dados geográficos como grafos RDF virtuais visando aproveitar algoritmos já existentes através de um conversor de SPARQL para SQL configurado por uma linguagem de mapeamento. Obtenção de dados adicionais limita-se a consultas à DBPedia

e ao Flickr. Permite realização limitada de

inferências usando Jena. Em Koutsomitropoulos et al. (KOUTSOMITROPOULOS et al., 2010), um framework para inferência descentralizada e distribuída usando uma API Java que opera remotamente é apresentado. Contudo, não provê um SPARQL endpoint para acesso por parte de aplicações. Mostra que em processamentos pesados como classificação, o tempo de processamento supera o atraso da rede, comprovando o benefício de ter um servidor dedicado à inferência, enquanto o cliente apenas se comunica com o servidor. Percebe-se que existem trabalhos que se assemelham com essa proposta. No entanto, este trabalho se diferencia pelo módulo descentralizado, facilmente configurável que consome dados de bases LOD, executa inferência sobre estes dados e disponibiliza dados derivados como um novo SPARQL endpoint.

67

3 3.1

LOUD – Linked Open Ubiquitous Data Introdução Este capítulo apresentará o Módulo de Inferência proposto para resolver o problema

específico descrito na seção 1.3 e um esboço da arquitetura LOUD (Linked Open Ubiquitous Data) proposta para solucionar o problema mais amplo descrito na seção 1.2. A arquitetura LOUD ainda se encontra em estado inicial de idealização devido ao fato de ser bastante ampla e não poder ser completamente desenvolvida em uma única dissertação de Mestrado. Assim, a seção 3.2 apresentará a arquitetura LOUD, e a seção 3.3 descreverá o Módulo de Inferência, parte que será desenvolvida de fato neste trabalho.

3.2

Arquitetura LOUD

3.2.1 Objetivos A arquitetura visa utilizar as técnicas e padrões da Web Semântica e Dados Ligados para facilitar o desenvolvimento de aplicações cientes de contexto. Pretende-se disponibilizar módulos de informação contextual descentralizados para acesso por parte destas aplicações. Estes módulos devem ser capazes de consultar bases de triplas que contenham dados estáticos, de sensores e/ou de contexto de mais alto nível existentes na nuvem e processar estas informações usando os mais variados mecanismos. Ao permitir variados mecanismos de processamento, um em cada módulo independente, a arquitetura mostra-se coerente com modelos híbridos. Tudo isso deve ser feito de forma a facilitar tanto a reutilização de vocabulários, ontologias e regras de inferência de contexto, quanto o mapeamento entre conceitos e relacionamentos. Por fim, pretende-se impulsionar a produtividade de tais aplicações a partir da especificação de passos a serem seguidos pelo desenvolver. 3.2.2 Estrutura A versão inicial da arquitetura é organizada em três camadas conforme apresentado na Figura 7. Elas serão mais bem detalhadas nas subseções a seguir, contudo cabe ressaltar que cada módulo, representado por uma caixa, recebe configurações, mas estas foram omitidas da figura e, no caso da camada intermediária serão apresentadas na seção 3.3.3. Observe que as

68

setas entre componentes da figura mostram o fluxo de dados (exceto de configuração) de modo que consultas (requisições por dados) circulam no sentido inverso das setas enquanto que os dados de resposta circulam no sentido direto. Segue uma breve descrição de cada camada: Camada de dados e sensoriamento – responsável por obter, armazenar e fornecer dados de sensores físicos, bases de dados e perfis do usuário. Camada de Inferência – composta por uma rede de módulos responsáveis por consumir informações da camada de dados e sensoriamento ou de outros módulos da camada de inferência e realizar inferência de contextos, ações e notificações. Camada de Aplicação – consome dados das camadas anteriores e é responsável por interagir com o usuário podendo gerar regras para a camada de inferência conforme solicitações do usuário; agentes computacionais (não-humanos) e

Legenda: Aplicação

Aplicação

Aplicação Fluxo de dados (exceto de configuração):

Publicação

Publicação

Armazenamento Processamento

Armazenamento Processamento

Consumo

Consumo

Consultas no sentido inverso das setas Dados de resposta no sentido direto

Publicação

Publicação

Armazenamento Processamento

Armazenamento Processamento

Consumo

Consumo

Endpoint

Endpoint

Base LOD

Base LOD

Sensoriamento

Dados

Inferência

Aplicação

mashups também poderiam compor esta camada.

Endpoint Sensor Físico

Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como produtores e consumidores. Entradas para configuração dos módulos foram omitidas.

3.2.2.1 Camada de dados e sensoriamento Esta camada é formada por módulos que devem disponibilizar SPARQL Endpoints para consulta, mas que podem diferir complemente na forma como obtém seus dados. Sendo assim, são classificados em módulo de dados e módulo de sensoriamento.

69

O módulo de sensoriamento adquire dados de sensores físicos heterogêneos, que podem ser locais ou remotos. No caso de sensores locais, o dispositivo do usuário deve estar executando um módulo de sensoriamento ou inserir seus dados em um existente na nuvem. Os módulos desta camada podem utilizar técnicas estatísticas, redes Bayesianas, lógica nebulosa, etc. para tratamento de dados, que reduzam a incerteza antes de disponibilizá-los à camada de inferência. O módulo na parte inferior direita da Figura 7 poderia ter, por exemplo, um classificador que filtraria amostras obtidas de um microfone (sensor físico). O módulo de dados executa a função de publicar dados estáticos ou que mudam com baixa frequência, adquiridos de bases de dados e perfis de usuário. Sendo assim, fornecem dados de guias de ruas, serviços públicos, pontos de interesse, preferências do usuário, etc. Estes dados podem ser mapeados diretamente de bancos de dados relacionais ou armazenados em repositórios de triplas. Note que estes módulos não precisam ser construídos do zero, pois já vem sendo implementados na iniciativa de Dados Ligados. 3.2.2.2 Camada de Inferência Esta camada é a mais próxima do foco deste trabalho. Ela se organiza como uma rede de módulos, a saída de um é ligada à entrada de outro, capazes de realizar inferência sobre dados de outras fontes com base em procedimentos (como ontologias, regras, programas imperativos, etc.) definidos pelo desenvolvedor. Basicamente, cada módulo carrega dados de um ou mais SPARQL Endpoints (módulos da camada de dados e sensoriamento ou da camada de inferência), processa estes dados e disponibiliza os resultados através de seu próprio endpoint (Figura 7). Assim, podem-se identificar três etapas realizadas: carregamento, processamento e publicação. A etapa de carregamento de dados é realizada por meio de consultas SPARQL. Já nesta etapa é possível algum processamento utilizando consultas SPARQL Construct. As consultas e suas configurações (URL de acesso dos endpoints, a frequência com que as consultas devem ser executadas, etc.) devem ser facilmente definidas pelo desenvolvedor. Os dados obtidos são armazenados em uma base intermediária. A etapa de processamento permite utilizar os dados armazenados na base intermediária, e seguindo algum algoritmo de processamento descobrir novas informações e adicioná-las à base intermediária ou modificar informações existentes. No estágio atual, almeja-se apenas inferência usando ontologias OWL e/ou regras definidas pelo desenvolvedor. Atualmente, identificam-se quatro tipos de tarefas de processamento:

70

Mapeamento vocabulário-ontologia (MVO) Mapeamento inter-ontologias (MIO) Inferência de contexto de mais alto nível (ICAN) Geração de recomendação (GR) Ontologias devem seguir os padrões RDFS e/ou OWL e precisam ser cuidadosamente desenvolvidas para atender os requisitos de expressividade do domínio em questão. Por esta razão serão denominadas ontologias de domínio (ODs). Regras também podem ser utilizadas, visto que OWL ainda possui carências de expressividade. Contudo ao desenvolver ontologias e regras deve-se atentar para manutenção da consistência e decidibilidade (veja seção 2.3.2). Retornando às tarefas de processamento, o MVO é necessário quando vocabulários de bases externas não são adequados para inferência, mapeando, assim, conceitos destes vocabulários para ODs. O MIO permite reutilizar ODs existentes, através da definição de relações entre conceitos e propriedades. Assim, caso exista mais de uma OD, a mais adequada pode ser adotada e conceitos das demais mapeados para conceitos da OD utilizada. A ICAN permite deduzir contexto de mais alto nível pela combinação de contextos de mais baixo nível, dados de bases, de perfis de usuário e de sensores físicos. Exemplos são descobrir bairro ou cidade a partir das coordenadas geográficas do usuário ou se uma pessoa tem algum amigo ou parente fazendo aniversário em determinada data. Na seção 2.3.2.5 é apresentado um exemplo de ICAN utilizando regras (não representável em OWL 2 DL) para deduzir a atividade de um usuário (MeetingSupervisor). Já a GR é responsável pela geração de recomendações, que podem ser ações para a aplicação ou notificações ao usuário. Exemplos seriam notificar usuário sobre aniversário de um amigo, executar a ação de comprar um livro quando determinadas condições definidas pelo usuário acontecem (disponibilidade de um título, preço, etc.), ou executar a ação de colocar o celular em estado vibratório ao entrar em uma sala de cinema ou de reunião. O processamento mais elaborado é feito usando ontologias e regras, mas é possível, logo no carregamento, usar SPARQL Construct para fazer alguns mapeamentos (MVO e MIO) e até mesmo ICAN e GR. Uma vez concluído este processo, a etapa de publicação disponibiliza um SPARQL endpoint na nuvem de LOD com os dados derivados gerados na etapa de processamento. Por fim, esta camada poderia ser expandida ou uma quarta camada poderia ser adicionada para contemplar outras possíveis necessidades.

71

3.2.2.3 Camada de Aplicação Como o nome sugere, as aplicações estão nesta camada. Ela interage diretamente com o usuário final, sendo responsável por fornecer a interface de comunicação com o usuário e também de obter seu perfil (gostos, interesses, e outras informações que sejam úteis para a aplicação) sendo, portanto, pouco generalizável. Os dados sobre o perfil do usuário podem estar nesta camada caso o perfil seja armazenado pela aplicação, ou podem estar na camada de dados caso o perfil fique em um endpoint remoto. Espera-se que o desenvolvedor da aplicação precise apenas criar a interface com o usuário, algumas consultas a módulos da camada anterior e controlar a interação. Necessidades do usuário e da aplicação podem ser expressas por tais consultas ou regras dentro de módulos de inferência externos, ou seja, não manipuláveis diretamente pela aplicação. Neste caso, é necessário usar regras parametrizadas nestes módulos. Exemplificando, considere uma regra para geração de uma ação de compra de livros (GR) que considera assunto e preço. Neste caso, pode-se ter uma única regra genérica que dispara a ação “comprar” quando assunto e preço (oriundos do perfil do usuário) coincidem com bases de livrarias. Desta forma, nem assunto nem preço podem ser fixados na regra, pois podem variar drasticamente ao longo do tempo. Sendo assim, o módulo que contém esta regra precisa realizar consultas que obtenham estes dados de perfis do usuário situados na camada de dados. No final, a aplicação precisa apenas atualizar o endpoint que armazena tais dados e o módulo se encarrega de obtê-los. Em um estágio futuro, regras poderão ser passadas diretamente à camada de inferência por meio de uma biblioteca fornecida pela arquitetura que gerencie as transferências e a comunicação entre as duas camadas, tornando-as mais dinâmicas. Adicionalmente, agentes computacionais e mashups também poderiam participar desta camada, mas isto não está no escopo deste trabalho. O conceito de agente foi discutido no início da seção 2.3 e na arquitetura CoBra na seção 2.4.1. 3.2.2.4 Discussão quanto aos requisitos do problema O uso de serviços Web convencionais exige que o desenvolvedor construa conversores de formato e tradutores para entendimento do significado das respostas do serviço, de forma a casá-las com os conceitos usados por sua(s) ontologia(s) de domínio, quando há tais ontologias. Portanto, a pura adoção de formatos e protocolos padronizados pelo W3C para comunicação já parece beneficiar a interoperabilidade, mas, o descasamento semântico ainda prejudica este requisito. No entanto, uma vez que os formatos sejam comuns, técnicas

72

de mapeamento entre os conceitos (MVO e MIO) se tornam mais simples. Acredita-se também, que a utilização de módulos previamente configurados e/ou de mapeamentos evite a criação ou modificação desnecessária de ontologias e vocabulários permitindo seu reuso. Apesar de tudo, não se deve impedir programação quando necessário. O uso de camadas fracamente acopladas e componentes descentralizados permite que estes rodem em máquinas e dispositivos distintos. Isto é importante para o uso de dispositivos móveis, necessários para atender os requisitos da Computação Ubíqua. Assim, uma aplicação em um dispositivo móvel pode ter o processamento pesado executado em servidores na nuvem de forma descentralizada e até mesmo distribuída. Aplicações mais simples podem ficar autocontidas no próprio dispositivo móvel. Com esta arquitetura, espera-se que não seja necessário que o desenvolvedor de aplicações CC defina e implemente tudo que precise (desde fontes de sensores e formatos de dados até ontologias e processadores). Assim, ao desenvolver uma aplicação ele pode aproveitar conjuntos de dados da nuvem LOD, consultas, ontologias e regras já existentes para seu domínio de aplicação e até mesmo módulos que já estejam funcionando na nuvem. Caso não exista um módulo disponível na nuvem que atenda todas as suas necessidades, o desenvolvedor de aplicação poderia se concentrar em: 1. Determinar ontologia(s) de domínio utilizada(s) na camada de inferência (ODs); 2. Determinar os endpoints que sirvam como fontes de dados (LOD, sensores ou módulos que atendam parcialmente), seus vocabulários e ontologias, e consultas SPARQL para obter os dados; 3. Mapeamento entre os vocabulários/ontologias das fontes e as ontologias de domínio (MVO e MIO); 4. Regras para inferência de contexto (ICANs) e geração de recomendações (GR); 5. Se concentrar na interface com o usuário da aplicação. Consequentemente, estes fatores (reuso, interoperabilidade e poucas etapas) devem levar a um aumento de produtividade se comparados às técnicas abordadas na literatura (criação de modelo de contexto e ontologias específicos para a aplicação). Esta arquitetura está em estado inicial e deverá sofrer modificações, como adição de novos módulos, componentes e até camadas.

73

3.3

Escopo do trabalho: o Módulo de Inferência Esta seção apresentará detalhadamente o Módulo de Inferência, foco deste trabalho,

como possível solução para o problema específico descrito na seção 1.3. Este módulo é parte da camada de inferência da arquitetura LOUD. O módulo pode ser configurado para ser capaz de carregar dados de várias fontes via SPARQL, processar estes dados usando OWL e regras definidas pelo usuário e prover seus dados a outros por meio de um SPARQL endpoint. Instâncias deste módulo na nuvem poderiam ser representadas na nuvem de LOD 12 como um quadrado em vez de um círculo para mostrar que há processamento de inferência. As camadas de aplicação e de dados e sensoriamento não estão no escopo deste trabalho, sendo assim, apenas o necessário para experimentos será construído: prover SPARQL Endpoints e aplicações para visualização sem aprofundamento. Módulos de sensoriamento serão simulados, isto é, não serão utilizados sensores de fato, mas apenas dados crus (raw data) históricos que tenham sido obtidos de sensores reais ou dados simulados de sensores fictícios. Estes dados servirão de base, juntamente com dados provenientes de módulos de dados para inferências de contexto de mais alto nível. Os módulos de dados conterão triplas de dados oriundos de bancos de dados relacionais (triplas virtuais) ou de repositórios de triplas (triplas materializadas). Aplicações que possam porventura ser construídas servirão apenas para visualização de dados das camadas inferiores, nunca voltados para interação com o usuário. As subseções a seguir apresentarão o estrutura interna do Módulo de Inferência, sua implementação e configuração. 3.3.1 Estrutura Este módulo é dividido em quatro componentes conforme apresentados na Figura 8 e descritos nas próximas subseções. Maiores detalhes sobre etapas internas e iterações entre componentes serão abordadas na seção 3.3.1.5.

12

Linked Data Cloud - http://lod-cloud.net/

74

Interface Web

SPARQL Endpoint

Legenda: Direção do fluxo de triplas RDF

Motor de Inferência Ontologias & Regras

Base de Armazenamento

Comunicação bidirecional: motor de inferência lê dados da base e adiciona novas triplas RDF na base

Carregadores de Dados

Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação bidirecional) é representada para fins didáticos, pois a base pode conter triplas virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a leitura sobre Jena e Pellet na seção 2.3.2).

3.3.1.1 Carregadores de dados O componente de carregamento é, na verdade, um conjunto de subcomponentes que rodam paralelamente, de forma que cada um encarrega-se de executar consultas SPARQL e obter dados de um único endpoint externo de forma síncrona ou assíncrona. O primeiro método é também conhecido como pull de forma que o carregador envia uma consulta SPARQL e permanece bloqueado até que o endpoint consultado retorne a resposta. Pode-se configurá-lo de maneira que cada carregador tenha o endereço do endpoint externo, as consultas a serem executadas contra este endpoint, a frequência de cada uma delas e possíveis substituições de variáveis. O segundo método é denominado push (ou publish/subscribe) e pode ser encontrado em (PASSANT; MENDES, 2010). Basicamente, ele funciona de forma a não bloquear o carregador até receber a resposta de uma consulta, ou seja, o carregador é acionado por eventos assíncronos. Para isso, o carregador se registra no servidor SPARQL fornecendo o evento, a consulta a ser executada quando este evento ocorrer no servidor e um ponto de retorno que receberá os resultados. Este segundo método pode ser usado para lidar com dados dinâmicos de sensores ou redes de sensores, de forma que os dados oriundos do sensoriamento podem ser recebidos de forma assíncrona, ou seja, sem intervalos de tempo pré-definidos. Esta funcionalidade é importante, pois comunicações assíncronas são comuns em redes de sensores que são comumente utilizadas para monitorar eventos físicos. O método também pode ser aplicado ao consumir dados de outros módulos de inferência, ou seja, o módulo de inferência fonte geraria um evento ao, por exemplo, deduzir um novo contexto. Atualmente, apenas operações síncronas são possíveis, mas operações assíncronas deverão ser permitidas no futuro.

75

A substituição de variáveis (variable binding) permite a construção de consultas parametrizadas, ou seja, que podem ter parâmetros com valores definidos dinamicamente. Assim, pode-se ter uma consulta com uma variável que é substituída, por exemplo, com a data e hora do momento de execução da mesma, ou com dados provenientes de outras consultas. O elemento responsável por fazer estas substituições é aqui denominado binder. Desta forma, antes de um carregador executar uma consulta, ele aciona o binder associado a ela que pode retornar até mesmo mais que uma consulta a ser executada pelo carregador. Neste caso, a consulta funciona como um modelo para a geração de várias consultas semelhantes, mas com valores diferentes nas variáveis substituíveis. O uso de binders poderia, em parte, ser substituído por SPARQL federado, mas devido ao pouco suporte atualmente, problemas de travamento durante testes e de estar fora do escopo isto não foi implementado. Dois tipos de consultas SPARQL são permitidos: DESCRIBE e CONSTRUCT. Ambas podem ter variáveis substituídas. A primeira descreve um ou mais recursos, ou seja, retorna todas as triplas tais que estes recursos são sujeitos, exatamente como estão na base consultada. A segunda forma permite mudar o padrão do grafo de resultado da consulta sem alterar o grafo da base consultada e, por este motivo, pode ser utilizada para certos mapeamentos conforme citado na seção 3.2.2.2. O resultado das consultas de cada carregador é guardado por cada um para posterior inserção na base de armazenamento intermediário. 3.3.1.2 Base de armazenamento intermediário O componente de armazenamento é um conjunto de grafos RDF independentes usados em várias fases. Primeiramente, armazena as triplas obtidas pelo componente de carregamento, a seguir o processo de inferência é feito sobre estes dados e, finalmente, o endpoint publica esta base. A criação de grafos intermediários é tratada pelas aqui denominadas políticas de atualização. Por exemplo, uma política “limpe e insira” poderia usar uma base vazia na fase pré-carregamento (grafo inicial) e eliminar dados intermediários após a inferência e antes de publicar. Outra política poderia manter alguns dados anteriormente publicados como grafo inicial e manter os dados intermediários gerados durante a inferência para publicação. Esta base pode ser armazenada em memória principal, em disco local ou até mesmo em cluster ou na nuvem conforme a necessidade, e também numa combinação destes. Mas é importante salientar que o segundo e terceiro casos são mais comuns para bases maiores e podem ser insatisfatórios, com respeito a desempenho e tempo de resposta, para executar

76

inferências. Por este motivo apenas bases em memória principal estão sendo consideradas neste trabalho. 3.3.1.3 Motor de Inferência ou Reasoner O componente de inferência permite processar o grafo de dados pós-carregamento (grafo inicial mais grafo com resultado das consultas) com base em ontologias OWL e regras definidas pelo projetista/desenvolvedor. Uma nova inferência é executada quando algum carregador detecta novos dados. Neste trabalho não haverá distinção formal entre os tipos de processamento que podem ser efetuados (MVO, MIO, ICAN e GR, vide seção 3.2.2.2) visto que do ponto de vista do módulo de inferência a distinção está apenas na forma de construção utilizada: SPARQL Construct, ontologias OWL e regras IF-THEN. Assim, é possível dizer, por exemplo, que Pessoa e Person são classes equivalentes (MIO) de três formas distintas, mas com igual significado: 1. CONSTRUCT { ?uri a x:Pessoa ; a y:Person . } WHERE { ?uri a x:Pessoa . } 2. x:Pessoa owl:equivalentClass y:Person . 3. ?uri a x:Pessoa  ?uri a y:Person . Na primeira forma, utiliza-se SPARQL Construct no componente de carregamento, de forma que a existência de um recurso do tipo x:Pessoa na base consultada, determina que este recurso também será uma instância de y:Person na base do módulo que consulta. A segunda utiliza a propriedade simétrica e transitiva owl:equivalentClass da linguagem OWL (seção 2.3.3). A terceira utiliza uma regra IF-THEN, similar a primeira forma usando SPARQL, mas que não requer repetição da afirmação que o recurso é instância de x:Pessoa, visto que esta afirmação já se encontra na base. Pode-se notar também que, a segunda forma difere das demais por não relacionar instâncias diretamente sendo perfeitamente compatível com reasoners DL. Contudo, se for usado um sistema de inferência baseado em regras e sem regras para os axiomas OWL, é necessário tratar as instâncias adicionando-se as seguintes regras (prefixo owl omitido): 2.1.

?c1 equivalentClass ?c2  ?c2 equivalenteClass ?c1

2.2.

?c1 equivalentClass ?c2 , ?c2 equivalentClass ?c3  ?c1 equivalenteClass ?c3

2.3.

?c1 equivalentClass ?c2 . ?x a ?c1 .  ?x a ?c2

77

A regra 2.1 fornece a simetria e a regra 2.2 garante a transitividade, enquanto a regra 2.3 é a forma genérica da regra expressa na terceira forma. Desta forma, estas três regras genéricas reduzem significativamente a quantidade de regras a serem escritas quando há muitas classes. Exemplo: considerando classes C 1 a C2n, onde Ci é equivalente a Cj, com i ímpar e j = i + 1, seriam necessárias 2n regras usando instâncias, e nenhuma regra adicional usando 2.1, 2.2 e 2.3. Neste segundo caso seria necessário, contudo, definir os n axiomas owl:equivalentClass. Para C1 a C3n, com Ci equivalente a Ci+1 equivalente a Ci+2, e i = {1, 4, 7, ... } tem-se 3n regras contra 2n axiomas. 3.3.1.4 SPARQL Endpoint O Sparql Endpoint é o quarto e último componente do Módulo de Inferência e permite que a aplicação e/ou outros módulos da camada de inferência acessem o conteúdo da base local usando o protocolo SPARQL do W3C. Assim, o módulo mantém um protocolo padronizado tanto na entrada (componente de carregamento) quanto na saída, permitindo que diversos módulos de inferência formem uma rede sendo cada um responsável por uma pequena parte de todo processamento. Uma interface para navegadores Web (página HTML) também é disponibilizada para navegação básica e executação de consultas. Após dados serem carregados e o motor de inferência ser acionado, o endpoint é atualizado. Para que estes novos dados estejam disponíveis para consulta por terceiros, duas formas de atualização foram planejadas. A primeira publica a mesma base usada pelo sistema de inferência. A segunda copia toda a base usada pelo sistema de inferência para uma segunda base contendo as triplas materializadas. Enquanto no primeiro caso há o benefício da publicação de novos dados mais rapidamente, no segundo há o benefício de se poder aproveitar de índices construídos pelo banco de triplas. No entanto, no primeiro caso, toda consulta pode provocar algum processamento lógico parcial, e no segundo caso, a cópia pode ser bastante demorada visto que todo o processo de inferência precisa ser executado de uma vez, podendo ser uma péssima escolha quando a atualização da base é muito frequente. Devido ao fato de ambos possuírem prós e contras, a definição de qual método adotar é definida pelo desenvolvedor no arquivo de configuração. 3.3.1.5 Estrutura de funcionamento Nas seções anteriores, cada componente foi apresentado separadamente. Nesta seção, as iterações e as etapas internas serão mais detalhadas.

78

A Figura 9 apresenta um diagrama de atividades do funcionamento do módulo. Primeiramente, o arquivo de configuração é lido e processado, para então se iniciar o endpoint e os carregadores de dados. A partir deste momento, tanto o fluxo principal (à esquerda) quanto os fluxos dos carregadores (no centro) ocorrem paralelamente. Apesar de a figura apresentar apenas um fluxo de carregador, vários podem executar paralelamente em suas respectivas threads. Quando um carregador obtém novos dados, ele ativa um sinal que pode ser percebido pelo fluxo principal e este executa o motor de inferência registrado. Em vez de o fluxo do carregador gerar um evento que dispara o reasoner diretamente, é o fluxo principal que percebe a ativação do sinal e executa o reasoner. Assim, se dois sinais forem gerados por diferentes carregadores num pequeno intervalo de tempo, a inferência executa apenas uma vez com os dados de ambos. Consequentemente, se durante uma inferência outros carregadores ativarem o sinal, nenhuma inferência adicional será executada em paralelo. Isto é particularmente útil no caso em que o tempo de inferência é maior que o intervalo entre consultas, evitando maior sobrecarga na máquina executante. Isto pode ocorrer devido a uma configuração equivocada (intervalo muito pequeno), devido à sobrecarga do processador da máquina ou mau dimensionamento de recursos. Quando a inferência termina, o endpoint é atualizado conforme a forma de atualização definida na configuração.

Figura 9. Diagrama de atividades do módulo de inferência

79

Em relação a um carregador, o fluxo central da Figura 9 apresenta três etapas. Na primeira, as consultas podem ter suas variáveis substituídas (variable binding) por valores conforme configuração fornecida. Isto pode gerar uma ou mais consultas que são executadas em sequência e seus resultados unidos em um único grafo. Uma vez que todos os dados foram obtidos, o carregador ativa seu sinal de aviso de modificação. Por fim, as etapas internas da atividade de inferência (à esquerda) são detalhadas no fluxo à direita (ligadas por um linha tracejada). Este fluxo está estreitamente relacionado às políticas de atualização anteriormente citadas, responsáveis por criar os grafos intermediários conforme pode ser visto nas atividades de obtenção do grafo inicial ou pré-carregamento, do grafo pré-inferência ou pós-carregamento e, por fim, do grafo para publicação. A atividade de obtenção do grafo pré-carregamento recebe o grafo atualmente publicado (GPUB), que é vazio na primeira iteração, e retorna o grafo inicial (G0) construído conforme a política de atualização. Em seguida, a segunda atividade reúne os resultados das consultas dos carregadores (GRC[i]) em um grafo GRC, onde a quantidade de operações de união depende da quantidade de carregadores existentes e, por fim, G0 é adicionado a GRC. A próxima atividade constrói o chamado grafo antes da inferência (G AInf) a partir dos grafos GPUB e GRC, permitindo, assim, adicionar ou remover triplas antes da execução da inferência. A quarta atividade, finalmente, realiza a inferência sobre os dados do G AInf utilizando as ontologias e regras definidas, produzindo então o grafo da inferência (G INF). Apesar de já haver pesquisas em inferência incremental, ou seja, aquela que não requer processamento para toda a base de dados, apenas para a parte modificada, as ferramentas que a fazem ainda estão em estágio inicial, e por isso, o assunto não entrou no escopo deste trabalho (GESSLER et al., 2009; SIRIN, EVREN et al., 2007). As duas últimas etapas são a construção do grafo para publicação (GPUB) a partir de GPUB, GRC e GINF e, finalmente, a atualização do endpoint. O algortimo pode ser visto a seguir: 1 2

G0 := get_initial_graph(GPUB) GRC := {}

3

Para cada carregador i faça GRC := GRC ∪ GRC[i]

4 5 6 7 8

GRC := GRC ∪ G0 GAInf := get_graph_before_reasoning(GPUB, GRC) GINF := do_reasoning(GAInf) GPUB := get_publishing_graph(GPUB, GRC, GINF) update_endpoint(GPUB)

Nota-se que, se a política de atualização for eficiente, como por exemplo, sempre retornar um grafo vazio ou já existente (GPUB, GRC e GINF, nas etapas grafo inicial, grafo antes

80

da inferência e grafo para publicação, respectivamente), os pontos que poderiam gerar gargalos são: a) Criação do GRC (linhas 2, 3 e 4 do algoritmo); b) Inferência (linha 6) e; c) Atualização do endpoint (linha 8). O ponto (a) tende a ser linear conforme a quantidade de triplas. No caso (b), o sistema de inferência geralmente executa apenas um rápido pré-processamento, sendo a inferência (que pode ter complexidade polinomial ou exponencial conforme a ontologia) executada, de fato, na atualização do endpoint (c) ou após a sua publicação quando houver uma consulta ao grafo GPUB. O fator determinante é a forma escolhida para atualização do endpoint (discutida na seção 3.3.1.4). 3.3.2 Implementação O Módulo de Inferência foi implementado usando a linguagem Java e as bibliotecas Jena e Pellet. Jena é capaz de processar RDF e OWL programaticamente e inclui reasoners baseados em sistemas de regras para RDF e OWL. Pellet é um reasoner OWL-DL implementado em Java que aceita ontologias que sigam a especificação OWL 2 DL e regras DL-seguras escritas usando a sintaxe SWRL (detalhes na seção 2.3.2 e 2.3.2.5). ARQ é um motor SPARQL que suporta SPARQL 1.0 e 1.1 além de um conjunto de extensões. Fuseki é um servidor SPARQL compatível com protocolo SPARQL sobre HTTP que também aceita SPARQL 1.0, 1.1 e extensões do ARQ. Ambos ARQ e Fuseki são parte da biblioteca Jena. Para permitir exploração do endpoint via navegadores Web foi usada uma aplicação Ajax chamada SNORQL13. Como a configuração dos módulos é feita via XML foi usado a biblioteca XStream para carregar XML e converter em objetos Java. Antes de entrar nos detalhes de implementação cabe informar a existência de duas classes e uma interface da biblioteca Jena largamente utilizadas. A interface Model representa um Grafo RDF que pode ser manipulado programaticamente pois permite leituras, inserções e remoções de triplas RDF sem necessitar de escrita de consultas SPARQL. A interface Reasoner representa um motor de inferência genérico que é especilizada tanto pelo reasoner baseado em sistemas de regras quanto pelo reasoner Pellet. A classe Query representa uma

13

SNORQL: an AJAXy front-end for exploring RDF SPARQL endpoints – https://github.com/kurtjx/SNORQL

81

consulta SPARQL e é capaz de parsear um texto descrevendo uma consulta e armazenar numa forma intermediária para posterior utilização dentro de motores SPARQL. A Figura 10 apresenta o diagrama das principais classes que compõem o Módulo de Inferência. A utilidade da maioria das classes e interfaces já foi apresentada em alto nível na seção anterior. As interfaces UpdatePolicy, QueryParameterBinder, SparqlExecutor e Loader representam políticas de atualização, substituidor de variáveis, executante de consultas SPARQL e carregadores respectivamente. Esta última é especializada em PullLoader, que são os carregadores síncronos já descritos, e cada instância desta classe é capaz de enviar múltiplas consultas a um endpoint e estas consultas são executadas em sequência. A classe SparqlExecutor possibilita a execução dos quatro tipos de consulta SPARQL existentes e se especializa em SparqlGraphExecutor e SparqlEndpointExecutor (não mostrados no diagrama) que são capazes de executar consultas a um grafo (interface Model do Jena) e a um endpoint remoto respectivamente. Classes que realizam QueryParameterBinder, ou seja, que implementam esta interface, são capazes de fazer a substituição de variáveis conforme já mencionado e serão detalhadas mais adiante. A interface UpdatePolicy é composta por três métodos que são equivalentes aos métodos apresentados no algoritmo da seção 3.3.1.5: getInitialGraph(GPUB) – retorna o grafo inicial (linha 1); getPreReasoningGraph(G PUB, GRC) – retorna o grafo que será passado ao motor de inferência (linha 5); e getPublishingGraph(GPUB, GRC e GINF) – retorna o grafo a ser publicado no SPARQL endpoint (linha 7). isCurrentModelChanged(mask) – retorna true caso o(s) método(s) definido(s) por mask alterem o grafo GPUB. O parâmetro mask representa um ou mais dentre os três métodos anteriores de UpdatePolicy. Este método é usado apenas na fase de leitura do XML e caso algum método retorne true o endpoint será atualizado por cópia para evitar alterações concorrentes no grafo GPUB (vide seção 3.3.1.4). Isto dá uma grande liberdade para a construção de diversos tipos de políticas de atualização, contudo apenas a classe ClearDataPolicy foi implementada neste trabalho e da forma mais simples possível: os métodos retornam um grafo inicial vazio, G RC e GINF, respectivamente.

82

Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado.

A classe SparqlServer encapsula uma instância do servidor Fuseki e permite inicialização e término e, principalmente, atualização do grafo disponibilizado pelo endpoint. As classes QueryConfig e QueryData, esta uma classe interna à classe PullLoader, guardam as consultas e suas configurações (binder e intervalo entre consultas) para cada um dos carregadores (um QueryData para cada consulta e um ou mais QueryData’s para cada carregador PullLoader). Quando um QueryConfig é adicionado a um Loader ele é selado, ou seja, não pode mais ser modificado. Qualquer tentativa de chamar métodos setX provoca o lançamento de uma exceção. A classe QueryConfig pode ser especializada ao se criar outros carregadores que necessitem de parâmetros adicionais (como o push loader) mas mantendo este comportamento. A classe InferenceModule orquestra o funcionamento de todas estas classes como será mostrado no próximo parágrafo. Disjunta a todas está a interface InfModReasonerFactory que é utilizada para instanciar um Reasoner antes da inicialização da classe InferenceModule. Observe que há uma fábrica para motor de inferência Jena e outra para Pellet. Após a leitura do XML de configuração, que será explicado na próxima seção, o conjunto de classes apresentado no diagrama da Figura 10 é instanciado e o processo apresentado no diagrama de atividades da Figura 9 é iniciado. Tanto por questão de espaço

83

quanto de visibilidade, o diagrama de sequência das classes foi dividido em dois conforme mostrado nas Figuras 11 e 12. A primeira foca na classe InferenceModule e será identificado por DS.IM (Diagrama de Sequência da classe InferenceModule) e a segunda na classe PullLoader (identificado por DS.PL). Primeiramente, o método start() da classe InferenceModule é chamado (DS.IM/1), e então o servidor SPARQL (DS.IM/1.1) e os carregadores

registrados

também

são

iniciados

(DS.IM/1.2).

Todos

executam

independentemente em seus próprios threads. A partir deste momento, cada carregador entra em um laço composto pelas mensagens DS.PL/1.x, que fazem a substituição de variáveis (messagens 1.1 e 1.1.1), e executam cada consulta resultante desta substituição conforme seu tipo (1.2 ou 1.3) e finalmente guardam seu resultado e sinalizam modificação (1.4). Enquanto o módulo deve permenecer executando ele verifica alguma alteração nos dados dos carregadores (DC.IM/1.3) e em caso afirmativo executa as mensagens DS.IM/1.4-1.9 que representam as linhas 1, 2-4, 5, 6, 7 e 8 do algoritmo da seção 3.3.1.5, respectivamente. O término da execução do módulo é disparado pela chamada ao método stop() (mensagem DS.IM/2) que desencadeia as mensagens DS.IM/2.1 (a mesma que DS.PL/2), DS.PL/2.1, DS.PL/2.2 e DS.IM/2.2. Do ponto vista do desenvolvedor este processo é atualmente iniciado ao pressionar as teclas Ctrl+C no terminal de execução.

84

Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule.

85

Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader.

A interface QueryParameterBinder merece destaque adicional por possuir quatro classes que a realizam. Conforme apresentado na fig, esta interface possui o método bind que recebe uma consulta, efetua as substituições de variáveis cabíveis e retorna uma ou mais

86

consultas resultantes na forma de lista. A classe DefaultQueryParameterBinder implementa o comportamento mais simples: retorna uma lista com um elemento, sendo este a mesma consulta inicial. A classe SelectQueryParameterBinder executa uma consulta SPARQL SELECT e substitui as varíaveis resultantes na consulta inicial. Como um SPARQL SELECT produz um resultado tabular, cada linha do resultado gera uma consulta como resposta. A classe TimeFrameQueryBinder computa um intervalo de tempo cujo término é o instante de execução da consulta e cujo inicio é o instante de término menos um intervalo definido na configuração deste binder (valor fixo). Ambos os instantes são substituídos nas variáveis ?startDate e ?finalDate. Por fim, tem-se a classe OffsetSplitterQueryParameterBinder que permite que consultas cujo endpoint fonte limite o tamanho das respostas sejam executadas e retornem todos os resultados desejados. Assim, este binder executa uma consulta que informa a quantidade de resultados (consulta de contagem), então, a consulta que obtém todos estes resultados é quebrada em várias consultas que contém as cláusulas OFFSET e LIMIT definidas. A consulta de contagem e o valor do LIMIT são definidas na configuração do binder. Tanto o sistema de regras do Jena quando o motor de processamento SPARQL do ARQ permitem a criação de funções personalizadas. Algumas são fornecidas juntamente com a biblioteca por padrão, outras foram criadas para serem adicionadas ao Módulo de Inferência via um sistema de plugins que são definidos na linha de comando. As funções do sistema de regras do Jena são conhecidas como regras embutidas (rule built-ins). Em linhas gerais, uma função personalizada do ARQ ou de regras é construída via realização de uma interface (Function e Builtin, respectivamente), ou mais facilmente no caso do ARQ, via especialização de uma dentre diversas classes de mais alto nível da biblioteca. Funções do ARQ e built-ins do Jena diferenciam-se pelo fato de que as primeiras recebem uma lista de valores (literais) e retornam outro valor, enquanto que os built-ins podem receber literais e variáveis e retornam sempre um booleano ou nada. Quando estes built-ins são chamados no corpo (antecedente) de uma regra o retorno é um booleano e quando chamados na cabeça (consequente) da regra não há retorno. Isto ocorre pois o corpo da regra define se a cabeça da regra será executada ou não via expressão booleana, ou seja, se todos os itens do antecedente são verdadeiros então o consequente será executado. Como o consequente apenas executa comandos não há necessidade de retorno. Nesta implementação apenas funções ARQ e built-ins de antecedente precisaram ser construídos. O Quadro 7 a seguir apresenta estas funções com uma pequena descrição, o tipo (função ARQ/SPARQL ou built-in de regras) e a origem (se já fornecida

87

pela biblioteca ou criada para o Módulo de Inferência por meio de plugins). Seus usos serão apresentados no Capítulo 4 e apêndices conforme necessário. Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas.

Tipo Assinatura Regra curTime(?tm)

Descrição Coloca xsd:dateTime atual em ?tm.

Regra makeNearestDateTime(?dtin, ?dtout)

Calcula próxima ocorrência da data de entrada, InfMod ou seja, mantém dia e mês e ajusta o ano.

Regra dateSum(?date_in, ?days, ?date_out) Regra dateDiff(?date1, ?date2, ?days) Regra noValue(?s, ?p, ?o) Regra notEqual(?x, ?y) Regra le(?x,?y) Regra ge(?x,?y) Regra localname(?uri, ?lname) makeNamedNode( ?new_node, )

Regra

SPARQL localname(?uri) SPARQL maxMatch(?a, ?b) SPARQL

distanceFromDegrees( ?lat1, ?lon1, ?lat2, ?lon2)

SPARQL nb_contains(?b, ?lat, ?lon) SPARQL concat(?a, ?b, ...) SPARQL sha1sum(?x) SPARQL sumTime(?dt, ?days, ?secs)

Origem InfMod

Adiciona ?days dias à data de entrada, InfMod colocando o valor na data de saída. Subtrai ?date1 - ?date2 retornando a diferença InfMod em dias em ?days. Retorna true se a tripla não está presente na Jena base. Retorna true se ?x != ?y Jena Retorna true se ?x = ?y Jena Coloca o localname de ?uri em ?lname. InfMod Ex. http://example.org/res/Fulano => “Fulano” ?new_node recebe um novo nó cujo URI é dado pela concatenação dos demais parâmetros. Retorna um literal string contendo o localname de ?uri Retorna a similaridade entre duas strings ?b e ?b Retorna a distância em metros entre as coordenadas geográficas (?lat1, ?lon1) e (?lat2, ?lon2). Retorna true se o ponto (?lat, ?lon) se encontra dentro do polígono com URI ?b. Retorna um literal string contendo a conctenação dos parâmetros. Calcula o SHA1 de ?x e retorna como um literal string. Retorna um xsd:dateTime que representa ?dt somados a ?days dias e ?secs segundos.

InfMod ARQ InfMod InfMod InfMod ARQ ARQ InfMod

3.3.3 Configuração Para a correta configuração de um módulo deve-se primeiro planejar o que deverá ser feito antes de escrever o arquivo XML de configuração. Este planejamento inclui escolher SPARQL endpoints cujos dados sejam adequados à aplicação a ser desenvolvida assim como possíveis ontologias que possam ser usadas. Este procedimento é complexo, pois requer levantamento e pesquisa de endpoints e ontologias existentes. Contudo, acredita-se que no

88

futuro isto não seja mais um problema conforme a tecnologia da Web Semântica se difunda. Quando não se encontram ontologias/regras prontas referentes ao domínio da aplicação tornase necessário construí-las. No capítulo seguinte serão apresentados alguns exemplos onde ontologias e regras foram construídas e também os próprios endpoints. O restante desta seção apresenta a estrutura e significado do arquivo XML. Inicialmente pretendia-se construir uma ontologia OWL para descrever o arquivo de configuração, contudo não foram encontrados ganhos no escopo deste trabalho e ainda poderia complicar a fase de experimentos com alunos não familiarizados, decidiu-se utilizar apenas XML. A Figura 13 apresenta a hierarquia mais externa de elementos XML. Os elementos loaders, inference e sparqlServer configuram o carregador, o motor de inferência e o servidor SPARQL (endpoint) respectivamente. Outros elementos também importantes são name que define o nome do módulo, prefixes que permite associar diversos namespaces a prefixos (rdf, owl, etc.), clock que aceita um atributo baseUri com o URL do simulador de relógio (desenvolvido especialmente para o módulo), resourceBaseUri que define a URI base para recursos específicos do módulo (atualmente apenas o recurso adicionado automaticamente com os horários de atualização utilizam esta URI), updatePolicy define a política de atualização e apenas ClearDataPolicy é aceita no momento. O elemento inference permite dizer qual motor de inferência deve ser utilizado (PELLET ou JENA) e com qual(is) ontologia(s) e regras. O elemento ontology pode ocorrer diversas vezes e cada ocorrência determina o nome do arquivo contendo uma ontologia que pode estar na mesma máquina do módulo (caminho para um arquivo local) ou na Internet (URL). Esta pode estar escrita tanto em Turtle quando em RDF/XML. O elemento rules recebe regras JENA e é incompatível com PELLET, sendo ignorado caso este seja selecionado pelo elemento reasoner. Para usar regras com Pellet devem-se construir regras SWRL e adicionar à ontologia (para facilitar este processo pode-se usar a ferramenta Protégé14 ou escrever em Turtle, pois RDF/XML é mais verboso e torna a construção mais complexa). O elemento sparqlServer contém três elementos filho. O elemento path determina como acessar o grafo RDF publicado pelo módulo e port diz em qual porta o endpoint estará acessível. Assim, se o módulo utilizar path=/graph/ e port=3333, é possível acessar o endpoint em http://dominio:3333/graph/sparql usando o protocolo SPARQL sobre HTTP. Uma

14

Protégé: a free, open source ontology editor and knowledge-base framework – http://protege.stanford.edu/

89

interface web SNORQL sempre estará disponível em http://dominio:3333/snorql. Finalmente, o elemento fastUpdate informa ao módulo se o endpoint deverá ser atualizado rapidamente ou não. Quando seu conteúdo for true o endpoint publica o mesmo grafo gerado pelo motor de inferência, e caso contrário (false) toda a inferência é processada e adicionada a um grafo com triplas materializadas (cópia).



: texto

...

: texto

: PELLET/JENA

: URI

: arquivo/URL



...

...

: regras do Jena

: URI

: caminho : número : 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



: texto : URL QueryData : SPARQL

: texto : URL : SPARQL : número

: texto : número : texto QueryData ...

: número : URL : 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 “= 18 && ?t PREFIX a: <http://dominio/resource/> CONSTRUCT { ... } WHERE { ... FILTER (?y >= 18 && ?t <= 70) }

Os prefixos definidos dentro do elemento prefixes são válidos em todo arquivo XML, tanto nas regras do elemento

rules quanto nas consultas principais (elemento

91

QueryData/query) e secundárias (elemento binder/query). Assim, aproveitando o exemplo de consulta acima, poderia-se omitir a primeira linha contendo o prefixo e adicionar um elemento Prefix, como mostrado a seguir: 1 2 3 4 a 5 http://dominio/resource/ 6 7 8 ... 9 10 14 15 ... 16

Uma vez completado o arquivo XML basta executar o módulo chamando-o em um terminal java –jar InferenceModule.jar config.xml. Por fim, para executar o plugin que possui funções adicionais para SPARQL e regras Jena apresentadas no Quadro 7 (coluna Origem igual a “InfMod”) deve-se adicionar um parâmetro, e o comando fica como mostrado a seguir: java -Dinfmod.function.path=plugin.jar –jar InferenceModule.jar config.xml

92

4

Cenários de Aplicação Para verificar a aplicabilidade do framework, foram elaborados três cenários que

poderiam ser aplicados no mundo real, porém sem considerar toda sua complexidade, visto que a elicitação e análise de requisitos está fora do escopo deste trabalho por demandar um tempo adicional que impediria seu término no prazo. Mas especificamente, também considerando o fator tempo, foram consideradas situações simplificadas para viabilizar a modelagem e construção de ontologias, regras e consultas. Neste capítulo será apresentado o processo utilizado para a construção da rede de módulos de inferência para cada cenário. Eventuais endpoints construídos para simular dados de sensores e bases LOD também são apresentados, porém de forma bastante superficial no capítulo e um pouco mais detalhada nos apêndices. A criação de endpoints simulados nos cenários decorre da atual carência de bases RDF realmente úteis no âmbito brasileiro. O terceiro e último cenário foi utilizado para que alunos com alguns conhecimentos das tecnologias atuais de Web Semântica (RDF, OWL e SPARQL) avaliassem o módulo. Antes de apresentar os cenários, é importante mencionar que um endpoint especial foi desenvolvido para ser usado em todos os experimentos: simulador de relógio. Conforme o nome indica, ele é capaz de simular um relógio, possibilitando definir horário de início e fim de uma simulação e a velocidade com que o relógio simulado correrá. Assim, é possível usar janelas de tempo quando necessário sem precisar modificar o relógio da máquina hospedeira. Além disso, a taxa de velocidade do relógio permite definir quantos segundos simulados ocorrem para cada segundo real. Por exemplo, uma taxa de 20x significa que quando decorre um segundo na máquina real decorrem 20 segundos no endpoint de relógio. Já uma taxa de 0,25 determina que um segundo real representa um quarto de segundo no endpoint.

4.1

Cenário 1: informação sobre hidrantes durante um incêndio Este cenário foi sugerido pelo aluno de doutorado Tiago Marino que ajudou na sua

construção. Situações de emergência possuem as mais variadas necessidades de informação, que se constituem, entre outras, de dados de saúde, segurança, geologia, logística, etc. Numa situação de emergência surgem diversas perguntas que precisam ser respondidas. Exemplos de tais perguntas são: Qual hospital possui a especialidade de ortopedia, mais próximo à

93

localidade do resgate? Quantas casas existem e quem são seus proprietários em determinada região soterrada por um deslizamento? Onde estão localizados os hidrantes de coluna no raio de 500 metros do foco de um incêndio? Estas questões são levantadas durante uma emergência e demandam resposta rápida para tomada de decisão e gerência da situação. Muitas dessas respostas existem, mas estão armazenadas em bancos desorganizados, não padronizados e não integrados. Para fins demonstrativos, apenas a última pergunta será abordada neste cenário. O objetivo deste cenário é utilizar apenas uma instância do framework proposto para mostrar integração de bases de triplas, inferência e checagem da consistência destes dados usando uma ontologia especialmente desenvolvida, que integra conceitos de vocabulários existentes. A implementação deste cenário requer diversos procedimentos para publicação, integração e consumo, ilustrados na Figura 15 que será explicada ao longo das próximas subseções.

Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD.

O restante desta seção discute a modelagem e construção das camadas de dados e inferências e uma pequena aplicação para consulta e apresentação em mapas. 4.1.1 Modelagem e construção da camada de dados O Corpo de Bombeiros do Estado do Rio de Janeiro (CBMERJ) é o órgão responsável por operações de controle de incêndio no Estado do Rio de Janeiro. Eles utilizam informações

94 do Sistema de Informações Geográficas Vigilância e Controle (ViconWeb 15), que inclui diversas iniciativas de trabalhos que auxiliam o processo de tomada de decisão do órgão. Seu cadastro de recursos hídricos contém informações referentes aos hidrantes de coluna (coordenadas de posicionamento, endereço, batalhão responsável, vazão e condições de funcionamento) existentes na cidade do Rio de Janeiro. Por se tratar de dados restritos ao CBMERJ, uma autorização para a extração do banco para fins de experimentação foi solicitada junto à Instituição. Contudo, para a utilização por parte do módulo de inferência seria necessário ainda a publicação de tais dados em algum SPARQL endpoint. Esta publicação foi feita por meio de um processo de ETL (Extraction, Transformation & Loading) utilizando-se a ferramenta Pentaho Data Integration 4.1.0 16, também conhecida como Kettle, tanto por ser uma ferramenta popular e aberta quanto por já existirem plugins específicos, desenvolvidos no projeto LinkedDataBR17, para se trabalhar com LOD. O projeto disponibiliza quatro plugins: entrada de dados via SPARQL, geração de propriedades de dados e de objetos (object e datatype properties do OWL), saída de dados usando SPARQL Update. Para o armazenamento e disponibilização das triplas, foi utilizado o software Virtuoso18, que é um repositório de triplas que disponibiliza interfaces para consultas SPARQL (SPARQL endpoint). O processo de ETL, superficialmente mostrado na Figura 15, é composto por cinco grandes etapas. A primeira delas é a extração dos dados da base de hidrantes do sistema ViconWeb e sua importação no Kettle. Os dados utilizados são descritos por uma ontologia criada para este cenário e que será discutida mais a frente. Estes dados são tratados para remover valores nulos ou inválidos. O próximo passo é a geração de URIs que consiste em, para cada recurso, utilizar um URL base pré-definido e acrescentar o nome da classe a que o recurso pertence e um identificador. O terceiro passo consiste na geração de campos sujeito, predicado e objeto, onde o predicado pode ser tanto DatatypeProperty quanto ObjectProperty da OWL. Na quarta etapa, os campos gerados anteriormente são convertidos para um único campo NTriplas. Finalmente, as triplas geradas são inseridas no Virtuoso usando SPARQL Update. Uma vez criado o processo, este pode ser executado diversas vezes, conforme necessário, a fim de atualizar a base do Virtuoso. 15

Vicon Web - http://www.viconsaga.com.br

16

Pentaho Data Integration - http://sourceforge.net/projects/pentaho/files/Data%20Integration/4.1.0-stable/

17

LinkedDataBR - http://greco.ppgi.ufrj.br/gtlinkedbr

18

Virtuoso - http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/

95

A ontologia para descrever a base de hidrantes é apresentada na Figura 16 que também mostra os relacionamentos com conceitos de vocabulários existentes na nuvem LOD. Para descobrir conceitos relacionados, foram realizadas pesquisas nas páginas do Linked Open Vocabularies (LOV)19 que reúne descrições e referências para diversos vocabulários e ontologias utilizados na nuvem LOD, do LinkedGeoData20 e DBPedia. Como resultado resolveu-se utilizar as classes: foaf:Organization do vocabulário FOAF (uma organização qualquer); geo:SpatialThing e suas propriedades geo:lat e geo:long do vocabulário “WGS84 Geopositioning”21 (objetos geolocalizados com latitude e longitude conforme o WGS84); lgdo:FireHydrant, lgdo:FireStation, lgdo:City e lgdo:Locality da Linked Geo Data Ontology; e yago:Neighbourhoods_inRio_(city) da DBPedia (bairros do município do Rio de Janeiro). O conceito central é hid:HidranteDeColuna que é uma especialização de geo:SpatialThing e de lgdo:FireHydrant (um hidrante qualquer). Ao conceito central, são relacionadas as propriedades (data properties) hid:vazão, hid:dataDoCadastro, hid:endereço que representam, respectivamente, a vazão em litros por minuto, a data que o hidrante foi cadastrado no sistema e um endereço textual. O hidrante também é relacionado ao bairro (hid:Bairro) e à cidade (hid:Cidade) em que se localiza, ao batalhão (hid:OBM equivalente a lgdo:FireStation) responsável pela manutenção e atualização de seus dados e, principalmente, à sua situação operacional que permite identificar quais hidrantes podem ser utilizados em determinado momento. Esta ontologia foi construída obedecendo ao padrão OWL 2 DL.

19

Linked Open Vocabularies (LOV) - http://labs.mondeca.com/dataset/lov/index.html

20

LinkedGeoData.org: Adding a spatial dimension to the Web of Data - http://linkedgeodata.org

21

Basic Geo (WGS84 lat/long) Vocabulary - http://www.w3.org/2003/01/geo/

96

lgdo:FireHydrant

foaf:Organization

xsd:float

hid: obmResponsavel hid:OBM

hid:vazao

hid:HidranteDeColuna

hid:dataDoCadastro

owl:equivalentClass

hid:endereco

lgdo:FireStation

xsd:dateTime

xsd:string

hid:situacaoOperacional

lgdo:Locality

hid:Bairro

geo:lat, geo:long

geo:SpatialThing

hid:SituacaoOperacional hid:bairro

owl:equivalentClass

yago: Neighbourhoods InRio_(city)

hid:cidade

hid:Cidade

owl: equivalentClass lgdo:City

hid:OPERANTE hid:PRECARIO hid:INOPERANTE

Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD

Além da base de hidrantes, foi utilizada a base LinkedGeoData.org (LGD), que disponibiliza dados georreferenciados na nuvem LOD (ruas, bairros, cidades, estados) existentes na base OpenStreetMap22, um serviço para criação de mapas colaborativo. Desta base foram extraídas todas as triplas da classe lgdo:Amenity existentes na cidade do Rio de Janeiro. Após consulta em sua ontologia, verificou-se que esta classe agrega subclasses de localidades geográficas do tipo: Aeroporto, Shopping Center, Hotel, Comércios, Escolas, Hospitais, etc. Estas entidades serão disponibilizadas para consulta na aplicação do caso de exemplo deste trabalho. 4.1.2 Camada de inferência para integração das bases Nesta seção será mostrada a configuração do módulo para integrar as duas bases RDF apresentadas na seção anterior. Da base de hidrantes foram extraídas informações relacionadas aos hidrantes através da consulta SPARQL DESCRIBE apresentada a seguir e identificada por Qhid: 1 2 3

DESCRIBE ?s ?s1 FROM WHERE { ?s a hid:HidranteDeColuna ; ?p ?s1 . }

Esta consulta descreve todas as triplas de hid:HidranteDeColuna, hid:Cidade, hid:Bairro e hid:OBM e é atualizada (executada novamente) em intervalos de uma hora.

22

OpenStreetMap - http://www.openstreetmap.org/

97

Da base LGD obtém-se todas as instâncias de lgdo:Amenity, suas coordenadas geográficas (geo:lat e geo:long) e seu rótulo (rdfs:label). Para reduzir a quantidade de resultados utilizou-se um filtro de coordenadas, ou seja, escolheu-se um retângulo imaginário na superfície da Terra que englobasse uma grande região do município do Rio de Janeiro. Como, o endpoint da LGD limita a quantidade de resultados, foi utilizado o binder OffsetSplitterQueryParameterBinder (veja seções 3.3.2 e 3.3.3) utilizando as consultas Qcontagem (contagem total de resultados) e Qamenity a seguir: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

# Qcontagem: contagem do total de resultados SELECT (count(?uri) as ?c) FROM WHERE { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . # Delimita um retângulo na superfície FILTER (?lat < -22.898474 && ?lat > -22.959342 && ?lng > -43.272572 && ?lng < -43.142624 && ?C != lgdo:Amenity && ?C != lgdo:Node) } # Qamenity: executada várias vezes alterando apenas valor do ?offset CONSTRUCT { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . } FROM WHERE { ?uri a lgdo:Amenity ; geo:lat ?lat ; geo:long ?lng ; rdfs:label ?nome ; a ?C . # Delimita um retângulo na superfície FILTER (?lat < -22.898474 && ?lat > -22.959342 && ?lng > -43.272572 && ?lng < -43.142624 && ?C != lgdo:Amenity && ?C != lgdo:Node) } ORDER BY ?uri OFFSET ?offset LIMIT ?limit

98

A realização de inferência sobre estes dados reunidos usando a ontologia criada permitiu relacionar as instâncias hid:HidranteDeColuna com a classe lgdo:FireHydrant, e de forma semelhante hid:OBM com foaf:Organization e lgdo:FireStation. As partes mais relevantes do arquivo XML de configuração são apresentadas a seguir: 1 2 3 4

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

Rio Maps ... http://derived.viconsaga.com.br/cbmerj/pgorh/resource/ ... Carrega hidrantes e seus recursos ... Qhid 60*60*1000 Carrega lgdo:Amenity de LGD http://linkedgeodata.org/sparql Qamenity 60*60*1000 Contagem de lgdo:Amenity 100 http://linkedgeodata.org/sparql Qcontagem PELLET hidracol.owl.xml /ds/ 32000

99

42 43

Para viabilizar consultas por parte da aplicação, duas funções foram construídas e adicionadas ao módulo por meio de plug-ins: maxMatch(texto1, texto2) – retorna o grau de similaridade, entre 0 e 1, entre os textos identificados por texto1 e texto2. Os parâmetros de entrada podem ser textos constantes entre aspas ou variáveis contendo um texto. distanceFromDegrees(lat1, lon1, lat2, lon2) – retorna a distância, em metros, entre dois pontos geográficos. Os parâmetros de entrada podem ser números constantes fornecidos diretamente ou passados por variáveis. A primeira função permite comparar nomes digitados pelo usuário da aplicação com os nomes das entidades geográficas existentes na base integrada, a fim de encontrar aquelas que o usuário está provavelmente se referindo. Já a segunda função é usada para retornar a distância entre uma entidade geográfica e cada hidrante de coluna, permitindo descobrir hidrantes próximos a ela. A próxima seção mostrará consultas utilizadas pela aplicação que aplicam estas funções. 4.1.3 Aplicação de consumo e considerações Com o término de todo processo descrito, os dados de hidrantes de coluna do sistema ViconWeb foram triplificados, integrados com dados da LinkedGeoData e disponibilizados em um endpoint provido pelo módulo de inferência. Para fins de demonstração, uma interface de consulta Web foi elaborada pelo mesmo aluno Tiago Marino de forma a receber como entrada uma localidade geográfica da cidade do Rio de Janeiro (existente na classe lgdo:Amenity da base LGD) e o raio de busca. A aplicação recebe os parâmetros de entrada do usuário, cria consultas SPARQL considerando estes parâmetros, as envia para o endpoint e recebe os resultados em formato JSON. Por exemplo, para consultar “Todos os hidrantes de coluna operantes no raio de 500 metros do comércio Casas Pedro”, duas consultas (e consequentemente duas requisições) são enviadas ao endpoint. A primeira delas visa buscar o URI que representa a Casas Pedro: 1 2 3 4 5

SELECT ?x ?l ?r WHERE { { SELECT DISTINCT ?x ?l (sfn:maxMatch(?l, "Casas Pedro") AS ?r) WHERE { ?x a lgdo:Amenity ; rdfs:label ?l

100

6 7 8 9

} ORDER BY DESC(?r) } FILTER (?r > 0)

10 }

O URI encontrado é 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 8 geo:lat ?lat ; 9 geo:long ?lon . 10 ?hyd a lgdo:FireHydrant ; 11 geo:lat ?hlat ; 12 geo:long ?hlon ; 13 hid:endereco ?endereco ; 14 hid:situacaoOperacional ?sit ; 15 hid:vazao ?vazao . 16 FILTER (?sit = hidres:OPERANTE) 17 } 18 ORDER BY ?dist 19 } 20 FILTER (?dist < 500) 21 }

Como retorno, a aplicação apresenta um mapa do Google Maps, centrado na localidade buscada, traça um círculo com o raio definido pelo usuário na entrada, e todos os hidrantes de coluna com situação operacional igual a “OPERANTE” (podem existir hidrantes em más condições) dentro do raio de busca (Figura 17).

101

Figura 17. Lista de Resultados na aplicação protótipo desenvolvida.

Algumas considerações devem ser feitas a respeito deste cenário. Primeiramente, buscou-se apresentar os procedimentos básicos que envolvem o processo de extração, transformação, publicação e integração a partir de dados armazenados nos formatos tradicionais para o padrão RDF, tornando-os disponíveis em um padrão legível por máquinas na Web e com semântica definida por uma ontologia. O ganho de se utilizar este padrão é seu caráter interoperável, que possibilita a integração entre bases provenientes de distintas fontes, como demonstrado na consulta apresentada. Outra observação importante é que os atributos descritores do objeto “Hidrante de coluna”, utilizados como base para a montagem e pesquisa dos vocabulários, foram elaborados pelos próprios membros do Corpo de Bombeiros, sendo estas pessoas as mais indicadas para modelar um objeto desta natureza por lidarem diretamente com este tipo de entidade. Quanto aos dados do LGD, verificou-se que a quantidade de entidades geográficas da cidade era pequena, o que mostra que ainda há um grande caminho a se percorrer até que existam bases realmente completas. Contudo, acredita-se que num futuro próximo, com a crescente demanda e adesão pela publicação de dados abertos no padrão LOD, os dados disponibilizados para a resposta a situações de emergência, saúde, trânsito, segurança pública serão mais confiáveis e atualizados, transformados em informação para apoio à decisão.

102

4.2

Cenário 2: alertas sobre chuvas e escorregamento de terra Este cenário foi inspirado pelas tragédias que ocorreram no Estado do Rio de Janeiro

entre 2010 e 2012, principalmente na região serrana e nos municípios de Niterói e Rio de Janeiro. Diversos óbitos ocorreram devido a enchentes e soterramentos, estes ocorridos após o deslizamento de terras em encostas ocupadas irregularmente por casas em comunidades carentes. Após os fatos ocorridos, o então prefeito do município do Rio de Janeiro, Eduardo Paes, ordenou a implantação de sirenes para alertar a população de diversas localidades sobre possíveis riscos de deslizamentos.23 Esta iniciativa incorre em gastos de recursos com implantação e manutenção que poderiam ser redirecionados para outras necessidades como treinamento da população e de pessoal caso infraestruturas já existentes fossem aproveitadas. Assim, o objetivo deste cenário é utilizar o framework apresentado neste trabalho para mostrar uma possível abordagem para notificação de usuários sobre a condição e possíveis riscos existentes no local em que ele se encontra. Geralmente estes locais são encostas de morros ou áreas carentes. Celulares convencionais poderiam ser utilizados para enviar mensagens de texto a números previamente cadastrados, contudo Smatphones oferecem serviços mais sofisticados como localização corrente e acesso à Internet sem fio. Apesar de parecer absurdo que usuários das classes C e D tenham acesso a dispositivos móveis de alta tecnologia, pesquisas de mercados mostram que tais pessoas desejam adquiri-los e não se importam em pagar inúmeras prestações.24 Desta forma, Smartphones ultrapassam a barreira de meros dispositivos de entretenimento e status social, para serem também de utilidade pública. Limitou-se a utilizar a localização corrente do usuário, mas outras localizações, fornecidas manualmente ou capturadas de dados históricos, poderiam ser utilizadas em um cenário mais realista. Um objetivo técnico adicional deste cenário foi verificar a capacidade de se usar comparações, iterações e cálculos matemáticos simples como agregações (redução dos valores de uma lista a um único valor, como por exemplo, soma e média). Nas próximas seções apresentar-se-á o domínio do cenário descrito, sua modelagem e implementação usando o framework proposto nesta dissertação.

23

Mais informações em http://oglobo.globo.com/rio/paes-afirma-que-todas-as-comunidades-mapeadas-pelageorio-receberao-sirenes-de-alerta-ate-fim-do-ano-2791735 e http://oglobo.globo.com/rio/mais-35-favelasdo-rio-terao-sirene-de-alerta-de-chuva-3730766 24

http://www.omelhordomarketing.com.br/desejos-dos-consumidores-classe-cd/

103

4.2.1 Domínio da aplicação e modelagem Neste cenário utilizaram-se medidas pluviométricas provenientes do Alerta-Rio25, um sistema de alerta mantido pela prefeitura da cidade do Rio de Janeiro através da Fundação Geo-Rio desde 1997. A Fundação Instituto de Geotécnica (Geo-Rio) é um órgão da Secretaria Municipal de Obras da Prefeitura do Rio de Janeiro responsável por avaliar e mapear as encostas da Cidade do Rio de Janeiro.26 O sistema é composto por 33 estações pluviométricas distribuídas sobre a área geográfica da cidade. A concentração das estações varia estrategicamente (AZEVEDO, 2011) e sua distribuição atual pode ser vista na Figura 18, extraída da página Web do sistema Alerta-Rio. A medição pluviométrica é feita em milímetros com resolução de 0,2 mm e medida a cada 15 minutos, sendo os dados de cada estação transmitidos a uma estação central via rádio (SILVA, 2008). A intensidade, frequência e duração das chuvas contribuem, juntamente com a instabilidade do solo e a gravidade, para a movimentação de massas de terra e rochas ao longo de uma encosta (AZEVEDO, 2011; SILVA, 2008). Tais movimentos são denominados movimentos de massa e, apesar de a literatura apresentar diversas classificações para tais movimentos este trabalho apresentará apenas a definição do termo escorregamento, utilizado pelo Alerta Rio. Assim, escorregamentos são “movimentos rápidos, de duração relativamente curta, de massas de solo ou rocha geralmente bem definidas quanto ao seu volume” (SILVA, 2008) ou “deslocamento rápido de (...) massa de rocha, solo residual ou sedimentos existentes em uma encosta, possuindo um centro de gravidade que se desenvolve seguindo para frente e para baixo” (AZEVEDO, 2011).

25

Sistema Alerta Rio - http://obras.rio.rj.gov.br/alertario.htm

26

Fundação Instituto de Geotécnica (Geo-Rio) - http://portalgeo.rio.rj.gov.br

104

Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012)

27

Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008)

Classificação

Intensidade pluviométrica (mm/h)

da chuva

Chuvisco

Chuva

Leve

0,5

25,1 a 50

Muito Forte

---

> 50,0

A partir das medições pluviométricas é possível definir a intensidade da chuva em cada estação conforme apresentado no Quadro 8. No entanto, a intensidade da chuva em mm/h apenas não é suficiente para detectar a probabilidade de escorregamento, sendo necessário considerar o histórico de chuvas. Assim, a quantidade de água acumulada durante 96 horas seguidas de chuva leve de 2,0 mm/h em média representa uma probabilidade muito alta de haver algum deslizamento. O Quadro 9 mostra os níveis de alerta (ou probabilidade) de escorregamento de terra definidos pelo sistema Alerta-Rio (AZEVEDO, 2011). 27

Coluna sobre chuviscos retirada de http://www.bibliotecapolicial.com.br/upload/documentos/ESTUDO-

PLUVIOMETRICO-E-REDUCAO-DE-DESASTRES-21069_2011_5_12_8_42.pdf, que usou uma revista sobre o GEORIO como fonte mas esta não foi encontrada.

105

Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011)

Quantidade de chuva acumulada por tempo Nível de alerta 1 hora

24 horas

96 horas

Moderado

10-30 mm

50-100 mm

100-175 mm

Alto

30-50 mm

100-175 mm

175-250 mm

Muito Alto

> 50 mm

> 175 mm

> 250 mm

A partir das medidas provenientes das estações pluviométricas pretende-se calcular a suposta quantidade de chuva incidindo sobre a localização do usuário. Para isto, será usada uma interpolação baseada no método de inverso do quadrado da distância usando as três estações mais próximas. Isto é equivalente à média ponderada pelo inverso do quadrado das distâncias entre as estações e o usuário. Assim, a suposta quantidade de chuva acumulada num ponto geográfico P=(x,y), onde o usuário se localiza, será dada pela seguinte fórmula:

v (t ) ( P)

1 (t ) 1 (t ) 1 (t ) v v v 2 1 2 2 2 3 d1 d2 d3 1 1 1 2 2 2 d1 d2 d3

Equação I. Cálculo da quantidade de chuva acumulada num ponto.

Onde di determina a distância em linha reta, na Terra, entre P e a localização da iésima estação mais próxima de P, vi(t) representa a soma das t últimas medições da i-ésima estação. Desta forma, t é igual a 4 para a última hora, 96 para as últimas 24 horas e 384 para as últimas 96 horas. Uma vez calculados tais valores, utiliza-se o Quadro 9 para descobrir a probabilidade de escorregamento no ponto P. No caso de haver diferentes resultados para cada valor de t será utilizado o pior nível de alerta. A intensidade de chuva (Quadro 8) será sempre calculada com base no v(1) e no v(4), ou seja, 15 minutos (última medição) e uma hora (quatro últimas medições) respectivamente. Para o último caso, serão usados os dados do quadro (mm/h) e, para o primeiro caso, estes valores serão divididos por 4 para se obter em mm/15min. Como a divisão de medidas de chuvisco por 4 resulta em valores menores que 0,28 e a resolução dos hidrômetros é de 0,2 mm, apenas a coluna do Quadro 8 com intensidades de chuva serão utilizadas para classificação de 15 minutos. Portanto 0,2 mm/15min será considerado como sem chuva e 0,4 mm/15min como chuva leve (0,4 × 4 =

106

1,6 mm/h). O Quadro 10 apresenta estes valores utilizados. Novamente, em caso de divergências entre mm/h e mm/15min a classificação de maior intensidade será utilizada. A metodologia de geração dos valores do ponto P será descrita na próxima seção. Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos

Classificação da chuva

Intensidade pluviométrica (mm/15min)

Ausente

< 0,28

Leve

0,28 a 1,25

Moderada

1,25 a 6,25

Forte

6,25 a 12,5

Muito Forte

> 12,5

4.2.2 Camada de dados e sensoriamento Para este cenário, três SPARQL endpoints simulados foram criados. O primeiro deles, denominado Rain Stations Endpoint (RSE), provê dados históricos de medidas do Alerta-Rio. O segundo, denominado User Locations Endpoint (ULE) simula movimentação de usuários na cidade. Ambos podem ser classificados como sensores físicos, pois provêm dados capturados do ambiente (pluviômetro e GPS). O terceiro, chamado Neighborhood Endpoint (NBE), é um endpoint adicional apenas para permitir descobrir se um ponto pertence a um polígono (um interpretador de contexto) usado para fornecer contexto a nível de bairro. Modelagem e implementação deles serão descritas nas próximas subseções e apêndices referenciados conforme necessário. 4.2.2.1 Rain Stations Endpoint (RSE) Para sua construção foi necessário obter previamente os dados históricos de chuva. O Alerta-Rio os disponibiliza para download no site, contudo, é necessário selecionar o ano a que as medições se referem para cada estação. Para automatizar este processo um script Python que constrói as URLs e baixa os arquivos foi construído. Estes dados obtidos foram inseridos em um banco de dados MySQL e mapeados para RDF utilizando o software D2RQ28 que faz mapeamento em tempo real, pois quando recebe uma consulta SPARQL gera uma consulta SQL e retorna o resultado conforme o protocolo SPARQL. 28

D2RQ Platform: Accessing Relational Databases as Virtual RDF Graphs - http://d2rq.org/

107

O diagrama de entidade-relacionamento para estes dados é composto pelas tabelas measure e station conforme apresentado à direita da Figura 19. A tabela station possui atributos para identificar a estação (chave primária), nome da estação, sua latitude e longitude, e datas de início e final de operação (uma estação ativa precisa ter data final posterior à data atual). A tabela measure possui atributos para identificar a medida (chave primária), identificar a estação medidora (chave estrangeira), além de data e valor da medição. O vocabulário RDF (à esquerda da Figura 19) é semelhante, contendo as classes Station e Measure e os datatype properties stationName, latitude, longitude, beginDate e endDate para Station e measureValue e measureDate para Measure. Por fim, cada medição é ligada à estação medidora por meio da object property station. Por ser bastante simples e também ser usado apenas no endpoint, não foi criado um vocabulário RDF Schema, sendo tudo isso apresentado diretamente nas instâncias pelo mapeamento. Isto será importante para demonstrar um endpoint sem ontologia ou vocabulário explícitos sendo mapeado para os elementos (classes e propriedades) da ontologia de domínio que será apresentada posteriormente. xsd:decimal

xsd:dateTime

a:measureValue a:measureDate

a:beginDate a:endDate

xsd:decimal

a:Measure a:station

id (PK) : INT station_id (FK) : INT date : DATETIME value : DOUBLE

a:Station

a:latitude a:longitude

xsd:decimal xsd:string

measure

a:stationName

station id (PK) : INT name : VARCHAR(40) latitude : DOUBLE longitude : DOUBLE begin_date : DATETIME end_date : DATETIME

Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o mapeamento entre conceitos.

O mapeamento usando D2R entre banco de dados e vocabulário é apresentado no Apêndice A. O URI de cada recurso segue o padrão , onde CLASSE é Station ou Measure e ID é o respectivo valor da coluna id do recurso. Como a tabela measure possui mais de 15 milhões de registros e consultas equivocadas como “recupere todas a medidas” demorariam muito tempo para serem

108

respondidas foi criada uma visão atualizada a cada 5 segundos que engloba apenas as últimas 96 horas de medição. 4.2.2.2 User Locations Endpoint (ULE) Este endpoint simula a obtenção das coordenadas de usuário por meio de um GPS. Foram criadas duas maneiras de se gerar tais coordenadas. A primeira, usada para testes iniciais, utiliza dois cenários de movimentação de usuários (um usuário por cenário) cujas rotas foram geradas no Google Maps e exportadas para KML (Keyhole Markup Language) manualmente. A segunda, usada para simular mais de dois usuários, é feita aleatoriamente através de um gerador de coordenadas e rotas automático. Para ambas as informações são armazendas em um banco de dados MySQL e o software D2R efetua o mapeamento como no endpoint anterior. A figura apresenta o diagrama do banco de dados, o vocabulário RDF e o mapeamento entre tabelas e classes. A separação entre o usuário e sua localização foi feita porque a tabela location fica em memória para ter uma atualização mais rápida. O URI dos recursos também segue o padrão . Para detalhes sobre a estrutura do KML exportado pelo Google Maps e os algoritmos de geração das coordenadas consulte o Apêndice B. xsd:string

usr:nome

usr:Usuario

usr:localizacao

user id (PK) : INT nome : VARCHAR(60)

usr:Ponto xsd:decimal

usr:latitude usr:longitude

xsd:decimal xsd:dateTime

usr:atualizacao

location id (PK) : INT latitude : DOUBLE longitude : DOUBLE instant : DATETIME user_id : INT

Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o mapeamento entre conceitos

4.2.2.3 Neighborhood Endpoint (NBE) Este endpoint é o mais simples e foi adicionado apenas para mostrar a possibilidade de obter contextos adicionais. Ele utiliza um módulo de inferência que armazena URIs e nomes de bairros em RDF e contém uma função nb_contains adicionada por meio de plugin. Esta função detecta se um ponto está dentro do polígono do bairro (identificado por seu URI) ou

109 não.29 As bordas dos polígonos dos bairros foram obtidas do Portal Geo da Prefeitura do Rio de Janeiro30 e são carregadas de um arquivo KML e armazenados internamente, i.e, não disponíveis em RDF. O uso da função (em negrito) é apresentado a seguir, onde também se pode observar o pequeno vocabulário criado (conceitos mapa:Bairro e propriedade rdfs:label): 1 2 3 4 5 6

PREFIX mapa: http://mapa.rio.rj.gov.br:25070/ontology# DESCRIBE ?b WHERE { ?b a mapa:Bairro . # rdfs:label contém o nome do bairro FILTER(geo:nb_contains(?b, -43.258041, -22.995279)) }

4.2.3 Camada de inferência Nesta seção apresentar-se-á o algoritmo, a ontologia e a disposição dos módulos de inferência necessários para atingir o objetivo de emissão dos alertas apresentados na seção 4.2.1. Uma vez que os endpoints simulados apresentados na seção anterior foram colocados à disposição, o ambiente necessário está pronto para ser usado. Na sequência serão apresentados (1) o algoritmo de cálculo dos níveis de alerta na posição do usuário, e (2) a organização dos módulos de inferência e a ontologia utilizada. A configuração detalhada da rede de módulos será apresentada no Apêndice C. 4.2.3.1 Algoritmo para cálculo de níveis de alerta Antes de apresentar o algoritmo, cabe relembrar o método, primeiramente precisa-se obter a posição dos usuários, e a seguir, para cada um deles calcular a suposta quantidade de chuva (Equação I) nos últimos 15 minutos, 1 hora, 24 horas e 96 horas (períodos), e classificá-las conforme os níveis de alerta dos quadros 8, 9 e 10. O algoritmo a seguir apresenta como isto seria feito utilizando um único programa: 1 2 3 4 5 6 7

users = SELECT ?uid ?location WHERE { ?uid a User ; location ?location } FOR u IN users DO l = u.location d = SELECT ?sid (geo:distance(?slat, ?slon,

29

O algoritmo utilizado pode ser encontrado em http://alienryderflex.com/polygon

30

Portal Geo - http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm

110

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

l.lat, l.lon) as ?dist) WHERE { ?sid a Station ; location [ latitude ?slat ; longitude ?slon ] } ORDER BY ?dist LIMIT 3 dtot = 0 FOR e IN d DO dtot = dtot + 1 / e.dist ^ 2 avg15 = avg60 = avg24 = avg96 = 0 FOR e IN d DO w = ((1 / e.dist ^ 2) / dtot) avg15 += w * acc_rain(e.sid, 15min) avg60 += w * acc_rain(e.sid, 60min) avg24 += w * acc_rain(e.sid, 24h) avg96 += w * acc_rain(e.sid, 96h) slv60 = map(avg60, [10 : Attention, 30 : Moderate, 50 : High], VeryHigh) slv24 = map(avg24, [50 : Attention, 100 : Moderate, 175 : High], VeryHigh) slv96 = map(avg96, [100 : Attention, 175 : Moderate, 250 : High], VeryHigh) u.slipLevel = max(slv60, slv24, slv96) rlv15 = map(avg15, [0.28 : HeavyDrizzle, 1.25 : LightRain, 6.25 : ModerateRain, 12.5 : HeavyRain], VeryHeavyRain) rlv60 = map(avg60, [0.00 : Dry, 0.25 : LightDrizzle, 0.50 : ModerateDrizzle, 1.10 : HeavyDrizzle, 5.00 : LightRain, 25.0 : ModerateRain, 50.0 : HeavyRain], VeryHeavyRain) u.rainLevel = max(rlv15, rlv60)

111

57 FUNCTION acc_rain(sid, range) 58 RETURN SELECT (SUM(?v) AS ?acc) 59 WHERE { 60 ?m station sid ; 61 measureValue ?v ; 62 measureDate ?t . 63 FILTER (?t >= TIMEDIFF(NOW, range) 64 && ?t station) map:measure_station a d2rq:PropertyBridge; d2rq:belongsToClassMap map:measure; d2rq:property a:station; d2rq:refersToClassMap map:station; d2rq:join "measure_view.station_id => station.id" .

Na configuração do servidor pode-se definir a porta de escuta do servidor (no caso 2020) e o URI base a ser utilizado ao construir o URI das instâncias (registro) das classes (tabelas). Para a conexão configura-se driver, endereço de acesso ao banco de dados, login e senha. Os mapeamentos podem ser de dois tipos: d2rq:ClassMap e d2rq:PropertyBridge. O primeiro mapeia uma tabela com um conceito, neste caso, station com a:Station (linhas 1519) e measure com a:Measure (linhas 33-37). O segundo mapeia atributos das tabelas com propriedades (p.ex. station.latitude com a:latitude, apresentado nas linhas 26-31). O URI de cada instância das classes é definido pela propriedade d2rq:uriPattern, que permite a definição do padrão de formação, usando atributos da tabela do banco, a ser adicionado ao URI base. Na linha 19 é apresentado um uso desta propriedade. Neste caso, a estação 15 seria identificada por . Adicionalmente, o tipo de dados diferentes de xsd:string para as propriedades podem ser

definido

conforme apresentado

na

linha 30.

Por

fim,

para não

estender

desnecessariamente, vale destacar as linhas 41 a 46 que apresentam o mapeamento de uma object property relacionando uma medição com a estação que a mediu. Observe a propriedade d2rq:join que permite relacionar os atributos station_id e id das tabelas measure_view e station. Por falar nisso, measure_view não é uma tabela, mas sim uma visão da tabela measure que seleciona apenas uma janela com as medidas mais recentes e é atualiza a cada 5 segundos por um programa Java que é executado paralelamente ao D2R. A janela adotada foi de quatro dias para englobar a necessidade de se ter 96 horas de medição, equivalente a quatro dias. Isto foi feito apenas por questões de desempenho, evitando que consultas equivocadas, do tipo “recupere todas a medidas”, demorassem muito tempo para serem respondidas. E isto realmente demoraria bastante em função de a tabela measure conter mais de 15 milhões de registros, uma vez que os dados históricos compreendem os anos de 1997 a 2011.

167

Apêndice B – Cenário 2: implementação da geração de coordenadas e mapeamento D2R para User Locations Endpoint (ULE) Conforme apresentado na seção 4.2.2.2, este endpoint simula a obtenção das coordenadas de usuário de um GPS produzidas de duas maneiras: arquivos KML gerados pelo Google Maps (dois cenários) e gerador automático de coordenadas e rotas. As informações são armazenadas em um banco de dados MySQL e o software D2R efetua o mapeamento. Adiante o diagrama do banco de dados, o vocabulário RDF e o mapeamento entre eles serão sucintamente apresentados. Em seguida a estrutura do KML exportado pelo Google Maps e os algoritmos de geração das coordenadas serão discutidos com mais detalhes. O diagrama entidade-relacionamento é composto apenas pelas tabelas user e location (Figura 20 na página 108). A primeira possui um atributo identificador e o nome do usuário e, a segunda, contém um atributo identificador, as coordenadas geográficas e o horário de atualização. As tabelas possuem uma relação 1:1 porque a primeira é armazenada em disco contendo 150.000 usuários com nomes gerados automaticamente e, a segunda, é armazenada em memória contendo os dados de localização que são sempre gerados dinamicamente e descartadas após a execução. A Figura 20 apresenta ainda o vocabulário RDF, com os conceitos usr:Usuario e usr:Ponto, e o mapeamento através de uma linha tracejada. O arquivo de mapeamento é similar ao apresentado no Apêndice A e será omitido. Vale ressaltar, contudo,

que

o

URI

das

instâncias

é

gerado

pela

concatenação

de

http://users.com.br:2026/resource/ com o nome do conceito e seu identificador na tabela. A construção dos dois cenários de movimentação de usuário começam por uma pequena história da atividade do usuário, apresentados textualmente a seguir: Cenário 1: “João de Deus mora na Cidade de Deus e trabalha como segurança em uma casa noturna na Lapa de terça a sábado. Ele sai de casa às 18h30 para chegar no trabalho por volta de 20h. Às 5h ele deixa o serviço e retorna para casa, chegando aproximadamente às 6h. Tanto na ida quanto na volta ele pode pegar dois caminhos dependendo do ônibus que passar primeiro: via Linha Amarela ou via Zona Sul. Contudo, 75% da vezes ele vai pela Linha Amarela”. Cenário 2: “Dona Maria mora na Rocinha e trabalha numa casa no Leblon de segunda a sexta das 7h às 13h. Ao sair, ela vai diretamente para o Andaraí às segundas e quartas onde ela faz curso de culinária das 14h30 às 15h30. Ela então vai para o Centro onde estuda Administração até 22h, quando então retorna para casa”.

168

A partir disto, foram geradas rotas usando o Google Maps. O processo foi realizado manualmente na página do serviço, ou seja, marcou-se o ponto inicial e final e exportou-se a rota para o formato KML. Assim, por exemplo, o trecho do cenário descrito por “Dona Maria mora na Rocinha e trabalha (...) no Leblon (...). Ao sair, ela vai diretamente para o Andaraí (...)” é convertido em duas rotas, uma Rocinha-Leblon e outra Leblon-Andaraí. Para descrever os dias e horários destas rotas foi feita uma extensão na estrutura base do KML. O formato KML33 é um arquivo XML, descrito basicamente pelos elementos kml, Placemark, ExtendedData e alguns outros que representam entidades geométricas. Um exemplo é apresentado a seguir: 1 2 3 Absolute Extruded 4 Transparent green wall... 5 6 7 -112.2550785337791,36.07954952145647,2357 8 -112.2549277039738,36.08117083492122,2357 9 ... 10 11 12 13

O element kml é o elemento raiz que pode ter um ou mais elementos Placemark (linha 2), usados para marcar uma posição na superfície da Terra. Tais marcadores podem conter um atributo identificador e os elementos name, description e uma geometria. A geometria é um nome genérico concretizado pelos elementos Point (ponto geográfico), LineString (segmentos de reta conectados), LinearRing (caminho fechado), Polygon (polígono que pode conter buracos) e alguns outros. Os três primeiros possuem, obrigatoriamente, um elemento coordinates que contém uma (para pontos) ou mais (para os demais) tuplas de dois ou três valores (latitude, longitude e, opcionalmente, altitude). As linhas 5 a 11 mostram a estrutura para um LineString. No caso de polígonos, há um elemento outerBoundaryIs contendo a borda externa do polígono e zero ou mais elementos innerBoundaryIs contendo os buracos. Ambos são definidos por um LinearRing. Adicionalmente, podem-se definir estilos para os marcadores e/ou organizá-los em diretórios (Folder) e documentos (Document).

33

Conteúdo para a explicação extraído de https://developers.google.com/kml/documentation/kmlreference

169

O elemento ExtendData permite adicionar dados personalizados a um recurso (Placemark, Folder ou Document). Assim, criou-se uma estrutura própria para definir um cenário com agendas e caminhos. Esta estrutura é apresentada a seguir: 1 2 3 Joao de Deus 4 5 6 18:30:00+00:00 7 8 TUESDAY 9 WEDNESDAY 10 ... 11 12 13 14 0.7500 15 40.0 16 FORWARD 17 18 19 0.2500 20 ... 21 22 23 ... 24 25

Note que é necessário definir um namespace (linha 1) no element ExtendedData e a seguir pode-se utilizar os elementos a:scenario, a:username, a:schedule e seus subelementos. O elemento a:scenario (linha 2) permite definir a agenda para o cenário, que é composta por sinais de ativação (a:trigger – linhas 5-12) e caminhos (a:path – linhas 13-22). Os sinais necessitam de um horário inicial e os dias da semana em que podem ser ativados (linhas 611). Os caminhos referenciam um Placemark (atributo ref – linhas 13 e 18) e possuem uma probabilidade de escolha (linhas 14 e 19), uma velocidade (linha 15) e uma direção (linha 16). Utiliza-se esta distribuição massa de probabilidade para, dado que um sinal de ativação foi disparado, determinar qual rota será escolhida. A velocidade determina, em km/h, qual seria a velocidade de deslocamento na execução de um caminho e, a direção define se o caminho será executado na ordem direta ou inversa dos pontos (elemento coordinates).

170

O carregamento de arquivos KML é feito em Java utilizando a biblioteca JAK (Java API for KML)34 para carregar os elementos do padrão KML e a biblioteca do padrão JAXB (Java Architecture for XML Binding)35 instalada juntamente com a plataforma Java para carregar o conteúdo XML do elemento ExtendedData. Ambos são capazes de transformar KML e XML em objetos Java (POJOs), sendo que a segunda utiliza Java annotations definidas pelo padrão JAXB. O diagrama de classes básico utilizado pela JAK é apresentado na Figura 38 (esquerda) e é de fácil entendimento visto que reflete a discussão dos parágrafos anteriores, sendo importante destacar apenas que AbstractObject é aquilo que possui um identificador. Para os dados personalizados, o conteúdo do elemento ExtendedData é convertido nos objetos Java apresentados também na Figura 38 (direita). Por fim, a classe Path é associada a um animador de caminho (uma instância da interface PathAnimator) que é capaz de interpretar as coordenadas do caminho estático (StaticPath) conforme a velocidade e a direção definidas e gerar pontos simulando o deslocamento no caminho. PathAnimator e StaticPath serão detalhadas posteriormente. Kml

AbstractObject UserScenario

1

+ username : String

1

Feature *

Geometry *

Container

Placemark

Point

1

*

LineString Folder LinearRing Document

Polygon MultiGeometry

*

* Schedule

Coordinate

Boundary

*

1 Trigger

Path

+ time: Calendar + weekly : List

+ pathId : String + probability : double + velocity : double + way : Way

Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita)

Além da geração de coordenadas usando o arquivo KML, foi também desenvolvido um método para gerar os pontos inicial e final de caminhos cujo traçado foi obtido do serviço Google Directions36. Este serviço é gratuito para uso não comercial, mas apesar de sua forma gratuita ter algumas limitações estas não atrapalharam o desenvolvimento. É um serviço Web que, resumidamente, recebe dois pontos (inicial e final) e retorna um arquivo JSON com os pontos da rota. De forma semelhante à conversão feita de XML para objetos Java, foi feita conversão de JSON para objetos Java usando anotações JAXB, contudo usando uma 34

Disponível em http://code.google.com/p/javaapiforkml/

35

Mais informações em http://www.oracle.com/technetwork/articles/javase/index-140168.html

36

Documentação disponível em https://developers.google.com/maps/documentation/directions/

171 biblioteca externa chamada Jersey37. Ao obter o arquivo JSON e construir os objetos Java, cria-se um caminho estático e um animador de caminho (StaticPath e PathAnimator). Quanto à geração dos pontos inicial e final de cada caminho é utilizada a densidade populacional das regiões administrativas (RAs) do município do Rio de Janeiro. Estes dados foram obtidos da tabela nº 2972 disponível na seção “Estatísticas > População” do Armazém de Dados de Prefeitura do Rio de Janeiro 38. A quantidade de habitantes residentes em cada RA foi colocada numa planilha do Excel e gerou-se sua distribuição acumulada conforme parcialmente apresentado no Quadro 15. Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em RAs (2010)

Regiões Administrativas Jacarepaguá Campo Grande Bangu Méier Madureira Santa Cruz Barra da Tijuca Realengo ... Cidade de Deus Paquetá Soma

População (hab.) 572.030 542.084 428.035 397.782 372.555 368.534 300.823 243.006 ... 36.515 3.361 6.320.446

% da população 9,05% 8,58% 6,77% 6,29% 5,89% 5,83% 4,76% 3,84% ... 0,58% 0,05%

Prob. Acumulada 9,05% 17,63% 24,40% 30,69% 36,59% 42,42% 47,18% 51,02% ... 99,95% 100,00%

Como base neste quadro, o algoritmo de geração de um ponto é apresentado a seguir: 1 2 3 4

# Algoritmo de geração de um ponto base na densidade populacional Gere um número pseudo-aleatório entre 0 e 1 usando a distribuição uniforme de probabilidade Descubra a qual região administrativa pertence consultando o quadro Use o método de Monte Carlo para gerar um ponto no polígono da RA

Para gerar um ponto dentro de uma RA não basta apenas gerar um ponto, mas também conhecer as bordas dos polígonos de todas elas. Estas bordas foram obtidas da página do Portal Geo da Prefeitura do Rio de Janeiro 39, e como disponibilizam para download em formato Shapefile40 foi usado o conversor para KML Shape2Earth41. Com as bordas

37

Biblioteca Jersey para desenvolvimento de serviços Web: http://jersey.java.net/

38

Armazém de Dados da Prefeitura do Rio de Janeiro: http://www.armazemdedados.rio.rj.gov.br/

39

Portal Geo: http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm

40

Formato Shapefile: http://pt.wikipedia.org/wiki/Shapefile

172

conhecidas constrói-se o bounding box, que é o retângulo que envolve todos os pontos do polígono. Assim, dada uma RA gera-se, aleatoriamente, um ponto (x, y) interno ao retângulo envolvente e verifica-se se o ponto pertence ao polígono 42. Este método de sortear uma solução e verificar se atende uma função é bastante conhecido e denomina-se Método de Monte Carlo. Com base nestas informações, o seguinte algoritmo de geração de coordenadas e atualização no banco de dados foi usado: 1 # algoritmo de geração de caminhos 2 para cada usuario 3 se existe caminho associado ao usuario 4 gere proximo ponto do caminho 5 atualize BD com posicao do usuario e horario atual 6 se caminho terminou 7 desassocie o caminho do usuario 8 se gerador aleatorio 9 defina proximo horario de movimentacao 10 senao 11 se gerador aleatorio 12 se horario atual > proximo horario de movimentacao 13 obtenha posicao atual p e gere um ponto destino q 14 gere um caminho entre p e q 15 senao # usando cenarios 16 obtenha caminho conforme horario atual e agenda do usuario 17 18 se obteve caminho 19 associe o caminho ao usuario 20 inicie animacao do caminho 21 senao 22 atualize BD para marcar horario de medicao atual

O algoritmo gera pontos aleatórios ou conforme cenários. A linha 4 utiliza o animador de caminho associado ao usuário para determinar sua posição atual. Este caminho é gerado na linha 14 ou 16. Nas linhas 11-14 é gerado um caminho a partir do ponto atual e de um ponto destino aleatório caso o próximo horário de movimetação tenha sido atingido. Este horário é definido aleatoriamente na linha 9. Nas linhas 15-16, o caminho para o horário atual é obtido diretamente do cenário no KML. Nas linhas 18-20 o caminho é associado ao usuário e a animação iniciada. Caso nenhum caminho seja criado o usuário continua no mesmo ponto com atualização apenas de sua data de medição (linha 22).

41

Disponível em http://shape2earth.com/

42

O algoritmo por ser encontrado em http://alienryderflex.com/polygon/

173

Para finalizar esta seção, falta falar de caminhos estáticos e animadores de caminho. Um caminho estático, classe StaticPath, contém um conjunto de pontos geográficos ordenados e a distância em metros referente a sua trajetória. Possui ainda um identificador e um nome. A sequência de pontos é dada na sua construção e é proveniente do KML ou do JSON do Google Directions. O comprimento da trajetória é calculado quando a sequência de pontos é passada ou atualizada quando um novo ponto é adicionado. Um animador de caminho é representado pela interface PathAnimator que declara métodos para retornar o caminho estático, iniciar animação e verificar se terminou, e calcular ponto e distância atuais da animação. A classe UniformVelocityPathAnimator implementa esta interface. Ela utiliza um caminho estático e uma direção neste caminho (direto ou inverso) e gera trajetórias em movimento uniforme (MU – velocidade constante). Permite definir a velocidade do movimento ou duração do trajeto utilizando um parâmetro passado no construtor. A Figura 39 apresenta o diagrama estático UML destas classes. PathAnimator + getPath() : StaticPath + getEstimatedDuration() : int + getFirstPoint() : Point + startAnimation() : boolean + isAnimationRunning() : boolean + getAnimationPoint() : Point + getTraveledDistance() : Float + getStartTime() : long

Point + x : double + y : double *

StaticPath UniformVelocityPathAnimator (StaticPath, duration : int, direction : Way) (StaticPath, velocity : int, direction : Way)

1

- id : String - name : String - distance : double

Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath.

174

Apêndice C – Cenário 2: implementação da configuração dos módulos Este apêndice apresenta a configuração detalhada dos módulos do cenário 2. Contudo, para prosseguir a leitura recomenda-se primeiramente a leitura completa das seções 4.2.1 a 4.2.3, pois há referências a muitos conceitos e tabelas apresentados nestas seções. Conforme apresentada na Figura 21, M1 consulta apenas o endpoint RSE, logo necessita de apenas um carregador, mas como precisa calcular as chuvas acumuladas nos quatro intervalos de tempo para cada estação e também obter as localizaçõs das estações, são necessárias cinco consultas. A forma padrão das quatro primeiras consultas é dada a seguir. Observa-se que é obtida a soma das medições durante o intervalo de tempo definido pelas variáveis ?startDate e ?finalDate. Estas são substituídas durante a execução pelo intervalo de tempo

desejado.

O

responsável

por

fazer

estas

substituições

é

o

binder

TimeFrameQueryBinder, sendo assim, a segunda variável será substituída pela data e hora do instante de execução da consulta, e a primeira, pela data e hora inicial, ou seja, aquela obtida por se subtrair o intervalo de tempo (em milissegundos) determinados pela janela de tempo. A chamada à função BIND cria um nó com URI para representar a instância da classe x:Location da estação. Um fato importante a se destacar foi observado ao usar o BIND com a versão 0.8.1 do D2RQ. A versão de consulta utilizando BIND no mesmo WHERE de um FILTER inutiliza o filtro, ou seja, é o mesmo que não colocar um filtro. Isto é destacado pelos trechos tachados (nas linhas 7 e 14). A solução utilizada para contornar esta falha é apresentada em sublinha na linha 18. Uma segunda solução seria não utilizar um BIND explícito, mas sim um implícito no final da projeção (SELECT na linha 7) contendo apenas a expressão URI...AS ?sloc entre parêntesis. Por fim, é construído um novo grafo que mapeia a ontologia do endpoint SER (prefixo a) para a ontologia usada nos módulos (prefixo x). Esta consulta é similar à função acc_rain do algoritmo apresentado (linhas 57-64) e será denominada Qacc até o final desta seção. 1 CONSTRUCT { 2 ?s a x:Station ; 3 x:location ?sloc . 4 ?sloc x:accRain15 ?acc . 5 } 6 WHERE { 7 { SELECT ?s (SUM(?v) as ?acc) ?sloc 8 WHERE { 9 ?s a a:Station . 10 ?m a:station ?s . 11 ?m a:measureValue ?v .

175

12 13 14 15 16 17 18

?m a:measureDate ?t . FILTER (?t >= ?startDate && ?t 14 15 15*60*1000 16 17 18 19 Qacc 20 2.5*60*1000 21 22 1*60*60*1000 23 24 25 26 Qacc 27 2.5*60*1000 28 29 24*60*60*1000 30 31 32 33 Qacc 34 2.5*60*1000 35 36 96*60*60*1000 37 38 39 40 Qstloc 41 60*60*1000 42 43 96*60*60*1000 44 45 46

177

47 48 49 50 PELLET 51 ontology.owl.ttl 52 53 54 /ds/ 55 25001 56 true 57 58

O módulo M2 calcula as distâncias entre usuários e estações, associando a cada usuário as três estações mais próximas. Isto equivale às linhas 1-15 do algoritmo, que consistem em duas consultas e um laço. A primeira, Quser, obtém a lista de usuários do endpoint ULE, suas localizações e horários de obtenção. A segunda, Qdist, é executada dentro do laço que itera sobre a lista de usuários, e tira proveito da função geo:distanceFromDegrees do módulo M1 para cálculo da distância geográfica entre dois pontos (neste caso usuário e as estações), ordena estes resultados usando a cláusula ORDER BY e faz um corte nos três primeiros resultados usando a cláusula LIMIT, selecionando assim, as três estações mais próximas. Para executar a consulta Qdist para cada linha de resultado da Quser usando o Módulo de Inferência utiliza-se o binder SelectQueryParameterBinder. Ambas as consultas são listadas a seguir e as variáveis da consulta Quser substituídas na consulta Qdist estão destacadas com sublinhado: 1 2 3 4 5 6 7 8

SELECT ?u ?uloc ?ulat ?ulon ?utime WHERE { ?u a usr:User ; usr:location ?uloc . ?uloc usr:latitude ?ulat ; usr:longitude ?ulon ; usr:updateTime ?utime . }

1 2 3 4 5 6 7 8 9

CONSTRUCT { ?u a x:User ; x:inferenceLocation ?uloc . ?uloc x:latitude ?ulat ; x:longitude ?ulon ; x:updateTime ?utime ; x:nearestStations ?ns . ?ns x:station ?s ; x:distance ?dist .

178

10 } 11 WHERE { 12 { SELECT ?s (geo:distanceFromDegrees(?ulat, ?ulon, ?slat, ?slon) as ?dist) 13 WHERE { 14 ?s a x:Station ; 15 x:location [ 16 x:latitude ?slat ; 17 x:longitude ?slon ] . 18 } 19 ORDER BY ?dist 20 LIMIT 3 21 } 22 BIND (URI(fn:concat( "http://infmod02.com.br/resource/NearestStationsInfo/", afn:sha1sum(fn:concat(?u, ?s)))) as ?ns) 23 }

Adicionalmente, uma consulta que obtém os valores de chuvas acumuladas de M1 foi adicionada ao módulo M2. Esta consulta funciona apenas para repassar estes valores para o endpoint de M2. Por ser um consulta simples e não acrescentar conhecimento será omitida e denominada Qacc2. O XML de M2 é apresentado a seguir: 1 2 M2 3 ... 4 http://infmod02.com.br/resource/ 5 6 7 8 9 http://infmod01.com.br:25001/ds/sparql 10 11 12 2*60*1000 13 Qacc2 14 15 16 17 2*60*1000 18 Qdist 19 20 http://users.com.br:2026/sparql 21 Quser 22 23 24 25

179

26 27 ... 28 ... 29



O modulo M3 é o mais complexo por implementar as linhas 17-55 do algoritmo. A Equação I é calculada através de uma consulta SPARQL e a classificação efetuada por meio de regras Jena. São usadas regras do Jena por dois motivos: (1) maior facilidade de se escrever regras por não haver necessidade de editores especiais devido a sua sintaxe simples; e (2) mostrar a possibilidade de se misturar dois diferentes motores de inferência na rede, desde que em diferentes módulos. Relembre que é necessário calcular o denominador do peso (dtot nas linhas 17-18) e o peso (linha 22) de cada estação no cálculo da suposta quantidade de chuva na posição do usuário (linhas 23 a 26). Portanto, a consulta SPARQL pode ser considerada complexa porque inclui quatro SELECTs distribuídos em três níveis de aninhamento (Sub-SELECTs), quatro junções (dois SELECTs e dois padrões de grafo), função de agregação SUM e expressões matemáticas (multiplicaçaõ e divisão). A consulta completa é mostrada a seguir (Qchuva): 1 CONSTRUCT { 2 ?u a x:User . 3 ?u x:inferenceLocation ?loc . 4 ?loc x:latitude ?lat ; 5 x:longitude ?lon ; 6 x:updateTime ?time ; 7 x:accRain15 ?avg15 ; 8 x:accRain01h ?avg60 ; 9 x:accRain24h ?avg24 ; 10 x:accRain96h ?avg96 ; 11 } 12 WHERE { 13 SELECT DISTINCT ?u ?loc ?lat ?lon ?time 14 (sum(?lv15) as ?avg15) # Calcula avg15 para 15 (sum(?lv60) as ?avg60) # Calcula avg60 para 16 (sum(?lv24) as ?avg24) # Calcula avg24 para 17 (sum(?lv96) as ?avg96) # Calcula avg96 para 18 WHERE { 19 SELECT DISTINCT ?u ?loc ?lat ?lon ?time 20 ((?w * ?v15) as ?lv15) # Calcula parcelas 21 ((?w * ?v60) as ?lv60) # Calcula parcelas 22 ((?w * ?v24) as ?lv24) # Calcula parcelas 23 ((?w * ?v96) as ?lv96) # Calcula parcelas 24 WHERE { 25 { 26 # Calcula denominador da fórmula (?dtot)

cada cada cada cada

usuario usuario usuario usuario

para 15 min para 1 h para 24 h para 96 h

180

27 { SELECT DISTINCT ?u ?loc (sum(1 / (?d * ?d)) as ?dtot) 28 WHERE { 29 ?u a x:User ; 30 x:inferenceLocation ?loc . 31 ?loc x:nearestStations ?ns . 32 ?ns x:station ?s ; 33 x:distance ?d . 34 } 35 GROUP BY ?u ?loc 36 } 37 # Calcula numerador de cada peso w: 1/d^2 (?num_w) 38 { SELECT DISTINCT ?u ?loc (1 / (?d * ?d) as ?num_w) ?s 39 WHERE { 40 ?u a x:User . 41 ?u x:inferenceLocation ?loc . 42 ?loc x:nearestStations ?ns . 43 ?ns x:station ?s ; 44 x:distance ?d . 45 } 46 } 47 # Obtem chuva acumulada nas estações próximas ao usuário ?u 48 { ?s x:location [ 49 x:accRain15 ?v15 ; 50 x:accRain01h ?v60 ; 51 x:accRain24h ?v24 ; 52 x:accRain96h ?v96 ] . 53 } 54 # Obtem lat/long do usuário ?u e horário de atualização 55 { ?loc x:latitude ?lat ; 56 x:longitude ?lon ; 57 x:updateTime ?time . 58 } 59 } 60 # Calcula pesos (?w) 61 BIND ((?num_w / ?dtot) as ?w) 62 } 63 } 64 GROUP BY ?u ?loc ?lat ?lon ?time 65 }

Os SELECTs mais internos calculam numerador e denominador dos pesos (1/d2 e Equação IIc) e são encontrados nas linhas 37-46 e 26-36, respectivamente. O cálculo do denominador utiliza a função de agregação SUM agrupada por usuário e localização. Existe apenas uma instância de x:UserLocation para cada propriedade x:inferenceLocation de usuário, mas outras poderiam ser adicionadas (como casa, trabalho, etc.) sem necessidade de alterações na consulta visto que ela já garante distinção. Uma vez que estes SELECTs retornam soluções nas variáveis ?u, ?loc, ?dtot, ?num_w, e ?s, estas são combinadas (produto

181

cartesiano ou junção) com os padrões de grafos das linhas 47-53 e 54-58 que capturam as chuvas acumuladas na estação ?s e latitude, longitude da localização ?loc do usuário ?u (e também horário de atualização destas coordenadas), respectivamente. O resultado desta junção é, então, utilizado no SELECT de segundo nível que calcula pesos (Equação IIb) na linha 61, e as parcelas wi vi(t) para os quatro períodos em questão preenchendo as variáveis ?lv15, ?lv60, ?lv24 e ?lv96 nas linhas 20-23. Estas parcelas são somadas no SELECT mais externo chegando-se ao resultado das variáveis ?avg15, ?avg60, ?avg24 e ?avg96 (Equação IIa). Por fim, é montado o grafo que armazenará estes resultados para posterior utilização através do CONSTRUCT. Baseado na suposta quantidade de chuva, a intensidade de chuva e a probabilidade de escorregamento definidas pelo Alerta-Rio são dadas por meio das seguintes regras Jena: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

# Intensidade de chuvas (15 min) r15a: (?p :accRain15 ?v) gt(?v, 12.50) r15b: (?p :accRain15 ?v) gt(?v, 6.25) r15c: (?p :accRain15 ?v) gt(?v, 1.25) r15d: (?p :accRain15 ?v) gt(?v, 0.28) r15e: (?p :accRain15 ?v) # Intensidade de chuvas (1h) r60a: (?p :accRain01h ?v) gt(?v,50.00) r60b: (?p :accRain01h ?v) gt(?v,25.00) r60c: (?p :accRain01h ?v) gt(?v, 5.00) r60d: (?p :accRain01h ?v) gt(?v, 1.10) r60e: (?p :accRain01h ?v) gt(?v, 0.50) r60f: (?p :accRain01h ?v) gt(?v, 0.25) r60g: (?p :accRain01h ?v) gt(?v, 0.00) r60h: (?p :accRain01h ?v)

-> (?p :rainLevel15 le(?v, 12.50) -> (?p :rainLevel15 le(?v, 6.25) -> (?p :rainLevel15 le(?v, 1.25) -> (?p :rainLevel15 le(?v, 0.28) -> (?p :rainLevel15

(?p (?p (?p (?p (?p (?p (?p (?p

:rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h :rainLevel01h

7) 6) 5) 4) 3) 2) 1) 0)

# Alerta de escorregamento (1h) s60a: (?p :accRain01h ?v) gt(?v,50.00) -> (?p s60b: (?p :accRain01h ?v) gt(?v,30.00) le(?v,50.00) -> (?p s60c: (?p :accRain01h ?v) gt(?v,10.00) le(?v,30.00) -> (?p s60d: (?p :accRain01h ?v) le(?v,10.00) -> (?p

:slipLevel01h :slipLevel01h :slipLevel01h :slipLevel01h

3) 2) 1) 0)

# Alerta de escorregamento (24h) s24a: (?p :accRain24h ?v) gt(?v,175.0) -> (?p s24b: (?p :accRain24h ?v) gt(?v,100.0) le(?v,175.0) -> (?p s24c: (?p :accRain24h ?v) gt(?v, 50.0) le(?v,100.0) -> (?p s24d: (?p :accRain24h ?v) le(?v, 50.0) -> (?p

:slipLevel24h :slipLevel24h :slipLevel24h :slipLevel24h

3) 2) 1) 0)

# Alerta de escorregamento (96h) s96a: (?p :accRain96h ?v) gt(?v,250.0) -> (?p s96b: (?p :accRain96h ?v) gt(?v,175.0) le(?v,250.0) -> (?p s96c: (?p :accRain96h ?v) gt(?v,100.0) le(?v,175.0) -> (?p s96d: (?p :accRain96h ?v) le(?v,100.0) -> (?p

:slipLevel96h :slipLevel96h :slipLevel96h :slipLevel96h

3) 2) 1) 0)

le(?v,50.00) le(?v,25.00) le(?v, 5.00) le(?v, 1.10) le(?v, 0.50) le(?v, 0.25) le(?v, 0.00)

-> -> -> -> -> -> -> ->

7) 6) 5) 4) 0)

182

37 # Intensidade de chuvas (final) 38 r01: (?p :rainLevel15 ?x) (?p :rainLevel01h ?y) max(?x, ?y, ?z) -> (?p :rainLevelX ?z) 39 40 r02: (?p :rainLevelX 7) -> (?p :rainLevel :VeryHeavyRain) 41 r03: (?p :rainLevelX 6) -> (?p :rainLevel :HeavyRain) 42 r04: (?p :rainLevelX 5) -> (?p :rainLevel :ModerateRain) 43 r05: (?p :rainLevelX 4) -> (?p :rainLevel :LightRain) 44 r06: (?p :rainLevelX 3) -> (?p :rainLevel :HeavyDrizzle) 45 r07: (?p :rainLevelX 2) -> (?p :rainLevel :ModerateDrizzle) 46 r08: (?p :rainLevelX 1) -> (?p :rainLevel :LightDrizzle) 47 r09: (?p :rainLevelX 0) -> (?p :rainLevel :Dry) 48 49 # Alerta de escorregamento (final) 50 s01: (?p :slipLevel01h ?x) (?p :slipLevel24h ?y) (?p :slipLevel96h ?z) max(?x,?y,?w0) max(?w0,?z,?w) -> (?p :slipLevelX ?w) 51 52 s02: (?p :slipLevelX 3) -> (?p :slipLevel :VeryHigh) 53 s03: (?p :slipLevelX 2) -> (?p :slipLevel :High) 54 s04: (?p :slipLevelX 1) -> (?p :slipLevel :Moderate) 55 s05: (?p :slipLevelX 0) -> (?p :slipLevel :Low)

As regras não são difíceis de se entender. Por exemplo, a regra r15a na linha 2 diz “se existe um localização cuja chuva dos últimos 15 minutos seja maior que 12.50 mm então adicione uma tripla afirmando que o nível para intensidade de chuva dos últimos 15 minutos é 7 (ou x:VeryHeavyRain)”. Maiores detalhes sobre cada regra e bloco de regras são dadas nos próximos parágrafos. Como apresentado nos Quadros 8 e 10, para a classificação do nível de intensidade de chuva, deve-se considerar os valores de medições em mm/h e mm/15min, respectivamente. Desta forma as regras r15a a r15e (linhas 2-6) verificam em qual faixa a propriedade x:accRain15 se encontra (mm/15min) e as regras r60a a r60h (linhas 9-16) verificam a faixa para a propriedade x:accRain01h. Estes dois conjuntos de regras produzem, respectivamente, triplas com predicados x:rainLevel15 e x:rainLevel01h cujos objetos são valores numéricos inteiros intermediários que representam o grau de gravidade do alerta (zero para sem chuva e sete para chuva muito forte). Para estas regras foram utilizadas duas funções (built-ins) do Jena: greaterThan (abreviada para gt) que retorna true se o primeiro argumento é maior que o segundo; e le que retorna true se o primeiro argumento é menor ou igual ao segundo. Conforme descrito na seção 4.2.1 sobre o domínio, escolheu-se utilizar o pior dos valores obtidos (máximo entre x:rainLevel15 e x:rainLevel01h), que corresponde a regra r01 (linha 38) e utiliza a função max. Este valor é então mapeado para instâncias de x:RainLevel por meio das regras r02 a r09 (linhas 40-49).

183

O processo é feito de forma semelhante para alertas de probabilidade de escorregamento (Quadro 9). As regras s60a a s60d (1 hora), s24a a s24d (24 horas) e s96a a s96d (96 horas) encontradas nas linha 19-22, 25-28 e 31-34, respectivamente, produzem triplas intermediárias com os predicados x:slipLevel01h, x:slipLevel24h e x:slipLevel96h que possuem os graus de gravidade do alerta (zero para baixa probabilidade de escorregamento, um para moderada, dois para alta e três para muito alta). Novamente, o valor mais crítico dentre estes três é obtido (regra s01 na linha 50) e mapeado para instâncias de x:SlipLevel (regras s02 a s05 nas linhas 52-55). Vários observações importantes devem ser destacadas aqui. Primeiramente, não haverá várias classificações (x:rainLevel e x:slipLevel) para uma mesma localização porque as propriedade x:accRainY são únicas para cada URI de localização (fato comprovado pelo GROUP BY mais externo da consulta Qchuva). Para ficar mais claro, veja que como existe no máximo uma tripla (?p x:accRain15 ?v) no grafo (para cada localização ?p) é garantido que no máximo uma tripla (?p x:rainLevel15 X) será criada e a regra r01 será disparada no máximo uma vez para cada localização (?p) gerando no máximo uma tripla (?p x:rainLevelX ?z) e consequentemente uma tripla com o predicado x:rainLevel. O mesmo ocorre para probabilidade de escorregamento. O segundo ponto diz respeito à consistência da base gerada por M3. As propriedades intermediárias x:rainLevel15, x:rainLevel01h, x:rainLevelX, x:slipLevel01h, x:slipLevel24h, x:slipLevel96h e x:slipLevelX não estão presentes na ontologia apresentada na Figura 22, logo uma validação nesta base resultaria em incosistência. Para resolver isto bastaria adicionar as propriedades à ontologia e configurar M3 para utilizá-la, mas optou-se por não realizar a validação que será feita no próximo módulo. Assim, este módulo é apenas baseado em regras sem validação OWL-DL. Outro ponto importante é que estas regras poderiam ser facilmente implementadas via programação convencional imperativa conforme apresentado no algoritmo completo (linhas 28-55 da seção 4.2.3.1), mas isto não é permitido pela arquitetura do Módulo de Inferência, sugerindo trabalhos futuros. Para concluir M3, o XML de configuração apenas com as partes mais importantes para evitar repetições é apresentado a seguir: 1 2 3 4 5 6 7

M3 ... http://infmod02.com.br:25002/ds/sparql

184

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Qchuva 3*60*1000 [r15a: (?p x:accRain15 ?v) greaterThan(?v, 12.50) -> (?p x:rainLevel15 7) ] [r15b: (?p x:accRain15 ?v) greaterThan(?v, 6.25) -> (?p x:rainLevel15 6) ] ... ...

le(?v, 12.50)

As regras são adicionadas no interior do element (linhas 17-21). Pode-se observar que cada regra deve ser envolvida por colchetes que foram omitidos devido ao pequeno espaço ao mostrar todas as regras anteriormente. Até este momento, a localização de cada usuário já possui uma classificação para intensidade de chuva e probabilidade de escorregamento. Poderia-se até finalizar a rede neste ponto, mas para mostrar como um novo módulo pode ser adicionado facilmente, foi criado o módulo M4 para produzir contexto de bairro para o usuário. Assim, a tarefa de M4 é recuperar a posição atual de cada usuário e adicionar a informação do bairro à ela, fazendo o mesmo com a posição usada para geração dos alertas. Para isso é utilizado um carregador para o endpoint NBE contendo dois pares de consultas. O primeiro par obtém a posição atual do usuário consultando o endpoint ULE com uma consulta semelhante à Quser, de forma que um SelectQueryParameterBinder é usado para atribuir valores às variáveis de uma outra consulta disparada contra o endpoint NBE. Esta última utiliza a função nb_contains para descobrir o bairro que contém a coordenada geográfica dada. Estas informações são associadas ao usuário através da propriedade x:currentLocation. O segundo par de consultas executa um processo semelhante, com a diferença de determinar o bairro da posição utilizada na inferência (propriedade x:inferenceLocation oriunda de M3), e adicionalmente repassar os valores das propriedades x:slipLevel e x:rainLevel já computadas por M3. O XML não será apresentado aqui.

185

Apêndice D – Cenário 3: implementação, mapeamento e configuração dos módulos para Bus Locations Endpoint (BLE) Este apêndice abordará a implementação do endpoint BLE, que compreende um gerador de caminho de ônibus com base em arquivos KML contendo pontos de ônibus e rotas. As coordenadas geradas são armazenadas em um banco de dados relacional e mapeadas para RDF usando uma parte da ontologia BusOnto (seção 4.3.1.3 na página 121). As bibliotecas e ferramentas utilizadas são as mesmas descritas no Apêndice B, salvo quando expresso o contrário. Por fim, dois módulos de inferência são usados para (a) completar o que não é expresso pelo mapeamento e checar a consistência da base estática usando Pellet e (b) agregar a base estática e os dados dinâmicos usando Jena. Este último módulo é o endpoint final do BLE. A Figura 40 esquematiza este procedimento. BusDyn (Jena) bus:Bus (10s)

Rotas, linhas, etc. (10min)

BusStatic (Pellet)

Rotas, linhas, etc. (1h)

BusD2R (porta 5050)

mapeamento para RDF Rotas (KML)

Paradas (KML)

Carregador de KML

Algoritmo de geração de ônibus e caminhos

atualiza SGBD

Figura 40. Estrutura interna do endpoint BLE

Como pode observar na figura, há dois tipos de arquivos KML (o formato é explicado no Apêndice B). O primeiro deles possui apenas paradas de ônibus, ou seja, dados estáticos sobre pontos geográficos rotulados (Placemark e Point). O segundo tipo de KML contém rotas de ônibus (Placemark e LineString) e o nome e código da linha. Apenas duas linhas de ônibus foram elaboradas, retratando uma linha interna (Alojamento – Vila Residencial) e uma linha externa (General Osório – Penha) que circulam no campus da Ilha do Fundão. Isto resultou em quatro arquivos KML. Para simplificar, considerou-se que ambas as linhas circulam todos os dias da semana, 24 horas por dia, a uma velocidade média de 50 km/h, com intervalos médios de 12 minutos e desvio padrão de 4 minutos seguindo a distribuição normal de probabilidade. As coordenadas geográficas que compõem ambos os tipos de KML foram

186 gerados usando o software Google Earth43 e retratam a realidade dentro do campus (paradas e rotas reais). Uma vez carregados, os dados dos arquivos KML são inseridos em um banco relacional cujo esquema é apresentado na FIGURA. De forma semelhante ao endpoint ULE, há tabelas em disco e em memória, dependendo da frequência de atualização de seus registros. Assim, a parte estática (tabelas stop, route_stop, route e line) fica em disco e a parte dinâmica (tabela bus_car) em memória. Todas as tabelas são análogas às classes apresentadas na ontologia da Figura 26 na página 122, ou seja, o mapeamento é direto, conforme pode ser visto na Figura 41. bus:RouteStop

bus:Stop

Disco

bus:Bus

route_stop id (PK) : INT route_id (FK) : INT stop_id (FK) : INT sequence : INT distance_origin : FLOAT

Memória

stop id (PK) : INT name : VARCHAR(40) latitude : DOUBLE longitude : DOUBLE

bus_car id (PK) : INT order_num : INT latitude : DOUBLE longitude : DOUBLE route_id (FK) : INT traveled_distance : FLOAT traveled_time : INT

route id (PK) : INT line_id (FK) : INT start_rs_id (FK) : INT final_rs_id (FK) : INT

bus:Route

line id (PK) : INT name : VARCHAR(60) code : VARCHAR(8)

bus:Line

Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto.

A geração das coordenadas das rotas dos ônibus é feita usando caminhos com trajetória em velocidade constante (classe UniformVelocityPathAnimator na Figura 39). Antes de criar o animador de caminho, a rota lida do KML é transformada numa lista de pontos (StaticPath). O processo é mostrado no algoritmo a seguir. 1 2 3 4 43

# Inicialização mi := 12 sigma := 4 Para cada rota r

Google Earth – http://www.google.com/earth/

187

5 next_time(r) = cur_time() 6 7 Enquanto simulação estiver rodando 8 # Geracao de carros 9 Para cada rota r 10 Se cur_time() > next_time(r) então 11 Crie um animador de caminho p iniciando em origem(r) 12 Crie um ônibus c com um número de ordem aleatório 13 Adicione (c, p) à simulação 14 next_time(r) = cur_time() + normal(mi, sigma * sigma) 15 16 # Atualização de coordenadas 17 Para cada (c, p) na simulação 18 Se p terminou então 19 Remova (c, p) da simulação 20 Senão 21 P = cur_point(p) 22 latitude(c) = P.y 23 longitude(c) = P.x 24 traveled_distance(c) = traveled_distance(p) 25 traveled_time(c) = cur_time - start_time(p) 26 Atualize c na simulação

Assim, a saída de carros segue a distribuição normal com média de 12 minutos e desvio padrão de 4 minutos (linha 14), sendo que cada carro possui um trajeto dado pelo animador de caminhos construído a partir da rota oriundo do KML (linhas 11-12). Uma vez que um par carro/caminho (c, p) é adicionado à simulação (linha 13) a tabela bus_car do banco de dados passa a ser frequentemente atualizada traçando o caminho do ônibus (linhas 21 a 26). Uma vez que KML foram carregados, trajetos estão sendo atualizados e o D2R foi configurado e iniciado, basta construir os arquivos XMLs de configuração dos dois módulos de inferência que completam e validam a base exportada pelo D2R. Eles já foram sucitamente descritos na seção 4.3.2.3 na página 129 e são reapresentados na parte superior da Figura 40. O módulo que obtém os dados estáticos (BusStatic) executa um SPARQL DESCRIBE dos recursos que sejam instâncias de bus:Stop, bus:Route, bus:Line e bus:RouteStop, e aciona o reasoner Pellet aplicando a ontologia BusOnto conforme mostra no XML a seguir: 1 2 3 4 5 6 7 8

Bus Endpoint http://bus.org/resource/ ... ...

188

9 10 Populate dataset 11 12 DESCRIBE ?bs ?route ?rs ?line 13 WHERE { 14 ?bs a bus:Stop . 15 ?route a bus:Route . 16 ?rs a bus:RouteStop . 17 ?line a bus:Line . 18 } 19 20 1*60*60*1000 21 22 23 24 25 26 27 PELLET 28 busonto.owl 29 30 ... 31

O módulo que obtém os dados dinâmicos (BusDyn) executa um SPARQL DESCRIBE dos recursos que sejam instâncias de bus:Bus oriundos de BusD2R e um SPARQL CONSTRUCT com todas as triplas de BusStatic. Utiliza uma regra Jena para adicionar a propridade bus:servingLine que associa um ônibus a uma linha. Para finalizar, o XML a seguir mostra a configuração do módulo: 1 2 ... 3 4 ... 5 6 7 DESCRIBE ?x WHERE { ?x a bus:Bus } 8 10*1000 9 10 11 12 13 ... 14 15 16 CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o } 17 10*60*1000 18

189

19 20 21 22 23 24 25 26 27

28 29 30 31 32

JENA [r1: (?b rdf:type bus:Bus), (?l rdf:type bus:Line), (?r rdf:type bus:Route), (?b bus:route ?r), (?l bus:route ?r) -> (?b bus:servingLine ?l) ] ...

190

Apêndice E – Cenário 3: Configuração dos módulos da camada de inferência Este apêndice apresenta a configuração detalhada dos módulos do cenário 3. Contudo, para prosseguir recomenda-se primeiramente a leitura completa das seções 4.3.1 a 4.3.3, pois há referências a muitos conceitos e tabelas apresentados nestas seções. O módulo A1 utiliza duas consultas, denominadas Qcmdate e Qurel, e um conjunto de sete regras. Ambas são apresentadas a seguir. A primeira consulta é um DESCRIBE que obtém todas as instâncias de app:CommemorativeDate de CDE que estão por chegar através da comparação da sua data inicial na variável ?beg (propriedade time:hasBeginning de evento de intervalo) com a data e hora atual na variável ?date usando um FILTER. Data e hora atuais são obtidas fazendo uma consulta ao endpoint do relógio e para isso utiliza-se um SelectQueryParameterBinder. A segunda consulta, feita ao USNLE, é um DESCRIBE das pessoas (variáveis ?u, ?x e ?y), das relações existentes entre pessoas (variável ?r) e dos intervalos de tempo em que estas relações ocorrem (variável ?t). Observe que ao descrever um usuário ?u todas as suas propriedades são retornadas (ex. rel:siblingOf, rel:husbandOf, etc.). Estas duas consultas não precisam ser atualizadas com muita frequência, por isso Qcmdate executa a cada 10 minutos e Qurel a cada 5 minutos. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# Qcmdate DESCRIBE ?x WHERE { ?x a apv:CommemorativeDate ; evt:timeSpan [ a time:Interval ; time:hasBeginning ?beg ] . FILTER (?date < ?beg) } # Qurel DESCRIBE ?u ?x ?r ?t WHERE { { ?u a foaf:Person . } { ?u foaf:knows ?x } UNION { ?u rel:relativeOf ?y } UNION { ?r rel:participant ?u ; evt:timeSpan ?t . } }

As regras utilizadas dividem-se três grupos: (a) construção de eventos de aniversário de nascimento e participações; (b) construção de eventos de aniversário de casamento e

191

namoro e participações; (c) construção de participações em eventos genéricos provenientes de CDE. As regras R1 e R1a apresentadas a seguir pertencem ao grupo (a). R1 pega a data de nascimento de uma pessoa (?dt), calcula o instante inicial da próxima data de aniversário usando a função makeNearestDateTime (?beg), gera o instante final (?end) e constrói dois nós no grafo da base intermediária usando a função makeNamedNode: um para o evento aniversário a ser criado (?ebn) e outro para o intervalo de tempo deste evento (?tbn). No caso de sucesso de todos estes procedimentos, adiciona triplas para dizer que ?ebn e ?tbn são instâncias de evt:Event e time:Interval respectivamente, relaciona ambos com a propriedade evt:timeSpan e define os instantes de início e fim do intervalo de tempo. Por fim, gera as triplas de participação (propriedades evt:playsRole e app:isBirthdayPersonOf). A regra R1a utiliza os eventos app:Birthday e participações app:isBirthdayPersonOf criados por R1 e as triplas com predicado foaf:knows para gerar participações do tipo “amigo de aniversariante” nos eventos aniversário. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

# Regra para construir evento Birthday: proximo aniversario R1: (?x rel:dateOfBirth ?dt), makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end), makeNamedNode(?ebn, ?x, "/Birthday"), makeNamedNode(?tbn, ?x, "/Birthday/Time") -> (?ebn rdf:type apv:Birthday), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?x app:isBirthdayPersonOf ?ebn) # Regra para associar pessoas ao aniversario de seus # conhecidos (amigos, mae, namorado, irmao, etc.) R1a: (?ev rdf:type apv:Birthday), (?x apv:isBirthdayPersonOf ?ev), (?x foaf:knows ?f) -> (?f evt:playsRole ?ev), (?f apv:isBirthdayPersonsFriendOf ?ev)

As regras R2 e R3 apresentadas a seguir fazem parte do grupo (b). R2 obtém os participantes de um casamento (?x e ?y), o instante de início do relacionamento (?beg), calcula o fim do dia do evento (?end), gera nós para o evento app:WeddingDay (?ebn) e o

192

intervalo de tempo de sua ocorrência (?tbn) e, em caso de sucesso, adiciona triplas sobre ?ebn e ?tbn e particapações evt:playsRole. R3 é análoga e não será explicada. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

# Regra para construir evento WeddingDay: proximo aniversario # da relacao Marriage R2: (?r rdf:type rel:Marriage), (?x rel:participantIn ?r), (?y rel:participantIn ?r), notEqual(?x, ?y), (?r evt:timeSpan ?t), (?t time:hasBeginning ?dt) makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end) makeNamedNode(?ebn, ?r, "/WeddingDay"), makeNamedNode(?tbn, ?r, "/WeddingDay/Time") -> (?ebn rdf:type apv:WeddingDay), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?y evt:playsRole ?ebn) # Regra para construir evento CourtshipDay: proximo aniversario # da relacao Courtship R3: (?r rdf:type rel:Courtship), (?x rel:participantIn ?r), (?y rel:participantIn ?r), notEqual(?x, ?y), (?r evt:timeSpan ?t), (?t time:hasBeginning ?dt) makeNearestDateTime(?dt, ?beg), dateSum(?beg, 1, ?end) makeNamedNode(?ebn, ?r, "/CourtshipDay"), makeNamedNode(?tbn, ?r, "/CourtshipDay/Time") -> (?ebn rdf:type apv:CourtshipDay), (?ebn rdf:type evt:Event), (?ebn evt:timeSpan ?tbn), (?tbn rdf:type time:Interval), (?tbn time:hasBeginning ?beg), (?tbn time:hasEnd ?end), (?x evt:playsRole ?ebn), (?y evt:playsRole ?ebn)

O terceiro grupo (c) é representado pela regras R_EG a seguir. Neste grupo, como os eventos já existem, pois vieram de CDE, basta construir as participações. Assim, todos

193

participam em feriados nacionais (R_EG1), apenas mãe e filho(a) participam do dia das mães (R_EG2) e apenas casais de namorados participam do dia dos namorados (R_EG3). Isto conclui o módulo A1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

# Regra para relacionar eventos Holiday existentes e # pessoas (eventos gerais) R_EG1: (?p rdf:type foaf:Person), (?ev rdf:type apv:Holiday), noValue(?ev, rdf:type, apv:MothersDay) -> (?p evt:playsRole ?ev) # Regra para relacionar eventos MothersDay e pessoas cuja # mae seja conhecida R_EG2: (?p1 rel:motherOf ?p2), (?ev rdf:type apv:MothersDay) -> (?p1 evt:playsRole ?ev), (?p2 evt:playsRole ?ev) # Regra para relacionar eventos ValentinesDay e pessoas # cujo(a) namorado(a) seja conhecido(a) R_EG3: (?p1 rel:courts ?p2), (?ev rdf:type apv:ValentinesDay) -> (?p1 evt:playsRole ?ev), (?p2 evt:playsRole ?ev)

O módulo B1 gera eventos de chegadas de ônibus em pontos de ônibus e para isso é necessário apenas uma consulta, denominada Qarrival1, que é um CONSTRUCT com SubSELECTs em dois níveis na cláusula WHERE. Ela é apresentada a seguir: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

# Qarrival1 CONSTRUCT { ?ev a apv:BusArrival , evt:InstantEvent , evt:Event ; apv:bus ?car ; apv:busStop ?stop ; rdfs:label ?label ; rdfs:comment "Estimated time for the bus arrival"@en ; evt:atTime ?evtm . ?evtm a time:Instant ; time:hasDateTime ?dateTime . ?car bus:route ?route . } WHERE { { SELECT ?car ?stop ?route (infmod:sumTime(?date, 0, ?est_time) as ?dateTime) (fn:concat("Onibus em direcao ao ponto '", 18 ?stopname, "'") as ?label) 19 WHERE { 20 { # Seleciona onibus e suas próximas paradas e calcula 21 # distancia entre ambos e tempo estimado até chegar 22 SELECT ?stop ?stopname ?route ?car 23 ((?dist1 - ?dist2) as ?remaining_dist) 24 ((?remaining_dist * (?time / ?dist2)) as ?est_time) 25 WHERE { 26 ?rs a bus:RouteStop ; 27 bus:stop ?stop ; 28 bus:belongsToRoute ?route ; 29 bus:distanceFromOrigin ?dist1 . 30 ?car a bus:Bus ; 31 bus:traveledDistance ?dist2 ; 32 bus:traveledTime ?time ; 33 bus:route ?route . 34 ?stop bus:name ?stopname . 35 FILTER (?dist1 >= ?dist2 ) 36 } 37 } 38 FILTER(?est_time > 15 && ?est_time < 1200) 39 } 40 } 41 BIND (URI(fn:concat(str(?car), 42 "/Stop", 43 afn:substr(str(?stop), 44 infmod:getLastIndexOf("/", str(?stop))), 45 "/Event")) as ?ev) 46 BIND (URI(fn:concat(str(?car), 47 "/Stop", 48 afn:substr(str(?stop), 49 infmod:getLastIndexOf("/", str(?stop))), 50 "/Event/Time")) as ?evtm) 51 }

O SELECT mais interno (linhas 22-35) seleciona ônibus e suas próximas paradas (?car e ?stop nas linhas 22 e 26-35) e calcula distância entre ambos (?remaining_dist, linha 23) e tempo estimado até chegar (?est_time, linha 24). O SELECT externo (linhas 14-40) filtra apenas os resultados cujo tempo estimado esteja entre 15 e 1200 segundos (FILTER na linha 38) e seleciona ônibus, rotas e paradas e constrói colunas ?dateTime e ?label (linhas 14-18). A primeira retorna o instante de chegada estimado no formato do tipo xsd:dateTime usando a função infmod:sumTime e, a segunda coluna, cria um texto explicativo. No final do WHERE mais externo há dois BINDs que constróem nós para os eventos de chegada e para o instante de tempo que o evento ocorrerá (linhas 41-46). Por fim, o CONSTRUCT cria o grafo com

195

eventos app:BusArrival (linhas 2-11). Esta consulta é configurada para executar em intervalos de 30 segundos. O módulo B2 utiliza uma consulta principal ao endpoint BLE, denominada Qrec (apresentada a seguir), com um SelectQueryParameterBinder adicional para obter as coordenadas dos usuários (?ulat e ?ulon na linha 19) e os destinos desejados (?uDestName, linha 33). Como esta consulta secundária retorna várias linhas de resultado (uma para cada usuário ?u), a quantidade de vezes que a consulta principal será executada depende da quantidade de usuários na base USNLE. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

# Qrec CONSTRUCT { ?u a foaf:Person . ?stop a bus:Stop . ?route a bus:Route . ?u app:recommendedBusStop ?pstop . ?pstop a app:BusStopRecommendation ; app:stop ?stop ; app:distance ?dist ; app:route ?route . } WHERE { # Variáveis resultantes da junção: # ?stop = ponto de onibus proximo da posicao atual do usuario # ?dist = distancia entre usuario e ?stop # ?route = rota de onibus que passa em ?stop e no ponto de # destino do usuario { SELECT ?stop (geofn:distanceFromDegrees(?lat, ?lon, ?ulat, ?ulon) as ?dist) WHERE { ?stop a bus:Stop ; geo:lat ?lat ; geo:long ?lon . } ORDER BY ?dist LIMIT 3 } { ?rs bus:stop ?stop ; bus:nextStop* ?rs2 . ?rs2 bus:stop/bus:name ?stopName ; bus:belongsToRoute ?route . FILTER (CONTAINS(LCASE(?stopName), LCASE(?uDestName))) } FILTER (?dist < 500)

196

37 BIND (URI(fn:concat( 38 "http://user-bus-contexts.com/resource/BusStopRecommendation/", 39 afn:substr(str(?u), infmod:getLastIndexOf("/", str(?u))), 40 afn:substr(str(?stop), infmod:getLastIndexOf("/", str(?stop))) 41 )) as ?pstop) 42 }

Observe que esta consulta faz um produto cartesiano entre (1) a lista de paradas (?stop) e distâncias entre cada parada e o usuário (?dist), limitando o resultado às três paradas mais próximas (linhas 18-27); e (2) a lista de paradas de rota ?rs2 seguintes (bus:nextStop) à parada de rota de cada ?stop da lista (1) de forma que nome da parada (?stopName) associada a ?rs2 case com o destino desejado do usuário (?uDestName) (linhas 28-34). O produto cartesiano é filtrado para manter apenas distâncias menores que 500 metros (linha 35), o que pode reduzir a quantidade de paradas para dois, um ou até mesmo zero para o usuário em questão. No final da cláusula WHERE é construído um nó para representar a instância da recomendação (BIND, linhas 37-41) cujas triplas são definidas na cláusula CONSTRUCT (linhas 2-10). Esta consulta foi configurada para executar a cada 5 minutos. O módulo B3 reúne as recomendações de B2 e as chegadas de ônibus de B1 e gera possíveis participações app:isPassegerOf de usuários nestas chegadas. A consulta a B1 (Qarrivel2) é apenas um SPARQL DESCRIBE das instâncias de app:BusArrival e dos objetos de suas triplas, enquanto a consulta a B2 (Qrec2) é apenas um DESCRIBE das instâncias de pessoas e recomendações a elas associadas. Qrec2 executa a cada 5 minutos e que Qarrival2 a cada 15 segundos. Ambas são mostradas a seguir: 1 2 3 4 5 6 7 8 9 10 11

# Qarrival2 DESCRIBE ?ev ?o WHERE { ?ev a apv:BusArrival ;

?p ?o . }

# Qrec2 DESCRIBE ?u ?pstop ?o WHERE { ?u a foaf:Person ; app:recommendedBusStop ?pstop . ?pstop ?p ?o . }

A geração das participações é feita com a regra mostrada a seguir. Ela liga eventos app:BusArrival a usuários (?ev e ?u nas linhas 9-10) usando paradas (?stop, linhas 2 e 6) e rotas (?route, linhas 4 e 7) existentes tanto nas recomendações (?b, linhas 5-7) quanto nos eventos (?ev, linhas 1-4).

197

1 (?ev rdf:type apv:BusArrival), 2 (?ev apv:busStop ?stop), 3 (?ev apv:bus ?bus), 4 (?bus bus:route ?route), 5 (?u app:recommendedBusStop ?b), 6 (?b app:stop ?stop), 7 (?b app:route ?route) 8 -> 9 (?u apv:isPassengerOf ?ev), 10 (?u evt:playsRole ?ev)

O módulo NEvt fica no topo de rede pois é responsável por reunir as participações em A1 e B3 e gerar notificações. É composto por quatro consultas a três endpoints: A1, B3 e BLE. Observando a Figura 30 verifica-se que as consultas feitas a A1 e B3 são iguais. Para não tornar as coisas mais complexas, elas pegam o grafo inteiro dos respectivos módulos usando consultas CONSTRUCT. As demais consultas são Qlow e Qhigh que pegam dados de baixa e alta taxa de atualização. Qlow descreve linhas, paradas, rotas e paradas de rotas de BLE, e Qhigh descreve os ônibus. Quantos aos intervalos, Qall de A1 executa a cada 10 minutos, Qall de B3 a cada 10 segundos, Qlow a cada 10 minutos e Qhigh a cada 10 segundos. NEvt também utiliza as regras listadas a seguir. O antecedente de R1 seleciona eventos que não sejam aniversários (linha 3), pessoas que participem destes eventos (linha 4) e data de início destes eventos (linha 5); verifica se esta data de início está no intervalo entre 1 e 180 dias contados da data atual (linha 6) e constrói um nó de notificação (associa um evento a uma pessoa, portanto, o URI da notificação deve considerar ambos). O consequente de R1 instancia o nó (app:Notification na linha 9), define evento associado a esta notificação (linha 10), o seu alvo (linha 11) e quantos dias restam para o evento ocorrer (linha 12). Quanto à linha 6, note que os built-ins curTime, dateDiff, le e ge são usados para representar a expressao "0