módulos de inferência na nuvem de dados ligados

CRISTIANO EXPEDITO RIBEIRO
MÓDULOS DE INFERÊNCIA NA NUVEM DE
DADOS LIGADOS PARA APOIAR O
DESENVOLVIMENTO DE APLICAÇÕES
RIO DE JANEIRO
2012
CRISTIANO EXPEDITO RIBEIRO
Módulos de inferência na nuvem de dados ligados para
apoiar o desenvolvimento de aplicações
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Informática
da Universidade Federal do Rio de Janeiro,
como requisito parcial à obtenção do título de
Mestre em Informática.
Orientadora: Prof.ª Dr.ª Adriana Santarosa Vivacqua
Rio de Janeiro
2012
R484 Ribeiro, Cristiano Expedito
Módulos de inferência na nuvem de dados ligados para apoiar o
desenvolvimento de aplicações. / Cristiano Expedito Ribeiro. – 2012.
203 f.: il.
Dissertação (Mestrado em Informática) – Universidade Federal do
Rio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti,
Programa de Pós-Graduação em Informática.
Orientadora: Adriana Santarosa Vivacqua
1. Módulos de Inferência. 2. Nuvem de Dados. 3. Nuvem para Apoio
e Desenvolvimento de Aplicações – Teses. I. Vivacqua, Adriana
Santarosa (Orient.). II. Universidade Federal do Rio de Janeiro, Instituto
de Matemática, Instituto Tércio Pacitti, Programa de Pós-Graduação em
Informática. III. Título
CDD
Agradecimentos
Agradeço à minha mãe Tania, à minha avó Zenith (in memoriam) e ao meu tio Sérgio
que me estimularam em minha formação acadêmica, e à minha irmã Christina.
À minha orientadora Adriana S. Vivacqua, expresso meu profundo agradecimento por
seu empenho e pelos conselhos nos momentos mais críticos do trabalho.
Aos professores Daniel Schwabe (DI-PUC-Rio) e Maria Luiza Machado Campos
(PPGI-UFRJ) pela gentileza de comporem a banca examinadora e pelas estimadas
contribuições.
Meus agradecimentos especiais aos professores do PPGI, Jonice Oliveira, João Carlos
e Marcos Borges pelas suas colaborações pontuais, mas extremamente úteis nos seminários.
Aos meus colegas e amigos de mestrado e laboratório, Augusto, Biancas Lima e
Pereira, Bruno Nascimento, Diego, Evelyn, Fábio, Fabrício Firmino, Inês Boscá, João Vítor,
Patrícia, Rafael Escalfoni, Rogers Reiche, Ruben Perorazio e Tiago Marino, pelo auxílio,
companheirismo e descontração em diversos momentos desta trajetória, e também aos meus
amigos da graduação, chefes e colegas de trabalho.
Finalmente, deixo meus agradecimentos à Universidade Federal do Rio de Janeiro
(UFRJ) e ao Programa de Pós-Graduação em Informática (PPGI) que me receberam em suas
dependências, e ao CNPq (Conselho Nascional de Desenvolvimento Científico e
Tecnológico) pelo suporte financeiro oferecido para apoiar o desenvolvimento desta
dissertação.
Resumo
RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para
apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em
Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto
Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012.
Computação ubíqua e pervasiva se caracterizam por sistemas computacionais
embarcados no ambiente, capazes de interagir amigavelmente com o usuário, reconhecendo e
se adaptando ao meio. Contudo, para isto se tornar realidade, é necessário entender o contexto
no qual estas interações ocorrem. Alguns middlewares para auxiliar o desenvolvimento de
aplicações cientes de contexto (CC) foram propostos, mas ainda não surgiu um realmente
efetivo quanto à aplicabilidade no mundo real. Além disso, dados de contexto devem ser
representados em um formato reutilizável e interoperável que permita compartilhamento,
comunicação e reuso, pois aplicações CC precisam integrar informações oriundas de sensores
locais e remotos, bases de dados e de contexto. O objetivo deste trabalho é aproveitar
tecnologias padronizadas da Web Semântica e de Linked Open Data (LOD) como formatos,
ontologias e linguagens de consultas para atender estas necessidades. Para tanto, propomos a
arquitetura LOUD e neste trabalho enfocamos o módulo de inferência, capaz de ser
facilmente configurado para consumir, processar e publicar triplas RDF, fazendo consultas a
SPARQL endpoints e gerando seu próprio endpoint com novos dados que são produzidos por
inferência OWL-DL e/ou regras. Estes módulos podem ser organizados hierarquicamente ou
em rede para produzir contextos com níveis mais altos de abstração. Para mostrar a
viabilidade de se produzir aplicações utilizando este módulo, foram implementados três
cenários e, posteriormente, um deles foi levado para experimentos com alunos que
configuraram uma pequena rede de módulos e fizeram uma avaliação através de um
questionário. Os resultados foram satisfatórios, pois apesar de alguns alunos apresentarem
dificuldades, foi relatada que a configuração é simples, detalhada e flexível, a execução é fácil
e consultas são simplificadas para o consumidor final.
Palavras-chaves: Linked Open Data, Web Semântica, contexto, ciência de contexto,
inferência, ontologias
Abstract
RIBEIRO, Cristiano Expedito. Módulos de inferência na nuvem de dados ligados para
apoiar o desenvolvimento de aplicações. 2012. 203 f. Dissertação (Mestrado em
Informática) – Programa de Pós-Graduação em Informática, Instituto de Matemática, Instituto
Tércio Pacitti, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2012.
Ubiquitous and pervasive computing are characterized by computational systems
embedded into the environment, able to interact with the user friendly, recognizing and
adapting to the environment. However, for this to become reality, it is necessary to understand
the context in which these interactions occur. Some middleware to support the development
of context-aware applications (CC) have been proposed, but no one has emerged as really
effective with respect to the applicability in the real world. Moreover, context data should be
represented in a reusable and interoperable format that allows sharing, communication and
reuse as CC applications need to integrate information from local and remote sensors, bases of
data and context. Our objective is to leverage standard technologies of the Semantic Web and
Linked Open Data (LOD) like formats, ontologies and query languages to meet these needs.
To this end, we propose the LOUD architecture and we focus on the inference module, which
is able to be easily configured to consume, process and publish RDF triples, making queries
to SPARQL endpoints and generating its own endpoint with the new data that are produced
by inference using OWL-DL and/or rules. These modules can be organized hierarchically or
as a network to produce contexts with higher levels of abstraction. To show the feasibility of
producing applications using this module, three scenarios were implemented and, later, one
was led to experiments with students who have set up a small network of modules and made
an assessment using a questionnaire. The results were satisfactory, because although some
students had presented difficulties, it was reported that the configuration is simple,
comprehensive and flexible, execution is easy and queries are simplified for the end
consumer.
Keywords: Linked Open Data, Semantic Web, context, context awareness, inference,
ontologies
Lista de Figuras
Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior
uma notação de conjuntos e na inferior as dimensões grau de mobilidade e de
embarcamento em eixos ortogonais. ............................................................................ 21
Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação,
à forma de obtenção, à visibilidade e à taxa de atualização. ......................................... 27
Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅. ........ 46
Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados
inesperados como alterações imprevistas no TBox. ..................................................... 53
Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005). ........................................... 60
Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003) ..................... 61
Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como
produtores e consumidores. Entradas para configuração dos módulos foram
omitidas. ..................................................................................................................... 68
Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação
bidirecional) é representada para fins didáticos, pois a base pode conter triplas
virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a leitura
sobre Jena e Pellet na seção 2.3.2). .............................................................................. 74
Figura 9. Diagrama de atividades do módulo de inferência ................................................... 78
Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente
implementado. ............................................................................................................ 82
Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule. ........... 84
Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe
PullLoader. ................................................................................................................. 85
Figura 13. Hierarquia mais externa dos elementos XML de configuração. ............................ 89
Figura 14. Elementos XML para configuração de carregadores e substituidores de
variáveis (binders)....................................................................................................... 90
Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para
Consultas Espaciais em LOD. ..................................................................................... 93
Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros
vocabulários existentes na nuvem LOD....................................................................... 96
Figura 17. Lista de Resultados na aplicação protótipo desenvolvida. .................................. 101
Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012) ....................... 104
Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda)
usados no endpoint RSE e o mapeamento entre conceitos. ........................................ 107
Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda)
usados no endpoint ULE e o mapeamento entre conceitos ......................................... 108
Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento. ............ 113
Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas. ............... 114
Figura 23. Diagrama das ontologias de tempo e eventos utilizadas. .................................... 119
Figura 24. Diagrama de classes da ontologia de relações entre pessoas. .............................. 120
Figura 25. Diagrama de hierarquia de propriedades da ontologia de relações entre
pessoas...................................................................................................................... 120
Figura 26. Ontologia de transporte por ônibus. ................................................................... 122
Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e
ônibus. ...................................................................................................................... 124
Figura 28. Rede social dos usuários do endpoint USNLE. .................................................. 128
Figura 29. Estrutura interna do endpoint BLE. ................................................................... 130
Figura 30. Rede de módulos de inferência para notificações sobre eventos (números ao
lados de módulos indica quantidade de regras usadas). .............................................. 131
Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações. ......... 132
Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b). .................... 134
Figura 33. Histogramas das respostas globais. .................................................................... 138
Figura 34. Resultados do teste presencial com alunos. ........................................................ 139
Figura 35. Teste remoto com alunos em pesquisa de tese. .................................................. 140
Figura 36. Resultados do teste remoto com alunos da disciplina. ........................................ 141
Figura 37. Mediana das respostas das três primeiras partes do questionário conforme
valores atribuídos a cada resposta (quanto mais próximo do valor máximo
melhor). .................................................................................................................... 142
Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados
(direita) ..................................................................................................................... 170
Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath. .................... 173
Figura 40. Estrutura interna do endpoint BLE .................................................................... 185
Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento
para a ontologia BusOnto. ......................................................................................... 186
Lista de Quadros e Tabelas
Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN,
C., 2004) ..................................................................................................................... 29
Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010) .......................... 32
Quadro 3. Lista de expressividade de diversas DLs atuais. ................................................... 48
Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL
que os aceitam. ........................................................................................................... 55
Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL
que os aceitam ............................................................................................................ 56
Quadro 6. Comparativo das arquiteturas. .............................................................................. 65
Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas. .............................. 87
Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008) ...................................... 104
Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e
tempo (AZEVEDO, 2011) ........................................................................................ 105
Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos .............. 106
Tabela 11. Exemplos de resultados da consulta ao M4: atraso pequeno (acima) e pouco
mais significativo (abaixo). ....................................................................................... 115
Quadro 12. Datas comemorativas utilizadas no endpoint CDE com as respectivas
classes e datas. .......................................................................................................... 126
Quadro 13. Localização atual e destino desejado dos usuários do USNLE. ......................... 128
Quadro 14. Consultas e regras removidas em cada módulo; competências testadas e
grau de dificuldade para cada etapa. .......................................................................... 134
Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em
RAs (2010) ............................................................................................................... 171
Lista de Siglas
API
Application Programming Interface
CBMERJ
Corpo de Bombeiros Militar do Estado do Rio de Janeiro
CC
Ciente de Contexto
CML
Context Modelling Language
DL
Description Logic
ETL
Extraction, Transformation, Loading
FOAF
Friend Of A Friend
GEO-RIO
Fundação Instituto de Geotécnica do Município do Rio de Janeiro
GPS
Global Positioning System
HTTP(S)
Hypertext Transfer Protocol (Secure)
KML
Keyhole Markup Language
LD
Lógica de Descrição
LOD
Linked Open Data / Dados Abertos Ligados
LOV
Linked Open Vocabularies
MVO
Mapeamento Vocabulário-Ontologia
MIO
Mapeamento Inter-Ontologias
N3
Notation 3
OD
Ontologia de Domínio
ORM
Object-Role Modelling
OWL
Web Ontology Language
RA
Região Administrativa
REST
Representational State Transfer
RCC
Region Connection Calculus
RDF
Resource Description Framework
SWRL
Semantic Web Rule Language
UBICOMP
Ubiquitous Computing / computação ubíqua
URI/L
Uniform Resource Identifier/Locator
W3C
World Wide Web Consortium
WGS84
World Geodetic System 1984
WS
Web Semântica
Sumário
1
2
Introdução ..................................................................................................................... 15
1.1
Motivação ............................................................................................................ 15
1.2
Contextualização do Problema ............................................................................. 15
1.3
Problema específico ............................................................................................. 17
1.4
Objetivo ............................................................................................................... 18
1.5
Contribuição ........................................................................................................ 19
1.6
Estrutura da dissertação ........................................................................................ 19
Referencial Teórico ....................................................................................................... 20
2.1
Computação ubíqua e contexto: definições ........................................................... 20
2.2
Aquisição, classificação e modelagem de contexto ............................................... 23
2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores ....... 23
2.2.2 Classificações de contexto ........................................................................ 25
2.2.3 Classificações de aplicações cientes de contexto ....................................... 27
2.2.4 Comparações entre modelos de contexto ................................................... 28
2.2.5 Ontologias de modelagem de contexto ...................................................... 33
2.3
Web Semântica e Dados Ligados ......................................................................... 37
2.3.1 Conceitos básicos ..................................................................................... 38
2.3.2 Lógica de Descrição (DL) ......................................................................... 41
2.3.3 Web Ontology Language (OWL) .............................................................. 53
2.3.4 Trabalhos de publicação em LOD ............................................................. 57
2.4
Trabalhos relacionados......................................................................................... 58
2.4.1 Frameworks para aplicações cientes de contexto ....................................... 58
2.4.2 Arquiteturas para integração de dados na Web .......................................... 65
3
LOUD – Linked Open Ubiquitous Data ........................................................................ 67
3.1
Introdução ............................................................................................................ 67
3.2
Arquitetura LOUD ............................................................................................... 67
3.2.1 Objetivos .................................................................................................. 67
3.2.2 Estrutura ................................................................................................... 67
3.3
Escopo do trabalho: o Módulo de Inferência ........................................................ 73
3.3.1 Estrutura ................................................................................................... 73
3.3.2 Implementação ......................................................................................... 80
3.3.3 Configuração ............................................................................................ 87
4
Cenários de Aplicação ................................................................................................... 92
4.1
Cenário 1: informação sobre hidrantes durante um incêndio ................................. 92
4.1.1 Modelagem e construção da camada de dados ........................................... 93
4.1.2 Camada de inferência para integração das bases ........................................ 96
4.1.3 Aplicação de consumo e considerações ..................................................... 99
4.2
Cenário 2: alertas sobre chuvas e escorregamento de terra .................................. 102
4.2.1 Domínio da aplicação e modelagem ........................................................ 103
4.2.2 Camada de dados e sensoriamento .......................................................... 106
4.2.3 Camada de inferência.............................................................................. 109
4.2.4 Discussão ............................................................................................... 116
4.3
Cenário 3: notificação sobre eventos sociais e chegadas de ônibus ..................... 117
4.3.1 Domínio da aplicação e modelagem ........................................................ 118
4.3.2 Camada de dados e sensoriamento .......................................................... 124
4.3.3 Camada de inferência.............................................................................. 130
4.3.4 Visualização das notificações em navegador Web ................................... 132
5
Experimentos e Resultados.......................................................................................... 133
5.1
Formato do experimento .................................................................................... 133
5.2
Avaliações dos alunos ........................................................................................ 135
5.2.1 Alguns dados quantitativos ..................................................................... 136
5.2.2 Avaliações qualitativas ........................................................................... 143
6
Considerações finais.................................................................................................... 147
6.1
Retrospectiva ..................................................................................................... 147
6.2
Estudo de viabilidade e experimentos realizados ................................................ 148
6.3
Contribuições e aspectos positivos ..................................................................... 150
6.4
Problemas e limitações ....................................................................................... 151
6.5
Trabalhos futuros ............................................................................................... 153
Referências ........................................................................................................................ 155
Apêndices .......................................................................................................................... 165
Apêndice A – Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE) ......... 165
Apêndice B – Cenário 2: implementação da geração de coordenadas e mapeamento D2R
para User Locations Endpoint (ULE) ................................................................................. 167
Apêndice C – Cenário 2: implementação da configuração dos módulos ....................... 174
Apêndice D – Cenário 3: implementação, mapeamento e configuração dos módulos para
Bus Locations Endpoint (BLE) .......................................................................................... 185
Apêndice E – Cenário 3: Configuração dos módulos da camada de inferência ............. 190
Apêndice F – Questionário passado aos alunos e respostas na íntegra .......................... 199
15
1
1.1
Introdução
Motivação
O surgimento de celulares menores, mais leves e baratos vem proporcionando
aumento de acessibilidade e maior facilidade de comunicação. Mais recentemente, a
disseminação de dispositivos móveis que utilizam formas variadas de comunicação sem fio
(Bluetooth e Wi-Fi, por exemplo) e o surgimento dos Smartphones (que permitem expansão
de suas funcionalidades) fornecem grandes oportunidades tanto para usuários quanto para
fabricantes e desenvolvedores. Esta evolução traz novas questões, pois o usuário passa a
requisitar conteúdo (inclusive da Web) que satisfaça suas necessidades momentâneas e de
forma imediata (RICCI, 2011). Nestas circunstâncias, surge a necessidade de um modelo
ciente de contexto (CC) o que remete às ideias de Computação Ubíqua de Mark Weiser
(WEISER, 1991). No entanto, a área de computação ciente de contexto ainda enfrenta grandes
desafios para o desenvolvimento de tais aplicações.
Paralelamente, iniciativas de tornar a Web Semântica (WS) uma realidade vêm
ganhando força (BIZER, 2009), e acredita-se que podem ser de grande utilidade no cenário da
computação ubíqua. A WS tem por objetivo atribuir significado ao conteúdo da Web,
tornando-a manipulável por máquinas. Para isso, usa vocabulários, ontologias e regras que
sigam um padrão de fato (BERNERS-LEE et al., 2001). A adoção destes padrões parece
resolver muitos dos problemas que serão descritos nas próximas seções.
1.2
Contextualização do Problema
Apesar de o desenvolvimento de aplicações CC ser uma área pesquisada há bastante
tempo e várias arquiteturas ou middlewares terem sido propostos para tentar facilitar e agilizar
este processo, nenhuma delas foi efetiva quanto à aplicabilidade no mundo real, necessitando
de mais pesquisas científicas (YU et al., 2010). Além disso, a maioria destas arquiteturas foi
construída para domínios específicos não podendo ser usada de forma corriqueira (HU et al.,
2009). Adicionalmente, a maioria das pesquisas em computação ubíqua tem focado em
ambientes ad hoc com protocolos e infraestruturas proprietárias e serviços CC não costumam
focar na interoperabilidade entre sistemas, dispositivos e serviços (LU et al., 2012).
16
É necessário que dados de contexto sejam representados em um formato sintatica e
semanticamente reutilizável e interoperável para permitir compartilhamento e reuso
(PERTTUNEN et al., 2009). Esta necessidade decorre do fato de que aplicações CC
frequentemente precisam integrar informações oriundas de sensores, bases de dados e fontes
de contextos externos, que ao adotarem variados formatos, protocolos, esquemas, taxonomias
e vocabulários, dificultam a interoperabilidade e, consequentemente, o reaproveitamento
(reutilização) de informações úteis já existentes. Serviços CC geralmente não permitem que
aplicações CC sejam interoperáveis por meio de tais modelos de contextos comuns
(HERVÁS; BRAVO, 2011). Contudo, esta interoperabilidade entre dispositivos e serviços é
um importante e difícil desafio em ambientes pervasivos, incluindo cientes de contexto,
porque dependem de diferentes modelos de interação e informação (BRØNSTED et al.,
2010). Todos estes fatores prejudicam a produtividade destas aplicações.
A interoperabilidade desejada pode ser obtida com tecnologias da Web Semântica
(HERVÁS; BRAVO, 2011). O uso de ontologias para criação de modelos de contexto é
promissor para atender estes requisitos (STRANG; LINNHOFF-POPIEN, C., 2004).
Contudo, até modelos e arquiteturas de contexto baseados em ontologias apresentam
dificuldades em reaproveitá-las para permitir interoperabilidade entre módulos de sistemas
distintos. Cada uma das arquiteturas pesquisadas, como SOCAM (GU et al., 2005), CoBrA
(CHEN, HARRY et al., 2003), iTransIT (LEE; MEIER, 2009) e COSAR (RIBONI;
BETTINI, 2011a), entre outras, utiliza sua própria ontologia e, em geral, não utilizam um
protocolo de comunicação comum. Segundo os autores do CoBrA, a maior deficiência de sua
abordagem é a “inabilidade de reusar outras ontologias consensuais” que “requer maior
sobrecarga no projeto e engenharia
de ontologias”
e que “pode reduzir a
interoperabilidade”.
Mesmo que houvesse uma ontologia unificada para tratamento de contexto ou que
todas as existentes tivessem mapeamento entre si, o modelo ontológico não é eficaz nem
eficiente para todas as necessidades da computação CC (BETTINI et al., 2010). Muitas delas
requerem outras técnicas de inteligência articial ou estatística, inclusive para tratamento de
dados de sensores, que geralmente são incertos, ambíguos e até mesmo conflitantes. Desta
forma, ontologias são geralmente usadas para descoberta de conhecimento implícito em um
nível mais alto e para validação de bases de conhecimento por utilizarem processos mais
formais quanto à semântica. Surge, então, a questão sobre como permitir interoperabilidade
entre estes sistemas heterogêneos, ou seja, com diversos tipos de modelos de contexto.
17
Resumidamente, se for necessário que, ao construir uma aplicação, o projetista crie
seu próprio modelo de contexto, por exemplo, ontologias e regras (pouca reutilização), e/ou o
desenvolvedor precise construir conversores para comunicação e interoperabilidade com
módulos externos (que utilizem modelos de contexto ontológicos ou não) há um prejuízo à
produtividade. Além do mais, mesmo adotando padrões da WS, as bases de dados e fontes de
contexto podem utilizar vocabulários e ontologias distintos que podem ainda prejudicar a
interoperabilidade se não houver uma forma padronizada de comunicação e de mapeamento
entre seus elementos.
Portanto, faz-se necessário a criação de uma arquitetura distribuída na Web que
forneça mecanismos de comunicação entre diversas fontes de dados e de inclusão de regras
tanto para mapeamento de conceitos quanto para inferência de contexto. Estes mecanismos
precisam ser interoperáveis e reutilizáveis para proporcionar melhoras na produtividade no
desenvolvimento de aplicações CC. Assim, o problema geral concentra-se em três conceitos
interligados: interoperabilidade, reutilização e produtividade.
1.3
Problema específico
Neste trabalho, pretende-se tratar tanto a interoperabilidade entre bases que provêem
dados contextuais, quanto reutilização de suas ontologias, regras de inferência e dados. Como
discutido na seção anterior, usar padrões e princípios da WS parece ser uma possível solução
por diversos motivos. A possibilidade de criação de ligações entre recursos Web de diferentes
bases de dados vista na iniciativa de Linked Data (LOD1) parece viabilizar parte da
interoperabilidade entre bases de dados contextuais, pois estabelecem mapeamentos entre tais
dados. A padronização de formato (triplas RDF) e linguagem de consulta (SPARQL)
estabelecida pela W3C parece viabilizar tanto interoperabilidade quanto reutilização, tanto de
fontes de dados estáticos (que não mudam com freqüência) quanto de sensores físicos. A
padronização de linguagens para representação de ontologias na Web (OWL) e para criação
de regras definidas pelo usuário (como SWRL) também parece viabilizar a reutilização de
modelos de contexto (taxonomias, ontologias e inferências).
No entanto, o uso de LOD traz diversos desafios que devem ser pesquisados. Um deles
é determinar quais bases e ligações são úteis e/ou confiáveis para serem utilizadas. Outro
desafio reside na disponibilização de dados de sensores físicos para acesso via SPARQL
1
Será utilizada a sigla LOD, mesmo para bases não abertas, para evitar confusão com lógica descritiva (LD).
18
endpoints. Isso vai desde a obtenção dos dados não-tratados de sensores físicos (termômetros,
GPS, pluviômetros, etc.) e a forma de atualização do SPARQL endpoint quando ocorre
alguma atualização, até fusão e agregação destes dados. Este último pode necessitar de
diversas técnicas de tratamento de dados incertos (lógica Fuzzy, redes bayesianas, Hidden
Markov Models, etc.). Nenhum destes desafios será pesquisado aqui.
O problema específico a ser tratado neste trabalho está relacionado a propor e testar
um módulo que permita inferências, incuindo de contexto, usando OWL-DL, que provê
construtos de lógica descritiva, e regras definidas pelo usuário. Este módulo pode ser
classificado como um sensor lógico ou interpretador de contexto segundo a literatura CC ou
como um dataset de dados derivados segundo os conceitos de LOD. Além de efetuar
inferência, é necessário que tais dados sejam disponibilizados na nuvem LOD, em um formato
comum que permita interoperabilidade para serem usados por diversas aplicações (CC ou
não) e até mesmo por outros módulos. Por fim, o framework precisa ser configurado
facilmente, desde que o domínio já tenha sido previamente definido. Assim, o problema é
enunciado da seguinte forma:
“Necessidade de um ferramental configurável, capaz de realizar
inferências, incluindo contexto, usando formatos de dados interoperáveis, e
também de disponibilizar seus dados para consumo seguindo princípios da Web
Semântica.”
1.4
Objetivo
Este trabalho tem por objetivo apresentar a arquitetura, a implementação e validação
do Módulo de Inferência proposto como parte de um framework mais geral, que se propõe a
ser um módulo facilmente configurável que permita inferência de contextos em níveis, do
mais geral ao mais específico. Contudo, esta pesquisa se limita a inferências usando o padrão
OWL 2 DL (Web Ontology Language 2 Description Logic) do W3C e regras IF-THEN sobre
instâncias de uma base. Portanto, não está no escopo qualquer outro método como Lógica
Fuzzy ou de Primeira Ordem, Redes Bayesianas, etc.
A etapa de validação compreenderá a descrição de alguns cenários onde dados
contextualizados são necessários e a explicação das etapas necessárias (modelagem do
domínio, construção da ontologia OWL, regras e consultas) para se chegar a uma base que
19
possa ser consultada diretamente por uma suposta aplicação. Por fim, acredita-se que, no
futuro, tais módulos poderiam ser disponibilizados na Web com diferentes tipos de
informações para que desenvolvedores de aplicações pudessem consumir seus dados.
1.5
Contribuição
A principal contribuição deste trabalho é um framework facilmente configurável para
auxiliar a construção da parte inteligente de aplicações cientes de contexto (inferência de
contexto e geração de notificações e/ou ações) utilizando formatos e padrões abertos da Web
Semântica. O uso destas tecnologias mostra que o framework também é útil para aplicações
genéricas para Web Semântica que necessitem de inferência com ontologias OWL e regras.
O framework mostra habilidade em fazer inferência modularizada e distribuída na
Web, ou seja, dividir o processamento de ontologias e regras em módulos distintos que podem
executar em máquinas distintas para posterior integração. Para mostrar a viabilidade três
cenários foram propostos e implementados. A facilidade de configuração proporcionada pelo
framework permite que pessoas sem grandes conhecimentos de linguagens de programação
possam configurar o módulo e disponibilizar seus dados na Web rapidamente. O framework
reduz a necessidade de programação, mas não substitui as necessidades de conhecimento do
domínio, levantamento de requisitos e modelagem como em qualquer desenvolvimento de
aplicações.
1.6
Estrutura da dissertação
Este trabalho é dividido em outros cinco capítulos. O capítulo 2 apresenta o referencial
teórico sobre contexto, web semântica e alguns trabalhos relacionados. O capítulo 3 descreve
uma arquitetura geral em camadas sugerida para o problema descrito na seção 1.2 e depois
aprofunda a discussão para uma parte da arquitetura denominada Módulo de Inferência que
visa abordar o problema específico da seção 1.3. O capítulo 4 mostra cenários de aplicação e
as respectivas provas de conceito através de implementações utilizando o módulo sugerido,
mostrando que é factível. O capítulo 5 apresenta um experimento feito com alunos de
mestrado e seus resultados a fim de verificar o grau de dificuldade em se entender e
configurar módulos para uma das aplicações do capítulo 4. Por fim, o capítulo 6 destaca
análises críticas quanto às contribuições, limitações e oportunidades futuras.
20
2
Referencial Teórico
A área de computação ubíqua (UBICOMP) e pervasiva está cada vez mais relacionada
à Web, pois à medida que esta se torna cada vez mais presente na vida das pessoas, mais útil
ela demonstra ser como um ferramenta para tarefas cruciais da computação ubíqua e
pervasiva. Este capítulo apresentará conceitos de computação ubíqua, pervasiva e ciente de
contexto, e Web Semântica (WS), e como esta tem sido empregada nessas áreas. Como é cada
vez mais difícil falar de UBICOMP sem falar das tecnologias da WS, e uma ordem deve ser
seguida, decidiu-se por falar primeiramente de UBICOMP (seções 2.1 e 2.2) reduzindo ao
máximo o uso de termos técnicos da WS, para depois introduzir conceitos de WS (seção 2.3).
A priori, caso o leitor não esteja familiarizado com WS, tenha em mente a seguinte
analogia entre WS, grafos, linguagens de programação e bancos de dados relacionais: RDF é
uma representação de informação usando nós e arestas, onde um nó pode ser um URI ou um
valor literal (número, texto, data). Um URI possui a forma de um endereço na Internet e é
equivalente à chave primária, identificando, portanto, um registro de tabela. Um literal
equivale a um campo de tabela que não seja chave estrangeira. Um URI, por ser um
identificador, pode representar um nó não literal ou um tipo de aresta. RDFS e OWL
representam ontologias sendo semelhante ao esquema do banco, ou seja, definem as relações
e restrições permitidas entre nós. Regras assemelham-se ao comando IF..THEN ou triggers, e
também permitem chamada de funções. Por fim, SPARQL é análogo à linguagem SQL.
2.1
Computação ubíqua e contexto: definições
Em 1991, Mark Weiser lança os princípios da Computação Ubíqua, onde introduz o
termo computação invisível (WEISER, 1991). Segundo ele, “As mais profundas tecnologias
são aquelas que desaparecem”. Sua proposta não era de eliminar ou ocultar máquinas, mas
de proporcionar interações mais amigáveis, tirando o foco de atenção das máquinas e
direcionando para as tarefas dos usuários.
Embora ainda não exista um consenso, os conceitos computação ubíqua e computação
“pervasiva” não serão, apesar de parecidos, considerados sinônimos neste trabalho. A palavra
“ubíquo” significa, segundo o dicionário Aurélio, “que está ao mesmo tempo em todo lugar”,
enquanto que a palavra “pervasive” vem do inglês, não existindo na língua portuguesa, e
21
significa difundido, embarcado ou penetrante. Segundo (ARAUJO, 2003) a computação
ubíqua é construída pela união das capacidades da computação pervasiva e móvel. Segundo
ela, na computação pervasiva “(...) o computador está embarcado no ambiente de forma
invisível para o usuário”. Ela diz também que:
“(...) o computador tem a capacidade de obter informação do ambiente
(...) e utilizá-la para (...) controlar, configurar e ajustar a aplicação para melhor
atender as necessidades do dispositivo ou usuário.”
No que se refere à computação ubíqua, ela afirma que:
“a computação ubíqua beneficia-se dos avanços da computação móvel e
da computação pervasiva” e “a justificativa de (...) diferenciação desses termos é
que um dispositivo que está embutido em um ambiente, não necessariamente é
móvel”.
Desta forma, estes três conceitos além do conceito de computação tradicional podem
ser simplificadamente ilustrados conforme a Figura 1 a seguir (LYYTTINEN; YOO, 2002):
Computação
Pervasiva
Computação
Ubíqua
Computação
Móvel
Alto grau de
“embarcamento”
Computação
Pervasiva
Computação
Ubíqua
Mobilidade baixa
Mobilidade alta
Computação Pessoal
tradicional
Computação
Móvel
Baixo grau de
“embarcamento”
Figura 1. Diferenças entre computação pervasiva, móvel e ubíqua. Na figura superior uma notação de conjuntos e na
inferior as dimensões grau de mobilidade e de embarcamento em eixos ortogonais.
Contudo, para caminhar na direção da computação ubíqua, é necessário entender e
conhecer o contexto no qual as interações ocorrem. Schilit et al. (SCHILIT et al., 1994) foram
os primeiros a usar o conceito de contexto e aplicações cientes de contexto na computação.
Em seu trabalho, definiram softwares cientes de contexto (CC) como aqueles capazes de
22
“adaptar-se à localização de uso, ao conjunto de pessoas e dispositivos próximos, assim
como, às mudanças destes ao longo do tempo”. Menciona também o que chamou de aspectos
de contexto como “where you are, who you are with and what resources are nearby”. Além
disso, categorizou aplicações CC como uma combinação de duas dimensões. A primeira delas
divide a tarefa em obtenção de informações ou execução de um comando. A segunda
determina se a tarefa é realizada manual ou automaticamente.
Dey e Abowd (DEY, A. K.; ABOWD, 1999) relatam que contexto foi definido usando
sinônimos, como por exemplo ambiente ou situação do usuário ou da aplicação, o estado das
coisas em torno da aplicação. Também relatam definições usando exemplos (localização, data
e hora, temperatura, nível de ruído, etc.) que são incompletas, pois é difícil aplicá-las diante
de novas informações. Devido a essas definições abstratas e/ou incompletas, eles definiram os
conceitos de contexto, ciência de contexto e aplicações cientes de contexto:
"contexto é qualquer informação que pode ser usada para caracterizar a
situação de uma entidade. Entidade é uma pessoa, lugar ou objeto que é
considerado relevante para a interação entre um usuário e uma aplicação,
incluindo usuário e a aplicação."
“um sistema é ciente de contexto se ele usa contexto para prover
informações relevantes e/ou serviços ao usuário, onde relevância depende da
tarefa do usuário.”
(DEY, A. K.; ABOWD, 1999)
Mais tarde, Becker e Nicklas (BECKER; NICKLAS, 2004) refinam as definições de
Dey e Abowd adicionando o termo adaptação e substituindo os termos interação com usuário
e serviços para o usuário por comportamento:
“contexto é a informação que pode ser usada para caracterizar a situação
de uma entidade. Entidades são pessoas, locais, ou objetos considerados
relevantes para o comportamento de uma aplicação. A própria entidade é
considerada como parte de seu contexto.”
“uma aplicação é ciente de contexto se ela adapta seu comportamento
conforme o contexto.”
(BECKER; NICKLAS, 2004)
Uma outra definição recente encontrada na literatura para ciência de contexto é dada
por Naudet:
“ciência de contexto é a habilidade de um sistema, conhecendo seu estado
e seu ambiente, sentir, interpretar e reagir a mudanças em seu estado ou no
ambiente em que está situado.”
(NAUDET, 2011)
23
Note-se que esta última definição usa os termos estado e ambiente, onde tanto estado
quanto ambiente dizem respeito às configurações num determinado momento, contudo a
primeira refere-se ao próprio sistema e o segundo ao que o rodeia (estado externo). Esta
definição também destaca a habilidade de sentir ou reconhecer o seu estado e o ambiente, a
interpretação da nova configuração e a reação à esta mudança.
2.2
Aquisição, classificação e modelagem de contexto
Além das definições de contexto apresentadas na seção anterior, vários outros aspectos
devem ser considerados. Esta seção abordará a aquisição de contexto (sensores, entradas do
usuário e interpretadores), classificações de contexto e de aplicações cientes de contexto
existentes na literatura e, por fim, modelagem de contexto.
2.2.1 Aquisição de contexto: perfis, sensores, interpretadores e provedores
A obtenção de dados de contexto é feita por meio dos chamados sensores. Indulska e
Sutton (INDULSKA, JADWIGA; SUTTON, 2003) definem o termo sensor como “um
sistema que provê informação” e Baldauf et al. (BALDAUF et al., 2007) dizem que sensor
“não se refere apenas a hardware, mas também a toda fonte de dados que possa prover
informação de contexto utilizável”. Segundo ambos os trabalhos, sensores podem ser
classificados, conforme sua natureza, em físicos, virtuais e lógicos:
sensores físicos são aqueles baseados em hardwares capazes de capturar diversas
propriedades físicas do ambiente como temperatura, aceleração, luminosidade,
áudio, posição geográfica, data e hora, entre outros;
sensores virtuais são aqueles que utilizam softwares ou serviços para fornecer
informação de contexto, como por exemplo, obter localização do usuário a partir
de sua agenda ou sistema de reservas de viagens; ou obter atividade do usuário a
partir da movimentação do mouse, entradas de teclado ou modificações no
sistema de arquivos do computador;
sensores lógicos também são baseados em softwares mas descobrem contextos de
mais alto nível a partir de inferências sobre contextos oriundos de sensores físicos
ou virtuais e também de bases de dados. Por exemplo, descobrir que o usuário está
em show de rock usando microfone, posição geográfica, a data e agenda.
24
Du & Wang (DU; WANG, L., 2008) utilizam ainda os termos sensor de hardware e
sensor de software e os termos sensor local e sensor remoto. Os dois primeiros são
autoexplicativos e os dois últimos são explicados a seguir:
Sensores locais são sensores físicos localizados na mesma máquina ou dispositivo
do usuário e cuja comunicação com aplicações é feita via chamadas ao sistema
operacional ou através de uma API (ex. o microfone de um smartphone).
Sensores remotos são aqueles externos ao dispositivo e que se comunicam com a
aplicação por meio do protocolo IP, podendo até mesmo ser organizados numa
rede de sensores. Um exemplo simples é um termômetro que mede a temperatura
da casa do usuário enquanto ele está no trabalho e se comunica com seu
Smartphone via Internet.
Uma questão que pode ser feita é o que Du & Wang quiseram dizer com sensor físico,
visto que sensores virtuais e lógicos também podem estar localizados no dispositivo do
usuário e até mesmo utilizar chamadas nativas. Sendo assim, eles não seriam nem locais nem
remotos. Outro trabalho mais recente de Bettini et al. (BETTINI et al., 2010) nem chega a
citar classificações, dizendo que “algumas informações de contextos são sentidas” e que
“sensores podem observar certos estados do mundo físico e prover acesso rápido quase em
tempo real”. As expressões “estados do mundo físico” e “quase em tempo real” parecem
representar apenas sensores físicos visto que sensores virtuais podem capturar dados de
agenda (mundo não físico) e sensores lógicos podem precisar de bastante tempo de
processamento (tempo não real). Mas Baldauf et al. diz que sensor não é apenas hardware
(sensor físico) mas qualquer fonte de dados que possa prover contexto. Sendo assim, um
simples sistema que armazena o perfil do usuário seria um sensor para Baldauf et al. e não
seria para Bettini et al.. Pode-se também considerar que Bettini et al. usaram o verbo
“podem” para não se comprometer, mas este parece não ser o caso pois na sequência eles
falam sobre dados inseridos pelo usuário sem qualquer relação com o termo sensor.
Estas discussões mostram que estes conceitos ainda não estão claramente definidos na
literatura e, como este trabalho não pretende discutí-los nem utilizá-los, decidiu-se por utilizar
conceitos mais simples. Assim, o termo sensor físico será usado para fontes que fornecem
características físicas do ambiente. O termo sensor virtual não será utilizado por se considerar
que estão numa região indefinida entre os físicos e lógicos. Para o conceito de sensor lógico
será usado o termo interpretador de contexto, retirado do trabalho de Gu et al. (GU et al.,
2005). Para fontes de dados pessoais inseridos diretamente pelo usuário será utilizado o termo
25
perfil de usuário. O termo bases de dados será utilizado para fontes de dados não associados a
uma entidade específica, mas que podem vir a se tornar contexto após processamento por
parte de interpretadores de contexto. Finalmente, o termo provedor de contexto, será utilizado
como um termo genérico para sensores físicos, perfis, bases de dados e interpretadores de
contexto, diferentemente da classificação de Gu et al.
2.2.2 Classificações de contexto
Dey e Abowd (DEY, A. K.; ABOWD, 1999) dividiram contexto em dois tipos:
primário e secundário. O contexto primário é divido em:
localização – responde onde (where) uma entidade está;
identidade – responde quem (who) é a entidade;
tempo – responde quando (when).
atividade – responde o que está ocorrendo ou o que o usuário está fazendo (what);
Atividade e tempo não foram consideradas por Schilit et al. (SCHILIT et al., 1994),
além disso, Ryan et al. (RYAN et al., 1998) tinham chamado atividade de ‘ambiente’, mas
por considerar um sinônimo de contexto Dey modificou para atividade. Já o contexto
secundário seria qualquer outro derivado destes, como por exemplo, previsão do tempo a
partir de localização e data ou endereço a partir da identidade da entidade.
O trabalho de Gu et al. (GU et al., 2005) apresenta uma divisão de contexto conforme
a forma de obtenção do contexto em:
contexto direto – que são obtidos diretamente do que ele designou provedores de
contexto e que podem ser ainda divididos em sensed e defined;
contexto indireto – onde são usados interpretadores de contextos que se
aproveitam de contextos já conhecidos para inferir novos. Também descrito como
deduced context.
Assim, os sensed contexts seriam obtidos de sensores físicos; os defined contexts
seriam aqueles fornecidos diretamente pelo usuário via formulários e praticamente constantes
(perfis do usuário; ex. preferências pessoais) e os deduced contexts seriam obtidos de
interpretadores de contexto. Henricksen et al. (HENRICKSEN, K. et al., 2004) apresenta
denominações semelhantes: sensed, derived (=deduced), profiled (=defined) e static
(semelhante ao defined mas de caráter impessoal). Esta classificação de Henricksen et al. é
interessante pois separa informações de contexto provenientes de bases de dados em duas
26
partes: uma fornecida pelo usuário representando suas informações pessoais (profiled
contexts) e outra fornecida por especialistas ou até mesmo usuários, mas representando
informações de caráter coletivo ou impessoal (static contexts).
Note que a divisão entre contexto primário e secundário é diferente da divisão entre
contexto direto e indireto, pois a primeira se refere ao tipo da informação de contexto e, a
segunda, à sua forma de obtenção. Como exemplo, considere que localização é sempre um
contexto primário, mas pode ser direto no caso de coordenadas geográficas obtidas de um
GPS, ou indireto no caso de lugares (ex. escola, praia) descobertos a partir de uma agenda ou
de geocode reverso (endereço a partir de coordenadas). Korpipaa et al. (KORPIPAA et al.,
2003) mencionam dois bons exemplos de contextos indiretos inferidos usando redes
bayesianas. Um destes exemplos é descobrir se usuário está dentro de um local fechado ou em
um local aberto utilizando intensidades sonora e luminosa, temperatura e posição do
dispositivo móvel. Outro exemplo dado em seu trabalho é utilizar vários dados de áudio para
determinar o tipo de som do ambiente (carro, elevador, conversa, música, entre outros).
Existem diversas outras classificações. Por exemplo, contextos podem ser públicos,
quando podem ser facilmente obtidos por qualquer pessoa (ex. tempo, guia de ruas, pontos de
interesse) ou privados, quando requerem proteção (ex. localização e preferências do usuário);
ou podem ter frequências de atualização alta (ex. sensores físicos), média (ex. aqueles
modificados por humanos como eventos sociais e culturais) ou baixa (ex. preferências
pessoais). A Figura 2 esquematiza estas divisões de contexto e associa aos provedores de
contexto (sensores, interpretadores, etc.) quando aplicável, porém não há qualquer intenção de
exaurir todas as possíveis classificações existentes na literatura.
Note ainda que a classificação de Dey não foi associada a fontes de contextos visto
que isso não possui uma regra. Por exemplo, a localização pode ser representada por
coordenadas geográficas obtidas de um GPS (sensor físico) ou ser uma informação de alto
nível, como universidade ou show de rock, inferida por um interpretador de contexto. Por fim,
relembre que este trabalho não utilizará os termos sensor virtual e lógico para fontes de
contexto, mas sim os termos sensor físico, perfil de usuário, base de dados e interpretador de
contexto.
27
Primário
Localização, Identidade,
Atividade, Tempo
Secundário
Obtidos dos primários
Direto
Sensed (sensores físicos)
Defined (definido pelo usuário)
Indireto
Deduced (interpretadores de contexto)
Pública
Obtido por qualquer pessoa
Privada
Necessário permissão para acessar
Alta
Fornecido por sensores
Média
Fornecido por humanos
Baixa
Perfis, mapas e guias
Tipo
Obtenção
Contexto
Visibilidade
Taxa de atualização
Figura 2. Esquematização das classificações de contexto: quanto ao tipo da informação, à forma de obtenção, à
visibilidade e à taxa de atualização.
2.2.3 Classificações de aplicações cientes de contexto
Em relação às aplicações cientes de contexto, Dey e Abowd (DEY, A. K.; ABOWD,
1999) classificaram-nas em três tipos:
Apresentação de informações e serviços ao usuário
Execução automática de serviços
Marcação de contexto à informação para recuperação posterior
Segundo Becker e Nicklas (BECKER; NICKLAS, 2004), o primeiro tipo
(apresentação) representa, na verdade, dois tipos: seleção e apresentação. O primeiro ocorre
quando uma aplicação escolhe uma informação ou serviço baseado no contexto. O segundo
relaciona-se à forma como algo é apresentado ao usuário dependendo do contexto como, por
exemplo, uma notificação motora e visual no cinema e notificação sonora quando usuário
estiver dirigindo. As demais classificações são equivalentes. A execução de Dey e Abowd é
denominada ação por Becker e Nicklas, mas ambas representam a execução automática de
algum serviço como, por exemplo, reservar um livro na biblioteca ou comprar um numa
livraria. Por último, a marcação inclui aplicações que apenas retem uma informação para que
o usuário recupere posteriormente como, por exemplo, anotar nome da livraria, local e preço
do livro para que o usuário consulte posteriormente e decida o que fazer.
28
Para Chen (CHEN, H. L., 2004) as aplicações podem ser classificadas ainda conforme
sua arquitetura de aquisição de contexto em três formas:
acesso direto aos sensores – a aplicação cliente obtém os dados dos sensores
diretamente, sem qualquer camada de abstração o que torna difícil o uso perante
grande concorrência de acesso ou uma vastidão de diferentes tipos de sensores.
infra-estrutura de middleware – usa uma camada de abstração que permite
extensibilidade e simplifica a reusabilidade, no entanto, consome mais recursos de
processamento que podem levar a uma redução de desempenho em dispositivos
menos potentes como smartphones.
servidor de contexto – utiliza uma máquina rica em recursos computacionais
responsável por obter dados dos sensores e disponibilizá-los de forma distribuída.
Note que cada um dos métodos pode ser aplicado dependendo das características dos
sensores e da aplicação. Por exemplo, se ambos estão em um único dispositivo móvel, não é
necessário um servidor de contexto, mas se a aplicação está num smartphone e obtém dados
de uma rede de sensores o servidor de contexto é de grande utilidade.
2.2.4 Comparações entre modelos de contexto
Diversas abordagens para modelagem de contexto, ou seja, formas de representação
que permitam processamento por máquinas já foram utilizadas (POSLAD, 2009; STRANG;
LINNHOFF-POPIEN, C., 2004). As abordagens mais antigas não eram genéricas, ou seja,
eram específicas para o domínio da aplicação sendo desenvolvida; enquanto que abordagens
seguintes, apesar de não serem tão atreladas à aplicação, ainda eram limitadas
(STRIMPAKOU, M. A. et al., 2006). Estes modelos englobam desde o simples modelo
chave-valor até ontologias, passando por modelos hierárquicos (SGML e XML), modelos
gráficos (UML e ORM), orientação a objetos e lógica. Strang e Linnhoff-Popien (STRANG;
LINNHOFF-POPIEN, C., 2004) fizeram uma comparação entre estes modelos avaliando-os
conforme os seguintes requisitos:
Composição distribuída (dc) – capacidade de lidar com o dinamismo requerido
pela computação ubíqua por meio de uso móvel e distribuído.
Validação parcial (pv) – capacidade de descobrir erros e inconsistências na
estrutura do modelo e nas suas instâncias.
29
Riqueza e qualidade da informação (qua) – dados oriundos de sensores podem
apresentar variações conforme o tipo e o fabricante do sensor e até mesmo durante
o funcionamento do mesmo sensor. Portanto, tal modelo deveria suportar tais
informações.
Incompletude e ambiguidade (inc) – o conjunto de informações de contexto que
caracterizam uma entidade em algum momento pode ser ambíguo e/ou
incompletas, inclusive quando provêm de uma rede de sensores. Portanto,
mecanismos para filtrar e tratar estes dados são desejados.
Nível de formalidade (for) – é importante que o modelo de contexto permita
compartilhar a mesma interpretação dos dados e significados entre os agentes
envolvidos (shared understanding).
Aplicabilidade a ambientes já existentes (app) – é importante que um modelo de
contexto seja factível, ou seja, sua implementação seja possível usando
infraestruturas existentes.
Dentre estes modelos, as ontologias foram consideradas as mais adequadas aos
requisitos da computação ubíqua, conforme pode ser observado no Quadro 1.
Quadro 1. Comparação entre modelos de contexto (STRANG; LINNHOFF-POPIEN, C., 2004)
Abordagem/requisitos
dc
pv
qua
inc
for
app
Modelos chave-valor
-
-
--
-- --
Modelos de marcação (XML)
+
++
-
-
+
++
Modelos gráficos
--
-
+
-
+
+
Modelos orientados a objetos
++
+
+
+
+
+
Modelos baseados em lógica
++
-
-
-
++
--
Modelos baseados em ontologia
++ ++
+
+
++
+
+
Mas tarde, Bettini et al. (BETTINI et al., 2010) fizeram uma comparação entre o
modelo ontológico e outros dois modelos não discutidos pelo trabalho anterior. Este trabalho
mais recente estabeleceu os seguintes requisitos que modelos de contexto devem viabilizar:
Heterogeneidade – ser capazes de lidar com uma grande variedade de fontes de
contexto (sensores físicos, contextos derivados de informações de contexto já
existentes, bases de dados).
30
Mobilidade – ser capazes de se adaptar a mudanças frequentes de ambiente seja
por parte de sensores que se movimentem seja por parte de aplicações que
executem em dispositivos móveis.
Relacionamentos e dependências – expressar variados tipos de relações entre
informações de contexto, incluse dependências onde uma mudança em uma
propriedade pode afetar outras.
Temporalidade – permitir que aplicações acessem estados passados e até mesmo
futuros (previsões); além disso, quando as atualizações tiverem frequência alta a
ponto de não poderem ser armazenadas individualmente é necessário que haja
possibilidade de se sumarizar tais informações.
Imperfeição – dados de sensores possuem qualidade muito variável, podendo se
tornar rapidamente obsoletos ou fornecer medidas conflitantes ou até mesmo
incorretas; assim, é necessário que modelos de contexto sejam capazes de
expressar a qualidade destes dados.
Raciocínio – muitas vezes é necessário que aplicações utilizem técnicas de
inferência para tomar certas decisões de adaptação a mudanças; além disso, é
preciso que haja checagem de consistência do modelo de contexto e que isso seja
computacionalmente eficiente.
Usabilidade – modelos de contexto devem apresentar facilidade para que
modeladores consigam traduzir conceitos do mundo real para seus construtos e
aplicações possam utilizar manipular estas informações.
Eficiência – deve permitir acesso eficiente às informações de contexto, mesmo
diante de modelos enormes e muitos objetos; para isso, deve haver índices e
caminhos de acesso que permitam a recuperação eficiente destes dados.
O primeiro modelo avaliado é chamado Object-role Model, que utiliza Context
Modeling Language (CML), uma linguagem com notação gráfica para apoiar análise e
especificação de requisitos de contexto utilizando fatos e relações (HENRICKSEN, K;
INDULSKA, J, 2004, 2006). CML é uma extensão do Object-Role Modelling (ORM) para
modelagem conceitual de bancos de dados (HALPIN, 2001). Construiu-se um procedimento
denominado Rmap para mapear CML para um esquema de banco de dados relacional
(HENRICKSEN, K, 2003). CML é capaz de representar contextos estáticos, sentidos,
fornecidos via perfil de usuário, derivados, assim como temporalidade e ambiguidade. Este
último é realizado usando os chamados fatos alternativos e uma lógica trivalorada
31
(verdadeiro, falso e possivelmente verdadeiro) de maneira que, se uma propriedade de um
indivíduo possui mais de um valor, ao se perguntar sobre a veracidade de apenas um destes
valores a resposta é possivelmente verdadeiro, visto que não se pode determinar se apenas
uma ou ambas as respostas são verdadeiras (por exemplo, valores sobre localização do
usuário podem ser equivalentes como casa e cozinha ou conflitantes como casa e
supermecado). Contudo, CML não permite representação de hierarquia, todos os tipos de
contexto são fatos atômicos e não suporta interoperabilidade.
Modelos espaciais se baseiam no fato de que muitas interações requerem alguma
proximidade espacial que pode ser física ou virtual. Proximidade física pode ser representada
por coordenadas geométricas ou simbólicas. A primeira representa pontos e áreas em sistemas
métricos como o datum WGS84 (DECKER, B. L., 1984) utilizado por GPS e permite cálculo
de distâncias e sobreposição numericamente. Coordenadas simbólicas usa identificadores para
pontos e regiões e conceitos como sobreposição, tangenciamento, inclusão, etc. para
relacioná-los, sendo conhecido como Region Connection Calculus (RCC) (RANDELL et al.,
1992). Proximidade virtual representa informação de contexto não física, ou seja, associa
localização a objetos virtuais que não estão presentes no mundo real, exemplo pode ser visto
em (LEONHARDI et al., 1999). Inferências permitidas por estes modelos dizem respeito às
relações espaciais entre objetos que permitem consultas relativas à posição de um objeto,
objetos dentro de uma área e objetos próximos a um objeto, portanto, sua indicação é limitada
a aplicações baseadas em localização ou que permitam tal analogia. Um problema deste
modelo é o esforço necessário para obter dados de localização da informação de contexto e
mantê-los atualizados (BETTINI et al., 2010).
Modelos baseados em ontologias usam lógica de descrição (DL) que tenta
contrabalançar expressividade da linguagem e complexidade da inferência usando ferramentas
automatizadas. Bettini et al. diz que ao usar esta teoria, a linguagem OWL-DL permite (a)
expressar dados de contexto complexos não representados por outros modelos; (b)
compartilhar e/ou integrar contextos de diferentes fontes devido à sua alta formalidade
semântica (interoperabilidade e heterogeneidade); (c) checar consistência da base e descobrir
contextos implícitos. Apesar de modelos espaciais serem os mais indicados para dados
geográficos, o modelo ontológico também pode tratar tal informação usando RCC (HAAV et
al., 2009). Bettini et al. mostram ainda a falta de construtos para fazer composição de
relações, que, foi adicionado na OWL 2. Eles também destacam que, apesar de OWL-DL ser
decidível, a inferência é computacionalmente custosa para ser feita em tempo real e não
32
escalável para grandes quantidades indivíduos, além disso, a adição de regras pode torná-la
indecidível. Adicionalmente, eles comentam que existe pouco suporte para tratar
temporalidade. Realmente, não há suporte direto para dados temporais, contudo há
abordagens sobre isso na literatura. Batsakis & Petrakis (BATSAKIS; PETRAKIS, 2010), por
exemplo, apresentam uma extensão OWL e SPARQL para representar tanto dados temporais,
usando as relações temporais de Allen (ALLEN, 1984), quanto RCC. O Quadro 2 resume as
conclusões de Bettini et al. quanto aos modelos e requisitos, de modo que os sinais “+” e “–”
representam, respectivamente, cumprimento ou não do requisito enquanto “~” representa
cumprimento parcial do requisito.
Mobilidade
Relacionamentos
Temporalidade
Imperfeição
Raciocínio
Usabilidade
Eficiência
~
~
+
~
~
+
~
Espacial
~
+
~
+
~
-
~
+
Ontológico
+
-
+
-
-
+
~
-
requisitos
+
e
Object-role
Abordagens
Heterogeneidade
Quadro 2. Comparação entre modelos de contexto (BETTINI et al., 2010)
Devido ao fato de todos os modelos apresentarem fraquezas, Bettini et al. sugerem um
modelo híbrido em três camadas que deve ser o futuro dos middlewares cientes de contexto.
A primeira captura e funde dados de sensores, a segunda efetua integração de dados de
diversas fontes (sensores da primeira camada, bases relacionais ou de triplas) e inferência com
vocabulários simples podendo tratar dados incertos, ambíguos e, inclusive, conflitantes. A
terceira camada usaria inferência com ontologias para checagem de consistência em um nível
mais alto de abstração. Aplicações se comunicariam apenas com a segunda camada que seria
responsável por se comunicar com as duas outras camadas. Neste trabalho apenas ontologias
com regras serão utilizadas, mas devido ao carater distribuído da arquitetura proposta tal
modelo híbrido pode ser concretizado em abordagens futuras. Além disso, este trabalho visa
mostrar que estas camadas podem ser formadas por pequenos módulos espalhados pela Web
que se comunicam usando uma linguagem de comunicação padronizada (RDF/SPARQL).
33
2.2.5 Ontologias de modelagem de contexto
Ontologia é um termo oriundo da filosofia para referir-se ao assunto de existência. Nas
ciências da computação e da informação, ontologias são usadas para expressar o
conhecimento sobre conceitos, seus atributos e também as relações entre eles (STRANG et
al., 2003). De forma mais detalhada, é uma representação formal e explícita de uma
conceitualização compartilhada. Esta conceitualização compartilhada refere-se a algum
domínio do conhecimento cujos conceitos e relações sejam consensuais, ou seja, aceitas por
um grupo e não apenas por um indivíduo. Os termos explícita e formal dizem,
respectivamente, que esta representação deve (1) ser explicitamente definida e (2) entendida
por máquinas, o que exclui o uso linguagem natural. (PERTTUNEN et al., 2009)
Uma ontologia é usada, então, para definir um domíno e para raciocinar sobre este
domínio (PATNI et al., 2010). Atualmente, a linguagem OWL, fundamentada na lógica de
descrição, é usada para representar e instanciar ontologias na Web e ambas serão discutidos
na seção 2.3. Diversas ontologias de contexto já foram utilizadas na literatura e algumas delas
serão comentadas aqui por ordem cronológica, mas antes, vale ressaltar que uma informação
de contexto tem diversas propriedades atribuídas a ela. Segundo (BALDAUF et al., 2007) as
mais triviais são:
Tipo é sua categoria ou classe como temperatura, localização, preferência pessoal,
e pode ser organizado numa hierarquia em árvore;
Valor representa o dado propriamente dito obtido por um sensor;
Marca de tempo identifica quando o contexto foi obtido;
Fonte identifica quem ou qual sensor obteve tal informação;
Confiança define o grau de incerteza do dado de contexto entre 0 e 1.
Uma das primeiras ontologias de contexto foi a CoOL (Context Ontology Language)
baseada no modelo Aspect-Scale-Context (ASC) (STRANG et al., 2003). Cada aspecto reúne
escalas e cada escala reune informações de contexto. Portanto, aspecto é um conjunto de uma
ou mais escalas, escala é um conjunto de objetos que definem o intervalo de informações de
contexto válidas para esta escala. Por exemplo, o aspecto GeographicCoordinateAspect
permite as escalas WGS84 e GaussKrueger, e infomação de contexto é um valor numa dada
escala como GaussKruegerCorrinate(367032,533074) para GaussKrueger, e “10” para
MeterScale. Uma informação de contexto A por ter outras infomaçoes de contexto
caracterizando a qualidade desta informação A, que podem ser intríssecas como erro mínimo,
34
erro médio e marca de tempo ou genéricas através da relação hasQuality. O conceito de
IntraOperation permite criar funções de mapeamento entre escalas de um mesmo aspecto (ex.
conversão entre WGS84 e GaussKrueger). Para mapear escalas de diferentes aspectos existe o
conceito de InterOperation (ex. KilometerPerHourScale de SpeedAspect representado como
SpatialDistanceAspect e DurationAspect). Observa-se assim que CoOL é falha em expressar
contextos abstratos como atividade do usuário (STRIMPAKOU, M. A. et al., 2006).
A ontologia CONON (CONtext ONtology) descreve uma ontologia genérica de
contexto (upper ontology) e uma específica para o domínio residencial (WANG, X. H.;
ZHANG, D. Q. et al., 2004). A ontologia genérica basicamente se restringe em definir uma
hierarquia do conceito chamado entidade de contexto que se especializa em entidade
computacional, localização, pessoa e atividade. Uma entidade computacional pode ser
serviço, aplicação, dispositivo, rede e agente. Localização pode ser interna (indoor) ou ao ar
livre (outdoor). Atividade pode ser deduzida ou agendada. Resumidamente, a ontologia
específica de domínio para residências inclui as classes televisão e celular (dispositivos), festa
e aniversário (atividades agendadas), cozinhar e tomar banho (atividades deduzidas), jardim
(espaço ao ar livre), sala ou cozinha (espaço fechado), entre outros; e propriedades, como
localização de uma entidade computacional ou usuário, estado de portas e janelas como aberto
ou fechado, entre outras.
As ontologias SOUPA (Standard Ontology for Ubiquitous and Pervasive
Applications) (CHEN, H.; PERICH; et al., 2004) utilizam conceitos de modelos, ontologias e
vocabulários anteriores como FOAF2, OWL-Time (PAN; HOBBS, 2003), OpenCyc
(LENAT, 1995), RCC, CoBrA-ONT(CHEN, HARRY et al., 2003) e BDI (BRATMAN,
1999; RAO; GEORGEFF, 1991), e é divida em dois subconjuntos: SOUPA-Core e SOUPAextension. A primeira define vocabulários genéricos para:
Pessoas – informações de contato e perfil;
Políticas e ações – políticas de privacidade e segurança com uma lógica de
descrição para gerar ações a serem executadas por agente baseadas nestas
políticas;
Agentes e BDI – agentes e seus estados mentais: belief-desire-intention (crenças,
desejos e intenções);
2
The Friend of a Friend Vocabulary: http://www.foaf-project.org/
35
Tempo – define conceitos para expresar tempo (instante e intervalo) e relações
temporais (antes, depois, inicia antes de, etc.);
Espaço – representa medidas geográficas, relações entre regiões espaciais,
mapeamento entre coordenadas geográficas e simbólicas;
Eventos – define eventos temporais (eventos que ocorrem em um instante ou que
duram um intervalo de tempo) e espaciais (que ocorrem em algum lugar
conhecido);
SOUPA-extension estende SOUPA-Core para certos tipos de aplicação e abrange
domínios como reuniões e agendas, descrição de documentos, captura de imagem e RCC.
Para maiores detalhes consulte (CHEN, H.; PERICH; et al., 2004).
A ontologia COMANTO (COntext MAnagement oNTOlogy) é semelhante à CONON
com algumas extensões. Também estabelece uma classe entidade de contexto que se
especializa em diversos outros como atividade, pessoa, etc. Atividade do usuário por ser física
como assistindo televisão ou uma atividade de serviço, ou seja, relacionada a um serviço onde
pessoas podem se registrar para usufruir. Tempo representa um instante de tempo e uma
atividade possui um tempo inicial e final. Objeto físico pode ser uma mesa ou celular, mas se
especializa em dispositivo que pode ter sensores atrelados e estar conectado a um rede. Um
smartphone é um dispositivo e, portanto, um objeto físico, mas o mesmo não ocorre com a
mesa que é apenas um objeto físico. Objeto físico, pessoa e atividade podem estar associados
a um lugar que representa uma localização simbólica ou geográfica. Preferências do usuário
se especializam em quatro outras classes que são relacionadas a dispositivos, rede, serviços ou
outra coisa que não se relacione a nenhum destes. (ROUSSAKI, I. et al., 2006;
STRIMPAKOU, M. A. et al., 2006)
Ontonym é um conjunto de ontologias que tenta representar as necessidades mais
comuns das aplicações cientes de contexto: tempo, espaço, pessoas (ou identidades) e eventos
(ou atividades) (STEVENSON et al., 2009). Para representar tempo e eventos, ela se utiliza
da OWL-Time (PAN; HOBBS, 2003) da mesma forma que a ontologia SOUPA. Para
modelagem espacial utiliza um modelo bastante elaborado (YE et al., 2007) que reúne
representação geométrica (ou geográfica) e simbólica de trabalhos anteriores (HIGHTOWER;
BORRIELLO, 2001; JIANG; STEENKISTE, 2002) e adiciona representações de relação
espacial como continência, adjacência e conectividade, este útlimo um caso especial de
adjacência onde é possível cruzar duas regiões. Para modelagem de pessoas, os autores
descrevem que, excluindo-se dados específicos das aplicações, é necessário representar
36
identidade, posse de dispositivos, detalhes pessoais e relações sociais. Para isso consideram
uso de URIs para identificar pessoas, versões adaptadas das ontologias vCard 3 e PIM4 do
W3C para detalhes pessoais e a ontologia Relationship 5 para descrever relacionamentos
interpessoais. Ontonym inclui ainda ontologias para representação de (1) sensores e suas
medições (observações) com respectiva taxa de atualização, precisão e acurácia; (2) dados de
proveniência como autoria e data de criação ou modificação; (3) dispositivos e ligação com
seu possuidor visto que eles funcionam como uma ponte para o usuário que geralmente está
carregando o aparelho; e (4) recursos na Web como formato de arquivo, idioma, direitos de
acesso, e nomes legíveis para humanos.
O trabalho de Naudet (NAUDET, 2011) apresenta uma ontologia com uma visão um
pouco diferente, centrada nos conceitos de entidade (Entity), elemento de contexto (Context
Element) e situação (Situation). Um elemento de contexto (CE) é “qualquer coisa desde um
simples valor numérico ou amostra de sinal (...) até uma afirmação ontológica (...) útil para
determinar a situação de uma entidade” e contexto é “um conjunto de elementos de contexto
disponíveis num dado momento, que será usado como base de conhecimento para determinar
a situação de uma entidade”. A motivação para sua abordagem é que ontologias anteriores
são dedicadas apenas a elementos de contexto (SOUPA e Ontonym) ou entidades de contexto
(CONON e COMANTO) e ele pretende reunir estes conceitos em uma ontologia de contexto
genérica unificante. Para isso, além dos conceitos já descritos, ele define atividade (Activity),
estado (State) e ambiente (Environment). Ambiente é tudo que rodeia um sistema e o
influencia sendo a entidade parte dele, estado refere-se à estrutura da entidade e atividade
refere-se ao seu comportamento, ou seja, suas ações. Além disso, CE = <CI, t, vp, loc, r, obs,
src> onde CI é a informação carregada (carried information), t é o instante de tempo em que a
informação foi obtida, vp é o período de validade da informação, loc é a localização onde a
informação é valida, r é um fator de confiabilidade, obs é a observação de onde a informação
se originou, e src é outro CE que porventura tenha gerado/deduzido este CE. Alguns destes
valores podem ser omitidos, por exemplo, a ausência de vp ou loc indica que a informação é
válida independentemente do tempo ou localização, e a ausência de obs indica que a
informaçao não foi obtida de um sensor. Existem ligações com outros vocabulários e
ontologias: Semantic Sensors Network Ontology do W3C para representação de observações e
3
vCard ontology: http://www.w3.org/2006/vcard/
4
W3C PIM: http://www.w3.org/2000/10/swap/pim/contact
5
RELATIONSHIP – A vocabulary for describing relationships between people: http://vocab.org/relationship
37
sensores, FOAF para especializar o conceito de entidade usando os conceitos de agente e
pessoa, Ontonym Location para localização de entidade e CE, OWL-Time para instante de
medição e validade de um CE.
Com base nos diversos trabalhos aqui apresentados, deve-se ressaltar que apesar de
estas ontologias descreverem medições de sensores, tais dados podem rapidamente atingir
grandes quantidades e inviabilizar inferências OWL usando a ontologia em questão. Portanto,
neste caso, tais ontologias deveriam ser utilizadas apenas para representação na troca de
informação e outros mecanismos devem ser usados para tratar estes grandes volumes de
dados. Outro importante aspecto a ser considerado é a pouca quantidade de informação e
documentação, quase inexistente, da maioria delas. Como a Ontonym foge a esta regra,
possuindo alguma documentação na Internet6, este trabalho utilizará um subconjunto dela na
seção 4.3.1.1 (página 118). Apesar de fora do escopo do trabalho, ao modelar ontologias mais
complexas é importante considerar aspectos abordados pelas ontologias de fundamentação
como princípio de identidade e aspectos temporais como fases e papéis de uma entidade. Isso
pode ser visto em trabalhos como a Unified Foundational Ontology (UFO) (GUIZZARDI;
WAGNER, 2010).
2.3
Web Semântica e Dados Ligados
A Web atualmente conhecida (Web de Documentos) é projetada apenas para
entendimento humano, ou seja, não expressa o significado de forma que possa ser acessado e
processado por máquinas em qualquer parte da Web. Desta forma, dados, metadados e regras
estão confinados em pequenos conjuntos, geralmente dentro de servidores, e podem ser
processados apenas por softwares especificamente desenvolvidos para obter e interpretar estes
dados. Vendo este cenário, Tim Berners-Lee introduziu, em 2001, os conceitos da Web
Semântica (WS) como uma extensão da Web então existente (BERNERS-LEE et al., 2001).
Assim, segundo ele, uma vez que tais dados e metadados estejam disponíveis na Web é
possível criar agentes que são “programas que coletam conteúdo da Web de diversas fontes,
processam a informação e trocam os resultados com outros programas” de forma que
“mesmo agentes que não foram explicitamente desenvolvidos para trabalhar junto possam
transferir dados entre si quando estes dados vêm com semântica”.
6
ONTONYM – Ontologies for pervasive computing: http://ontonym.org
38
Apesar de a WS ser apenas uma visão, conceito ou ideia, conforme descrito no
parágrafo anterior, este trabalho não tratará do ponto de vista filosófico e, portanto, não
diferenciará WS e as tecnologias atuais que a implementam (RDF, OWL, SPARQL). As
próximas seções descreverão os conceitos básicos da WS e uma pequena parte da teoria por
trás dela, além de um pouco do que vem sendo feito com a iniciativa da Web de Dados ou
Dados Ligados.
2.3.1 Conceitos básicos
Assim como a Web de Documentos, a WS propõe o uso de identificadores, formatos e
protocolos padronizados para descrever e interligar recursos disponibilizados na Web. Isto
quer dizer que assim como existem as linguagens HTML, CSS e Javascript e os protocolos
HTTP e HTTPS novas linguagens e protocolos também serão padronizados e passarão a ser
adotados. Observe, contudo, que como a nova Web deve ser uma extensão da Web atual,
todas estas linguagens devem coexistir.
Os elementos mais básicos da Web Semântica são os identificadores ou URIs
(Uniform Resource Identifiers) e as triplas. URIs identificam recursos enquanto as triplas
provêm informações sobre estes recursos. URI são bem semelhantes aos endereços
eletrônicos usados para acessar páginas na Web, mas não precisam ser derreferenciáveis como
as URLs, ou seja, não precisam retornar uma página HTML quando digitadas em um
navegador. Um exemplo de URI que representasse a professora Adriana Vivacqua dentro do
PPGI poderia ser:
http://greco.ppgi.ufrj.br/resource/Professor/AdrianaVivacqua
Adicionalmente, é possível definir um prefixo que represente a parte inicial do URI
para escrever o URI em uma forma compacta. Por exemplo, se o prefixo greco for definido
como http://greco.ppgi.ufrj.br/resource/Professor/, o URI acima pode ser escrito como
greco:AdrianaVivacqua.
Triplas são compostas por três partes: sujeito, predicado e objeto. Sujeito e predicado
sempre são identificadores. O primeiro identifica um recurso qualquer na Web (como a
professora) e o segundo identifica um recurso especial chamado propriedade. O objeto pode
ser um URI para um recurso ou um literal (número, texto, data, etc.). O exemplo de tripla a
seguir informa o nome completo da professora Adriana Vivacqua (parte do URI do sujeito
omitido para caber na linha):
39
<http://.../AdrianaVivacqua> foaf:name “Adriana Santarosa Vivacqua”.
O prefixo foaf representa o URI do vocabulário FOAF para descrever redes sociais ou
de informação. Assim foaf:name representa a propriedade <http://xmlns.com/foaf/0.1/name>.
Ao escrever uma tripla, as formas longas devem usar os símbolos de menor e maior como
delimitadores. O nome entre aspas é denominado literal. Um conjunto de triplas forma um
grafo, de maneira que os vértices representam sujeitos e objetos, e as arestas representam
predicados. O padrão RDF (Resource Description Framework) aplica estes conceitos para
representar informações na Web por meio de notações XML, Turtle, N3 e NTriplas. A seguir
pode-se observar um exemplo utilizando as notações Turtle e XML:
1
2
3
4
5
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix greco: <http://greco.ppgi.ufrj.br/resource/Professor/> .
greco:AdrianaVivacqua
foaf:name
"Adriana Santarosa Vivacqua" ;
foaf:homepage
<http://dcc.ufrj.br/~avivacqua/> .
1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description
rdf:about=
"http://greco.ppgi.ufrj.br/resource/Professor/AdrianaVivacqua">
<foaf:name>Adriana Santarosa Vivacqua</foaf:name>
<foaf:homepage rdf:resource="http://dcc.ufrj.br/~avivacqua/"/>
</rdf:Description>
</rdf:RDF>
Como se pode observar uma sequência de triplas que compartilham o mesmo sujeito
pode ter sua escrita simplificada por meio da separação usando ponto-e-vírgula (;) e omissão
deste sujeito. O mesmo ocorre quando ambos o sujeito e o predicado se repetem, mas utilizase a vírgula como separador. O RDF por si só permite apenas descrever recursos na Web, ou
seja, não provê mecanismos para descrever um esquema a ser obedecido, como é comum em
bancos de dados relacionais e linguagens de programação. Para este fim, foi criado o padrão
RDF Schema (RDFS) que permite definir classes (conceitos) e suas propriedades, hierarquias
entre classes e propriedades, além dos tipos aceitos no sujeito (rdfs:domain) e intervalos de
valores aceitos no objeto (rdfs:range) das triplas.
40
Adicionalmente uma linguagem para representação de ontologias foi proposta.
Originalmente usada em filosofia como a disciplina que estuda “a natureza da existência” e
“quais tipos de coisas existem”, pesquisadores de IA e da Web adotaram esta palavra para a
descrição formal da relação entre termos (conceitos, classes, propriedades) e regras que
permitam processos de inferência (deduções lógicas) sobre estes termos (BERNERS-LEE et
al., 2001; RUSSELL; NORVIG, 1995). Entre 2001 e 2004 o W3C manteve um grupo de
trabalho para desenvolver uma linguagem (e também uma sintaxe baseada em RDF) para
descrever ontologias que culminou com a criação da OWL (Web Ontology Language). A
OWL se tornou o padrão para representação de ontologias que permite, entre outras
funcionalidades, descrever (a) características de simetria, reflexividade e transitividade de
propriedades; (b) equivalência e diferença entre classes e instâncias; e (c) operações de
interseção, união e complemento sobre classes (que são análogas a conjuntos). A ferramenta
capaz de processar ontologias e regras de forma automatizada é denominada motor (ou
máquina) de inferência ou reasoner. Há motores de inferência para lógica de descrição (teoria
base da OWL), para sistemas de regras ou híbridos. Maiores detalhes sobre DLs e regras serão
apresentados na seção 2.3.2 a seguir.
SPARQL é a linguagem de consulta para bases de triplas, que tem alguma
similaridade com SQL. SPARQL permite a execução de quatro tipos de consulta: SELECT,
ASK, DESCRIBE e CONSTRUCT. O primeiro gera resultados no formato de tabelas; o
segundo responde uma pergunta com verdadeiro ou falso; o terceiro responde um conjunto de
triplas (grafo) sobre determinado recurso (URI); o último utiliza modelos (templates) de
triplas e retorna um grafo contendo a união de todos os resultados, funcionando assim, como
uma forma de mapeamento. Bases de triplas podem ser consultadas via HTTP por meio do
uso de serviços REST que implementem o protocolo SPARQL do W3C (CLARK et al.,
2008)7. Tais serviços são conhecidos como SPARQL Endpoints. Há também o SPARQL
Update8 para realizar inserções e remoções em bases de triplas, mas ela está fora do escopo
deste trabalho.
7
O protocolo para SPARQL 1.0 é uma recomendação e foi citado como referência. A versão para SPARQL 1.1
ainda é um rascunho de trabalho e pode ser encontrada em http://www.w3.org/TR/sparql11-protocol.
8
SPARQL Update - http://www.w3.org/Submission/SPARQL-Update/
41
2.3.2 Lógica de Descrição (DL)
As DLs são formalismos para representação do conhecimento (KR – Knowledge
Representation) que sucederam os sistemas de frames e redes semânticas que falhavam em
apresentar uma semântica formal (BAADER et al., 2008). Uma semântica formal permite
definir uma linguagem ou conjunto de símbolos e operações com interpretações lógicas para
conceitos e relações existentes no mundo. A lógica de predicados estuda tais representações
formais, através da lógica proposicional, lógica de primeira ordem, entre outras. DL é um
subconjunto da lógica de primeira ordem que tenta conciliar expressividade com
complexidade e decibilidade, pois parte do princípio que do ponto de vista computacional não
adianta ter uma lógica com alta capacidade de expressão se o sistema precisar de quantidades
de tempo e espaço astronômicas para responder perguntas, ou nem ser capaz de respondê-las
(NARDI; BRACHMAN, 2003). As próximas subseções tentarão apresentar conceitos básicos
de DL utilizados na OWL, fazendo analogias para facilitar a compreensão sempre que
possível.
2.3.2.1 Conceitos de TBox, ABox e KB
Assim como na matemática existem conjuntos, elementos e funções, e na programação
orientada a objetos existem classes, instâncias e métodos, DL também possui seus
equivalentes. A terminologia, ou seja, o vocabulário do domínio da aplicação consiste de
conceitos e relações ou papéis (roles) que podem ser combinados para representar descrições
mais complexas. Esta terminologia é denominada TBox (terminological box). Ao especificar
os elementos ou indíviduos existentes na aplicação, cria-se o chamado ABox (assertion box)
ou conjunto de afirmações sobre fatos do mundo. A união do TBox com o ABox é chamada
base de conhecimento ou KB (knowledge base). Desta forma sistemas DL usam o TBox e o
conhecimento explícito do ABox para descobrir conhecimento implícito e responder
perguntas. (BAADER; NUTT, 2003)
Para exemplificar, considere o conceito pai (Father) como uma pessoa (Person) do
sexo masculino (Male) que possui pelo menos um filho (hasChild). Isto pode ser representado
na notação DL como (TBox):
Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person
Aqui, o símbolo ⊓ representa a interseção entre conjuntos e a expressão
∃hasChild.Person representa o conjunto de indivíduos que possuem pelo menos uma relação
42
hasChild com algum individuo do conceito pessoa. Suponha agora que o ABox possua as
seguintes afirmações dizendo que JOHN e MARY são pessoas, JOHN é do sexo masculino e
JOHN tem filha MARY:
Person(JOHN)
Male(JOHN)
Person(MARY)
hasChild(JOHN, MARY)
Com base nisso alguém poderia perguntar ao KB se JOHN é pai e a resposta seria sim,
pois JOHN é Person e Male (interseção) e tem um filho que é Person, satisfazendo a definição
de Father. Se a afirmação Male(JOHN) fosse retirada, seria impossível responder à pergunta,
mas neste caso surge a questão sobre que resposta deveria ser data pelo sistema: (1) JOHN
não é pai, (2) não sei se JOHN é pai. Esta é a grande diferença entre os bancos de dados
relacionais e bases de representação de conhecimento. Enquanto o primeiro reponde (1), o
segundo responde (2). A primeira forma é dita mundo fechado (closed world assumption),
pois considera que toda a informação sobre o mundo está presente na base, e as segunda é dita
mundo aberto (open world assumption), pois considera que a base de conhecimento não é
completa, ou seja, não possui toda a informação sobre o mundo. DL e OWL usam a hipótese
do mundo aberto. Considere agora a adição das seguintes afirmações ao ABox:
Father(MARY)
¬Male(MARY)
Isto diz que MARY é pai e não é do sexo masculino, mas o TBox diz que todo pai é
do sexo masculino, tornado o KB inconsistente. Neste caso foi fácil observar este problema
mas conforme a quantidade de indivíduos no KB aumenta se torna impossível descobrir
inconsistências sem métodos automatizados. Inconsistência é um dos tipos de problemas de
inferência tratados pelos motores de inferência e que serão apresentados na seção 2.3.2.3.
2.3.2.2 Nomenclatura, síntaxe e semântica
As DLs são nomeadas conforme os contrutos que oferecem. A DL mais básica é
chamada AL (Attributive Language) e conforme mais construtos são adicionados, adicionamse letras ao nome da DL (BAADER; NUTT, 2003). A linguagem ALC (Attribute Language
with Complements), por exemplo, é a adição de negação (complementos) à AL. Muitas vezes
uma mesma linguagem possui mais de um nome, por exemplo, ALC é equivalente a ALUℰ e S
é equivalente à ALC
R+.
A partir daqui será usada uma convenção de letras: A e B serão
usadas para representar conceitos atômicos ou primitivos, C e D para descrições de conceitos
43
(definidos com base em outros), r e s para relações atômicas. Um conceto-ALC é definido
como:
⊤ – conceito universal (contém todos os indivíduos);
⊥ – conceito vazio (não contém indivíduos);
C ⊓ D – interseção dos indivíduos dos conceitos C e D
C ⊔ D – união dos indivíduos dos conceitos C e D
¬C – indivíduos que não estão em C
∃r.C – indivíduos que possuem pelo menos uma relação r com um indivíduo de C
(quantificação existencial completa)
∀r.C – indivíduos que se possuírem uma relação r esta é apenas com indivíduos de
C (restrição de valor)
Uma interpretação I = (ΔI, •I) consiste de um conjunto de indivíduos ΔI (domínio da
interpretação) e uma função •I que mapeia todo conceito-ALC a um subconjunto de ΔI e todo
nome de relação a um subconjunto de ΔI × ΔI (BAADER et al., 2008). Desta forma, pode-se
escrever a interpretação matemática de qualquer conceito-ALC. Veja alguns exemplos:
⊤I = ΔI
⊥I = ∅
(C ⊓ D) I = CI ∩ DI
(∃r.C) I = {x ∈ ΔI | Existe algum y ∈ ΔI tal que (x, y) ∈ rI e y ∈ CI }
(∀r.C) I = {x ∈ ΔI | Para todo y ∈ ΔI, se (x, y) ∈ rI então y ∈ CI }
Um axioma é uma afirmação sobre o mundo e pode ser terminológico ou assertivo,
dependendo se tratam de conceitos ou indivíduos. O axioma terminológico pode ser:
Inclusão de conceitos (hierarquia): C ⊑ D
Inclusão de relações (hierarquia): r ⊑ s
Equivalência de conceitos: C ≡ D
Equivalência de relações: r ≡ s
Já o axioma assertivo ou fato pode ser da forma C(a), r(a, b), a = b e a ≠ b. O TBox é o
conjunto de axiomas terminológicos e o ABox o conjunto de axiomas assertivos.
Uma interpretação I é um modelo de um axioma C ⊑ D se CI ⊆ DI, e um modelo de
um TBox se é um modelo de todos os axiomas deste TBox. Uma interpretação I é um modelo
de um axioma assertivo C(a) se aI ∈ CI, e um modelo de um ABox se é um modelo de todos
44
os axiomas deste ABox. Analogamente, uma interpretação I é um modelo para uma base de
conhecimento se é um modelo tanto do seu TBox quanto do seu ABox. Desta forma,
aproveitando o exemplo anterior, uma interpretação I 1 = (Δ1I, •1I), onde:
Δ1I = {JOHNI, MARYI}
•1I = { Person1I = {JOHNI, MARYI},
Male1I = {JOHNI},
Father1I = {JOHNI},
hasChild1I = {(JOHNI, MARYI)} }
é um modelo para a base de conhecimento formada pelo TBox:
Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person
e pelo ABox:
Person(JOHN)
Male(JOHN)
Person(MARY)
hasChild(JOHN, MARY)
Esta outra interpretação I 2 = (Δ2I, •2I) também é um modelo para este mesmo KB:
Δ2I = {JOHNI, MARYI}
•2I = { Person2I = {JOHNI, MARYI},
Male2 I = {JOHNI},
Father2I = {JOHNI},
hasChild2I = {(MARYI, MARYI)} }
contudo não deveria, pois MARY é filha dela mesma. Isto ocorre porque não há um axioma
restritivo que diga que a propriedade hasChild é irreflexiva. Este é um problema gerado pela
falta de expressividade da linguagem utilizada (ALC). Existem inúmero outros problemas
semelhantes que foram resolvidos a partir de DLs mais expressivas. Algumas desteas
extensões serão apresentadas na seção 2.3.2.4.
2.3.2.3 Problemas de inferência
Na seção 2.3.2.1 foi mostrado um exemplo de incosistência do KB. O algoritmo de
Tableau resolve este e outros problemas comuns. Nesta seção estes problemas serão
45
apresentados com base nos conceitos de interpretação e modelo. Para isso considere um KB K
= (T, A) onde T é um TBox e A um ABox, conceitos C e D, indivíduos a e b e uma relação r.
Consistência: K é consistente se ele possui um modelo;
Satisfatibilidade: C é satisfatível em relação a K se existe um modelo I de K com CI
≠ ∅ (I é um modelo de C em relação a K ) e escreve-se K ⊨ C ≢ ⊥;
Subsumption9: C é subconjunto de D (C ⊑ D) em relação a K se CI ⊆ DI para todos os
modelos I de K (escreve-se K ⊨ C ⊑ D, ou seja, C ⊑ D é provável a partir de K);
Equivalência: C e D são equivalentes em relação a K se um é subconjunto do outro,
ou seja, CI = DI para todos os modelos de I de K (escreve-se K ⊨ C ≡ D);
Disjunção: C e D são disjuntos em relação a K se CI ∩ DI = ∅ para todos os modelos I
de K e escreve-se K ⊨ C ⊓ D ≡ ⊥;
Instância: a é instância de C em relação a K se aI ∈ CI para todos os modelos I de K e
escreve-se K ⊨ C(a). Analogamente, (a,b) é instância de r em relação a K if (aI,bI) ∈ r para
todos os modelos I de K e escreve-se K ⊨ r(a,b).
Trabalhos mostram que estes problemas podem ser reduzidos a apenas um deles
(BAADER; NUTT, 2003; HORROCKS, I et al., 2006). Por exemplo, a redução à subsunção
(reduction to subsumption) apresenta as seguintes transformaçoes:
(i)
C ≡ ⊥ ⇔ C ⊑ ⊥;
(insatisfatibilidade)
(ii)
C ≡ D ⇔ C ⊑ D e D ⊑ C;
(equivalência)
(iii)
C ⊓ D ≡ ⊥ ⇔ (C ⊓ D) ⊑ ⊥.
(disjunção)
Há também a redução à insatisfatibilidade (reduction to unsatisfiability) que é
utilizada no algoritmo Tableau:
9
(i)
C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥
(subsumption)
(ii)
C ≡ D ⇔ (C ⊓ ¬D) ≡ ⊥ e (¬C ⊓ D) ≡ ⊥
(equivalência)
(iii)
(C ⊓ D) ⊑ ⊥ ⇔ C ⊓ D ≡ ⊥
(disjunção)
Subsumption significa, na filosofia, ato de um objeto cair sob um conceito. Nada mais é que a relação de
subconjunto, contudo, decidiu-se por não criar uma tradução para o termo.
46
Qualquer um destes pode ser reduzido à consistência do KB. Para isso, considere que
se queira saber se C é um subconjunto de D com relação a K (K ⊨ C ⊑ D). Usando a redução à
insatisfatibilidade (i), sabe-se que C ⊑ D ⇔ C ⊓ ¬D ≡ ⊥ (veja Figura 3). Portanto, isto
equivale a verificar se um KB K’ = (T, A ⋃ { (C ⊓ ¬D)(x) }) é inconsistente para algum
indivíduo x. Para isso, o algoritmo tenta construir um modelo para K’ utilizando regras de
expansão para lidar com os construtos da linguagem, verificação de condições conflitantes
para descobrir inconsistência e bloqueios para impedir aplicações infinitamente repetitivas das
regras de expansão. Se um modelo for obtido significa que a interseção não é vazia, logo C
não é subconjunto de D; caso contrário, C é subconjunto de D. O algoritmo deve considerar
que C e D podem ser descrições de conceitos complexas com quantificação existencial,
negação, união, interseção ou quaisquer outros construtos existentes em linguagens mais
expressivas que a ALC.
Um problema investigado antes de aumentar a expressividade (i.e. adicionar um novo
construto) de uma DL é verificar se a linguagem continua decidível, ou seja, se é possível
adicionar regras de expansão e bloqueios ao algoritmo de forma que ele sempre termine. Para
maiores detalhes recomenda-se ler (BAADER et al., 2008; BAADER; NUTT, 2003).
C ⊓ ¬D ≢ ⊥
C⊑D ⇔ C ⊓ ¬D ≡⊥
¬D
D
C
¬D
C
D
Figura 3. Diagrama de Venn mostrando a validade da fórmula C ⊑ D ⇔ C ⊓ ¬D = ∅.
2.3.2.4 Extensões da linguagem ALC
Conforme já discutido, a linguagem ALC possui baixa expressividade para
representação de conhecimento. Por este motivo vários trabalhos com o intuito de prover
novas funcionalidades mantendo decidibilidade foram feitos, chegando-se ao que é
apresentado no Quadro 3 que resume construtos e axiomas existentes em diversas DLs e que
são usados em OWL-DL. O quadro apresenta descrição, notação, nomenclatura e se é um
axioma ou construto. Pode-se verificar que AL contém os conceitos universal e vazio, assim
47
como negação atômica, interseção, restrição de valor, quantificação existencial limitada e
equivalência e hierarquia de conceitos. Expressividades adicionais incluem quantificação
existencial completa (ℰ), complemento (C ), união de conceitos (U), restrições de número
qualificadas (Q ) ou não (N ), transitividade (R+), inversibilidade (I), equivalência e hierarquia
(H) de relações, e inclusão de relações complexas para composição de relações (R ). Dentre
elas podem-se destacar as restrições de número a composição de relações. As primeiras
representam subconjuntos de ΔI cujos indivíduos devem possuir uma quantidade mínima ou
máxima de ocorrências numa dada relação. Estas restrições podem ser qualificadas ou não.
Exemplo:
1. Parent ≡ ≥1hasChild
2. Orphan ≡ ≥1hasParent.Dead ⊓ ≤2hasParent.Dead
A primeira é uma restrição de número não qualificada pois diz que para um indivíduo
(p.ex. JOHN) ser pai/mãe basta que ele tenha ao menos um par na relação hasChild. Assim,
para uma afirmação hasChild(JOHN, MARY) não há exigência de que MARY pertença a
qualquer conceito. O segundo exemplo é uma relação qualificada pois diz que para um
indivídio ser órfão deve existir uma ou duas afirmações do tipo hasParent cujo segundo
elemento é falecido.
A composição de relações permite fazer um processo similar ao de composição de
funções:
1. hasParent ∘ hasParent ≡ hasGrandParent
2. owns ∘ hasPart ≡ owns
A primeira mostra relação hasGrandParent como a composição da relação hasParent e
a propriedade owns como composição entre a relação owns e hasPart. Na primeira, se o ABox
tiver hasParent(JOHN, MARY) e hasParent(MARY, ANNA) pode-se inferir a relação
hasGrandParent(JOHN, ANNA). A segunda é semelhante: owns(PETER, CAR) e
hasPart(CAR, ENGINE) então owns(PETER, ENGINE). Assim como existe o TBox para os
conceitos e o ABox para indivíduos, na linguagem SROIQ existe o RBox que contém os
axiomas para relaçõs, como estes dois descritos. Por fim, cabe relembrar que a nomenclatura
ALC é equivalente a ALUℰ e S é equivalente à ALCR+, Portanto SROIQ é ALCR+ com nominais
(O), inversibilidade de relação (I) e restrição de número qualificada (Q). Uma extensão
importante é a adição de tipos de dados (inteiro, string, data, etc.) e representada pela adição
de (D) ao nome da linguagem (HORROCKS, I et al., 2001).
48
Quadro 3. Lista de expressividade de diversas DLs atuais.
Descrição
Notação
Nomenclatura
Tipo
Conceito universal
⊤
AL
Construto
Conceito vazio
⊥
AL
Construto
¬A
AL
Construto
Interseção de conceitos
C⊓D
AL
Construto
Restrição de valor
∀r.C
AL
Construto
Quantificação existencial limitada
∃r.⊤
AL
Construto
Hierarquia de conceitos
C⊑D
AL
Axioma
Equivalência entre conceitos
C≡D
AL
Axioma
Quantificação existencial completa
∃r.C
ℰ
Construto
Negação ou complemento
¬C
C
Construto
C⊔D
U
Construto
Tr(r), r+ ⊑ r
R+
Axioma
≥n r, ≤n r
N
Construto
≥n r.C, ≤n r.C
Q
Construto
≤1 r
F
Construto
r¯
I
Construto
r ≡ s, r ⊑ s ⊓ s ⊑ r
H
Axioma
r⊑s
H
Axioma
r1 ∘ r2 ⊑ s
R
Axioma
Reflexividade local
∃r.Self
R
Construto
Reflexividade global
⊤ ⊑ ∃r.Self
R
Construto
{a1, a2, ..., an}
O
Construto
-
(D)
-
Negação atômica
União de conceitos
Transitividade de relação
Restrições de número
Restrições de número qualificadas
Propriedades funcionais
Inversibilidade de relação
Equivalencia entre relações
Hierarquia de relações
Inclusão de relações complexas
(cadeia ou composição de relações)
Nominals (indivíduos no TBox)
Tipos de dados
49
2.3.2.5 Regras DL-seguras
DLs, apesar de possuírem um relativamente rico conjunto de construtos para
conceitos, possuíam grandes limitações com respeito à expressividade de propriedades. Estas
limitações eram maiores antes das DLs SROIQ (D), pois não permitiam representação de
composição nem reflexividade de relações. Por outro lado, sistemas de processamento de
regras (cláusulas de Horn) permitem estabelecer os mais variados tipos de relações
(propriedades) entre indivíduos. Sendo assim, surgiram propostas para adicionar regras a
motores de inferência DL, contudo, estas abordagens tornavam a linguagem resultante
indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004). Propostas posteriores
passaram a utilizar as chamadas regras DL-seguras (DL-safe rules) que garantem
decidibilidade do processo de inferência. A seguir, apresentar-se-á a definição geral de regra,
regras DL e DL-seguras.
Um termo é uma constante (a, b, c) ou uma variável (x, y, z). Um átomo tem a forma
P(t1, ... , tn), onde t1 a tn são termos. Um literal é um átomo ou um átomo negado. Assim, uma
regra ou cláusula de Horn segue a forma
H ← B1, ..., Bn
ou
B1, ..., Bn → H
onde H e B1 a Bn são átomos; H é dita a cabeça ou consequente da regra e B1 a Bn é o
corpo ou cauda ou antecedente da regra. Regras podem ser vistas como IF-THEN (SE
antecedente ENTÃO consequente), ou seja, o antecedente representa uma condição e o
consequente as informações que serão adicionadas ao KB quando a condição é satisfeita. Um
conjunto finito de regras é chamado um programa. Uma regra-DL é obtida restringindo
átomos para os chamados átomos-DL que podem ser da forma C(t) ou R(s, t). Um conjunto de
regras-DL forma um programa-DL. (KOLOVSKI et al., 2006)
Como esta definição é possível expressar necessidades de modelagem não permitidas
nas DLs convencionais, como apresentado nos dois exemplos a seguir:
(i)
hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y), Female(y)
(ii)
hasCurrentActivity(x, MeetingSupervisor) ← Person(x), Person(y),
Location(z), hasSupervisor(x, y), hasOffice(y, z), hasCurrentLocation(x, z)
A regra (i) diz que se um indivíduo x tem um ancestral direto (pai ou mãe) z que
possui uma irmã y então y é tia de x (MOTIK et al., 2005). A regra (ii) apresenta um exemplo
de inferência de contexto da atividade de uma pessoa, pois diz que se uma pessoa x é
50
supervisionada por uma pessoa y e x se encontra no mesmo local que o escritório de y, então
x está praticando a atividade “reunião com seu supervisor” (WANG, X.; DONG, J. S. et al.,
2004). OWL 1 DL (SHOIN ) não possui construtos nativos para nenhuma das duas regras,
enquanto OWL 2 DL (SROIQ ) possui construtos apenas para a regra (i) (RIBONI; BETTINI,
2011b). Isto mostra a importância da extensão de DLs com regras.
Tanto DLs quanto linguagens de regras (LP e RETE) são fragmentos decidíveis da
lógica de primeira ordem, contudo a simples união de ambas torna a linguagem resultante
indecidível (HORROCKS, IAN; PATEL-SCHNEIDER, 2004; MOTIK et al., 2005). A
decidibilidade de DLs é mantida pela propriedade modelo de árvore, que diz que um conceito
tem um modelo se, e somente se, suas propriedades definem um grafo direcionado na forma
de árvore (GROSOF et al., 2003). Esta propriedade é comprometida quando surgem árvores
com ramos que possuam cadeias infinitas. Veja o seguinte KB:
Person ⊑ ∃father.Person
Person(JOHN)
isto resulta em uma cadeia infinita de pais desconhecidos (indivíduos anônimos), pois
diz que toda pessoa possui um pai que é uma pessoa, logo este pai também tem um pai que é
uma pessoa, e assim sucessivamente. Transitividade de relações também compromete este
modelo, contudo ambos os casos são resolvidos com bloqueios que impedem aplicações
repetitivas de regras de expansão.
Ao adicionar regras esta propriedade das DLs é perdida, além disso, como reasoners
DL tipicamente produzem indivíduos anônimos dentro de um domínio possivelmente infinito
(ex. Person ⊑ ∃father.Person) e regras são universalmente quantificadas (i.e., aplicam-se a
todos os indivíduos do domínio) isto dificulta a inferência e torna o KB indecidível
(KRISNADHI et al., 2011). Para evitar problemas causados pelo uso de regras-DL, foi criado
o conceito de regras-DL-seguras.
Uma regra-DL-segura é uma regra-DL tal que todas as suas variáveis ocorrem em um
átomo não-DL no corpo da regra. Assim, as regras (i) e (ii) não são regras-DL-seguras, mas se
tornam DL-seguras ao adicionar (a) um átomo unário não-DL, O(x), ao corpo da regra para
cada variável existente na regra e (b) um fato O(a) para cada indivíduo existente no KB e no
programa. Exemplificando, a regra (i) ficaria da seguinte forma:
51
(i)
hasAunt(x, y) ← hasParent(x, z), hasSibling(z, y),
Female(y), O(x), O(y), O(z)
O reflexo na expressividade e semântica desta restrição pode ser facilmente verificado
com o exemplo a seguir. Considere o seguinte KB:
father ∘ father¯ ⊑ sibling
∃father.(∃father¯.{CAIN})(ABEL)
O primeiro axioma diz que indivíduos com o mesmo pai são irmãos (ignore o fato de o
axioma permitir que uma pessoa seja irmã dela mesma) e o segundo diz que CAIN e ABEL
possuem o mesmo pai. Ao questionar se CAIN e ABEL são irmãos, o motor de inferência
diria que sim. Agora considere trocar o primeiro axioma pela regra:
sibling(x,y) ← father(x, z), father(y, z), O(x), O(y), O(z)
A mesma pergunta teria resposta “não sei”, pois o motor de inferência não criaria um
indivíduo anônimo representando o pai de CAIN e ABEL para casar com a variável z da
regra. Para que tal regra funcionasse como desejado, seria necessário explicitar quem é o pai
de ambos, que poderia ser feito apenas desmembrando o segundo axioma ou substituindo-o
por relações father entre ABEL, CAIN e ADAM:
(a) ∃father.{ADAM}(ABEL)
∃father¯.{CAIN}(ADAM)
(b) father(ABEL, ADAM)
father(CAIN, ADAM)
Apesar de esta restrição parecer incoveniente ela evita que regras propaguem relações
indesejadas, que resultariam numa possível alteração desconhecida do TBox. Considere o
KB10:
A ≡ ∃R.B
A(c)
C ≡ ∃R.{c}
R(a, b)
R(b, c)
A Figura 4 mostra um grafo (à esquerda) representando este KB. Note que o indivíduo
c foi classificado como uma instância de C, pois há uma propriedade R que relaciona b e c. O
ABox diz que o indivíduo c pertence ao conceito A, logo infere-se que existe um indivíduo
10
Adaptado de http://weblog.clarkparsia.com/2007/08/27/understanding-swrl-part-2-dl-safety/
52
anônimo x pertencente ao conceito B que se relaciona com c através da relação R. Considere
agora a adição de uma regra não-DL-segura para transitividade da relação R:
R(x, y) ← R(x, z), R(z, y)
Isto leva ao grafo na parte direita de figura que mostra que a, b, c e um possível x se
relacionam por R. Além diso, b passa a ser também instância de A, e a passa a ser instância de
A e C. Contudo, não apenas a e b se tornam instâncias de A e C, mas também todas as
possíveis instâncais de C. Veja, por exemplo, que adição de um indivíduo y do tipo C resulta
nas arestas tracejadas e classifica y também como instância de A (≡ ∃R.B). Logo, tem-se um
novo axioma C ⊑ A não existente no TBox. Este é apenas um exemplo e o uso de regras nãoDL-seguras pode gerar muitos outros problemas. Assim, a aplicação das regras restringe-se
aos indivíduos explicitamente existentes no KB (neste caso a, b e c).
O reasoner Pellet implementa o algoritmo de Tableau para SROIQ (D) e o estende
para aceitar regras SWRL DL-seguras usando
um subconjunto decidível da SWRL
(KOLOVSKI et al., 2006). O reasoner Jena não é um motor de inferência OWL DL, mas sim
um sistema de processamento de regras que podem ser forward- ou backward-chaining, ou
ambos (híbrido). Forward-chaining parte da condição (corpo) para então adicionar de forma
concreta estes novos fatos na base utilizando o algoritmo RETE (FORGY, 1982). Backwardchaining descobre nova informação baseado em objetivo, ou seja, procura regras que possuam
um dado objetivo no consequente e cujo antecedente seja confirmado pelos dados do KB,
utilizando algoritmo de programação lógica (Logic Programming) como resolução (também
aplicada em Prolog). Portanto, a primeira materializa os novos dados e a segunda aguarda
uma pergunta sobre um consequente para então verificar se os dados da base o confirmam.
(EITER et al., 2008)
53
a
{}
a
R
b
{ ∃R.{c}, C, ∃R.B, A }
R
{ ∃R.{c}, C }
R
⇒
R
b
{ ∃R.{c}, C } ∪ { ∃R.B, A }
R
R
y
{ C, ∃R.{c}, ∃R.B, A }
R
c
{ ∃R.B, A }
R
c
{ ∃R.B, A }
C⊑A
R
x
R
R
{B}
x
{B}
Figura 4. Regras DL irrestritas (como transitividade) podem ocasionar resultados inesperados como alterações
imprevistas no TBox.
Apesar de este trabalho utilizar apenas os motores de inferência Jena e Pellet, existem
inúmeros outros. Dentre os disponíveis para OWL, pode-se mencionar FaCT++, HermiT,
RacerPro, JESS, Hoolet, KAON2, OWLIM. Jena, JESS e OWLIM são baseados em regras;
Hoolet utiliza um algoritmo de prova para lógica de primeira ordem; Pellet, FaCT++ e
RacerPro são baseados em Tableau mas enquanto os dois primeiros suportam SROIQ(D), o
último suporta apenas SHIQ(D); KAON2 usa resolução para SHIQ(D); HermiT utiliza o
algoritmo Hypertableau, uma variante do Tableau, também para SROIQ(D). (DENTLER et al.,
2011; LIANG; KIFER, 2009; SINGH; KARWAYUN, 2010)
2.3.3 Web Ontology Language (OWL)
A linguagem OWL, cuja sigla foi construída de forma invertida, nada mais é que uma
lógica de descrição com uma sintaxe variante, ou seja, mapeia os construtos e axiomas
apresentados na coluna “Notação” do Quadro 3 para uma sintaxe RDF. OWL Lite é uma DL
com expressividade SHIF (D), OWL DL é SHOIN (D) e OWL 2 DL é SROIQ (D)
(HORROCKS, I et al., 2006; HORROCKS, IAN et al., 2003). Portanto, considerando-se ZX
como o conjunto de construtos/axiomas suportados por uma dada versão X da OWL, pode-se
dizer que ZOWL-Lite ⊂ ZOWL-DL ⊂ ZOWL2-DL.
Os Quadros 4 e 5 mostram como construtos da notação DL padrão são mapeados para
sintaxe OWL e foram montadas por meio de consultas a diversos artigos e recomendações do
54
W3C (ANTONIOU; HARMELEN, FRANK VAN, 2009; EITER et al., 2008; GOLBREICH;
WALLACE, 2009; MCGUINNESS; HARMELEN, FRANK VAN, 2004; MOTIK et al.,
2009). Os construtos e axiomas que contém OWL Lite marcado com asterisco permitem
apenas classes ou restrições nomeadas, ou seja, não permite expressões usando construtos
como C ⊓ D. Para facilitar o entendimento do quadro, o KB apresentado anteriormente será
transformado para OWL. Assim, o conceito Father do TBox:
Father ≡ Person ⊓ Male ⊓ ∃hasChild.Person
é a interseção entre três conceitos e pode ser escrito em Turtle como:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@prefix : <http://exemplo.com/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:<http://www.w3.org/2002/07/owl#> .
:Person a owl:Class .
:Male a owl:Class .
:hasChild a owl:ObjectProperty .
:Father a owl:Class ;
owl:equivalentClass [
a owl:Class ;
owl:intersectionOf ( :Person :Male [
a owl:Restriction ;
owl:onProperty :hasChild ;
owl:someValuesFrom :Person
] )
] .
onde as linhas 5 e 6 definem que os termos Person e Male são classes e a linha 7 define que o
termo hasChild é um propriedade. As linhas 9 a 17 definem a equivalência entre um novo
conceito Father e a interseção entre os dois conceitos anteriores (Person e Male) e uma
restrição de quantificação existencial completa ∃hasChild.Person. Os fatos do ABox são
definidos da seguinte forma:
18 :JOHN rdf:type :Person ,
19
:Male ;
20
:hasChild :MARY .
21 :MARY rdf:type :Person .
55
Quadro 4. Construtos, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam.
Construtos
Notação DL
Sintaxe OWL
Versão OWL
C1 ⊓ ... ⊓ Cn
[] rdf:type owl:Class ;
owl:intersectionOf (C1 ... Cn) .
OWL DL/Lite*
C1 ⊔ ... ⊔ Cn
[] rdf:type owl:Class ;
owl:unionOf (C1 … Cn) .
OWL DL
¬C
[] rdf:type owl:Class ;
owl:complementOf C .
OWL DL
{a1, … an}
[] rdf:type owl:Class ;
oneOf (a1 … an) .
OWL DL
∀P.C
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:allValuesFrom C .
OWL Lite
∃P.C
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:someValuesFrom C .
OWL Lite
∃P.{a}
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:hasValue a .
OWL DL
≥n P
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:minCardinality n .
OWL DL
OWL Lite (n=0,1)
≤n P
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:maxCardinality n .
OWL DL
OWL Lite (n=0,1)
≥n P.C
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:minQualifiedCardinality n ;
owl:onClass C .
OWL 2 DL
≤n P.C
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:maxQualifiedCardinality n ;
owl:onClass C .
OWL 2 DL
≥n P.D
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:minQualifiedCardinality n ;
owl:onDataRange D .
OWL 2 DL
≤n P.D
[] rdf:type owl:Restriction;
owl:onProperty P ;
owl:maxQualifiedCardinality n ;
owl:onDateRange D .
OWL 2 DL
R¯
[] owl:inverseOf R .
OWL Lite
⊤
owl:Thing
OWL Lite
⊥
owl:Nothing
OWL Lite
56
Quadro 5. Axiomas, seus mapeamentos entre sintaxes DL e OWL e versões da OWL que os aceitam
Axiomas
Notação DL
Sintaxe OWL
Versão OWL
C1 ⊑ C2
C1 rdfs:subClassOf C2 .
OWL DL/Lite*
C1 ≡ C2
C1 owl:equivalentClass C2 .
OWL DL/Lite*
P1 ⊑ P2
P1 rdfs:subPropertyOf P2 .
OWL DL/Lite*
P1 ≡ P2
P1 owl:equivalentProperty P2 .
OWL DL/Lite*
C1 ⊓ C2 ≡ ⊥, C1 ⊑ ¬C2
C1 owl:disjointWith C2 .
OWL DL
C1 ⊓ ... ⊓ Cn ≡ ⊥
[] rdf:type owl:AllDisjointClasses ;
owl:members ( C1 .. Cn) .
OWL 2 DL
P1 ⊓ ... ⊓ Pn ≡ ⊥
[] rdf:type owl:AllDisjointProperty ;
owl:members ( P1 .. Pn) .
OWL 2 DL
C ≡ C1 ⊔ ... ⊔ Cn e
Ci ⊓ Ck ≡ ⊥, onde
1≤i,k≤n e i≠k
C owl:disjointUnionOf (C1 ... Cn) .
OWL 2 DL
⊤ ⊑ ∀P¯.C
P rdfs:domain C .
OWL Lite
⊤ ⊑ ∀P.C
P rdfs:range C .
OWL Lite
P ≡ P¯
P rdf:type owl:SymmetricProperty .
OWL Lite
⊤ ⊑ ≤1 P
P rdf:type owl:FunctionProperty .
OWL Lite
⊤ ⊑ ≤1 P¯
P rdf:type owl:InverseFunctionProperty .
OWL Lite
Tr(P) ou P+ ⊑ P
P rdf:type owl:TransitiveProperty .
OWL Lite
∃P.Self
P rdf:type owl:ReflexiveProperty .
OWL 2 DL
P1 ∘ ... ∘ Pn ⊑ P
P owl:propertyChainAxiom (P1 ... Pn) .
OWL 2 DL
P1 ≡ P2
P1 owl:equivalentProperty P2 .
OWL Lite
{a1} ≡ {a2} ou a1 = a2
a1 owl:sameAs a2 .
OWL Lite
{a1} ≢ {a2} ou a1 ≠ a2
ou {a1} ⊑ ¬{a2}
a1 owl:differentFrom a2 .
OWL Lite
C(a)
a rdf:type C .
OWL Lite
P(a,b)
a P b .
OWL Lite
57
2.3.4 Trabalhos de publicação em LOD
Muitos trabalhos têm explorado o uso das tecnologias da Web Semântica para
descrever e publicar tanto dados de sensores quanto dados estáticos. Redes de sensores vêm
sendo utilizadas como fontes de dados de temperatura, umidade, pressão, etc. (GONG et al.,
2011; SZEWCZYK et al., 2004) e, uma vez inseridas na Web Semântica, podem ser
largamente utilizadas como fonte de dados de contexto. O W3C, por exemplo, abriu um grupo
de trabalho que estudou várias ontologias e produziu a Semantic Sensors Networks (SSN)
Ontology para descrever estas redes (COMPTON et al., 2009; NEUHAUS; COMPTON,
2009).
Dois grandes esforços de publicação de dados em RDF/SPARQL são o Linked Open
Data (LOD) e o Linked Stream Data (LSD). O primeiro é uma iniciativa para publicar dados
ligados e abertos (BIZER, 2009), que podem ser estáticos ou semi-estáticos (mudam com
baixa frequência). Dentre os dados publicados, pode-se destacar DBPedia.org (dados da
Wikipédia), LinkedGeoData.org (do OpenStreetMaps), GeoNames11 e Linked Movie
Database (do Internet Movie Database). O termo LOD pode ser simplificado para Linked
Data quando se tratar de dados privados (por exemplo, dados sigilosos de uma empresa
acessíveis apenas por aplicações usadas por funcionários). Neste trabalho, a sigla LOD
continuará sendo usada para evitar confusão com o termo lógica descritiva (LD). A iniciativa
LSD foi introduzida por Sequeda e Corcho (SEQUEDA; CORCHO, 2009) e propõe uma
forma de identificar e acessar streams de dados oriundos de redes de sensores. Uma
implementação é mostrada por Le-Phuoc et al. (LE-PHUOC et al., 2011) que apresenta o
Linked Stream Middleware (LSM), capaz de publicar dados provenientes de uma grande
quantidade de sensores. A maioria das publicações ainda é feita ad hoc por meio de
programas e scripts, mas arquiteturas começam a aparecer, como mostrado em Cordeiro et al.
(CORDEIRO et al., 2011), que apresenta uma arquitetura de publicação baseada na
ferramenta de ETL Kettle.
Apesar da quantidade de acervos publicados estar aumentando significativamente
desde o início das iniciativas, ainda há diversas questões em aberto (JAIN et al., 2010).
Contudo, esta alta atividade sugere que estas questões serão abordadas em breve e que bases
de dados maiores e de melhor qualidade irão, em breve, prover informação útil, aberta e de
forma padronizada para aplicações cientes de contexto. No âmbito nacional, o fato que
11
GeoNames – geonames.org
58
corrobora esta afirmação é a assinatura por parte da Presidenta Dilma Roussef, em setembro
de 2011 (DOU 16/09/2011), do decreto que institui o “Plano de Ação Nacional sobre
Governo Aberto” (SCHULZE, 2011), fortalecendo ainda mais a crescente tendência de
publicação de dados públicos em prol de um governo mais transparente. Em condições ideais,
órgãos do governo (Bombeiro, Polícia, Defesa civil, etc.) publicam os seus dados de domínio
público, permitindo assim seu consumo automatizado, seja por outras agências do governo ou
por cidadãos.
2.4
Trabalhos relacionados
2.4.1 Frameworks para aplicações cientes de contexto
Diversas abordagens para modelagem e inferência de contexto já foram propostas na
literatura. As primeiras utilizavam pares chave-valor, linguagem de marcação (ex. XML) e
modelos relacionais e/ou orientados a objetos. Alguns trabalhos se valeram de Object Role
Mapping (ORM), outros de ontologias (OWL) e outros construíram modelos híbridos
(BETTINI et al., 2010). Nesta seção, algumas destas arquiteturas serão descritas e
comparadas.
A arquitetura Hydrogen (HOFER et al., 2002) propõe um modelo de contexto
orientado a objetos, dividido em três camadas onde contextos de diversos dispositivos são
compartilhados usando um modelo P2P dispensando o uso de servidores remotos. A camada
Adapter é responsável por ler dados dos sensores físicos e passar para o ContextServer que
armazena e possibilita leituras concorrentes por parte de diversas aplicações que podem estar
no mesmo dispositivo ou não (via P2P).
Context-Aware Sub-Structure (CASS) é uma arquitetura para dispositivos móveis
baseada em um servidor centralizado (FAHY; CLARKE, 2004). Eles separam código da
aplicação e inferência de contexto com o objetivo de simplificar o código e evitar
recompilação a cada modificação de regras (extensibilidade). Segundo esta arquitetura,
sensores são anexados a nós (dispositivos móveis ou estáticos) que se comunicam com
servidores via redes sem fio. Utiliza um banco de dados relacional para armazenamento de
dados e regras.
Context Management Framework é apresentado por Korpipaa et al. (KORPIPAA et
al., 2003). Ele é capaz de reconhecer contexto em tempo real na presença de incerteza, ruído e
informações dinâmicas, e roda em um dispositivo móvel com Symbiam OS. Os valores
59
obtidos dos diversos sensores são quantizados (fuzzy ou crisp) e contextos de baixo nível são
descobertos baseado numa ontologia em RDF predefinida. Contextos de mais alto nível são
derivados usando classificadores Bayesianos. Como resultado, reconhecem mais de 80
contextos com acuraria de 96% em ambientes controlados e 87% no mundo real.
A arquitetura CORTEX utiliza bases relacionais, redes Bayesianas e o sistema CLIPS
para construção do motor de inferência (BIEGEL; CAHILL, 2004). Diferentemente dos
demais, nesta arquitetura cada componente pode ser consumidor e produtor de informação
além de poderem ser organizados de forma descentralizada e em uma rede hierárquica, como
na arquitetura aqui proposta. Contudo, todas estas arquiteturas apresentam a desvantagem de
não poderem ser facilmente integradas no ambiente Web, devido a não utilização de padrões
abertos do W3C. As duas abordagens a seguir, embora não foquem em disponibilidade na
Web, merecem maior destaque por adotarem padrões da Web Semântica.
Gu et al. (GU et al., 2005) apresenta a arquitetura SOCAM (Service-Oriented ContextAware Middleware) que é organizada em três camadas (Figure 5): Context Application Layer,
Context Middleware Layer e Context Sensing Layer. Na última, localizam-se sensores físicos
e virtuais e na de aplicação os agentes, serviços e aplicações que utilizam contextos obtidos da
camada intermediária. A camada intermediária, Context Middleware Layer, é o núcleo da
arquitetura, funcionando como um servidor centralizado capaz de deduzir contexto de mais
alto nível. Mais precisamente, é composta pelos Provedores de Contexto internos e externos
que obtém dados dos sensores físicos e virtuais respectivamente e os converte em
representações RDF/OWL para serem compartilhadas e reusadas. Também possui o
Interpretador de Contexto composto por uma base de conhecimento (KB) e um motor de
inferência responsável por processar os dados de contexto de baixo nível oriundos dos
Provedores de Contexto e inferir contexto de alto nível (com base nas ontologias e em regras
do usuário) assim como detectar inconsistências no KB. A comunicação entre seus
componentes é feita por meio de uma API que usa Java RMI (Remote Method Invocation).
Sua modelagem de contexto utiliza ontologias em dois domínios específicos: veículos
e smart home. Os autores apresentam a ideia de ontologia genérica e específica, onde a
primeira estaria sempre em memória e a segunda seria carregada e descarregada conforme
necessário. Assim, a ontologia de smart home não é carregada enquanto o usuário estiver em
seu carro. A inferência é baseada em lógica de primeira ordem e implementada usando a
ferramenta Jena2. Eles analisaram a desempenho da inferência usando Jena e concluíram que
60
o processo é bastante intensivo computacionalmente e pode ser um gargalo em computação
“pervasiva”, no entanto, é aceitável para aplicações onde o tempo não é crítico.
Figure 5. Visão geral da arquitetura SOCAM (GU et al., 2005).
Por fim, a arquitetura CoBrA (Context Broker Architecture) pretende apoiar a
aquisição, inferência e compartilhamento de conhecimento de contexto em ambientes
inteligentes (CHEN, H.; FININ, T. et al., 2004). Ela está baseada nos conceitos de agente e
broker. Agente é uma entidade capaz de executar alguma tarefa, como aplicações de usuários,
serviços providos por dispositivos, e serviços Web. Nesta arquitetura, o context broker é um
agente especial capaz de gerenciar partes de um espaço inteligente e compartilhar modelos
contextuais entre diversos agentes seguindo uma política de privacidade. O broker é um
dispositivo rico em recursos computacionais capaz de processar as informações dos agentes
ao seu redor. Para aplicações em larga escala como um campus universitário é possível usar
múltiplos brokers para formar uma federação de brokers organizados numa forma P2P ou
hierárquica. Assim como no SOCAM, foi desenvolvida uma ontologia específica para seu
domínio, neste caso, uma sala de reuniões inteligente capaz de representar locais, agentes e
seus contextos. Não aborda disponibilização na Web, comentando apenas, sobre a linguagem
de consulta RDQL, que é predecessora do SPARQL e não mais mantida nem recomendada.
A arquitetura do Context Broker é dividida em quatro componentes conforme
apresentado a seguir (estes e os possíveis agentes ao seu redor podem ser visto na Figura 6):
Context Knowledge Base (Base de Conhecimento de Contexto): uma área para
armazenamento das informações de contexto do espaço inteligente.
61
Context Reasoning Engine (Motor de Inferência de Contexto): responsável por
“raciocinar” sobre a base tanto para inferir novas informações quanto para manter
a consistência do KB.
Context Acquisition Module (Módulo de Aquisição de Contexto): responsável por
adquirir informações de fontes externas como sensores físicos, serviços Web,
bancos de dados, dispositivos e agentes.
Privacy Management Module (Módulo de Gerenciamento de Privacidade):
responsável por aplicar regras de privacidade definidas pelo usuário a fim de evitar
compartilhamento de informações indesejadas.
Figura 6. Representação da arquitetura CoBrA (CHEN, HARRY et al., 2003)
O trabalho apresentado por Lee & Meier (LEE; MEIER, 2009) apresenta uma
arquitetura baseada em um modelo híbrido de contexto que permite organização
descentralizada, em forma de rede para o domínio de transporte. Para isso, propõem uma
mesclagem entre um modelo de contexto orientado a objetos e outro ontológico, de forma que
há um mapeamento direto entre ambos. Modelos orientados a objetos oferecem herança,
modularidade, polimorfismo, encapsulamento, enquanto modelos ontológicos oferecem um
formalismo semântico que permite entendimento compartilhado e inferências. O primeiro foi
denominado PCM (Primary-Context Model) e o segundo PCOnt (Primary-Context Ontology).
Ambos os modelos se baseiam nos contextos primários, onde há um objeto espacial que
62
possui identidade (URI), localização (simbólica ou absoluta), tempo (criação e última
modificação) e qualidade de serviço (confiança, latência e tempo de vida). Para acessar estes
objetos espaciais foi criada uma interface orientada a objetos (Spatial API). PCOnt é dividida
em Upper PCOnt (genérica) e Extended PCOnt (específica). A primeira define os conceitos
supracitados (identidade, tempo, etc.) enquanto a segunda permite expandí-los. Esta técnica
permite distribuir o gerenciamento de ontologias, evitando a manutenção de uma ontologia
única e extensa.
Desta forma, propõem o iTransIT framework, uma arquitetura distribuída, seguindo o
modelo em camadas, para facilitar compartilhamento de dados entre sistemas de transporte
que usam iTransIT e outros legados. O framework adotas camadas Legacy (sistemas legados),
iTransIT (sistemas novos) e Application (aplicações que consomem os dados). A camada
iTansIT é uma federação de sistemas que suportam a API nativamente e wrappers
(conversores) para os sistemas legados. O framework não provê comunicação usando
SPARQL, apenas uma API específica criada por eles e também não menciona tratamento de
dados históricos nem descoberta de recursos e/ou serviços.
O SmartLab middleware (ALMEIDA et al., 2009) possui uma arquitetura em quatro
camadas que utiliza tecnologias da Web Semântica para representar, compartilhar e inferir
contexto de diversas fontes e OSGi para comunicação. Diferentemente de outras abordagens
que precisam que a modelagem da ontologia seja feita na etapa de projeto, este middleware
tem a habilidade de expandir sua ontologia (adicionando conceitos e regras) dinamicamente
ao passo que novos dispositivos se tornam disponíveis no ambiente, fazendo com que
sistemas possam se adaptar aos novos dispositivos em tempo de execução.
A camada Sensing and Actuation possui os diversos dispositivos como câmeras,
sensores, VoIP, etc., e a camda Service Abstration encapsula as funcionalidades de
dispositivos em pacotes OSGi (bundles) que podem ser descobertos pela camada Semantic
Context and Service Management, cuja responsabilidade é gerenciar e raciocinar sobre
contexto usando a ontologia corrente. Esta ontologia é incrementada por esta última camada
que possui módulos para procurar por novos dispositivos, adicioná-los à ontologia (novos
conceitos e regras) e verificar consistência da nova ontologia. A última camada, Management
and Interaction Layer, possui as aplicações que utilizam as informações da camada anterior.
Para que seja possível a descoberta e uso de um dispositivo, é necessário que seu
serviço implemente uma interface (ISmartLabService) que possui métodos para obter
metadados, conceitos, regras e indivíduos necessários para que o novo dispositivo funcione no
63
ambiente SmartLab. A ontologia nesta arquitetura é modelada usando RDF/XML e possui
quatro conceitos principais que são estendidos pelas ontologias de domínio: espaço, tempo,
evento, ator (dispositivos e pessoas). Estes representam pontos, áreas, salas ou construções;
instante, intervalo e relações temporais; ou uma reação a uma mudança de contexto (evento).
Eventos são representados por regras de domínio, que descrevem o comportamento de
aplicações. As regras de elicitação de contexto podem ser semânticas, ou seja, descrever os
modelos RDF e OWL (o framework não aceita DLs) ou podem ser heurísticas que inferem
conhecimento espaçal e temporal. Infelizmente, o trabalho peca em não se aprofundar na
apresentação de como a interação entre os módulos funciona. Além disso, não provê
comunicação usando SPARQL nem menciona tratamento de dados históricos.
O sistema COSAR (RIBONI; BETTINI, 2011a) utiliza inferência híbrida para
reconhecer atividades humanas. Ontologia é usada para validar atividades reconhecidas
estatisticamente e para reconhecer atividades complexas impossíveis para métodos puramente
estatísticos. Assim, definiram uma ontologia de atividades e outros conceitos assim como suas
relações para representar e reconhecer tais atividades simples e complexas. Basicamente,
inferência estatística é usada para pegar dados de sensores e predizer as atividades mais
prováveis, dando probabilidades. Estas são filtradas por inferência ontológica (simbólica)
através da seleção das atividas permitidas baseadas na localização do usuário.
A arquitetura do sistema possui quatro camadas e é um sistema centralizado que
utiliza um dispositivo móvel e servidores para processamento pesado que se comunicam via
rede sem-fio. Na camada mais inferior estão os sensores que coletam dados de sensores nas
roupas do usuário ou no ambiente. A seguir, na camada no dispositivo móvel do usuário
encontra-se o módulo COSAR que captura as medições da camada de sensores via Wi-Fi e
faz a fusão destes. Dados de localização podem ser obtidos diretamente via GPS do
dispositivo ou via RFID ou triangularização GSM quando dados de GPS não estão
disponíveis ou são inacurados (locais fechados). Estes (RFID e GSM) são gerados pelo
chamado Location Server que se encontra na camada de infraestrutura (terceiro nível). Um
sistema GIS efetua a conversão de localização física para simbólica. A camada de
infraestrutura roda em servidores que efetuam classificação estatística e inferência ontológica,
separadamente e possui ainda um provedor de rede para a quarta camada (serviços). Esta
quarta não é bem esclarecida, sendo que na implementação ela encontra-se no próprio
dispositivo móvel.
64
O módulo de classificação estatística é responsável por gerar um vetor com a
probabilidade de cada atividade estar sendo executada pelo usuário a partir dos dados dos
sensores usando um modelo previamente treinado. Para o módulo de inferência ontológica foi
construída uma ontologia OWL 2 DL que modela atividades, artefatos (objetos), pessoas,
localização simbólica (sala, hospital, etc.) e tempo, contendo 35, 43, 4, 30 e 11 subclasses,
respectivamente. Com base nesta ontologia, derivam atividades permitidas em cada local, pela
geração de uma matriz cujas linhas representam localizações simbólicas e colunas
representam atividades, onde o valor corresponde é 1 se uma atividade pode ocorrer em uma
dada localização, e 0 caso não possa. Para detectar a atividade final de um usuário o módulo
COSAR pega a atividade com maior probabilidade em um vetor de atividades modificado.
Este vetor modificado é obtido de duas formas: (1) casando-o com a linha da matriz referente
a localização do usuário, quanto esta é certa, ou (2) unindo linhas da matriz que representam
as possíveis localizações e então casando o vetor com esta linha unida. O casamento é feito
pegando os valores do vetor cuja atividade é permitida pela matriz (possui valor 1).
Atividades complexas são inferidas adicionando-se um ABox contendo atividades mais
simples sendo conhecidamente executadas pelos usuários e suas localizções.
Um comparativo entre as arquiteturas descritas pode ser visto no Quadro 6.
Estas arquiteturas visam auxiliar desenvolvedores a construir de aplicações CC.
Contudo, apesar de fora do escopo deste trabalho, arquiteturas para auxiliar usuários finais
(com vários níveis de conhecimento) a desenvolver estes tipos de aplicações também foram
propostas. Elas aplicam interfaces visuais como iCAP (DEY, A. et al., 2006), máquinas de
estados como UbiPlay (MATTILA; VÄÄTÄNEN, 2006) ou objeto tangíveis como
StoryRoom (MONTEMAYOR et al., 2004). Uma pesquisa sobre estas abordagens pode ser
encontrada em (TANG et al., 2011). Recentemente, (GUO et al., 2011) apresenta uma
arquitetura com a intenção de permitir que tanto desenvolvedores quanto usuários possam
contribuir colaborativamente a desenvolver aplicações CC. Para isso, dispõe de três modos de
programação (incremental, de composição e de parametrização) que permitem editar desde
ontologias e regras (desenvolvedores) até a instanciação das variáveis nestas regras (usuários
iniciantes).
65
Quadro 6. Comparativo das arquiteturas.
Modelagem e
Dados de
Descoberta
processamento de
contexto
de recursos
contexto
históricos
Orientado a objetos;
Três camadas; peerinterpretação e agregação
Não
Não
to-peer
de dados
Banco relacional para
Centralizado
dados e regras; motor de
Não
Sim
inferência
Padrões
abertos W3C?
Disponível na Web?
Apenas XML
Não, mas troca
informações via TCP/IP
Não
Não, mas troca
informações via redes
sem fio
Apenas RDF
Não, pois não é focado na
infraestrutura
Não
Não
RDF(S), OWL
Não, comunicação via API
RMI do Java.
CoBra
Chen, H. et al.
(2004)
RDF(S), OWL
Não menciona
iTransIT
Lee, Meier
(2009)
RDF, OWL
Sim, API própria
Camadas,
federação
RDF, OWL
Sim, OSGi
RDF, OWL
Não, comunicação
apenas entre módulos
RDF(S), OWL,
SPARQL
Sim, com protocolos
HTTP e SPARQL
Arquitetura
Hydrogen
Hofer et al.
(2002)
CASS
Fahy & Clarke
(2004)
CMF
Korpipaa et al.
(2003)
CORTEX
Biegel & Cahill
(2004)
SOCAM
Gu et al.
(2005)
Almeida et al.
(2009)
COSAR
Riboni & Bettini
(2011)
LOUD
2.4.2
Arquiteturas para integração de dados na Web
Organização
RDF, lógica fuzzy e crisp,
redes Bayesianas
Sim
Não
Banco relacional; redes
Bayesianas, CLIPS
Sim
Sim
RDF, ontologias e regras de
inferência
Sim
Sim
Agentes (brokers);
RDF, ontologias e regras de
federação de
inferência
brokers
Não
Sim
RDF, ontologias, orientado
a objetos
Não
Não
Camadas,
centralizado
RDF, ontologias e regras de
inferência dinâmicas
Sim
Não
Camadas,
centralizado
RDF, ontologia OWL-DL e
estatística
Não
Sim
Centralizado
Em rede,
hierárquica e
descentralizado
Três camadas;
servidor
centralizado
Camadas, em rede, RDF, ontologias e regras de Não, mas
hierárquica e
inferência (outros serão
possível
descentralizado
possíveis)
futuramente
O framework deste trabalho, apesar de ter sido planejado para prover dados para
aplicações CC, também se apresenta como um módulo para integração de dados de diversas
bases na Web. Portanto, alguns trabalhos com este intuito são apresentados nesta seção.
O projeto Active XML, apresenta um framework onde arquivos XML contendo
chamadas a serviços Web permitem integrar informação externa através de uma arquitetura
P2P (ABITEBOUL et al., 2007). Um framework conceitual para integrar dados geográficos
usando ontologias de domínio e de aplicação e mapeamentos entre elas é apresentado por
Vidal et al. (VIDAL et al., 2009). O primeiro trabalho não usa padrões da Web Semântica
(WS) e o segundo não chega a experimentar a proposta. Em Omitola et al. (OMITOLA et al.,
2010), é relatada a experiência de converter dados governamentais do Reino Unido dos
formatos HTML, XML e planilhas para LOD, e a junção destes dados com dados geográficos
já existentes na nuvem LOD. A aplicação desenvolvida consome dados do SPARQL endpoint
gerado e permite que o usuário visualize as informações pertinentes à sua localização
Sim
66
geográfica. Não provêm ferramentas para publicação de bases nem para integração, sendo o
processo feito por meio de scripts.
Integração na Web Semântica pode ser obtida por meio de consultas SPARQL
federadas que podem ser de três formas: repositório central, múltiplos repositórios usando
suas API nativas e múltiplos repositórios via SPARQL endpoints (HAASE et al., 2010). Esta
última é implementada por Langegger et al. (LANGEGGER, 2008; LANGEGGER et al.,
2008) no Semantic Web Integrator and Query Engine (SemWIQ), um endpoint virtual onde
diversos endpoints podem se registrar para serem consultados de forma transparente. Com ele,
um cliente pode executar uma consulta neste endpoint virtual que se encarrega de construir
consultas para cada endpoint registrado. Segundo Haase et al. (HAASE et al., 2010) esta
forma apresenta altos tempos de execução de consultas devidos ao atraso da rede, enquanto a
primeira apresenta os melhores. Contudo, a principal vantagem de usar um repositório central
é a possibilidade de executar inferências, recurso que os trabalhos citados não permitem.
Quanto ao uso de inferência, Winkels et al. (WINKELS et al., 2010) apresenta um
trabalho que utiliza dados geográficos para verificar o cumprimento de normas quanto ao uso
de terras. Apresentam uma ontologia OWL com conceitos região e região conflitante,
permitindo identificar descumprimento de uma norma. Porfim, apresenta um mashup que
consome SPARQL e apresenta informações em um mapa. Em Della Valle et al. (DELLA
VALLE et al., 2009), apresenta-se um framework para disponibilizar dados geográficos como
grafos RDF virtuais visando aproveitar algoritmos já existentes através de um conversor de
SPARQL para SQL configurado por uma linguagem de mapeamento. Obtenção de dados
adicionais limita-se a consultas à DBPedia
e ao Flickr. Permite realização limitada de
inferências usando Jena. Em Koutsomitropoulos et al. (KOUTSOMITROPOULOS et al.,
2010), um framework para inferência descentralizada e distribuída usando uma API Java que
opera remotamente é apresentado. Contudo, não provê um SPARQL endpoint para acesso por
parte de aplicações. Mostra que em processamentos pesados como classificação, o tempo de
processamento supera o atraso da rede, comprovando o benefício de ter um servidor dedicado
à inferência, enquanto o cliente apenas se comunica com o servidor.
Percebe-se que existem trabalhos que se assemelham com essa proposta. No entanto,
este trabalho se diferencia pelo módulo descentralizado, facilmente configurável que consome
dados de bases LOD, executa inferência sobre estes dados e disponibiliza dados derivados
como um novo SPARQL endpoint.
67
3
3.1
LOUD – Linked Open Ubiquitous Data
Introdução
Este capítulo apresentará o Módulo de Inferência proposto para resolver o problema
específico descrito na seção 1.3 e um esboço da arquitetura LOUD (Linked Open Ubiquitous
Data) proposta para solucionar o problema mais amplo descrito na seção 1.2. A arquitetura
LOUD ainda se encontra em estado inicial de idealização devido ao fato de ser bastante ampla
e não poder ser completamente desenvolvida em uma única dissertação de Mestrado. Assim, a
seção 3.2 apresentará a arquitetura LOUD, e a seção 3.3 descreverá o Módulo de Inferência,
parte que será desenvolvida de fato neste trabalho.
3.2
Arquitetura LOUD
3.2.1 Objetivos
A arquitetura visa utilizar as técnicas e padrões da Web Semântica e Dados Ligados
para facilitar o desenvolvimento de aplicações cientes de contexto. Pretende-se disponibilizar
módulos de informação contextual descentralizados para acesso por parte destas aplicações.
Estes módulos devem ser capazes de consultar bases de triplas que contenham dados
estáticos, de sensores e/ou de contexto de mais alto nível existentes na nuvem e processar
estas informações usando os mais variados mecanismos. Ao permitir variados mecanismos de
processamento, um em cada módulo independente, a arquitetura mostra-se coerente com
modelos híbridos. Tudo isso deve ser feito de forma a facilitar tanto a reutilização de
vocabulários, ontologias e regras de inferência de contexto, quanto o mapeamento entre
conceitos e relacionamentos. Por fim, pretende-se impulsionar a produtividade de tais
aplicações a partir da especificação de passos a serem seguidos pelo desenvolver.
3.2.2 Estrutura
A versão inicial da arquitetura é organizada em três camadas conforme apresentado na
Figura 7. Elas serão mais bem detalhadas nas subseções a seguir, contudo cabe ressaltar que
cada módulo, representado por uma caixa, recebe configurações, mas estas foram omitidas da
figura e, no caso da camada intermediária serão apresentadas na seção 3.3.3. Observe que as
68
setas entre componentes da figura mostram o fluxo de dados (exceto de configuração) de
modo que consultas (requisições por dados) circulam no sentido inverso das setas enquanto
que os dados de resposta circulam no sentido direto. Segue uma breve descrição de cada
camada:
Camada de dados e sensoriamento – responsável por obter, armazenar e fornecer
dados de sensores físicos, bases de dados e perfis do usuário.
Camada de Inferência – composta por uma rede de módulos responsáveis por
consumir informações da camada de dados e sensoriamento ou de outros módulos
da camada de inferência e realizar inferência de contextos, ações e notificações.
Camada de Aplicação – consome dados das camadas anteriores e é responsável
por interagir com o usuário podendo gerar regras para a camada de inferência
conforme solicitações do usuário; agentes computacionais (não-humanos) e
Legenda:
Aplicação
Aplicação
Aplicação
Fluxo de dados (exceto
de configuração):
Publicação
Publicação
Armazenamento
Processamento
Armazenamento
Processamento
Consumo
Consumo
Consultas no sentido
inverso das setas
Dados de resposta no
sentido direto
Publicação
Publicação
Armazenamento
Processamento
Armazenamento
Processamento
Consumo
Consumo
Endpoint
Endpoint
Base LOD
Base LOD
Sensoriamento
Dados
Inferência
Aplicação
mashups também poderiam compor esta camada.
Endpoint
Sensor Físico
Figura 7. Arquitetura LOUD com suas três camadas e módulos que podem atuar como produtores e consumidores.
Entradas para configuração dos módulos foram omitidas.
3.2.2.1 Camada de dados e sensoriamento
Esta camada é formada por módulos que devem disponibilizar SPARQL Endpoints
para consulta, mas que podem diferir complemente na forma como obtém seus dados. Sendo
assim, são classificados em módulo de dados e módulo de sensoriamento.
69
O módulo de sensoriamento adquire dados de sensores físicos heterogêneos, que
podem ser locais ou remotos. No caso de sensores locais, o dispositivo do usuário deve estar
executando um módulo de sensoriamento ou inserir seus dados em um existente na nuvem.
Os módulos desta camada podem utilizar técnicas estatísticas, redes Bayesianas, lógica
nebulosa, etc. para tratamento de dados, que reduzam a incerteza antes de disponibilizá-los à
camada de inferência. O módulo na parte inferior direita da Figura 7 poderia ter, por exemplo,
um classificador que filtraria amostras obtidas de um microfone (sensor físico).
O módulo de dados executa a função de publicar dados estáticos ou que mudam com
baixa frequência, adquiridos de bases de dados e perfis de usuário. Sendo assim, fornecem
dados de guias de ruas, serviços públicos, pontos de interesse, preferências do usuário, etc.
Estes dados podem ser mapeados diretamente de bancos de dados relacionais ou armazenados
em repositórios de triplas. Note que estes módulos não precisam ser construídos do zero, pois
já vem sendo implementados na iniciativa de Dados Ligados.
3.2.2.2 Camada de Inferência
Esta camada é a mais próxima do foco deste trabalho. Ela se organiza como uma rede
de módulos, a saída de um é ligada à entrada de outro, capazes de realizar inferência sobre
dados de outras fontes com base em procedimentos (como ontologias, regras, programas
imperativos, etc.) definidos pelo desenvolvedor. Basicamente, cada módulo carrega dados de
um ou mais SPARQL Endpoints (módulos da camada de dados e sensoriamento ou da
camada de inferência), processa estes dados e disponibiliza os resultados através de seu
próprio endpoint (Figura 7). Assim, podem-se identificar três etapas realizadas: carregamento,
processamento e publicação.
A etapa de carregamento de dados é realizada por meio de consultas SPARQL. Já
nesta etapa é possível algum processamento utilizando consultas SPARQL Construct. As
consultas e suas configurações (URL de acesso dos endpoints, a frequência com que as
consultas devem ser executadas, etc.) devem ser facilmente definidas pelo desenvolvedor. Os
dados obtidos são armazenados em uma base intermediária.
A etapa de processamento permite utilizar os dados armazenados na base
intermediária, e seguindo algum algoritmo de processamento descobrir novas informações e
adicioná-las à base intermediária ou modificar informações existentes. No estágio atual,
almeja-se apenas inferência usando ontologias OWL e/ou regras definidas pelo
desenvolvedor. Atualmente, identificam-se quatro tipos de tarefas de processamento:
70
Mapeamento vocabulário-ontologia (MVO)
Mapeamento inter-ontologias (MIO)
Inferência de contexto de mais alto nível (ICAN)
Geração de recomendação (GR)
Ontologias devem seguir os padrões RDFS e/ou OWL e precisam ser cuidadosamente
desenvolvidas para atender os requisitos de expressividade do domínio em questão. Por esta
razão serão denominadas ontologias de domínio (ODs). Regras também podem ser utilizadas,
visto que OWL ainda possui carências de expressividade. Contudo ao desenvolver ontologias
e regras deve-se atentar para manutenção da consistência e decidibilidade (veja seção 2.3.2).
Retornando às tarefas de processamento, o MVO é necessário quando vocabulários de
bases externas não são adequados para inferência, mapeando, assim, conceitos destes
vocabulários para ODs. O MIO permite reutilizar ODs existentes, através da definição de
relações entre conceitos e propriedades. Assim, caso exista mais de uma OD, a mais adequada
pode ser adotada e conceitos das demais mapeados para conceitos da OD utilizada.
A ICAN permite deduzir contexto de mais alto nível pela combinação de contextos de
mais baixo nível, dados de bases, de perfis de usuário e de sensores físicos. Exemplos são
descobrir bairro ou cidade a partir das coordenadas geográficas do usuário ou se uma pessoa
tem algum amigo ou parente fazendo aniversário em determinada data. Na seção 2.3.2.5 é
apresentado um exemplo de ICAN utilizando regras (não representável em OWL 2 DL) para
deduzir a atividade de um usuário (MeetingSupervisor).
Já a GR é responsável pela geração de recomendações, que podem ser ações para a
aplicação ou notificações ao usuário. Exemplos seriam notificar usuário sobre aniversário de
um amigo, executar a ação de comprar um livro quando determinadas condições definidas
pelo usuário acontecem (disponibilidade de um título, preço, etc.), ou executar a ação de
colocar o celular em estado vibratório ao entrar em uma sala de cinema ou de reunião.
O processamento mais elaborado é feito usando ontologias e regras, mas é possível,
logo no carregamento, usar SPARQL Construct para fazer alguns mapeamentos (MVO e
MIO) e até mesmo ICAN e GR. Uma vez concluído este processo, a etapa de publicação
disponibiliza um SPARQL endpoint na nuvem de LOD com os dados derivados gerados na
etapa de processamento. Por fim, esta camada poderia ser expandida ou uma quarta camada
poderia ser adicionada para contemplar outras possíveis necessidades.
71
3.2.2.3 Camada de Aplicação
Como o nome sugere, as aplicações estão nesta camada. Ela interage diretamente com
o usuário final, sendo responsável por fornecer a interface de comunicação com o usuário e
também de obter seu perfil (gostos, interesses, e outras informações que sejam úteis para a
aplicação) sendo, portanto, pouco generalizável. Os dados sobre o perfil do usuário podem
estar nesta camada caso o perfil seja armazenado pela aplicação, ou podem estar na camada
de dados caso o perfil fique em um endpoint remoto.
Espera-se que o desenvolvedor da aplicação precise apenas criar a interface com o
usuário, algumas consultas a módulos da camada anterior e controlar a interação.
Necessidades do usuário e da aplicação podem ser expressas por tais consultas ou regras
dentro de módulos de inferência externos, ou seja, não manipuláveis diretamente pela
aplicação. Neste caso, é necessário usar regras parametrizadas nestes módulos.
Exemplificando, considere uma regra para geração de uma ação de compra de livros (GR) que
considera assunto e preço. Neste caso, pode-se ter uma única regra genérica que dispara a
ação “comprar” quando assunto e preço (oriundos do perfil do usuário) coincidem com bases
de livrarias. Desta forma, nem assunto nem preço podem ser fixados na regra, pois podem
variar drasticamente ao longo do tempo. Sendo assim, o módulo que contém esta regra precisa
realizar consultas que obtenham estes dados de perfis do usuário situados na camada de
dados. No final, a aplicação precisa apenas atualizar o endpoint que armazena tais dados e o
módulo se encarrega de obtê-los. Em um estágio futuro, regras poderão ser passadas
diretamente à camada de inferência por meio de uma biblioteca fornecida pela arquitetura que
gerencie as transferências e a comunicação entre as duas camadas, tornando-as mais
dinâmicas. Adicionalmente, agentes computacionais e mashups também poderiam participar
desta camada, mas isto não está no escopo deste trabalho. O conceito de agente foi discutido
no início da seção 2.3 e na arquitetura CoBra na seção 2.4.1.
3.2.2.4 Discussão quanto aos requisitos do problema
O uso de serviços Web convencionais exige que o desenvolvedor construa conversores
de formato e tradutores para entendimento do significado das respostas do serviço, de forma a
casá-las com os conceitos usados por sua(s) ontologia(s) de domínio, quando há tais
ontologias. Portanto, a pura adoção de formatos e protocolos padronizados pelo W3C para
comunicação já parece beneficiar a interoperabilidade, mas, o descasamento semântico
ainda prejudica este requisito. No entanto, uma vez que os formatos sejam comuns, técnicas
72
de mapeamento entre os conceitos (MVO e MIO) se tornam mais simples. Acredita-se
também, que a utilização de módulos previamente configurados e/ou de mapeamentos evite a
criação ou modificação desnecessária de ontologias e vocabulários permitindo seu reuso.
Apesar de tudo, não se deve impedir programação quando necessário.
O uso de camadas fracamente acopladas e componentes descentralizados permite que
estes rodem em máquinas e dispositivos distintos. Isto é importante para o uso de dispositivos
móveis, necessários para atender os requisitos da Computação Ubíqua. Assim, uma aplicação
em um dispositivo móvel pode ter o processamento pesado executado em servidores na
nuvem de forma descentralizada e até mesmo distribuída. Aplicações mais simples podem
ficar autocontidas no próprio dispositivo móvel.
Com esta arquitetura, espera-se que não seja necessário que o desenvolvedor de
aplicações CC defina e implemente tudo que precise (desde fontes de sensores e formatos de
dados até ontologias e processadores). Assim, ao desenvolver uma aplicação ele pode
aproveitar conjuntos de dados da nuvem LOD, consultas, ontologias e regras já existentes
para seu domínio de aplicação e até mesmo módulos que já estejam funcionando na nuvem.
Caso não exista um módulo disponível na nuvem que atenda todas as suas necessidades, o
desenvolvedor de aplicação poderia se concentrar em:
1. Determinar ontologia(s) de domínio utilizada(s) na camada de inferência (ODs);
2. Determinar os endpoints que sirvam como fontes de dados (LOD, sensores ou
módulos que atendam parcialmente), seus vocabulários e ontologias, e consultas
SPARQL para obter os dados;
3. Mapeamento entre os vocabulários/ontologias das fontes e as ontologias de
domínio (MVO e MIO);
4. Regras para inferência de contexto (ICANs) e geração de recomendações (GR);
5. Se concentrar na interface com o usuário da aplicação.
Consequentemente, estes fatores (reuso, interoperabilidade e poucas etapas) devem
levar a um aumento de produtividade se comparados às técnicas abordadas na literatura
(criação de modelo de contexto e ontologias específicos para a aplicação). Esta arquitetura
está em estado inicial e deverá sofrer modificações, como adição de novos módulos,
componentes e até camadas.
73
3.3
Escopo do trabalho: o Módulo de Inferência
Esta seção apresentará detalhadamente o Módulo de Inferência, foco deste trabalho,
como possível solução para o problema específico descrito na seção 1.3. Este módulo é parte
da camada de inferência da arquitetura LOUD. O módulo pode ser configurado para ser capaz
de carregar dados de várias fontes via SPARQL, processar estes dados usando OWL e regras
definidas pelo usuário e prover seus dados a outros por meio de um SPARQL endpoint.
Instâncias deste módulo na nuvem poderiam ser representadas na nuvem de LOD 12 como um
quadrado em vez de um círculo para mostrar que há processamento de inferência.
As camadas de aplicação e de dados e sensoriamento não estão no escopo deste
trabalho, sendo assim, apenas o necessário para experimentos será construído: prover
SPARQL Endpoints e aplicações para visualização sem aprofundamento. Módulos de
sensoriamento serão simulados, isto é, não serão utilizados sensores de fato, mas apenas
dados crus (raw data) históricos que tenham sido obtidos de sensores reais ou dados
simulados de sensores fictícios. Estes dados servirão de base, juntamente com dados
provenientes de módulos de dados para inferências de contexto de mais alto nível. Os
módulos de dados conterão triplas de dados oriundos de bancos de dados relacionais (triplas
virtuais) ou de repositórios de triplas (triplas materializadas). Aplicações que possam
porventura ser construídas servirão apenas para visualização de dados das camadas inferiores,
nunca voltados para interação com o usuário.
As subseções a seguir apresentarão o estrutura interna do Módulo de Inferência, sua
implementação e configuração.
3.3.1 Estrutura
Este módulo é dividido em quatro componentes conforme apresentados na Figura 8 e
descritos nas próximas subseções. Maiores detalhes sobre etapas internas e iterações entre
componentes serão abordadas na seção 3.3.1.5.
12
Linked Data Cloud - http://lod-cloud.net/
74
Interface Web
SPARQL Endpoint
Legenda:
Direção do fluxo
de triplas RDF
Motor de Inferência
Ontologias & Regras
Base de
Armazenamento
Comunicação
bidirecional: motor de
inferência lê dados da
base e adiciona novas
triplas RDF na base
Carregadores de Dados
Figura 8. Estrutura interna do módulo de inferência. A seta dupla (comunicação bidirecional) é representada para fins
didáticos, pois a base pode conter triplas virtuais, geradas sobre demanda quando há uma consulta (recomenda-se a
leitura sobre Jena e Pellet na seção 2.3.2).
3.3.1.1 Carregadores de dados
O componente de carregamento é, na verdade, um conjunto de subcomponentes que
rodam paralelamente, de forma que cada um encarrega-se de executar consultas SPARQL e
obter dados de um único endpoint externo de forma síncrona ou assíncrona. O primeiro
método é também conhecido como pull de forma que o carregador envia uma consulta
SPARQL e permanece bloqueado até que o endpoint consultado retorne a resposta. Pode-se
configurá-lo de maneira que cada carregador tenha o endereço do endpoint externo, as
consultas a serem executadas contra este endpoint, a frequência de cada uma delas e possíveis
substituições de variáveis. O segundo método é denominado push (ou publish/subscribe) e
pode ser encontrado em (PASSANT; MENDES, 2010). Basicamente, ele funciona de forma a
não bloquear o carregador até receber a resposta de uma consulta, ou seja, o carregador é
acionado por eventos assíncronos. Para isso, o carregador se registra no servidor SPARQL
fornecendo o evento, a consulta a ser executada quando este evento ocorrer no servidor e um
ponto de retorno que receberá os resultados.
Este segundo método pode ser usado para lidar com dados dinâmicos de sensores ou
redes de sensores, de forma que os dados oriundos do sensoriamento podem ser recebidos de
forma assíncrona, ou seja, sem intervalos de tempo pré-definidos. Esta funcionalidade é
importante, pois comunicações assíncronas são comuns em redes de sensores que são
comumente utilizadas para monitorar eventos físicos. O método também pode ser aplicado ao
consumir dados de outros módulos de inferência, ou seja, o módulo de inferência fonte geraria
um evento ao, por exemplo, deduzir um novo contexto. Atualmente, apenas operações
síncronas são possíveis, mas operações assíncronas deverão ser permitidas no futuro.
75
A substituição de variáveis (variable binding) permite a construção de consultas
parametrizadas, ou seja, que podem ter parâmetros com valores definidos dinamicamente.
Assim, pode-se ter uma consulta com uma variável que é substituída, por exemplo, com a data
e hora do momento de execução da mesma, ou com dados provenientes de outras consultas. O
elemento responsável por fazer estas substituições é aqui denominado binder. Desta forma,
antes de um carregador executar uma consulta, ele aciona o binder associado a ela que pode
retornar até mesmo mais que uma consulta a ser executada pelo carregador. Neste caso, a
consulta funciona como um modelo para a geração de várias consultas semelhantes, mas com
valores diferentes nas variáveis substituíveis. O uso de binders poderia, em parte, ser
substituído por SPARQL federado, mas devido ao pouco suporte atualmente, problemas de
travamento durante testes e de estar fora do escopo isto não foi implementado.
Dois tipos de consultas SPARQL são permitidos: DESCRIBE e CONSTRUCT.
Ambas podem ter variáveis substituídas. A primeira descreve um ou mais recursos, ou seja,
retorna todas as triplas tais que estes recursos são sujeitos, exatamente como estão na base
consultada. A segunda forma permite mudar o padrão do grafo de resultado da consulta sem
alterar o grafo da base consultada e, por este motivo, pode ser utilizada para certos
mapeamentos conforme citado na seção 3.2.2.2. O resultado das consultas de cada carregador
é guardado por cada um para posterior inserção na base de armazenamento intermediário.
3.3.1.2 Base de armazenamento intermediário
O componente de armazenamento é um conjunto de grafos RDF independentes usados
em várias fases. Primeiramente, armazena as triplas obtidas pelo componente de
carregamento, a seguir o processo de inferência é feito sobre estes dados e, finalmente, o
endpoint publica esta base. A criação de grafos intermediários é tratada pelas aqui
denominadas políticas de atualização. Por exemplo, uma política “limpe e insira” poderia usar
uma base vazia na fase pré-carregamento (grafo inicial) e eliminar dados intermediários após
a inferência e antes de publicar. Outra política poderia manter alguns dados anteriormente
publicados como grafo inicial e manter os dados intermediários gerados durante a inferência
para publicação.
Esta base pode ser armazenada em memória principal, em disco local ou até mesmo
em cluster ou na nuvem conforme a necessidade, e também numa combinação destes. Mas é
importante salientar que o segundo e terceiro casos são mais comuns para bases maiores e
podem ser insatisfatórios, com respeito a desempenho e tempo de resposta, para executar
76
inferências. Por este motivo apenas bases em memória principal estão sendo consideradas
neste trabalho.
3.3.1.3 Motor de Inferência ou Reasoner
O componente de inferência permite processar o grafo de dados pós-carregamento
(grafo inicial mais grafo com resultado das consultas) com base em ontologias OWL e regras
definidas pelo projetista/desenvolvedor. Uma nova inferência é executada quando algum
carregador detecta novos dados. Neste trabalho não haverá distinção formal entre os tipos de
processamento que podem ser efetuados (MVO, MIO, ICAN e GR, vide seção 3.2.2.2) visto
que do ponto de vista do módulo de inferência a distinção está apenas na forma de construção
utilizada: SPARQL Construct, ontologias OWL e regras IF-THEN. Assim, é possível dizer,
por exemplo, que Pessoa e Person são classes equivalentes (MIO) de três formas distintas,
mas com igual significado:
1. CONSTRUCT { ?uri a x:Pessoa ; a y:Person . }
WHERE { ?uri a x:Pessoa . }
2. x:Pessoa owl:equivalentClass y:Person .
3. ?uri a x:Pessoa  ?uri a y:Person .
Na primeira forma, utiliza-se SPARQL Construct no componente de carregamento, de
forma que a existência de um recurso do tipo x:Pessoa na base consultada, determina que este
recurso também será uma instância de y:Person na base do módulo que consulta. A segunda
utiliza a propriedade simétrica e transitiva owl:equivalentClass da linguagem OWL (seção
2.3.3). A terceira utiliza uma regra IF-THEN, similar a primeira forma usando SPARQL, mas
que não requer repetição da afirmação que o recurso é instância de x:Pessoa, visto que esta
afirmação já se encontra na base. Pode-se notar também que, a segunda forma difere das
demais por não relacionar instâncias diretamente sendo perfeitamente compatível com
reasoners DL. Contudo, se for usado um sistema de inferência baseado em regras e sem
regras para os axiomas OWL, é necessário tratar as instâncias adicionando-se as seguintes
regras (prefixo owl omitido):
2.1.
?c1 equivalentClass ?c2  ?c2 equivalenteClass ?c1
2.2.
?c1 equivalentClass ?c2 , ?c2 equivalentClass ?c3  ?c1 equivalenteClass ?c3
2.3.
?c1 equivalentClass ?c2 . ?x a ?c1 .  ?x a ?c2
77
A regra 2.1 fornece a simetria e a regra 2.2 garante a transitividade, enquanto a regra
2.3 é a forma genérica da regra expressa na terceira forma. Desta forma, estas três regras
genéricas reduzem significativamente a quantidade de regras a serem escritas quando há
muitas classes. Exemplo: considerando classes C 1 a C2n, onde Ci é equivalente a Cj, com i
ímpar e j = i + 1, seriam necessárias 2n regras usando instâncias, e nenhuma regra adicional
usando 2.1, 2.2 e 2.3. Neste segundo caso seria necessário, contudo, definir os n axiomas
owl:equivalentClass. Para C1 a C3n, com Ci equivalente a Ci+1 equivalente a Ci+2, e i = {1, 4, 7,
... } tem-se 3n regras contra 2n axiomas.
3.3.1.4 SPARQL Endpoint
O Sparql Endpoint é o quarto e último componente do Módulo de Inferência e permite
que a aplicação e/ou outros módulos da camada de inferência acessem o conteúdo da base
local usando o protocolo SPARQL do W3C. Assim, o módulo mantém um protocolo
padronizado tanto na entrada (componente de carregamento) quanto na saída, permitindo que
diversos módulos de inferência formem uma rede sendo cada um responsável por uma
pequena parte de todo processamento. Uma interface para navegadores Web (página HTML)
também é disponibilizada para navegação básica e executação de consultas.
Após dados serem carregados e o motor de inferência ser acionado, o endpoint é
atualizado. Para que estes novos dados estejam disponíveis para consulta por terceiros, duas
formas de atualização foram planejadas. A primeira publica a mesma base usada pelo sistema
de inferência. A segunda copia toda a base usada pelo sistema de inferência para uma segunda
base contendo as triplas materializadas. Enquanto no primeiro caso há o benefício da
publicação de novos dados mais rapidamente, no segundo há o benefício de se poder
aproveitar de índices construídos pelo banco de triplas. No entanto, no primeiro caso, toda
consulta pode provocar algum processamento lógico parcial, e no segundo caso, a cópia pode
ser bastante demorada visto que todo o processo de inferência precisa ser executado de uma
vez, podendo ser uma péssima escolha quando a atualização da base é muito frequente.
Devido ao fato de ambos possuírem prós e contras, a definição de qual método adotar é
definida pelo desenvolvedor no arquivo de configuração.
3.3.1.5 Estrutura de funcionamento
Nas seções anteriores, cada componente foi apresentado separadamente. Nesta seção,
as iterações e as etapas internas serão mais detalhadas.
78
A Figura 9 apresenta um diagrama de atividades do funcionamento do módulo.
Primeiramente, o arquivo de configuração é lido e processado, para então se iniciar o endpoint
e os carregadores de dados. A partir deste momento, tanto o fluxo principal (à esquerda)
quanto os fluxos dos carregadores (no centro) ocorrem paralelamente. Apesar de a figura
apresentar apenas um fluxo de carregador, vários podem executar paralelamente em suas
respectivas threads. Quando um carregador obtém novos dados, ele ativa um sinal que pode
ser percebido pelo fluxo principal e este executa o motor de inferência registrado. Em vez de
o fluxo do carregador gerar um evento que dispara o reasoner diretamente, é o fluxo principal
que percebe a ativação do sinal e executa o reasoner. Assim, se dois sinais forem gerados por
diferentes carregadores num pequeno intervalo de tempo, a inferência executa apenas uma vez
com os dados de ambos. Consequentemente, se durante uma inferência outros carregadores
ativarem o sinal, nenhuma inferência adicional será executada em paralelo. Isto é
particularmente útil no caso em que o tempo de inferência é maior que o intervalo entre
consultas, evitando maior sobrecarga na máquina executante. Isto pode ocorrer devido a uma
configuração equivocada (intervalo muito pequeno), devido à sobrecarga do processador da
máquina ou mau dimensionamento de recursos. Quando a inferência termina, o endpoint é
atualizado conforme a forma de atualização definida na configuração.
Figura 9. Diagrama de atividades do módulo de inferência
79
Em relação a um carregador, o fluxo central da Figura 9 apresenta três etapas. Na
primeira, as consultas podem ter suas variáveis substituídas (variable binding) por valores
conforme configuração fornecida. Isto pode gerar uma ou mais consultas que são executadas
em sequência e seus resultados unidos em um único grafo. Uma vez que todos os dados foram
obtidos, o carregador ativa seu sinal de aviso de modificação.
Por fim, as etapas internas da atividade de inferência (à esquerda) são detalhadas no
fluxo à direita (ligadas por um linha tracejada). Este fluxo está estreitamente relacionado às
políticas de atualização anteriormente citadas, responsáveis por criar os grafos intermediários
conforme pode ser visto nas atividades de obtenção do grafo inicial ou pré-carregamento, do
grafo pré-inferência ou pós-carregamento e, por fim, do grafo para publicação.
A atividade de obtenção do grafo pré-carregamento recebe o grafo atualmente
publicado (GPUB), que é vazio na primeira iteração, e retorna o grafo inicial (G0) construído
conforme a política de atualização. Em seguida, a segunda atividade reúne os resultados das
consultas dos carregadores (GRC[i]) em um grafo GRC, onde a quantidade de operações de
união depende da quantidade de carregadores existentes e, por fim, G0 é adicionado a GRC. A
próxima atividade constrói o chamado grafo antes da inferência (G AInf) a partir dos grafos
GPUB e GRC, permitindo, assim, adicionar ou remover triplas antes da execução da inferência.
A quarta atividade, finalmente, realiza a inferência sobre os dados do G AInf utilizando as
ontologias e regras definidas, produzindo então o grafo da inferência (G INF). Apesar de já
haver pesquisas em inferência incremental, ou seja, aquela que não requer processamento para
toda a base de dados, apenas para a parte modificada, as ferramentas que a fazem ainda estão
em estágio inicial, e por isso, o assunto não entrou no escopo deste trabalho (GESSLER et al.,
2009; SIRIN, EVREN et al., 2007). As duas últimas etapas são a construção do grafo para
publicação (GPUB) a partir de GPUB, GRC e GINF e, finalmente, a atualização do endpoint. O
algortimo pode ser visto a seguir:
1
2
G0 := get_initial_graph(GPUB)
GRC := {}
3
Para cada carregador i faça GRC := GRC ∪ GRC[i]
4
5
6
7
8
GRC := GRC ∪ G0
GAInf := get_graph_before_reasoning(GPUB, GRC)
GINF := do_reasoning(GAInf)
GPUB := get_publishing_graph(GPUB, GRC, GINF)
update_endpoint(GPUB)
Nota-se que, se a política de atualização for eficiente, como por exemplo, sempre
retornar um grafo vazio ou já existente (GPUB, GRC e GINF, nas etapas grafo inicial, grafo antes
80
da inferência e grafo para publicação, respectivamente), os pontos que poderiam gerar
gargalos são:
a) Criação do GRC (linhas 2, 3 e 4 do algoritmo);
b) Inferência (linha 6) e;
c) Atualização do endpoint (linha 8).
O ponto (a) tende a ser linear conforme a quantidade de triplas. No caso (b), o sistema
de inferência geralmente executa apenas um rápido pré-processamento, sendo a inferência
(que pode ter complexidade polinomial ou exponencial conforme a ontologia) executada, de
fato, na atualização do endpoint (c) ou após a sua publicação quando houver uma consulta ao
grafo GPUB. O fator determinante é a forma escolhida para atualização do endpoint (discutida
na seção 3.3.1.4).
3.3.2 Implementação
O Módulo de Inferência foi implementado usando a linguagem Java e as bibliotecas
Jena e Pellet. Jena é capaz de processar RDF e OWL programaticamente e inclui reasoners
baseados em sistemas de regras para RDF e OWL. Pellet é um reasoner OWL-DL
implementado em Java que aceita ontologias que sigam a especificação OWL 2 DL e regras
DL-seguras escritas usando a sintaxe SWRL (detalhes na seção 2.3.2 e 2.3.2.5). ARQ é um
motor SPARQL que suporta SPARQL 1.0 e 1.1 além de um conjunto de extensões. Fuseki é
um servidor SPARQL compatível com protocolo SPARQL sobre HTTP que também aceita
SPARQL 1.0, 1.1 e extensões do ARQ. Ambos ARQ e Fuseki são parte da biblioteca Jena.
Para permitir exploração do endpoint via navegadores Web foi usada uma aplicação Ajax
chamada SNORQL13. Como a configuração dos módulos é feita via XML foi usado a
biblioteca XStream para carregar XML e converter em objetos Java.
Antes de entrar nos detalhes de implementação cabe informar a existência de duas
classes e uma interface da biblioteca Jena largamente utilizadas. A interface Model representa
um Grafo RDF que pode ser manipulado programaticamente pois permite leituras, inserções e
remoções de triplas RDF sem necessitar de escrita de consultas SPARQL. A interface
Reasoner representa um motor de inferência genérico que é especilizada tanto pelo reasoner
baseado em sistemas de regras quanto pelo reasoner Pellet. A classe Query representa uma
13
SNORQL: an AJAXy front-end for exploring RDF SPARQL endpoints – https://github.com/kurtjx/SNORQL
81
consulta SPARQL e é capaz de parsear um texto descrevendo uma consulta e armazenar
numa forma intermediária para posterior utilização dentro de motores SPARQL.
A Figura 10 apresenta o diagrama das principais classes que compõem o Módulo de
Inferência. A utilidade da maioria das classes e interfaces já foi apresentada em alto nível na
seção anterior. As interfaces UpdatePolicy, QueryParameterBinder, SparqlExecutor e Loader
representam políticas de atualização, substituidor de variáveis, executante de consultas
SPARQL e carregadores respectivamente. Esta última é especializada em PullLoader, que são
os carregadores síncronos já descritos, e cada instância desta classe é capaz de enviar
múltiplas consultas a um endpoint e estas consultas são executadas em sequência. A classe
SparqlExecutor possibilita a execução dos quatro tipos de consulta SPARQL existentes e se
especializa em SparqlGraphExecutor e SparqlEndpointExecutor (não mostrados no diagrama)
que são capazes de executar consultas a um grafo (interface Model do Jena) e a um endpoint
remoto respectivamente. Classes que realizam QueryParameterBinder, ou seja, que
implementam esta interface, são capazes de fazer a substituição de variáveis conforme já
mencionado e serão detalhadas mais adiante. A interface UpdatePolicy é composta por três
métodos que são equivalentes aos métodos apresentados no algoritmo da seção 3.3.1.5:
getInitialGraph(GPUB) – retorna o grafo inicial (linha 1);
getPreReasoningGraph(G PUB, GRC) – retorna o grafo que será passado ao motor de
inferência (linha 5); e
getPublishingGraph(GPUB, GRC e GINF) – retorna o grafo a ser publicado no
SPARQL endpoint (linha 7).
isCurrentModelChanged(mask) – retorna true caso o(s) método(s) definido(s) por
mask alterem o grafo GPUB. O parâmetro mask representa um ou mais dentre os
três métodos anteriores de UpdatePolicy. Este método é usado apenas na fase de
leitura do XML e caso algum método retorne true o endpoint será atualizado por
cópia para evitar alterações concorrentes no grafo GPUB (vide seção 3.3.1.4).
Isto dá uma grande liberdade para a construção de diversos tipos de políticas de
atualização, contudo apenas a classe ClearDataPolicy foi implementada neste trabalho e da
forma mais simples possível: os métodos retornam um grafo inicial vazio, G RC e GINF,
respectivamente.
82
Figura 10. Diagramas das principais classes do Módulo de Inferência atualmente implementado.
A classe SparqlServer encapsula uma instância do servidor Fuseki e permite
inicialização e término e, principalmente, atualização do grafo disponibilizado pelo endpoint.
As classes QueryConfig e QueryData, esta uma classe interna à classe PullLoader, guardam as
consultas e suas configurações (binder e intervalo entre consultas) para cada um dos
carregadores (um QueryData para cada consulta e um ou mais QueryData’s para cada
carregador PullLoader). Quando um QueryConfig é adicionado a um Loader ele é selado, ou
seja, não pode mais ser modificado. Qualquer tentativa de chamar métodos setX provoca o
lançamento de uma exceção. A classe QueryConfig pode ser especializada ao se criar outros
carregadores que necessitem de parâmetros adicionais (como o push loader) mas mantendo
este comportamento.
A classe InferenceModule orquestra o funcionamento de todas estas classes como será
mostrado no próximo parágrafo. Disjunta a todas está a interface InfModReasonerFactory que
é utilizada para instanciar um Reasoner antes da inicialização da classe InferenceModule.
Observe que há uma fábrica para motor de inferência Jena e outra para Pellet.
Após a leitura do XML de configuração, que será explicado na próxima seção, o
conjunto de classes apresentado no diagrama da Figura 10 é instanciado e o processo
apresentado no diagrama de atividades da Figura 9 é iniciado. Tanto por questão de espaço
83
quanto de visibilidade, o diagrama de sequência das classes foi dividido em dois conforme
mostrado nas Figuras 11 e 12. A primeira foca na classe InferenceModule e será identificado
por DS.IM (Diagrama de Sequência da classe InferenceModule) e a segunda na classe
PullLoader (identificado por DS.PL). Primeiramente, o método start() da classe
InferenceModule é chamado (DS.IM/1), e então o servidor SPARQL (DS.IM/1.1) e os
carregadores
registrados
também
são
iniciados
(DS.IM/1.2).
Todos
executam
independentemente em seus próprios threads. A partir deste momento, cada carregador entra
em um laço composto pelas mensagens DS.PL/1.x, que fazem a substituição de variáveis
(messagens 1.1 e 1.1.1), e executam cada consulta resultante desta substituição conforme seu
tipo (1.2 ou 1.3) e finalmente guardam seu resultado e sinalizam modificação (1.4). Enquanto
o módulo deve permenecer executando ele verifica alguma alteração nos dados dos
carregadores (DC.IM/1.3) e em caso afirmativo executa as mensagens DS.IM/1.4-1.9 que
representam as linhas 1, 2-4, 5, 6, 7 e 8 do algoritmo da seção 3.3.1.5, respectivamente.
O término da execução do módulo é disparado pela chamada ao método stop()
(mensagem DS.IM/2) que desencadeia as mensagens DS.IM/2.1 (a mesma que DS.PL/2),
DS.PL/2.1, DS.PL/2.2 e DS.IM/2.2. Do ponto vista do desenvolvedor este processo é
atualmente iniciado ao pressionar as teclas Ctrl+C no terminal de execução.
84
Figura 11. Diagrama de Sequência do módulo com foco na classe InferenceModule.
85
Figura 12. Continuação do Diagrama de Sequência do módulo com foco na classe PullLoader.
A interface QueryParameterBinder merece destaque adicional por possuir quatro
classes que a realizam. Conforme apresentado na fig, esta interface possui o método bind que
recebe uma consulta, efetua as substituições de variáveis cabíveis e retorna uma ou mais
86
consultas resultantes na forma de lista. A classe DefaultQueryParameterBinder implementa o
comportamento mais simples: retorna uma lista com um elemento, sendo este a mesma
consulta inicial. A classe SelectQueryParameterBinder executa uma consulta SPARQL
SELECT e substitui as varíaveis resultantes na consulta inicial. Como um SPARQL SELECT
produz um resultado tabular, cada linha do resultado gera uma consulta como resposta. A
classe TimeFrameQueryBinder computa um intervalo de tempo cujo término é o instante de
execução da consulta e cujo inicio é o instante de término menos um intervalo definido na
configuração deste binder (valor fixo). Ambos os instantes são substituídos nas variáveis
?startDate e ?finalDate. Por fim, tem-se a classe OffsetSplitterQueryParameterBinder que
permite que consultas cujo endpoint fonte limite o tamanho das respostas sejam executadas e
retornem todos os resultados desejados. Assim, este binder executa uma consulta que informa
a quantidade de resultados (consulta de contagem), então, a consulta que obtém todos estes
resultados é quebrada em várias consultas que contém as cláusulas OFFSET e LIMIT
definidas. A consulta de contagem e o valor do LIMIT são definidas na configuração do
binder.
Tanto o sistema de regras do Jena quando o motor de processamento SPARQL do
ARQ permitem a criação de funções personalizadas. Algumas são fornecidas juntamente com
a biblioteca por padrão, outras foram criadas para serem adicionadas ao Módulo de Inferência
via um sistema de plugins que são definidos na linha de comando. As funções do sistema de
regras do Jena são conhecidas como regras embutidas (rule built-ins). Em linhas gerais, uma
função personalizada do ARQ ou de regras é construída via realização de uma interface
(Function e Builtin, respectivamente), ou mais facilmente no caso do ARQ, via especialização
de uma dentre diversas classes de mais alto nível da biblioteca. Funções do ARQ e built-ins
do Jena diferenciam-se pelo fato de que as primeiras recebem uma lista de valores (literais) e
retornam outro valor, enquanto que os built-ins podem receber literais e variáveis e retornam
sempre um booleano ou nada. Quando estes built-ins são chamados no corpo (antecedente) de
uma regra o retorno é um booleano e quando chamados na cabeça (consequente) da regra não
há retorno. Isto ocorre pois o corpo da regra define se a cabeça da regra será executada ou não
via expressão booleana, ou seja, se todos os itens do antecedente são verdadeiros então o
consequente será executado. Como o consequente apenas executa comandos não há
necessidade de retorno. Nesta implementação apenas funções ARQ e built-ins de antecedente
precisaram ser construídos. O Quadro 7 a seguir apresenta estas funções com uma pequena
descrição, o tipo (função ARQ/SPARQL ou built-in de regras) e a origem (se já fornecida
87
pela biblioteca ou criada para o Módulo de Inferência por meio de plugins). Seus usos serão
apresentados no Capítulo 4 e apêndices conforme necessário.
Quadro 7. Resumos das funções para SPARQL e regras Jena utilizadas.
Tipo
Assinatura
Regra curTime(?tm)
Descrição
Coloca xsd:dateTime atual em ?tm.
Regra makeNearestDateTime(?dtin, ?dtout)
Calcula próxima ocorrência da data de entrada,
InfMod
ou seja, mantém dia e mês e ajusta o ano.
Regra dateSum(?date_in, ?days, ?date_out)
Regra dateDiff(?date1, ?date2, ?days)
Regra noValue(?s, ?p, ?o)
Regra notEqual(?x, ?y)
Regra le(?x,?y)
Regra ge(?x,?y)
Regra localname(?uri, ?lname)
makeNamedNode(
?new_node, <strlist>)
Regra
SPARQL localname(?uri)
SPARQL maxMatch(?a, ?b)
SPARQL
distanceFromDegrees(
?lat1, ?lon1, ?lat2, ?lon2)
SPARQL nb_contains(?b, ?lat, ?lon)
SPARQL concat(?a, ?b, ...)
SPARQL sha1sum(?x)
SPARQL sumTime(?dt, ?days, ?secs)
Origem
InfMod
Adiciona ?days dias à data de entrada,
InfMod
colocando o valor na data de saída.
Subtrai ?date1 - ?date2 retornando a diferença
InfMod
em dias em ?days.
Retorna true se a tripla não está presente na
Jena
base.
Retorna true se ?x != ?y
Jena
Retorna true se ?x <= ?y
Jena
Retorna true se ?x >= ?y
Jena
Coloca o localname de ?uri em ?lname.
InfMod
Ex. http://example.org/res/Fulano => “Fulano”
?new_node recebe um novo nó cujo URI é
dado pela concatenação dos demais
parâmetros.
Retorna um literal string contendo o localname
de ?uri
Retorna a similaridade entre duas strings ?b e
?b
Retorna a distância em metros entre as
coordenadas geográficas (?lat1, ?lon1) e (?lat2,
?lon2).
Retorna true se o ponto (?lat, ?lon) se encontra
dentro do polígono com URI ?b.
Retorna um literal string contendo a
conctenação dos parâmetros.
Calcula o SHA1 de ?x e retorna como um literal
string.
Retorna um xsd:dateTime que representa ?dt
somados a ?days dias e ?secs segundos.
InfMod
ARQ
InfMod
InfMod
InfMod
ARQ
ARQ
InfMod
3.3.3 Configuração
Para a correta configuração de um módulo deve-se primeiro planejar o que deverá ser
feito antes de escrever o arquivo XML de configuração. Este planejamento inclui escolher
SPARQL endpoints cujos dados sejam adequados à aplicação a ser desenvolvida assim como
possíveis ontologias que possam ser usadas. Este procedimento é complexo, pois requer
levantamento e pesquisa de endpoints e ontologias existentes. Contudo, acredita-se que no
88
futuro isto não seja mais um problema conforme a tecnologia da Web Semântica se difunda.
Quando não se encontram ontologias/regras prontas referentes ao domínio da aplicação tornase necessário construí-las. No capítulo seguinte serão apresentados alguns exemplos onde
ontologias e regras foram construídas e também os próprios endpoints. O restante desta seção
apresenta a estrutura e significado do arquivo XML. Inicialmente pretendia-se construir uma
ontologia OWL para descrever o arquivo de configuração, contudo não foram encontrados
ganhos no escopo deste trabalho e ainda poderia complicar a fase de experimentos com alunos
não familiarizados, decidiu-se utilizar apenas XML.
A Figura 13 apresenta a hierarquia mais externa de elementos XML. Os elementos
loaders, inference e sparqlServer configuram o carregador, o motor de inferência e o servidor
SPARQL (endpoint) respectivamente. Outros elementos também importantes são name que
define o nome do módulo, prefixes que permite associar diversos namespaces a prefixos (rdf,
owl, etc.), clock que aceita um atributo baseUri com o URL do simulador de relógio
(desenvolvido especialmente para o módulo), resourceBaseUri que define a URI base para
recursos específicos do módulo (atualmente apenas o recurso adicionado automaticamente
com os horários de atualização utilizam esta URI), updatePolicy define a política de
atualização e apenas ClearDataPolicy é aceita no momento.
O elemento inference permite dizer qual motor de inferência deve ser utilizado
(PELLET ou JENA) e com qual(is) ontologia(s) e regras. O elemento ontology pode ocorrer
diversas vezes e cada ocorrência determina o nome do arquivo contendo uma ontologia que
pode estar na mesma máquina do módulo (caminho para um arquivo local) ou na Internet
(URL). Esta pode estar escrita tanto em Turtle quando em RDF/XML. O elemento rules
recebe regras JENA e é incompatível com PELLET, sendo ignorado caso este seja
selecionado pelo elemento reasoner. Para usar regras com Pellet devem-se construir regras
SWRL e adicionar à ontologia (para facilitar este processo pode-se usar a ferramenta
Protégé14 ou escrever em Turtle, pois RDF/XML é mais verboso e torna a construção mais
complexa).
O elemento sparqlServer contém três elementos filho. O elemento path determina
como acessar o grafo RDF publicado pelo módulo e port diz em qual porta o endpoint estará
acessível. Assim, se o módulo utilizar path=/graph/ e port=3333, é possível acessar o endpoint
em http://dominio:3333/graph/sparql usando o protocolo SPARQL sobre HTTP. Uma
14
Protégé: a free, open source ontology editor and knowledge-base framework – http://protege.stanford.edu/
89
interface web SNORQL sempre estará disponível em http://dominio:3333/snorql. Finalmente,
o elemento fastUpdate informa ao módulo se o endpoint deverá ser atualizado rapidamente ou
não. Quando seu conteúdo for true o endpoint publica o mesmo grafo gerado pelo motor de
inferência, e caso contrário (false) toda a inferência é processada e adicionada a um grafo com
triplas materializadas (cópia).
<InferenceModule>
<loaders>
<PullLoader>
<name> : texto
<prefixes>
<Prefix>
<PullLoader>
...
<inference>
<prefix> : texto
<reasoner> : PELLET/JENA
<namespace> : URI
<ontology> : arquivo/URL
<Prefix>
...
...
<rules> : regras do Jena
<clock baseUri=”url”>
<resourceBaseUri> : URI
<updatePolicy class=”ClearDataPolicy” />
<sparqlServer>
<path> : caminho
<port> : número
<fastUpdate> : booleano
Figura 13. Hierarquia mais externa dos elementos XML de configuração.
O elemento loaders, como o nome sugere configura carregadores. Cada endpoint fonte
a ser usado deve ser especificado com o elemento PullLoader que representa o carregador
síncrono já descrito. A Figura 14 detalha esta etapa da configuração. Como pode-se observar,
dentro do elemento PullLoader define-se o endpoint e uma descrição pertinente através dos
elementos homônimos, e uma lista de QueryData’s com informações de cada consulta a ser
executada dentro do elemento queryConfigs. Cada QueryData contém uma consulta
(elemento query), uma descrição textual, um intervalo de tempo em milissegundos entre
execuções (que pode ser uma expressão aritmética) e um elemento binder para configurar
possíveis substituições de variáveis. Os quatro possíveis binders são mostrados no lado direito
da Figura 14. SelectQueryParameterBinder aceita um endpoint e uma consulta SPARQL
SELECT. TimeFrameQueryBinder aceita o tamanho da janela de tempo (milissegundos a
retroagir) no elemento frameMillis. OffsetSplitterQueryParameterBinder aceita um endpoint,
uma consulta que deve ser um SELECT COUNT e um limite para o tamanho da janela
(elemento limit).
90
<binder class=”DefaultQueryParameterBinder”>
<PullLoader>
<description> : texto
<endpoint> : URL
<queryConfigs>
QueryData
<query> : SPARQL
<binder class=”SelectQueryParameterBinder”>
<description> : texto
<endpoint> : URL
<query> : SPARQL
<binder class=”TimeFrameQueryBinder”>
<frameMillis> : número
<description> : texto
<binder class=”OffsetSplitterQueryParameterBinder”>
<interval> : número
<description> : texto
<binder class=”...”>
QueryData
...
<limit> : número
<endpoint> : URL
<query> : SPARQL
Figura 14. Elementos XML para configuração de carregadores e substituidores de variáveis (binders).
Os elementos que recebem um texto podem utilizar o CDATA do XML quando
existem caracteres especiais dentro do texto. Caracteres especiais são “<” e “&” que
representam início de elemento e de entidade, respectivamente. Eles podem ser encontrados
em qualquer texto, mas muito mais facilmente em consultas SPARQL, sendo recomendado
utilizar CDATA sempre que houver necessidade de utilizar os caracteres. As entidades “&lt;”
e “&amp;” podem ser utilizadas para representar estes caracteres, contudo isto prejudica a
legibilidade do texto. Veja dois exemplos de consulta com e sem CDATA, respectivamente:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<query>
<![CDATA[
PREFIX a: <http://dominio/resource/>
CONSTRUCT { ...
}
WHERE {
...
FILTER (?y >= 18 && ?t <= 70)
}
]]>
</query>
<query>
PREFIX a: &lt;http://dominio/resource/>
CONSTRUCT { ...
}
WHERE {
...
FILTER (?y >= 18 &amp;&amp; ?t &lt;= 70)
}
</query>
Os prefixos definidos dentro do elemento prefixes são válidos em todo arquivo XML,
tanto nas regras do elemento
rules quanto nas consultas principais (elemento
91
QueryData/query) e secundárias (elemento binder/query). Assim, aproveitando o exemplo de
consulta acima, poderia-se omitir a primeira linha contendo o prefixo e adicionar um
elemento Prefix, como mostrado a seguir:
1 <InferenceModule>
2
<prefixes>
3
<Prefix>
4
<prefix>a</prefix>
5
<namespace>http://dominio/resource/</namespace>
6
</Prefix>
7
</prefixes>
8
...
9
<query>
10
<![CDATA[
# PREFIX omitido
11
CONSTRUCT { ... }
12
WHERE { ... }
13
]]>
14
</query>
15
...
16 </InferenceModule>
Uma vez completado o arquivo XML basta executar o módulo chamando-o em um
terminal java –jar InferenceModule.jar config.xml. Por fim, para executar o plugin que possui
funções adicionais para SPARQL e regras Jena apresentadas no Quadro 7 (coluna Origem
igual a “InfMod”) deve-se adicionar um parâmetro, e o comando fica como mostrado a seguir:
java -Dinfmod.function.path=plugin.jar –jar InferenceModule.jar config.xml
92
4
Cenários de Aplicação
Para verificar a aplicabilidade do framework, foram elaborados três cenários que
poderiam ser aplicados no mundo real, porém sem considerar toda sua complexidade, visto
que a elicitação e análise de requisitos está fora do escopo deste trabalho por demandar um
tempo adicional que impediria seu término no prazo. Mas especificamente, também
considerando o fator tempo, foram consideradas situações simplificadas para viabilizar a
modelagem e construção de ontologias, regras e consultas.
Neste capítulo será apresentado o processo utilizado para a construção da rede de
módulos de inferência para cada cenário. Eventuais endpoints construídos para simular dados
de sensores e bases LOD também são apresentados, porém de forma bastante superficial no
capítulo e um pouco mais detalhada nos apêndices. A criação de endpoints simulados nos
cenários decorre da atual carência de bases RDF realmente úteis no âmbito brasileiro. O
terceiro e último cenário foi utilizado para que alunos com alguns conhecimentos das
tecnologias atuais de Web Semântica (RDF, OWL e SPARQL) avaliassem o módulo.
Antes de apresentar os cenários, é importante mencionar que um endpoint especial foi
desenvolvido para ser usado em todos os experimentos: simulador de relógio. Conforme o
nome indica, ele é capaz de simular um relógio, possibilitando definir horário de início e fim
de uma simulação e a velocidade com que o relógio simulado correrá. Assim, é possível usar
janelas de tempo quando necessário sem precisar modificar o relógio da máquina hospedeira.
Além disso, a taxa de velocidade do relógio permite definir quantos segundos simulados
ocorrem para cada segundo real. Por exemplo, uma taxa de 20x significa que quando decorre
um segundo na máquina real decorrem 20 segundos no endpoint de relógio. Já uma taxa de
0,25 determina que um segundo real representa um quarto de segundo no endpoint.
4.1
Cenário 1: informação sobre hidrantes durante um incêndio
Este cenário foi sugerido pelo aluno de doutorado Tiago Marino que ajudou na sua
construção. Situações de emergência possuem as mais variadas necessidades de informação,
que se constituem, entre outras, de dados de saúde, segurança, geologia, logística, etc. Numa
situação de emergência surgem diversas perguntas que precisam ser respondidas. Exemplos
de tais perguntas são: Qual hospital possui a especialidade de ortopedia, mais próximo à
93
localidade do resgate? Quantas casas existem e quem são seus proprietários em determinada
região soterrada por um deslizamento? Onde estão localizados os hidrantes de coluna no raio
de 500 metros do foco de um incêndio? Estas questões são levantadas durante uma
emergência e demandam resposta rápida para tomada de decisão e gerência da situação.
Muitas dessas respostas existem, mas estão armazenadas em bancos desorganizados, não
padronizados e não integrados. Para fins demonstrativos, apenas a última pergunta será
abordada neste cenário.
O objetivo deste cenário é utilizar apenas uma instância do framework proposto para
mostrar integração de bases de triplas, inferência e checagem da consistência destes dados
usando uma ontologia especialmente desenvolvida, que integra conceitos de vocabulários
existentes. A implementação deste cenário requer diversos procedimentos para publicação,
integração e consumo, ilustrados na Figura 15 que será explicada ao longo das próximas
subseções.
Figura 15. Extração, Tratamento, Publicação e Integração de Dados Hídricos para Consultas Espaciais em LOD.
O restante desta seção discute a modelagem e construção das camadas de dados e
inferências e uma pequena aplicação para consulta e apresentação em mapas.
4.1.1 Modelagem e construção da camada de dados
O Corpo de Bombeiros do Estado do Rio de Janeiro (CBMERJ) é o órgão responsável
por operações de controle de incêndio no Estado do Rio de Janeiro. Eles utilizam informações
94
do Sistema de Informações Geográficas Vigilância e Controle (ViconWeb 15), que inclui
diversas iniciativas de trabalhos que auxiliam o processo de tomada de decisão do órgão. Seu
cadastro de recursos hídricos contém informações referentes aos hidrantes de coluna
(coordenadas de posicionamento, endereço, batalhão responsável, vazão e condições de
funcionamento) existentes na cidade do Rio de Janeiro. Por se tratar de dados restritos ao
CBMERJ, uma autorização para a extração do banco para fins de experimentação foi
solicitada junto à Instituição. Contudo, para a utilização por parte do módulo de inferência
seria necessário ainda a publicação de tais dados em algum SPARQL endpoint.
Esta publicação foi feita por meio de um processo de ETL (Extraction,
Transformation & Loading) utilizando-se a ferramenta Pentaho Data Integration 4.1.0 16,
também conhecida como Kettle, tanto por ser uma ferramenta popular e aberta quanto por já
existirem plugins específicos, desenvolvidos no projeto LinkedDataBR17, para se trabalhar
com LOD. O projeto disponibiliza quatro plugins: entrada de dados via SPARQL, geração de
propriedades de dados e de objetos (object e datatype properties do OWL), saída de dados
usando SPARQL Update. Para o armazenamento e disponibilização das triplas, foi utilizado o
software Virtuoso18, que é um repositório de triplas que disponibiliza interfaces para consultas
SPARQL (SPARQL endpoint).
O processo de ETL, superficialmente mostrado na Figura 15, é composto por cinco
grandes etapas. A primeira delas é a extração dos dados da base de hidrantes do sistema
ViconWeb e sua importação no Kettle. Os dados utilizados são descritos por uma ontologia
criada para este cenário e que será discutida mais a frente. Estes dados são tratados para
remover valores nulos ou inválidos. O próximo passo é a geração de URIs que consiste em,
para cada recurso, utilizar um URL base pré-definido e acrescentar o nome da classe a que o
recurso pertence e um identificador. O terceiro passo consiste na geração de campos sujeito,
predicado e objeto, onde o predicado pode ser tanto DatatypeProperty quanto ObjectProperty
da OWL. Na quarta etapa, os campos gerados anteriormente são convertidos para um único
campo NTriplas. Finalmente, as triplas geradas são inseridas no Virtuoso usando SPARQL
Update. Uma vez criado o processo, este pode ser executado diversas vezes, conforme
necessário, a fim de atualizar a base do Virtuoso.
15
Vicon Web - http://www.viconsaga.com.br
16
Pentaho Data Integration - http://sourceforge.net/projects/pentaho/files/Data%20Integration/4.1.0-stable/
17
LinkedDataBR - http://greco.ppgi.ufrj.br/gtlinkedbr
18
Virtuoso - http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/
95
A ontologia para descrever a base de hidrantes é apresentada na Figura 16 que também
mostra os relacionamentos com conceitos de vocabulários existentes na nuvem LOD. Para
descobrir conceitos relacionados, foram realizadas pesquisas nas páginas do Linked Open
Vocabularies (LOV)19 que reúne descrições e referências para diversos vocabulários e
ontologias utilizados na nuvem LOD, do LinkedGeoData20 e DBPedia. Como resultado
resolveu-se utilizar as classes: foaf:Organization do vocabulário FOAF (uma organização
qualquer); geo:SpatialThing e suas propriedades geo:lat e geo:long do vocabulário “WGS84
Geopositioning”21 (objetos geolocalizados com latitude e longitude conforme o WGS84);
lgdo:FireHydrant, lgdo:FireStation, lgdo:City e lgdo:Locality da Linked Geo Data Ontology;
e yago:Neighbourhoods_inRio_(city) da DBPedia (bairros do município do Rio de Janeiro).
O conceito central é hid:HidranteDeColuna que é uma especialização de
geo:SpatialThing e de lgdo:FireHydrant (um hidrante qualquer). Ao conceito central, são
relacionadas as propriedades (data properties) hid:vazão, hid:dataDoCadastro, hid:endereço
que representam, respectivamente, a vazão em litros por minuto, a data que o hidrante foi
cadastrado no sistema e um endereço textual. O hidrante também é relacionado ao bairro
(hid:Bairro) e à cidade (hid:Cidade) em que se localiza, ao batalhão (hid:OBM equivalente a
lgdo:FireStation) responsável pela manutenção e atualização de seus dados e, principalmente,
à sua situação operacional que permite identificar quais hidrantes podem ser utilizados em
determinado momento. Esta ontologia foi construída obedecendo ao padrão OWL 2 DL.
19
Linked Open Vocabularies (LOV) - http://labs.mondeca.com/dataset/lov/index.html
20
LinkedGeoData.org: Adding a spatial dimension to the Web of Data - http://linkedgeodata.org
21
Basic Geo (WGS84 lat/long) Vocabulary - http://www.w3.org/2003/01/geo/
96
lgdo:FireHydrant
foaf:Organization
xsd:float
hid:
obmResponsavel
hid:OBM
hid:vazao
hid:HidranteDeColuna
hid:dataDoCadastro
owl:equivalentClass
hid:endereco
lgdo:FireStation
xsd:dateTime
xsd:string
hid:situacaoOperacional
lgdo:Locality
hid:Bairro
geo:lat, geo:long
geo:SpatialThing
hid:SituacaoOperacional
hid:bairro
owl:equivalentClass
yago:
Neighbourhoods
InRio_(city)
hid:cidade
hid:Cidade
owl:
equivalentClass
lgdo:City
hid:OPERANTE
hid:PRECARIO
hid:INOPERANTE
Figura 16. Ontologia para Hidrante de Coluna e relacionamentos com outros vocabulários existentes na nuvem LOD
Além da base de hidrantes, foi utilizada a base LinkedGeoData.org (LGD), que
disponibiliza dados georreferenciados na nuvem LOD (ruas, bairros, cidades, estados)
existentes na base OpenStreetMap22, um serviço para criação de mapas colaborativo. Desta
base foram extraídas todas as triplas da classe lgdo:Amenity existentes na cidade do Rio de
Janeiro. Após consulta em sua ontologia, verificou-se que esta classe agrega subclasses de
localidades geográficas do tipo: Aeroporto, Shopping Center, Hotel, Comércios, Escolas,
Hospitais, etc. Estas entidades serão disponibilizadas para consulta na aplicação do caso de
exemplo deste trabalho.
4.1.2 Camada de inferência para integração das bases
Nesta seção será mostrada a configuração do módulo para integrar as duas bases RDF
apresentadas na seção anterior. Da base de hidrantes foram extraídas informações
relacionadas aos hidrantes através da consulta SPARQL DESCRIBE apresentada a seguir e
identificada por Qhid:
1
2
3
DESCRIBE ?s ?s1
FROM <http://www.viconsaga.com.br/cbmerj/pgorh/graph>
WHERE { ?s a hid:HidranteDeColuna ; ?p ?s1 . }
Esta consulta descreve todas as triplas de hid:HidranteDeColuna, hid:Cidade,
hid:Bairro e hid:OBM e é atualizada (executada novamente) em intervalos de uma hora.
22
OpenStreetMap - http://www.openstreetmap.org/
97
Da base LGD obtém-se todas as instâncias de lgdo:Amenity, suas coordenadas
geográficas (geo:lat e geo:long) e seu rótulo (rdfs:label). Para reduzir a quantidade de
resultados utilizou-se um filtro de coordenadas, ou seja, escolheu-se um retângulo imaginário
na superfície da Terra que englobasse uma grande região do município do Rio de Janeiro.
Como, o endpoint da LGD limita a quantidade de resultados, foi utilizado o binder OffsetSplitterQueryParameterBinder (veja seções 3.3.2 e 3.3.3) utilizando as consultas Qcontagem
(contagem total de resultados) e Qamenity a seguir:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# Qcontagem: contagem do total de resultados
SELECT (count(?uri) as ?c)
FROM <http://linkedgeodata.org>
WHERE {
?uri a lgdo:Amenity ;
geo:lat ?lat ;
geo:long ?lng ;
rdfs:label ?nome ;
a ?C .
# Delimita um retângulo na superfície
FILTER (?lat < -22.898474 && ?lat > -22.959342
&& ?lng > -43.272572 && ?lng < -43.142624
&& ?C != lgdo:Amenity && ?C != lgdo:Node)
}
# Qamenity: executada várias vezes alterando apenas valor do ?offset
CONSTRUCT {
?uri a lgdo:Amenity ;
geo:lat ?lat ;
geo:long ?lng ;
rdfs:label ?nome ;
a ?C .
}
FROM <http://linkedgeodata.org>
WHERE {
?uri a lgdo:Amenity ;
geo:lat ?lat ;
geo:long ?lng ;
rdfs:label ?nome ;
a ?C .
# Delimita um retângulo na superfície
FILTER (?lat < -22.898474 && ?lat > -22.959342
&& ?lng > -43.272572 && ?lng < -43.142624
&& ?C != lgdo:Amenity && ?C != lgdo:Node)
}
ORDER BY ?uri
OFFSET ?offset
LIMIT ?limit
98
A realização de inferência sobre estes dados reunidos usando a ontologia criada
permitiu relacionar as instâncias hid:HidranteDeColuna com a classe lgdo:FireHydrant, e de
forma semelhante hid:OBM com foaf:Organization e lgdo:FireStation. As partes mais
relevantes do arquivo XML de configuração são apresentadas a seguir:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<InferenceModule>
<name>Rio Maps</name>
<prefixes>...</prefixes>
<resourceBaseUri>
http://derived.viconsaga.com.br/cbmerj/pgorh/resource/
</resourceBaseUri>
...
<loaders>
<PullLoader>
<description>Carrega hidrantes e seus recursos</description>
<endpoint>...</endpoint>
<queryConfigs>
<QueryData>
<query>Qhid</query>
<interval>60*60*1000</interval>
<binder class="DefaultQueryParameterBinder" />
</QueryData>
</queryConfigs>
</PullLoader>
<PullLoader>
<description>Carrega lgdo:Amenity de LGD</description>
<endpoint>http://linkedgeodata.org/sparql</endpoint>
<queryConfigs>
<QueryData>
<query>Qamenity</query>
<interval>60*60*1000</interval>
<binder class="OffsetSplitterQueryParameterBinder">
<description>Contagem de lgdo:Amenity</description>
<limit>100</limit>
<endpoint>http://linkedgeodata.org/sparql</endpoint>
<query>Qcontagem</query>
</binder>
</QueryData>
</queryConfigs>
</PullLoader>
</loaders>
<inference>
<reasoner>PELLET</reasoner>
<ontology>hidracol.owl.xml</ontology>
</inference>
<sparqlServer>
<path>/ds/</path>
<port>32000</port>
99
42
</sparqlServer>
43 </InferenceModule>
Para viabilizar consultas por parte da aplicação, duas funções foram construídas e
adicionadas ao módulo por meio de plug-ins:
maxMatch(texto1, texto2) – retorna o grau de similaridade, entre 0 e 1, entre os
textos identificados por texto1 e texto2. Os parâmetros de entrada podem ser textos
constantes entre aspas ou variáveis contendo um texto.
distanceFromDegrees(lat1, lon1, lat2, lon2) – retorna a distância, em metros,
entre dois pontos geográficos. Os parâmetros de entrada podem ser números
constantes fornecidos diretamente ou passados por variáveis.
A primeira função permite comparar nomes digitados pelo usuário da aplicação com
os nomes das entidades geográficas existentes na base integrada, a fim de encontrar aquelas
que o usuário está provavelmente se referindo. Já a segunda função é usada para retornar a
distância entre uma entidade geográfica e cada hidrante de coluna, permitindo descobrir
hidrantes próximos a ela. A próxima seção mostrará consultas utilizadas pela aplicação que
aplicam estas funções.
4.1.3 Aplicação de consumo e considerações
Com o término de todo processo descrito, os dados de hidrantes de coluna do sistema
ViconWeb foram triplificados, integrados com dados da LinkedGeoData e disponibilizados
em um endpoint provido pelo módulo de inferência. Para fins de demonstração, uma interface
de consulta Web foi elaborada pelo mesmo aluno Tiago Marino de forma a receber como
entrada uma localidade geográfica da cidade do Rio de Janeiro (existente na classe
lgdo:Amenity da base LGD) e o raio de busca.
A aplicação recebe os parâmetros de entrada do usuário, cria consultas SPARQL
considerando estes parâmetros, as envia para o endpoint e recebe os resultados em formato
JSON. Por exemplo, para consultar “Todos os hidrantes de coluna operantes no raio de 500
metros do comércio Casas Pedro”, duas consultas (e consequentemente duas requisições) são
enviadas ao endpoint. A primeira delas visa buscar o URI que representa a Casas Pedro:
1
2
3
4
5
SELECT ?x ?l ?r
WHERE {
{ SELECT DISTINCT ?x ?l (sfn:maxMatch(?l, "Casas Pedro") AS ?r)
WHERE {
?x a lgdo:Amenity ; rdfs:label ?l
100
6
7
8
9
}
ORDER BY DESC(?r)
}
FILTER (?r > 0)
10 }
O URI encontrado é <http://linkedgeodata.org/triplify/node633485277> que é então
passado para a segunda consulta que busca todos os hidrantes de coluna operantes a uma
distância inferior a 500 metros das coordenadas (?lat, ?lon) da Casas Pedro. Esta consulta é
apresentada a seguir:
1 SELECT *
2 WHERE {
3
{ SELECT ?label ?hyd ?hlat ?hlon
4
(gfn:distanceFromDegrees(?hlat, ?hlon, ?lat, ?lon) as ?dist)
5
?endereco ?sit ?vazao
6
WHERE {
7
<http://linkedgeodata.org/triplify/node633485277>
8
geo:lat ?lat ;
9
geo:long ?lon .
10
?hyd a lgdo:FireHydrant ;
11
geo:lat ?hlat ;
12
geo:long ?hlon ;
13
hid:endereco ?endereco ;
14
hid:situacaoOperacional ?sit ;
15
hid:vazao ?vazao .
16
FILTER (?sit = hidres:OPERANTE)
17
}
18
ORDER BY ?dist
19
}
20
FILTER (?dist < 500)
21 }
Como retorno, a aplicação apresenta um mapa do Google Maps, centrado na
localidade buscada, traça um círculo com o raio definido pelo usuário na entrada, e todos os
hidrantes de coluna com situação operacional igual a “OPERANTE” (podem existir hidrantes
em más condições) dentro do raio de busca (Figura 17).
101
Figura 17. Lista de Resultados na aplicação protótipo desenvolvida.
Algumas considerações devem ser feitas a respeito deste cenário. Primeiramente,
buscou-se apresentar os procedimentos básicos que envolvem o processo de extração,
transformação, publicação e integração a partir de dados armazenados nos formatos
tradicionais para o padrão RDF, tornando-os disponíveis em um padrão legível por máquinas
na Web e com semântica definida por uma ontologia. O ganho de se utilizar este padrão é seu
caráter interoperável, que possibilita a integração entre bases provenientes de distintas fontes,
como demonstrado na consulta apresentada.
Outra observação importante é que os atributos descritores do objeto “Hidrante de
coluna”, utilizados como base para a montagem e pesquisa dos vocabulários, foram
elaborados pelos próprios membros do Corpo de Bombeiros, sendo estas pessoas as mais
indicadas para modelar um objeto desta natureza por lidarem diretamente com este tipo de
entidade.
Quanto aos dados do LGD, verificou-se que a quantidade de entidades geográficas da
cidade era pequena, o que mostra que ainda há um grande caminho a se percorrer até que
existam bases realmente completas. Contudo, acredita-se que num futuro próximo, com a
crescente demanda e adesão pela publicação de dados abertos no padrão LOD, os dados
disponibilizados para a resposta a situações de emergência, saúde, trânsito, segurança pública
serão mais confiáveis e atualizados, transformados em informação para apoio à decisão.
102
4.2
Cenário 2: alertas sobre chuvas e escorregamento de terra
Este cenário foi inspirado pelas tragédias que ocorreram no Estado do Rio de Janeiro
entre 2010 e 2012, principalmente na região serrana e nos municípios de Niterói e Rio de
Janeiro. Diversos óbitos ocorreram devido a enchentes e soterramentos, estes ocorridos após o
deslizamento de terras em encostas ocupadas irregularmente por casas em comunidades
carentes. Após os fatos ocorridos, o então prefeito do município do Rio de Janeiro, Eduardo
Paes, ordenou a implantação de sirenes para alertar a população de diversas localidades sobre
possíveis riscos de deslizamentos.23 Esta iniciativa incorre em gastos de recursos com
implantação e manutenção que poderiam ser redirecionados para outras necessidades como
treinamento da população e de pessoal caso infraestruturas já existentes fossem aproveitadas.
Assim, o objetivo deste cenário é utilizar o framework apresentado neste trabalho para
mostrar uma possível abordagem para notificação de usuários sobre a condição e possíveis
riscos existentes no local em que ele se encontra. Geralmente estes locais são encostas de
morros ou áreas carentes. Celulares convencionais poderiam ser utilizados para enviar
mensagens de texto a números previamente cadastrados, contudo Smatphones oferecem
serviços mais sofisticados como localização corrente e acesso à Internet sem fio. Apesar de
parecer absurdo que usuários das classes C e D tenham acesso a dispositivos móveis de alta
tecnologia, pesquisas de mercados mostram que tais pessoas desejam adquiri-los e não se
importam em pagar inúmeras prestações.24 Desta forma, Smartphones ultrapassam a barreira
de meros dispositivos de entretenimento e status social, para serem também de utilidade
pública. Limitou-se a utilizar a localização corrente do usuário, mas outras localizações,
fornecidas manualmente ou capturadas de dados históricos, poderiam ser utilizadas em um
cenário mais realista.
Um objetivo técnico adicional deste cenário foi verificar a capacidade de se usar
comparações, iterações e cálculos matemáticos simples como agregações (redução dos valores
de uma lista a um único valor, como por exemplo, soma e média). Nas próximas seções
apresentar-se-á o domínio do cenário descrito, sua modelagem e implementação usando o
framework proposto nesta dissertação.
23
Mais informações em http://oglobo.globo.com/rio/paes-afirma-que-todas-as-comunidades-mapeadas-pelageorio-receberao-sirenes-de-alerta-ate-fim-do-ano-2791735 e http://oglobo.globo.com/rio/mais-35-favelasdo-rio-terao-sirene-de-alerta-de-chuva-3730766
24
http://www.omelhordomarketing.com.br/desejos-dos-consumidores-classe-cd/
103
4.2.1 Domínio da aplicação e modelagem
Neste cenário utilizaram-se medidas pluviométricas provenientes do Alerta-Rio25, um
sistema de alerta mantido pela prefeitura da cidade do Rio de Janeiro através da Fundação
Geo-Rio desde 1997. A Fundação Instituto de Geotécnica (Geo-Rio) é um órgão da Secretaria
Municipal de Obras da Prefeitura do Rio de Janeiro responsável por avaliar e mapear as
encostas da Cidade do Rio de Janeiro.26 O sistema é composto por 33 estações pluviométricas
distribuídas sobre a área geográfica da cidade. A concentração das estações varia
estrategicamente (AZEVEDO, 2011) e sua distribuição atual pode ser vista na Figura 18,
extraída da página Web do sistema Alerta-Rio. A medição pluviométrica é feita em
milímetros com resolução de 0,2 mm e medida a cada 15 minutos, sendo os dados de cada
estação transmitidos a uma estação central via rádio (SILVA, 2008).
A intensidade, frequência e duração das chuvas contribuem, juntamente com a
instabilidade do solo e a gravidade, para a movimentação de massas de terra e rochas ao longo
de uma encosta (AZEVEDO, 2011; SILVA, 2008). Tais movimentos são denominados
movimentos de massa e, apesar de a literatura apresentar diversas classificações para tais
movimentos este trabalho apresentará apenas a definição do termo escorregamento, utilizado
pelo Alerta Rio. Assim, escorregamentos são “movimentos rápidos, de duração relativamente
curta, de massas de solo ou rocha geralmente bem definidas quanto ao seu volume” (SILVA,
2008) ou “deslocamento rápido de (...) massa de rocha, solo residual ou sedimentos
existentes em uma encosta, possuindo um centro de gravidade que se desenvolve seguindo
para frente e para baixo” (AZEVEDO, 2011).
25
Sistema Alerta Rio - http://obras.rio.rj.gov.br/alertario.htm
26
Fundação Instituto de Geotécnica (Geo-Rio) - http://portalgeo.rio.rj.gov.br
104
Figura 18. Distribuição das estações do sistema Alerta-Rio (julho de 2012)
27
Quadro 8. Classificação de intensidade de chuvas (SILVA, 2008)
Classificação
Intensidade pluviométrica (mm/h)
da chuva
Chuvisco
Chuva
Leve
<= 0,25
1,1 a 5,0
Moderada
0,25 a 0,5
5,1 a 25
Forte
> 0,5
25,1 a 50
Muito Forte
---
> 50,0
A partir das medições pluviométricas é possível definir a intensidade da chuva em
cada estação conforme apresentado no Quadro 8. No entanto, a intensidade da chuva em
mm/h apenas não é suficiente para detectar a probabilidade de escorregamento, sendo
necessário considerar o histórico de chuvas. Assim, a quantidade de água acumulada durante
96 horas seguidas de chuva leve de 2,0 mm/h em média representa uma probabilidade muito
alta de haver algum deslizamento. O Quadro 9 mostra os níveis de alerta (ou probabilidade)
de escorregamento de terra definidos pelo sistema Alerta-Rio (AZEVEDO, 2011).
27
Coluna sobre chuviscos retirada de http://www.bibliotecapolicial.com.br/upload/documentos/ESTUDO-
PLUVIOMETRICO-E-REDUCAO-DE-DESASTRES-21069_2011_5_12_8_42.pdf, que usou uma revista sobre o GEORIO como fonte mas esta não foi encontrada.
105
Quadro 9. Probabilidade de escorregamento conforme quantidade de chuva acumulada e tempo (AZEVEDO, 2011)
Quantidade de chuva acumulada por tempo
Nível de alerta
1 hora
24 horas
96 horas
Moderado
10-30 mm
50-100 mm
100-175 mm
Alto
30-50 mm
100-175 mm
175-250 mm
Muito Alto
> 50 mm
> 175 mm
> 250 mm
A partir das medidas provenientes das estações pluviométricas pretende-se calcular a
suposta quantidade de chuva incidindo sobre a localização do usuário. Para isto, será usada
uma interpolação baseada no método de inverso do quadrado da distância usando as três
estações mais próximas. Isto é equivalente à média ponderada pelo inverso do quadrado das
distâncias entre as estações e o usuário. Assim, a suposta quantidade de chuva acumulada
num ponto geográfico P=(x,y), onde o usuário se localiza, será dada pela seguinte fórmula:
v (t ) ( P)
1 (t )
1 (t )
1 (t )
v
v
v
2 1
2 2
2 3
d1
d2
d3
1
1
1
2
2
2
d1
d2
d3
Equação I. Cálculo da quantidade de chuva acumulada num ponto.
Onde di determina a distância em linha reta, na Terra, entre P e a localização da iésima estação mais próxima de P, vi(t) representa a soma das t últimas medições da i-ésima
estação. Desta forma, t é igual a 4 para a última hora, 96 para as últimas 24 horas e 384 para
as últimas 96 horas. Uma vez calculados tais valores, utiliza-se o Quadro 9 para descobrir a
probabilidade de escorregamento no ponto P. No caso de haver diferentes resultados para
cada valor de t será utilizado o pior nível de alerta. A intensidade de chuva (Quadro 8) será
sempre calculada com base no v(1) e no v(4), ou seja, 15 minutos (última medição) e uma hora
(quatro últimas medições) respectivamente. Para o último caso, serão usados os dados do
quadro (mm/h) e, para o primeiro caso, estes valores serão divididos por 4 para se obter em
mm/15min. Como a divisão de medidas de chuvisco por 4 resulta em valores menores que
0,28 e a resolução dos hidrômetros é de 0,2 mm, apenas a coluna do Quadro 8 com
intensidades de chuva serão utilizadas para classificação de 15 minutos. Portanto 0,2
mm/15min será considerado como sem chuva e 0,4 mm/15min como chuva leve (0,4 × 4 =
106
1,6 mm/h). O Quadro 10 apresenta estes valores utilizados. Novamente, em caso de
divergências entre mm/h e mm/15min a classificação de maior intensidade será utilizada. A
metodologia de geração dos valores do ponto P será descrita na próxima seção.
Quadro 10. Adaptação do Quadro 8 para medições pluviométricas de 15 minutos
Classificação
da chuva
Intensidade pluviométrica
(mm/15min)
Ausente
< 0,28
Leve
0,28 a 1,25
Moderada
1,25 a 6,25
Forte
6,25 a 12,5
Muito Forte
> 12,5
4.2.2 Camada de dados e sensoriamento
Para este cenário, três SPARQL endpoints simulados foram criados. O primeiro deles,
denominado Rain Stations Endpoint (RSE), provê dados históricos de medidas do Alerta-Rio.
O segundo, denominado User Locations Endpoint (ULE) simula movimentação de usuários
na cidade. Ambos podem ser classificados como sensores físicos, pois provêm dados
capturados do ambiente (pluviômetro e GPS). O terceiro, chamado Neighborhood Endpoint
(NBE), é um endpoint adicional apenas para permitir descobrir se um ponto pertence a um
polígono (um interpretador de contexto) usado para fornecer contexto a nível de bairro.
Modelagem e implementação deles serão descritas nas próximas subseções e apêndices
referenciados conforme necessário.
4.2.2.1 Rain Stations Endpoint (RSE)
Para sua construção foi necessário obter previamente os dados históricos de chuva. O
Alerta-Rio os disponibiliza para download no site, contudo, é necessário selecionar o ano a
que as medições se referem para cada estação. Para automatizar este processo um script
Python que constrói as URLs e baixa os arquivos foi construído. Estes dados obtidos foram
inseridos em um banco de dados MySQL e mapeados para RDF utilizando o software
D2RQ28 que faz mapeamento em tempo real, pois quando recebe uma consulta SPARQL
gera uma consulta SQL e retorna o resultado conforme o protocolo SPARQL.
28
D2RQ Platform: Accessing Relational Databases as Virtual RDF Graphs - http://d2rq.org/
107
O diagrama de entidade-relacionamento para estes dados é composto pelas tabelas
measure e station conforme apresentado à direita da Figura 19. A tabela station possui
atributos para identificar a estação (chave primária), nome da estação, sua latitude e longitude,
e datas de início e final de operação (uma estação ativa precisa ter data final posterior à data
atual). A tabela measure possui atributos para identificar a medida (chave primária),
identificar a estação medidora (chave estrangeira), além de data e valor da medição.
O vocabulário RDF (à esquerda da Figura 19) é semelhante, contendo as classes
Station e Measure e os datatype properties stationName, latitude, longitude, beginDate e
endDate para Station e measureValue e measureDate para Measure. Por fim, cada medição é
ligada à estação medidora por meio da object property station. Por ser bastante simples e
também ser usado apenas no endpoint, não foi criado um vocabulário RDF Schema, sendo
tudo isso apresentado diretamente nas instâncias pelo mapeamento. Isto será importante para
demonstrar um endpoint sem ontologia ou vocabulário explícitos sendo mapeado para os
elementos (classes e propriedades) da ontologia de domínio que será apresentada
posteriormente.
xsd:decimal
xsd:dateTime
a:measureValue
a:measureDate
a:beginDate
a:endDate
xsd:decimal
a:Measure
a:station
id (PK) : INT
station_id (FK) : INT
date : DATETIME
value : DOUBLE
a:Station
a:latitude
a:longitude
xsd:decimal
xsd:string
measure
a:stationName
station
id (PK) : INT
name : VARCHAR(40)
latitude : DOUBLE
longitude : DOUBLE
begin_date : DATETIME
end_date : DATETIME
Figura 19. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint RSE e o
mapeamento entre conceitos.
O mapeamento usando D2R entre banco de dados e vocabulário é apresentado no
Apêndice A. O URI de cada recurso segue o padrão <http://alertario.rio.rj.gov.br:2020/
resource/CLASSE/ID>, onde CLASSE é Station ou Measure e ID é o respectivo valor da
coluna id do recurso. Como a tabela measure possui mais de 15 milhões de registros e
consultas equivocadas como “recupere todas a medidas” demorariam muito tempo para serem
108
respondidas foi criada uma visão atualizada a cada 5 segundos que engloba apenas as últimas
96 horas de medição.
4.2.2.2 User Locations Endpoint (ULE)
Este endpoint simula a obtenção das coordenadas de usuário por meio de um GPS.
Foram criadas duas maneiras de se gerar tais coordenadas. A primeira, usada para testes
iniciais, utiliza dois cenários de movimentação de usuários (um usuário por cenário) cujas
rotas foram geradas no Google Maps e exportadas para KML (Keyhole Markup Language)
manualmente. A segunda, usada para simular mais de dois usuários, é feita aleatoriamente
através de um gerador de coordenadas e rotas automático. Para ambas as informações são
armazendas em um banco de dados MySQL e o software D2R efetua o mapeamento como no
endpoint anterior. A figura apresenta o diagrama do banco de dados, o vocabulário RDF e o
mapeamento entre tabelas e classes. A separação entre o usuário e sua localização foi feita
porque a tabela location fica em memória para ter uma atualização mais rápida. O URI dos
recursos também segue o padrão <http://users.com.br:2026/resource/CLASSE/ID>. Para
detalhes sobre a estrutura do KML exportado pelo Google Maps e os algoritmos de geração
das coordenadas consulte o Apêndice B.
xsd:string
usr:nome
usr:Usuario
usr:localizacao
user
id (PK) : INT
nome : VARCHAR(60)
usr:Ponto
xsd:decimal
usr:latitude
usr:longitude
xsd:decimal
xsd:dateTime
usr:atualizacao
location
id (PK) : INT
latitude : DOUBLE
longitude : DOUBLE
instant : DATETIME
user_id : INT
Figura 20. Diagrama entidade-relacionamento (direita) e vocabulário RDF (esquerda) usados no endpoint ULE e o
mapeamento entre conceitos
4.2.2.3 Neighborhood Endpoint (NBE)
Este endpoint é o mais simples e foi adicionado apenas para mostrar a possibilidade de
obter contextos adicionais. Ele utiliza um módulo de inferência que armazena URIs e nomes
de bairros em RDF e contém uma função nb_contains adicionada por meio de plugin. Esta
função detecta se um ponto está dentro do polígono do bairro (identificado por seu URI) ou
109
não.29 As bordas dos polígonos dos bairros foram obtidas do Portal Geo da Prefeitura do Rio
de Janeiro30 e são carregadas de um arquivo KML e armazenados internamente, i.e, não
disponíveis em RDF. O uso da função (em negrito) é apresentado a seguir, onde também se
pode observar o pequeno vocabulário criado (conceitos mapa:Bairro e propriedade
rdfs:label):
1
2
3
4
5
6
PREFIX mapa: http://mapa.rio.rj.gov.br:25070/ontology#
DESCRIBE ?b
WHERE {
?b a mapa:Bairro . # rdfs:label contém o nome do bairro
FILTER(geo:nb_contains(?b, -43.258041, -22.995279))
}
4.2.3 Camada de inferência
Nesta seção apresentar-se-á o algoritmo, a ontologia e a disposição dos módulos de
inferência necessários para atingir o objetivo de emissão dos alertas apresentados na seção
4.2.1. Uma vez que os endpoints simulados apresentados na seção anterior foram colocados à
disposição, o ambiente necessário está pronto para ser usado. Na sequência serão
apresentados (1) o algoritmo de cálculo dos níveis de alerta na posição do usuário, e (2) a
organização dos módulos de inferência e a ontologia utilizada. A configuração detalhada da
rede de módulos será apresentada no Apêndice C.
4.2.3.1 Algoritmo para cálculo de níveis de alerta
Antes de apresentar o algoritmo, cabe relembrar o método, primeiramente precisa-se
obter a posição dos usuários, e a seguir, para cada um deles calcular a suposta quantidade de
chuva (Equação I) nos últimos 15 minutos, 1 hora, 24 horas e 96 horas (períodos), e
classificá-las conforme os níveis de alerta dos quadros 8, 9 e 10. O algoritmo a seguir
apresenta como isto seria feito utilizando um único programa:
1
2
3
4
5
6
7
users = SELECT ?uid ?location
WHERE {
?uid a User ; location ?location }
FOR u IN users DO
l = u.location
d = SELECT ?sid
(geo:distance(?slat, ?slon,
29
O algoritmo utilizado pode ser encontrado em http://alienryderflex.com/polygon
30
Portal Geo - http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm
110
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
l.lat, l.lon) as ?dist)
WHERE {
?sid a Station ;
location [
latitude ?slat ;
longitude ?slon ] }
ORDER BY ?dist
LIMIT 3
dtot = 0
FOR e IN d DO dtot = dtot + 1 / e.dist ^ 2
avg15 = avg60 = avg24 = avg96 = 0
FOR e IN d DO
w = ((1 / e.dist ^ 2) / dtot)
avg15 += w * acc_rain(e.sid, 15min)
avg60 += w * acc_rain(e.sid, 60min)
avg24 += w * acc_rain(e.sid, 24h)
avg96 += w * acc_rain(e.sid, 96h)
slv60 = map(avg60, [10 : Attention,
30 : Moderate,
50 : High],
VeryHigh)
slv24 = map(avg24, [50 : Attention,
100 : Moderate,
175 : High],
VeryHigh)
slv96 = map(avg96, [100 : Attention,
175 : Moderate,
250 : High],
VeryHigh)
u.slipLevel = max(slv60, slv24, slv96)
rlv15 = map(avg15, [0.28 : HeavyDrizzle,
1.25 : LightRain,
6.25 : ModerateRain,
12.5 : HeavyRain],
VeryHeavyRain)
rlv60 = map(avg60, [0.00 : Dry,
0.25 : LightDrizzle,
0.50 : ModerateDrizzle,
1.10 : HeavyDrizzle,
5.00 : LightRain,
25.0 : ModerateRain,
50.0 : HeavyRain],
VeryHeavyRain)
u.rainLevel = max(rlv15, rlv60)
111
57 FUNCTION acc_rain(sid, range)
58
RETURN SELECT (SUM(?v) AS ?acc)
59
WHERE {
60
?m station sid ;
61
measureValue ?v ;
62
measureDate ?t .
63
FILTER (?t >= TIMEDIFF(NOW, range)
64
&& ?t <= NOW) }
65
66 FUNCTION map(v, m, default)
67
FOR e IN m DO
68
IF v <= e.key THEN RETURN e.value
69
RETURN default
Apesar de parecer um algoritmo pequeno, seria um pouco complexo implementá-lo
com as bibliotecas Java existentes. Note que, para facilitar a compreensão, as consultas
SPARQL foram colocadas como parte do próprio código e sem informação dos endpoints
consultados. Resumidamente, obtém-se uma lista com URIs e localizações dos usuários
(linhas 1-3) e, ao iterar sobre a lista (linhas 4-55), obtém-se as três estações mais próximas
(linhas 5-15), calcula-se a suposta quantidade de chuva, nos quatro períodos, dada pela
fórmula da seção 4.2.1 (linhas 17-26) e, por fim, é feita a classificação dos níveis de alerta
conforme dados dos quadros 8, 9 e 10 (linhas 28-55). Nas linhas 57-64 é calcula a soma das
medições de uma estação durante o intervalo de tempo fornecido no parâmetro range.
Finalmente, as linhas 66-69 mostram a função que mapeia um valor v para um nível de alerta
conforme a tabela m fornecida.
O algoritmo desmembra a Equação I em três outras confome pode ser visto na
Equação II a seguir. Em (a) calcula-se a suposta quantidade de chuva como soma das
medições acumuladas vi(t) ponderadas por um peso wi; em (b) calcula-se o peso wi da estação i
e, em (c) calcula-se o denominador do peso wi. Examinando o algoritmo, verifica-se que as
linhas 17-18 calculam a Equação IIc, a linha 22 calcula Equação IIb e, as linhas 23-26
calculam a Equação IIa para t igual a 1, 4, 96 e 384. Desta forma, ao término do laço da linha
21, as variáveis avg15, avg60, avg24 e avg96 possuem os valores v(1)(P), v(4)(P), v(96)(P) e
v(384)(P), respectivamente.
112
3
(t )
wi vi(t )
v ( P)
(a)
i 1
wi
1
2
di
d total
3
d total
j
1
2
1 dj
(b)
(c)
Equação II. Desmembramento da Equação I em três equações separadas.
4.2.3.2 Organização dos módulos e ontologia
Esta seção apresentará a organização dos módulos para implantar o algoritmo
discutido e a ontologia construída para validar a consistências dos dados.
Para implementar este algoritmo, precisa-se primeiramente avaliar como distribuir as
consultas e regras de forma que se encaixe na estrutura atual do framework: carregamento,
processamento com ontologias e regras, e publicação. A primeira separação é simples,
bastando separar a função acc_rain em um módulo que calcula a chuva acumulada em cada
estação pluviométrica. Este poderia ser até mesmo um endpoint fornecido pelo próprio
sistema Alerta-Rio. Outra separação possível é nas linhas 1-15, onde um módulo pode
calcular e guardar as distâncias entre usuários e estações. Finalmente, um terceiro módulo
pode fazer consultas para cálculo da suposta quantidade de chuva (linhas 17-26) e processar
regras para classificação (linhas 28-55). Estes módulos serão doravante denominados M1, M2
e M3, respectivamente. Para ilustrar o acréscimo de obtenção do contexto de bairro do usuário
utilizando o endpoint NBE, mais um módulo foi adicionado e será chamado M4. A Figura 21
ilustra a configuração da rede que será detalhada nos próximos parágrafos. As setas indicam a
direção das respostas às consultas SPARQL, as linhas contínuas representam consultas
primárias e as tracejadas representam consultas secundárias realizadas por binders do tipo
SelectQueryParameterBinder. Os textos próximos às setas são os nomes atribuídos às
consultas cujo Apêndice C explicará em detalhes. Por fim, as linhas com tracejado
diferenciado ligam cada módulo a um pequeno resumo descritivo sobre ele.
113
Applicação
Contexto de bairro
Applicação
Suposta quantidade de chuva
+
classificação da intensidade de chuva e
dos níveis de alerta de escorregamento
Qapp
M4
M3
Seleciona estações mais próximas
Qchuva
Chuva acumulada por estação
+
Localização das estações ativas
M2
Qdist
Quser
Qacc2
Qacc
Qstloc
NBE
ULE
Legenda:
M1
RSE
consulta primária
consulta secundária (binder)
Módulo
- Sentido inverso:
consultas SPARQL
- Sentido direto:
respostas RDF
Descrição resumida
Figura 21. Rede de módulos de inferência para alerta de chuvas e escorregamento.
Neste cenário, a tarefa descrita no algoritmo será realizada apenas com consultas
(responsáveis por mapear conceitos usando SPARQL Construct) e regras Jena (apenas no M3
para fazer classificação). Contudo uma ontologia foi construída apenas para validar a
consistência dos dados usando o reasoner Pellet (módulos M1, M2 e M4). A Figura 22
apresenta a ontologia OWL composta por oito classes que foi validada como OWL-DL pelo
Pellet. A classe Station representa uma estação pluviométrica e a classe User o usuário, de
forma que ambas possuem uma localização associada. A primeira é associada com Location
através da propriedade location e, a segunda, associada a uma subclasse desta denominada
UserLocation através das propriedades currentLocation e inferenceLocation. Estas duas
propriedades para localização do usuário são adotadas, pois a localização corrente do usuário
pode, e geralmente é, diferente da posição utilizada na inferência. Isto ocorre porque apesar de
a primeira ser obtida tanto por M2 quanto por M4, quando o processamento de M3 termina e
disponibiliza a localização obtida por M2, esta pode não ser mais a mesma da disponibilizada
atualmente pelo ULE. Portanto, M4 pode ler duas localizações: a atual disponibilizada por
ULE e a usada na inferência que pode ser mais antiga. A propriedade updateTime informa
data e hora de atualização das coordenadas (latitude e longitude) do usuário. Sendo assim,
seria possível verificar o atraso aproximado gerado pela inferência. Adicionalmente, uma
localização contém as propriedades accRainX, que apresentam a quantidade de chuva
acumulada nos últimos 15 minutos (X=15), 1 hora (X=01h), 24 horas (X=24h) ou 96 horas
(X=96h) medida por um estação ou calculada com base na Equação I; rainLevel e slipLevel,
114
que representam as classificações de intensidade de chuva e probabilidade de escorregamento;
e por fim, locatedAt que informa a qual bairro a localização pertence (classe Neighborhood).
A classe UserLocation adiciona a propriedade nearestStations que associa a localização do
usuário com a classe StationDistanceInfo que representa uma das estações mais próximas
(station) com a respectiva distância (distance). Finalmente, as classes RainLevel e SlipLevel
correspondem ao rdfs:range das propriedades rainLevel e slipLevel, respectivamente. Seus
possíveis valores (instâncias) são fixos, pois seguem as classificações dos Quadros 8, 9 e 10, e
sua ligação à respectiva classe são representadas por uma linha tracejada. (Figura 22)
x:Dry,
x:LightDrizzle,
x:ModerateDrizzle,
x:HeavyDrizzle,
x:LightRain,
x:ModerateRain,
x:HeavyRain,
x:VeryHeavyRain
xsd:dateTime
x:latitude
x:longitude
x:RainLevel
x:rainLevel
x:Low,
x:Moderate,
x:High,
x:VeryHigh
x:locatedAt
x:name
xsd:string
x:name
x:location
x:Neighborhood
x:Station
x:UserLocation
x:nearestStations
x:station
x:currentLocation
x:inferenceLocation
x:accRain15
x:accRain01h
x:accRain24h
x:accRain96h
x:Location
x:slipLevel
x:SlipLevel
x:User
xsd:decimal
x:updateTime
x:distance
xsd:double
x:StationDistanceInfo
Figura 22. Ontologia utilizada pelo módulos M1 a M4 para o cenário de chuvas.
No final, uma aplicação poderia fazer a seguinte consulta ao endpoint M4:
1 SELECT ?usuario ?bairroAtual ?horaLocAtual ?bairroInf ?horaLocInf
2
(geo:distanceFromDegrees(?lat1, ?lon1, ?lat2, ?lon2) as ?dist)
3
(afn:localname(?rainLevel) as ?classChuva)
4
(afn:localname(?slipLevel) as ?probEscrg)
5 WHERE {
6
?u a x:User ;
7
x:name ?usuario ;
8
x:currentLocation [
9
x:locatedAt [ x:name ?bairroAtual ];
10
x:latitude ?lat1; x:longitude ?lon1;
11
x:updateTime ?horaLocAtual
12
] ;
13
x:inferenceLocation [
14
x:locatedAt [ x:name ?bairroInf ];
15
x:latitude ?lat2; x:longitude ?lon2;
115
16
17
18
19
20 }
x:updateTime ?horaLocInf;
x:slipLevel ?slipLevel;
x:rainLevel ?rainLevel
] ;
As infomações retornadas são apresentadas na Tabela 11. As colunas com o prefixo
“horaLoc” indicam o horário de quando as coordenadas da localização do usuário foram
medidas pelo GPS, e as colunas “bairro” informam o bairro a qual estas coordenadas
pertencem. As colunas com sufixo “Atual” foram capturadas diretamente de ULE por M4 e as
colunas com sufixo “Inf” foram capturadas indiretamente de ULE através do caminho M1M2-M3-M4. A coluna “dist” informa a distância entre a posição “Atual” e a posição “Inf”,
enquanto que as duas últimas colunas contêm as classificações de intensidade de chuva e
probabilidade de escorregamento para a posição “Inf”.
Tabela 11. Exemplos de resultados da consulta ao M4: atraso pequeno (acima) e pouco mais significativo (abaixo).
usuario
Camille Moraes
Mateus Veiga
John Alcantara
Jeane Murta
bairroAtual
Ramos
Jacarepagua
Jacarepagua
Pca Bandeira
horaLocAtual
2010-04-06T00:15:13
2010-04-06T00:15:13
2010-04-06T00:15:13
2010-04-06T00:15:13
bairroInf
Olaria
Jacarepagua
Jacarepagua
Pca Bandeira
horaLocInf
2010-04-06T00:14:31
2010-04-06T00:14:31
2010-04-06T00:14:31
2010-04-06T00:14:31
dist
classChuva
probEscrg
913,39 ModerateRain Moderate
933,56
LightRain
Moderate
933,40
LightRain
Moderate
934,52 HeavyRain
Moderate
usuario
Camille Moraes
Mateus Veiga
John Alcantara
Jeane Murta
bairroAtual
Copacabana
Barra da Tijuca
Vila Militar
Vasco da Gama
horaLocAtual
2010-04-06T01:43:09
2010-04-06T01:43:09
2010-04-06T01:43:09
2010-04-06T01:43:09
bairroInf
Gavea
Camorim
Realengo
Jacarezinho
horaLocInf
2010-04-06T01:40:47
2010-04-06T01:40:47
2010-04-06T01:40:47
2010-04-06T01:40:47
dist
classChuva
probEscrg
4393,48
LightRain
High
3133,75 ModerateRain Moderate
3156,04 HeavyRain
Moderate
3155,34 ModerateRain
High
Para finalizar a seção, dois exemplos de notificações que uma aplicação poderia fazer
usando estes resultados são mostrados a seguir. Para o primeiro suponha que o horário do
informe seja 00h16min41s e para o segundo 01h45min50s.
1
2
“Camille Moraes, dados pluviométricos baseados na sua localização no
bairro Olaria há 2min10s apontam chuva de intensidade moderada e
probabilidade de escorregamento moderada. Uma posição mais recente
foi obtida há 1min28s a 910 m de distância no bairro Ramos mas ainda
não foi processada.”
“Camille Moraes, dados pluviométricos baseados na sua localização no
bairro Gávea há 5min03s apontam chuva de intensidade leve e
probabilidade de escorregamento alta. Uma posição mais recente foi
obtida há 2min41s a 4,4 km de distância no bairro Copacabana. Apesar
de agora a chuva estar fraca, o acumulado mostra que lugares
sucetíveis a escorregamento de terra estão arriscados.”
116
4.2.4 Discussão
Ainda em relação à Tabela 11, observa-se que horaLocInf <= horaLocAtual, conforme
esperado. Esta diferença pode ser mais ou menos significativa (tabelas inferior e superior),
pois depende dos intervalos entre consultas definidos em cada um dos módulos do caminho,
da velocidade de conexão da rede e capacidade de processamento. Uma melhor avaliação
destes atrasos e possíveis formas de contorná-los (como uso de push loaders) deve ser alvo de
trabalhos futuros.
Uma difículdade adicional encontrada na implementação deste cenário foi a
necessidade de construir três endpoints para simular um mundo onde dados de sensores
físicos (ULE, RSE) e bases de dados provedoras de contexto (NBE) estivessem disponíveis.
Vantagens e desvantagens podem ser verificadas. Primeiramente, a quantidade de
chuva acumulada por estação é calculada por M1 de uma vez a cada 2,5 minutos evitando
repetição de consultas como o algoritmo sugere. Contudo, uma implementação convencional
do algoritmo (via programação) poderia fazer cache destes valores e atualizar (a) em
intervalos de tempo predefinidos (como na rede detalhada aqui) ou (b) quando houvesse
modificação. Neste segundo caso, quando novos dados fossem gerados pelo RSE, alguma
consulta seria executada e os resultados enviados ao cache. Um problema desta abordagem é
a possibilidade de que tais dados fossem gerados em sequência e em intervalos de tempo
muito curtos (ordem de milissegundos) o que acarretaria na abertura de muitas conexões TCP,
sendo necessário considerar medidas como conexões persistentes ou enviar respostas em
rajada (acumular até que uma certa quantidade fosse atinginda e/ou que algum intervalo de
tempo expirasse). Esta abordagem recai nos já discutivos push loaders (carregadores
assíncronos) que devem ser estudados em trabalhos futuros.
Outra vantagem é que apesar de ser necessário construir ontologias, consultas e regras,
que se apresenta como um trabalho longo e cansativo, após tais elementos estarem definidos,
a construção dos arquivos XML de configuração é muito simples. Além disso, tais elementos
precisariam ser construídos mesmo em uma implementação envolvendo programação
convencional. A configuração via XML reduz a necessidade de programação, deixando a
implementação do cerne da solução para modeladores e também para especialistas nas
tecnlogias padronizadas da Web Semântica (RDF, OWL, SPARQL e futuramente uma
linguagem para regras). A consulta Qchuva é complexa (veja Apêndice C), mas a
implementação do algoritmo usando programação também o é, sendo difícil concluir sem
experimentos que comparem ambas as abordagens.
117
Observando as consultas construídas, verifica-se também que o sistema poderia ser
expandido facilmente para considerar outras localizações, e não apenas a atual medida pelo
GPS, como casa, trabalho, destinos de viagens, etc. com poucas mudanças. Na verdade
bastaria haver mais instâncias de usr:Ponto na base ULE e criar um propriedade base para
inferenceLocation e currentLocation ou tornar location esta propriedade base. Poderia-se
também criar, por exemplo, propriedades homeLocation, workingLocation, entre outras, mas
o uso de uma propriedade base seria mais simples. Uma nova propriedade de usr:Ponto
poderia ser responsável por manter a informação sobre o que significa aquele ponto (casa,
posição atual, trabalho, etc.) ou poderia-se também criar subclasses. Por fim, pequenas
alterações seriam feitas nas consultas Quser e Qchuva. Outro aspecto interesante é que a
expansão da Equação I para qualquer valor constante N de estações mais próximas pode ser
atingido modificando apenas o valor do LIMIT no Sub-SELECT da consulta Qdist. Veja
Apêndice C para detalhes das consultas.
Assim, a partir da implementação deste cenário, verificou-se que apesar de alguns
problemas terem sido encontrados, há indícios de que a abordagem pode ser boa devido a
redução da necessidade de programação e da possibilidade de validar a base sendo
disponibilizada.
4.3
Cenário 3: notificação sobre eventos sociais e chegadas de ônibus
Devido à agitação diária nos dias atuais é cada vez mais difícil para as pessoas
gerenciar compromissos (reuniões de trabalho, aniversários de casamento, etc.) sem utilizar
meios eletrônicos que auxiliem a armazenar e lembrar a ocorrência destes eventos. Além
disso, nem todos os eventos podem ser determinados com antecedência e adicionados a uma
agenda, mesmo que eletrônica, como é o caso de chegadas de um ônibus ou metrô no ponto
ou estação onde um usuário se localiza. Neste segundo caso um atraso na chegada de um
metrô ou ônibus deixaria o usuário aguardando, provavelmente parado e entediado, enquanto
que a ciência do atraso permitiria que ele adiantasse outras possíveis tarefas que não
dependessem daquele transporte naquelo momento.
Este cenário tem por objetivo ilustrar o uso de ontologias, consultas e regras dispostas
em módulos do framework para gerar notificações aos usuários sobre alguns dos eventos
discutidos acima. Além disso, o cenário não deve ser muito complexo para possibilitar
entendimento por parte das pessoas que irão testar e avaliar o framework. Este cenário é,
118
justamente, o escolhido para que alunos de Web Semântica testem o framework e forneçam
suas avaliações via questionário (próximo capítulo). Por fim, mas não menos importante, este
cenário ilustrará o consumo de dados de três SPARQL endpoints independentes que são
integrados por meio de ontologias comuns, diferentemente do cenário anterior que
apresentava uma ontologia para cada endpoint que eram mapeadas para a ontologia de
domínio via SPARQL Construct.
As próximas subseções apresentarão maiores detalhes sobre o domínio, incluindo as
ontologias e os endpoints criados para serem usados como exemplo e a implementação da
rede de módulos. Maiores detalhes técnicos são abordados no Apêndice D e no Apêndice E.
4.3.1 Domínio da aplicação e modelagem
Para gerar notificações sobre eventos foi montado um conjunto de ontologias que
pudesse representar os aspectos dos domínios das relações sociais e dos transportes por
ônibus necessários para a construção do cenário. Sendo assim, ontologias para os tópicos
tempo, eventos e relacionamento entre pessoas foram adaptadas de outras existentes, e uma
ontologia de transporte rodoviário por ônibus foi construída. Nas próximas subseções serão
detalhadas estas ontologias e uma ontologia específica da aplicação que expande as ontologias
de eventos e transporte por ônibus com o objetivo de mostrar como ontologias de aplicação
podem estender ontologias já existentes.
4.3.1.1 Ontologia de tempo e eventos (TEvOnto)
Para descrever eventos e suas ocorrências no tempo foram definidas duas ontologias.
A ontologia de tempo é uma versão simplificada da OWL Time (PAN; HOBBS, 2003) e a
ontologia de eventos é um subconjunto da Ontonym Event Ontology (STEVENSON et al.,
2009). Eventos podem possuir datas de início e fim bem definidas como datas ou festas de
aniversários, reuniões de trabalho, etc. ou podem ser ocorrências pontuais no tempo cujo
intervalo não pode ser facilmente caracterizado como chegadas de ônibus em um ponto. Para
isso, são definidos eventos de intervalo e de instante, que se baseiam nos conceitos de
intervalo e instante da OWL Time.
Na Figura 23 pode-se observar estas ontologias. A classe TemporalEntity é a
superclasse para representação do tempo. Esta se especializa em Interval e Instant que
representam um intervalo de tempo com início e fim e um instante pontual no tempo,
respectivamente. A classe Event é a superclasse das classes IntervalEvent e InstantEvent que
119
representam eventos de intervalo e de instante, respectivamente. As propriedades
hasBeginning e hasEnd representam início e fim de um intervalo e a propriedade
hasDateTime representa um ponto no tempo. As três propriedades possuem um xsd:dateTime
como rdfs:range que armazena ano, mês, dia, hora, minuto e segundo. As propriedades
timeSpan e atTime relacionam um evento com o respectivo objeto de tempo. Por fim, existe
uma classe Role (papel), cujas instâncias são indivíduos que desempenham algum papel em
um evento. Role e Event são ligados por meio da propriedade playsRole indicando que o
primeiro tem participação no segundo. A maior parte das classes e propriedades foi
aproveitada das ontologias OWL Time e Ontonym Event. Contudo, propriedades de Instant
foram removidas para dar lugar a hasDateTime e as propriedades hasBeginning e hasEnd de
Interval tiveram seus ranges modificados para xsd:dateTime.
Figura 23. Diagrama das ontologias de tempo e eventos utilizadas.
4.3.1.2 Ontologia de relações sociais (SoROnto)
Para representar as relações sociais foi desenvolvida uma ontologia que usa o conceito
foaf:Person e cria outros conceitos baseados nas ontologias Relationship31 e Ontonym Person
Ontology (STEVENSON et al., 2009). A Figura 24 apresenta o diagrama de classes que é
formado pelos conceitos foaf:Person, rel:Woman e rel:Man, que representam pessoas como a
união disjunta (owl:disjointUnionOf) de mulheres e homens e os conceitos rel:Relationship,
rel:Marriage e rel:Courtship que representam relacionamentos genéricos, casamentos e
namoros respectivamente. Os participantes são sempre pessoas e, embora possível, nenhum
outro tipo de relacionamento precisou ser criado para o cenário. Uma pessoa é uma entidade
31
RELATIONSHIP – A vocabulary for describing relationships between people: http://vocab.org/relationship
120
geográfica (geo:SpatialThing) pois possui dados de localização (latitude e longitude). Esta
mesma figura apresenta o domínio e a imagem das propriedades que relacionam pessoas.
Na Figura 25 pode-se observar a hierarquia das propriedades que representam as
relações parente (rel:relativeOf), ancestral e descendente (rel:ancestorOf e rel:descendantOf),
pai e mãe (rel:parentOf, rel:motherOf, rel:fatherOf), filho(a) (rel:childOf), irmão e irmã
(rel:siblingOf, rel:sisterOf, rel:brotherOf), conhecido (foaf:knows), amigo(a) (rel:friendOf),
vizinho(a) (rel:neighborOf) e relacionamentos amorosos genéricos (rel:romanticallyInvolvedWith) e mais específicos como matrimônio (rel:spouseOf, rel:husbandOf, rel:wifeOf) e
namoro (rel:courts, rel:boyfriendOf, rel:girlfriendOf). Na mesma figura aparecem alguns
detalhes: do lado direito a propriedade sobre a data de aniversário de uma pessoa, e do lado
esquerdo mostra que propriedades ligados por seta dupla são inversas uma da outra e uma seta
dupla ligando a mesma propriedade indica que está é simétrica.
Figura 24. Diagrama de classes da ontologia de relações entre pessoas.
Figura 25. Diagrama de hierarquia de propriedades da ontologia de relações entre pessoas.
121
4.3.1.3 Ontologia de transporte por ônibus (BusOnto)
A terceira ontologia foi desenvolvida para representar ônibus, paradas e linhas de
ônibus e itinerários destas linhas. Sua construção não se baseou em nenhuma ontologia
existente, sendo, portanto, fruto deste trabalho.
Na Figura 26 é possível ver que ela se baseia em cinco classes principais: bus:Stop,
bus:Line, bus:Route, bus:RouteStop e bus:Bus. A primeira representa uma parada ou ponto de
ônibus possuindo um nome além de um par de coordenadas geográficas provenientes da
classe geo:SpatialThing. A segunda representa uma linha de ônibus possuindo um código, um
nome e uma rota (ou itinerário). O código é uma sequencia de números e letras que identifica
a linha, por exemplo, no município do Rio de Janeiro, linhas convencionais são identificadas
por três números: 485, 497, 910. A terceira classe representa um itinerário com sentido,
portanto linhas com caminhos de ide e volta possuem duas rotas e linhas circulares possuem
apenas uma rota. Esta classe apresenta um ponto inicial e um ponto final que podem ser os
mesmos para o caso de linhas circulares. Contudo estes pontos não são representados pela
mesma classe bus:Stop, mas pela classe bus:RouteStop que indica o ponto de uma rota de
ônibus. Para entender melhor esta distinção repare que um bus:Stop não necessariamente é
seguido por um outro ponto de ônibus em todos os itinerários, assim é necessária uma classe
que permita manter esta sequência. Desta forma, um bus:RouteStop possui as propriedades
bus:nextStop e bus:previousStop (que são inversas entre si) para formar a sequência de
paradas e também a propriedade bus:belongsToRoute para determinar a qual itinerário
pertence. Adicionalmente, há um atributo bus:sequence que permite saber numericamente
qual o índice desta parada na rota e um atributo bus:distanceFromOrigin que apresenta a
distância em metros desde o ponto inicial da rota até a respectiva parada seguindo todo o
caminho do itinerário. Por fim, a última classe é a bus:Bus que representa um ônibus que
circula na cidade e, consequentemente, possui coordenadas geográficas da sua posição atual,
uma rota e uma linha associadas além dos atributos bus:number, bus:traveledTime e
bus:traveledDistance. O primeiro é apenas o número do carro, também conhecido como
número de ordem. O segundo e terceiro indicam o tempo decorrido e a distância percorrida
deste a saída do carro do ponto inicial.
122
Legenda
double
domain
geo:lat
geo:
SpatialThing
double
property
range
bus:sequence
string
geo:long
integer
bus:name
rdfs:subClassOf
bus:Bus
bus:number
bus:distanceFromOrigin
bus:stop
bus:Stop
bus:startStop
bus:nextStop
bus:previousStop
integer
bus:finalStop
bus:traveledTime
integer
float
bus:
RouteStop
bus:Route
bus:belongsToRoute
bus:route
bus:name
string
bus:belongsToLine
bus:code
float
bus:traveledDistance
bus:Line
string
bus:servingLine
Figura 26. Ontologia de transporte por ônibus.
4.3.1.4 Ontologia específica da aplicação (AppOnto)
A última ontologia a ser apresentada é a ontologia específica da aplicação. Ela estende
as ontologias TEvOnto e BusOnto através da adição de classes que representam eventos de
datas comemorativas e de chegadas de ônibus, papéis de aniversariante, de amigo de
aniversariante e de passageiro, além das notificações.
A Figura 27 apresenta a ontologia da aplicação juntamente com partes relevantes das
ontologias bases (TEvOnto e BusOnto). As classes evt:IntervalEvent e evt:InstantEvent são
especializadas em app:CommemorativeDate e app:BusArrival que representam uma data
comemorativa e uma chegada de ônibus, respectivamente. Datas comemorativas podem ser
eventos genéricos como dia dos namorados (app:ValentinesDay) e feriado (app:Holiday),
eventos pessoais individuais (que dependem apenas de uma pessoa para ocorrer) como
aniversário (app:Birthday), ou eventos pessoais em dupla (ocorrência dependente de duas
pessoas) como aniversário de namoro ou casamento (app:CourtshipDay e app:WeddingDay).
Um feriado pode ser especializado em Dia das Mães (app:MothersDay). Estas classificações
de evento genérico e pessoal poderiam ter sido explicitadas na ontologia assim como outros
tipos de evento poderiam ter sido construídos, mas decidiu-se por não poluir a ontologia com
informações desnecessárias e facilitar entendimento por partes do leitor. No lado direito da
123
figura pode-se observar as relações entre alguns destes novos eventos e três novos papéis
criados (subclasses de evt:Role). Todos estes novos papéis são também subclasses de
foaf:Person. Assim, app:Passenger representa um possível passageiro (poderia ser likely
passenger), app:BirthdayPerson representa um aniversariante e app:BirthdayPersonsFriend
um amigo de aniversariante (birthday person’s friend). O primeiro papel é associado ao
evento chegada de ônibus por meio da propriedade app:isPassengerOf, ou seja, diz que uma
pessoa é um possível passageiro do ônibus prestes a chegar, ou seja, do ônibus associado ao
evento de chegada. O segundo e terceiro papéis são associados ao evento aniversário por meio
das propriedades app:isBirthdayPersonOf e app:isBirthdayPersonsFriendOf. Todas as três
propriedades são especializações da propriedade evt:playsRole que representa uma
participação em um evento (canto inferior esquerdo da figura).
Na região superior direita observa-se um maior detalhamento do evento
app:BusArrival que relaciona um ônibus com o ponto de ônibus onde ele está prestes a
chegar. Apesar de não ter sido ilustrado, este evento herda a propriedade evt:atTime de
evt:InstantEvent como visto na Figura 23. Nesta mesma região do diagrama aparece a classe
app:BusStopRecommendation que representa uma recomendação sobre qual dentre os pontos
de ônibus mais próximos do usuário está no caminho de uma certa rota de linha de ônibus de
maneira que esta rota irá posteriormente passar num ponto cujo nome foi especificado pelo
usuário através da propriedade app:desiredDestination. Desta maneira, a propriedade
app:stop representa tal parada de ônibus, a propriedade app:route representa a rota e o
atributo app:distance representa a distância entre a posição atual do usuário e a posição do
ponto de ônibus. A propriedade app:recommendedBusStop liga um usuário a uma
recomendação.
Ainda com respeito a Figura 27, observa-se no canto superior esquerdo a classe
app:Notification que representa uma notificação a um usuário sobre a ocorrência de um
evento. O usuário é dito o alvo da notificação e relacionado através da propriedade
app:target, e o evento é relacionado pela propriedade app:event. Apesar de o alvo sempre ser
um usuário neste cenário, decidiu-se por deixar a classe owl:Thing como o range da
propriedade app:target, pois acredita-se que notificações não necessariamente precisam ser
enviadas apenas a pessoas. Os atributos app:remainingTime e app:remainingDays indicam
quanto tempo falta para o evento ocorrer em segundos e dias respectivamente.
As consultas e regras associadas à criação de eventos, participações, recomendações e
notificações serão apresentadas na seção sobre a camada de inferência.
124
Figura 27. Ontologia específica da aplicação que estende as ontologias de evento e ônibus.
4.3.2 Camada de dados e sensoriamento
Para este cenário, três SPARQL endpoints simulados foram criados. O primeiro deles,
denominado Commemorative Dates Endpoint (CDE), fornece datas comemorativas que sejam
eventos gerais (independentes da existência de uma pessoa). O segundo, denominado User’s
Social Networks and Locations Endpoint (USNLE), armazena a rede social, localização e
destino desejado dos usuários. O terceiro, chamado Bus Locations Endpoint (BLE), armazena
tanto informações estáticas como rotas e pontos de ônibus quanto informações dinâmicas
sobre a localização geográfica de cada carro. Para facilitar a compreensão por parte dos
experimentadores apenas BLE sofre atualizações frequêntes e as demais bases são estáticas,
logo, as localizações dos usuários e seus destinos nunca se alteram. BLE é um provedor de
contexto que fornece dados de uma rede de sensores físicos e de bases de dados, pois provêm
dados que seriam capturados pelos dispositivos GPS dos ônibus e também informações
estáticas e impessoais de rotas, linhas, etc. USNLE é um provedor de contexto como perfis de
usuário e sensores físicos.
Estes endpoints não possuem ontologias específicas como no Cenário 2, logo o mesmo
conjunto de ontologias descrito na seção 4.3.1 é utilizado por eles, com apenas algumas
particularidades que serão descritas ao longo das demais subseções juntamente com sua
implementação.
125
4.3.2.1 Commemorative Dates Endpoint (CDE)
Este endpoint estático armazena informações sobre datas comemorativas que
independem da uma ou mais pessoas para ocorrer. Estas datas se enquadram em um dos
eventos genéricos app:ValentinesDay, app:Holiday e app:MothersDay, que por serem
eventos de intervalo possuem uma data fixa de início e fim. O Quadro 12 apresenta os eventos
adicionados à base com as respectivas classes e datas de início e término, todos com intervalo
de um único dia. Por questões de espaço a coluna “Recurso” contém apenas a parte final do
URI do evento, de forma que a URI do evento é obtida pela concatenação do URI base
<http://commemorative_days.org/resource/> com o respectivo valor da coluna. Utilizando os
valores do quadro descreve-se um evento usando a seguinte sequência de triplas:
1
2
3
4
5
6
7
:ConfUniv2012
a
app:Holiday ;
rdfs:label "Feriado do Dia da Confraternizacao Universal"@pt ;
evt:timeSpan [
a time:Interval ;
time:hasBeginning "2012-01-01T00:00:00Z"^^xsd:dateTime ;
time:hasEnd
"2012-01-02T00:00:00Z"^^xsd:dateTime
] .
Para colocar o endpoint funcionando utilizou-se o próprio Módulo de Inferência, pois,
neste caso, ele apresenta duas vantagens em relação a bases de triplas tradicionais: (a) uso de
uma consulta simples para gerar dados, e (b) configuração simples da ontologia AppOnto.
Devido à obrigatoriedade de se especificar um endpoint como fonte de dados, esta consulta
utiliza o próprio endpoint gerado pelo módulo, porém a cláusula WHERE é vazia e todas as
triplas estão estaticamente presentes na cláusula CONSTRUCT. Devido a esta estaticidade a
consulta pode ter intervalo entre execuções bastante longo. O uso da AppOnto permite
inferência imediata das superclasses de cada evento e das classes dos blank nodes
representando cada intervalo de tempo além da checagem da consistência dos dados. Na
configuração do módulo apresentada a seguir observe o uso do mesmo endereço para servidor
SPARQL e endpoint de consulta (localhost na porta 50000), o intervalo de 24 horas entre
execuções da consulta e a configuração do Pellet para utilizar a ontologia AppOnto:
1
2
3
4
5
6
7
8
<InferenceModule>
<name>Base de dados de datas comemorativas</name>
...
<loaders>
<PullLoader>
<endpoint>http://localhost:50000/graph/sparql</endpoint>
<queryConfigs>
<QueryData>
126
9
<query>
10
CONSTRUCT {
11
:ConfUniv2012
a apv:Holiday ;
12
rdfs:label "Feriado da Confraternizacao Universal"@pt ;
13
evt:timeSpan [
14
a time:Interval ;
15
time:hasBeginning "2012-01-01T00:00:00Z"^^xsd:dateTime ;
16
time:hasEnd
"2012-01-02T00:00:00Z"^^xsd:dateTime
17
] .
18
# Demais eventos aqui...
19
}
20
WHERE { }
21
</query>
22
<interval>24*60*60*1000</interval>
23
<binder class="DefaultQueryParameterBinder" />
24
</QueryData>
25
</queryConfigs>
26
</PullLoader>
27 </loaders>
28 <inference>
29
<reasoner>PELLET</reasoner>
30
<ontology>AppOnto.owl</ontology>
31 </inference>
32 <sparqlServer>
33
<path>/graph/</path>
34
<port>50000</port>
35
<fastUpdate>false</fastUpdate>
36 </sparqlServer>
37 </InferenceModule>
Quadro 12. Datas comemorativas utilizadas no endpoint CDE com as respectivas classes e datas.
Recurso
Classe
Início
Fim
ConfUniv2012
apv:Holiday
2012-01-01T00:00:00Z
2012-01-02T00:00:00Z
Tiradentes2012
apv:Holiday
2012-04-21T00:00:00Z
2012-04-22T00:00:00Z
Trabalho2012
apv:Holiday
2012-05-01T00:00:00Z
2012-05-02T00:00:00Z
Independencia2012
apv:Holiday
2012-09-07T00:00:00Z
2012-09-08T00:00:00Z
DiaNamorados2012
apv:ValentinesDay
2012-06-12T00:00:00Z
2012-06-13T00:00:00Z
DiaDasMaes2012
apv:MothersDay
2012-05-13T00:00:00Z
2012-05-14T00:00:00Z
127
4.3.2.2 User’s Social Networks and Locations Endpoint (USNLE)
Este endpoint contempla informações da rede social dos usuários, suas localizações e
também os destinos desejados por eles. A rede social é apresentada na Figura 28 e as demais
informações no Quadro 13. Pela figura pode-se observar que existem 12 usuários no endpoint
e eles se relacionam de diversas formas, contudo as informações estão incompletas e as
relações implícitas são descobertas com base na ontologia SoROnto. Algumas datas de
aniversário, casamento e namoro foram definidas para Carlos Silva, Julia Silva, Ana Lins
Silva e alguns outros. O quadro de Carlos Silva, por exemplo, que contém sua data de
aniversário (1970-09-15) que é representa pela propriedade rel:dateOfBirth. Outro exemplo é
a relação de casamento entre Carlos e Julia (rel:Marriage) que pode ser construída com base
na afirmação de que Carlos é marido de Julia e se casaram em 1992-07-05 (conforme
apresentado no inferior da relação rel:husbandOf). Este casamento pode ser escrito usando as
triplas
a
seguir
que
definem,
além
da
propriedade
rel:husbandOf,
o
recurso
CarlosAndJuliaMarriage que é instância do conceito rel:Marriage e tem Carlos como
participante (rel:participantIn). O processo de inferência pode descobrir que este recurso
também é uma instância de evt:IntervalEvent através da propriedade evt:timeSpan.
1
2
3
4
5
6
:CarlosSilva
rel:husbandOf
:JuliaLins ;
rel:participantIn :CarlosAndJuliaMarriage .
:CarlosAndJuliaMarriage a rel:Marriage ;
evt:timeSpan
:CarlosAndJuliaMarriageTime .
:CarlosAndJuliaMarriageTime a time:Interval ;
time:hasBeginning "1992-07-05T00:00:00Z"^^xsd:dateTime .
128
Paulo Lins
Pedro
rel:brotherOf
rel:fatherOf
Rodrigo
rel:friendOf
Manoel Silva
rel:brotherOf
Carlos Silva
(1970-09-15)
Julia Silva
(1971-04-08)
rel:husbandOf
(1992-07-05)
rel: childOf
Marcelo
rel: friendOf
rel:friendOf
rel:girlfriendOf
(2011-06-15)
Vitor
Ana Lins Silva
(1994-05-08)
rel: friendOf
Mariana
rel:motherOf
rel:boyfriendOf
(2010-04-17)
Felipe
foaf:knows
Joana
rel:neighborOf
Figura 28. Rede social dos usuários do endpoint USNLE.
O Quadro 13 apresenta os usuários cuja localização geográfica é conhecida e um texto
representando o destino deles. Note que este texto simula uma digitação feita pelo próprio
usuário. Os dados do quadro são facilmente convertidos em triplas que obedecem as
ontologias criadas conforme apresentado a seguir para o usuário Pedro:
1
2
3
4
:Pedro
geo:lat -22.860754 ;
geo:long -43.227124 ;
rdfs:comment "Localizado no ponto da Letras"@pt ;
app:desiredDestination "alojamento" .
Quadro 13. Localização atual e destino desejado dos usuários do USNLE.
Usuário
Destino
desejado
latitude
longitude
Descrição do local
Pedro
alojamento
-22,860754
-43,227124
Ponto da Letras
AnaLinsSilva
penha
-22,858565
-43,232525
Vermelhinho
Felipe
general
-22,858565
-43,232525
Vermelhinho
Marcelo
vila
-22,857799
-43,232585
Sala do CCMN
Mariana
hospital
-22,858900
-43,230620
Bloco A do CT
129
Vitor
penha
-22,842834
-43,234262
Estacionamento do
CCS em frente ao BB
Por também ser uma base estática que necessita de inferência foi aplicada a mesma
ideia do CDE de usar um módulo de inferência. Foi escrita uma consulta com triplas
descrevendo as informações dos usuários e as ontologias TEvOnto e SoROnto foram
definidas para inferência. Consulta e o arquivo XML de configuração não serão mostrados
para evitar repetições desnecessárias.
4.3.2.3 Bus Locations Endpoint (BLE)
Este endpoint necessita tanto simular movimentação dos ônibus quanto fazer
inferência com respeito à ontologia BusOnto. A simulação de movimentação foi feita de
forma similar ao endpoint ULE do Cenário 2 (seção 4.2.2.2), utilizando uma aplicação Java
que atualiza um banco de dados relacional e o D2R que mapeia os dados do banco relacional
para triplas e as disponibiliza em um SPARQL endpoint. Para processamento das ontologias
decidiu-se utilizar o módulo de inferência pelo mesmo motivo dos endpoints CDE e USNLE
(seções 4.3.2.1 e 4.3.2.2): facilidade de alimentação de dados e configuração das ontologias e
do endpoint. Observando-se a Figura 26 (pág. 122), verifica-se que a ontologia inclui dados
com alta e baixa taxa de atualização. Apenas a classe bus:Bus está relacionada a dados com
alta taxa, enquanto que as demais classes possuem dados raramente atualizados, apenas
quando há mudanças em itinerários, linhas e pontos de ônibus (durante a execução deste
cenário estes dados nunca são modificados de fato).
A montagem real deste endpoint é apresentada na Figura 29. O endpoint BusD2R
fornece dados sobre instâncias das classes bus:Stop, bus:Line, bus:Route, bus:RouteStop e
bus:Bus correspondendo a uma parte da ontologia BusOnto para evitar a escrita de longos
arquivos de mapeamento do D2R. As triplas publicadas com este vocabulário são expandidas
e validadas através de inferências feitas pelos demais módulos apresentados na figura. Optouse por utilizar dois módulos para evitar processamento repetitivo e desnecessário dos dados
estáticos. Assim, o módulo BusStatic consome os dados estáticos do endpoint BusD2R
(paradas, linhas, rotas e paradas de rotas) e o módulo BusDyn consome os dados dinâmicos
de ônibus (classe bus:Bus). Mas especificamente, BusStatic envia uma consulta DESCRIBE
ao endpoint BusD2R para listar e descrever as instâncias das classes bus:Stop, bus:Line,
bus:Route e bus:RouteStop a cada hora e usa Pellet para inferência da ontologia BusOnto. O
módulo BusDyn envia uma consulta ao endpoint BusStatic para recuperar todas as triplas a
130
cada 10 minutos e outra consulta ao endpoint BusD2R para descrever as instâncias de bus:Bus
a cada segundo, combinando todas estas triplas através do motor de inferência do Jena.
Concluindo, o endpoint BLE agrupa estes três elementos (BusD2R, BusStatic e BusDyn)
transformando-se em uma caixa preta que é acessada pela interface SPARQL do módulo
BusDyn. Maiores detalhes são descritos no Apêndice D.
BusDyn
Rotas, linhas, etc. (10min)
bus:Bus (10s)
Legenda:
BusStatic
Módulo
descrição
Sentido inverso: consultas SPARQL
Sentido direto: respostas RDF
Rotas, linhas, etc. (1h)
+ Pellet
BusD2R
Figura 29. Estrutura interna do endpoint BLE.
4.3.3 Camada de inferência
Nesta seção será apresentada a organização dos módulos para gerar as notificações
utilizando as ontologias descritas na seção 4.3.1 e algumas regras. A configuração detalhada,
com consultas e regras usadas, é apresentada no Apêndice E, sendo assim, esta seção fornece
explicações menos técnicas.
A camada de inferência é organizada em cinco módulos que são apresentados na
Figura 30. Os nomes nas arestas representam consultas utilizadas e os números ao lado de
alguns módulos informam a quantidade de regras utilizadas por ele. Os retângulos ligados aos
módulos com uma seta tracejada descrevem suas funções.
O módulo A1 obtém eventos genéricos de CDE (app:ValentinesDay, app:Holiday e
app:MothersDay) e dados dos perfis de usuários com suas relações interpessoais (SoROnto)
para gerar outros eventos e participações. No tocante aos eventos pessoais (apv:Birthday,
apv:WeddingDay e apv:CourtshipDay) estes são criados a partir da propriedade
rel:dateOfBirth de foaf:Person e relações entre indivíduos (rel:participantIn com objeto
pertencente a um dos conceitos rel:Marriage ou rel:Courtship). As participações de usuários
em eventos são geradas tanto para os eventos pessoais quanto para os genéricos (de CDE).
131
Legenda:
Applicação
consulta primária
Gera notificações sobre
eventos aos usuários
consulta secundária (binder)
NEvt 3
Módulo
Gera recomendações de
pontos próximos aos
usuários com linhas úteis
1
Gera eventos pessoais e
participações de
usuários em eventos
genéricos e pessoais
B3
Qrec2
A1
Qcmdate
7
B2
Qurel
Qrec
CDE
USNLE
Descrição resumida
Qlow
Qhigh
Qall
Qall
- Sentido inverso:
consultas SPARQL
- Sentido direto:
respostas RDF
Qarrival2
Gera possíveis participações
de usuários nas chegadas de
ônibus utilizando as
recomendações
B1
Qarrival1
BLE
Gera eventos de
chegadas de ônibus em
pontos de ônibus
Figura 30. Rede de módulos de inferência para notificações sobre eventos (números ao lados de módulos indica
quantidade de regras usadas).
A tríade B1-B2-B3 constrói as possíveis participações em eventos referentes a
chegadas de ônibus. B1 gera apenas os eventos de chegadas (classe app:BusArrival) dizendo
quais carros chegarão em quais pontos de ônibus e o horário estimado da chegada. B2 gera
recomendações sobre qual dentre os pontos de ônibus mais próximos de cada usuário está no
caminho de uma certa rota de linha de ônibus de maneira que esta rota irá posteriormente
passar num ponto cujo nome foi especificado pelo usuário como destino desejado. Para tal,
B2 obtém de USNLE as coordenadas geográficas atuais dos usuários e os destinos desejados
por eles, assim como as coordenadas geográficas de pontos de ônibus e as rotas de BLE. B3
reúne os eventos de chegada de B1 e as recomendações de B2 e gera possíveis participações
dos usuários nestes eventos (propriedade app:isPassengerOf).
Por fim, NEvt agrupa as participações criadas por A1 e B3 e gera notificações sobre
todos estes eventos utilizando três regras: (a) notificação de participações em eventos
genéricos e pessoais (feriados, aniversário de casamento, etc., exceto aniversários de
nascimento); (b) notificação a amigos de aniversariantes, que é uma evento pessoal, mas cujo
aniversariante (que também é um participante) não precisa ser notificado; e (c) notificação
sobre chegadas de ônibus provavelmente úteis.
132
4.3.4 Visualização das notificações em navegador Web
Para visualizar as notificações foi construída uma pequena página Web. Ela plota
ícones estáticos referentes aos pontos de ônibus (oriundos de BLE) e às localizações dos
usuários (oriundos de USNLE) num mapa usando da API do Google Maps. A movimentação
dos ônibus também é apresentada juntamente com notificações. A Figura 31 mostra os ícones
espalhados no mapa e as notificações partindo do canto superior direito. A página foi
construída usando JavaScript e Ajax no lado do cliente e Java no lado do servidor. O uso de
Java se tornou imprescindível devido à facilidade de se portar para os alunos rodarem em seus
micros sem precisar instalar servidores HTTP. Além disso, a especificação do objeto
XMLHttpRequest usado em chamadas Ajax proíbe chamadas fora do domínio da página,
assim, não seria possível executar as consultas aos endpoints USNLE e BLE, o que resultaria
em cada aluno ter que executar todos estes endpoints em suas máquinas. As notificações para
um usuário são exibidas ao clicar no respectivo ícone.
Figura 31. Página Web para visualização de pontos, ônibus, usuários e notificações.
133
5
Experimentos e Resultados
O teste com alunos visa receber comentários, críticas e sugestões sobre a eficiência do
framework em cobrir os objetivos de reutilização e facilidade de configuração. No restante
desta seção serão apresentados o formato do experimento e a avaliação dada pelos alunos.
5.1
Formato do experimento
O experimento passado aos alunos consistiu na montagem da rede do cenário 3.
Contudo, como a montagem desde o início seria algo muito complexo e o intuito não era de
que os alunos escrevessem consultas e regras, mas sim que entendessem o funcionamento do
módulo e como configurá-lo, de modo que pudessem ser capazes de pegar consultas e regras
prontas e colocar na região certa do XML correto, decidiu-se solicitar que apenas
completassem os arquivos XML. Sendo assim, algumas consultas e regras dos módulos foram
retiradas, desordenadas e colocadas em um arquivo de texto separado.
Antes de ser repassada aos alunos, a rede de módulos foi dividida em duas partes. A
primeira parte consiste na criação de uma rede A1-A2, onde A2 é a parte de NEvt apenas com
gerações de notificações sobre os eventos sociais. A segunda parte consiste em construir a
rede completa através da complementação da rede A1-A2 da primeira parte. Esta
complementação consiste na construção da rede B1, B2 e B3 e expansão de A2 até fazer o
mesmo que NEvt. O exercício consistiu, então, em (1) completar cinco arquivos XML, um
para cada módulo (A1, A2, B1, B2 e B3), que foram fornecidos propositalmente incompletos
e; (2) estender o XML de A2 até ficar equivalente ao NEvt. O Quadro 14 apresenta quais
consultas e regras foram removidas de cada um dos módulos (para detalhes sobre elas veja
seção 4.3 e Apêndice E), qual o suposto nível de dificuldade e quais competências testadas em
cada etapa. Note que foram apenas movidas dos XML para o arquivo texto sem qualquer
modificação adicional. Quanto à configuração das portas, isto consiste em colocar o número
da porta corretamente conforme a Figura 32, que ilustra as duas partes em que a rede foi
dividida e também a sua organização. O grau de dificuldade foi classificado em três grupos:
maior, médio e menor. A1 e A2x são considerados mais complexos por ser o primeiro contato
com XML, consultas e regras, e por ser necessário expandir o XML e criar uma consulta,
respectivamente. As etapas A2 e B3 foram classificadas como média, pois exigem a
134
configuração das portas, e isto não é informado, sendo necessário que o aluno perceba a
ausência destas informações no XML inicial. De menor dificuldade são B1 e B2 que exigem
competências já testadas nas etapas anteriores.
Quadro 14. Consultas e regras removidas em cada módulo; competências testadas e grau de dificuldade para cada etapa.
Consultas
removidas
Módulo
A1
A2
Regras
removidas
Qcmdate
-
Competências testadas
Dificuldade
R3; R_EG3
Contato inicial com o XML;
Adição de consultas e regras.
Maior, por ser o
primeiro
Média
R2 de NEvt
Adição de regra;
Configuração da porta do endpoint
deste módulo.
Menor
Menor
B1
Qarrival1
-
Adição de consulta;
Configuração da porta do endpoint
deste módulo.
B2
Qrec
-
Adição de consulta.
Regra única
Adição de regra;
Média
Configuração da porta dos endpoints
consultados.
B3
-
A2x
(NEvt)
Qall de B3(criar);
R3 de NEvt
Qlow; Qhigh
Expansão do XML para adição de
consultas e regras;
Criação de uma consulta simples.
A2
NEvt
Porta 45000
Porta 45000
Maior, por ser
necessário expandir
o XML
B3
Porta 43000
A1
Porta 40000
A1
B2
B1
Porta 40000
Porta 41000
Porta 42000
Dates
Users
Dates
Users
Bus
Porta 50000
Porta 51000
Porta 50000
Porta 51000
Porta 52000
(a)
(b)
Figura 32. Divisão da rede de módulos do cenário 3 em duas partes (a) e (b).
Assim, o material entregue incluía o arquivo JAR do módulo de inferência, os cinco
arquivos XMLs incompletos, o arquivo texto com as consultas e regras removidas dos XMLs,
135
um JAR contendo a página Web de visualização e uma apresentação em PDF. Esta
apresentação foi construída com o intuito de ser uma pequena documentação que excluísse a
necessidade de treinamentos presenciais. A apresentação foi dividida em quatro partes. A
primeira parte faz um resumo das tecnologias RDF, OWL e SPARQL. A segunda, uma
pequena motivação para o cenário. A terceira explica o módulo de inferência. A quarta
explica o domínio do cenário e passa o exercício a ser feito de forma independente (com
pouco ou nenhum auxílio) e individual.
Antes de solicitar que os alunos fizessem estes exercícios, foi feito um teste piloto
presencial com dois alunos separadamente. Assim, a apresentação foi mostrada e solicitou-se
que eles completassem os XMLs. Suas dúvidas foram esclarecidas no mesmo momento da
execução do teste. Algum tempo depois foi solicitado que respondessem a um questionário.
Esse teste foi útil tanto para verificar se eles conseguiriam concluir a rede quanto para fazer
algumas melhorias na apresentação. O tempo dispendido com cada um dos dois alunos foi de
aproximadamente duas horas. Resultados serão apresentados na sessão seguinte.
O teste remoto e independente foi feito com 14 alunos, dos quais 12 cursavam a
disciplina de Web Semântica existente do Programa de Pós-Graduação em Informática
(PPGI) e os demais eram alunos também do PPGI, mas já em fase de pesquisa de tese, que
tivessem algum conhecimento prévio da tecnologia da Web Semântica. Para os alunos da
disciplina foi feita uma apresentação rápida em sala de aproximadamente 15 minutos para
explicar o que deveriam fazer no exercício, mas sem entrar em detalhes. Após uma semana
houve uma sessão de laboratório de aproximadamente duas horas para esclarecimento de
dúvidas, ou seja, não foi aula nem treinamento. Os alunos apresentavam algumas dificuldades
encontradas e algumas diretrizes que levassem à solução eram apresentadas de volta. A seção
seguinte apresentará os resultados.
5.2
Avaliações dos alunos
Uma vez que os alunos terminavam a construção da rede eles respondiam um
questionário para avaliar o experimento. A primeira parte do questionário consistiu em
solicitar que o aluno dissesse qual o nível de conhecimento que ele considerava ter em relação
à Programação, Web (HTTP e HTML), XML, Web Services, Grafos, URI e RDF, SQL,
SPARQL, Lógica. Possíveis respostas eram Nenhum (0), Baixo (1), Moderado (2) ou Alto
(3). A segunda parte consistiu-se em que dissessem como foi a compreensão das tecnologias,
136
do domínio da aplicação e do funcionamento do módulo e a facilidade de configuração e
execução do módulo. Possíveis respostas eram Não entendi (0), Difícil (1), Moderado (2) e
Fácil (3). A terceira parte consistiu em dizer quanto tempo, aproximadamente, foi gasto em
cada etapa (A1, A2, B1, B2, B3 e A2x) e as possíveis respostas eram Não consegui (0), mais
que 40 minutos (1), entre 25 e 40 minutos (2), 10 a 25 minutos (3), e menos que 10 minutos
4). A última parte era composta por questões abertas que perguntavam:
a que o aluno atribuía a demora na etapa que ele perdeu mais tempo;
se a documentação foi suficiente para entender o módulo e o domínio da aplicação;
se achavam que o módulo atendia o objetivo de permitir reuso de consultas,
ontologias e regras ao prover dados derivados, e quais foram as dificuldades e
pontos positivos e negativos observados.
As perguntas das três primeiras partes visavam obter dados quantitativos, contudo
devido ao pequeno tamanho da amostra (16 alunos), acredita-se que não sejam
estatisticamente relevantes. Portanto, apenas histogramas e medianas das respostas serão
apresentados e discutidos sob o ponto de vista quantitativo. Para outras análises por parte do
leitor estas respostas foram disponibilizadas no Apêndice F.
5.2.1 Alguns dados quantitativos
Considerando todos os 16 alunos, verifica-se que a maioria deles informou não possuir
um bom conhecimento de RDF e SPARQL (Figura 33a). Os itens serviços Web e Grafos
também tiveram baixo grau de conhecimento, porém não eram relevantes neste experimento.
Felizmente nenhum disse não ter entendido o experimento, contudo três alegaram achar as
tecnologias, o domínio e a configuração difíceis (Figura 33b). Ainda neste histograma, onze
disseram que compreender o funcionamento do módulo foi difícil e isto é um dado negativo
visto que é um ponto crucial para sua correta utilização. Isto foi relatado, inclusive, por um
dos alunos que fez o teste presencial. Por outro lado, 13 alegaram que a configuração do
módulo é fácil ou moderada e 14 tiveram a mesma opinião sobre a execução. Quanto ao
tempo gasto para completar o arquivo XML de configuração, apresentado na Figura 33c, a
maioria disse ter gasto menos de 25 minutos em cada uma das etapas A2, B1, B2 e B3. As
etapas A1 e A2x apresentaram resultados piores, conforme esperado, onde 4 e 5 relataram ter
gasto mais que 40 minutos. Adicionalmente, dois alunos não conseguiram concluir a etapa
A2x.
137
As Figuras 34, 35 e 36 detalham melhor o comportamento para cada tipo de teste
isoladamente. A primeira figura mostra que ambos os alunos do teste piloto presencial tinham
conhecimento ou moderado ou alto de programação, XML e lógica, mas um deles possui
baixo conhecimento de RDF e SPARQL (Figura 34a). Quanto à dificuldade no experimento,
um deles disse achar a compreensão do funcionamento difícil, e ambos acharam a
configuração moderada e a execução fácil a moderada. Em relação ao tempo, a etapa A1 foi a
mais complexa, contudo, ninguém demorou mais que 40 minutos (Figura 34c). Comparando
com os histogramas da Figura 35 (teste remoto com alunos em pesquisa de tese), observa-se
que há bastante semelhança em (a), contudo, neste caso os alunos disseram ter conhecimento
moderado ou alto em RDF e SPARQL. No histograma (b), ambos disseram que tanto
configuração quanto execução são fáceis e que a compreensão do funcionamento é fácil a
moderada. Os tempos (Figura 35c) também se apresentaram equilibrados sendo a primeira e a
última etapa as mais demoradas novamente. Na Figura 36 (teste com alunos da disciplina),
verifica-se que a maioria diz entender de programação, XML e lógica, mas pouco de RDF e
SPARQL. Dez dos 12 tiveram dificuldade em compreender o funcionamento, três em
configurar e dois em executar. Quanto aos tempos, os resultados foram consideram adequados
para as etapas intermediárias e razoáveis para a primeira etapa e última. Esta última, contudo,
não foi completada por dois alunos conforme já relatado.
Comparando os graus de dificuldade do Quadro 14 e os tempos dispendidos nas etapas
apresentados nos histogramas, pode-se verificar que realmente as etapas A1 e A2x apresentam
maior complexidade, e B2 menor complexidade. As demais etapas tiveram grau de
dificuldade bastante similares que podem ser considerados medianos, contudo, B3 foi um
pouco mais fácil que B1 e A2 um pouco mais difícil que B1. Resumindo, pode-se observar
que alunos com maior dificuldade nas tecnologias da Web Semântica apresentaram maior
dificuldade no experimento, o que permite concluir que realmente é necessário conhecê-las
para utilizar o módulo, mesmo que as consultas já estejam prontas e seja necessário apenas
entendê-las.
138
Respostas globais
12
10
8
(a)
Nível de
conhecimento nas
tecnologias
6
Nenhum
4
Baixo
2
Moderado
0
Alto
12
10
(b)
Dificuldade no
experimento
8
6
Não entendi
4
Difícil
2
Moderado
0
Fácil
9
8
7
(c)
Tempo de
configuração e
execução de cada
etapa
6
Não consegui
5
Mais que 40 min
4
25 a 40 min
3
10 a 25 min
2
Menos que 10 min
1
0
A1
A2
B1
B2
B3
A2x
Figura 33. Histogramas das respostas globais.
139
Alunos do teste piloto (teste presencial)
3
(a)
Nível de
conhecimento
nas tecnologias
2
Nenhum
1
Baixo
0
Moderato
Alto
3
(b)
2
Dificuldade no
experimento 1
Não entendi
Difícil
0
Moderado
Fácil
3
Não consegui
(c)
Tempo de
2
configuração e
execução de 1
cada etapa
0
Mais que 40 min
25 a 40 min
10 a 25 min
A1
A2
B1
B2
B3
A2x
Figura 34. Resultados do teste presencial com alunos.
Menos que 10 min
140
Alunos em pesquisa de tese (teste remoto)
3
(a)
Nível de
conhecimento
nas tecnologias
2
Nenhum
1
Baixo
0
Moderato
Alto
3
(b)
2
Dificuldade no
experimento 1
0
Não entendi
Difícil
Moderado
Fácil
3
Não consegui
(c)
2
Tempo de
configuração e
execução de 1
cada etapa
0
Mais que 40 min
25 a 40 min
10 a 25 min
A1
A2
B1
B2
B3
A2x
Figura 35. Teste remoto com alunos em pesquisa de tese.
Menos que 10 min
141
Alunos da disciplina (teste remoto com esclarecimentos)
(a)
Nível de
conhecimento
nas tecnologias
10
9
8
7
6
5
4
3
2
1
0
Nenhum
Baixo
Moderato
Alto
11
10
9
8
7
(b)
6
Dificuldade no
5
experimento
4
3
2
1
0
Não entendi
Difícil
Moderado
Fácil
7
6
(c)
5
Tempo de
4
configuração e
3
execução de
2
cada etapa
1
0
Não consegui
Mais que 40 min
25 a 40 min
10 a 25 min
Menos que 10 min
A1
A2
B1
B2
B3
A2x
Figura 36. Resultados do teste remoto com alunos da disciplina.
142
Medianas das respostas das três primeiras partes do questionário
(a)
Nível de
conhecimento
nas tecnologias
(0-3)
3.5
3.0
2.5
2.0
1.5
1.0
0.5
0.0
Global
Alunos da
disciplina
Teste piloto
Alunos em
pesquisa tese
3.5
3.0
(b)
Dificuldade no
experimento
(0-3)
Global
2.5
2.0
1.0
Alunos da
disciplina
0.5
Teste piloto
1.5
0.0
Alunos em
pesquisa tese
4.5
4.0
Global
3.5
(c)
Tempo de
configuração
e execução de
cada etapa
(0-4)
3.0
Alunos da
disciplina
2.5
2.0
Teste piloto
1.5
1.0
Alunos em
pesquisa tese
0.5
0.0
A1
A2
B1
B2
B3
A2x
Figura 37. Mediana das respostas das três primeiras partes do questionário conforme valores atribuídos a cada resposta
(quanto mais próximo do valor máximo melhor).
143
Os gráficos das medianas são apresentados na Figura 37. Para cálculo da mediana das
respostas foram utilizados os valores apresentados no primeiro parágrafo da seção 5.2 (página
135). No gráfico da Figura 37a verifica-se que os alunos da disciplina possuem conhecimento
das tecnologias da Web Semântica menor que os demais alunos, fato que parece explicar o
maior tempo gasto na configuração dos módulos (Figura 37c). Por outro lado, os alunos em
pesquisa de tese e do teste piloto, que tinham conhecimento maior das tecnologias,
apresentaram maior facilidade na execução do experimento. Novamente pode-se verificar que
a compreensão do funcionamento foi aquém do esperado o que pode ter comprometido os
demais itens avaliados (Figura 37b). O aspecto positivo visto nesta figura é a facilidade de
configuração ter apresentado medianas entre 2,0 (grupos de alunos do teste piloto e da
disciplina) e 3,0 (alunos em pesquisa de tese) que representam as respostas Moderado e Fácil
do questionário. A facilidade de execução foi até um pouco superior variando entre 2,0
(alunos da disciplina) e 3,0 (alunos em pesquisa de tese), mas com um dos valores sendo 2,5
(alunos do teste piloto). Novamente observa-se maior dificuldade nas etapas A1 e A2x.
5.2.2 Avaliações qualitativas
A parte qualitativa do questionário foi composta pelas três perguntas descritas no
início desta seção. Em relação à primeira delas, que pergunta a que o aluno atribuía a demora
na(s) etapa(s) que ele perdeu mais tempo, os alunos que tiveram maior demora na etapa A1
declararam como motivo principal o fato desta ser a primeira etapa prática e o entendimento
do domínio e/ou tecnologia ainda não estar claro (citado por 5 alunos), outros citaram não ter
lido os arquivos de ajuda, estar com a porta bloqueada no computador do aluno (que não
contribui para o resultado), e não ter percebido que as consultas estavam prontas. Aqueles que
demoraram mais na etapa A2x disseram que esta tinha maior nível de dificuldade (2 alunos),
se confundiram ao usar as regras fornecidas (2 alunos), teve falta de atenção ao definir as
portas (1 aluno), e não entendeu claramente o que deveria ser feito (2 alunos, sendo que um
disse que isto não estava claro na apresentação). Alguns destes alunos se sobrepõem por terem
demorado em ambas as etapas. Alunos que apresentaram demora em mais de duas etapas
relataram dificuldade em entender as regras (1 aluno, etapas A1, B1 e B3), demora em
perceber que cada etapa dependia das anteriores (1 aluno, A1, A2 e B1), e desconhecimento
das tecnologias que o obrigou a ler e reler o material (1 aluno, etapas B1, B2, B3 e A2x). Dois
alunos não conseguiram terminar a etapa A2x. Um deles não disse o porquê de não ter
conseguido e o outro disse não ter conseguido completar a tempo de entregar (para alunos da
disciplina foi necessário definir um tempo para entregar esta tarefa).
144
A segunda pergunta questionava se a documentação foi suficiente para entender o
módulo e o domínio da aplicação e foi feita a apenas 14 alunos (os dois do teste presencial
não responderam esta pergunta pois a documentação ainda estava em desenvolvimento). A
maioria das respostas foi positiva, contendo afirmações como muito boa (3 alunos), bem
completa (2 alunos) clara e concisa (3 alunos) e suficiente (4 alunos), contudo algumas destas
afirmações foi feita pelo mesmo aluno, totalizando 10 respostas claramente positivas. Uma
resposta já esperada e considerada neutra foi que houve necessidade de ler e reler, mas
conforme praticava foi ficando mais fácil de entender. Ressalvas apresentadas por estes 11
alunos foram que um leigo na tecnologia não entenderia bem (1 dos alunos em pesquisa de
tese), o módulo poderia ser melhor explicado (1 aluno), o domínio era muito complexo (1
aluno), o XML poderia ser melhor detalhado (1 aluno) e, poderia ter mais exemplos de regras
e não foi muito fácil perceber quais modelos eram exemplos e quais representavam as bases
RDF usadas no exercício (1 aluno). Acréscimos às respostas positivas foram que a
documentação explica o módulo e contextualiza o exercício (1 aluno), o material ensinou
bastante (1 aluno) e, os diagramas foram fundamentais para o entendimento (1 aluno). As
outras 3 respostas foram consideradas negativas. Um disse que leigos encontrariam
dificuldade e o objetivo de cada etapa não ficou muito claro além de o domínio ser complexo.
Outro disse que para quem não entende as tecnologias seria necessário um treinamento. O
último disse que o conteúdo sobre a disciplina estava claro, mas a explicação sobre o que
fazer nos exercícios não, sendo necessário ler diversas vezes e mesmo assim perguntar
pessoalmente.
Sobre as reclamações de que o que deveria ser feito não estava claro nos slides e que
não teria visto os arquivos de ajuda ou que as consultas estavam prontas, isto ocorreu apenas
com poucos alunos da disciplina, e provavelmente por não terem comparecido ou prestado
atenção à primeira apresentação onde foi informado o que deveria ser feito (completar os
XML com consultas e regras existentes em um arquivo texto fornecido com o material).
Realmente os slides não foram criados para explicar detalhes práticos do exercício, apenas
estrutura e funcionamento do módulo e o domínio da aplicação. A parte da apresentação que
passava o exercício apenas chamava atenção para a marcação de tempo e dizia para adicionar
consultas e/ou regras aos arquivos XML, discrimando-os no exercício de cada etapa.
Adicionalmente, os arquivos XML apresentavam comentários na forma “EXERCICIO A2:
PEGAR REGRA DO ARQUIVO” em letras maiúsculas logo acima do trecho que deveria ser
145
completado. Por isso, estas reclamações podem até ter prejudicado um pouco o resultado do
experimento, mas não para produzir falsos resultados positivos, mas sim o contrário.
A terceira pergunta era (1) se achavam que o módulo atendia o objetivo de permitir
reuso de consultas, ontologias e regras ao prover dados derivados, e (2) quais foram as
dificuldades e pontos positivos e negativos observados. Por haver um único campo de
resposta nem todos os alunos responderam ambos os itens. O primeiro item teve 15 respostas,
onde quatro afirmaram que sim, o objetivo foi atendido e os outros onze dissem acreditar que
sim. Dentre as dificuldades encontradas, citaram dificuldade inicial com: sintaxe (1 aluno),
definição das regras do JENA (1 aluno) e análise dos dados gerados (1 aluno). Outros
disseram que foi montar o XML devido à falta de conhecimento das tecnologias e não devido
à sintaxe em si (1 aluno), dúvidas, não informadas, na manipulação do XML (1 aluno),
entender o exercício por meio dos slides que não estavam claros, mas que após descobrir que
as consultas e regras estavam prontas foi fácil completar (1 aluno) e entender como os
endpoints se interligam (1 aluno). Novamente, estas observações se sobrepõem tendo sido
relatadas por 6 alunos. Um sétimo aluno relatou ter dificuldade em aprender a estrutura da
linguagem, identificar a estrutura de dados na aplicação e construir consultas e regras. O
primeiro parece referir-se ao XML, o segundo ao consumo dos dados pela aplicação e o
terceiro pode ser devido ao domínio e/ou baixo conhecimento das tecnologias. Dois alunos
relataram a queda do endpoint no último dia do prazo de entrega, que foi resolvido poucas
horas após percepção da ocorrência.
Os pontos negativos identificados foram dependência de conhecimento sobre a
tecnologia e domínio da aplicação (2 alunos), domínio sobre ferramenta requer mais tempo (1
aluno), que a curva de aprendizado é grande (1 aluno), ter de executar diversos programas no
exercício (1 aluno), mensagens de erro ao executar o módulo não eram claras mesmo com
erros de fácil resolução (1 aluno) e, ausência de uma interface gráfica para configurar o XML,
que aumentaria a utilidade do módulo (1 aluno). Um dos alunos detalhou sua opinião sobre a
necessidade de conhecimento das tecnologias: SPARQL (alto), RDF (alto), regras (alto),
grafos (médio), modelagem conceitual/ontologia (médio). Quanto aos pontos positivos,
diversas foram as respostas, umas relacionadas ao módulo e outras específicas do exercício.
Esta segunda foi que os cenários de uso propostos foram apropriados e ilustraram a
importância da abordagem e que o exercício de completar consultas e regras foi apropriado
para o aprendizado. Os pontos positivos do módulo relatados foram sua capacidade de
simplificar consultas para usuário final após configurado e executado; execução e
146
visualização simples e intuitivas; permissividade de reutilização de informações de forma
transparente para que várias aplicações consultem a mesma informação independente da
plataforma; facilidade de se entender, configurar o XML e alterar a configuração, e executar;
e configuração é bastante detalhada e flexível.
Um fato curioso ao comparar as repostas é que 11 dos 16 alunos, sendo 10 alunos da
disciplina disseram ter tido dificuldade de compreensão do funcionamento do módulo, mas
nenhuma das respostas discursivas abordou este tema. Elas se direcionaram para a
complexidade de se entender as tecnologias e o domínio da aplicação e, em menor
quantidade, algumas dificuldades em manipular o arquivo XML.
Em resumo, o módulo realmente parece proporcionar reuso de dados derivados e a
facilidade de configuração e execução foi considerada moderada a alta, contudo a necessidade
de conhecimento médio ou alto de XML, RDF, SPARQL e programação podem comprometer
estes aspectos positivos. E, apesar de XML e programção serem bastante difundidos no meio
de desenvolvedores, as tecnologias RDF e SPARQL ainda são um entrave para uma avaliação
mais efetiva do módulo, fato observado pela dificuldade em se conseguir pessoas que
pudessem testar o framework. Estas tecnologias semânticas não são fáceis de serem
entendidas quando se deseja atender objetivos mais complexos, ou seja, quando se requer
compreensão mais avançada sobre elas. O conhecimento do domínio é uma dificuldade que
existe seja qual for a tecnologia adotada. Talvez ela seja mais reforçada quando se utilizam
ontologias, regras e consultas SPARQL em vez de programação convencional e bancos de
dados relacionais. Por fim, o funcionamento não foi facilmente compreendido, sendo
necessário um aprimoramento da apresentação ou treinamento.
147
6
Considerações finais
Este capítulo apresenta uma retrospectiva do trabalho apresentado nos capítulos
anteriores como problema tratado, proposta, prova de conceito e experimentos com alunos.
Por fim, aborda as contribuições, problemas e limitações do framework e trabalho futuros.
6.1
Retrospectiva
Este trabalho pretendeu abordar, inicialmente, o problema da dificuldade se utilizar
informações oriundas de diversas bases de dados e fontes de contexto ao construir uma
aplicação ciente de contexto. Devido ao fato de existirem diversos formatos e variadas formas
de comunicação se torna difícil construir tais aplicações. Por isso, existe a necessidade de que
contextos sejam representados em um formato reutilizável e interoperável (PERTTUNEN et
al., 2009). Para tentar lidar com isto, foi proposta a arquitetura LOUD (Linked Open
Ubiquitous Data), uma arquitetura em três camadas (dados e sensoriamento, inferência e
aplicação) e descentralizada que utiliza padrões da Web Semântica para comunicação entre
seus componentes.
A primeira camada é responsável por obter, armazenar e fornecer dados de sensores
físicos, bases de dados e perfis do usuário. Os chamados módulos de sensoriamento seriam
capazes de obter dados brutos de sensores físicos, e os módulos de dados das demais fontes
(bases de dados e perfis do usuário). Estes módulos armazenam estes dados obtidos podendo
fazer algum pré-processamento. Por fim, fornecem estes dados através de SPARQL endpoints
na nuvem LOD. A segunda camada é a camada de inferência, que é composta por uma rede
de módulos de inferência responsáveis por consumir informações de outros módulos desta
mesma camada ou da camada de dados e sensoriamento e realizar inferência de contextos,
ações e notificações. Estes módulos de inferência identificam três etapas: carregamento,
processamento e publicação. A primeira obtém informações através de consultas SPARQL
feitas a um ou mais endpoints. A segunda permite, no estágio atual, realiza inferências usando
ontologias OWL e regras IF-THEN, para mapear conceitos de diferentes ontologias, descobrir
contexto de mais alto nível e gerar recomendações de notificações ou ações a serem
executadas por uma aplicação ou agente. A publicação é a disponibilização destes dados na
nuvem LOD através de um SPARQL endpoint criado pelo módulo. A camada de aplicação
148
contém as aplicações que interagem diretamente com o usuário final. Estas aplicações
consomem dados de um ou mais módulos de inferência por meio de seu(s) SPARQL
endpoint(s).
Estas camadas formam a estrutura inicial da arquitetura LOUD, mas devido à
complexidade não foi possível desenvolver todo o projeto nesta dissertação. Desta forma,
resolveu-se construir o Módulo de Inferência da camada de inferência, com o objetivo de
tratar o problema da inexistência de um ferramental configurável, capaz realizar inferências,
incluindo contexto, usando formatos de dados interoperáveis disponíveis na Web Semântica e
também de disponibilizar seus dados seguindo tais princípios.
O módulo de inferência possui quatro componentes: carregador de dados, base de
armazenamento intermediário, motor de inferência e SPARQL endpoint. O carregador de
dados é formado por uma ou mais threads de execução, uma para cada endpoint fonte, de
forma que cada thread envia consultas (DESCRIBE ou CONSTRUCT) sequencialmente a
seu endpoint, podendo existir variáveis cujos valores sejam provenientes de outras fontes
(substituições de variáveis). Os resultados obtidos das consultas de cada endpoint i são
armazenados em grafos GRC[i] separadamente, reunidos em um grafo GRC, processados pelo
motor de inferência (gerando GINF) até chegar ao grafo para publicação (GPUB) que é
disponibilizado atráves do endpoint do módulo. O motor de inferência é um raciocinador
baseado em regras (JENA) ou OWL-DL (Pellet), sendo necessário escolher um deles. A
atualização do endpoint pode ser feita por cópia ou compartilhamento do grafo usado pelo
raciocinador, ambas possuem prós e contras que foram discutidos na seção 3.3.1.4 (pág. 77).
Estes componentes são configuráveis através de um arquivo XML, de maneira que se pode
definir endpoints fonte, consultas e seus intervalos de execução, substituições de variáveis,
ontologias, regras, raciocinador e forma de atualização.
6.2
Estudo de viabilidade e experimentos realizados
Para mostrar a viabilidade de se construir aplicações cientes de contexto utilizando o
módulo foram idealizados e constrúidos três cenários. O primeiro cenário visava suprir uma
necessidade de informação muito comum do Corpo de Bombeiros do Estado do Rio de
Janeiro (CBMERJ) sobre disponibilidade de hidrantes de coluna próximos a um foco de
incêndio. Para isso, a base de recursos hídricos do Sistema de Informações Geográficas
Vigilância e Controle (ViconWeb) foi disponibilizada como um SPARQL endpoint, uma
149
ontologia OWL foi desenvolvida e um módulo que reunia estas informações com outras
provenientes do endpoint do projeto LinkedGeoData foi configurado. O segundo cenário foi
inspirado nas tragédias ocasionadas pelas chuvas de 2010 a 2012 no Rio de Janeiro que
resultou na instalação de sirenes por parte do prefeito. Assim, o objetivo do cenário era gerar
notificações sobre intensidade de chuva e probabilidade de escorregamento à população, com
base na precipitação existente na localização simulada de cada usuário. Como fonte de dados
foi criado um endpoint contendo medições pluviométricas das 33 estações do Sistema AlertaRio. Para cada suposto usuário eram geradas notificações usando regras do Alerta-Rio. O
terceiro cenário também envolveu geração de notificações para usuários, mas focando em
eventos sociais e chegadas de ônibus. Para prover os dados necessários foram construídos três
endpoints: simulação da movimentação de ônibus (restritos à área geográfica da cidade
universitária da UFRJ), rede social de usuários (alguns supostos alunos da UFRJ, seus
parentes e amigos) e, bases de datas comemorativas e feriados. Quatro ontologias e diversas
regras foram desenvolvidas e distribuídas em cinco módulos de inferência com atribuições
específicas. Como resultado, usuários eram notificados sobre a proximidade de aniversários,
feriados e chegadas de ônibus em paradas próximas à sua localização.
Como a facilidade de configuração é um ponto crucial para a difusão do uso, foi
realizado um experimento com alunos do Programa de Pós-Graduação em Informática (PPGI)
a fim de recolher avaliações positivas e negativas. O terceiro cenário foi escolhido para que os
alunos tentassem configurar a rede de módulos, contudo, como não seria possível que os
alunos construíssem todas as consultas e regras, decidiu-se por removê-las dos arquivos de
configuração e colocá-las em um arquivo de texto. Assim, as estrutura dos XMLs foi mantida
e os alunos deveriam entender o módulo e o domínio e, por fim, completar os arquivos XML.
Isto foi importante para mostrar e/ou confirmar diversos aspectos positivos e limitações que
serão discutidos nas próximas seções.
Apesar de este experimento ter mostrado que alunos com maior conhecimento em
programação tiveram maior facilidade, acredita-se que isto se deva ao raciocínio algoritmico
utilizado e não necessariamente ao conhecimento de linguagens de programação, visto que
nenhuma linguagem de programação é usada ao configurar o módulo, apenas linguagens de
marcação (XML), consulta (SPARQL) e representação de conhecimento (RDF e OWL).
150
6.3
Contribuições e aspectos positivos
A principal contribuição deste trabalho é permitir o processamento de informações
para aplicações cientes de contexto utilizando formatos e padrões abertos da Web Semântica.
Trazer tais tecnologias para estas aplicações é importante, pois a computação ciente de
contexto não está mais restrita a um ambiente fechado e a sensores locais. Usuários estão cada
vez mais conectados à Internet, e as aplicações, portanto, devem prover informações e
serviços condizentes com suas expectativas utilizando todos os benefícios da conectividade
global.
O framework foi concebido inicialmente para auxiliar a construção da parte inteligente
de aplicações cientes de contexto, ou seja, inferência de contexto e geração de recomendações
(notificações e/ou ações) usando as tecnologias da Web Semântica. Contudo, por usar estas
tecnologias, acabou se tornando também útil para a construção de aplicações genéricas,
agentes e mashups que necessitem de inferência com ontologias OWL e regras.
Outro aspecto positivo é a habilidade de ser fazer inferência modularizada e
distribuída na Web, ou seja, dividir o processamento de ontologias e regras em módulos
distintos que podem executar em máquinas distintas para posterior integração. Isto permite
reduzir o tempo total gasto tanto em processamentos que devem ser executados em série (que
possuem alguma relação de dependência) quanto daqueles que podem ser paralelizados
(dados sem relação direta). Isto pode ser visto na implementação dos cenários. No cenário 3,
por exemplo, o módulo NEvt que gerava notificações sobre eventos precisava consultar as
participações em eventos geradas por outros módulos (A1 e B3) que operavam paralelamente
devido ao fato de os seus dados não possuírem dependência entre si.
Apesar de esta ideia não ser inédita, a facilidade de configuração proporcionada pelo
framework permite que pessoas sem grandes conhecimentos de linguagens programação
possam configurar o módulo e disponibilizar seus dados na Web rapidamente. Isto se deve ao
fato de se utilizar um arquivo XML para configuração, que possui apenas os elementos
essenciais para serem configurados. Se não fosse o módulo, pessoas que quisessem produzir
tais dados para aplicações precisariam criar programas para realizar as consultas, carregar
ontologias e regras, processar os dados com um motor de inferência e depois fazer a inserção
de dados em uma base de triplas. O framework reduz a necessidade de programação, mas
obviamente não exclui a necessidade de conhecer os endpoints fonte, suas ontologias ou
vocabulários, nem de construir consultas, ontologias e regras, ou seja, não substitui as
151
necessidades de conhecimento do domínio, levantamento de requisitos e modelagem como
em qualquer desenvolvimento.
Aspectos positivos apresentados por alguns alunos foram (1) simplificação de
consultas para o consumidor final depois de configurado e executado, (2) execução e
visualização simples e intuitivas, (3) reutilização de informações por parte de aplicações
independente de suas plataformas, (4) facilidade de entendimento, configuração e alteração da
configuração e (5) configuração bastante detalhada e flexível. Outras vantagens que podem
ser comentadas são (6) possibilidade de se validar a base de dados gerada, ou seja, verificar a
consistência com base numa ontologia predefinida e, (7) independência de platarforma
(linguagem de programação e sistemas operacional), pois foi implementado em Java e utiliza
as tecnologias XML, RDF e SPARQL do W3C.
6.4
Problemas e limitações
Os problemas e limitações encontrados neste trabalho podem ser divididos naqueles
inerentes à tecnologia, ou seja, não diretamente relacionados ao framework e os inerentes ao
framework. Quanto ao primeiro, apesar da inúmera quantidade de bases publicadas seguindo
o padrão, ainda há uma carência de bases com informações úteis, confíaveis e atualizadas,
inclusive no âmbito nacional. Além disso, muitos endpoints aceitam apenas SPARQL 1.0,
linguagem limitada que dificulta a execução de consultas mais complexas. Adicionalmente, o
tempo de processamento ainda é um gargalo, pois aumenta rapidamente conforme a
quantidade de instâncias aumenta (BOCK, JURGEN et al., 2008) e os raciocinadores variam
significativamente quanto às funcionalidades, sendo necessária uma avaliação crítica dos
requisitos antes de escolher um para uma aplicação (DENTLER et al., 2011).
Outra observação importante é que ainda não foi estabelecida uma ferramenta
realmente fácil e intuitiva para edição de OWL e regras, visto que apesar de o software
Protégé ser útil e funcionar de forma satisfatória, ainda não é muito amigável. Não é difícil se
confundir com suas telas durante a edição. Isto poderia ser melhorado com a adição de uma
área de edição visual semelhante ao UML, mas no momento apenas a visualização pode ser
feita visualmente. Por este motivo, neste trabalho as ontologias necessárias foram
desenvolvidas em editores de texto convencionais usando o formato Turtle e com checagem
de consistência pela ferramenta Pellet. Contudo, para pessoas que não tenham amplo
152
conhecimento de Turtle e OWL é inevitável o uso do Protégé, proporcionando alguma
dificuldade na manipulação de ontologias, que se espera diminuir no curto ou médio prazo.
Por fim, a tecnologia ainda é pouco difundida ao público em geral, mesmo os mais
capacitados. Isto ficou evidenciado pelo fato de que diversos alunos de mestrado, já cursando
a disciplina, tiveram dificuldade em compreender as tecnologias durante o experimento.
Conhecimento de alguns princípios da lógica de descrição também é útil ao desenvolver
ontologias OWL-DL, ou as ontologias construídas podem não ser consistentes e gerar
resultados não satisfatórios ou errados, mas isso pode ser contornado com ferramentas de
checagem, como Pellet. O Protégé permite validação usando este e outros motores de
inferência.
No tocante a problemas e limitações do framework, alguns itens foram verificados. O
uso de base de armazenamento em memória pode limitar a capacidade de armazenamento,
mas a possibilidade de armazenar dados em disco deveria ser bem estudada, pois poderia
trazer problemas tanto pela menor velocidade de acesso quanto pela permissividade em
armazenar mais instâncias. Outra limitação do módulo é realizar apenas processamento de
ontologias OWL-DL e regras IF-THEN que, apesar de proporcionar formalidade lógica,
dificulta o processamento de dados incertos (BETTINI et al., 2010). Fusão básica de dados
pode ser obtida por meio de funções de agregação em consultas SPARQL, contudo isto é
muito limitado sendo necessário incorporar outros mecanismos como sugerido na seção 3.2 e
na próxima.
No atual estágio, apenas carregadores síncronos estão disponíveis e isto, apesar de
eficaz, pode reduzir a eficiência da atualização, pois não há garantias de que o atraso na
atualização é o mínimo possível e também aumenta o tráfego de informções (quando não há
atualização o carregador recebe infomação repetida). Resumidamente, é praticamente
impossível determinar o instante de tempo correto para obter uma informação, sem que a
fonte desta informação envie um evento ao receptor.
A distribuição dos módulos na rede precisa ser feita manualmente sem um mecanismo
que propricie maior facilidade em depurar o processo de configuração do módulo. Nesta
linha, um dos alunos que fez o experimento relatou que a utilidade do módulo seria
aumentada se houvesse uma interface gráfica para configurar o XML. Por fim, também houve
um relato sobre as mensagens de erro do módulo não serem claras, e realmente, não houve
preocupação em desenvolver esta linha de comunicação.
153
6.5
Trabalhos futuros
Dentre possíveis trabalhos futuros pode-se mencionar carregadores síncronos, inclusão
de outros raciocinadores e interface visual de configuração. As vantagens que podem ser
proporcionadas por carregadores assíncronos foram discutidas na seção anterior. O trabalho
de (PASSANT; MENDES, 2010) discute o método e apresenta uma ferramenta feita em PHP
que funciona como um proxy que recebe consultas, as registra e gera feeds RSS ou Atom que
são registrados em um hub e também enviados de volta ao cliente. Quando novas triplas são
inseridas via SPARQL Update, este proxy gera triggers que executam as consultas registradas
e atualizam o hub com novos feeds. Por fim, o hub envia os novos feeds aos clientes. A adição
desta funcionalidade seria de grande utilidade, porém possíveis impactos ainda precisam ser
levantados e estudados. Dentre os repositórios atuais, o Virtuoso já possui esta
funcionalidade32.
A inclusão de outros raciocinadores OWL-DL, até mesmo com reasoning incremental,
e a adição de mecanismos que permitam determinar o raciocinador mais apropriado para a
ontologia em questão também seria de bastante utilidade. Em (BOCK, JÜRGEN et al., 2012)
é apresentado um trabalho para seleçao de raciocinadores baseado em técnicas de aprendizado
de máquina como redes bayesianas e SVM (Support Vector Machine). Além disso, outras
formas de processamento para fusão de dados e/ou clusterizacao poderiam ser adotadas desde
os mais simples como scripts (programas Javascript ou Python, por exemplo) até outros mais
sofisticados como Hidden Markov Models (HMM), lógica probabilística ou fuzzy, com as
devidas adaptações para RDF (BETTINI et al., 2010). A implementação de módulos que
permitam tais técnicas é muito importante, tanto na camada de inferência quanto na camada
de sensoriamento, e um aperfeiçoamento deste tipo na arquitetura LOUD permitirá tirar
proveito do melhor que cada técnica pode oferecer (BETTINI et al., 2010).
Mecanismos automáticos que permitam distribuir inferência e armazenamento por
várias máquinas também seriam de grande utilidade, pois permitiriam que o processamento se
tornasse escalável na Web sem necessidade da configurção manual de vários módulos
independentemente, como ocorre atualmente. Trabalhos apresentados por Jacopo Urbani
(URBANI, J; OREN, E; et al., 2009; URBANI, JACOPO; KOTOULAS; et al., 2009)
apresentam uma abordagem para inferência RDFS e OWL usando o algoritmo MapReduce.
Para RDFS, a abordagem se mostrou bastante efetiva, eficiente e escalável, sendo capaz de
32
http://ods.openlinksw.com/wiki/ODS/VirtPubSubHub
154
processar um bilhão de triplas em menos de uma hora. Contudo, para inferência OWL, o autor
relata que os resultados foram lentos e frágeis, sendo necessário desativar algumas regras para
se concluir a execução. Um trabalho também usando MapReduce, mas voltado a SPARQL
distribuído, é apresentado em (KULKARNI, 2010) e apresentou bons resultados quanto à
escalabilidade de grandes volumes de dados, mas o tempo de resposta não foi aceitável pois
ainda é necessário investimentos em indexação distribuída.
A descrição dos serviços providos por um módulo permite que aplicações e agentes
sejam capazes de se adaptar a novos ambientes tirando proveito de serviços disponíveis na
localidade. A quantidade de funcionalidades que um serviço pode oferecer é imensa, como a
consulta de informações regionais, execução de algoritmos, localização de hardwares como
impressoras, serviços de fax, etc. (MIAN et al., 2009). Apesar da associação com a
localidade, é importante que tais descrições de serviços estejam disponíveis na Web, pois o
consumidor não necessariamente está na mesma rede local ou área do serviço buscado. Um
bom exemplo seria o caso de uma aplicação apresentar ao usuário um planejamento de ações
relacionadas a um evento futuro. Acredita-se, portanto, que agregar contribuições do campo
da descoberta de serviços seja uma funcionalidade útil, mas devem-se levar em consideração
possíveis necessidades de um consumidor distante do local do serviço.
Um ambiente de desenvolvimento visual para construção dos módulos permitiria que
novatos pudessem iniciar o desenvolvimento sem grande conhecimento inicial, pois este
ambiente auxiliaria no processo de configuração, testes e depuração, e consequente
aprendizado prático. A construção das ontologias, regras e consultas poderiam também ser
integradas neste ambiente. A efetividade deste ambiente poderia ser comparada com o
processo manual atual de configuração, teste e depuração, e também com o desenvolvimento
de aplicações cientes de contexto usando desenvolvimento por programação, para se verificar
pontos em que há ganhos reais, e pontos indiferentes ou negativos.
155
Referências
ABITEBOUL, S. ; BENJELLOUN, O. ; MILO, T. The Active XML project: an overview.
The VLDB Journal, New York, v. 17, n. 5, p. 1019-1040, 2007.
ALLEN, J. F. Towards a general theory of action and time. Artificial Intelligence,
Amsterdam, v. 23, n. 2, p. 123-154, Jul. 1984.
ALMEIDA, A. ; LÓPEZ-DE-IPIÑA, D. ; AGUILERA, U. et al. An Approach to dynamic
knowledge extension and semantic reasoning in highly-mutable environments. In:
CORCHADO, J. ; TAPIA, D. ; BRAVO, J. (Eds.). 3rd Symposium of Ubiquitous
Computing and Ambient Intelligence 2008. Berlin / Heidelberg: Springer, 2009. p. 265273. (Advances in Intelligent and Soft Computing, v. 51).
ANTONIOU, G. ; HARMELEN, F. VAN. Web ontology language: OWL. In: STAAB, S. ;
RUDI STUDER, D. (Eds.). Handbook on ontologies. Berlin / Heidelberg, Springer, 2009. p.
91-110.
ARAUJO, R. B. Computação ubíqua : princípios, tecnologias e desafios. In: SIMPÓSIO
BRASILEIRO DE REDES DE COMPUTADORES, 21., 2003., Natal. Mini Curso … Natal:
UFRN/SBC, 2003, p. 45-115.
AZEVEDO, G. F. Análise da relação chuva-escorregamento em regiões tropicais
montanhosas urbanas, caso de estudo. 2011. 120 f. Dissertação (Mestrado em Geotecnia) –
Universidade de Brasília, Brásilia, 2011.
BAADER, F. et al. Description logics. In: VAN HARMELEN, F. ; LIFSCHITZ, V. ;
PORTER, BRUCE (Eds.). Handbook of knowledge representation. 1. ed. [S.l.]: Elsevier,
2008. v. 1. p. 135-179. (Foundations of Artificial Intelligence)
BAADER, F. ; NUTT, W. Basic description logics. In: BAADER, F. ; CALVANESE, D. et
al. (Eds.). The description logic handbook: theory, implementation and applications.
Cambridge: Cambridge University Press, 2003. p. 43-95.
BALDAUF, M. ; DUSTDAR, S. ; ROSENBERG, F. A survey on context-aware systems.
International Journal of Ad Hoc and Ubiquitous Computing, Geneva, v. 2, n. 4, p. 263–
277, 2007.
BATSAKIS, S. ; PETRAKIS, E. G. M. SOWL: spatio-temporal representation, reasoning and
querying over the semantic web. In: INTERNATIONAL CONFERENCE ON SEMANTIC
SYSTEMS, 6., 2010, Graz, Austria. Proceedings … New York: ACM, 2010. . Disponível
em: <http://doi.acm.org/10.1145/1839707.1839726> Acesso em: 2010
BECKER, C. ; NICKLAS, D. Where do spatial context-models end and where do ontologies
start? a proposal of a combined approach. In: INTERNATIONAL WORKSHOP ON
ADVANCED CONTEXT MODELLING, REASONING AND MANAGEMENT, 1., 2004.
Nottingham, Eng. Proceedings … New York: ACM, 2004.
156
BERNERS-LEE, T. ; HENDLER, J. ; LASSILA, O. The semantic web. Scientific American,
New York, v. 284, n. 5, p. 34–43, 2001.
BETTINI, C. et al. A survey of context modelling and reasoning techniques. Pervasive and
Mobile Computing, New York, v. 6, n. 2, p. 161-180, Apr. 2010.
BIEGEL, G. ; CAHILL, V. A framework for developing mobile, context-aware applications.
In: IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS, 2., 2004. Orlando. Proceedings ... Los Alamitos: IEEE, 2004.
Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1276875>.
Acesso em: 31 jul. 2011.
BIZER, C. Linked data - the story so far. International Journal on Semantic Web and
Information Systems, Hershey, PA, v. 4, n. 2, p. 1-22, 2009.
BOCK, J. et al. Benchmarking OWL reasoners. In: INTERNATIONAL WORKSHOP ON
ADVANCING REASONING ON THE WEB: Scalability and Commonsense, 2008. Tenerife.
Proceedings … [S.l.]: CEUR, 2008
BOCK, J. ; LÖSCH, U. ; WANG, H. Automatic reasoner selection using machine learning.
In: INTERNATIONAL CONFERENCE ON WEB INTELLIGENCE, MINING AND
SEMANTICS, 2., 2012, Craiova, Romania. Proceedings … New York: ACM. 2012.
Disponível em: <http://doi.acm.org/10.1145/2254129.2254159>.Acesso em junl. 2012
BRATMAN, M. E. Intention, plans, and practical reason. Stanford: Center for the Study of
Language and Information, 1999. (David Hume Series)
BRØNSTED, J. ; HANSEN, K. M. ; INGSTRUP, M. Service composition issues in pervasive
computing. IEEE Pervasive Computing, New York, v. 9, n. 1, p. 62-70, Jan./Mar. 2010.
CHEN, H. An intelligent broker architecture for pervasive context-aware systems.
2004.Tese (Doutorado) – University of Maryland, Baltmore County, Baltimore County, 2004.
CHEN, H. ; FININ, T. ; JOSHI, A. semantic web in the context broker architecture. In: IEEE
ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS,
2., 2004. Orlando. Proceedings ... Los Alamitos: IEEE, 2004. p. 277-286.
________. An ontology for context-aware pervasive computing environments. The
Knowledge Engineering Review, Cambridge, Eng., v. 18, n. 3, p. 197-207, Sept. 2003.
CHEN, H. et al. SOUPA: standard ontology for ubiquitous and pervasive applications. In:
MOBIQUITOUS 2004 - ANNUAL INTERNATIONAL CONFERENCE ON MOBILE AND
UBIQUITOUS SYSTEMS: NETWORKING AND SERVICES, 1., 2004, Boston.
Proceedings … New Yok: ACM, 2004. p. 258-267.
CLARK, K. G. ; FEIGENBAUM, L. ; TORRES, E. SPARQL Protocol for RDF. Disponível
em: <http://www.w3.org/TR/rdf-sparql-protocol/>. Acesso em: 21 out. 2012.
COMPTON, M. et al. A Survey of the semantic specification of sensors. networks, In:
INTERNATIONAL WORKSHOP ON SEMANTIC SENSOR NETWORKS, 2., 2009,
Washington, DC. Proceedings … [S. l.]: CEUR, 2009. v. 522.
157
CORDEIRO, K. F. ; FARIA, F. F. ; PEREIRA, B. O. et al. An approach for managing and
semantically enriching the publication of linked open governmental data. In: WCGE 2011 WORKSHOP DE COMPUTAÇÃO APLICADA EM GOVERNO ELETRÔNICO, 3., 2011, .
Florianópolis. Anais... Porto Alegre: SBC, 2011. Disponível em:
<http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:An+approach+for+manag
ing+and+semantically+enriching+the+publication+of+Linked+Open+Governmental+Data#0
>. Acesso em: 20 nov. 2011.
DECKER, B. L. World geodetic system 1984. Fourth INTERNATIONAL GEODETIC
SYMPOSIUM ON SATELLITE POSITIONING, 4., 1986 Austin, TX. Proceedings …
Austin, TX: Defense Mapping Agency, 1986.
DELLA VALLE, E. ; QASIM, M. H. ; CELINO, I. Towards treating GIS as virtual RDF
graphs. 1st In: WebMGS 2010 - INTERNATIONAL WORKSHOP ON PERVASIVE WEB
MAPPING GEOPROCESSING AND SERVICES, 1., 2009, Como, Italy. Proceedings …
Como, Italy: ISPRS, 2009. Disponível em: <http://www.isprs.org/proceedings/XXXVIII/4W13/ID_36.pdf>. Acesso em: nov.2011.
DENTLER, K. et al. Comparison of reasoners for large ontologies in the OWL 2 EL profile.
Semantic Web – Interoperability, UsabilityApplicability an IOS Press Journal, [S. l.], v.
2, n. 2, p. 71-87, 2011.
DEY, A. K. ; ABOWD, G. D. Towards a better understanding of context and contextawareness. In: GELLERSEN, H-W (Ed.). Handheld and Ubiquitous Computing, First
International Symposium, HUC'99, Karlsruhe, Germany, 1999. Berlin: Springer, 1999. p.
304-307. (Lecture Notes in Computer Science, V. 1707).
DEY, A. et al. ICAP Interactive prototyping of context-aware applications. In: FISHKIN, K.
P. et al.(Eds). Pervasive Computing, 4th International Conference PERVASIVE, Dublin,
Ireland, 2006. Berlin: Springer, 2006. p. 254-271. (Lecture Notes in Computer Science, v.
3968).
DU, W. ; WANG, L. Context-aware application programming for mobile devices. In:
C3S2E'08 - C3S2E CANADIAN CONFERENCE ON COMPUTER SCIENCE &
SOFTWARE, 2008, Montreal QC, Proceedings … New York, ACM, 2008. p. 215-217.
EITER, T. et al. A. Rules and ontologies for the semantic web. In: BAROGLIO, C. et al.
(Eds.). Reasoning Web. 4 th International Summer School 2008. Venice ,Italy, 2008. Berlin:
Springer, 2008. p. 1-53. (Lecture Notes in Computer Science, v. 5224).
FAHY, P. ; CLARKE, S. CASS – a middleware for mobile cotext-aware applications. In:
MobiSys - WORKSHOP ON CONTEXT AWARENESS MOBISYS, 2., 2004, Boston.
Proceedings … New York: ACM, 2004. Disponível em:
<http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:CASS++Middleware+for+Mobile+Context-Aware+Applications#0>. Acesso em: 22 jan. 2011.
FORGY, C. L. Rete: A fast algorithm for the many pattern/many object pattern match
problem. Artificial Intelligence, Amsterdam, v. 19, n. 1, p. 17-37, 1982.
GESSLER, D. D. et al. A Simple semantic web architecture and protocol for semantic web
services. BMC Bioinformatics, London, v. 10, n. 1, p. 309, Sept. 2009.
158
GOLBREICH, C. ; WALLACE, E. K. OWL 2 web ontology language: new features and
rationale. Disponível em: <http://www.w3.org/TR/owl-new-features/>. Acesso em: 20 out.
2012.
GONG, S. et al. Design and Implementation of a low-power ZigBee wireless temperature
humidity sensor network. In: LI, D. ; LIU, Y.; CHEN, Y. (Eds.). Computer and computing
technologies in agriculture IV. 4Th IFIC TC Conference, CCTA 2010, Nanchang, China,
2010. Selected Papers, part IV. Berlin: Springer, 2011. p. 616-622. (IFIP Advances in
Information and Communications Technology, v. 347).
GROSOF, B. N. et al. Description logic programs: combining logic programs with description
logic. In: WWW'03 - Proceedings of the 12th INTERNATIONAL CONFERENCE ON
WORLD WIDE WEB, 12., 2003. Budapest. Proceedings … New York: ACM, 2003. p. 4857. Disponível em: <http://doi.acm.org/10.1145/775152.775160>. Aceso em jan. 2011.
GU, T. ; PUNG, H. ; ZHANG, D. A service-oriented middleware for building context-aware
services. Journal of Network and Computer Applications, London, v. 28, n. 1, p. 1-18, Jan
2005.
GUIZZARDI, G. ; WAGNER, G. Using the Unified Foundational Ontology (UFO) as a
Foundation for General Conceptual Modeling Languages. In: POLI, R. ; HEALY, M. ;
KAMEAS, A. (Eds.). Theory and applications of ontology: computer applications.
Dordrecht: Springer, 2010. p. 175-196.
GUO, B.; ZHANG, D. ; IMAI, M. Toward a cooperative programming framework for
context-aware applications. Personal and Ubiquitous Computing, London, v. 15, n. 3, p.
221-233, Mar. 2011.
HAASE, P. ; MATHÄS, T. ; ZILLER, M. An evaluation of approaches to federated query
processing over linked data. INTERNATIONAL CONFERENCE ON SEMANTIC
SYSTEMS, 6., 2010, Graz, Austria. Proceedings ... New York: ACM. 2010. Disponível em:
<http://doi.acm.org/10.1145/1839707.1839713>. Acesso em: jan. 2011.
HAAV, H.-M. et al. Ontology-based retrieval of spatially related objects for location based
services. In: MEERSMAN, R. ; DILLON, T. ; HERRERO, P. (Eds.). On the move to
meaningful internet systems: OTM 2009. Berlin: Springer, 2009. p. 1010-1024. (Lecture
Notes in Computer Science, v. 5871).
HALPIN, T. A. Information modeling and relational databases. San Francisco: Morgan
Kaufmarm, 2001.
HENRICKSEN, K. A framework for context-aware pervasive computing applications.
2003. PhD.Tesis -- University of Queensland, Brisbane, Australia, 2003.
HENRICKSEN, K. ; LIVINGSTONE, S. ; INDULSKA, J. Towards a hybrid approach to
context modelling, reasoning and interoperation. In: INTERNATIONAL WORKSHOP ON
ADVANCED CONTEXT MODELLING, REASONING AND MANAGEMENT, 1., 2004.
Nottingham, Eng. Proceedings … New York: ACM, 2004. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.70.2735&amp;rep=rep1&amp;typ
e=pdf>. Acesso em: 21 ago. 2011.
159
HENRICKSEN, K ; INDULSKA, J. Modelling and using imperfect context information. In:
IEEE ANNUAL CONFERENCE ON PERVASIVE COMPUTING AND
COMMUNICATIONS WORKSHOPS, 2., 2004, Orlando. Proceedings … Los Alamitos:
IEEE, 2004
HENRICKSEN, K ; INDULSKA, J. Developing context-aware pervasive computing
applications: models and approach. Pervasive and Mobile Computing, New York, v. 2, n. 1,
p. 37-64, 2006.
HERVÁS, R. ; BRAVO, J. COIVA: context-aware and ontology-powered information
visualization architecture. Software: Practice and Experience, London, v. 41, n. 4, p. 403426, Apr. 2011.
HIGHTOWER, J. ; BORRIELLO, G. Location systems for ubiquitous computing.
Computer, Long Beach, v. 34, n. 8, p. 57-66, Aug. 2001.
HOFER, T. ; SCHWINGER, W. ; PICHLER, M. et al. Context-awareness on mobile devices
- the hydrogen approach. In: HICSS'03 – ANNUAL HAWAII INTERNATIONAL
CONFERENCE ON SYSTEM SCIENCES, 36., 2003, Big Island. Proceedings … .
Washington, DC: IEEE Computer Society. 2003. Track 9, v. 9. p. 292.1. Disponível em:
<http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2003.1174831>. Acesso em:
2011.
HORROCKS, I. ; KUTZ, O. ; SATTLER, U. The even more irresistible SROIQ. In: KR-2006
- INTERNATIONAL CONFERENCE ON PRINCIPLES OF KNOWLEDGE
REPRESENTATION AND REASONING, 10., 2006, Lake District of the UK. Proceedings
… Palo Alto, CA: AAAI Press, 2006.
HORROCKS, I ; SATTLER, U. Ontology reasoning in the SHOQ (D) description logic. In:
IJCAI 2001 - INTERNATIONAL JOINT CONFERENCE ON ARTIFICIAL
INTELLIGENCE, 17., 2001, Seattle. Proceedings … San Francisco: Morgan Kaufmann,
2001.
HORROCKS, I. ; PATEL-SCHNEIDER, P. F. A proposal for an owl rules language. In:
INTERNATIONAL CONFERENCE ON WORLD WIDE WEB. 13., 2004, New Yok.
Proceedings … Anais... New York: ACM, 2004. Disponível em:
<http://doi.acm.org/10.1145/988672.988771>. Acesso em: jan. 2011.
HORROCKS, I. ; PATEL-SCHNEIDER, P. F. ; HARMELEN, F. V. From SHIQ and RDF to
OWL: the making of a web ontology language. Web Semantics: Science, Services and
Agents on the World Wide Web, [S. l.], v. 1, n. 1, p. 7-26, 2003.
HU, D. H. ; DONG, F. ; WANG, C.-L. A Semantic context management framework on
mobile device.In: ICESS'09 - INTERNATIONAL CONFERENCE ON EMBEDDED
SOFTWARE AND SYSTEMS, 6., 2009, Hangzhou, China. Proceedings... Los Alamitos:
IEEE, 2009. p. 331-338, 2009.
INDULSKA, J. ; SUTTON, P. Location management in pervasive systems. In: Proceedings
of AUSTRALASIAN INFORMATION SECURITY WORKSHOP CONFERENCE ON
ACSW FRONTIERS, 2003, Adelaide. Proceedings … Darlinghurst: Australian Computer
Science, 2003. p. 143-141. Disponível em:
<http://dl.acm.org/citation.cfm?id=827987.828003>. Acesso em: 2 jan. 2012.
160
JAIN, P. et al. Linked data is merely more data. In: AAAI SPRINGER SYMPOSIUM:
LINKED DATA MEETS ARTIFICIAL, 2010, Stanford. Proceedings … Palo Alto, CA:
AAAI Press, 2010. p. 82-86.
JIANG, C.; STEENKISTE, P. A Hybrid Location Model with a Computable Location
Identifier for Ubiquitous Computing. In: BORRIELLO, GAETANO; HOLMQUIST, L.
(Eds.). UbiComp 2002: Ubiquitous Computing. [S.l.]: Springer Berlin / Heidelberg, 2002.
v. 2498p. 307-313.
KOLOVSKI, V. ; PARSIA, B. ; SIRIN, E. Extending the SHOIQ (D) tableaux with DL-safe
rules: first r esults. In: DL 2006 - INTERNATIONAL WORKSHOP ON DESCRIPTION
LOGICS , 2006, Lake District of the UK. Proceedings … Lake District of the UK: CEUR,
2006. (CEUR Workshop Proceedings, v. 189).
KORPIPAA, P. et al. Managing context information in mobile devices. IEEE Pervasive
Computing, New York, v. 2, n. 3, p. 42-51, Jul 2003.
KOUTSOMITROPOULOS, D. et al. Developing distributed reasoning-based applications for
the semantic web. In: IEEE INTERNATIONAL CONFERENCE ON ADVANCED
INFORMATION NETWORKING AND APPLICATIONS WORKSHOPS, 24., 2010, Perth,
Australian. Proceedings … Los Alamitos: IEEE, 2010. p. 593-598.
KRISNADHI, A. ; MAIER, F. ; HITZLER, P. OWL and rules. reasoning web. semantic
technologies for the web of data. In: POLLERSES, A. et al. (Eds.). Reasoning web. Semantic
technologies for the web data. 7Th International Summer School 2011. Galway,
Ireland.Tutorial Lectures, Heidelberg: Springer, 2011. p. 382-415, 2011.
KULKARNI, P. Distributed SPARQL query engine using MapReduce. 2010. Thesis
(Master of Science Computer Science). School of Informatics University of Edinburgh,
Edinburgh. 2010.
LANGEGGER, A. Virtual data integration on the web: novel methods for accessing
heterogeneous and distributed data with rich semantics. In: INTERNATIONAL
CONFERENCE ON INFORMATION INTEGRATION AND WEB-BASED
APPLICATIONS & SERVICES, 10., 2008. Linz, Austria. Proceedings … New York: ACM,
2008. Disponível em: <http://doi.acm.org/10.1145/1497308.1497410>. , 2008
LANGEGGER, A. ; WÖS, W. ; BLÖCHL, M. A Semantic web middleware for virtual data
integration on the web. In: BECHHOFER, S. et al. (Eds.) The semantic web research and
applications 5th European semantic web conference Tenerife. 2008. Berlin: Springer, 2008. p.
493-507. (Lecture Notes in Computer Science, v. 5021).
LE-PHUOC, D. ; QUOC, H. ; PARREIRA, J. The linked sensor middleware — Connecting
the real world and the Semantic Web. In: ISWC 2011 – INTERNATIONAL SEMANTIC
WEB CONFERENCE, 2011, Bonn. Proceedings … Berlin: Elsevier, 2011.
LEE, D. ; MEIER, R. A hybrid approach to context modelling in large-scale pervasive
computing environments. In: INTERNATIONAL ICST CONFERENCE ON
COMMUNICATION SYSTEM SOFTWARE AND MIDDLEWARE, 4., 2009, Dublin.
Proceedings ... Anais... New York, ACM, 2009. Disponível em:
<http://doi.acm.org/10.1145/1621890.1621909>. Acesso em: 2011.
161
LENAT, D. B. CYC: a large-scale investment in knowledge infrastructure. Communications
of the. ACM, v. 38, n. 11, p. 33-38, Nov. 1995.
LEONHARDI, A. et al. Virtual information towers-a metaphor for intuitive, location-aware
information access in a mobile environment. Wearable Computers. In: INTERNATIONAL
SYMPOSIUM ON. WEARABLE COMPUTERS, 3., 1999, San Francisco, CA. Digest of
Papers ... Los Alamitos: IEEE, 1999
LIANG, S. et al. OpenRuleBench : an analysis of the performance of rule engines. In:
WWW'09 - 2009. INTERNATIONAL CONFERENCE ON WORLD WIDE WEB,18., 2009,
Madrid. Proceedings … New York: ACM, 2009. p. 601-610.
LU, J. ; WANG, C. ; HWANG, R. Open framework for distributed context management in
ubiquitous environments. International Journal of Ad Hoc and Ubiquitous Computing,
Geneve, v. 9, n. 4, p. 199-210, 2012.
LYYTTINEN, K. ; YOO, Y. Issues and challenges in ubiquitous computing (special section).
Communication of the ACM, New York, v. 45, n. 12, p. 63–65, 67-96, Dec. 2002.
MATTILA, J. ; VÄÄTÄNEN, A. UbiPlay: an interactive playground and visual programming
tools for children. In: INTERNATIONAL CONFERENCE ON INTERACTION DESIGN
AND CHILDREN, 5., 2006, Tampere. Proceedings … New York, ACM, 2006
MCGUINNESS, D. L. ; HARMELEN, F.V. OWL web ontology language overview.
Disponível em: <http://www.w3.org/TR/owl-features/>. Acesso em: 20 out. 2012.
MIAN, A. N. ; BALDONI, R. ; BERALDI, R. A Survey of service discovery protocols in
multihop mobile ad Hoc networks. IEEE Pervasive Computing, New York, v. 8, n. 1, p. 6674, 2009.
MONTEMAYOR, J. et al. Tools for children to create physical interactive storyrooms. CIE
Computers in Entertainment, New York, v. 2, n. 1, p. 12, 2004.
MOTIK, B. et al. OWL 2 web ontology language: direct semantics. 2012. (W3C
Recommendation). Disponível em: <http://www.w3.org/TR/owl-direct-semantics/>. Acesso
em: 20 out. 2012.
MOTIK, B. et al. Query answering for OWL-DL with rules. Web Semantics: Science,
Services and Agents on the World Wide Web, [S. l.], v. 3, n. 1, p. 41-60, 2005.
NARDI, D. ; BRACHMAN, R. J. An introduction to description logics. In: BAADER, F. et
al. (Eds.). The description logic handbook: theory, implementation and applications.
Cambridge: Cambridge University Press, 2003. p. 1-40.
NAUDET, Y. Reconciling context , observations and sensors in ontologies for pervasive
computing. In: SMAP'11 – INTERNATIONAL WORKSHOP ON SEMANTIC MEDIA
ADAPTATION AND PERSONALIZATION, 6., 2011, Vigo, Spain. Proceedings...
Washington, DC: IEEE, 2011.
NEUHAUS, H. ; COMPTON, M. The semantic sensor network ontology : a generic
language to describe sensor assets. AGILE 2009 – PRE-CONFERENCEWORKSHOP
CHALLENGES IN GEOSPATIAL DATA HARMONISATION, 2009. Havover.
Proceedings … Hanover: ESDI, 2009.
162
OMITOLA, T. et al. Integrating public datasets using linked data: challenges and design
principles. In: FUTURE INTERNET ASSEMBLY, Ghent, Belgium Proceedings … Ghent,
Belgium: European Future Internet Portal, 2010. Disponível em:
<http://eprints.soton.ac.uk/271955/>.Acesso em: 2012.
PAN, F. ; HOBBS, J. R. Time in OWL-S. 2003. Disponível em:
citeseerx.ist.psu.edu/.../download... Acesso em: 2012.
PASSANT, A. ; MENDES, P. N. sparqlPuSH: proactive notification of data updates in RDF
stores using PubSubHubbub. In: SCRIPTING FOR THE SEMANTIC WEB WORKSHOP
SFSW2010 AT ESWC2010, 6., 2010, Crete Greece. Proceedings … [S. l.]: CEUR, 2010.
Disponível em:
<http://www.semanticscripting.org/SFSW2010/papers/sfsw2010_submission_6.pdf>.Acesso
em: 2012.
PATNI, H. ; HENSON, C. ; SHETH, A. Linked sensor data. In: 2010 INTERNATIONAL
SYMPOSIUM ON COLLABORATIVE TECHNOLOGIES AND SYSTEMS, 2010,
Chicago. Proceedings … Los Alamitos: IEEE. 2010. p. 362-370. Disponível em:
<http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5478492>. Acesso em: 22 mar.
2012.
PERTTUNEN, M. ; RIEKKI, J. ; LASSILA, O. Context representation and reasoning in
pervasive computing: a review. International Journal of Multimedia and Ubiquitous
Engineering, [S. l.], v. 4, n. 4, p. 1-28, 2009.
POSLAD, S. Ubiquitous computing: smart devices, environments and interactions.
Chichester: John Wiley and Sons, 2009. 502p.
RANDELL, D. A. ; CUI, Z. ; COHN, A. G. A spatial logic based on regions and connection.
In: INTERNATIONAL CONFERENCE ON KNOWLEDGE REPRESENTATION AND
REASONING, 3;, 1992. Proceedings … San Francisco: Morgan Kaufmann, 1992.
RAO, A. S. ; GEORGEFF, M. P. Modeling rational agents within a BDI architecture. In:
INTERNATIONAL CONFERENCE ON PRINCIPLES OF KNOWLEDGE
REPRESENTATION AND REASONING, 2., 1991, [S. l]. Proceedings … San Mateo:
Morgan Kaufmann Publishers, 1991. Disponível em:
<http://jmvidal.cse.sc.edu/library/rao91a.pdf>.Acesso em: 2012.
RIBONI, D. ; BETTINI, C. COSAR: hybrid reasoning for context-aware activity recognition.
Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 271-289, 2011a.
________. OWL 2 modeling and reasoning with complex human activities. Pervasive and
Mobile Computing, New York, v. 7, n. 3, p. 379-395, 1 jun 2011b.
RICCI, F. Mobile recommender systems. Information Technology & Tourism, Putnam
Valley, NY, v. 12, n. 3, p. 205-231, 1 Apr. 2011.
ROUSSAKI, I. Et al. Hybrid context modeling: a location-based scheme using ontologies. In:
PerCom 2006 Workshops – ANNUAL IEEE INTERNATIONAL CONFERENCE ON
PERVASIVE COMPUTING AND COMMUNICATIONS WORKSHOPS, 4., Pisa.
Proceedings … Los Alamitos: IEEE, 2006.
RUSSELL, S. ; NORVIG, P. Artificial intelligence: a modern approach. Upper Saddler
River: Prentice Hall, 1995. 932 p.
163
RYAN, N. S. ; PASCOE, J. ; MORSE, D. R. Enhanced reality fieldwork: the context-aware
archaeological assistant. In: DINGWALL, l. et al. (Eds.). Archaeology in the Age of the
internet. CAAA97 - Computer applications and quantitative methods in archaeology. Oxford:
Archaeopress, 1999. (BAR International Series, 750.). Disponível em:
<http://www.cs.kent.ac.uk/pubs/1998/616> Acesso em: 2012.
SCHILIT, B. ; ADAMS, N. ; WANT, R. Context-aware computing applications. In:
WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS, 1., 1994.
Santa Cruz, CA. Proceedings … Los Alamitos: IEEE, 1994. p. 85-90.
SCHULZE, C. J. Plano nacional sobre governo aberto. Disponível em:
<http://jus.com.br/revista/texto/20268>. Acesso em: 10 abr. 2012.
SEQUEDA, J. F. ; CORCHO, Ó. Linked stream data: a position paper. . Madri: Facultad
de Informática – UPM, 2009. Disponível em:
<http://oa.upm.es/5442/1/INVE_MEM_2009_64353.pdf>. Acesso em: 21 mar. 2012.
SILVA, M. A. Aplicação de lógica nebulosa para previsão do risco de escorregamentos
de taludes em solo residual. 2008. 150 f. Dissertação (Mestrado em Engenharia Civil) –
Programa de Pós-Graduação em Engenharia Civil, Universidade do Estado do Rio de Janeiro
Rio de Janeiro, 2008.
SINGH, S.; KARWAYUN, R. A Comparative study of inference engines. In: ITNG - 2010
International Conference on Information Technology: New Generations, 7., 2010, Las Vegas.
Proceedings … Los Alamitos: IEEE, 2010. p. 53-57.
SIRIN, E. Pellet : a practical OWL-DL reasoner. World Wide Web Internet And Web
Information Systems, [S. l.], v. 5, n.2, p. 51-53, Jun. 2007.
STEVENSON, G. et al. Ontonym: a collection of upper ontologies for developing pervasive
systems. In: CIAO'09 – WORKSHOP ON CONTEXT, INFORMATION AND
ONTOLOGIES, 1., 2009, Heraklion Greece. Proceedings … New York: ACM, 2009. Article
n. 9.
STRANG, T. ; LINNHOFF-POPIEN, C. A context modeling survey. In: INTERNATIONAL
WORKSHOP ON ADVANCED CONTEXT MODELLING REASONING AND
MANAGEMENT AS PART OF UBICOMP,1., 2004, Nottigham, Eng. Proceedings … New
York: ACM, 2004.[S.l.]: Citeseer. Disponível em: <http://www.mendeley.com/research/acontext-modeling-survey/>. Acesso em: 29 nov. 2011.
STRANG, T. ; LINNHOFF-POPIEN, C. ; FRANK, K. CoOL: a context ontology language to
enable contextual interoperability.In: STEFANI, J-B. ; DEMEURE, I. ; HAGIMONT, D.
(Eds.). Distributed applications and interoperaable systems. .4 th IFIP WG 6.1
International Conference DAIS. Paris, France 2010. Proceedings. Berlin: Springer Verlag,
2003. (Lecture Notes in Computer Science, 2893).
STRIMPAKOU, M. A. ; ROUSSAKI, I. G. ; ANAGNOSTOU, M. E. A Context ontology for
pervasive service provision. In: AINA - INTERNATIONAL CONFERENCE ON
ADVANCED INFORMATION NETWORKING IN APLLICATIONS, 20., 2006, Viena.
Proceedings … Los Alamitos: IEEE, 2006. V. 2.
SZEWCZYK, R. et al. Habitat monitoring with sensor networks. Communications of the
ACM, New York, v. 47, n. 6, p. 34–40, Jun 2004.
164
TANG, L. et al. Supporting rapid design and evaluation of pervasive applications: challenges
and solutions. Personal and Ubiquitous Computing, London, v. 15, n. 3, p. 253-269, Aug.
2011.
URBANI, J. RDFS/OWL reasoning using the MapReduce framework. 2009. Master
thesis, Dept. of Computer Science, Faculty of Sciences, Vrije Universiteit, Amsterdam, 2009.
URBANI, J. et al. Scalable distributed reasoning using MapReduce. In: BERSTEIN, A. et al.
(Eds.). The semantic web – ISWC 2009. 8 th International Semantic Web Conference,
ISWC 2009, Chantily, VA, 2009 Proceedings. Berlin: Springer-Verlag, 2009. (Lecture Notes
in Computer Science, v. 5823). Disponível em: <http://dx.doi.org/10.1007/978-3-642-049309_40>. Acesso em: 2011
VIDAL, V. Et al. An ontology-based framework for geographic data integration. In:
HEUSER, C. A. ; PERNUL, G. (Eds.). Advances in c onceptual modeling hallenging
perspectives. ER 2009 Workshop CoMoL, EttheCoM, FP-UML, MOST-ONISW, QoIS,
RIGiM, SeCoGIS. Gramado Brasil, 2009, Proceedings. Berlin: Springer: 2009. (Lecture
Notes in Computer Science, v. 5833. p. 337-346.
WANG, X. H. et al. Ontology based context modeling and reasoning using OWL. In: IEEE
ANNUAL CONFERENCE ON PERVASIVE COMPUTINGAND COMMUNICATIONS
WORKSHOPS, 2., 2004, Orlando. Proceedings … los Alamitos: IEEE, 2004. p.18-22.
Disponível em: <http://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=1276898>.
Acesso em: 2011.
WANG, X. et al. Semantic space: an infrastructure for smart spaces. IEEE Pervasive
Computing, New York, v. 3, n. 3, p. 32-39, Jul./Sept. 2004.
WEISER, M. The computer for the 21st century. Scientific American, New York, v. 265, n.
3, p. 94–104, 1991.
WINKELS, R. ; HOEKSTRA, R. ; HUPKES, E. Normative reasoning with geo information.
In: COMGeo 10 - INTERNATIONAL CONFERENCE AND EXHIBITION ON
COMPUTING FOR GEOSPATIAL RESEARCH & APPLICATIONS, 1., 2010, San Jose,
CA. Proceedings … New York: ACM, 2010. Article 16. Disponível em:
<http://doi.acm.org/10.1145/1823854.1823874>. Acesso em: 2011.
YE, J. et al. A unified semantics space model. In: HIGHTOWER, J. : SCHIELE, B. ;
STRANG, T. (Eds.). Location-and context-awareness, Third International Symposium
LoCA 2007, Oberpfaffenhofen, Germany, 2007 Proceedings. Berlin:Springer, 2007. p. 103120. (Lecture Notes in Computer Science, v. 4718).
YU, Z. et al. Theme issue on context-aware middleware and applications. Personal and
Ubiquitous Computing, London, v. 15, n. 3, p. 219-220, Aug. 2010.
165
Apêndices
Apêndice A – Cenário 2: mapeamento D2R para Rain Stations Endpoint (RSE)
O mapeamento usando D2R é realizado através de um arquivo de mapeamento, cujo
formato é definido pela própria plataforma D2RQ. A listagem a seguir apresenta alguns
trechos deste arquivo usando a sintaxe Turtle. Basicamente é necessário definir as
configurações do servidor D2R (linhas 1-6), da conexão com o banco de dados (linhas 8-13) e
os mapeamentos de classes e propriedades (demais linhas).
1
2
3
4
5
6
7
8
9
10
11
# Configuração básica do servidor
<> a d2r:Server;
rdfs:label "Alerta Rio" ;
d2r:baseURI <http://alertario.rio.rj.gov.br:2020/> ;
d2r:port 2020 ;
(...)
# Configuração da conexao com o banco de dados
map:database a d2rq:Database;
d2rq:jdbcDriver "com.mysql.jdbc.Driver";
d2rq:jdbcDSN "jdbc:mysql://db.alertario.rio.rj.gov.br
/rain_sensors";
12
d2rq:username "alertario";
13
(...)
14
15 # Table station
16 map:station a d2rq:ClassMap;
17
d2rq:dataStorage map:database;
18
d2rq:class a:Station;
19
d2rq:uriPattern "Station/@@station.id@@".
20
21 map:station_name a d2rq:PropertyBridge;
22
d2rq:belongsToClassMap map:station;
23
d2rq:property a:stationName;
24
d2rq:column "station.name".
25
26 map:station_lat a d2rq:PropertyBridge;
27
d2rq:belongsToClassMap map:station;
28
d2rq:property a:latitude;
29
d2rq:column "station.latitude";
30
d2rq:datatype xsd:decimal .
31 (...)
32
33 # Table measure
166
34
35
36
37
38
39
40
41
42
43
44
45
46
map:measure a d2rq:ClassMap ;
d2rq:dataStorage map:database ;
d2rq:class a:Measure ;
d2rq:uriPattern "Measure/@@measure_view.id@@" .
# map:measure_date e map:measure_value omitidos ...
# Mapeamento object property (measure -> station)
map:measure_station a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:measure;
d2rq:property a:station;
d2rq:refersToClassMap map:station;
d2rq:join "measure_view.station_id => station.id" .
Na configuração do servidor pode-se definir a porta de escuta do servidor (no caso
2020) e o URI base a ser utilizado ao construir o URI das instâncias (registro) das classes
(tabelas). Para a conexão configura-se driver, endereço de acesso ao banco de dados, login e
senha. Os mapeamentos podem ser de dois tipos: d2rq:ClassMap e d2rq:PropertyBridge. O
primeiro mapeia uma tabela com um conceito, neste caso, station com a:Station (linhas 1519) e measure com a:Measure (linhas 33-37). O segundo mapeia atributos das tabelas com
propriedades (p.ex. station.latitude com a:latitude, apresentado nas linhas 26-31). O URI de
cada instância das classes é definido pela propriedade d2rq:uriPattern, que permite a
definição do padrão de formação, usando atributos da tabela do banco, a ser adicionado ao
URI base. Na linha 19 é apresentado um uso desta propriedade. Neste caso, a estação 15 seria
identificada por <http://alertario.rio.rj.gov.br:2020/resource/Station/15>.
Adicionalmente, o tipo de dados diferentes de xsd:string para as propriedades podem
ser
definido
conforme apresentado
na
linha 30.
Por
fim,
para não
estender
desnecessariamente, vale destacar as linhas 41 a 46 que apresentam o mapeamento de uma
object property relacionando uma medição com a estação que a mediu. Observe a propriedade
d2rq:join que permite relacionar os atributos station_id e id das tabelas measure_view e
station. Por falar nisso, measure_view não é uma tabela, mas sim uma visão da tabela
measure que seleciona apenas uma janela com as medidas mais recentes e é atualiza a cada 5
segundos por um programa Java que é executado paralelamente ao D2R. A janela adotada foi
de quatro dias para englobar a necessidade de se ter 96 horas de medição, equivalente a quatro
dias. Isto foi feito apenas por questões de desempenho, evitando que consultas equivocadas,
do tipo “recupere todas a medidas”, demorassem muito tempo para serem respondidas. E isto
realmente demoraria bastante em função de a tabela measure conter mais de 15 milhões de
registros, uma vez que os dados históricos compreendem os anos de 1997 a 2011.
167
Apêndice B – Cenário 2: implementação da geração de coordenadas e mapeamento
D2R para User Locations Endpoint (ULE)
Conforme apresentado na seção 4.2.2.2, este endpoint simula a obtenção das
coordenadas de usuário de um GPS produzidas de duas maneiras: arquivos KML gerados pelo
Google Maps (dois cenários) e gerador automático de coordenadas e rotas. As informações
são armazenadas em um banco de dados MySQL e o software D2R efetua o mapeamento.
Adiante o diagrama do banco de dados, o vocabulário RDF e o mapeamento entre eles serão
sucintamente apresentados. Em seguida a estrutura do KML exportado pelo Google Maps e os
algoritmos de geração das coordenadas serão discutidos com mais detalhes.
O diagrama entidade-relacionamento é composto apenas pelas tabelas user e location
(Figura 20 na página 108). A primeira possui um atributo identificador e o nome do usuário e,
a segunda, contém um atributo identificador, as coordenadas geográficas e o horário de
atualização. As tabelas possuem uma relação 1:1 porque a primeira é armazenada em disco
contendo 150.000 usuários com nomes gerados automaticamente e, a segunda, é armazenada
em memória contendo os dados de localização que são sempre gerados dinamicamente e
descartadas após a execução. A Figura 20 apresenta ainda o vocabulário RDF, com os
conceitos usr:Usuario e usr:Ponto, e o mapeamento através de uma linha tracejada. O arquivo
de mapeamento é similar ao apresentado no Apêndice A e será omitido. Vale ressaltar,
contudo,
que
o
URI
das
instâncias
é
gerado
pela
concatenação
de
http://users.com.br:2026/resource/ com o nome do conceito e seu identificador na tabela.
A construção dos dois cenários de movimentação de usuário começam por uma
pequena história da atividade do usuário, apresentados textualmente a seguir:
Cenário 1: “João de Deus mora na Cidade de Deus e trabalha como segurança em
uma casa noturna na Lapa de terça a sábado. Ele sai de casa às 18h30 para chegar no
trabalho por volta de 20h. Às 5h ele deixa o serviço e retorna para casa, chegando
aproximadamente às 6h. Tanto na ida quanto na volta ele pode pegar dois caminhos
dependendo do ônibus que passar primeiro: via Linha Amarela ou via Zona Sul. Contudo,
75% da vezes ele vai pela Linha Amarela”.
Cenário 2: “Dona Maria mora na Rocinha e trabalha numa casa no Leblon de
segunda a sexta das 7h às 13h. Ao sair, ela vai diretamente para o Andaraí às segundas e
quartas onde ela faz curso de culinária das 14h30 às 15h30. Ela então vai para o Centro
onde estuda Administração até 22h, quando então retorna para casa”.
168
A partir disto, foram geradas rotas usando o Google Maps. O processo foi realizado
manualmente na página do serviço, ou seja, marcou-se o ponto inicial e final e exportou-se a
rota para o formato KML. Assim, por exemplo, o trecho do cenário descrito por “Dona Maria
mora na Rocinha e trabalha (...) no Leblon (...). Ao sair, ela vai diretamente para o Andaraí
(...)” é convertido em duas rotas, uma Rocinha-Leblon e outra Leblon-Andaraí. Para
descrever os dias e horários destas rotas foi feita uma extensão na estrutura base do KML. O
formato KML33 é um arquivo XML, descrito basicamente pelos elementos kml, Placemark,
ExtendedData e alguns outros que representam entidades geométricas. Um exemplo é
apresentado a seguir:
1 <kml xmlns="http://www.opengis.net/kml/2.2">
2
<Placemark id=”id_marcador”>
3
<name>Absolute Extruded</name>
4
<description>Transparent green wall...</description>
5
<LineString>
6
<coordinates>
7
-112.2550785337791,36.07954952145647,2357
8
-112.2549277039738,36.08117083492122,2357
9
...
10
</coordinates>
11
</LineString>
12
</Placemark>
13 </kml>
O element kml é o elemento raiz que pode ter um ou mais elementos Placemark (linha
2), usados para marcar uma posição na superfície da Terra. Tais marcadores podem conter um
atributo identificador e os elementos name, description e uma geometria. A geometria é um
nome genérico concretizado pelos elementos Point (ponto geográfico), LineString (segmentos
de reta conectados), LinearRing (caminho fechado), Polygon (polígono que pode conter
buracos) e alguns outros. Os três primeiros possuem, obrigatoriamente, um elemento
coordinates que contém uma (para pontos) ou mais (para os demais) tuplas de dois ou três
valores (latitude, longitude e, opcionalmente, altitude). As linhas 5 a 11 mostram a estrutura
para um LineString. No caso de polígonos, há um elemento outerBoundaryIs contendo a
borda externa do polígono e zero ou mais elementos innerBoundaryIs contendo os buracos.
Ambos são definidos por um LinearRing. Adicionalmente, podem-se definir estilos para os
marcadores e/ou organizá-los em diretórios (Folder) e documentos (Document).
33
Conteúdo para a explicação extraído de https://developers.google.com/kml/documentation/kmlreference
169
O elemento ExtendData permite adicionar dados personalizados a um recurso
(Placemark, Folder ou Document). Assim, criou-se uma estrutura própria para definir um
cenário com agendas e caminhos. Esta estrutura é apresentada a seguir:
1 <ExtendedData xmlns:a="http://user.com.br">
2
<a:scenario>
3
<a:username>Joao de Deus</a:username>
4
<a:schedule>
5
<a:trigger>
6
<a:time>18:30:00+00:00</a:time>
7
<a:weekly>
8
TUESDAY
9
WEDNESDAY
10
...
11
</a:weekly>
12
</a:trigger>
13
<a:path ref="amarela">
14
<a:probability>0.7500</a:probability>
15
<a:velocity>40.0</a:velocity>
16
<a:way>FORWARD</a:way> <!-- backward -->
17
</a:path>
18
<a:path ref="zona_sul">
19
<a:probability>0.2500</a:probability>
20
...
21
</a:path>
22
</a:schedule>
23
...
24
</a:scenario>
25 </ExtendedData>
Note que é necessário definir um namespace (linha 1) no element ExtendedData e a
seguir pode-se utilizar os elementos a:scenario, a:username, a:schedule e seus subelementos.
O elemento a:scenario (linha 2) permite definir a agenda para o cenário, que é composta por
sinais de ativação (a:trigger – linhas 5-12) e caminhos (a:path – linhas 13-22). Os sinais
necessitam de um horário inicial e os dias da semana em que podem ser ativados (linhas 611). Os caminhos referenciam um Placemark (atributo ref – linhas 13 e 18) e possuem uma
probabilidade de escolha (linhas 14 e 19), uma velocidade (linha 15) e uma direção (linha 16).
Utiliza-se esta distribuição massa de probabilidade para, dado que um sinal de ativação foi
disparado, determinar qual rota será escolhida. A velocidade determina, em km/h, qual seria a
velocidade de deslocamento na execução de um caminho e, a direção define se o caminho
será executado na ordem direta ou inversa dos pontos (elemento coordinates).
170
O carregamento de arquivos KML é feito em Java utilizando a biblioteca JAK (Java
API for KML)34 para carregar os elementos do padrão KML e a biblioteca do padrão JAXB
(Java Architecture for XML Binding)35 instalada juntamente com a plataforma Java para
carregar o conteúdo XML do elemento ExtendedData. Ambos são capazes de transformar
KML e XML em objetos Java (POJOs), sendo que a segunda utiliza Java annotations
definidas pelo padrão JAXB. O diagrama de classes básico utilizado pela JAK é apresentado
na Figura 38 (esquerda) e é de fácil entendimento visto que reflete a discussão dos parágrafos
anteriores, sendo importante destacar apenas que AbstractObject é aquilo que possui um
identificador. Para os dados personalizados, o conteúdo do elemento ExtendedData é
convertido nos objetos Java apresentados também na Figura 38 (direita). Por fim, a classe
Path é associada a um animador de caminho (uma instância da interface PathAnimator) que é
capaz de interpretar as coordenadas do caminho estático (StaticPath) conforme a velocidade e
a direção definidas e gerar pontos simulando o deslocamento no caminho. PathAnimator e
StaticPath serão detalhadas posteriormente.
Kml
AbstractObject
UserScenario
1
+ username : String
1
Feature
*
Geometry
*
Container
Placemark
Point
1
*
LineString
Folder
LinearRing
Document
Polygon
MultiGeometry
*
*
Schedule
Coordinate
Boundary
*
1
Trigger
Path
+ time: Calendar
+ weekly : List <Day>
+ pathId : String
+ probability : double
+ velocity : double
+ way : Way
Figura 38. Diagram de classes: biblioteca JAK (esquerda) e dados personalizados (direita)
Além da geração de coordenadas usando o arquivo KML, foi também desenvolvido
um método para gerar os pontos inicial e final de caminhos cujo traçado foi obtido do serviço
Google Directions36. Este serviço é gratuito para uso não comercial, mas apesar de sua forma
gratuita ter algumas limitações estas não atrapalharam o desenvolvimento. É um serviço Web
que, resumidamente, recebe dois pontos (inicial e final) e retorna um arquivo JSON com os
pontos da rota. De forma semelhante à conversão feita de XML para objetos Java, foi feita
conversão de JSON para objetos Java usando anotações JAXB, contudo usando uma
34
Disponível em http://code.google.com/p/javaapiforkml/
35
Mais informações em http://www.oracle.com/technetwork/articles/javase/index-140168.html
36
Documentação disponível em https://developers.google.com/maps/documentation/directions/
171
biblioteca externa chamada Jersey37. Ao obter o arquivo JSON e construir os objetos Java,
cria-se um caminho estático e um animador de caminho (StaticPath e PathAnimator).
Quanto à geração dos pontos inicial e final de cada caminho é utilizada a densidade
populacional das regiões administrativas (RAs) do município do Rio de Janeiro. Estes dados
foram obtidos da tabela nº 2972 disponível na seção “Estatísticas > População” do Armazém
de Dados de Prefeitura do Rio de Janeiro 38. A quantidade de habitantes residentes em cada
RA foi colocada numa planilha do Excel e gerou-se sua distribuição acumulada conforme
parcialmente apresentado no Quadro 15.
Quadro 15. Distribuição de probabilidade acumulada (parcial) de um pessoa residir em RAs (2010)
Regiões
Administrativas
Jacarepaguá
Campo Grande
Bangu
Méier
Madureira
Santa Cruz
Barra da Tijuca
Realengo
...
Cidade de Deus
Paquetá
Soma
População
(hab.)
572.030
542.084
428.035
397.782
372.555
368.534
300.823
243.006
...
36.515
3.361
6.320.446
% da
população
9,05%
8,58%
6,77%
6,29%
5,89%
5,83%
4,76%
3,84%
...
0,58%
0,05%
Prob.
Acumulada
9,05%
17,63%
24,40%
30,69%
36,59%
42,42%
47,18%
51,02%
...
99,95%
100,00%
Como base neste quadro, o algoritmo de geração de um ponto é apresentado a seguir:
1
2
3
4
# Algoritmo de geração de um ponto base na densidade populacional
Gere um número pseudo-aleatório entre 0 e 1 usando a distribuição
uniforme de probabilidade
Descubra a qual região administrativa pertence consultando o quadro
Use o método de Monte Carlo para gerar um ponto no polígono da RA
Para gerar um ponto dentro de uma RA não basta apenas gerar um ponto, mas também
conhecer as bordas dos polígonos de todas elas. Estas bordas foram obtidas da página do
Portal Geo da Prefeitura do Rio de Janeiro 39, e como disponibilizam para download em
formato Shapefile40 foi usado o conversor para KML Shape2Earth41. Com as bordas
37
Biblioteca Jersey para desenvolvimento de serviços Web: http://jersey.java.net/
38
Armazém de Dados da Prefeitura do Rio de Janeiro: http://www.armazemdedados.rio.rj.gov.br/
39
Portal Geo: http://portalgeo.rio.rj.gov.br/website/basegeo/viewer.htm
40
Formato Shapefile: http://pt.wikipedia.org/wiki/Shapefile
172
conhecidas constrói-se o bounding box, que é o retângulo que envolve todos os pontos do
polígono. Assim, dada uma RA gera-se, aleatoriamente, um ponto (x, y) interno ao retângulo
envolvente e verifica-se se o ponto pertence ao polígono 42. Este método de sortear uma
solução e verificar se atende uma função é bastante conhecido e denomina-se Método de
Monte Carlo.
Com base nestas informações, o seguinte algoritmo de geração de coordenadas e
atualização no banco de dados foi usado:
1 # algoritmo de geração de caminhos
2 para cada usuario
3
se existe caminho associado ao usuario
4
gere proximo ponto do caminho
5
atualize BD com posicao do usuario e horario atual
6
se caminho terminou
7
desassocie o caminho do usuario
8
se gerador aleatorio
9
defina proximo horario de movimentacao
10
senao
11
se gerador aleatorio
12
se horario atual > proximo horario de movimentacao
13
obtenha posicao atual p e gere um ponto destino q
14
gere um caminho entre p e q
15
senao
# usando cenarios
16
obtenha caminho conforme horario atual e agenda do usuario
17
18
se obteve caminho
19
associe o caminho ao usuario
20
inicie animacao do caminho
21
senao
22
atualize BD para marcar horario de medicao atual
O algoritmo gera pontos aleatórios ou conforme cenários. A linha 4 utiliza o animador
de caminho associado ao usuário para determinar sua posição atual. Este caminho é gerado na
linha 14 ou 16. Nas linhas 11-14 é gerado um caminho a partir do ponto atual e de um ponto
destino aleatório caso o próximo horário de movimetação tenha sido atingido. Este horário é
definido aleatoriamente na linha 9. Nas linhas 15-16, o caminho para o horário atual é obtido
diretamente do cenário no KML. Nas linhas 18-20 o caminho é associado ao usuário e a
animação iniciada. Caso nenhum caminho seja criado o usuário continua no mesmo ponto
com atualização apenas de sua data de medição (linha 22).
41
Disponível em http://shape2earth.com/
42
O algoritmo por ser encontrado em http://alienryderflex.com/polygon/
173
Para finalizar esta seção, falta falar de caminhos estáticos e animadores de caminho.
Um caminho estático, classe StaticPath, contém um conjunto de pontos geográficos
ordenados e a distância em metros referente a sua trajetória. Possui ainda um identificador e
um nome. A sequência de pontos é dada na sua construção e é proveniente do KML ou do
JSON do Google Directions. O comprimento da trajetória é calculado quando a sequência de
pontos é passada ou atualizada quando um novo ponto é adicionado.
Um animador de caminho é representado pela interface PathAnimator que declara
métodos para retornar o caminho estático, iniciar animação e verificar se terminou, e calcular
ponto e distância atuais da animação. A classe UniformVelocityPathAnimator implementa
esta interface. Ela utiliza um caminho estático e uma direção neste caminho (direto ou
inverso) e gera trajetórias em movimento uniforme (MU – velocidade constante). Permite
definir a velocidade do movimento ou duração do trajeto utilizando um parâmetro passado no
construtor. A Figura 39 apresenta o diagrama estático UML destas classes.
PathAnimator
<<interface>>
+ getPath() : StaticPath
+ getEstimatedDuration() : int
+ getFirstPoint() : Point
+ startAnimation() : boolean
+ isAnimationRunning() : boolean
+ getAnimationPoint() : Point
+ getTraveledDistance() : Float
+ getStartTime() : long
Point
+ x : double
+ y : double
*
StaticPath
UniformVelocityPathAnimator
<<constructor>>(StaticPath, duration : int, direction : Way)
<<constructor>>(StaticPath, velocity : int, direction : Way)
1
- id : String
- name : String
- distance : double
Figura 39. Diagrama de classes simplificado para PathAnimator e StaticPath.
174
Apêndice C – Cenário 2: implementação da configuração dos módulos
Este apêndice apresenta a configuração detalhada dos módulos do cenário 2. Contudo,
para prosseguir a leitura recomenda-se primeiramente a leitura completa das seções 4.2.1 a
4.2.3, pois há referências a muitos conceitos e tabelas apresentados nestas seções.
Conforme apresentada na Figura 21, M1 consulta apenas o endpoint RSE, logo
necessita de apenas um carregador, mas como precisa calcular as chuvas acumuladas nos
quatro intervalos de tempo para cada estação e também obter as localizaçõs das estações, são
necessárias cinco consultas. A forma padrão das quatro primeiras consultas é dada a seguir.
Observa-se que é obtida a soma das medições durante o intervalo de tempo definido pelas
variáveis ?startDate e ?finalDate. Estas são substituídas durante a execução pelo intervalo de
tempo
desejado.
O
responsável
por
fazer
estas
substituições
é
o
binder
TimeFrameQueryBinder, sendo assim, a segunda variável será substituída pela data e hora do
instante de execução da consulta, e a primeira, pela data e hora inicial, ou seja, aquela obtida
por se subtrair o intervalo de tempo (em milissegundos) determinados pela janela de tempo. A
chamada à função BIND cria um nó com URI para representar a instância da classe
x:Location da estação. Um fato importante a se destacar foi observado ao usar o BIND com a
versão 0.8.1 do D2RQ. A versão de consulta utilizando BIND no mesmo WHERE de um
FILTER inutiliza o filtro, ou seja, é o mesmo que não colocar um filtro. Isto é destacado pelos
trechos tachados (nas linhas 7 e 14). A solução utilizada para contornar esta falha é
apresentada em sublinha na linha 18. Uma segunda solução seria não utilizar um BIND
explícito, mas sim um implícito no final da projeção (SELECT na linha 7) contendo apenas a
expressão URI...AS ?sloc entre parêntesis. Por fim, é construído um novo grafo que mapeia a
ontologia do endpoint SER (prefixo a) para a ontologia usada nos módulos (prefixo x). Esta
consulta é similar à função acc_rain do algoritmo apresentado (linhas 57-64) e será
denominada Qacc até o final desta seção.
1 CONSTRUCT {
2
?s
a x:Station ;
3
x:location ?sloc .
4
?sloc x:accRain15 ?acc .
5 }
6 WHERE {
7
{ SELECT ?s (SUM(?v) as ?acc) ?sloc
8
WHERE {
9
?s a a:Station .
10
?m a:station ?s .
11
?m a:measureValue ?v .
175
12
13
14
15
16
17
18
?m a:measureDate ?t .
FILTER (?t >= ?startDate && ?t <= ?finalDate)
BIND(URI(...) AS ?sloc)
}
GROUP BY ?s ?sloc
}
BIND(URI(fn:concat(
"http://infmod01.com.br/resource/stlocation/",
afn:sha1sum(?s))) AS ?sloc)
19 }
A consulta para obter as localizações das estações também é simples, obtendo,
basicamente, latitude e longitude das estações cujo período de funcionamento (a:beginDate e
a:endDate) está compreendido na janela de tempo definida pelas variáveis ?startDate e
?finalDate (também usando TimeFrameQueryBinder). Devido à falha da inutilização do filtro
em conjunto com BIND foi necessário adicionar um Sub-SELECT (um binding implícito
também seria possível). Esta consulta será denominada Qstloc até o final desta seção e é
apresentada a seguir.
1 CONSTRUCT {
2
?s
a x:Station ;
3
x:location ?sloc .
4
?sloc x:latitude ?slat ;
5
x:longitude ?slon .
6 }
7 WHERE {
8
{ SELECT ?s ?slat ?slon
9
WHERE {
10
?s a a:Station ;
11
a:latitude ?slat ;
12
a:longitude ?slon ;
13
a:beginDate ?t0 ;
14
a:endDate
?t1 .
15
FILTER (?t0 <= ?startDate && ?t1 > ?finalDate).
16
}
17
}
18
BIND(URI(fn:concat(
"http://infmod01.com.br/resource/stlocation/",
afn:sha1sum(?s))) AS ?sloc)
19 }
Uma vez definidas as consultas, a configuração do XML do módulo M1 se torna
simples conforme apresentada a seguir. Observa-se que a configuração do binder necessita de
apenas um elemento <frameMillis> que informa q uantos
milissegundos
devem
ser
subtraídos da data e hora atual para determinar o valor de ?startDate (linhas 15, 22, 29, 36 e
176
43). Nas linhas 49-52 pode-se visualizar a configuração da inferência usando a ontologia
apresentada para validar os dados usando Pelet Reasoner.
1 <InferenceModule>
2
<name>M1</name>
3
<prefixes>...</prefixes>
4
<resourceBaseUri>http://infmod01.com.br/resource/</resourceBaseUri>
5
<updatePolicy class="ClearDataPolicy" />
6
<clock baseUri="http://localhost:3030/" endpoint="" />
7
<loaders>
8
<PullLoader>
9
<endpoint>http://alertario.rio.rj.gov.br:2020/sparql</endpoint>
10
<queryConfigs>
11
<QueryData>
<!-- Pega chuva dos ultimos 15 minutos -->
12
<query>Qacc</query>
13
<interval>2.5*60*1000</interval> <!-- Intervalo de 2.5 min -->
14
<binder class="TimeFrameQueryBinder">
15
<frameMillis>15*60*1000</frameMillis> <!-- últimos 15 min -->
16
</binder>
17
</QueryData>
18
<QueryData>
<!-- Pega chuva acumulada na última 01 hora -->
19
<query>Qacc</query>
20
<interval>2.5*60*1000</interval>
<!-- Intervalo de 5 min -->
21
<binder class="TimeFrameQueryBinder">
22
<frameMillis>1*60*60*1000</frameMillis> <!-- última 1 hora -->
23
</binder>
24
</QueryData>
25
<QueryData>
<!-- Chuvas acumuladas nas últimas 24 horas -->
26
<query>Qacc</query>
27
<interval>2.5*60*1000</interval>
28
<binder class="TimeFrameQueryBinder">
29
<frameMillis>24*60*60*1000</frameMillis>
<!-- 24 horas -->
30
</binder>
31
</QueryData>
32
<QueryData>
<!-- Chuvas acumuladas nas últimas 96 horas -->
33
<query>Qacc</query>
34
<interval>2.5*60*1000</interval>
35
<binder class="TimeFrameQueryBinder">
36
<frameMillis>96*60*60*1000</frameMillis>
<!-- 96 horas -->
37
</binder>
38
</QueryData>
39
<QueryData>
<!-- Pega estacoes e suas localizações-->
40
<query>Qstloc</query>
41
<interval>60*60*1000</interval>
42
<binder class="TimeFrameQueryBinder">
43
<frameMillis>96*60*60*1000</frameMillis>
<!-- 96 horas -->
44
</binder>
45
</QueryData>
46
</queryConfigs>
177
47
</PullLoader>
48 </loaders>
49 <inference>
50
<reasoner>PELLET</reasoner>
51
<ontology>ontology.owl.ttl</ontology>
52 </inference>
53 <sparqlServer>
54
<path>/ds/</path>
55
<port>25001</port>
56
<fastUpdate>true</fastUpdate>
57 </sparqlServer>
58 </InferenceModule>
O módulo M2 calcula as distâncias entre usuários e estações, associando a cada
usuário as três estações mais próximas. Isto equivale às linhas 1-15 do algoritmo, que
consistem em duas consultas e um laço. A primeira, Quser, obtém a lista de usuários do
endpoint ULE, suas localizações e horários de obtenção. A segunda, Qdist, é executada dentro
do laço que itera sobre a lista de usuários, e tira proveito da função geo:distanceFromDegrees
do módulo M1 para cálculo da distância geográfica entre dois pontos (neste caso usuário e as
estações), ordena estes resultados usando a cláusula ORDER BY e faz um corte nos três
primeiros resultados usando a cláusula LIMIT, selecionando assim, as três estações mais
próximas. Para executar a consulta Qdist para cada linha de resultado da Quser usando o
Módulo de Inferência utiliza-se o binder SelectQueryParameterBinder. Ambas as consultas
são listadas a seguir e as variáveis da consulta Quser substituídas na consulta Qdist estão
destacadas com sublinhado:
1
2
3
4
5
6
7
8
SELECT ?u ?uloc ?ulat ?ulon ?utime
WHERE {
?u
a usr:User ;
usr:location ?uloc .
?uloc usr:latitude ?ulat ;
usr:longitude ?ulon ;
usr:updateTime ?utime .
}
1
2
3
4
5
6
7
8
9
CONSTRUCT {
?u
a x:User ;
x:inferenceLocation ?uloc .
?uloc x:latitude ?ulat ;
x:longitude ?ulon ;
x:updateTime ?utime ;
x:nearestStations ?ns .
?ns
x:station ?s ;
x:distance ?dist .
178
10 }
11 WHERE {
12
{ SELECT ?s
(geo:distanceFromDegrees(?ulat, ?ulon, ?slat, ?slon) as ?dist)
13
WHERE {
14
?s a x:Station ;
15
x:location [
16
x:latitude ?slat ;
17
x:longitude ?slon ] .
18
}
19
ORDER BY ?dist
20
LIMIT 3
21
}
22
BIND (URI(fn:concat(
"http://infmod02.com.br/resource/NearestStationsInfo/",
afn:sha1sum(fn:concat(?u, ?s)))) as ?ns)
23 }
Adicionalmente, uma consulta que obtém os valores de chuvas acumuladas de M1 foi
adicionada ao módulo M2. Esta consulta funciona apenas para repassar estes valores para o
endpoint de M2. Por ser um consulta simples e não acrescentar conhecimento será omitida e
denominada Qacc2. O XML de M2 é apresentado a seguir:
1 <InferenceModule>
2
<name>M2</name>
3
<prefixes>...</prefixes>
4
<resourceBaseUri>http://infmod02.com.br/resource/</resourceBaseUri>
5
<updatePolicy class="ClearDataPolicy" />
6
<clock baseUri="http://localhost:3030/" endpoint="" />
7
<loaders>
8
<PullLoader>
9
<endpoint>http://infmod01.com.br:25001/ds/sparql</endpoint>
10
<queryConfigs>
11
<QueryData>
12
<interval>2*60*1000</interval>
13
<query>Qacc2</query>
14
<binder class="DefaultQueryParameterBinder" />
15
</QueryData>
16
<QueryData>
17
<interval>2*60*1000</interval>
18
<query>Qdist</query>
19
<binder class="SelectQueryParameterBinder">
20
<endpoint>http://users.com.br:2026/sparql</endpoint>
21
<query>Quser</query>
22
</binder>
23
</QueryData>
24
</queryConfigs>
25
</PullLoader>
179
26 </loaders>
27 <inference>...</inference>
28 <sparqlServer>...</sparqlServer>
29 </InferenceModule>
<!-igual ao M1
-->
<!-- semelhante ao M1 -->
O modulo M3 é o mais complexo por implementar as linhas 17-55 do algoritmo. A
Equação I é calculada através de uma consulta SPARQL e a classificação efetuada por meio
de regras Jena. São usadas regras do Jena por dois motivos: (1) maior facilidade de se
escrever regras por não haver necessidade de editores especiais devido a sua sintaxe simples;
e (2) mostrar a possibilidade de se misturar dois diferentes motores de inferência na rede,
desde que em diferentes módulos. Relembre que é necessário calcular o denominador do peso
(dtot nas linhas 17-18) e o peso (linha 22) de cada estação no cálculo da suposta quantidade de
chuva na posição do usuário (linhas 23 a 26). Portanto, a consulta SPARQL pode ser
considerada complexa porque inclui quatro SELECTs distribuídos em três níveis de
aninhamento (Sub-SELECTs), quatro junções (dois SELECTs e dois padrões de grafo),
função de agregação SUM e expressões matemáticas (multiplicaçaõ e divisão). A consulta
completa é mostrada a seguir (Qchuva):
1 CONSTRUCT {
2
?u
a x:User .
3
?u
x:inferenceLocation ?loc .
4
?loc x:latitude
?lat ;
5
x:longitude ?lon ;
6
x:updateTime ?time ;
7
x:accRain15 ?avg15 ;
8
x:accRain01h ?avg60 ;
9
x:accRain24h ?avg24 ;
10
x:accRain96h ?avg96 ;
11 }
12 WHERE {
13
SELECT DISTINCT ?u ?loc ?lat ?lon ?time
14
(sum(?lv15) as ?avg15)
# Calcula avg15 para
15
(sum(?lv60) as ?avg60)
# Calcula avg60 para
16
(sum(?lv24) as ?avg24)
# Calcula avg24 para
17
(sum(?lv96) as ?avg96)
# Calcula avg96 para
18
WHERE {
19
SELECT DISTINCT ?u ?loc ?lat ?lon ?time
20
((?w * ?v15) as ?lv15)
# Calcula parcelas
21
((?w * ?v60) as ?lv60)
# Calcula parcelas
22
((?w * ?v24) as ?lv24)
# Calcula parcelas
23
((?w * ?v96) as ?lv96)
# Calcula parcelas
24
WHERE {
25
{
26
# Calcula denominador da fórmula (?dtot)
cada
cada
cada
cada
usuario
usuario
usuario
usuario
para 15 min
para 1 h
para 24 h
para 96 h
180
27
{ SELECT DISTINCT ?u ?loc (sum(1 / (?d * ?d)) as ?dtot)
28
WHERE {
29
?u
a x:User ;
30
x:inferenceLocation ?loc .
31
?loc x:nearestStations ?ns .
32
?ns x:station
?s ;
33
x:distance
?d .
34
}
35
GROUP BY ?u ?loc
36
}
37
# Calcula numerador de cada peso w: 1/d^2 (?num_w)
38
{ SELECT DISTINCT ?u ?loc (1 / (?d * ?d) as ?num_w) ?s
39
WHERE {
40
?u
a x:User .
41
?u
x:inferenceLocation ?loc .
42
?loc x:nearestStations ?ns .
43
?ns x:station
?s ;
44
x:distance
?d .
45
}
46
}
47
# Obtem chuva acumulada nas estações próximas ao usuário ?u
48
{ ?s x:location [
49
x:accRain15 ?v15 ;
50
x:accRain01h ?v60 ;
51
x:accRain24h ?v24 ;
52
x:accRain96h ?v96 ] .
53
}
54
# Obtem lat/long do usuário ?u e horário de atualização
55
{ ?loc x:latitude ?lat ;
56
x:longitude ?lon ;
57
x:updateTime ?time .
58
}
59
}
60
# Calcula pesos (?w)
61
BIND ((?num_w / ?dtot) as ?w)
62
}
63
}
64
GROUP BY ?u ?loc ?lat ?lon ?time
65 }
Os SELECTs mais internos calculam numerador e denominador dos pesos (1/d2 e
Equação IIc) e são encontrados nas linhas 37-46 e 26-36, respectivamente. O cálculo do
denominador utiliza a função de agregação SUM agrupada por usuário e localização. Existe
apenas uma instância de x:UserLocation para cada propriedade x:inferenceLocation de
usuário, mas outras poderiam ser adicionadas (como casa, trabalho, etc.) sem necessidade de
alterações na consulta visto que ela já garante distinção. Uma vez que estes SELECTs
retornam soluções nas variáveis ?u, ?loc, ?dtot, ?num_w, e ?s, estas são combinadas (produto
181
cartesiano ou junção) com os padrões de grafos das linhas 47-53 e 54-58 que capturam as
chuvas acumuladas na estação ?s e latitude, longitude da localização ?loc do usuário ?u (e
também horário de atualização destas coordenadas), respectivamente. O resultado desta
junção é, então, utilizado no SELECT de segundo nível que calcula pesos (Equação IIb) na
linha 61, e as parcelas wi vi(t) para os quatro períodos em questão preenchendo as variáveis
?lv15, ?lv60, ?lv24 e ?lv96 nas linhas 20-23. Estas parcelas são somadas no SELECT mais
externo chegando-se ao resultado das variáveis ?avg15, ?avg60, ?avg24 e ?avg96 (Equação
IIa). Por fim, é montado o grafo que armazenará estes resultados para posterior utilização
através do CONSTRUCT.
Baseado na suposta quantidade de chuva, a intensidade de chuva e a probabilidade de
escorregamento definidas pelo Alerta-Rio são dadas por meio das seguintes regras Jena:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Intensidade de chuvas (15 min)
r15a: (?p :accRain15 ?v) gt(?v, 12.50)
r15b: (?p :accRain15 ?v) gt(?v, 6.25)
r15c: (?p :accRain15 ?v) gt(?v, 1.25)
r15d: (?p :accRain15 ?v) gt(?v, 0.28)
r15e: (?p :accRain15 ?v)
# Intensidade de chuvas (1h)
r60a: (?p :accRain01h ?v) gt(?v,50.00)
r60b: (?p :accRain01h ?v) gt(?v,25.00)
r60c: (?p :accRain01h ?v) gt(?v, 5.00)
r60d: (?p :accRain01h ?v) gt(?v, 1.10)
r60e: (?p :accRain01h ?v) gt(?v, 0.50)
r60f: (?p :accRain01h ?v) gt(?v, 0.25)
r60g: (?p :accRain01h ?v) gt(?v, 0.00)
r60h: (?p :accRain01h ?v)
-> (?p :rainLevel15
le(?v, 12.50) -> (?p :rainLevel15
le(?v, 6.25) -> (?p :rainLevel15
le(?v, 1.25) -> (?p :rainLevel15
le(?v, 0.28) -> (?p :rainLevel15
(?p
(?p
(?p
(?p
(?p
(?p
(?p
(?p
:rainLevel01h
:rainLevel01h
:rainLevel01h
:rainLevel01h
:rainLevel01h
:rainLevel01h
:rainLevel01h
:rainLevel01h
7)
6)
5)
4)
3)
2)
1)
0)
# Alerta de escorregamento (1h)
s60a: (?p :accRain01h ?v) gt(?v,50.00)
-> (?p
s60b: (?p :accRain01h ?v) gt(?v,30.00) le(?v,50.00) -> (?p
s60c: (?p :accRain01h ?v) gt(?v,10.00) le(?v,30.00) -> (?p
s60d: (?p :accRain01h ?v)
le(?v,10.00) -> (?p
:slipLevel01h
:slipLevel01h
:slipLevel01h
:slipLevel01h
3)
2)
1)
0)
# Alerta de escorregamento (24h)
s24a: (?p :accRain24h ?v) gt(?v,175.0)
-> (?p
s24b: (?p :accRain24h ?v) gt(?v,100.0) le(?v,175.0) -> (?p
s24c: (?p :accRain24h ?v) gt(?v, 50.0) le(?v,100.0) -> (?p
s24d: (?p :accRain24h ?v)
le(?v, 50.0) -> (?p
:slipLevel24h
:slipLevel24h
:slipLevel24h
:slipLevel24h
3)
2)
1)
0)
# Alerta de escorregamento (96h)
s96a: (?p :accRain96h ?v) gt(?v,250.0)
-> (?p
s96b: (?p :accRain96h ?v) gt(?v,175.0) le(?v,250.0) -> (?p
s96c: (?p :accRain96h ?v) gt(?v,100.0) le(?v,175.0) -> (?p
s96d: (?p :accRain96h ?v)
le(?v,100.0) -> (?p
:slipLevel96h
:slipLevel96h
:slipLevel96h
:slipLevel96h
3)
2)
1)
0)
le(?v,50.00)
le(?v,25.00)
le(?v, 5.00)
le(?v, 1.10)
le(?v, 0.50)
le(?v, 0.25)
le(?v, 0.00)
->
->
->
->
->
->
->
->
7)
6)
5)
4)
0)
182
37 # Intensidade de chuvas (final)
38 r01: (?p :rainLevel15 ?x) (?p :rainLevel01h ?y) max(?x, ?y, ?z)
-> (?p :rainLevelX ?z)
39
40 r02: (?p :rainLevelX 7) -> (?p :rainLevel :VeryHeavyRain)
41 r03: (?p :rainLevelX 6) -> (?p :rainLevel :HeavyRain)
42 r04: (?p :rainLevelX 5) -> (?p :rainLevel :ModerateRain)
43 r05: (?p :rainLevelX 4) -> (?p :rainLevel :LightRain)
44 r06: (?p :rainLevelX 3) -> (?p :rainLevel :HeavyDrizzle)
45 r07: (?p :rainLevelX 2) -> (?p :rainLevel :ModerateDrizzle)
46 r08: (?p :rainLevelX 1) -> (?p :rainLevel :LightDrizzle)
47 r09: (?p :rainLevelX 0) -> (?p :rainLevel :Dry)
48
49 # Alerta de escorregamento (final)
50 s01: (?p :slipLevel01h ?x) (?p :slipLevel24h ?y) (?p :slipLevel96h ?z)
max(?x,?y,?w0) max(?w0,?z,?w) -> (?p :slipLevelX ?w)
51
52 s02: (?p :slipLevelX 3) -> (?p :slipLevel :VeryHigh)
53 s03: (?p :slipLevelX 2) -> (?p :slipLevel :High)
54 s04: (?p :slipLevelX 1) -> (?p :slipLevel :Moderate)
55 s05: (?p :slipLevelX 0) -> (?p :slipLevel :Low)
As regras não são difíceis de se entender. Por exemplo, a regra r15a na linha 2 diz “se
existe um localização cuja chuva dos últimos 15 minutos seja maior que 12.50 mm então
adicione uma tripla afirmando que o nível para intensidade de chuva dos últimos 15 minutos é
7 (ou x:VeryHeavyRain)”. Maiores detalhes sobre cada regra e bloco de regras são dadas nos
próximos parágrafos.
Como apresentado nos Quadros 8 e 10, para a classificação do nível de intensidade de
chuva, deve-se considerar os valores de medições em mm/h e mm/15min, respectivamente.
Desta forma as regras r15a a r15e (linhas 2-6) verificam em qual faixa a propriedade
x:accRain15 se encontra (mm/15min) e as regras r60a a r60h (linhas 9-16) verificam a faixa
para a propriedade x:accRain01h. Estes dois conjuntos de regras produzem, respectivamente,
triplas com predicados x:rainLevel15 e x:rainLevel01h cujos objetos são valores numéricos
inteiros intermediários que representam o grau de gravidade do alerta (zero para sem chuva e
sete para chuva muito forte). Para estas regras foram utilizadas duas funções (built-ins) do
Jena: greaterThan (abreviada para gt) que retorna true se o primeiro argumento é maior que o
segundo; e le que retorna true se o primeiro argumento é menor ou igual ao segundo.
Conforme descrito na seção 4.2.1 sobre o domínio, escolheu-se utilizar o pior dos valores
obtidos (máximo entre x:rainLevel15 e x:rainLevel01h), que corresponde a regra r01 (linha
38) e utiliza a função max. Este valor é então mapeado para instâncias de x:RainLevel por
meio das regras r02 a r09 (linhas 40-49).
183
O processo é feito de forma semelhante para alertas de probabilidade de
escorregamento (Quadro 9). As regras s60a a s60d (1 hora), s24a a s24d (24 horas) e s96a a
s96d (96 horas) encontradas nas linha 19-22, 25-28 e 31-34, respectivamente, produzem
triplas intermediárias com os predicados x:slipLevel01h, x:slipLevel24h e x:slipLevel96h que
possuem os graus de gravidade do alerta (zero para baixa probabilidade de escorregamento,
um para moderada, dois para alta e três para muito alta). Novamente, o valor mais crítico
dentre estes três é obtido (regra s01 na linha 50) e mapeado para instâncias de x:SlipLevel
(regras s02 a s05 nas linhas 52-55).
Vários observações importantes devem ser destacadas aqui. Primeiramente, não
haverá várias classificações (x:rainLevel e x:slipLevel) para uma mesma localização porque
as propriedade x:accRainY são únicas para cada URI de localização (fato comprovado pelo
GROUP BY mais externo da consulta Qchuva). Para ficar mais claro, veja que como existe no
máximo uma tripla (?p x:accRain15 ?v) no grafo (para cada localização ?p) é garantido que
no máximo uma tripla (?p x:rainLevel15 X) será criada e a regra r01 será disparada no
máximo uma vez para cada localização (?p) gerando no máximo uma tripla (?p x:rainLevelX
?z) e consequentemente uma tripla com o predicado x:rainLevel. O mesmo ocorre para
probabilidade de escorregamento.
O segundo ponto diz respeito à consistência da base gerada por M3. As propriedades
intermediárias x:rainLevel15, x:rainLevel01h, x:rainLevelX, x:slipLevel01h, x:slipLevel24h,
x:slipLevel96h e x:slipLevelX não estão presentes na ontologia apresentada na Figura 22,
logo uma validação nesta base resultaria em incosistência. Para resolver isto bastaria adicionar
as propriedades à ontologia e configurar M3 para utilizá-la, mas optou-se por não realizar a
validação que será feita no próximo módulo. Assim, este módulo é apenas baseado em regras
sem validação OWL-DL. Outro ponto importante é que estas regras poderiam ser facilmente
implementadas via programação convencional imperativa conforme apresentado no algoritmo
completo (linhas 28-55 da seção 4.2.3.1), mas isto não é permitido pela arquitetura do Módulo
de Inferência, sugerindo trabalhos futuros. Para concluir M3, o XML de configuração apenas
com as partes mais importantes para evitar repetições é apresentado a seguir:
1
2
3
4
5
6
7
<InferenceModule>
<name>M3</name>
...
<loaders>
<PullLoader>
<endpoint>http://infmod02.com.br:25002/ds/sparql</endpoint>
<queryConfigs>
184
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<QueryData>
<query>Qchuva</query>
<interval>3*60*1000</interval>
<binder class="DefaultQueryParameterBinder" />
</QueryData>
</queryConfigs>
</PullLoader>
</loaders>
<inference>
<rules>
[r15a: (?p x:accRain15 ?v) greaterThan(?v, 12.50)
-> (?p x:rainLevel15 7) ]
[r15b: (?p x:accRain15 ?v) greaterThan(?v, 6.25)
-> (?p x:rainLevel15 6) ]
...
</rules>
</inference>
<sparqlServer> ... </sparqlServer>
</InferenceModule>
le(?v, 12.50)
As regras são adicionadas no interior do element <rules> (linhas 17-21). Pode-se
observar que cada regra deve ser envolvida por colchetes que foram omitidos devido ao
pequeno espaço ao mostrar todas as regras anteriormente.
Até este momento, a localização de cada usuário já possui uma classificação para
intensidade de chuva e probabilidade de escorregamento. Poderia-se até finalizar a rede neste
ponto, mas para mostrar como um novo módulo pode ser adicionado facilmente, foi criado o
módulo M4 para produzir contexto de bairro para o usuário. Assim, a tarefa de M4 é
recuperar a posição atual de cada usuário e adicionar a informação do bairro à ela, fazendo o
mesmo com a posição usada para geração dos alertas. Para isso é utilizado um carregador para
o endpoint NBE contendo dois pares de consultas. O primeiro par obtém a posição atual do
usuário consultando o endpoint ULE com uma consulta semelhante à Quser, de forma que um
SelectQueryParameterBinder é usado para atribuir valores às variáveis de uma outra consulta
disparada contra o endpoint NBE. Esta última utiliza a função nb_contains para descobrir o
bairro que contém a coordenada geográfica dada. Estas informações são associadas ao usuário
através da propriedade x:currentLocation. O segundo par de consultas executa um processo
semelhante, com a diferença de determinar o bairro da posição utilizada na inferência
(propriedade x:inferenceLocation oriunda de M3), e adicionalmente repassar os valores das
propriedades x:slipLevel e x:rainLevel já computadas por M3. O XML não será apresentado
aqui.
185
Apêndice D – Cenário 3: implementação, mapeamento e configuração dos módulos
para Bus Locations Endpoint (BLE)
Este apêndice abordará a implementação do endpoint BLE, que compreende um
gerador de caminho de ônibus com base em arquivos KML contendo pontos de ônibus e rotas.
As coordenadas geradas são armazenadas em um banco de dados relacional e mapeadas para
RDF usando uma parte da ontologia BusOnto (seção 4.3.1.3 na página 121). As bibliotecas e
ferramentas utilizadas são as mesmas descritas no Apêndice B, salvo quando expresso o
contrário. Por fim, dois módulos de inferência são usados para (a) completar o que não é
expresso pelo mapeamento e checar a consistência da base estática usando Pellet e (b) agregar
a base estática e os dados dinâmicos usando Jena. Este último módulo é o endpoint final do
BLE. A Figura 40 esquematiza este procedimento.
BusDyn
(Jena)
bus:Bus (10s)
Rotas, linhas, etc. (10min)
BusStatic
(Pellet)
Rotas, linhas, etc. (1h)
BusD2R
(porta 5050)
mapeamento para RDF
Rotas
(KML)
Paradas
(KML)
Carregador
de KML
Algoritmo de
geração de ônibus e
caminhos
atualiza
SGBD
Figura 40. Estrutura interna do endpoint BLE
Como pode observar na figura, há dois tipos de arquivos KML (o formato é explicado
no Apêndice B). O primeiro deles possui apenas paradas de ônibus, ou seja, dados estáticos
sobre pontos geográficos rotulados (Placemark e Point). O segundo tipo de KML contém
rotas de ônibus (Placemark e LineString) e o nome e código da linha. Apenas duas linhas de
ônibus foram elaboradas, retratando uma linha interna (Alojamento – Vila Residencial) e uma
linha externa (General Osório – Penha) que circulam no campus da Ilha do Fundão. Isto
resultou em quatro arquivos KML. Para simplificar, considerou-se que ambas as linhas
circulam todos os dias da semana, 24 horas por dia, a uma velocidade média de 50 km/h, com
intervalos médios de 12 minutos e desvio padrão de 4 minutos seguindo a distribuição normal
de probabilidade. As coordenadas geográficas que compõem ambos os tipos de KML foram
186
gerados usando o software Google Earth43 e retratam a realidade dentro do campus (paradas e
rotas reais).
Uma vez carregados, os dados dos arquivos KML são inseridos em um banco
relacional cujo esquema é apresentado na FIGURA. De forma semelhante ao endpoint ULE,
há tabelas em disco e em memória, dependendo da frequência de atualização de seus
registros. Assim, a parte estática (tabelas stop, route_stop, route e line) fica em disco e a parte
dinâmica (tabela bus_car) em memória. Todas as tabelas são análogas às classes apresentadas
na ontologia da Figura 26 na página 122, ou seja, o mapeamento é direto, conforme pode ser
visto na Figura 41.
bus:RouteStop
bus:Stop
Disco
bus:Bus
route_stop
id (PK) : INT
route_id (FK) : INT
stop_id (FK) : INT
sequence : INT
distance_origin : FLOAT
Memória
stop
id (PK) : INT
name : VARCHAR(40)
latitude : DOUBLE
longitude : DOUBLE
bus_car
id (PK) : INT
order_num : INT
latitude : DOUBLE
longitude : DOUBLE
route_id (FK) : INT
traveled_distance : FLOAT
traveled_time : INT
route
id (PK) : INT
line_id (FK) : INT
start_rs_id (FK) : INT
final_rs_id (FK) : INT
bus:Route
line
id (PK) : INT
name : VARCHAR(60)
code : VARCHAR(8)
bus:Line
Figura 41. Diagrama entidade-relacionamente usado no endpoint BLE com mapeamento para a ontologia BusOnto.
A geração das coordenadas das rotas dos ônibus é feita usando caminhos com
trajetória em velocidade constante (classe UniformVelocityPathAnimator na Figura 39).
Antes de criar o animador de caminho, a rota lida do KML é transformada numa lista de
pontos (StaticPath). O processo é mostrado no algoritmo a seguir.
1
2
3
4
43
# Inicialização
mi := 12
sigma := 4
Para cada rota r
Google Earth – http://www.google.com/earth/
187
5
next_time(r) = cur_time()
6
7 Enquanto simulação estiver rodando
8
# Geracao de carros
9
Para cada rota r
10
Se cur_time() > next_time(r) então
11
Crie um animador de caminho p iniciando em origem(r)
12
Crie um ônibus c com um número de ordem aleatório
13
Adicione (c, p) à simulação
14
next_time(r) = cur_time() + normal(mi, sigma * sigma)
15
16
# Atualização de coordenadas
17
Para cada (c, p) na simulação
18
Se p terminou então
19
Remova (c, p) da simulação
20
Senão
21
P = cur_point(p)
22
latitude(c) = P.y
23
longitude(c) = P.x
24
traveled_distance(c) = traveled_distance(p)
25
traveled_time(c) = cur_time - start_time(p)
26
Atualize c na simulação
Assim, a saída de carros segue a distribuição normal com média de 12 minutos e desvio
padrão de 4 minutos (linha 14), sendo que cada carro possui um trajeto dado pelo animador de
caminhos construído a partir da rota oriundo do KML (linhas 11-12). Uma vez que um par
carro/caminho (c, p) é adicionado à simulação (linha 13) a tabela bus_car do banco de dados
passa a ser frequentemente atualizada traçando o caminho do ônibus (linhas 21 a 26).
Uma vez que KML foram carregados, trajetos estão sendo atualizados e o D2R foi
configurado e iniciado, basta construir os arquivos XMLs de configuração dos dois módulos
de inferência que completam e validam a base exportada pelo D2R. Eles já foram sucitamente
descritos na seção 4.3.2.3 na página 129 e são reapresentados na parte superior da Figura 40.
O módulo que obtém os dados estáticos (BusStatic) executa um SPARQL DESCRIBE dos
recursos que sejam instâncias de bus:Stop, bus:Route, bus:Line e bus:RouteStop, e aciona o
reasoner Pellet aplicando a ontologia BusOnto conforme mostra no XML a seguir:
1
2
3
4
5
6
7
8
<InferenceModule>
<name>Bus Endpoint</name>
<resourceBaseUri>http://bus.org/resource/</resourceBaseUri>
...
<loaders>
<PullLoader>
...
<queryConfigs>
188
9
<QueryData>
10
<description>Populate dataset</description>
11
<query>
12
DESCRIBE ?bs ?route ?rs ?line
13
WHERE {
14
?bs a bus:Stop .
15
?route a bus:Route .
16
?rs a bus:RouteStop .
17
?line a bus:Line .
18
}
19
</query>
20
<interval>1*60*60*1000</interval>
21
<binder class="DefaultQueryParameterBinder" />
22
</QueryData>
23
</queryConfigs>
24
</PullLoader>
25
</loaders>
26
<inference>
27
<reasoner>PELLET</reasoner>
28
<ontology>busonto.owl</ontology>
29
</inference>
30
<sparqlServer>...</sparqlServer>
31 </InferenceModule>
O módulo que obtém os dados dinâmicos (BusDyn) executa um SPARQL DESCRIBE
dos recursos que sejam instâncias de bus:Bus oriundos de BusD2R e um SPARQL
CONSTRUCT com todas as triplas de BusStatic. Utiliza uma regra Jena para adicionar a
propridade bus:servingLine que associa um ônibus a uma linha. Para finalizar, o XML a
seguir mostra a configuração do módulo:
1 <InferenceModule>
2
...
3
<loaders>
4
<PullLoader> ...
5
<queryConfigs>
6
<QueryData>
7
<query>DESCRIBE ?x WHERE { ?x a bus:Bus }</query>
8
<interval>10*1000</interval>
9
<binder class="DefaultQueryParameterBinder" />
10
</QueryData>
11
</queryConfigs>
12
</PullLoader>
13
<PullLoader> ...
14
<queryConfigs>
15
<QueryData>
16
<query>CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }</query>
17
<interval>10*60*1000</interval>
18
<binder class="DefaultQueryParameterBinder" />
189
19
20
21
22
23
24
25
26
27
28
29
30
31
32
</QueryData>
</queryConfigs>
</PullLoader>
</loaders>
<inference>
<reasoner>JENA</reasoner>
<rules>
[r1:
(?b rdf:type bus:Bus), (?l rdf:type bus:Line),
(?r rdf:type bus:Route),
(?b bus:route ?r), (?l bus:route ?r)
-> (?b bus:servingLine ?l)
]
</rules>
</inference>
<sparqlServer>...</sparqlServer>
</InferenceModule>
190
Apêndice E – Cenário 3: Configuração dos módulos da camada de inferência
Este apêndice apresenta a configuração detalhada dos módulos do cenário 3. Contudo,
para prosseguir recomenda-se primeiramente a leitura completa das seções 4.3.1 a 4.3.3, pois
há referências a muitos conceitos e tabelas apresentados nestas seções.
O módulo A1 utiliza duas consultas, denominadas Qcmdate e Qurel, e um conjunto de
sete regras. Ambas são apresentadas a seguir. A primeira consulta é um DESCRIBE que
obtém todas as instâncias de app:CommemorativeDate de CDE que estão por chegar através
da comparação da sua data inicial na variável ?beg (propriedade time:hasBeginning de evento
de intervalo) com a data e hora atual na variável ?date usando um FILTER. Data e hora atuais
são obtidas fazendo uma consulta ao endpoint do relógio e para isso utiliza-se um
SelectQueryParameterBinder. A segunda consulta, feita ao USNLE, é um DESCRIBE das
pessoas (variáveis ?u, ?x e ?y), das relações existentes entre pessoas (variável ?r) e dos
intervalos de tempo em que estas relações ocorrem (variável ?t). Observe que ao descrever um
usuário ?u todas as suas propriedades são retornadas (ex. rel:siblingOf, rel:husbandOf, etc.).
Estas duas consultas não precisam ser atualizadas com muita frequência, por isso Qcmdate
executa a cada 10 minutos e Qurel a cada 5 minutos.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Qcmdate
DESCRIBE ?x
WHERE {
?x a apv:CommemorativeDate ;
evt:timeSpan [
a time:Interval ;
time:hasBeginning ?beg
] .
FILTER (?date < ?beg)
}
# Qurel
DESCRIBE ?u ?x ?r ?t
WHERE {
{ ?u a foaf:Person . }
{ ?u foaf:knows ?x }
UNION
{ ?u rel:relativeOf ?y }
UNION
{ ?r rel:participant ?u ; evt:timeSpan ?t . }
}
As regras utilizadas dividem-se três grupos: (a) construção de eventos de aniversário
de nascimento e participações; (b) construção de eventos de aniversário de casamento e
191
namoro e participações; (c) construção de participações em eventos genéricos provenientes de
CDE. As regras R1 e R1a apresentadas a seguir pertencem ao grupo (a). R1 pega a data de
nascimento de uma pessoa (?dt), calcula o instante inicial da próxima data de aniversário
usando a função makeNearestDateTime (?beg), gera o instante final (?end) e constrói dois nós
no grafo da base intermediária usando a função makeNamedNode: um para o evento
aniversário a ser criado (?ebn) e outro para o intervalo de tempo deste evento (?tbn). No caso
de sucesso de todos estes procedimentos, adiciona triplas para dizer que ?ebn e ?tbn são
instâncias de evt:Event e time:Interval respectivamente, relaciona ambos com a propriedade
evt:timeSpan e define os instantes de início e fim do intervalo de tempo. Por fim, gera as
triplas de participação (propriedades evt:playsRole e app:isBirthdayPersonOf). A regra R1a
utiliza os eventos app:Birthday e participações app:isBirthdayPersonOf criados por R1 e as
triplas com predicado foaf:knows para gerar participações do tipo “amigo de aniversariante”
nos eventos aniversário.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Regra para construir evento Birthday: proximo aniversario
R1:
(?x rel:dateOfBirth ?dt),
makeNearestDateTime(?dt, ?beg),
dateSum(?beg, 1, ?end),
makeNamedNode(?ebn, ?x, "/Birthday"),
makeNamedNode(?tbn, ?x, "/Birthday/Time")
-> (?ebn rdf:type apv:Birthday),
(?ebn rdf:type evt:Event),
(?ebn evt:timeSpan ?tbn),
(?tbn rdf:type time:Interval),
(?tbn time:hasBeginning ?beg),
(?tbn time:hasEnd ?end),
(?x evt:playsRole ?ebn),
(?x app:isBirthdayPersonOf ?ebn)
# Regra para associar pessoas ao aniversario de seus
# conhecidos (amigos, mae, namorado, irmao, etc.)
R1a:
(?ev rdf:type apv:Birthday),
(?x apv:isBirthdayPersonOf ?ev),
(?x foaf:knows ?f)
-> (?f evt:playsRole ?ev),
(?f apv:isBirthdayPersonsFriendOf ?ev)
As regras R2 e R3 apresentadas a seguir fazem parte do grupo (b). R2 obtém os
participantes de um casamento (?x e ?y), o instante de início do relacionamento (?beg),
calcula o fim do dia do evento (?end), gera nós para o evento app:WeddingDay (?ebn) e o
192
intervalo de tempo de sua ocorrência (?tbn) e, em caso de sucesso, adiciona triplas sobre ?ebn
e ?tbn e particapações evt:playsRole. R3 é análoga e não será explicada.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
# Regra para construir evento WeddingDay: proximo aniversario
# da relacao Marriage
R2:
(?r rdf:type rel:Marriage),
(?x rel:participantIn ?r),
(?y rel:participantIn ?r),
notEqual(?x, ?y),
(?r evt:timeSpan ?t),
(?t time:hasBeginning ?dt)
makeNearestDateTime(?dt, ?beg),
dateSum(?beg, 1, ?end)
makeNamedNode(?ebn, ?r, "/WeddingDay"),
makeNamedNode(?tbn, ?r, "/WeddingDay/Time")
-> (?ebn rdf:type apv:WeddingDay),
(?ebn rdf:type evt:Event),
(?ebn evt:timeSpan ?tbn),
(?tbn rdf:type time:Interval),
(?tbn time:hasBeginning ?beg),
(?tbn time:hasEnd ?end),
(?x evt:playsRole ?ebn),
(?y evt:playsRole ?ebn)
# Regra para construir evento CourtshipDay: proximo aniversario
# da relacao Courtship
R3:
(?r rdf:type rel:Courtship),
(?x rel:participantIn ?r),
(?y rel:participantIn ?r),
notEqual(?x, ?y),
(?r evt:timeSpan ?t),
(?t time:hasBeginning ?dt)
makeNearestDateTime(?dt, ?beg),
dateSum(?beg, 1, ?end)
makeNamedNode(?ebn, ?r, "/CourtshipDay"),
makeNamedNode(?tbn, ?r, "/CourtshipDay/Time")
-> (?ebn rdf:type apv:CourtshipDay),
(?ebn rdf:type evt:Event),
(?ebn evt:timeSpan ?tbn),
(?tbn rdf:type time:Interval),
(?tbn time:hasBeginning ?beg),
(?tbn time:hasEnd ?end),
(?x evt:playsRole ?ebn),
(?y evt:playsRole ?ebn)
O terceiro grupo (c) é representado pela regras R_EG a seguir. Neste grupo, como os
eventos já existem, pois vieram de CDE, basta construir as participações. Assim, todos
193
participam em feriados nacionais (R_EG1), apenas mãe e filho(a) participam do dia das mães
(R_EG2) e apenas casais de namorados participam do dia dos namorados (R_EG3). Isto
conclui o módulo A1.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Regra para relacionar eventos Holiday existentes e
# pessoas (eventos gerais)
R_EG1:
(?p rdf:type foaf:Person),
(?ev rdf:type apv:Holiday),
noValue(?ev, rdf:type, apv:MothersDay)
-> (?p evt:playsRole ?ev)
# Regra para relacionar eventos MothersDay e pessoas cuja
# mae seja conhecida
R_EG2:
(?p1 rel:motherOf ?p2),
(?ev rdf:type apv:MothersDay)
-> (?p1 evt:playsRole ?ev),
(?p2 evt:playsRole ?ev)
# Regra para relacionar eventos ValentinesDay e pessoas
# cujo(a) namorado(a) seja conhecido(a)
R_EG3:
(?p1 rel:courts ?p2),
(?ev rdf:type apv:ValentinesDay)
-> (?p1 evt:playsRole ?ev),
(?p2 evt:playsRole ?ev)
O módulo B1 gera eventos de chegadas de ônibus em pontos de ônibus e para isso é
necessário apenas uma consulta, denominada Qarrival1, que é um CONSTRUCT com SubSELECTs em dois níveis na cláusula WHERE. Ela é apresentada a seguir:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Qarrival1
CONSTRUCT {
?ev a apv:BusArrival , evt:InstantEvent , evt:Event ;
apv:bus ?car ;
apv:busStop ?stop ;
rdfs:label ?label ;
rdfs:comment "Estimated time for the bus arrival"@en ;
evt:atTime ?evtm .
?evtm a time:Instant ;
time:hasDateTime ?dateTime .
?car bus:route ?route .
}
WHERE {
{ SELECT ?car ?stop ?route
(infmod:sumTime(?date, 0, ?est_time) as ?dateTime)
(fn:concat("Onibus <", str(?car),
194
17
"> em direcao ao ponto '",
18
?stopname, "'") as ?label)
19
WHERE {
20
{ # Seleciona onibus e suas próximas paradas e calcula
21
# distancia entre ambos e tempo estimado até chegar
22
SELECT ?stop ?stopname ?route ?car
23
((?dist1 - ?dist2) as ?remaining_dist)
24
((?remaining_dist * (?time / ?dist2)) as ?est_time)
25
WHERE {
26
?rs
a bus:RouteStop ;
27
bus:stop ?stop ;
28
bus:belongsToRoute ?route ;
29
bus:distanceFromOrigin ?dist1 .
30
?car a bus:Bus ;
31
bus:traveledDistance ?dist2 ;
32
bus:traveledTime ?time ;
33
bus:route ?route .
34
?stop bus:name ?stopname .
35
FILTER (?dist1 >= ?dist2 )
36
}
37
}
38
FILTER(?est_time > 15 && ?est_time < 1200)
39
}
40
}
41
BIND (URI(fn:concat(str(?car),
42
"/Stop",
43
afn:substr(str(?stop),
44
infmod:getLastIndexOf("/", str(?stop))),
45
"/Event")) as ?ev)
46
BIND (URI(fn:concat(str(?car),
47
"/Stop",
48
afn:substr(str(?stop),
49
infmod:getLastIndexOf("/", str(?stop))),
50
"/Event/Time")) as ?evtm)
51 }
O SELECT mais interno (linhas 22-35) seleciona ônibus e suas próximas paradas (?car
e ?stop nas linhas 22 e 26-35) e calcula distância entre ambos (?remaining_dist, linha 23) e
tempo estimado até chegar (?est_time, linha 24). O SELECT externo (linhas 14-40) filtra
apenas os resultados cujo tempo estimado esteja entre 15 e 1200 segundos (FILTER na linha
38) e seleciona ônibus, rotas e paradas e constrói colunas ?dateTime e ?label (linhas 14-18). A
primeira retorna o instante de chegada estimado no formato do tipo xsd:dateTime usando a
função infmod:sumTime e, a segunda coluna, cria um texto explicativo. No final do WHERE
mais externo há dois BINDs que constróem nós para os eventos de chegada e para o instante
de tempo que o evento ocorrerá (linhas 41-46). Por fim, o CONSTRUCT cria o grafo com
195
eventos app:BusArrival (linhas 2-11). Esta consulta é configurada para executar em intervalos
de 30 segundos.
O módulo B2 utiliza uma consulta principal ao endpoint BLE, denominada Qrec
(apresentada a seguir), com um SelectQueryParameterBinder adicional para obter as
coordenadas dos usuários (?ulat e ?ulon na linha 19) e os destinos desejados (?uDestName,
linha 33). Como esta consulta secundária retorna várias linhas de resultado (uma para cada
usuário ?u), a quantidade de vezes que a consulta principal será executada depende da
quantidade de usuários na base USNLE.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Qrec
CONSTRUCT {
?u
a foaf:Person .
?stop a bus:Stop .
?route a bus:Route .
?u
app:recommendedBusStop ?pstop .
?pstop a app:BusStopRecommendation ;
app:stop ?stop ;
app:distance ?dist ;
app:route ?route .
}
WHERE {
# Variáveis resultantes da junção:
#
?stop = ponto de onibus proximo da posicao atual do usuario
#
?dist = distancia entre usuario e ?stop
#
?route = rota de onibus que passa em ?stop e no ponto de
#
destino do usuario
{ SELECT ?stop
(geofn:distanceFromDegrees(?lat, ?lon, ?ulat, ?ulon) as ?dist)
WHERE {
?stop a bus:Stop ;
geo:lat ?lat ;
geo:long ?lon .
}
ORDER BY ?dist
LIMIT 3
}
{
?rs bus:stop ?stop ;
bus:nextStop* ?rs2 .
?rs2 bus:stop/bus:name ?stopName ;
bus:belongsToRoute ?route .
FILTER (CONTAINS(LCASE(?stopName), LCASE(?uDestName)))
}
FILTER (?dist < 500)
196
37
BIND (URI(fn:concat(
38
"http://user-bus-contexts.com/resource/BusStopRecommendation/",
39
afn:substr(str(?u), infmod:getLastIndexOf("/", str(?u))),
40
afn:substr(str(?stop), infmod:getLastIndexOf("/", str(?stop)))
41
)) as ?pstop)
42 }
Observe que esta consulta faz um produto cartesiano entre (1) a lista de paradas
(?stop) e distâncias entre cada parada e o usuário (?dist), limitando o resultado às três paradas
mais próximas (linhas 18-27); e (2) a lista de paradas de rota ?rs2 seguintes (bus:nextStop) à
parada de rota de cada ?stop da lista (1) de forma que nome da parada (?stopName) associada
a ?rs2 case com o destino desejado do usuário (?uDestName) (linhas 28-34). O produto
cartesiano é filtrado para manter apenas distâncias menores que 500 metros (linha 35), o que
pode reduzir a quantidade de paradas para dois, um ou até mesmo zero para o usuário em
questão. No final da cláusula WHERE é construído um nó para representar a instância da
recomendação (BIND, linhas 37-41) cujas triplas são definidas na cláusula CONSTRUCT
(linhas 2-10). Esta consulta foi configurada para executar a cada 5 minutos.
O módulo B3 reúne as recomendações de B2 e as chegadas de ônibus de B1 e gera
possíveis participações app:isPassegerOf de usuários nestas chegadas. A consulta a B1
(Qarrivel2) é apenas um SPARQL DESCRIBE das instâncias de app:BusArrival e dos
objetos de suas triplas, enquanto a consulta a B2 (Qrec2) é apenas um DESCRIBE das
instâncias de pessoas e recomendações a elas associadas. Qrec2 executa a cada 5 minutos e
que Qarrival2 a cada 15 segundos. Ambas são mostradas a seguir:
1
2
3
4
5
6
7
8
9
10
11
# Qarrival2
DESCRIBE ?ev ?o
WHERE { ?ev a apv:BusArrival ;
?p ?o . }
# Qrec2
DESCRIBE ?u ?pstop ?o
WHERE {
?u a foaf:Person ;
app:recommendedBusStop ?pstop .
?pstop ?p ?o .
}
A geração das participações é feita com a regra mostrada a seguir. Ela liga eventos
app:BusArrival a usuários (?ev e ?u nas linhas 9-10) usando paradas (?stop, linhas 2 e 6) e
rotas (?route, linhas 4 e 7) existentes tanto nas recomendações (?b, linhas 5-7) quanto nos
eventos (?ev, linhas 1-4).
197
1 (?ev rdf:type apv:BusArrival),
2
(?ev apv:busStop ?stop),
3
(?ev apv:bus ?bus),
4
(?bus bus:route ?route),
5 (?u app:recommendedBusStop ?b),
6
(?b app:stop ?stop),
7
(?b app:route ?route)
8 ->
9
(?u apv:isPassengerOf ?ev),
10
(?u evt:playsRole ?ev)
O módulo NEvt fica no topo de rede pois é responsável por reunir as participações em
A1 e B3 e gerar notificações. É composto por quatro consultas a três endpoints: A1, B3 e
BLE. Observando a Figura 30 verifica-se que as consultas feitas a A1 e B3 são iguais. Para
não tornar as coisas mais complexas, elas pegam o grafo inteiro dos respectivos módulos
usando consultas CONSTRUCT. As demais consultas são Qlow e Qhigh que pegam dados de
baixa e alta taxa de atualização. Qlow descreve linhas, paradas, rotas e paradas de rotas de
BLE, e Qhigh descreve os ônibus. Quantos aos intervalos, Qall de A1 executa a cada 10
minutos, Qall de B3 a cada 10 segundos, Qlow a cada 10 minutos e Qhigh a cada 10
segundos.
NEvt também utiliza as regras listadas a seguir. O antecedente de R1 seleciona eventos
que não sejam aniversários (linha 3), pessoas que participem destes eventos (linha 4) e data de
início destes eventos (linha 5); verifica se esta data de início está no intervalo entre 1 e 180
dias contados da data atual (linha 6) e constrói um nó de notificação (associa um evento a uma
pessoa, portanto, o URI da notificação deve considerar ambos). O consequente de R1
instancia o nó (app:Notification na linha 9), define evento associado a esta notificação (linha
10), o seu alvo (linha 11) e quantos dias restam para o evento ocorrer (linha 12). Quanto à
linha 6, note que os built-ins curTime, dateDiff, le e ge são usados para representar a
expressao "0 <= ev.beginning - curTime <= 180 dias". A regra R2 é similar, mas para o
evento
aniversário
e,
portanto,
a
participação
é
representada
pelo
predicado
app:isBirthdayPersonsFriendOf. Por fim, R3 é similar, mas para eventos de ônibus que
precisam modificar a comparação de tempo (linha 34) para cálculo em segundos.
1
2
3
4
5
6
7
# Cria notificacoes para eventos proximos (exceto aniversarios)
R1:
(?ev rdf:type evt:Event), noValue(?ev, rdf:type, apv:Birthday),
(?p rdf:type foaf:Person), (?p evt:playsRole ?ev),
(?ev evt:timeSpan ?t), (?t time:hasBeginning ?beg),
curTime(?tm), dateDiff(?beg, ?tm, ?d), le(?d, 180), ge(?d, 0),
localname(?p, ?pln),
198
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
makeNamedNode(?ntf, ?ev, "/Notification/", ?pln, "/", ?beg)
-> (?ntf rdf:type evt:Notification),
(?ntf evt:event ?ev),
(?ntf evt:target ?p),
(?ntf evt:remainingDays ?d)
# Birthday: uma notificacao para cada amigo de aniversariante
# (aniversariante nao precisa ser notificado)
R2:
(?ev rdf:type apv:Birthday),
(?friend rdf:type foaf:Person),
(?friend apv:isBirthdayPersonsFriendOf ?ev),
(?ev evt:timeSpan ?t), (?t time:hasBeginning ?beg),
curTime(?tm), dateDiff(?beg, ?tm, ?d), le(?d, 300), ge(?d, 0),
localname(?friend, ?fln),
makeNamedNode(?ntf, ?ev, "/Notification/", ?fln, "/", ?beg)
-> (?ntf rdf:type evt:Notification),
(?ntf evt:event ?ev),
(?ntf evt:target ?friend),
(?ntf evt:remainingDays ?d)
# Notificacao sobre eventos de chegada de onibus
R3:
(?ev rdf:type evt:Event)
(?p rdf:type foaf:Person), (?p evt:playsRole ?ev),
(?ev evt:atTime ?t), (?t time:hasDateTime ?beg),
curTime(?tm), timeDiff(?beg, ?tm, ?d), le(?d, 1800), ge(?d, 0),
localname(?p, ?pln),
makeNamedNode(?ntf, ?ev, "/Notification/", ?pln, "/", ?beg)
-> (?ntf rdf:type evt:Notification),
(?ntf evt:event ?ev),
(?ntf evt:target ?p),
(?ntf evt:remainingTime ?d)
Aluno Teste Piloto 1
Aluno Teste Piloto 2
Aluno Pesquisa de Tese 1
Aluno Pesquisa de Tese 2
Aluno da Disciplina 1
Aluno da Disciplina 2
Aluno da Disciplina 3
Aluno da Disciplina 4
Aluno da Disciplina 5
Aluno da Disciplina 6
Aluno da Disciplina 7
Aluno da Disciplina 8
Aluno da Disciplina 9
Aluno da Disciplina 10
Aluno da Disciplina 11
Aluno da Disciplina 12
Aluno / Critérios
2
3
3
3
3
3
3
3
2
1
2
2
2
3
2
1
Configuração
2
2
3
3
1
1
3
1
3
2
2
3
2
2
2
2
Funcionamento
1
2
3
2
1
1
2
1
1
1
1
2
1
1
1
1
Domínio
2
3
1
2
2
2
2
2
3
3
1
1
2
3
2
3
Tecnologias
2
3
2
2
1
2
2
2
2
2
1
1
2
3
2
2
Lógica
2
3
3
2
1
2
3
2
1
2
2
2
2
2
2
3
SPARQL
3
1
2
3
1
1
2
1
1
1
1
1
0
2
1
1
SQL
3
2
3
3
2
2
2
2
3
3
3
3
1
2
2
3
URI e RDF
3
1
2
3
1
1
3
2
1
2
0
1
0
2
1
0
Grafos
2
3
2
3
1
2
2
2
1
2
1
1
0
1
1
1
Web Services
3
1
1
3
1
1
1
2
2
2
1
0
0
1
1
1
XML
3
2
2
3
2
1
2
3
2
3
0
1
0
2
2
2
Web (HTTP e HTML)
3
2
2
3
3
2
3
3
3
3
2
1
0
2
2
3
Programação
3
3
3
3
3
2
2
3
3
3
2
3
1
2
2
3
Dificuldade no
experimento (0-3)
Execução
Nível de conhecimento (0-3)
A1 A2 B1 B2 B3 A2x
4
4
4
3
3
2
4
4
4
4
3
3
4
3
4
3
4
3
2
4
4
4
4
3
3
3
4
2
2
2
1
2
2
2
1
1
1
2
2
2
2
1
2
4
4
4
4
1
1
3
3
3
3
2
2
3
4
4
4
3
0
2
2
2
2
1
1
2
2
2
2
2
0
2
2
2
2
3
2
4
4
4
3
2
1
1
1
1
2
2
2
3
3
3
3
3
Tempo (0-4)
199
Apêndice F – Questionário passado aos alunos e respostas na íntegra
O significado dos números é definido na seção 5.2 (página 135).
200
Aluno
Aluno Teste Piloto 1
Aluno Teste Piloto 2
Aluno Pesquisa de Tese 1
Aluno Pesquisa de Tese 2
Aluno da Disciplina 1
Aluno da Disciplina 2
Aluno da Disciplina 3
Aluno da Disciplina 4
Aluno da Disciplina 5
Aluno da Disciplina 6
Aluno da Disciplina 7
Aluno da Disciplina 8
Aluno da Disciplina 9
Aluno da Disciplina 10
Aluno da Disciplina 11
Aluno da Disciplina 12
Considerando a etapa que você demorou mais, a que você atribui a
demora?
Entendimento sobre o domínio e sobre a tecnologia. Uma vez compreendido as
outras etapas ficaram mais fáceis.
A demora se deu por ser a primeira etapa prática de aplicação. A partir deste
momento, os conceitos, sintaxe e aplicação ficaram claros e as outras etapas
foram concluídas mais rapidamente.
Entendimento de como funcionam as regras. Verificação do modelo para
formular regras e consutas.
A etapa que mais demorei foi o A2 estendido (28 min).
Atribuo 2 motivos à demora:
1- Considero a etapa do experimento com maior nível de dificuldade.
2- Tive dúvidas no entendimento da regra a ser adicionada em r3 (devido à
utilização da superclasse evt:Event e da superpropriedade evt:playsRole, em
vez da classe apv:BusArrival e da propriedade apv:isPassengerOf).
As etapas que demorei mais foram as primeiras porque estava menos
familiarizada com a atividade e acabava não verificando endpoint e
sparqlserver antes de iniciar. Além disso, não tinha entendido de início que para
uma etapa executar dependia da etapa anterior estar executando.
Eu fiquei um pouco insegura durante o exercício porque eu não consegui
visualizar as classes do módulo B1. Por causa disso, eu parei o exercício após
a execução do módulo B3. Como eu ainda não tinha feito o A2 estendido e não
tinha usado todas consultas e regras do arquivo "ajuda.txt", achei que estava
fazendo algumas coisa errada.
A etapa A1, pois a porta 40000 deixou de funcionar e demorei para descobrir o
que estava acontecendo. Acabei usando a porta 44000.
Não tinha lido os txt de ajuda
Configuração do ambiente não estava OK e falta de atenção para deixar ops
endpoints mapeados (portas), executando da forma correta e síncrona.
Ficou demorado porque tive que entender o que realmente era feito para fazer
funcionar.
A primeira etapa para mim foi a mais complicado por não conhecer bem o
experimento.
Apos avançar nas etapas pude entender melhor a proposta e tive que voltar
para rever os exercicios anterios. Isto comprometeu a medição do tempo. Alem
disso o servidor web começou a travar e não pude fazer mais testes para
entender melhor a aplicação.
Demora devido a nao entender as msgs de erro que sao emitidas após a
execuçao do XML, apesar de perceber depois que os erros eram bobos. Como
só consegui resolver o erro "bobo" do B3 no ultimo dia de entrega, nao consegui
evoluir para tentar estender e testar o "A2 estendido", porque minhas execuções
pararam no B1, sem acesso a http://expedit.dyndns.info:3030/sparql . Ainda
tentarei resolver e enviar fora do prazo.
Na etapa A1, demorei a entender que as consultas já estavam feita, era só
copiar e colar. Mas isso foi bom, porque me forçou a pensar um pouco. Nas
outros houve entendimento mais superficial.
Na etapa A2 estendido, demorei mais para entender as modificações
necessárias.
A minha demora é diretamente proporcional ao meu desconhecimento destas
tecnologias, ou seja tive de ler e reler o material para entender como as
“coisas” se conectavam.
Complexidade da etapa A2 estendido, pois havia necessidade de criar uma
consulta que não estava contemplada na no arquivo ajuda.txt. Além disso, os
slides não tinham nenhuma clareza sobre o que fazer nessa etapa.
201
Aluno
Aluno Teste Piloto 1
Aluno Teste Piloto 2
Aluno Pesquisa de Tese 1
Aluno Pesquisa de Tese 2
Aluno da Disciplina 1
Aluno da Disciplina 2
Aluno da Disciplina 3
O Módulo de Inferência tem o objetivo de fornecer um endpoint de dados
derivados para outros consumidores de forma que consultas, ontologias
e regras possam ser reutilizadas de forma transparente, ou seja, não
precisem ser reescritas toda vez que forem necessárias. Você acha que o
objetivo foi atendido? Identifique dificuldades encontradas, pontos
positivos e negativos.
O objetivo foi entendido, entretanto a construção de regras depende não
somente de conhecimento sobre a tecnologia como também sobre o domínio,
seria necessário gastar algum tempo para ter domínio sobre a ferramenta e
sobre o que é possível fazer.
No meu conhecimento limitado sobre as tecnologias envolvidas (webservices,
uri, RDF e SPARQL) acredito que o objetivo tenha sido atendido. Depois de
configurado e executado, o módulo de inferência certamente é capaz de
simplificar consultas para o usuário final, que de outra forma seriam complexas.
As inferências também permitem que um modelo geral seja extendido
automaticamente para casos mais específicos, sem retrabalho. Houve uma
dificuldade inicial em entender a sintaxe, mas depois de apenas um exemplo já
foi muito fácil prosseguir nas etapas. Os casos de uso propostos foram
apropriados e certamente ilustraram a importância da abordagem. Visto minha
pouca experiência com trabalhos relacionados ao tema, fica difícil apontar
pontos positivos e negativos comparativos, mas a facilidade de utilização e
resultado sugerem que a abordagem é funcional e efetiva.
Sim. Existe a dificuldade inicial de entender e analisar os dados gerados. Porém
o objetivo é atendido tornando a experiencia cada vez mais facil com a
reutilização. Portanto existe a dificuldade inicial, porém o objetivo é atendido
permitindo a reutilização.
Acho que o objetivo foi atendido. O fácil entendimento, configuração e
execução do XML são pontos positivos. Encontrei dificuldade na parte de
definição das regras JENA, por falta de experiência no assunto, dificuldade esta
que foi diminuindo durante a execução das etapas do experimento.
Acho que foram atendidos sim. Também achei a execução dos módulos e a
visualização bem simples e intuitiva. A parte mais crítica, na minha opinião, foi
montar os arquivos xml, mas acredito que foi por falta de conhecimento meu,
principalmente em turtle, rdf, jena, devido às configurações e termos que
deveríamos saber do que pela sintaxe em si. Não entendi muito bem como os
"endpoints" estão interligados.
Sim, acho que o Módulo de Inferência pode ajudar na reutilização de consultas
e regras de forma transparente.
Dificuldades encontradas: - Dúvidas na manipulação do arquivo xml.
Pontos Positivos: - Reutilização de informações de forma transparente,
permitindo que várias aplicações consultem a mesma informação.
Pontos Negativos: - As pessoas precisam ter conhecimento de RDF e SPARQL
para que possam utilizar esses dados e manipular os arquivos. Acho que no
início a curva de aprendizado é grande.
Sim, acho que o objetivo foi atingido.
Pontos positivos:
- o módulo permite uma configuração bastante detalhada e flexível
- não tenho como avaliar com precisão, mas aparentemente tem boa
performance, é rápido
- portabilidade, pois está implementado em Java
- permite a criação de aplicações que utilizam as tecnologias da Web
Semântica com os benefícios da programação modular
Ponto negativo:
- para criar uma aplicação é necessário ter conhecimentos de SPARQL (alto),
RDF (alto), regras (alto), grafos (médio), modelagem conceitual/ontologia
(médio)
202
Aluno da Disciplina 4
Aluno da Disciplina 5
Aluno da Disciplina 6
Aluno da Disciplina 7
Aluno da Disciplina 8
Aluno da Disciplina 9
Aluno da Disciplina 10
Aluno da Disciplina 11
Acredito que o objetivo foi atingido. Dentro do exercício proposto a única coisa
ruim é ter que ficar executando diversos programas, mas acredito que em um
cenário real estes endpoints sejam somente URLs diferentes em um mesmo
sistema.
Sim, foi atendido. Com a "topologia" distribuída e as execuções de forma
modular foi fácil enxergar a reutilização que o Framework fornece.
O Objetivo foi atingido. Qualquer mudança ou inserção basta alterar o xml e
recarregar.
A grande dificuldade e aprender a estrutura da linguagem. A segunda seria
identificar a estrutura de dados na aplicação. Aprender a construir as consultas
e regras para mim foi complicado. Pontos possitivos: O material está bem
completo sobre o assunto . O exercicio de completar consultas e regras é muito
legal aprendi bastante sobre o tema.
Sim, parece que o objetivo foi atendido, mas não tenho grande experiencia
sobre o tema o que me dificulta avaliar de uma forma mais crítica e contribuir
mais para este experimento.
Acho que foi atingido. As dificuldades encontrados já foram mencionadas nas
respostas acima.
Apesar de ainda não compreender a profundidade do problema, acho que o
módulo cumpriu sua função. Mas acho que o passo fundamental seria uma
interface gráfica para escrever as regras e configurar o xml, para que a
ferramenta possa ser úportil a mais gente. Mesmo que isso prejudique a
flexibilidade, aumentaria em muito a utilidade do módulo.
Achei uma ótima ideia a reutilização de dados gerados. A minha dificuldade em
resolver a proposta de unir os arquivos em um só que foi questionada. Acho
que sim, como qualquer sistema deve ser testado e retestado em situação real.
Sim, acredito que o objetivo foi atendido, pois esse endpoint pode ser utilizado
por outras aplicações, ou até mesmo para versões da mesma aplicação para
outras plataformas, como plataformas de Smartphones por exemplo.
Aluno da Disciplina 12
A maior dificuldade foi entender o exercício por intermédio dos slides, que
repito, não estavam nem um pouco claros. Depois de entendido o exercício, foi
fácil adequar as consultas e regras do ajuda.txt à aplicação.
203
Aluno
Aluno Pesquisa de Tese 1
Aluno Pesquisa de Tese 2
Aluno da Disciplina 1
Aluno da Disciplina 2
Aluno da Disciplina 3
Aluno da Disciplina 4
Aluno da Disciplina 5
Aluno da Disciplina 6
Aluno da Disciplina 7
Aluno da Disciplina 8
Aluno da Disciplina 9
Aluno da Disciplina 10
Aluno da Disciplina 11
Aluno da Disciplina 12
Você considera que a documentação (apresentação em PDF) foi suficiente
para o entendimento do Módulo de Inferência e do domínio da aplicação?
Comente sua resposta em poucas palavras, falando sobre os pontos
positivos e/ou negativos que você tenha identificado.
Sim. A documentação mostra uma visão geral das tecnologias mostrando
exemplos simples e mais avançados de cada uma. Talvez para uma pessoa
que não tenha nenhum conhecimento sobre sparql, rdf, owl seja necessária uma
documentação mais explicativa que mostre o que é cada tecnologia e como
funciona.
Considero que a documentação foi suficiente. Há uma apresentação clara e
concisa do fundamento teórico, da arquitetura do Módulo de Inferência e dos
cenários/etapas da experimentação.
O domínio da aplicação ficou bem claro pela documentação, porém acho que o
Módulo de Inferência poderia ser um pouco mais explicado. Depois dos
exercícios você tem uma noção geral do módulo, mas eu não acredito que
tenha entendido ele por completo. Acredito que pra se entender por completo
tem que ter um conhecimento mais sólido do que eu tenho em rdf, turtle, owl e
afins.
Acho que a documentação está bem completa.
Pontos positivos: - Auxilia a realização das tarefas e contextualiza o exercício; e
- Explica a estrutura e os componentes do Módulo de Inferência.
Pontos negativos: - A existência de muitos conceitos associados ao módulo de
inferência dificultou um pouco o entendimento do exercício.
A apresentação está muito boa. Como não tinha utilizados raciocinadores, a
parte das regras foi bastante complexa para mim. Talvez poderia ter mais
exemplos de regras. Havia também muitos modelos conceituais e acabou
ficando um pouco difícil saber quais eram meros exemplos e quais eram de fato
modelos das bases RDF.
Acredito que para uma pessoa que já conhece essas tecnologias fica fácil de
usar. Porém leigos devem encontrar dificuldades. Não ficou muito claro o
objetivo de cada etapa e o domínio me pareceu muito complexo para um "Hello
World"
A apresentação ficou muito boa, porém talvez fosse melhor abrir um dos
arquivos XML mostrando onde cada coisa "acontece" (acesso às base,
endpoints, consultas, regras, etc).
Em relação aos conceitos a apresentação foi suficiente.
O material é muito bom. Aprendi bastante sobre o assunto. A sugestão seria a
inclusão de referencias bibliográficas sobre alguns temas trabalhados na
apresentação.
Para uma pessoa que não tem familiaridade com RDF, LOD, etc. esta
documentação não seria suficente. Na verdade seria necessário um
treinamento.
Precise ler, reler, ler, reler, mas ao passo que testava os modulos a leitura ia
tornando-se melhor compreensivel. Acredito que isto se deva ao fato da minha
quase nula experiencia com os temas.
Sim, a documentação está bem completa. Percebi duas coisas: em alguns
grafos, onde se lê app: deveria estar apv: ; além disso, no slide 134, o primeiro
users deve ser trocador por stop.
O material foi suficiente sim, mas como o domínio é relativamente complexo,
os diagramas foram fundamentais.
Não. A parte de conteúdo sobre a disciplina estava claro. Porém, os exercícios
não estavam claros nos slides. Os slides sobre o exercicio estavam muito
confusos, não entendi o que fazer, mesmo lendo diversas vezes. Precisei
perguntar pessoalmente para entender o que tinha que fazer no trabalho. Nos
slides não está claro que temos que utilizar consultas e regras do arquivo
ajuda.txt.