inferência situacional em sistemas baseados em informação de … · sibilita ainda uma fácil...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Inferência Situacional em SistemasBaseados em Informação de Contexto

Luís Miguel Marques Pereira Rocha

Mestrado Integrado em Engenharia Informática e Computação

Orientador: João António Correia Lopes (Professor Doutor)

Responsável de Acompanhamento: Telma Mota (Enga.)

13 de Julho de 2011

Inferência Situacional em Sistemas Baseados emInformação de Contexto

Luís Miguel Marques Pereira Rocha

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo júri:

Presidente: Luís Filipe Pinto de Almeida Teixeira (Doutor)

Vogal Externo: Maria Benedita Campos Neves Malheiro (Doutor)

Orientador: João António Correia Lopes (Doutor)

13 de Julho de 2011

Resumo

Desde o início da década de 90 que diversas entidades começaram a recolher de in-formação sobre os utilizadores para posteriormente extrair informação relevante que lhespermita melhorar o seu negócio e a sua relação com os seus utilizadores. Começou a ser,assim, possível fornecer produtos e serviços que têm em conta o contexto e preferênciasdos seus utilizadores a cada momento. As tecnologias estão a evoluir cada vez mais nosentido de, num futuro próximo, qualquer pessoa estar quase permanentemente ligada àsredes de informação. A recente expansão dos dispositivos móveis e redes sem fios veiopotenciar esta realidade, sendo hoje muito mais fácil recolher uma enorme quantidade dedados sobre o contexto de cada pessoa.A PT Inovação pretende explorar estes conceitos e desenvolver um modelo de negóciosbaseado em context-as-a-service (CXaaS). Para este efeito, já se encontra a desenvolveruma plataforma que permite definir bibliotecas que facilitam a comunicação entre diversasaplicações de um sistema, nomeadamente o envio da diversa informação que é recolhidasobre os seus utilizadores. No entanto, a informação que chega da maioria destas apli-cações não é suficientemente significativa para prestar serviços dirigidos ao contexto emque cada pessoa se encontra.O objectivo do trabalho aqui descrito passou por desenvolver um novo tipo de compo-nente no qual se pudesse centrar o processamento da informação de mais baixo nível queé actualmente recolhida, de forma a inferir nova informação de mais alto nível. Foram es-tudados alguns sistemas de gestão de contexto existentes e os tipos de abordagem usadosna representação e inferência sobre a informação do sistema. Foram também estudadasas principais abordagens de agregação de posições geográficas e métodos de classificaçãode locais.O componente desenvolvido foi implementado recorrendo a diversas tecnologias base-adas em Java e é constituídos por 4 módulos: um componente central, um módulo deaprendizagem computacional, um motor de regras baseado em Jess e uma interface ORM(Object-Relational Mapping) com uma base de dados relacional MySQL. O sistema pos-sibilita ainda uma fácil integração de qualquer tipo de informação de contexto, tanto sobreos tipos actualmente definidos como qualquer outro que possa vir a ser definido no futuro.Possibilita também a inferência de informação de mais alto nível através de um conjuntode regras que podem ser definidas à medida das soluções pretendidas.Durante o período em que decorreu este trabalho, o sistema desenvolvido foi testado deforma a recolher posições GNSS (Global Navigation Satellite Systems) obtidas a partir deuma aplicação desenvolvida para dispositivos com plataforma Android e posteriormenteprocessar esses dados de forma a determinar quais o locais mais frequentes no dia-a-diade cada utilizador. Estes locais são classificados segundo um conjunto de categorias pré-definidas assim como em termos da importância relativa para o utilizador.

i

As avaliações efectuadas sobre o sistema mostram que uma abordagem de agregação in-cremental sobre os dados permite ao sistema ir identificando eficientemente os diversoslocais à medida que novos dados vão sendo recolhidos. Esta abordagem garante tambémum bom tempo de resposta por parte do novo componente desenvolvido. Os métodos declassificação baseados na API do Google Places, no entanto, demonstram não ser mini-mamente fiáveis para os objectivos propostos.

ii

Abstract

Since the early 90’s, many entities started to collect data about their users in order toextract new information that might be usefull to improve their business and client rela-tionship. The goal is to provide products and services that take into account the contextand preferences of its users at a given moment. Tecnology is evolving in such a way thatin a near future anyone may be permanently connected to the information networks. Therecent mobile device and wireless networks expansion provided many new possibilites togather and distribute this kind of data, making it possible to collect a massive number ofcontext data in much less time.PT inovação wants to explore this concept, creating a business model based in Context-as-a-Service (CXaaS). In order to do this there is a framework currently under developmentthat allows to specify a collection of libraries to assist the comunication between diferentapplications in a context-based system. However, most of the retrived data is not signifi-cant enough for the purpose of creating context-oriented services.The main goal of this work included the development of another kind of provider, in whichthe system could centralize most of the data processing in order to deduce new high-levelinformation from the low-level information that is being collected. In order to accom-plish this goal, a studywas done in the area of existent context management systems anddifferent approaches for context representation and inference were analysed. Also, themost common geografic clustering algorithms and location classification methods werestudied.The developed component was mostly implemented using available Java technologies andis composed by 4 modules: a central component, a machine learning framework, a ruleengine based in Jess and an ORM (Object-Relational Mapping) interface with a MySQLrelational database. The system makes it possible to integrate any kind of context infor-mation that may be specified in an easy and quick way and also uses a set of defined rulesto produce high-level information from the low-level collected data.This system was tested for gathering GNSS (Global Navigation Satellite Systems) in-formation from an Android application and process that data afterwards in order to findwhich are the most significant locations in the user daily routine. These locations are laterclassified according to a specified set of categories, as well as in terms of the importancethat these places may have to each person.The evaluation done to the system shows that it is possible to implement an incremen-tal clustering approach over the gathered data in order to efficiently identify the mostrelevant locations in the daily routine of the users. This apprach also grants a system res-ponse under a very acceptable time. The classification methods based on Google PlacesAPI queries, however, did not show reliable results for the proposed goals.

iii

Agradecimentos

Ao meu orientador, o Professor João Correia Lopes, pelo acompanhamento e paci-ência durante este trabalho, mesmo — e principalmente — quando tudo parecia incerto.Também a todos os professores que tive o privilégio de “apanhar” ao longo do meu per-curso académico, pelos conhecimentos transmitidos e rigor exigido.

Aos meus os colegas do IEX1, pelo acolhimento na PT Inovação e ajuda prestada aolongo deste trabalho.

A todos os meus amigos, por todos os momentos passados ao longo de intermináveisdias e noites nos últimos 5 anos, por terem feito da FEUP, mais que uma faculdade, umasegunda casa. Por me terem ajudado a crescer de uma forma que nunca poderia imaginar.

À minha família, em particular aos meus pais, pela educação, suporte e dedicação.Sem eles nunca poderia ter chegado aqui.

Luís Rocha

v

“Somos o que fazemos, mas somos, principalmente, o que fazemos para mudar o quesomos”

Eduardo Galeano

vii

Conteúdo

1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Enquadramento e Motivação . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Framework de Contexto da PT Inovação 72.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Modelos de Descrição de Informação de Contexto . . . . . . . . . . . . . 82.3 Fontes de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Fornecedores de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Mediador de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Consumidores de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Revisão Bibliográfica 133.1 Sistema Baseados em Informação de Contexto . . . . . . . . . . . . . . . 13

3.1.1 Sistemas Baseados em Regras . . . . . . . . . . . . . . . . . . . 143.1.2 Sistemas Baseados em Ontologias . . . . . . . . . . . . . . . . . 153.1.3 Sistemas Baseados em Casos . . . . . . . . . . . . . . . . . . . . 16

3.2 Aprendizagem de Locais Significativos . . . . . . . . . . . . . . . . . . 183.2.1 Identificação de Locais Significativos . . . . . . . . . . . . . . . 183.2.2 Classificação de Locais Significativos . . . . . . . . . . . . . . . 24

3.3 Reconhecimento de Actividades . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Reconhecimento por Inferência Lógica . . . . . . . . . . . . . . 263.3.2 Reconhecimento por Aprendizagem Computacional . . . . . . . 26

3.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Especificação da Solução 314.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Requisitos de Implementação . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1 Definição dos Dados de Contexto . . . . . . . . . . . . . . . . . 324.2.2 Inferência de Contexto . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Recolha e Publicação da Informação . . . . . . . . . . . . . . . . 334.2.4 Caso de Estudo: Informação Situacional . . . . . . . . . . . . . . 33

4.3 Desenho do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.1 Arquitectura Física . . . . . . . . . . . . . . . . . . . . . . . . . 35

ix

CONTEÚDO

4.3.2 Arquitectura Lógica . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Publicação e Armazenamento de Dados 395.1 Publicador de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Arquitectura e Funcionamento Geral . . . . . . . . . . . . . . . . 405.1.2 Informação de Contexto Publicada . . . . . . . . . . . . . . . . . 40

5.2 Armazém de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.1 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2 Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2.3 Motor de Armazenamento . . . . . . . . . . . . . . . . . . . . . 505.2.4 Índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.5 Mapeamento de Objectos Java . . . . . . . . . . . . . . . . . . . 51

5.3 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Inferência de Contexto 556.1 Componente Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2 Módulo de Inferência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.1 Motor de Regras . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.2 Memória de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . 586.2.3 Ficheiro de Regras . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.3 Adaptabilidade do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 596.4 Análise de Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . 606.5 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Aprendizagem de Locais Significativos 637.1 Identificação de Locais Significativos . . . . . . . . . . . . . . . . . . . 63

7.1.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.1.2 Algoritmo IncDJ-Cluster . . . . . . . . . . . . . . . . . . . . . . 647.1.3 Pré e Pós-Processamento . . . . . . . . . . . . . . . . . . . . . . 657.1.4 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.2 Classificação de Locais . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2.1 Casa e Local de Trabalho . . . . . . . . . . . . . . . . . . . . . . 757.2.2 Outros Locais Relevantes . . . . . . . . . . . . . . . . . . . . . . 757.2.3 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.3 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8 Conclusão 798.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Referências 81

A Modelos de Informação Inferida 87A.1 Ruído, Luminosidade e Movimento . . . . . . . . . . . . . . . . . . . . 87A.2 Locais e Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

x

CONTEÚDO

B Base de Dados 91B.1 Índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

C Regras de Inferência 93C.1 Definição de Regras de Inferência . . . . . . . . . . . . . . . . . . . . . 93

xi

CONTEÚDO

xii

Lista de Figuras

2.1 Diagrama de sequência: fluxo típico da informação na framework de ges-tão de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Exemplo de uma árvore Publish-Subscribe . . . . . . . . . . . . . . . . . 12

3.1 Arquitectura do motor de regras no sistema ec(h)o . . . . . . . . . . . . . 143.2 Inferência de contexto no sistema de Goix et al. . . . . . . . . . . . . . . 153.3 Taxonomia usada na ontologia do sistema Mobilife . . . . . . . . . . . . 173.4 Visão geral do processo em CBR . . . . . . . . . . . . . . . . . . . . . . 173.5 Agregação baseada em tempo num espaço bidimencional [KWSB05] . . 203.6 Conceitos básicos do algoritmo DBSCAN . . . . . . . . . . . . . . . . . 213.7 Agregação através do algoritmo DJ-Cluster . . . . . . . . . . . . . . . . 223.8 Visão geral sobre o algoritmo BeaconPrint . . . . . . . . . . . . . . . . . 233.9 Árvore induzida através do algorimto C4.5 no projecto UPCASE . . . . . 27

4.1 Diagrama de sequência: comunicação entre o novo fornecedor e o mediador 344.2 Diagrama de sequência: comunicação entre o novo fornecedor e um con-

sumidor de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Diagrama de distribuição do sistema implementado . . . . . . . . . . . . 374.4 Diagrama de pacotes do fornecedor inteligente . . . . . . . . . . . . . . . 37

5.1 Modelo da Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . 485.2 Diagrama de classes do ContextDatabase . . . . . . . . . . . . . . . . . 51

6.1 Diagrama de sequência do SmartProvider . . . . . . . . . . . . . . . . . 576.2 Artefactos e dependências entre módulos do sistema . . . . . . . . . . . . 596.3 Tempos de execução do Fornecedor Inteligente . . . . . . . . . . . . . . 60

7.1 Gráfico do tempo de execução do algoritmo IncDJ-Cluster para sucessivasactualizações com Eps=10 e MinPts=5 . . . . . . . . . . . . . . . . . . . 70

7.2 Gráfico do tempo de execução do algoritmo IncDJ-Cluster para sucessivasactualizações com Eps=50 e MinPts=5 . . . . . . . . . . . . . . . . . . . 70

7.3 Número de grupos identificados para diferentes combinações de Eps eMinPts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.4 Gráfico do valor da cobertura para variações nos parâmetros Eps e MinPts 727.5 Gráfico do valor da precisão para variações nos parâmetros Eps e MinPts 727.6 Gráfico do valor do F1-Score para variações nos parâmetros Eps e MinPts 737.7 Gráfico da análise do algoritmo para variações de MinVisits quando Eps=50

e MinPts=5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

xiii

LISTA DE FIGURAS

7.8 Gráfico da análise do algoritmo para variações de MinDuration quandoEps=50 e MinPts=5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

xiv

Lista de Tabelas

5.1 Informação de contexto recolhida pela aplicação para Android . . . . . . 41

7.1 Número de dados de contexto utilizados durante a fase de avaliações . . . 687.2 Número de locais marcados pelo utilizador por categoria e importância . . 697.3 Categorias de locais e correspondentes expressões da API Google Places . 767.4 Resultados dos testes de classificação de locais . . . . . . . . . . . . . . 77

B.1 Tabela de índices da base de dados . . . . . . . . . . . . . . . . . . . . . 92

xv

LISTA DE TABELAS

xvi

Abreviaturas e Símbolos

API Application Programming InterfaceCBR Case-Based ReasoningDBN Dynamic Bayesian NetworkDBSCAN Density-Based Spatial Clustering of Applications with NoiseDJ-Cluster Density-Joinable ClusterDL Description LogicDTD Document Type DefinitionEJB Enterprise JavaBeansGIS Geographic Information SystemGPL GNU Public LicenceGPS Global Position SystemGNSS Global Navigation Satellite SystemsGSM Global System for Mobile CommunicationsHTTP Hypertext Transfer ProtocolIETF Internet Engineering Task ForceIQ Info-QueryJessML Jess Markup LanguageJID Jabber IdentificationJSON JavaScript Object NotationJVM Java Virtual Machinek-NN k-Nearest NeighbourLAR Location-based Activity RecognitionMOM Message-Oriented MiddlewareORM Object/Relational MappingOWL Web Ontology LanguagePHP PHP: Hypertext PreprocessorPOJO Plain Old Java ObjectPT Portugal TelecomPubSub Publish-SubscribeRD Resource DiscoveryRDF Resource Description FrameworkRDQL RDF Data Query LanguageRFC Request For CommentsRuleML Rule Markup LanguageSAR Segmentation-based Activity RecognitionSOAP Simple Object Access ProtocolSOCAM Service-oriented Context-Aware Middleware

xvii

ABREVIATURAS E SÍMBOLOS

SP Situation ProviderSSID Service Set IdentifierSVM Support Vector MachineUE União EuropeiaXEP XMPP Extension ProtocolXML Extensible Markup LanguageXMPP Extensible Messaging and Presence ProtocolXSB Extended Stony BrookXSD XML Schema DescriptionXSLT Extensible Stylesheet Language Transformations

xviii

Capítulo 1

Introdução

Neste capítulo são descritos, em primeiro lugar, o contexto e enquadramento destetrabalho, seguindo-se a apresentação de alguns dos conceitos mais relevantes assim comoa motivação e os objectivos. Por fim, é apresentada a estrutura desta dissertação.

1.1 Contexto

Nos últimos anos verificou-se uma grande revolução na forma de desenvolver Soft-ware e na oferta de serviços. O mercado exige cada vez mais dinamismo por parte dasorganizações, pelo que estas procuram cada vez mais distinguir os seus produtos e servi-ços, orientando-os cada vez mais de acordo com as necessidades de cada utilizador. Nestesentido, as áreas da Interacção Humano-Computador e Data Mining têm ganho uma cres-cente importância e muitos estudos se têm feito com o objectivo de procurar determinar aforma como as pessoas interagem com as aplicações e o que preferem.É neste âmbito que surge um novo conceito de context-as-a-service (CxaaS), em quese procura adaptar os serviços oferecidos por um determinado sistema, tendo em contaaquilo que o utilizador prefere e qual o contexto em que este se encontra. Estes novostipos de serviços são também designados por smart services.O conceito de informação de contexto não se encontra exactamente bem definido nestaárea e vários significados ligeiramente diferentes têm sido usados por diversos investiga-dores [Dey01]. No âmbito desta dissertação, o termo informação de contexto é usado paradescrever qualquer tipo de dados relacionados com o utilizador e as actividades que estese encontra a realizar num dado momento. Este tipo de informação abrange dados taiscomo a identidade do utilizador, a sua localização, pessoas ou outras entidades próximasou mesmo informação do terminal que está a utilizar. Outro conceito importante é o desituação ou informação situacional, que representa um nível mais abstracto de contexto,

1

Introdução

obtido a partir dos dados de mais baixo nível. Exemplos de informação situacional in-cluem informação sobre o estado do utilizador, tais como se este se encontra a dormir, atrabalhar, em viagem, etc.O conceito de aplicações baseadas em contexto (context-awareness) é um tópico estudadojá desde 1994 com a escrita das primeiras teses sobre o assunto [NSW94, Sch95]. No en-tanto, apenas mais recentemente, com o avanço nos estudos sobre computação móvel eubíqua, esta ideia começou a ser explorada em termos mais práticos [Lok06]. Com a re-cente expansão do mercado móvel, surgem novas plataformas portáteis cada vez mais so-fisticadas, equipadas de novos tipos de sensores capazes de fornecer informação mais de-talhada sobre o contexto dos utilizadores (localização, movimentos, luminosidade, etc.).Este paradigma da computação móvel vem assim trazer novas oportunidades e desa-fios [BZMK09]. Por exemplo, uma ideia mais recente é o conceito de smart spaces,espaços públicos ou privados que através da sua própria rede wireless oferecem determi-nados serviços baseados em contexto a serem utilizados a partir das várias plataformasmóveis existentes. Os progressos feitos na área da computação ubíqua têm trazido sis-temas cada vez mais universais. Estes sistemas têm vindo a evoluir no sentido de, nofuturo, permitirem um acesso quase constante às redes de informação tal como a Internet,permitindo recolher muitos mais dados e estender o conceito de smart spaces a cidadesinteiras — as designadas smart cities.

1.2 Enquadramento e Motivação

Este trabalho está inserido no âmbito do projecto de um sistema baseado em informa-ção de contexto que se encontra a ser desenvolvido pela PT Inovação. A PT Inovação éuma organização dentro do grupo Portugal Telecom (PT) e é a principal responsável pelodesenvolvimento de soluções tecnológicas para as empresas deste grupo.Dentro do grupo PT existem diversos fornecedores de conteúdos e serviços, assim comoaplicações desenvolvidas com o propósito específico de permitir o acesso a esses conteú-dos. Por forma a melhorar a qualidade dos serviços e conteúdos oferecidos, a PT Inovaçãopretende explorar o conceito de sistemas baseados em contexto (context-aware) e para talcomeçou a desenvolver a sua própria framework para recolha, armazenamento e divulga-ção de informação de contexto. Esta framework é descrito com maior detalhe no Capítulo2.A informação de contexto é neste momento obtida a partir de diversas aplicações e contémdados tais como os valores da localização dos utilizadores, informação sobre os conteúdosconsumidos e outros dados relativos aos terminais utilizados. É também possível obterinformação sobre o perfil social, rede de amigos e preferências publicadas pelos utiliza-dores das redes sociais Facebook e Orkut. Estes dados são actualmente utilizados por

2

Introdução

sistemas simples de recomendação de conteúdos e publicidade.No entanto o sistema actual possui várias limitações. Uma dessas limitações encontra-se relacionada com o facto de, por motivos legais, a informação recolhida não poder sermantida por períodos superiores a um ano. Por outro lado, a informação recolhida é pro-cessada no seu estado bruto, isto é, não é feita ainda qualquer análise aos dados recolhidose, portanto, o sistema nada aprende sobre o comportamento dos utilizadores. A informa-ção está neste momento a ser muito subaproveitada.Existe também a necessidade de desenvolver várias aplicações baseadas no contexto dosutilizadores. Uma mais-valia pretendida passa por tornar possível fazer recomendação deconteúdos e envio de publicidade direccionada à situação em que o utilizador se encontra,seja em relação ao tipo de local onde se encontra (por exemplo, se está em casa ou numlocal de compras), seja à actividade (por exemplo, a dormir ou a trabalhar). No entanto,os dados brutos a que actualmente se tem acesso, como a localização GNSS, não são sufi-cientemente significativos para serem interpretados pelos diversos serviços. Este trabalhopretende explorar formas de aproveitar melhor esta informação de baixo nível permitindoinferir a situação em que cada utilizador se encontra a partir desta informação de baixonível.

1.3 Objectivos

Tendo em conta o enquadramento do trabalho descrito neste documento, podemos de-finir 3 objectivos para esta dissertação. O primeiro objectivo é permitir inferir informaçãosobre a situação em que uma pessoa se encontra, a partir dos dados de mais baixo nívelque são enviados pelas fontes de contexto (ver Secção 2.3). Este novo tipo de informa-ção deve consistir inicialmente no tipo de localização em que uma determinada pessoase encontra e provável tipo de actividade num determinado instante de tempo. O tipo deactividade está limitado a um conjunto de actividades mais frequentes do dia-a-dia comodormir ou trabalhar. Os tipos de localização referidos correspondem a termos que classifi-quem de uma forma genérica alguns locais mais frequentes no dia-a-dia das pessoas. Doiscasos comuns neste tipo de sistemas são a casa e o local de trabalho. Com este trabalhopretende-se explorar outras classificações como locais de compras, paragens e estaçõesde transportes públicos ou zonas de diversão e desporto.O segundo objectivo prende-se precisamente com este último aspecto referido: classificaro local em que uma pessoa se encontra em determinada altura. No entanto, no decorrerdeste trabalho pretende-se explorar uma forma não supervisionada de aprender quais oslocais mais significativos para cada pessoa, isto é, pretende-se que não seja necessárioqualquer feedback por parte dos utilizadores das potenciais aplicações que venham fazeruso da framework de contexto. Assim sendo, é necessário recolher o histórico de loca-lizações de cada utilizador ao longo do seu dia-a-dia e determinar quais os locais mais

3

Introdução

significativos. Para tal serão implementados e estudados alguns algoritmos de agregaçãoaplicados sobre um conjunto de pontos geográficos. Preferencialmente, estes algoritmosdeverão actualizar incrementalmente os diversos grupos de locais, isto é, à medida quenovos dados vão chegando. Depois é necessário definir um conjunto de regras de clas-sificação sobre os locais encontrados. Com este trabalho pretende-se utilizar qualquerconjunto de informação de contexto disponível que possa ser útil para esta classificaçãoe avaliar os resultados que estes dados adicionais produzem em relação a outras soluçõesjá existentes.Por fim, o último objectivo é tornar esta solução o mais genérica possível de forma afacilitar a integração com a framework de contexto que a PT inovação já se encontra adesenvolver (ver Secção 2), possibilitando a integração deste módulo com novas regrasde negócio que possam vir a ser definidas. Por outras palavras, a solução deverá permi-tir facilmente adicionar novos tipos ou alterar os tipos de contexto que existem, assimcomo adicionar novas regras ou alterar as regras de inferência existentes. Por exemplo,deverá ser possível adicionar novos tipos de localização a inferir e definir quais as regrasde inferência a aplicar reutilizando o código já existente.

1.4 Estrutura do Documento

Este documento encontra-se organizado em 8 capítulos:O Capítulo 2 complementa o enquadramento do projecto desenvolvido no âmbito

desta dissertação, descrevendo o sistema já existente no qual o sistema implementadoé baseado e com o qual deverá ser integrado. Este capítulo descreve conceitos que sãoutilizados nos restantes capítulos deste documento.

O Capítulo 3 apresenta abordagens encontradas na literatura existente, incluindo mé-todos e tecnologias utilizadas para resolver diversos problemas dentro do âmbito destadissertação, apresentando também alguns outros sistemas existentes semelhantes ao sis-tema desenvolvido ou que tenham a mesma finalidade.

O Capítulo 4 descreve mais detalhadamente os requisitos inicialmente esperados parao trabalho desenvolvido. É também apresentado o desenho global da solução implemen-tada, incluindo a arquitectura física do sistema e a arquitectura lógica do novo componentedesenvolvido.

A descrição da implementação e avaliação da solução implementada encontra-se divi-dida pelos 3 capítulos seguintes.

O Capítulo 5 descreve as abordagens e tecnologias utilizadas para recolher a informa-ção de contexto necessária para a realização do projecto assim como a forma como estainformação é armazenada para futuro processamento.

O Capítulo 6 apresenta o novo componente desenvolvido no qual é centrada a grandemaioria do processamento de dados efectuados no âmbito da dissertação. Neste capítulo

4

Introdução

é também detalhada a forma como a inferência de contexto é realizada e a forma de comoé possível adaptar o sistema a novos tipos de contexto.

O Capítulo 7 descreve os métodos utilizados para um caso particular do sistema queconsiste em identificar quais serão os locais mais relevantes no dia-a-dia de cada pessoarecorrendo à informação que é recolhida a partir dos seus dispositivos móveis.

Finalmente, no Capítulo 8 são apresentadas as conclusões retiradas do trabalho rea-lizado, enumerando o que ficou por realizar e sugeridas futuras melhorias e adições aosistema implementado.

5

Introdução

6

Capítulo 2

Framework de Contexto da PT Inovação

Neste capítulo é descrito um aspecto importante no enquadramento deste trabalho: aframework de gestão de contexto em desenvolvimento na PT Inovação. O resultado destetrabalho consiste num novo componente a ser integrado nesta framework, sendo portantorelevante referir as tecnologias e protocolos que são já utilizados e quais os restantescomponentes com os quais será necessário interagir.A secção seguinte pretende dar uma visão geral da framework referida. Nas secçõesseguintes são descritos os modelos de informação de contexto utilizados e apresentadosos vários tipos de componentes existentes.

2.1 Visão Geral

Por forma a conseguir obter informação de contexto sobre os utilizadores que con-somem os diversos serviços da Portugal Telecom e, posteriormente, usar esta informaçãopara oferecer serviços mais orientados a cada um destes utilizadores, a PT Inovação come-çou a desenvolver uma framework para gestão de contexto [GGSA10]. Esta framework ébaseada noutros projectos financiados pela UE tal como o projecto Mobilife1 e o projectoC-CAST2. Tal como nestes 2 projectos, a nova framework, assente numa arquitecturabaseada num mediador, é responsável pela recolha, armazenamento e publicação da in-formação de contexto.O que diferencia esta nova framework das existentes é a utilização da tecnologia XMPP(Extensible Messaging and Presence Protocol) como protocolo de comunicação entreestes vários componentes. Esta tecnologia foi escolhida por suportar serviços de Publish-Subscribe e responder melhor às necessidades de comunicação em tempo-real face a

1http://www.ist-mobilife.org/2http://www.ist-ccast.eu

7


Figura 2.1: Diagrama de sequência: fluxo típico da informação na framework de gestão de con-texto

outras tecnologias como o SOAP (Simple Object Access Protocol) ou MOM (Message-Oriented Middleware). Outro aspecto que distingue esta framework das existentes é autilização de uma representação mais genérica da informação de contexto, sob a formade documentos XML (Extensible Markup Language). Esta representação mais complexabeneficia do facto de facilitar a comunicação de vários tipos de contexto, desde que os me-canismos de Resource Discovery utilize modelos de descrição normalizados como XSD(XML Schema Description) ou DTD (Document Type Definition).Para além do mediador de contexto, esta arquitectura possui ainda outros 3 tipos de ac-tores no sistema: as fontes de contexto, os fornecedores de contexto e consumidores decontexto. O caso mais comum do fluxo de informação entre estes elementos pode servisto na Figura 2.1.

2.2 Modelos de Descrição de Informação de Contexto

Como foi referido anteriormente, toda a informação entre os vários componentes étrocada recorrendo ao protocolo XMPP, um protocolo baseado na troca de mensagensXML. Por forma a facilitar a integração dos diversos componentes da framework, cadatipo de informação de contexto enviado nessas mensagem encontra-se bem definido edescrito em ficheiros XSD. Este é actualmente um dos modelo de descrição de dadosmais utilizado pois torna fácil a tarefa de validar o formato dos dados trocados e outrostipos de análise. Actualmente encontram-se já implementadas bibliotecas em Java, Rubye PHP (PHP: Hypertext Preprocessor) para efeitos de construção, análise e envio de dadosde contexto.

Na Listagem 2.1 encontra-se a descrição do formato das mensagens de contexto tro-cadas entre todos os componentes. Neste ficheiro é descrito um nó designado “context”que serve de raíz para todos os restantes nós XML que representam os dados de contextoem si. Na Secção 5.1.2 podem ser encontradas as descrições XSD dos tipos de contexto

8


1 <?xml version="1.0" encoding="UTF-8"?>2 <schema xmlns="http://www.w3.org/2001/XMLSchema"3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"4 xsi:schemaLocation="http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/

XMLSchema.xsd"5 targetNamespace="http://iex.ptin.pt/ctx/core"6 xmlns:tns="http://iex.ptin.pt/ctx/core">7

8 <complexType name="ContextType">9 <sequence>

10 <any minOccurs="1" maxOccurs="unbounded"></any>11 </sequence>12 <attribute name="entity" type="anyURI" use="optional"/>13 <attribute name="contextProvider" type="anyURI" use="optional"/>14 <attribute name="contextSource" type="anyURI" use="required" />15 <attribute name="captured" type="dateTime" use="required" />16 </complexType>17

18 <element name="context" type="tns:ContextType"></element>19 </schema>

Listagem 2.1: Schema das mensagens de contexto.

utilizados no âmbito deste projecto. O nó “context” pode ter um número ilimitado destestipos de contexto e serve basicamente de cabeçalho a cada mensagem de contexto. Nestecabeçalho são incluídas a data e hora a que os dados que a mensagem contém foramcapturados e o JID (Jabber Identification) da entidade e fonte original da mensagem.

2.3 Fontes de Contexto

Uma fonte de contexto (context source) é a designação dada no âmbito deste projectoa qualquer aplicação responsável por extrair dados de contexto, por exemplo, a partirde sensores de um dispositivo. Cada fonte de contexto tem à partida um conjunto bemdefinido de tipos de contexto a recolher e é responsável por enviar periodicamente umamensagem, contendo os dados obtidos, aos respectivos fornecedores de contexto.Actualmente existem alguns protótipos de aplicações Java, Android e Ruby que fazem oupermitem simular essa recolha. A aplicação descrita na Secção 5.1 é uma fonte de con-texto. Outro exemplo de dispositivos já utilizados para recolha de contexto são as set-topboxes da Meo3, especialmente programadas para o efeito. Outros tipos de informaçãode contexto, tal como informação do perfil dos utilizadores, redes sociais e preferênciassão obtidos por aplicações Web através das API fornecidas. Com o desenvolvimento danova framework de gestão de contexto, a PT Inovação tem como objectivo possibilitar que

3Serviço de transmissão de conteúdos televisivos da Portugal Telecom

9


qualquer aparelho possa enviar informação de contexto, desde que programável e com li-gação directa ou indirecta com a Internet.

2.4 Fornecedores de Contexto

Os fornecedores de contexto (context providers) são componentes XMPP com ligaçãopermanente ao mediador de contexto. Estes componentes são programas implementadosem Ruby, PHP ou Java que utilizam as bibliotecas XMPP4R, XMPPHP e Smack respec-tivamente. Estes fornecedores são responsáveis por receber os dados vindos de fontesespecíficas, validar e processar (se necessário) estes dados e publicar então esta informa-ção no mediador de contexto ou responder a eventuais pedidos vindos directamente dealgum consumidor de contexto. No caso da recolha de informação vinda das redes soci-ais, estes fornecedores funcionam como crawlers, redireccionando esta informação parao mediador de contexto.

2.5 Mediador de Contexto

O mediador de contexto (context broker) é um módulo XMPP a correr num servidorOpenfire. Este componente utiliza a extensão XEP (XMPP Extension Protocol) Publish-Subscribe. Esta funcionalidade permite construir um sistema sem que os consumidores decontexto tenham de enviar pedidos regulares para verificar se houve alguma alteração nocontexto do utilizador. Os dados que chegam ao mediador são guardados numa base dedados CouchDB. A extensão Publish-Subcribe permite manter estes documentos numaestrutura em árvore, onde cada mensagem é organizada hierarquicamente por tipo decontexto e fonte conforme se pode ver na Figura 2.2. Qualquer aplicação pode subscrevervários nós de qualquer nível e receber todos os novos documentos que vão chegando aosnós que pertençam a essa subscrição.

2.6 Consumidores de Contexto

Consumidor de contexto (context consumers) é a designação dada a qualquer aplicaçãoque utilize os dados publicados pelas fontes de contexto para qualquer tipo de serviços.Estas aplicações podem ser clientes ou componentes XMPP. Uma fonte de contexto podeser considerada também um consumidor de contexto se, por exemplo, agregar dados deoutras fontes para publicar, processar e reenviar como um diferente tipo de dados e/ou paradiferentes destinatários. A recolha de dados pode ser realizada através de mecanismosde polling directamente sobre os fornecedores ou subscrevendo um determinado tipo de

10


informação no mediador. Consumidores actuais que tiram partido desta informação decontexto são, por exemplo, os sistemas de recomendação e publicidade já existentes.

2.7 Sumário

Neste capítulo foi descrita a framework de gestão de sistemas baseados em informaçãode contexto que a PT Inovação se encontra a desenvolver. Esta framework é baseadano protocolo de comunicação XMPP e a informação de contexto é definida através deesquemas XML. A framework é composta por 4 tipos de componentes:

• As fontes de contexto que são programas responsáveis por recolher a informaçãode contexto;

• Os consumidores de contexto que são programas que utilizam a informação decontexto recolhida;

• O mediador de contexto que é um componente XMPP que armazena os dadoscoleccionados e oferece um serviço de Publish-Subscribe sobre a informação decontexto aos consumidores de contexto;

• Os fornecedores de contexto que são programas que servem de intermediários en-tre as fontes de contexto e o mediador ou consumidores e fazem a validação dosdados enviados.

11


Figura 2.2: Exemplo de uma árvore Publish-Subscribe

12

Capítulo 3

Revisão Bibliográfica

Neste capítulo são apresentados alguns dos mais recentes trabalhos descritos na litera-tura sobre as áreas abordadas ao longo do projecto desenvolvido. Tendo em conta o factode que este trabalho aborda áreas significativamente distintas e independentes entre si,este capítulo encontra-se dividido em 3 secções, cada uma focada numa área específica.A Secção 3.1 foca-se na área de gestão de informação de contexto, onde são descritostrabalhos já existentes com propósitos semelhantes ao da framework da PT Inovação, in-cluindo as diferentes tecnologias e abordagens utilizadas na representação da informaçãoe na arquitectura dos respectivos sistemas. A Secção 3.2 aborda diversas técnicas usadasna identificação e classificação de locais relevantes dentro de um conjunto de registos deposições geográficas. Na Secção 3.3 são apresentadas as principais abordagens utilizadasna inferência da actividade dos utilizadores a partir de informação de contexto.

3.1 Sistema Baseados em Informação de Contexto

Os tipo de informação de contexto actualmente definidos encontram-se divididos emvários conceitos como a localização e tipo de actividade, entre outros. Estes conceitos es-tão geralmente relacionados entre si e alguns são até muitas vezes interdependentes. Estesconceitos estão também organizados em diferentes níveis de abstracção. O problema deinferência de contexto (e situação) dos utilizadores a partir de diferentes níveis de abstrac-ção pressupõe assim um modelo descritivo destes vários conceitos. O primeiro problemaque se põe prende-se com a forma de representar estes modelos aquando da comunicaçãodesta informação. O segundo problema é o de como fazer a inferência sobre uma dadainstância deste modelo. Neste capítulo são indicados alguns trabalhos já existentes nestaárea e quais as tecnologias utilizadas. Estes trabalhos são divididos em três categorias

13


Figura 3.1: Arquitectura do motor de regras no sistema ec(h)o

relativas à abordagem utilizada [BPAP08]: baseadas em regras, baseadas em ontologias ebaseadas em casos.

3.1.1 Sistemas Baseados em Regras

Nos sistemas baseados em regras, as relações entre os vários conceitos são represen-tados sob a forma de regras lógicas. A inferência pode ser feita através de programaçãoem lógica com regras definidas segundo a respectiva linguagem ou através de motores deregras, usando descrições que possam ser interpretadas por esses motores.Em [Lok04], Loke apresenta uma extensão da linguagem Prolog chamada LogicCAP,desenvolvida com o objectivo de facilitar a programação de aplicações context-aware. Asvárias situações possíveis são definidas através de um conjunto de regras descritas emprogramação em lógica. Este autor introduz o conceito de predicado sensorial que per-mite descrever os valores obtidos a partir de sensores na forma “<sensor_id>*(<inputs>,<output readings>).”.O projecto Gaia [RHC+02] também assenta numa infraestrutura que utiliza este tipo derepresentação [RC03]. A informação de contexto é representada por predicados na forma“<contexto>(<sujeito>, <predicado>, <objecto>)”, especificados numa ontologia escritaem DAML+OIL [Hor02]. A inferência de contexto é feita através de interrogações Prologusando o motor XSB [SSW94].O ec(h)o system, representado parcialmente na Figura 3.1 [HWK05], é um sistema querecolhe os dados da posição de visitantes num museu e tem como objectivo decidir quaisos sons a reproduzir para cada visitante. O modelo conceptual do contexto de cada pes-soa é também representado em DAML+OIL, mas é utilizado o motor de regras Jess eDAMLJessKB [KR03] na conversão entre as ontologias apropriadas.

14


Figura 3.2: Inferência de contexto no sistema de Goix et al.

A framework Jena é bastante popular na literatura e é usada em vários trabalhos [WDC+02,GPZ05b, KK05, NGMW08] que utilizam inferência por regras e representação ontológicado contexto. O projecto Context Broker Architecture (CoBrA) [CFJ03] usa uma formasemelhante de inferência, recorrendo também a Jess quando o Jena não é suficiente.Goix et al. apresentam uma infra-estrutura, representada na Figura 3.2 [GVCF08], pararecolha e processamento de informação de contexto baseada num mediador de contexto.A informação é trocada num formato XML que designam por ContextML. Para fazerinferência de situações de um determinado utilizador, estes autores desenvolveram ummódulo que chamam de Situation Provider (SP). O SP corre sobre um servidor JBoss, foidesenvolvido em Stateless EJB (Enterprise JavaBeans) e actua como um consumidor decontexto adquirido através do mediador de contexto. O motor de regras usado é baseadoem Jess e processa regras definidas no formato RuleML. São usadas folhas XSLT (Ex-tensible Stylesheet Language Transformations) para efectuar a conversão de ContextMLpara RuleML e vice-versa.

3.1.2 Sistemas Baseados em Ontologias

A maior parte dos sistemas neste domínio representam o modelo da informação decontexto segundo uma ontologia descrita em OWL [PRL09]. Nesta secção são menci-onados alguns trabalhos que utilizam ferramentas de inferência baseadas em ontologias.Estas ferramentas têm, em geral, um bom desempenho e integram-se facilmente com os

15


modelos escritos em linguagens de descrição de ontologias. No entanto o seu poder deinferência é bastante limitado e, como tal, é comum estes sistemas utilizarem conjunta-mente motores de regras [BPAP08].O Service-oriented Context-Aware Middleware (SOCAM) [GP05, GPZ05a] é uma fra-mework desenvolvida para facilitar a implementação de serviços móveis baseados emcontexto. O modelo conceptual da informação de contexto desta framework é descrita emOWL, usando um conjunto de triplos RDF na forma “(<sujeito>, <predicado>, <valor/ob-jecto>)”. O interpretador é dividido numa Base de Conhecimento e num context reasonerimplementado em Jena2, que possui interfaces para inferência em RDFS e OWL, paraalém de suportar regras. Uma outra forma de representar o conhecimento é através deLógica Descritiva (Description Logic). Em [TSB06], Turhan et al. exploram um cenáriode utilização muito simples para smart homes em que descrevem os conceitos e regrasem OWL DL. Estes autores experimentaram o seu sistema comparando três motores deinferência em DL: RACER, RACERPro (uma versão comercial) e Pellet.O sistema Mobilife [LMW+05, KBB+06], um projecto financiado pela União Europeia(UE) no qual se baseia o trabalho da PT Inovação, consiste também numa frameworkbaseada num mediador. O modelo conceptual de contexto é representado em OWL, ge-rido através da ferramenta Protégé, e a Base de Conhecimento é interrogada através deRDQL (Resource description framework Data Query Language). Para processar o con-texto recorrem ao motor de inferência RACER. Este processamento é enriquecido tam-bém através do uso de Jess. A taxonomia utilizada no projecto Mobilife pode ser vista naFigura 3.3, retirada de [LMW+05].

3.1.3 Sistemas Baseados em Casos

A inferência baseada em casos (Case Based Reasoning) procura reutilizar soluçõesencontradas para ocorrências anteriores para resolver um novo problema que seja seme-lhante [Lea96]. Na aplicação a sistemas baseados em contexto, esta abordagem pode serutilizada para encontrar as situações identificadas anteriormente para um conjunto de da-dos de contexto conhecidos a priori. Este processo pode ser dividido em 4 fases, comopode ser visto na Figura 3.4 [AP94]. Primeiro são procurados casos já conhecidos quesejam semelhantes ao novo caso. A nova situação é então avaliada com base nas situaçõesdetectadas para esses casos. Este sistema pressupõe algum tipo de feedback que permitacorrigir esta avaliação e guardar este novo caso conjuntamente com os casos anteriores.

O sistema AmbieSense [MKP05] pretende determinar uma série de acções a realizartendo em conta o contexto de utilizadores de uma aplicação móvel. Neste sistema os casossão representados segundo uma taxonomia escrita pelos autores e a consistência do mo-delo é verificada através de um conjunto de modelos que determina as situações possíveispara determinados contextos. O processo de inferência é realizado por um conjunto de

16


Figura 3.3: Taxonomia usada na ontologia do sistema Mobilife

Figura 3.4: Visão geral do processo em CBR

17


agentes, tanto em modo online como offline, para ser possível suportar a carga adicionaldos casos que vão chegando.Zimmermann [Zim03] apresenta uma framework baseada em casos para gerar recomen-dações. Este autor propõe a representação de casos segundo quatro dimensões: tempo,identidade, localização e actividade. Para cada caso é associado um objecto a recomendar.No entanto, no artigo citado não é apresentada qualquer implementação da ideia referida.Em [LL07] é apresentado um sistema de recomendação de músicas num sistema context-aware (C2_Music) onde o conhecimento é representado com base em casos. Neste sis-tema são guardados dados relativos às músicas, aos utilizadores e ao seu histórico deutilização. O contexto é representado em casos que reúnem a região do utilizador, a alturado ano (dia e mês) e o estado meteorológico. Os autores do artigo mencionado refe-rem, contudo, o problema de encontrar casos semelhantes através do algoritmo k-NearestNeighbour (k-NN).

3.2 Aprendizagem de Locais Significativos

A informação de contexto relativa à localização é, desde os primeiros estudos na área,o tipo de contexto mais usado e explorado. A localização de um utilizador é uma dasinformações mais importantes no âmbito da maioria das aplicações actuais. Inicialmente,esta informação de contexto era limitada a zonas específicas, recolhida a partir de umarede se sensores montados em determinadas áreas. Nos dias de hoje a maioria dos dispo-sitivos móveis tem acesso a tecnologias que permitem determinar a sua localização, o quetorna este tipo de informação globalmente acessível e permite recolher ainda mais dados.O processo de aprendizagem de locais significativos tem como objectivo determinar, apartir dos vários locais visitados por cada pessoa, quais as zonas que representam os sítiosmais relevantes no seu dia-a-dia e que significado têm para essas pessoas. Este processopode ser então dividido em duas fases: em primeiro lugar, determinar quais os locais deinteresse e, em segundo lugar, classificar esses locais segundo o significado que têm paracada utilizador. A primeira fase é abordada na Secção 3.2.1 e a segunda na Secção 3.2.2.

3.2.1 Identificação de Locais Significativos

Actualmente quase todos os smart phones e muitos outros dispositivos móveis têmacesso à sua localização por GNSS. Por esse motivo, a maior parte dos dados usados paradeterminar a localização dos utilizadores é deste tipo. No entanto este tipo de localizaçãonão se encontra sempre disponível, principalmente em zonas fechadas como edifícios oumesmo zonas externas rodeadas por edifícios altos — os chamados urban canyons. Poreste motivo e principalmente para detectar a localização dentro de edifícios, outras fontesde informação de localização são por vezes utilizadas, como o identificador de células

18


GSM ou pontos de acesso WiFi. Estes últimos tipos de localização são menos precisos,mas estão geralmente acessíveis mesmo onde a localização GPS não é possível.De seguida é apresentada alguma da literatura existente sobre vários métodos que procu-ram explorar diferentes tipos de dados e sobre abordagens para identificar locais significa-tivos. Um recente estudo comparativo [Bha09] sobre alguns dos métodos mais recentes,divide estes métodos segundo três tipos de abordagens: abordagens baseadas na distân-cia entre pontos, abordagens baseadas na densidade dos grupos (clusters) e abordagensprobabilísticas.

3.2.1.1 Abordagens Baseadas em Distância

A principal limitação desta fonte de localização prende-se com o facto de estar geral-mente inacessível dentro de edifícios e de ser muito susceptível a falhas em várias zonasurbanas.O método proposto em [MS02] explora este factor na identificação de edifícios. Estesautores partem de dois pressupostos: que os locais mais frequentados pelo utilizador sig-nificam que esses locais são relevantes e que a falta de sinal significa que o utilizadorentrou em algum tipo de edifício. Se o sinal de localização de um dado utilizador desa-parece e reaparece dentro de um determinado raio, então a zona definida por esse raio édefinida como sendo um edifício. A frequência com que cada utilizador visita um edifícioidentificado é usada para determinar quais os locais mais significativos na sua rotina.Em [AS03] são propostas algumas extensões ao método anterior. A primeira melhoriaconsiste na utilização de um valor de tempo t durante o qual cada pessoa deverá perma-necer num dos locais detectados de forma a determinar esse local como sendo relevante.Um valor demasiado alto poderá omitir alguns locais relevantes mas, por outro lado, umvalor demasiado baixo faz com que demasiados locais sejam detectados. No final, osautores decidem usar um valor de 10 min para esta detecção. Outra melhoria propostaconsiste em agrupar localizações próximas. Esta melhoria é muito significativa, uma vezque mesmo a localização dada para uma pessoa parada pode variar ligeiramente. Numafase posterior é proposto um passo de divisão das zonas encontradas em sub-locais. Esteagrupamento foi explorado usando uma variante do algoritmo de agregação k-Means.Esta última abordagem é aprofundada em [TOK+05]. Estes autores utilizam vários valo-res para o raio dentro de um dado local, de uma forma iterativa, para encontrar sub-locaisrelevantes dentro de cada local detectado e baseiam-se em valores de densidade para eli-minar ruído nos dados.Os métodos anteriores correm, no entanto, o risco de detectar zonas fora dos locais sig-nificativos, tais como o pontos de deslocação entre estes locais. Kang et al. [KWSB05]propõem um método de agregação das localizações à medida que os dados vão chegando(Figura 3.5). Se uma nova localização estiver dentro de um determinado alcance do grupo

19


Figura 3.5: Agregação baseada em tempo num espaço bidimencional [KWSB05]

actual então o local é adicionado, caso contrário um novo grupo é formado. Os grupossignificativos são detectados se o tempo de permanência dentro de um determinado grupofor superior ao limite definido.

3.2.1.2 Abordagens Baseadas em Densidade

Os algoritmos baseados em distância mencionados tendem a formar grupos de loca-lizações dentro de zonas com formato rectangular ou circular. No entanto, certas loca-lizações não podem ser definidas de uma forma tão regular. Os algoritmos baseado emdensidade têm a vantagem de permitir formar grupos em limites mais irregulares.Adams et al. [APV08] aplicam uma versão incremental do algoritmo Density-Based Spa-tial Clustering of Applications with Noise (DBSCAN) [EKSX96] — designado por In-cremental DBSCAN (IncDBSCAN) [EKS+98] — no reconhecimento de locais significa-tivos. Estes autores começam por filtrar posições que se estimam estarem fora dos locaissignificativos, tais como as posições durante deslocamentos entre os vários locais. Estafiltragem é feita tendo em conta um determinado limite de velocidade. O algoritmo DBS-CAN requer dois parâmetros na formação de grupos: um valor máximo de distância entrepontos no mesmo grupo (Eps) e um número mínimo de pontos que cada um deve conter(MinPts). Dois pontos dizem-se directamente alcançáveis se estiverem ambos dentro davizinhança definida pelo raio Eps e se essa vizinhança contiver no mínimo MinPts pon-tos. Dois pontos são alcançáveis se for possível ligá-los através de uma cadeia de pontosque cumpram a propriedade anterior. Dois pontos dizem-se conectados se estiverem navizinhança de dois pontos alcançáveis. Um grupo é definido por um conjunto de pontos

20


Figura 3.6: Conceitos básicos do algoritmo DBSCAN

que cumpram a propriedade de conectividade anterior. Estes conceitos são ilustrados naFigura 3.6, retirada de [EKSX96].Este algoritmo é apenas aplicado sobre um conjunto de dados estáticos. O algoritmoIncDBSCAN vem melhorar este algoritmo de forma a actualizar cada grupo de pontos àmedida que vão chegando novos dados. Esta actualização é feita através de operações deinserção e remoção de pontos nos vários grupos.

A construção dos grupos de pontos através dos algoritmos anteriores é feita com basenuma expansão recursiva da vizinhança dos grupos iniciais. Por esta razão, estes métodosconsumem bastantes recursos de memória e são bastante demorados [Bha09]. Zhou etal. [ZFL+07] propõem um algoritmo chamado Density-Joinable Cluster (DJ-Cluster)para contornar estes problemas. Tal como o algoritmo DBSCAN, utiliza os parâmetrosEps e MinPts. No entanto, o valor MinPts é determinado de uma forma automática emque o algoritmo vai tentar encontrar um valor óptimo explorando iterativamente váriosvalores. Estes autores também introduzem o conceito de density-joinable. Dois gruposdizem-se density-joinable se existir pelo menos um ponto comum a ambos. O algoritmovai iterando de ponto a ponto de forma a determinar a sua vizinhança. Se esta vizinhançacumprir o limite mínimo de MinPts então um novo grupo é formado. No fim do ciclo, estegrupo é combinado com os grupos existentes que sejam density-joinable (ver Figura 3.7,extraída de [ZFL+07]).

3.2.1.3 Abordagens Probabilísticas

Aipperspach et al. [ARWC06] introduzem um algoritmo de agregação que consistenuma variação probabilística dos algoritmos baseados em distância anteriormente menci-

21


Figura 3.7: Agregação através do algoritmo DJ-Cluster

onados. Neste algoritmo, os vários pontos obtidos são representados segundo uma distri-buição Gaussiana em três dimensões: latitude, longitude e tempo. Os grupos iniciais sãoconstituídos por cada um dos pontos separados, ao que se segue um processo de agregaçãoentre os pontos mais próximos dentro do espaço tridimensional. Esta agregação é feitotendo em conta a divergência de Kullback–Leibler entre as distribuições de cada grupo.Após esta primeira fase são descartados os grupos que não cumprem um determinado li-mite de tempo de permanência. Finalmente, é feito outra agregação entre os grupos querestam, desta vez para agrupar pontos que representem visitas a um mesmo local. Nesteúltimo agregação são apenas consideradas as dimensões espaciais.Em [NB08] é descrito o algoritmo Dirichlet Process Clustering (DPCluster). Este al-goritmo distingue-se por não ter que receber quaisquer parâmetros nem usar a dimensãotemporal em todo o seu processo. Em vez disso o algoritmo é baseado em modelos mistosde processos de Dirichlet [Fer73, Ant74, Ras00]. Numa primeira fase, este algoritmo vaiestimar os vários parâmetros deste modelo por amostragem de Gibbs [Nea00]. Numa se-gunda fase de pós-processamento, é feita uma filtragem temporal e espacial. A filtragemtemporal é feita relativamente à frequência relativa de cada grupo de pontos enquanto quea filtragem espacial é feita sobre os grupos que possuem maior variância.

3.2.1.4 Abordagens Baseadas em “Fingerprints”

Todos os métodos anteriormente mencionados são baseados em posições GNSS e empadrões geométricos nos pontos detectados. Outros tipos de métodos são os chamadosmétodos baseados em “fingerprints” que recolhem uma lista de locais sem qualquer re-ferência geográfica e são capazes de, mais tarde, reconhecer quando determinada pessoaregressa a esses locais. Estes métodos são assim adequados na identificação de locais apartir de dados GSM.Um destes métodos é proposto em [LRT04]. Dois conceitos relevantes utilizados porestes autores são localização e base. Uma localização é a unidade mais pequena querepresente um local de forma fiável. Uma base consiste num local temporalmente sig-nificativo para os utilizadores (baseado no tempo que estes permanecem em cada local).

22


Figura 3.8: Visão geral sobre o algoritmo BeaconPrint

Um grafo de células GSM é construído a partir dos dados que vão chegando, sendo quecada aresta representa uma transição entre duas células. Estas células são depois agru-padas por proximidade, baseando-se nos tempos de permanência entre cada célula. Cadagrupo representa no máximo um sub-grafo com diâmetro máximo de 2. A localizaçãode uma dada célula é então dada pelo fecho transitivo entre todos os possíveis grupos,de forma a resolver possíveis sobreposições entre grupos ou pela própria célula, caso nãoseja atribuído nenhum grupo existente. Uma base é determinada segundo os valores depermanência numa determinada localização, calculados através do tempo total de perma-nência e a frequência das visitas.Outro algoritmo proposto é o BeaconPrint [HCL+05]. Uma visão geral deste processoencontra-se representada na Figura 3.8. Este algoritmo opera em duas fases principais:em primeiro lugar aprende quais os lugares visitados por um determinado utilizador eem seguida utiliza a lista de locais gerados para comparar com os novos dados que vãochegando. Este algoritmo recebe dois parâmetros: um intervalo de tempo w e um va-lor de confiança máximo cmax. O intervalo w é dividido em d sub-intervalos. Por cadasub-intervalo em que não não seja detectado um novo identificador, o valor de certezaé incrementado. Quando o valor de certeza atinge cmax esses registos são considera-dos uma “fingerprint” válida. As várias “fingerprints” são posteriormente fundidas deacordo com o grau de semelhança, medido pelo número de identificadores em comum.Posteriormente, esta medida de semelhança é usada também para reconhecer a localiza-ção de novos registos que vão chegando. Uma lista de locais candidatos, ordenada porsemelhança, é dada no caso de existirem várias “fingerprints” possíveis. Outras técni-cas procuram explorar vários tipos de localização possíveis. Nurmi e Koolwaaij [NK06]utilizam uma abordagem semelhante à de Laasonen et al. [LRT04] que combina a infor-mação GSM enriquecida pela localização GPS, sempre que possível. Nesta abordagemprocura-se melhorar a localização de cada célula GSM através do calculo do centróidecorrespondente a partir das posições GPS disponíveis.

23


3.2.2 Classificação de Locais Significativos

Os algoritmos de identificação de locais descritos anteriormente apenas indicam gru-pos de coordenadas que representam um local significativo na rotina de cada pessoa. Noentanto, fica por determinar qual o significado que o local tem. O próximo passo passa en-tão por classificar cada um destes locais. Este significado deverá ser atribuído em termosque sejam descritivos tanto para o utilizador como para as aplicações e serviços com queeste interage. Exemplos desses termos são “casa” para indicar o local onde o utilizadormora, “trabalho” para indicar os locais onde estes exercem actividades profissionais ou“loja” para indicar um local onde este efectua as suas compras. No entanto, esta classi-ficação deve ser feita considerando cada utilizador em particular. Uma “loja” para umadeterminada pessoa pode representar o “trabalho” de outra.Nesta secção são descritas algumas abordagens feitas nesse sentido. Estas abordagenspodem ser manuais, em que o próprio utilizador classifica os locais, ou automáticas, pro-curando formas de classificar os locais sem qualquer intervenção directa dos utilizadores.

3.2.2.1 Classificação Manual

A classificação manual por parte de cada utilizador é a abordagem mais simples paraobter uma boa classificação dos locais identificados, sendo, por isso, uma abordagemmuito comum [Bha09].A introdução do nome do local pode ser feita livremente pelo utilizador ou escolhendouma de entre várias opções mais comuns. A primeira opção permite a cada utilizador ex-pressar mais detalhadamente o significado de um determinado local. No entanto, corre-seo risco de esta classificação não ser reconhecida ou de não ter qualquer significado paraas aplicações e serviços.Zhou et al. [ZFL+07] descreve algumas formas de recolher essa informação do utiliza-dor. Uma das formas é permitir ao utilizador identificar cada local a partir de um mapainteractivo. Outra forma passa pela identificação no próprio local, através do dispositivo.Esta classificação manual pode ser facilitada através de um sistema colaborativo entre vá-rios utilizadores. O sistema SerPens [BKNF08] associa os termos semânticos atribuídospelos utilizadores a cada local e permite, posteriormente, que outros utilizadores reutili-zem termos já atribuídos.

3.2.2.2 Classificação Automática

Métodos automáticos têm sido explorados mais recentemente para identificar o signi-ficado que os vários locais têm para cada utilizador, sem ser necessária qualquer indica-ção por parte destes. Alguns métodos mais simples utilizam termos utilizados por outras

24


aplicações para fazer esta classificação. Naaman et al. [NSPGM04] comparam as coorde-nadas obtidas com uma base de dados com coordenadas de várias regiões administrativasdos Estados Unidos por forma a adicionar informação de localização como “arredores deSan Francisco” ou “40 km a Sul de San Jose”, numa colecção de fotografias.Outras fontes úteis, onde se podem encontrar informação sobre locais, incluem serviçosGIS, motores de busca geográficos e aplicações de calendário [ZFL+07, Bha09].Adams et al. [APV08] dividem os locais encontrados segundo as classificações “CASA”,“TRABALHO” e “OUTRO”. Para tal, estes autores aplicam filtros temporais, por exem-plo, classificando como “CASA” locais onde as posições são detectadas antes das 7:00 ouapós as 19:00. Esta informação pode ser melhorada baseada em informação sobre zonasurbanas a partir de serviços GIS. Os autores reconhecem também o problema deste modode classificação relativamente a pessoas com trabalhos nocturnos ou vários empregos ereferem que algoritmos mais sofisticados são necessários para lidar com variações noshábitos dos utilizadores.Moreira e Santos [MS05] baseiam-se numa “hora de pico” para determinar a casa de umadeterminada pessoa. Esta abordagem assenta no pressuposto de que o utilizador passamais horas por dia em casa. Estes autores também conseguem determinar, através dashoras de pico inversas, o local de trabalho da mesma pessoa.Zhou et al. [ZBST07] recorrem ao número de leituras por dia para determinar locais im-portantes para cada pessoa e indicar o local provável onde moram.

3.3 Reconhecimento de Actividades

O processo de inferência de actividades procura determinar, a partir de diversos sen-sores, as acções de interesse que uma determinada pessoa está a realizar. Exemplos deactividades comuns em sistemas baseados em contexto incluem se uma pessoa está a an-dar, a correr ou a dormir. Neste capítulo são descritos alguns métodos apresentados naliteratura que permitem resolver estes problemas. Estes métodos podem inferir sobre aactividade de uma pessoa a partir de dados de localização, sensores e imagens de vídeo.Como no âmbito deste trabalho a framework é limitada a dados de localização e aos senso-res disponíveis nos smart phones mais comuns, não são abordados métodos que utilizemimagens de vídeo.De seguida, são apresentados vários métodos existentes no reconhecimento de activida-des, divididos em dois tipos de abordagem: por inferência lógica e por aprendizagemcomputacional.

25


3.3.1 Reconhecimento por Inferência Lógica

Certas actividades podem ser deduzidas a partir de outros contextos já conhecidos.Por exemplo, se uma pessoa se encontra de madrugada em casa, inactivo e num localcom fraca iluminação é provável que se encontre a dormir. É possível afirmar com maiorcerteza tal facto se for possível introduzir mais informação, por exemplo, se esta pessoase encontra deitada ou no quarto.Os métodos de inferência lógica baseiam-se assim em representações lógicas de cadatipo de actividade. Esta representação pode ser descrita de várias formas tais como pre-dicados em linguagens de programação lógica [Lok06] ou através de lógica descritiva(DL) [BGB06]. Na Listagem 3.1 encontra-se um exemplo de regras baseadas em predica-dos lógicos retirado de [RC03]. Outra forma pode ser através de ontologias. Por exemplo,uma actividade pode estar associada ao uso de determinados objectos num determinadolocal e intervalo de tempo [TIH+07, YSK+07]. Na próxima secção são apresentadas di-ferentes formas de representação e ferramentas que permitem manter a consistência dosmodelos, assim como de inferir sobre a informação obtida.

1 Sound (Room 3234, ‘‘>’’, 40 dB) ∧2 Lighting (Room3234, Stroboscopic) ∧3 #People (Room 3234, ‘‘>’’, 6) ⇒4 Social Activity (Room 3234, Party)

Listagem 3.1: Exemplo de uma regra baseada em predicados lógicos.

Os métodos que utilizam inferência lógica são, em geral, bastante eficazes e simples deimplementar, sofrendo, contudo, de alguns problemas. Em primeiro lugar, as definiçõessão geralmente estáticas, tendo pouco poder de aprendizagem [CN09]. Isto leva a quetais modelos não tenham em consideração exemplos excepcionais, por exemplo, pessoasque tenham um emprego nocturno. Por outro lado, é difícil modelar regras para grandesquantidades de valores contínuos, por exemplo, inferir uma actividade com base em valo-res obtidos através de sensores de movimento em vários objectos. Estes métodos tambémnão são apropriados em sistemas que necessitem de lidar com conhecimento imperfeito edados susceptíveis a variações (por exemplo, na localização por GPS) [BPAP08].

3.3.2 Reconhecimento por Aprendizagem Computacional

O problema de reconhecimento de actividades pode ser visto como um problema declassificação sobre determinadas instâncias definidas por valores de sensores. Os méto-dos de aprendizagem computacional recorrem a algoritmos que partem de um conjuntode treino, isto é, um conjunto de instâncias de contexto cujas actividades se encontramclassificadas a priori. As novas instâncias por classificar são depois processadas segundo

26


Figura 3.9: Árvore induzida através do algorimto C4.5 no projecto UPCASE

o treino efectuado. Este método é geralmente preferido em relação a outras abordagens,especialmente quando se pretendem definir regras que relacionem os dados provenientesde vários sensores com o contexto correspondente ou quando estes valores são em grandenúmero e muito susceptíveis a variações e erros de leitura [CN09].Um dos métodos mais utilizados é baseado em redes Bayesianas. Os Hidden Mar-kov Models são uma forma simples destas redes, muito usadas para tratar dados vin-dos de sensores aplicados em sujeitos e objectos [PFKP05, WL+06], mais especifica-mente acelerómetros. Philipose et al. [PFP+04] e Wang et al. [WPP+07] utilizam redesBayesianas dinâmicas (Dynamic Bayesian Network) em problemas semelhantes. Yin etal. [YCY04] também utilizam DBN, mas sobre um modelo baseado nos registos de lo-calização GPS do utilizador a que chamam Location-based Activity Recognition (LAR).Mais tarde, desenvolveram um novo modelo baseado apenas em segmentos desses regis-tos — Segmentation-based Activity Recognition (SAR) [YYSL08].Outros métodos de aprendizagem explorados neste âmbito incluem algoritmos de apren-dizagem de árvores de decisão (Decision Trees) como a que pode ser vista na Figura 3.9,retirada de [STC+09]. Os trabalhos mencionados em [TIH+07] e [STC+09] recorrem aoalgoritmo C4.5, um dos algoritmos baseados em DT mais utilizados.

Menos utilizados no reconhecimento de actividades, mas também dignos de mencio-nar, são o algoritmo k-NearestNeighbours (k-NN) e as Support Vector Machines (SVM).A utilização de SVM no reconhecimento de actividades a partir de sensores é referidaem [Huy08] e o algoritmo k-NN em [LM02]. Ravi et al. [RDML05] implementam váriasversões dos últimos algoritmos mencionado e fazem uma avaliação para diferentes cená-rios, utilizando um único acelerómetro. Estes autores conseguiram obter resultados muitoprecisos ao combinar os resultados dos vários algoritmos através de uma votação.

27


3.4 Sumário

Neste capítulo foi apresentado o Estado da Arte em 3 áreas relacionadas com o pro-jecto desenvolvido.Foram apresentados alguns dos mais recentes sistemas baseados em informação de con-texto e as respectivas abordagens utilizadas. Estes sistemas descritos foram divididos daseguinte forma:

• Sistemas baseados em regras, que representam o conhecimento sobre a forma depredicados lógicos ou descrições baseadas em XML e utilizam regras para relacio-nar os diferentes conceitos e motores de regras para as executar;

• Sistemas baseados em ontologias, que utilizam linguagens de descrição de ontolo-gias como OWL para representar o conhecimento e recorrem a motores de inferên-cia (reasoners);

• Sistemas baseados em casos, que utilizam conhecimento sobre instâncias anteriorespara inferir sobre novas instâncias.

Foram também apresentados os principais algoritmos utilizados para identificar locais apartir de um conjunto de posições GNSS. Os algoritmos descritos foram divididos se-gundo as seguintes categorias:

• Algoritmos baseados em distância, que recorrem a parâmetros de distância e tempopara separar um conjunto de posições em diferentes locais;

• Algoritmos baseados em densidade, que recorrem a dois principais parâmetros paraencontrar os locais mais frequentes sobre um conjunto de posições;

• Algoritmos baseados em modelos probabilísticos;

• Algoritmos baseados em “fingerprints, que trabalham sobre um conjunto de iden-tificadores em vez de posições GNSS. Estes algoritmos são úteis para identificarlocais a partir de redes wireless ou células GSM.

Foram também apresentados alguns métodos utilizadas para classificação de locais, quese podem dividir em métodos manuais — em que são os próprios utilizadores a fazer aclassificação (de forma colaborativa ou não) — e métodos automáticos que partem decertos pressupostos sobre os hábitos dos utilizadores.Para este trabalho serão utilizadas abordagens baseadas no algoritmo DJ-Cluster, um dosmelhores algoritmos na categoria dos algoritmos baseados em densidade, que têm a van-tagem de conseguir identificar locais com formas geométricas irregulares e, por isso, commaior precisão. Serão também explorados métodos automáticos na classificação dos lo-cais.

28


A última área coberta por este estudo do Estado da Arte foi o reconhecimento de activi-dades a partir de dados de sensores. Os métodos apresentados fora divididos em métodosbaseados em inferência lógica e métodos baseados em aprendizagem computacional.

29


30

Capítulo 4

Especificação da Solução

Neste capítulo são apresentados com maior detalhe os objectivos inicialmente propos-tos e que deverão ser cumpridos com este trabalho. É dada uma visão geral da soluçãoproposta por forma a cumprir estes objectivos, descrevendo também o seu funcionamentogeral e arquitectura.

4.1 Visão Geral

A framework de gestão de contexto que a PT Inovação se encontra a desenvolver temcomo objectivos iniciais possibilitar a implementação de uma série de serviços de reco-mendação e publicidade em tempo real. Para oferecer serviços de grande qualidade, énecessário que o sistema consiga adaptar-se rápida e eficazmente aos diversos contextosdo dia-a-dia de cada um dos destinatários desses serviços — utilizadores de determinadosprodutos integrados na framework desenvolvida.Durante o desenvolvimento deste projecto foi também necessário criar uma aplicaçãomóvel a partir da qual fosse possível extrair alguns novos tipos de informação de con-texto. Cada pacote contendo informação de contexto é enviado, segundo a arquitecturada framework já existente, para os respectivos fornecedores de contexto que validam essainformação e a publicam no mediador do sistema. Um novo fornecedor desenvolvido quesubscreve os nós correspondentes a essa informação vai recebendo assim as actualizaçõesdos dados de contexto recolhidos. A informação recebida é armazenada e é processadautilizando um motor de regras para inferir nova informação de mais alto-nível e tambémpublicar, por sua vez, esta nova informação no mediador.

31


4.2 Requisitos de Implementação

Nesta secção são apresentados os objectivos inicialmente propostos para o trabalhodesenvolvido assim como os requisitos mínimos esperados do sistema, principalmenteem termos de desempenho. Os objectivos esperados são divididos nas secções seguintes,segundo os diferentes tipo de problemas a abordar. Estes problemas são essencialmente aadaptação do sistema a vários tipos de informação de contexto, a recolha e publicação deinformação no sistema e o processo de inferência de contexto a partir dos dados recolhi-dos. Por fim, é descrito o âmbito do novo componente, nomeadamente a inferência sobrea localização e actividade dos utilizadores do sistema.

4.2.1 Definição dos Dados de Contexto

Um dos principais aspectos requiridos é a flexibilidade de utilização. O sistema devefacilmente ser adaptável a qualquer modelo de negócio que pretenda explorar o desenvol-vimento de serviços baseados em informação de contexto. Os tipos de informação trocadaentre o sistema dependem dos recursos disponíveis que possam ser utilizados na recolhade dados. Por exemplo, numa determinada área de negócio pode ser necessário explo-rar informação sobre programas televisivos vistos pelos utilizadores, enquanto outra podequerer saber quais os locais mais importantes que cada pessoa visita no seu dia-a-dia. Asregras utilizadas para inferir informação de mais alto-nível, não disponível directamenteatravés das fontes de contexto existentes, diferem, não só pela natureza do modelo utili-zado, mas também, consoante os recursos utilizados para recolher dados.O sistema deve portanto ser o mais genérico possível, permitindo aos administradoresespecificar o esquema dos dados a serem trocados assim como quaisquer regras de in-ferência necessárias e, a partir destas especificações, rapidamente lançar um novo forne-cedor que responda a estas necessidades, envolvendo o mínimo esforço de programaçãopossível.

4.2.2 Inferência de Contexto

A informação que chega das diversas fontes de contexto muitas vezes não é sufici-entemente significativa para expressar o contexto em que o utilizador se encontra. Umexemplo muito comum é a informação de localização. A informação de localização queé obtida através de GNSS é representada na sua forma mais básica por uma posição emtermos de latitude, longitude e altitude. Este tipo de informação bruta não possui qual-quer expressão nos termos que interessem à oferta de serviços baseados na localizaçãodo utilizador. Para determinar a posição em termos semânticos, é necessário processarestes dados. Esta computação é geralmente dispendiosa, tornando-se um factor muitoimportante porque muitos dispositivos usados na recolha de dados têm capacidades de

32


processamento e memória bastante limitadas.O que se pretende é implementar um novo tipo de fornecedor que possa centralizar todoo processo de inferência sobre os dados que são recebidos das várias fontes de contexto.Esta arquitectura tem também a vantagem de facilitar a adaptação do sistema a quaisquermudanças no processo de inferência, já que as alterações mais custosas são efectuadasapenas sobre um tipo de componente e não sobre cada uma das aplicações que publicama informação.Um requisito fundamental do novo fornecedor a implementar é portanto que este consigatransmitir a informação inferida dentro de um limite de tempo aceitável, preferencial-mente de forma a acompanhar em tempo quase real as mudanças de contexto publicadas.Definiu-se um tempo máximo de execução de 10 s como limite óptimo, podendo estender-se a um limite aceitável de 30 s, desde o momento em que os dados são recebidos até aomomento em que a nova informação é publicada.

4.2.3 Recolha e Publicação da Informação

O funcionamento geral do novo fornecedor passa por 3 processos ao longo da fra-mework existente: recolha, processamento e publicação dos dados. Uma vez que estecomponente deverá ser inserido nesta framework, os processos de recolha e publicaçãosão semelhantes aos dos fornecedores já existentes, como foi explicado no Capítulo 2.Deverão existir duas formas diferentes de um consumidor de contexto ter acesso à infor-mação inferida. A Figura 4.1 descreve a forma actualmente utilizada na grande maioriadas aplicações. O consumidor subscreve os nós correspondentes à informação inferida.Assim que o mediador recebe novos dados vindos de um qualquer fornecedor e casose trate de um nó subscrito pelo novo componente então essa mensagem é-lhe reencami-nhada. Este fornecedor processa esses dados e, eventualmente, publica a nova informação— através do protocolo de PubSub para XMPP — que tenha sido inferida a partir da ori-ginal. Após esta publicação, o consumidor recebe a informação que subscreveu sempreque uma actualização se verificar no mediador.A segunda forma consiste em enviar um pedido que, no protocolo XMPP, se traduz numpacote IQ (Info-Query) do tipo “get”. Neste pacote deve constar o nome dos tipos de con-texto que se pretende obter. Quando o fornecedor recebe uma mensagem deste tipo vaiefectuar inferência a partir dos últimos dados guardados na base de dados pertencentes aoutilizador que corresponde ao JID do remetente da query e envia uma mensagem de voltacom os tipos de contexto especificados. Este último caso é ilustrado na Figura 4.2.

4.2.4 Caso de Estudo: Informação Situacional

Como prova de conceito do sistema implementado pretende-se que o novo fornecedorpublique um novo tipo de informação designado informação situacional. No âmbito desta

33


Figura 4.1: Diagrama de sequência: comunica-ção entre o novo fornecedor e o mediador

Figura 4.2: Diagrama de sequência: comunica-ção entre o novo fornecedor e um consumidor decontexto

dissertação uma situação é definida pela associação de um determinado utilizador a umtipo de local e actividade num determinado instante de tempo. O sistema deve processaros dados obtidos a partir das fontes existentes e determinar a que tipo de local e actividadecorrespondem, dentro de um conjunto pré-definido de situações mais comuns do dia-a-dia.

Inicialmente pretende-se que o local em que o utilizador se encontra seja classificadosegundo os seguintes tipos:

• HOME: Habitação principal do utilizador;

• WORK: Local de trabalho;

• SHOP: Local de compras, por exemplo, um centro comercial ou loja de conveniên-cia;

• FOOD: Estabelecimentos de restauração, por exemplo uma cantina, restaurante oumesmo uma confeitaria;

• STOP: Paragem ou estação de transportes públicos, como estações de comboio,paragens de autocarro ou praças de táxis;

• ENTERTAINMENT: Local de lazer e diversão, tais como cinemas, parques dediversão ou discotecas;

• SCHOOL: Escolas e outros estabelecimentos de ensino;

• SPORT: Local dedicado a actividades desportivas, por exemplo, estádios de futebolou ginásios.

34


• OTHER: Local significativo que não se enquadra em nenhuma das anteriores. Podesignificar, a título de exemplo, a casa de uma outra pessoa que o utilizador visitefrequentemente.

Para além de um local, cada utilizador pode estar associado a uma determinada acti-vidade que pode ser uma das seguintes:

• SLEEPING (a dormir);

• WORKING (a trabalhar);

• WALKING (a andar);

• RUNNING (a correr);

Este novo tipo de informação permitirá assim aplicar a framework de gestão de con-texto desenvolvida em áreas de negócio tais como o advertising e a recomendação deconteúdos, levando em conta os gostos do utilizador e os momentos mais apropriadossegundo o contexto em que se encontra. A título de exemplo e no âmbito dos serviços derecomendação e publicidade, esta informação permite que seja enviada publicidade sobredescontos se estiver num local de compras e evitar o envio de mensagens se o utilizadorestiver a dormir ou a trabalhar.

4.3 Desenho do Sistema

Nesta secção é apresentada a solução implementada por forma a cumprir os objectivosanteriormente descritos. Na Secção 4.3.1 encontra-se descrita a arquitectura física do sis-tema, os vários componentes utilizados neste trabalho e a sua distribuição. A Secção 4.3.2foca-se no novo fornecedor implementado, descrevendo sucintamente os diferentes mó-dulos que constituem este componente. Uma explicação mais detalhada dos mesmos éfeita ao longo dos capítulos seguintes.

4.3.1 Arquitectura Física

O sistema ao qual o fornecedor inteligente de contexto pertence foi desenhado paracorrer em 3 nós, como pode ser visto na Figura 4.3. Um nó consiste numa máquina acorrer o servidor Openfire. Este servidor é responsável por gerir um conjunto de for-necedores, escritos em linguagem Ruby, que servem de intermediário entre um tipo deinformação de contexto diferente e o broker. O servidor executa também um componentebaseado no Idavoll1, uma implementação em Python do servidor de Publish-Subscribe2

1http://idavoll.ik.nu/2Extensão XEP-0060 para XMPP: http://xmpp.org/extensions/xep-0060.html

35


e que recorre a uma base de dados CouchDB para armazenar as mensagens de contextopublicadas.Numa segunda máquina corre o fornecedor de informação situacional desenvolvido. Estenó também tem instalado o servidor de base de dados MySQL (ver Secção 5.2).O sistema inclui ainda um programa Java responsável pela identificação e classificaçãodos locais significativos (ver Capítulo 7). Este programa percorre a base de dados de cadautilizador e é invocado periodicamente (por exemplo, uma vez por semana) numa terceiramáquina que possa dedicar esse tempo a esta função. Esta decisão foi tomada tendo emconta questões de optimização do desempenho e utilização da memória.

4.3.2 Arquitectura Lógica

Do ponto de vista da estrutura lógica do sistema, o fornecedor é constituído por 4 mó-dulos designados SmartProvider, ContextReasoner, LocationLearner e ContextDatabase.O diagrama de pacotes representado na Figura 4.4 mostra a dependência entre estes mó-dulos.O SmartProvider é o componente central do fornecedor implementado. Consiste numaimplementação Java de um componente externo XMPP que subscreve um conjunto denós do PubSub relativos aos dados que chegam da aplicação Android. Este componenterecebe então todas as actualizações desses dados, processando essa informação atravésdo motor de regras de inferência. O SmartProvider publica então os resultados obtidosa partir de cada mensagem recebida e armazena toda a informação relevante na base dedados relacional.O ContextReasoner é uma interface simples, também em Java, entre o motor de regrasutilizado (Jess) e o SmartProvider.O LocationLearner é outro módulo Java que implementa os algoritmos de agregação eclassificação, permitindo uma aprendizagem incremental das diferentes localizações aolongo do tempo. Esta aprendizagem é feita através de um conjunto de interfaces que per-mitem ao SmartProvider adicionar cada ponto sequencialmente, actualizando os grupos(clusters) existentes em função de cada nova informação GPS que recebe.O módulo ContextDatabase consiste em mais uma interface Java entre o SmartProvidere a base de dados MySQL. Esta interface é conseguida através do mapeamento entre umconjunto de classes — um JavaBean para cada objecto da base de dados — e as respecti-vas tabelas. Cada uma destas classes corresponde a um objecto de contexto da bibliotecaexistente, adicionando também outros dados tais como os instantes de tempo inicial e finale a respectiva duração. Esta interface é explicada mais detalhadamente na Secção 5.2.5.

36


Figura 4.3: Diagrama de distribuição do sistema implementado

Figura 4.4: Diagrama de pacotes do fornecedor inteligente

37


4.4 Sumário

Neste capítulo são apresentados os objectivos inicialmente propostos para o projectodesenvolvido, assim como o desenho da solução implementada em termos da arquitecturafísica e lógica.

Os objectivos propostos passam, de forma resumida, por implementar um novo for-necedor de contexto (ver Secção 2) onde se possa centrar todo o processamento da in-formação de contexto por forma a inferir nova informação de mais alto-nível. O novofornecedor deverá facilmente adaptar-se a quaisquer tipos de informação de contexto quese encontrem definidos e a diferentes requisitos através de alterações mínimas no códigoe ficheiros de definição das regras de inferência. As principais restrições ao fornecedorestão relacionadas com o seu desempenho, devendo este componente publicar as novasinformações inferidas num tempo limitado. Para este projecto pretende-se utilizar o novofornecedor para inferir sobre a situação do utilizador em termos dos tipos de localizaçãoe actividade.

A solução implementada foi desenhada por forma a aproveitar as vantagens do pro-tocolo XMPP de forma a facilitar a comunicação entre componentes do sistema e a suaescalabilidade. O novo fornecedor é constituído pelos seguintes módulos:

• ContextDatabase , uma framework baseada em Hibernate que oferece uma interfaceentre os restantes módulos e a base de dados relacional utilizada;

• ContextReasoner , uma interface simples a servir de camada superior sobre um mo-tor de regras Jess;

• LocationLearner , o módulo onde se encontram implementados os algoritmos deidentificação e classificação de locais significativos;

• SmartProvider , o módulo responsável por receber e publicar a informação de con-texto e coordenar o processamento dos dados entre os restantes módulos.

OS módulos anteriormente referidos assentam em tecnologias Java que facilitam a suaintegração.

38

Capítulo 5

Publicação e Armazenamento de Dados

Neste capítulo é descrita a implementação detalhada do sistema construído no âmbitodeste projecto. É descrita a arquitectura do sistema assim como cada um dos compo-nentes existentes, apresentando as tecnologias usadas e explicando as principais decisõestomadas.

5.1 Publicador de Contexto

No âmbito da identificação e classificação dos locais significativos para os utilizadoresfoi escolhida uma aplicação para Android que já se encontrava em desenvolvimento naPT Inovação.Um grande número de publicações na área dos sistemas baseados em contexto apresentaformas de inferir a situação dos utilizadores com base em sensores designados wearables,isto é, sensores que são espalhados de forma mais ou menos estratégica pelo corpo empeças de roupa e similares. Ao longo destes anos de investigação e desenvolvimento,os avanços nesta área têm alcançado formas cada vez mais discretas para este tipo desensores. Uma alternativa ou adição a estes sistemas de sensores passa pelos dispositi-vos móveis. Actualmente, muitos dos smart phones existentes apresentam-se como umaboa opção para esta recolha. Em particular, os dispositivos com a plataforma Androidtêm ganho uma crescente popularidade nos últimos anos. Os modelos mais recentes vêmequipados de um conjunto de sensores básicos que incluem sensores de iluminação, ace-lerómetro e GPS. Estes dispositivos são uma fonte fiável do contexto dos seus utilizadorespois, do mesmo modo que com a carteira, os utilizadores mantêm regularmente os dispo-sitivos consigo.

39


5.1.1 Arquitectura e Funcionamento Geral

A aplicação assenta basicamente num serviço que corre em background, sem ser ne-cessária qualquer outra interacção por parte do utilizador a não ser para activar e desac-tivar a recolha de informação. Para este efeito, a aplicação possui uma interface muitosimples onde o utilizador pode alterar as definições de recolha e efectuar a autenticaçãono sistema.A recolha de informação é feita recorrendo a um conjunto de escutadores (listeners), amaioria a correr assincronamente (na forma de uma implementação da interface Async-Task ). O envio da informação de contexto é desencadeado quando ocorre qualquer altera-ção do estado anterior, quer imediatamente, como é o caso da informação sobre a conec-tividade, quer após um período de tempo (regra geral 60 s) ao fim do qual o valor máximoé obtido. Esta última medida foi tomada por forma a poupar bateria, memória e proces-samento, caso contrário a utilização da aplicação seria muito ineficiente. Considerou-seportanto que 1 min seria um intervalo de tempo suficiente para manter actualizada a in-formação acerca da situação em que se encontra o utilizador e evitar enviar alteraçõesinsignificantes do contexto do utilizador.A aplicação envia instantaneamente a informação recolhida se o dispositivo se encontrarligado a uma rede wireless. Caso contrário, grava temporariamente a informação numabase de dados até que o envio seja possível. Esta última medida foi tomada apenas porser necessário manter um histórico constante dos utilizadores para posterior utilização nafase de aprendizagem (ver Capítulo 7).

5.1.2 Informação de Contexto Publicada

A PT Inovação já possuía um protótipo de divulgador de contexto para Android que,correndo como um serviço em background, tem como principal propósito recolher a lo-calização GPS e enviá-la ao respectivo fornecedor de contexto. Esta aplicação foi modi-ficada no âmbito deste projecto para recolher outros tipos de contexto, à semelhança doque era feito com a localização.A localização GPS é fundamental no âmbito da vertente científica do projecto. Os al-goritmos de agregação baseiam-se exclusivamente nas posições para formar grupos delocalizações. Os restantes tipos de contexto são usados para inferir a situação em queo utilizador se encontra correntemente, informação que é posteriormente utilizada paraclassificar alguns desses locais em termos semânticos.A Tabela 5.1 resume os tipo de informação recolhidos pela aplicação Android e que sãoexplicados com maior detalhe nas secções seguintes.

40


Tabela 5.1: Informação de contexto recolhida pela aplicação para Android

Tipo Campo Descrição Medida

GPS

accuracy possível desvioquanto à posiçãoreal

m

altitude altitude mbearing direcção da bús-

sola relativamentea um ponto de des-tino

o

latitude latitudelongitude longitudespeed velocidade aproxi-

mada a que o dis-positivo se deslocacalculada pela mu-dança de posiçãoao longo do tempo

m/s

Ruído amplitude valor máximo daamplitude gravadaa partir do micro-fone do dispositivo

[0;12,5]

Movimentospeed velocidade aproxi-

mada a que o dis-positivo é movido,calculada a partirdos valores do ace-lerómetro

m/s

frequency Número de varia-ções de velocidadedetectadas no dis-positivo por sensi-velmente 1 min

Luminosidade brightness valor da ilumina-ção recebida pelosensor de luz dodispositivo

lux

Conectividadewifi estado da ligação a

redes wireless{’enabled’, ’disa-bled’}

mobile estado da ligação3G do dispositivo

{’unavailable’,’connected’,’disconnected’}

networks lista dos SSID dasredes WiFi detec-tadas pelo disposi-tivo

41


1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/gps"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/gps">5

6 <complexType name="GpsType">7 <sequence>8 <element ref="tns:accuracy" maxOccurs="1" minOccurs="0"></element>9 <element ref="tns:altitude" maxOccurs="1" minOccurs="0"></element>

10 <element ref="tns:bearing" maxOccurs="1" minOccurs="0"></element>11 <element ref="tns:latitude" maxOccurs="1" minOccurs="1"></element>12 <element ref="tns:longitude" maxOccurs="1" minOccurs="1"></element>13 <element ref="tns:speed" maxOccurs="1" minOccurs="0"></element>14 </sequence>15 </complexType>16

17 <element name="gps" type="tns:GpsType"></element>18 <element name="latitude" type="double"></element>19 <element name="longitude" type="double"></element>20 <element name="altitude" type="double"></element>21 <element name="bearing" type="double"></element>22 <element name="speed" type="double"></element>23 <element name="accuracy" type="double"></element>24 </schema>

Listagem 5.1: Schema para a informação de GPS.

5.1.2.1 Localização GPS

A recolha da informação de GPS é feita através de um objecto LocationManager, dis-ponível em todas as versões da API do Android. Este objecto possui um método reques-tLocationUpdates que aceita 4 parâmetros: o nome do provider a utilizar, uma distânciae tempo mínimos e um objecto da classe LocationListener que implementa uma série defunções que são invocadas quando ocorre algum evento sobre o LocationManager .O nome do provider é obtido através do método getBestProvider usando um conjunto decritérios de forma a obter o melhor provider disponível em termos de precisão, quantidadede dados e poupança de energia. Quando o melhor provider se encontra indisponível (quegeralmente utiliza satélites para determinar a posição do dispositivo) é utilizado, se estiverdisponível, um provider que utiliza as redes wireless para determinar a posição. Este úl-timo tipo de provider é menos preciso. No entanto, é útil quando o utilizador se encontradentro de um edifício, onde geralmente a posição GPS é impossível de obter. A distânciamínima escolhida é bastante relevante. Por um lado, há que ter em conta que geralmenteexiste algum erro na posição GPS determinada, o que significa que posições diferentespodem ser obtidas mesmo quando o utilizador se encontra parado no mesmo local. Nãoconvém, por isso, definir uma distância mínima muito pequena. O valor definido paraesta aplicação é de 10 m, um valor geralmente maior que o desvio encontrado, evitando

42


que algumas falsas mudanças de posição sejam enviadas e dando uma boa margem paradetectar diferentes edifícios durante os percursos do utilizador. O tempo mínimo corres-ponde ao intervalo de tempo entre actualizações. Este valor é meramente indicativo deforma a permitir poupar bateria, podendo na realidade ser um pouco menor ou maior emfunção do dispositivo. O valor utilizado é o mínimo recomendado: 60 s.

5.1.2.2 Ruído

1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/sensor/noise"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/sensor/noise">5

6 <complexType name="NoiseType">7 <sequence>8 <element ref="tns:amplitude" maxOccurs="1" minOccurs="1"></element>9 </sequence>

10 </complexType>11

12 <element name="noise" type="tns:NoiseType"></element>13 <element name="amplitude" type="double"></element>14 </schema>

Listagem 5.2: Schema para a informação de ruído.

O nível de ruído é um tipo de informação bastante importante para detectar a situaçãoem que o utilizador se encontra. Por exemplo, ainda esta não seja uma inferência semprecorrecta, é mais provável que o utilizador esteja a dormir se o nível de ruído detectado formuito reduzido. De forma semelhante, se um nível de ruído alto e constante for detectado,pode significar que a pessoa se encontra num local cheio de gente.O nível de ruído não é tão trivial de obter, uma vez que não existe um provider nativo daAPI do Android próprio para este efeito. A solução encontrada foi utilizar as funcionalida-des de gravação de som presentes na API do Android, nomeadamente o MediaRecorder .O serviço grava de forma provisória um ficheiro de som a partir do microfone durantesensivelmente 60 s, ao fim do qual é extraído o valor máximo da amplitude de som atra-vés do método getMaxAmplitude. Esta amplitude corresponde a um valor decimal quevaria sensivelmente na gama [0; 12,5] para todos os dispositivos em que foram feitos ostestes. É utilizado um threshold de 1,0 para que uma diferença seja detectada e enviada aorespectivo fornecedor de contexto. No entanto, esta funcionalidade não foi correctamentesuportada por alguns dispositivos testados em plataformas com versões anteriores à 2.1.Nos restantes casos, foi registada uma carga considerável do processador.

43


5.1.2.3 Movimento

1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/sensor/accelerometer"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/sensor/accelerometer">5

6 <complexType name="AccelType">7 <sequence>8 <element ref="tns:frequency" maxOccurs="1" minOccurs="1"></element>9 <element ref="tns:speed" maxOccurs="1" minOccurs="1"></element>

10 </sequence>11 </complexType>12

13 <element name="accelerometer" type="tns:AccelType"></element>14 <element name="speed" type="double"></element>15 <element name="frequency" type="long"></element>16 </schema>

Listagem 5.3: Schema para a informação do acelerómetro.

A informação de movimento do dispositivo é extraída a partir dos valores do acele-rómetro, um recurso disponível em praticamente todos os dispositivos móveis recentes.Estes valores são obtidos através do registo de um SensorEventListener na API do Sen-sorManager . Este escutador retorna 3 variáveis correspondentes à força registada nosrespectivos eixos. De notar que a força da gravidade é sempre registada e, portanto, ovalor por omissão num dispositivo imóvel corresponde ao valor desta força.A informação de contexto a ser enviada contém dois campos: a velocidade e a frequência.A velocidade corresponde ao valor estimado de algum movimento feito em determinadaaltura sobre o telemóvel e é calculada segundo a expressão

speed =∣∣∣√x2 + y2 + z2−g

∣∣∣em que x, y e z correspondem aos valores das forças exercidas nos 3 eixos do acelerómetroe g ao valor constante da força da gravidade (' 9,8 m/s).

A frequência de movimento corresponde ao número de picos detectados na velocidadedo dispositivo, isto é, procura descrever o número de movimentos feitos que ultrapassemum determinado valor limite. As aplicações em utilização têm este valor definido em 1,0m/s.Tal como nos restantes tipos de informação, o divulgador de contexto correspondentegrava o máximo valor de velocidade registado e envia este valor juntamente com a frequên-cia somada até ao momento, repondo este último valor a 0.O valor da velocidade máxima permite determinar se o dispositivo se manteve parado ou

44


não e qual o grau de movimento detectado. Contudo, surgiu a necessidade de registartambém a frequência de movimento para diferenciar algumas situações distintas.

5.1.2.4 Luminosidade

A ideia de recolher o valor de luminosidade pretende identificar, em conjunto com onível de ruído, o tipo de ambiente em que o utilizador se encontra. Este valor correspondeao nível de iluminação detectada pelo sensor de luz do dispositivo, um recurso que emboraesteja presente na grande maioria dos modelos de smart phone mais recentes é menoscomum que o acelerómetro nos modelos mais antigos. O valor da iluminação é obtido,tal como os valores de outros sensores, através da API do SensorManager .

1 <?xml version="1.0" encoding="UTF-8"?>

2 <schema targetNamespace="http://iex.ptin.pt/ctx/sensor/light"

3 xmlns="http://www.w3.org/2001/XMLSchema"

4 xmlns:tns="http://iex.ptin.pt/ctx/sensor/light">

5

6 <complexType name="LightType">

7 <sequence>

8 <element ref="tns:brightness" maxOccurs="1" minOccurs="1"></element>

9 </sequence>

10 </complexType>

11

12 <element name="light" type="tns:LightType"></element>

13 <element name="brightness" type="double"></element>

14 </schema>

Listagem 5.4: Schema para a informação de luminosidade.

5.1.2.5 Estado da Conectividade

A informação sobre o estado da conectividade pretende informar o sistema sobre oestado da ligação WiFi e 3G do dispositivo (se está activada, desactivada ou mesmo in-disponível) e quais a redes detectadas pelo dispositivo, incluindo qual a rede a que outilizador se encontra ligado. Este tipo de informação pode ser bastante útil para inferiras actividades do utilizador e mesmo relacionar locais significativos e redes disponíveisnesses mesmos locais. Isto pode permitir, posteriormente, inferir sobre a localização doutilizador mesmo quando não esteja disponível qualquer informação recente sobre a sualocalização GPS.Para recolher esta informação, o serviço que corre em background “escuta” alteraçõessobre o estado da conectividade através da implementação de um BroadcastReceiver e os

45


dados são obtidos através do ConectivityManager presente na API de qualquer versão daplataforma Android.

1 <?xml version="1.0" encoding="UTF-8"?>

2 <schema targetNamespace="http://iex.ptin.pt/ctx/connectivity"

3 xmlns="http://www.w3.org/2001/XMLSchema"

4 xmlns:tns="http://iex.ptin.pt/ctx/connectivity">

5

6 <complexType name="ConnectivityType">

7 <sequence>

8 <element ref="tns:wifi" maxOccurs="1" minOccurs="1"></element>

9 <element ref="tns:mobile" maxOccurs="1" minOccurs="1"></element>

10 <element ref="tns:networks" maxOccurs="1" minOccurs="0"></element>

11 </sequence>

12 </complexType>

13

14 <complexType name="NetworksType">

15 <sequence>

16 <element ref="tns:ssid" maxOccurs="unbounded" minOccurs="0"></element>

17 </sequence>

18 </complexType>

19

20 <complexType name="SsidType">

21 <simpleContent>

22 <extension base="string">

23 <attribute name="connected" type="boolean" />

24 </extension>

25 </simpleContent>

26 </complexType>

27

28 <simpleType name=’wifiStatus’>

29 <restriction base=’string’>

30 <enumeration value=’enabled’ />

31 <enumeration value=’disabled’ />

32 </restriction>

33 </simpleType>

34

35 <simpleType name=’mobileStatus’>

36 <restriction base=’string’>

37 <enumeration value=’connected’ />

38 <enumeration value=’disconnected’ />

39 <enumeration value=’unavailable’ />

40 </restriction>

41 </simpleType>

42

43 <element name="connectivity" type="tns:ConnectivityType"></element>

44 <element name="wifi" type="tns:wifiStatus"></element>

45 <element name="mobile" type="tns:mobileStatus"></element>

46


46 <element name="networks" type="tns:NetworksType"></element>

47 <element name="ssid" type="tns:SsidType"></element>

48 </schema>

Listagem 5.5: Schema para a informação do estado da conectividade.

5.2 Armazém de Dados

A necessidade da implementação de uma base de dados relacional surgiu juntamentecom a necessidade de se poderem definir regras que utilizem não só o conhecimento sobreo contexto actual de uma pessoa mas também sobre o seu histórico. Era igualmente ne-cessário poder efectuar algumas interrogações do tipo: Em que momentos se verificaramníveis baixos em todos os sensores? Quantos dias o utilizador visitou determinado local?Inicialmente, os dados que chegavam das fontes de contexto eram mantidos apenas pelomediador do sistema numa base de dados não-relacional (CouchDB). Esta forma de ar-mazenamento não permitia, pelo menos de uma forma eficiente, determinar as respostasa interrogações como as exemplificadas anteriormente.Foi decidido implementar então uma base de dados relacional MySQL. MySQL é actual-mente o sistema de gestão de bases de dados mais popular, é open-source, muito estável,apresenta um bom desempenho e possui interfaces para as principais linguagens de pro-gramação existentes. O esquema da base de dados utilizado na recolha da informaçãovinda da aplicação utilizada durante o decorrer deste trabalho encontra-se representadona Figura 5.1.

5.2.1 Tabelas

O modelo usado na representação das várias classes centra-se na classe User , que re-presenta um utilizador da aplicação, identificado simplesmente pelo campo username databela users. Este campo corresponde ao nome de utilizador com que cada utilizador seencontra registado no servidor Openfire. Como a recolha de dados foi feita tendo em contaum dispositivo por utilizador, este identificador basta para associar os restantes dados aoutilizador. Caso o sistema seja posteriormente alargado a vários tipos de dispositivos for-necedores de contexto, bastará adicionar uma nova tabela cujos registos correspondam àinformação do dispositivo e associar dispositivo a um ou vários utilizadores. Em todo ocaso é já enviada a identificação do utilizador e respectivo dispositivo em cada mensagemde contexto (como foi referido na Secção 2.2).A cada utilizador estão associados vários objectos correspondentes a diferentes tipos decontexto utilizados. Estas tabelas possuem alguns elementos comuns. Cada registo éidentificado por um valor único em cada tabela e está relacionado através de uma chaveestrangeira à chave do respectivo utilizador. Cada tabela, com excepção das tabelas users

47


Figura 5.1: Modelo da Base de Dados

48


e clusters, tem também dois campos para identificar os instantes de tempo iniciais e finaisentre os quais ocorreu cada instância do contexto. Apenas o instante inicial é conhecidoaquando da gravação dessa mesma informação. O instante de tempo final é armazenadoposteriormente, com o valor do instante inicial do próximo contexto do mesmo tipo. Osrestantes campos representam os valores das propriedades de cada tipo de contexto con-forme definido nos schemas especificados (ver Anexo A).Existem contudo algumas tabelas que apresentam campos adicionais. Em primeiro lugar,a tabela raw_gps, onde são guardados os valores da localização GPS, está relacionada porchave estrangeira a um registo da tabela clusters. Esta tabela contém a informação so-bre as localizações (conjuntos de pontos) encontradas que deverão ter algum significadono dia-a-dia do utilizador. Estas localizações são representadas de forma mais simplifi-cada nesta tabela pelas coordenadas do centróide e pelo raio — distância máxima entreo centróide e os restantes pontos do grupo. Cada grupo tem também associado um ró-tulo (label) que indica o tipo de localização. Esta representação, mais simplificada, éutilizada apenas para facilitar a visualização do grupo de pontos pois, geograficamente,o seu formato pode ser demasiado irregular para ser representada através de um círculo.As operações de construção dos grupos são efectuadas na realidade sobre a colecção depontos da tabela raw_gps.Outra diferença existente entre as classes Java utilizadas e a sua representação na base dedados é o caso da informação da conectividade. Na base de dados é apenas guardado onome da rede à qual o dispositivo se encontra ligado, em vez de todas as redes encontra-das. Esta medida foi tomada para simplificar a representação, visto que essa informaçãoextra não foi utilizada no contexto deste trabalho. No caso do dispositivo não estar ligadoa qualquer rede o valor deste campo é nulo.As tabelas class_noise, class_light e class_accel guardam respectivamente os níveis infe-ridos sobre os sensores de ruído, luminosidade e movimento. Estes níveis, representadospor um número inteiro, estão directamente relacionados com o índice dos respectivosvalores no enumerado especificado no esquema correspondente. Estes níveis, que sãorepresentados textualmente nos respectivos ficheiros XSD, podem assim ser comparadosem termos de grandeza desde que estes valores se encontrem definidos por ordem cres-cente de valor. A título de exemplo, a classificação semântica da iluminação é descritapor 5 níveis ordenados crescentemente desde “very dark” até “very bright”.

5.2.2 Vistas

A base de dados possui uma única vista, para possibilitar mais facilmente a obtençãode algumas estatísticas sobre os grupos identificados, nomeadamente a duração total, onúmero de visitas e o tempo de estadia mais longo por dia. O código SQL correspondenteà vista referida pode ser visto na Listagem 5.6.

49


1 CREATE VIEW cluster\_day\_stats AS

2 SELECT clusters.id, SUM(timestampdiff(MINUTE,init,final)) AS duration, COUNT(∗) AS

visits, MAX(timestampdiff(MINUTE,init,final)) AS stay

3 FROM clusters join raw\_gps ON clusters.id = raw\_gps.cluster

4 GROUP BY clusters.id, DATE(init)

Listagem 5.6: Código SQL correspondente à vista cluster_day_stats.

5.2.3 Motor de Armazenamento

Todas as tabelas desta base de dados guardam os seus dados através do motor InnoDB.O motor InnoDB é normalmente aconselhado quando o número de escritas e actualiza-ções na base de dados supera em geral o número de leituras, enquanto que nos casosinversos o motor MyISAm é geralmente mais eficiente. No entanto, e apesar de se es-perarem muitas mais operações de leitura do que escrita, o primeiro motor foi escolhidopor permitir, ao contrário do segundo, manter a integridade dos dados através de transac-ções e rollback, restrições através de chaves-estrangeiras, aumentando assim a segurançae desempenho em operações concorrentes. Estes são factores muito importantes uma vezque o componente XMPP responsável por todas estas operações funciona em ambientemuti-thread.

5.2.4 Índices

Como foi referido anteriormente, o motor InnoDB perde geralmente eficácia em ter-mos de leitura da base de dados quando comparado ao motor MyISAM, que é o escolhidopor omissão. Como a grande maioria das operações a efectuar na base de dados serãode leitura é necessário colmatar essa deficiência através do mecanismo que este motoroferece para o feito: índices. O InnoDB gera automaticamente índices por cada chaveprimária definida nas tabelas. No entanto, dado que a maioria das interrogações incluemrestrições sobre outros campos das tabelas, foi decidido acrescentar um conjunto de índi-ces extra.A maioria das interrogações efectuadas pretende filtrar dados de um determinado utili-zador, incluindo portanto uma condição where sobre o campo user. Cada tabela tem,portanto, um índice do tipo HASH associado a este campo. Os índices tipo HASH fun-cionam apenas com operadores “=” e “<=>” mas oferecem melhor desempenho que osrestantes tipos de índices.Outro tipo de pesquisa frequente consiste em obter um conjunto de registos correspon-dente a um determinado instante ou intervalo de tempo. Como as interrogações utilizadasrecorrem geralmente ao operador BETWEEN, é utilizado nestes casos um índice B-TREE

50


Figura 5.2: Diagrama de classes do ContextDatabase

associado aos campos init e final. A lista completa de índices utilizados pode ser consul-tada na tabela do Anexo B.A utilização de índices tem 2 desvantagens: aumenta o espaço que a base de dados ocupaem disco e torna as operações de escrita mais lentas, pois o motor da base de dados temde actualizar estes ficheiros a cada actualização. Mais uma vez, como neste sistema asoperações de escrita são muito menos frequentes que as de leitura esta solução é maisvantajosa de modo geral. Em todo o caso, de forma a permitir a inserção de dados tãorápida quanto possível e assim reduzir o tempo de resposta do componente, a opção “DE-LAY_KEY_WRITE” foi activada. Esta opção permite que os dados sejam introduzidossem que os respectivos índices sejam actualizados imediatamente.

5.2.5 Mapeamento de Objectos Java

O ContextDatabase é um módulo implementado em Java onde é definida uma sériede classes que mapeiam os objectos da base de dados MySQL e criam interfaces paraadicionar, actualizar e obter registos. A Figura 5.2 representa parte do diagrama de clas-ses, neste caso das classes utilizadas para mapear a informação vinda do acelerómetropara a base de dados. As restantes classes, uma para cada tipo de contexto, encontram-semapeadas de forma semelhante.

A classe PersistentContext implementa uma série de propriedades comuns a todos astabelas que correspondem a tipos de contexto, ou seja, à maioria das tabelas. Todas asclasses que derivem de um tipo de contexto poderão assim simplesmente especializar estaclasse. Como a linguagem Java não permite herança múltipla entre classes, a solução paraincluir os restantes campos (distintos a cada tipo de contexto) passou por replicar na classede mapeamento cada um dos métodos presentes no objecto original correspondente. Parafacilitar a conversão entre objectos, cada uma destas classes inclui como membro um

51


objecto do tipo de contexto correspondente e duas funções que permitem alterar e obteresse mesmo objecto. Um exemplo dessa implementação pode ser visto na Listagem 5.7.

1 public class AccelRaw extends PersistentContext {

2

3 private AccelType accelraw;

4

5 public AccelRaw() { accelraw = new AccelType(); }

6

7 public void setSpeed(double speed) {

8 accelraw.setSpeed(speed);

9 }

10

11 public double getSpeed() {

12 return accelraw.getSpeed();

13 }

14

15 public void setFrequency(long frequency) {

16 accelraw.setFrequency(frequency);

17 }

18

19 public long getFrequency() {

20 return accelraw.getFrequency();

21 }

22

23 public void loadPojo(Object ctx) {

24 accelraw = (AccelType) ctx;

25 }

26

27 public Object toPojo() {

28 return accelraw;

29 }

30 }

Listagem 5.7: Implementação Java da classe AccelRaw.

Nem todas as classes que são definidas no módulo ContextDatabase correspondema informação de contexto. A classe User é igualmente mapeada na base de dados pelatabela users e relacionada por chave-estrangeira com as restantes tabelas. Esta classeimplementa uma interface que permitem obter mais facilmente os dados relativos a umadeterminada pessoa, incluindo a procura do contexto em determinado instante de tempoe a adição de novos dados à tabela.Também a classe Cluster é mapeada na tabela clusters. Esta classe é apenas usada pelomódulo LocationLearner para identificar os locais associados a cada posição GPS e, as-sim, determinar o local correspondente a cada instante de tempo.Esta interface faz uso da tecnologia Hibernate, uma implementação ORM open-source

52


para Java, que tem a vantagem de ser facilmente integrada em diferentes sistemas de ges-tão de bases de dados. Este mapeamento entre os membros de cada classe e as respectivascolunas da tabela é feita com base num conjunto de ficheiros XML. Na Listagem 5.8 podeser encontrado um exemplo desse mapeamento, o mapeamento entre a classe AccelRawda listagem 5.7 e a tabela raw_accel.

1 <hibernate-mapping package="c3s.component.provider.situation.database.models">

2 <class name="AccelRaw" table="raw_accel">

3 <id name="id">

4 <generator class="native" />

5 </id>

6 <property name="user" />

7 <property name="initial_time" type="timestamp" column="init" />

8 <property name="final_time" type="timestamp" column="final"/>

9

10 <property name="speed" />

11 <property name="frequency" />

12 </class>

13 </hibernate-mapping>

Listagem 5.8: Ficheiro de mapeamento entre a classe AccelRaw e a tabela raw_noise.

5.3 Sumário

Neste capítulo é apresentada a solução implementada para recolher informação decontexto dos utilizadores e armazenar essa informação de forma a posteriormente serprocessada.

Para recolher informação de contexto dos utilizadores é utilizada uma aplicação paradispositivos Android. Esta aplicação corre um serviço que envia a informação disponívelsobre a luminosidade, aceleração e nível de ruído, assim como a posição GPS e estado daconectividade do dispositivo.

Para armazenar a informação é utilizada uma base de dados relacional MySQL. NaSecção 5.2 são descritas as tabelas, índices e vistas utilizadas. É também apresentado omódulo baseado em Hibernate que serve de interface entre a base de dados referida e osrestantes módulos do novo fornecedor implementado, que são descritos em detalhe noCapítulo 6.

53


54

Capítulo 6

Inferência de Contexto

6.1 Componente Central

O SmartProvider corresponde ao módulo central e consiste num componente XMPPexterno. O componente foi desenvolvido na linguagem Java e consiste na implementaçãode um AbstractComponent da biblioteca tinder1. A classe AbstractComponent forneceuma interface simples para tratar vários tipos de mensagens que sejam enviados paraeste componente. Recorre-se também a um ExternalComponentManager da bibliotecawhack2 para gerir automaticamente, de forma multi-threaded, o componente criado.O funcionamento geral deste componente pode ser resumido pelo diagrama de sequênciada Figura 6.1. Este processo é activado cada vez que o componente recebe uma novaactualização vinda do mediador e consiste nas seguintes fases:

1. Processar a mensagem recebida, validando o formato e dividindo as diferentes in-formações de contexto que possa ter;

2. Mapear os objectos obtidos e inserir estes registos na base de dados através de umainstância ContextDatabase;

3. Caso se verifique a presença de uma nova posição GPS, actualizar os grupos depontos associados ao utilizador através da interface do LocationLearner;

4. Obter todos os últimos dados de contexto do utilizador e carregá-los na memória detrabalho de uma instância do ContextReasoner;

5. Executar o motor de regras de inferência e obter os objectos gerados;

6. Actualizar a base de dados com os dados inferidos;

7. Converter os objectos da base de dados em objectos da biblioteca de contexto epublicar cada objecto no respectivo nó do PubSub .

1http://www.igniterealtime.org/projects/tinder/2http://www.igniterealtime.org/projects/whack/

55


Um segundo caso consiste na interacção apresentada na Figura 4.2. Neste caso, osprocessos consistem em:

1. Processar o pedido de forma a obter os tipos de contexto especificados;

2. Obter os últimos dados para todos os tipos de contexto do utilizador e carregá-losna memória de trabalho de uma instância do ContextReasoner;

3. Executar o motor de regras de inferência e obter os objectos gerados;

4. Converter os objectos da base de dados para objectos da biblioteca de contexto eenviar uma mensagem com todos os itens pedidos.

Na aplicação implementada, este serviço pode correr até 20 threads em simultâneo, ovalor definido por omissão, mas que pode facilmente ser alterado se for necessário adaptara solução consoante os processadores disponíveis e o número de dispositivos a publicarinformação. O objecto SmartProvider da Figura 6.1 corresponde a uma única linha deexecução. A cada mensagem recebida é criada uma nova thread (até ao limite máximodefinido) que invoca a sua própria linha de execução podendo, assim, o processo descritoocorrer paralelamente em várias threads. Note-se que cada linha de execução mantém asua própria instância do ContextReasoner , mas a instância do ContextDatabase é única, oque permite, através da framework do Hibernate, lidar com transacções concorrentes semgerar conflitos.

6.2 Módulo de Inferência

O que torna este novo fornecedor diferente dos restantes fornecedores da frameworkda PT Inovação é o facto de ter a capacidade de produzir nova informação de contextoa partir dos dados que recebe. Esta capacidade é conseguida através da definição de umconjunto de regras e de um motor de regras que as executa quando novos dados de con-texto são adicionados à memoria do motor de regras.O módulo ContextReasoner consististe numa framework simples que oferece uma inter-face mais adaptada ao sistema implementado, facilitando a gestão da memória do motorde regras por parte do componente central.

6.2.1 Motor de Regras

O motor de regras escolhido é o Jess. A versão utilizada é a mais recente 7.13. Trata-sede um dos motores de regras mais rápidos e leves disponíveis, recorrendo a um algoritmoRete [For82, Doo95] para processar a informação. O Jess é escrito em linguagem Javamas executa comandos escritos numa linguagem própria baseada em Lisp. É possível,

3http://www.jessrules.com/jess/charlemagne.shtml

56


Figura 6.1: Diagrama de sequência do SmartProvider

57


no entanto, correr comandos Jess a partir de programas Java e este motor permite mesmocarregar modelos a partir de classes Java e operar sobre objectos dessas classes — desig-nados shadow facts.Este motor possui ainda algumas funcionalidades tais como a partilha de regras entreobjectos e mecanismos de sincronização, que o tornam apropriado para um ambientemulti-threaded.

6.2.2 Memória de Trabalho

No Jess, um objecto (neste caso, correspondente a um determinado tipo de contexto)que seja adicionado ao motor passa a representar um facto. Ao conjunto de factos domotor é chamado memória de trabalho (working memory).Uma vez que as regras são carregadas aquando da criação de uma instância do ContextRe-asoner e permanecem estáticas ao longo de todo o tempo, o motor de regras não conseguedistinguir exactamente quais os factos sobre os quais deve trabalhar e quais os anteriores.Por esta razão, e estando o motor de regras sujeito ao aparecimento constante de novosfactos, os factos são apagados da memória após cada ciclo de processamento. Para alémdisso, cada thread está associada a uma instância diferente do ContextReasoner . Estamedida permite também optimizar a memória física e o tempo de processamento das re-gras, uma vez que este processo é mais demorado quanto maior o tamanho da memóriade trabalho. A principal desvantagem é que esta medida implica que, em casos que sejanecessário usar dados de contexto anteriores, seja necessário interrogar a base de dadose carregá-los mais uma vez na memória de trabalho. Estes casos são, no entanto, poucofrequentes e actualmente ocorrem apenas durante o processo de classificação de locaissignificativos.

6.2.3 Ficheiro de Regras

As regras utilizadas pelo ContextReasoner podem ser lidas a partir de um ou maisficheiros. Estas regras podem ser escritas usando a linguagem própria do Jess ou numalinguagem XML como RuleML (Rule Markup Language) ou JessML (Jess Markup Lan-guage) — um formato usado apenas por este motor. Como as regras devem ser definidaspelos administradores do sistema e não existe ainda nenhuma interface que auxilie nestatarefa, optou-se por definir as regras no primeiro formato pois é menos extenso e maisintuitivo. O formato de regras do Jess é também mais poderoso que outras definições pa-drão porque permite incluir algumas condições complexas, incluindo o uso de expressõesregulares e definição temporária de variáveis.As regras definidas em Jess consistem basicamente numa expressão com dois elementos,separados pelo símbolo “=>”. Os comandos definidos à direita do símbolo são executados

58


Figura 6.2: Artefactos e dependências entre módulos do sistema

sempre que todas as condições descritas à esquerda do símbolo se verifiquem. O conjuntode regras utilizadas ao longo deste trabalho podem ser consultado no Anexo C.

6.3 Adaptabilidade do Sistema

Uma das características pretendidas era a flexibilidade de adaptação a novos tipos deinformação de contexto. Esta adaptação deve ser fácil, permitindo manter a consistênciados dados e reduzindo a (re)escrita de código ao máximo, já que qualquer alteração aocódigo traz sempre custos associados ao tempo adicional de programação e testes, alémde ser sempre susceptível a erros que aumentam esses custos.A framework desenvolvida, embora não seja totalmente automatizada, procura ir ao en-contro dessa solução. O diagrama presente na Figura 6.2 mostra as dependências entre osmódulos e os principais artefactos relacionados com este aspecto.

Para alterar ou acrescentar tipos de contexto é necessário:

• Descrever o esquema da informação a ser usada num ficheiro XSD. Este ficheiropermite gerar automaticamente uma série de classes (POJO) a serem incluídas narespectiva biblioteca;

• Se necessário, incluir novas regras que permitam gerar novos objectos a partir daspropriedades dos objectos já existentes. Estas regras devem ser definidas num fi-cheiro de texto, usando a linguagem própria para descrição de regras Jess.

Caso seja necessário utilizar a base de dados para armazenar o histórico do novo tipode contexto, é necessário adicionalmente:

• Criar a respectiva tabela na base de dados MySQL;

59


Figura 6.3: Tempos de execução do Fornecedor Inteligente

• Criar um novo ficheiro Java com a implementação da classe que vai mapear a tabelacriada. Salvo algum caso excepcional, a classe deverá especializar a classe Persis-teContext e incluir um objecto da classe definida e uma interface para modificar asrespectivas propriedades;

• Escrever o ficheiro XML com o mapeamento entre as propriedades do objecto defi-nido e as colunas respectivas da base de dados.

6.4 Análise de Desempenho

A avaliação do desempenho do novo fornecedor foi feita medindo o tempo de exe-cução e resposta a um conjunto de 100 mensagens de contexto enviadas, das quais 30continham informação de localização. O fornecedor foi testado numa máquina com pro-cessador de 2,8 Ghz e 2 GB de memória disponíveis a correr o sistema operativo Ubuntu.Os tempos de execução obtidos podem ser observados na Figura 6.3.

Os tempos de execução variam entre cerca de 700 e 4000 ms para mensagens decontexto sem localização e entre 6000 e 16000 ms para mensagens de localização. Estadiferença deve-se ao facto destas últimas mensagens implicarem uma actualização dosgrupos de pontos do utilizador, processo que demora cerca de 2 segundos de execuçãopara mais de 3370 pontos já conhecidos. O tempo de execução do motor de inferência estárelacionado com o tamanho da memória de trabalho, isto é, número de factos conhecidose o número de regras. Como estes números são muito reduzidos nesta fase, o tempo deexecução desta fase ronda os 500 ms.

Dos resultados obtidos é possível concluir que o novo fornecedor cumpre um bomdesempenho, dentro dos requisitos pedidos. Nos piores casos obtidos chegou aos 16 s,o que apesar de não ser considerado um tempo ideal, ainda permanece bem dentro doslimites razoáveis pedidos nesta fase.

60


6.5 Sumário

Neste capítulo foram apresentados os módulos SmartProvider e ContextReasoner donovo fornecedor implementado. Foi detalhado como o módulo SmartProvider procededesde a recepção de uma mensagem até á publicação da informação de contexto inferidapara dois casos: na subscrição de nós do serviço de Publish-Subscribe e quando recebeum pedido directamente dos consumidores de contexto. Foi também explicada de queforma este componente está pronto a ser executado em ambiente multi-thread, usandopara isso as bibliotecas whack e tinder para a construção de componentes XMPP.

Posteriormente foi apresentada a implementação do módulo ContextReasoner , umacamada que serve de interface com um motor de regras Jess. São descrito o funciona-mento do motor, nomeadamente a gestão dos factos na memória de trabalho do motor deregras, e a forma como as regras são definidas.

Por fim, é apresentado o resultado de testes de execução efectuados sobre o fornece-dor em termos dos tempos de execução durante o processamento de 100 mensagens dediferentes tipos de contexto.

61


62

Capítulo 7

Aprendizagem de Locais Significativos

Como prova de conceito do sistema implementado pretendia-se explorar um caso es-pecífico de inferência. Esta prova consiste em inferir sobre a situação em que uma pessoase encontra em termos de localização e actividade. Enquanto que a actividade pode serinferida através de um conjunto de regras sobre a informação já obtida, para o caso dalocalização não é tão trivial. Este capítulo descreve o módulo de aprendizagem compu-tacional implementado para identificar os vários locais relevantes do dia-a-dia de cadautilizador e, posteriormente, permitir classificar esses locais nos termos especificados naSecção 4.2.4.

7.1 Identificação de Locais Significativos

Uma forma básica de representar um local é através de formas geométricas simétricase regulares como um círculo ou rectângulo, em que basta definir atributos como o pontocentral e o raio ou os limites horizontal e vertical. No entanto, um sistema mais exactodeve permitir identificar regiões com formas geométricas irregulares. Para estes últimoscasos a única opção é representar cada localização pelo conjunto de pontos que o cons-tituem. No entanto, essas localizações não só não são conhecidas a priori como aindapor cima podem diferir muito de pessoa para pessoa. É necessário, portanto, aplicar me-todologias de aprendizagem automática para ir construindo incrementalmente cada umadessas zonas à medida que novas posições GPS chegam ao mediador do sistema. Nesteprojecto, foi implementada uma versão incremental do algoritmo DJ-Cluster [ZFL+07],que é descrita de seguida.

63


7.1.1 Conceitos

O algoritmo DJ-Cluster é baseado em 2 parâmetros fundamentais: um valor mínimode densidade e um valor mínimo de distância, designados daqui em diante por MinPtse Eps respectivamente. A vizinhança de um ponto geográfico é constituída pelos pontosque se encontram a distância máxima Eps deste. A distância (em m) é calculada deacordo com a fórmula da distância ortodrómica1 entre 2 pontos na Terra. A Listagem 7.1apresenta o código Java utilizado nesse cálculo.

1 public double getDistance(GpsRaw point) {

2 double pk = 180/3.14159;

3

4 double a1 = this.getLatitude() / pk;

5 double a2 = this.getLongitude() / pk;

6 double b1 = point.getLatitude() / pk;

7 double b2 = point.getLongitude() / pk;

8

9 double t1 = Math.cos(a1)∗Math.cos(a2)∗Math.cos(b1)∗Math.cos(b2);10 double t2 = Math.cos(a1)∗Math.sin(a2)∗Math.cos(b1)∗Math.sin(b2);11 double t3 = Math.sin(a1)∗Math.sin(b1);12 double tt = Math.acos(t1 + t2 + t3);

13

14 return 6366000∗tt;15 }

Listagem 7.1: Código Java utilizado no cálculo da distância geométrica entre dois pontos.

Um grupo (cluster) de pontos é formado por um grupo de pontos tal que todos os pon-tos possuam uma vizinhança (incluindo o próprio ponto) de pelo menos MinPts pontosou pertençam à vizinhança de pelo menos um ponto que cumpra este requisito. Todos osrestantes pontos são interpretados como ruído. Existem duas operações sobre um grupo:a inserção de um novo ponto e a remoção de um ponto existente. A junção de dois gruposconsiste em remover todos os pontos de um e inseri-los no outro.O algoritmo DJ-Cluster tradicional opera em duas fases principais: primeiro encontra to-dos os pontos cuja vizinhança tenha o valor (densidade) mínimo. Numa segunda fasejunta todos os grupos que tenham pelo menos um ponto em comum num único grupo.

7.1.2 Algoritmo IncDJ-Cluster

A variante incremental implementada segue os mesmos conceitos que o DJ-Cluster,mas permite operar sobre os pontos conhecidos de forma a gerar novos grupos à medida

1http://en.wikipedia.org/wiki/Great-circle_distance

64


que um novo ponto é inserido no conjunto. Este algoritmo, apresentado na Listagem 7.2,segue o princípio de que quando um novo ponto é inserido apenas os pontos na sua vizi-nhança, incluindo o próprio, estão habilitados a formar um novo grupo.

1 Cluster(point, Points, Clusters)

2 add point to Points

3 Neighborhood := neighbors(point, Points)

4 for each neighbor in Neighborhood do

5 Neighbors := neighbors(neighbor,Points)

6 if(Neighbors.size > MinPts)

7 cluster := new Cluster

8 add cluster to Clusters

9 while( Neighbors is not empty ) do

10 n := Neighbors[0]

11 c := n.cluster

12 if(c is not null) then

13 merge(c, cluster)

14 remove cluster from Clusters

15 remove c.points from Neighbors

16 cluster := c

17 else

18 add n to cluster

19 remove n from Neighbors

20 add cluster to Clusters

Listagem 7.2: Pseudo-código do algorítmo IncDJ-Cluster.

O algoritmo foi implementado como operação de uma classe Java IncDJClusterer , emque os parâmetros MinPts e Eps são guardados como membros privados das instânciasda classe. A execução do algoritmo é invocada com a chamada ao método cluster daclass IncDJClusterer que recebe 3 parâmetros: um novo ponto a ser inserido, uma lista depontos já anteriormente processados e uma lista dos grupos de pontos já conhecidos. Estemétodo retorna o objecto Cluster ao qual o novo ponto pertence ou um objecto nulo casotenha sido considerado ruído. Este ponto é também inserido na lista de pontos processadose a lista de grupos é actualizada.

7.1.3 Pré e Pós-Processamento

Um processo comum ao longo do algoritmo implementado é o cálculo da vizinhançade um ponto, que tem por base o cálculo da distância entre um ponto e todos os restan-tes pontos conhecidos. A complexidade deste algoritmo cresce portanto com o númerode posições conhecidas. Como a identificação de locais relevantes tem como princípioencontrar locais onde uma pessoa passa uma parte significativa do seu tempo, existem

65


alguns pontos que poderão ser descartados em função da duração de permanência. Pon-tos com uma curta duração (por exemplo, menos de um minuto) geralmente representamlocais encontrados durante a deslocação do utilizador entre dois locais e portanto não se-rão, à partida, significativos. Com base nesta ideia criou-se uma extensão ao algoritmode modo a filtrar pontos com uma duração muito curta. Existe então um novo parâmetro(MinStay) que representa o valor mínimo da permanência sobre um determinado ponto.Posições com duração menor que este limite são simplesmente ignorados pelo sistema.

Os algoritmos baseados em densidade como o DBSCAN ou o DJ-Cluster são tambémconhecidos por serem bastante sensíveis aos parâmetros MinPts e Eps [ZBST07, BS10].Um valor mais pequeno de MinPts pode ajudar a identificar mais locais, mas origina tam-bém mais falsos positivos. Por outro lado, um valor demasiado grande para Eps podefazer com que diferentes locais, mas muito próximos entre si, sejam identificados comoum só.Por forma a procurar obter melhores resultados explorando valores mais baixos nos pa-râmetros, foi implementada uma outra extensão ao algoritmo para uma fase de pós-processamento. Esta fase é executada a partir da invocação do método postProcess daclasse IncDJClusterer , que recebe como parâmetro uma lista de grupos conhecidos. Estesgrupos são posteriormente filtrados segundo dois atributos: duração máxima (MaxDura-tion) e dias visitados (MinVisits).O valor da duração máxima corresponde ao intervalo máximo do tempo em que o uti-lizador permaneceu nesse local em cada visita. Este valor é obtido através da seguinteinterrogação SQL:

SELECT MAX(stay) FROM clusters JOIN cluster_day_stats

ON clusters.id = cluster_day_stats.id WHERE clusters.id = ?

O valor dos dias visitados corresponde ao número de dias em que o utilizador foi encon-trado nesse local e é obtido através da interrogação SQL:

SELECT COUNT(*) FROM clusters JOIN cluster_day_stats

ON clusters.id = cluster_day_stats.id WHERE clusters.id = ?

7.1.4 Avaliação

De seguida são apresentados alguns testes efectuados sobre o algoritmo de identifi-cação de locais. Estes testes permitem não só verificar a eficiência do algoritmo em si,como são também importantes para determinar o comportamento e resultados obtidos,tendo em conta variações nos diversos parâmetros definidos. Foram realizadas execuçõessobre os dados recolhidos, medindo o período de tempo para cada combinação de parâ-metros dentro de uma gama representativa e foram registados os resultados em termosde precisão da identificação dos locais, comparando os grupos de pontos obtidos com asposições marcadas pelo respectivo utilizador.

66


7.1.4.1 Abordagem

Os dados de entrada correspondem aos valores recolhidos ao longo de um período de5 semanas a partir do dispositivo de um dos utilizadores. Os valores mais importantes sãoas posições GPS.No início do período de testes foi pedido ao utilizador que, com o auxílio de uma interfaceWeb desenhada para o efeito, marcasse quais os pontos que consideravam mais relevan-tes dentro das zonas captadas pelo dispositivo. Para cada localização, foi permitido aoutilizador introduzir o tipo de local dentro do conjunto definido e indicar se este local éimportante e/ou frequente no seu dia-a-dia. Os locais e estes dados correspondentes fica-ram guardados numa tabela da base de dados para serem usados durante os testes.Para além de medir o tempo gasto por cada operação, os testes foram também avaliadosde acordo com 3 métricas: cobertura (recall) e precisão (precision) [MKSW99] para ostestes sobre o algoritmo de agregação e exactidão (accuracy) para os testes de classifica-ção.O valor de cobertura corresponde à percentagem de locais encontrados, isto é, ao númerode locais encontrados sobre o total de locais definidos pelo utilizador. Seja {locals} oconjunto de locais definidos pelo utilizador e {clusters} o conjunto de grupos de pon-tos detectados pelo algoritmo de agregação, o valor de cobertura é dado pela seguinteFórmula 7.1:

recall =|{locals}

⋂{clusters}|

|{locals}|(7.1)

Os valores de cobertura são divididos segundo 4 categorias de locais:

• Importantes e frequentes;

• Importantes mas não frequentes;

• Frequentes mas não importantes;

• Nem importantes nem frequentes.

Estas classificações foram atribuídas a cada local pelo próprio utilizador durante a iden-tificação manual dos seus locais significativos. Os valores de cobertura são assim calcu-lados separadamente para cada um destes conjuntos. Um valor global é calculado usandodiferentes pesos para os resultados obtidos, uma vez que tem mais valor encontrar os lo-cais mais importantes do que aqueles que não têm tanta importância para cada utilizador.Sejam i f _recall, i_recall, f _recall e n_recall respectivamente os valores de coberturapara os locais importantes e frequentes, locais importantes, locais frequentes e locais nemimportantes nem frequentes, o valor global de cobertura é dado pela Fórmula 7.2:

67


global = 0.5 · i f _recall +0.2 · i_recall +0.2 · f _recall +0.1 ·n_recall (7.2)

O valor de precisão corresponde ao número de clusters que são de facto relevantes,isto é, que correspondem a algum local definido pelo utilizador sobre o número total declusters obtidos. Este valor é calculado segundo a Fórmula 7.3:

precision =|{locals}

⋂{clusters}|

|{clusters}|(7.3)

Uma medida comum para combinar estes dois últimos resultados é o chamado F1-Score que corresponde à média harmónica entre estes dois valores. Este valor é calculadosegundo a seguinte Fórmula 7.4:

F1Score =2 ·global_recall · precisionglobal_recall + precision

(7.4)

Finalmente o valor de exactidão está relacionado não apenas com a identificação, mascom a percentagem de locais que foram correctamente classificados, tendo em conta aclassificação dada pelos utilizadores. O algoritmo usado compara a classificação de cadalocal definido pelo utilizador ao rótulo que foi atribuída ao respectivo cluster pelo al-goritmo de classificação e cálcula o valor de exactidão. Sendo {correct} o conjunto degrupos correctamente identificados e {incorrect} o conjunto de falsos positivos, a exacti-dão é obtida segundo a Fórmula 7.5:

accuracy =|{correct}|

|{correct}∪{incorrect}|(7.5)

7.1.4.2 Dados de Entrada

Os resultados foram obtidos a partir de uma série de testes efectuados sobre os mé-todos implementados utilizando como dados de entrada os registos guardados relativos aum utilizador. Estes dados correspondem aos dados enviados a partir do dispositivo An-droid do utilizador durante o período de 7 dias compreendidos entre 30 de Março e 11 deMaio de 2011. As posições geográficas correspondem, na sua grande maioria, às cidadesdo Porto e Aveiro.

Na Tabela 7.1 estão indicados os números de registos armazenados para cada tipo decontexto deste utilizador.

Tabela 7.1: Número de dados de contexto utilizados durante a fase de avaliações

GPS Luminosidade Movimento Ruído Conectividade3376 3700 2574 383 901

68


A Tabela 7.2 mostra o número de locais marcados pelo utilizador segundo a sua cate-goria e tipo de importância que este atribuiu a cada local.

Tabela 7.2: Número de locais marcados pelo utilizador por categoria e importância

HOME WORK FOOD SCHOOL SHOP STOP OTHER TotalImportantee Frequente

1 1 0 0 0 0 0 2

Importante 0 0 0 1 0 0 1 2Frequente 0 0 1 0 0 0 0 1Não Im-portante ouFrequente

0 0 0 0 2 4 0 6

Total 1 1 1 1 2 4 1 11

7.1.4.3 Análise de Desempenho

Para analisar o tempo de processamento de cada posição GPS, realizou-se uma experi-ência durante a qual foram introduzidos sequencialmente os vários registos de localizaçãorecolhidos através do método de agregação incremental implementado.

A operação que mais tempo consome durante este processo é o cálculo da vizinhançade um ponto. A complexidade desta operação é O(n), sendo n o número de pontos jáconhecidos. Devido ao facto do fornecedor poder receber um grande número de actuali-zações de diferentes utilizadores, as vizinhanças anteriormente calculadas que estejam emmemória terão eventualmente de ser recalculadas a médio/longo prazo. De forma a anali-sar a pior das hipóteses durante a execução deste teste, o cálculo da vizinhança é semprefeito, mesmo para posições já anteriormente processadas. A cada nova actualização estecálculo ocorre m+1 vezes (linhas 3 e 5 do algoritmo presente na Listagem 7.2), sendo m onúmero de pontos na vizinhança do novo ponto introduzido. As restantes operações nesteprocesso podem ser consideradas como tendo complexidade constante. Assim sendo, napior das hipóteses, isto é, quando as vizinhanças anteriormente calculadas não estão dis-poníveis em memória, a complexidade total do processo de agregação é de O(n(m+1)).No pior dos casos, para os quais o valor de Eps definido seja igual ou maior à distânciamáxima entre cada par de pontos conhecidos, a complexidade é de O(n2).

Nas Figuras 7.1 e 7.2 encontram-se os gráficos do tempo de execução (em ms) doprocesso de agregação incremental sobre a sequência de posições armazenadas para ovalor comum de 5 MinPts e os valores de 10 e 50 Eps respectivamente.

Os testes efectuados foram executados numa máquina com 4 processadores de 2 GHze 4 GB de memória disponíveis.

69


Figura 7.1: Gráfico do tempo de execução do algoritmo IncDJ-Cluster para sucessivas actualiza-ções com Eps=10 e MinPts=5

Figura 7.2: Gráfico do tempo de execução do algoritmo IncDJ-Cluster para sucessivas actualiza-ções com Eps=50 e MinPts=5

70


Figura 7.3: Número de grupos identificados para diferentes combinações de Eps e MinPts

Ambos os gráficos capturam bem a complexidade do algoritmo. O tempo de execuçãomáximo tende a aumentar à medida que novos pontos vão sendo processados. Os gráfi-cos também mostram que o algoritmo tem um tempo de execução muito reduzido paraaproximadamente os primeiros 2000 pontos. É possível também verificar que o tempo,apesar de ser crescente nos piores casos, mantém-se muito reduzido em posições queestejam mais isoladas. A diferença dos valores máximos nos dois gráficos demonstramcomo o tempo de execução está directamente relacionado com o valor de Eps definido,pois quanto maior for definido este parâmetro, mais densas tenderão a ser as vizinhançasdos pontos. Ainda assim, é possível constatar que o valor máximo atingido para cerca de3300 pontos encontra-se dentro de um limite razoável de aproximadamente 2 s.

7.1.4.4 Resultados

A Figura 7.3 mostra o número de grupos obtidos através dos testes para algumasvariações dos parâmetros Eps e MinPts. Este gráfico mostra claramente a correlaçãoentre o valor destes parâmetros e o número de locais identificados, nomeadamente o factodo número de grupos crescer com o aumento da variável Eps e diminuir com o aumentodo valor de MinPts.

Apesar de não ser bem visível neste gráfico, verificou-se igualmente que, à medida queo valor de MinPts é aumentado, o conjunto de grupos identificados tende a ficar restritoa um pequeno grupo de locais — os que são visitados mais frequentemente. No caso dostestes corridos os mesmos 3 grupos podem ser obtidos para valor superiores a 40 MinPts.

Nas Figuras 7.4 e 7.5 é possível ver a influência que a variação dos parâmetros refe-ridos, e por consequência o número de grupos detectados, tem nos valores de cobertura eprecisão do algoritmo implementado.

Destes gráficos é possível concluir que a precisão do algoritmo é maior quanto maiorfor o limite mínimo da densidade dos grupos de pontos. Isto verifica-se sobretudo porque

71


Figura 7.4: Gráfico do valor da cobertura para variações nos parâmetros Eps e MinPts

Figura 7.5: Gráfico do valor da precisão para variações nos parâmetros Eps e MinPts

72


Figura 7.6: Gráfico do valor do F1-Score para variações nos parâmetros Eps e MinPts

quanto maior for este parâmetro menor será o número de locais encontrados e, portanto,menor será também a percentagem de falsos positivos.

Por outro lado, com o aumento do valor de MinPts e consequentemente diminuiçãodo número de locais detectados, maior é a probabilidade de alguns locais menos frequen-tes, mas ainda assim significativos, não serem detectados. Existe assim um trade-off aconsiderar de forma a obter os resultados mais apropriados.

Na Figura 7.6 é apresentada a evolução da métrica F1-Score, que combina estas duasanteriores medidas, para a mesma variação de parâmetros. O valor máximo obtido atravésdos testes efectuados foi de 0,825, sendo Eps e MinPts 50 e 35, respectivamente.

A baixa precisão do algoritmo deve-se ao facto de serem detectados muitos falsospositivos entre os vários grupos calculados. A fim de procurar melhorar os resultadosobtidos, principalmente para valores mais pequenos de MinPts, foram realizadas análisesanálises, recorrendo a uma fase posterior de filtragem dos grupos baseada em valoresmínimos de permanência diária e número de dias visitados.

A Figura 7.7 mostra a evolução das 3 medidas usadas para variações do parâmetroMinVisits com Eps=50 e MinPts=5.

Com a utilização desta fase de pós-processamento usando apenas como filtro o parâ-metro MinVisits, é possível obter um F1-Score de até 0,846. Este resultado não só é muitosuperior aos 0,105 obtidos para os mesmos valores de Eps e MinPts sem filtragem, comoé ainda superior ao valor máximo obtido durantes os testes anteriores por cerca de 0,2unidades. No entanto é importante notar que este aumento do valor máximo vem com umcusto da redução do valor de cobertura, neste caso de 0,95 para 0,733. Isto significa queapesar de ser possível eliminar por quase completo o número de falsos positivos, tambémsão eliminados alguns dos verdadeiros positivos detectados.

73


Figura 7.7: Gráfico da análise do algoritmo para variações de MinVisits quando Eps=50 eMinPts=5

Também foram realizados testes usando variações do parâmetro MinDuration apenas,de modo a analisar uma filtragem baseada na duração diária máxima registada para cadalocal. Esta filtragem também melhora significativamente o valor global dos resultadosmas de uma forma muito menos acentuada, como se pode verificar através da Figura 7.8.

Outros testes efectuados mostram que usando uma combinação destes dois parâmetrosde filtragem, a adição do parâmetro MinDuration à utilização do parâmetro MinVisitsnão traz melhorias significativas sobre os resultados, não se tendo registado qualquerinfluência positiva ou negativa nos melhores casos de teste.

7.2 Classificação de Locais

Os locais obtidos pelo método descrito anteriormente, apesar de permitirem distinguirdiferentes locais entre as várias posições que são recolhidas, não têm qualquer significadoassociado. Uma tarefa importante é classificar esses locais em função do que representampara cada utilizador.O desafio proposto para esta dissertação foi explorar técnicas que permitissem essa clas-sificação de uma forma não supervisionada, isto é, sem recorrer a qualquer informaçãoadicional por parte do utilizador. Para este efeito foram utilizados dois métodos diferen-tes para dois grupos de classificações definido: uma abordagem para os locais da casa etrabalho e outra para os restantes tipos de locais.

74


Figura 7.8: Gráfico da análise do algoritmo para variações de MinDuration quando Eps=50 eMinPts=5

7.2.1 Casa e Local de Trabalho

A casa e local de trabalho de uma pessoa são dois dos tipos de classificações maisfrequentemente explorados em sistemas semelhantes. Diferentes abordagens têm sidoutilizadas assentes numa série de pressupostos sobre os hábitos quotidianos dos utilizado-res dos respectivos sistemas. Para este projecto, a classificação destes locais assenta nosseguintes pressupostos, baseados no trabalho de Adams et al. [APV08]:

• Cada utilizador possui apenas uma casa;

• Cada utilizador possui apenas um local de trabalho;

• A casa do utilizador é o local em que este se encontra mais frequentemente duranteo período da noite;

• O local de trabalho corresponde ao local onde o utilizador se encontra mais frequen-temente durante o período do dia.

Apesar de ser susceptível a muitas excepções (trabalhadores durante o período nocturno,pessoas que trabalham em casa ou perto, etc.), esta solução é suficientemente simples paratestar o sistema implementado e os pressupostos estão geralmente correctos para grandeparte dos utilizadores.

7.2.2 Outros Locais Relevantes

A identificação de outros locais é bastante mais complexa pois locais como lojas oulocais de diversão não são tão frequentes no dia-a-dia das pessoas e não seguem rotinastão precisas como os locais anteriormente referidos, acrescendo o facto de variarem muito

75


Tabela 7.3: Categorias de locais e correspondentes expressões da API Google Places

Categoria ExpressõesENTERTAINMENT amusement_park, aquarium, bowling_alley,

art_gallery, bar, casino, night_clubFOOD cafe, food, restaurantSCHOOL school, universitySHOP store, grocery_or_supermarket, shopping_mallSPORTS gym, stadiumSTOP airport, station, taxi_stand

de pessoa para pessoa e dependerem da época do ano, entre outros factores.A solução que pareceu mais adequada para obter a classe do local de uma forma maisgenérica foi utilizar classificações encontradas em serviços de sistemas de informaçãogeográficos disponíveis na Internet.Os testes efectuados neste âmbito utilizam a API do Google Places 2. O módulo de clas-sificação faz buscas sobre a API do Google Place Search que retornam um conjunto deinformação sobre vários locais, marcados dentro de um raio à volta das coordenadas envi-adas. O programa envia como parâmetros as coordenadas do centróide do grupo e o raio,que corresponde à distância entre o centróide e o ponto mais afastado. Entre a informaçãoretornada num objecto JSON (JavaScript Object Notation), o programa extrai dos rótulosatribuídos aos vários locais encontrados e classifica o grupo de pontos respectivo como tipo mais provável entre os possivelmente encontrados, isto é, a categoria com maisexpressões associadas dentro do conjunto obtido.

Na Tabela 7.3 encontram-se as expressões associadas a cada categoria de local. Omódulo de classificação procura estas palavras e incrementa a pontuação correspondenteà categoria a cada expressão encontrada associada.

7.2.3 Avaliação

Para avaliar os métodos de classificação usados foram utilizados como dados de en-trada o conjunto de 10 locais detectados através do algoritmo de agregação implementado.Esses grupos são submetidos às 3 fases do processo de classificação: a identificação dacasa ("HOME"), a identificação do local de trabalho ("WORK") e a identificação das res-tantes categorias através da API do Google Places. Os resultados obtidos encontram-serepresentados na Tabela 7.4.

Em 6 dos 8 casos que restavam classificar, a classificação errou por falta de categoriassignificativas dentro dos resultados da query ao Google Place Search. Os outros 2 casoseram classificados erradamente por existirem mais locais na vizinhança com categoriasnão relacionadas com o local marcado.

2http://code.google.com/intl/pt-PT/apis/maps/documentation/places/

76


Tabela 7.4: Resultados dos testes de classificação de locais

ClassificaçãoCorrecta

ClassificaçãoErrada

Semclassificação

Total

Importantes eFrequentes

2 0 0 2

Importantes 0 0 2 2Frequentes 0 1 0 1Não Importantesou Frequentes

0 1 4 5

Total 2 2 6 10

Os resultados obtidos para os primeiros dois casos, apesar de não serem muito repre-sentativos mostram que a aproximação tomada é um bom caminho a seguir para casosmais simples. É no entanto muito susceptível a excepções que invalidam os pressupostosreferidos. Os resultados obtidos para o caso das restantes localizações parecem apontarpara o facto da abordagem utilizada não ser minimamente adequada para os objectivosque foram definidos, pelo que uma nova abordagem deverá ser explorada no futuro.

7.3 Sumário

Neste capítulo foram apresentadas as metodologias utilizadas para identificar e classi-ficar locais significativos a partir de um conjunto de posições GNSS.

Na Secção 7.1 é apresentado um novo algoritmo — designado Incremental DJ-Cluster(IncDJ-Cluster) — baseado no algoritmo DJ-Cluster. Começa-se por apresentar os con-ceitos que servem de base a estes algoritmos e, de seguida, é detalhada a forma como oalgoritmo DJ-Cluster foi adaptado para uma versão incremental — que agrega conjuntosde posições à medida que novos dados são recebidos. Posteriormente, são apresentadasduas extensões ao novo algoritmo. Estas extensões passam por filtrar posições ou gruposde posições com base no na no tempo de permanência e frequência de visitas. São tam-bém detalhadas as avaliações feitas sobre a implementação do algoritmo, explicando asmétricas utilizadas e apresentados os resultados obtidos.

Na Secção 7.2 são descritas as abordagens utilizadas na classificação dos locais iden-tificados pelo algoritmo anteriormente referido. Neste projecto são utilizadas duas abor-dagens distintas sobre duas categorias de locais diferentes. Para classificar os locais detrabalho e casa dos utilizadores utilizou-se uma abordagem que parte de pressupostos so-bre os hábitos dos utilizadores. Para classificar todos os restantes procurou-se utilizar asanotações sobre a posição dos locais a partir da API do Google Places. Finalmente, sãoapresentados os resultados obtidos para a classificação de 10 locais obtidos.

77


78

Capítulo 8

Conclusão

Neste capítulo são apresentadas as conclusões do trabalho efectuado. São tambémdeixadas algumas notas finais sobre o trabalho realizado, incluindo possíveis melhorias eoutro trabalho futuro.

8.1 Conclusões

O projecto descrito neste documento consistiu no desenvolvimento de um novo com-ponente que permite inferir sobre informação de contexto, nomeadamente, sobre a loca-lização e actividade dos utilizadores de uma aplicação móvel, à medida que a informaçãovai sendo publicada pelas diversas fontes de contexto.

O trabalho realizado cumpre quase todos os objectivos definidos, ficando apenas porsatisfazer a classificação dos locais encontrados, tendo-se verificado que a aproximaçãoutilizada, recorrendo à extracção de informação através da API do Google Places, não éminimamente fiável para este efeito.

A arquitectura do sistema, baseada num mediador e com comunicação através do pro-tocolo XMPP, demonstrou ser adequada à gestão de dados entre diversas entidades quepublicam e consomem informação de contexto. Através da implementação de um forne-cedor que recorre a um motor de regras Jess, provou-se que é possível centrar o proces-samento destes dados numa aplicação de forma a ser mais fácil inferir nova informaçãoa partir dos dados recolhidos e distribuir esta informação pelo sistema com um tempo deexecução satisfatório. O novo sistema integra-se facilmente na framework desenvolvidana PT inovação, sendo também facilmente adaptável a novas situações que requeirammodificações sobre o tipo de informação trocada entre cada componente.

Ficou demonstrado também que é possível determinar com bastante eficiência e pre-cisão o conhecimento sobre os locais mais significativos para cada utilizador, recorrendoa uma abordagem incremental do algoritmo DJ-Cluster para agregação de posições geo-gráficas.

79

Conclusão

8.2 Trabalho Futuro

Apesar dos bons resultados obtidos na análise do sistema desenvolvido, dadas as limi-tações a que estiveram sujeitos os testes, estes resultados não são representativos do seudesempenho ou eficácia num âmbito de utilização mais realista, com muitas mais pessoase fontes de contexto envolvidas. Os dados recolhidos são de um grupo muito pequenode utilizadores: à data de escrita deste documento, apenas um utilizador possuía dadossuficientemente significativos para os testes mínimos requiridos. É portanto necessáriorecolher mais dados, de um grupo mais largo de utilizadores e efectuar mais testes sobreesses dados.

O motor de regras Jess é um dos mais referidos na literatura dentro do âmbito dossistemas de gestão de contexto com inferência baseada em regras e demonstrou ter umacapacidade mais que suficiente no âmbito deste projecto. No entanto, existem outras al-ternativas que se apresentam tão ou mais fiáveis, como o Drools Expert 1. Este sistema,além de ser baseado também em Java e ser open-source, parece apresentar um desempe-nho superior ao do Jess [Jef09] para além das regras poderem ser definidas em Java, oque pode ser considerado mais user-friendly durante a definição de regras. Também so-bre a definição de regras poderá ainda ser desenvolvida uma aplicação com uma interfacegráfica simples, a partir da qual se possa especificar as regras de uma forma mais natural.

A propósito do módulo de aprendizagem de locais significativos deverão continuara ser exploradas abordagens para a classificação de locais, um aspecto que não satisfezpor completo os objectivos propostos. Deverá também ser feita uma comparação maisaprofundada do algoritmo de agregação implementado com outras soluções encontradasna literatura.

1http://www.jboss.org/drools/drools-expert.html

80

Referências

[Ant74] C.E. Antoniak. Mixtures of Dirichlet processes with applications to Baye-sian nonparametric problems. The annals of statistics, 2(6):1152–1174,1974.

[AP94] A. Aamodt e E. Plaza. Case-based reasoning: Foundational issues, metho-dological variations, and system approaches. AI communications, 7(1):39–59, 1994.

[APV08] B. Adams, D. Phung e S. Venkatesh. Sensing and using social context.ACM Transactions on Multimedia Computing, Communications, and Ap-plications (TOMCCAP), 5(2):1–27, 2008.

[ARWC06] R. Aipperspach, T. Rattenbury, A. Woodruff e J. Canny. A quantitativemethod for revealing and comparing places in the home. UbiComp 2006:Ubiquitous Computing, pages 1–18, 2006.

[AS03] D. Ashbrook e T. Starner. Using GPS to learn significant locations and pre-dict movement across multiple users. Personal and Ubiquitous Computing,7(5):286, 2003.

[BGB06] B. Bouchard, S. Giroux e A. Bouzouane. A Smart Home Agent for Plan Re-cognition of Cognitively-impaired Patients. Journal of Computers, 1(5):53,2006.

[Bha09] S. Bhattacharya. Place Identification: A Comparative Study, October 222009.

[BKNF08] S. Bhattacharya, J. Kukkonen, P. Nurmi e P. Floréen. SerPens: a tool forsemantically enriched location information on personal devices. In Pro-ceedings of the ICST 3rd international conference on Body area networks,pages 1–2. ICST (Institute for Computer Sciences, Social-Informatics andTelecommunications Engineering), 2008.

[BPAP08] A. Bikakis, T. Patkos, G. Antoniou e D. Plexousakis. A survey of semantics-based approaches for context reasoning in ambient intelligence. Construc-ting Ambient Intelligence, pages 14–23, 2008.

[BS10] A. Bamis e A. Savvides. Lightweight extraction of frequent spatio-temporalactivities from gps traces. In 2010 31st IEEE Real-Time Systems Sympo-sium, pages 281–291. IEEE, 2010.

81

REFERÊNCIAS

[BZMK09] N. Baker, M. Zafar, B. Moltchanov e M. Knappmeyer. Context-Aware Sys-tems and Implications for Future Internet. Towards the Future Internet,page 335, 2009.

[CFJ03] H. Chen, T. Finin e A. Joshi. An ontology for context-aware pervasive com-puting environments. The Knowledge Engineering Review, 18(03):197–207, 2003.

[CN09] L. Chen e C. Nugent. Ontology-based activity recognition in intelligentpervasive environments. International Journal of Web Information Systems,5(4):410–430, 2009.

[Dey01] Anind K. Dey. Understanding and using context. Personal UbiquitousComput., 5:4–7, January 2001.

[Doo95] Robert B. Doorenbos. Production matching for large learning systems. Te-chnical report, 1995.

[EKS+98] M. Ester, H.P. Kriegel, J. Sander, M. Wimmer e X. Xu. Incremental clus-tering for mining in a data warehousing environment. In Proceedings ofthe International Conference on Very Large Data Bases, pages 323–333.Citeseer, 1998.

[EKSX96] M. Ester, H.P. Kriegel, J. Sander e X. Xu. A density-based algorithm fordiscovering clusters in large spatial databases with noise. In Proc. KDD,volume 96, pages 226–231, 1996.

[Fer73] T.S. Ferguson. A Bayesian analysis of some nonparametric problems. Theannals of statistics, 1(2):209–230, 1973.

[For82] C.L. Forgy. Rete: A fast algorithm for the many pattern/many object patternmatch problem* 1. Artificial intelligence, 19(1):17–37, 1982.

[GGSA10] Diogo Gomes, João Gonçalves, Ricardo Santos e Rui L Aguiar. Xmpp ba-sed context management architecture. In Workshop on Enabling the FutureService-Oriented Internet (EFSOI), Miami, Florida, USA, 2010.

[GP05] T. Gu e H.K. Pung. A middleware for building context-aware mobile ser-vices. In Vehicular Technology Conference, 2004. VTC 2004-Spring. 2004IEEE 59th, volume 5, pages 2656–2660. IEEE, 2005.

[GPZ05a] T. Gu, H.K. Pung e D.Q. Zhang. A service-oriented middleware for buildingcontext-aware services. Journal of Network and Computer Applications,28(1):1–18, 2005.

[GPZ05b] T. Gu, H.K. Pung e DQ Zhang. Toward an OSGi-based infrastructure forcontext-aware applications. Pervasive Computing, IEEE, 3(4):66–74, 2005.

[GVCF08] L.W. Goix, M. Valla, L. Cerami e P. Falcarin. Situation inference for mobileusers: a rule based approach. In Mobile Data Management, 2007 Internati-onal Conference on, pages 299–303. IEEE, 2008.

82

REFERÊNCIAS

[HCL+05] J. Hightower, S. Consolvo, A. LaMarca, I. Smith e J. Hughes. Learningand recognizing the places we go. UbiComp 2005: Ubiquitous Computing,pages 159–176, 2005.

[Hor02] I. Horrocks. DAML+ OIL: a description logic for the semantic web. Bulle-tin of the Technical Committee on, 51(4), 2002.

[Huy08] D.T.G. Huynh. Human Activity Recognition with Wearable Sensors. PhDthesis, TU Darmstadt, 2008.

[HWK05] M. Hatala, R. Wakkary e L. Kalantari. Rules and ontologies in supportof real-time ubiquitous application. Web Semantics: Science, Services andAgents on the World Wide Web, 3(1):5–22, 2005.

[Jef09] Ralph Jeffery. Banking benchmark performance: Jess vs.drools. http://blogs.illation.com.au/2009/08/performance-comparison-jess-vs-drools/, 2009. Acedido a17 de Junho de 2011.

[KBB+06] R. Kernchen, D. Bonnefoy, A. Battestini, B. Mrohs, M. Wagner e M. Kle-mettinen. Context-awareness in MobiLife. Proc. of the 15th IST MobileSummit, Mykonos, Greece, 2006.

[KK05] M. Khedr e A. Karmouch. ACAI: agent-based context-aware infrastructurefor spontaneous applications. Journal of Network and Computer Applicati-ons, 28(1):19–44, 2005.

[KR03] J. Kopena e W. Regli. DAMLJessKB: A tool for reasoning with the Seman-tic Web. The SemanticWeb-ISWC 2003, pages 628–643, 2003.

[KWSB05] J.H. Kang, W. Welbourne, B. Stewart e G. Borriello. Extracting places fromtraces of locations. ACM SIGMOBILE Mobile Computing and Communi-cations Review, 9(3):58–68, 2005.

[Lea96] D.B. Leake. CBR in context: The present and future. Case-based reaso-ning: Experiences, lessons, and future directions, pages 3–30, 1996.

[LL07] J.S. Lee e J.C. Lee. Context awareness by case-based reasoning in a musicrecommendation system. In Proceedings of the 4th international conferenceon Ubiquitous computing systems, pages 45–58. Springer-Verlag, 2007.

[LM02] S.W. Lee e K. Mase. Activity and location recognition using wearable sen-sors. Pervasive Computing, IEEE, 1(3):24–32, 2002.

[LMW+05] M. Luther, B. Mrohs, M. Wagner, S. Steglich e W. Kellerer. Situationalreasoning-a practical OWL use case. In Autonomous Decentralized Sys-tems, 2005. ISADS 2005. Proceedings, pages 461–468. IEEE, 2005.

[Lok04] Seng W. Loke. Logic programming for context-aware pervasive computing:Language support, characterizing situations, and integration with the web.In Proceedings of the 2004 IEEE/WIC/ACM International Conference onWeb Intelligence, WI ’04, pages 44–50, Washington, DC, USA, 2004. IEEEComputer Society.

83

http://blogs.illation.com.au/2009/08/performance-comparison-jess-vs-drools/

http://blogs.illation.com.au/2009/08/performance-comparison-jess-vs-drools/

REFERÊNCIAS

[Lok06] S. Loke. Context-aware pervasive systems: architectures for a new breedof applications. Auerbach Pub, 2006.

[LRT04] K. Laasonen, M. Raento e H. Toivonen. Adaptive on-device location recog-nition. Pervasive Computing, pages 287–304, 2004.

[MKP05] M. Mikalsen e A. Kofod-Petersen. Representing and reasoning about con-text in a mobile environment. In Proceedings of the First InternationalWorkshop on Modeling and Retrieval of Context. CEUR Workshop Procee-dings, volume 114, pages 25–35, 2005.

[MKSW99] John Makhoul, Francis Kubala, Richard Schwartz e Ralph Weischedel. Per-formance measures for information extraction. In In Proceedings of DARPABroadcast News Workshop, pages 249–252, 1999.

[MS02] N. Marmasse e C. Schmandt. A user-centered location model. Personaland Ubiquitous Computing, 6(5-6):318–321, 2002.

[MS05] A. Moreira e M.Y. Santos. From gps tracks to context: Inference of high-level context information through spatial clustering. In International Con-ference And Exhibition on Geographic Information, Estoril, 2005.

[NB08] P. Nurmi e S. Bhattacharya. Identifying meaningful places: the non-parametric way. Pervasive Computing, pages 111–127, 2008.

[Nea00] R.M. Neal. Markov chain sampling methods for Dirichlet process mixturemodels. Journal of computational and graphical statistics, 9(2):249–265,2000.

[NGMW08] D. Nicklas, M. Grossmann, J. Minguez e M. Wieland. Adding high-levelreasoning to efficient low-level context management: A hybrid approach.In Pervasive Computing and Communications, 2008. PerCom 2008. SixthAnnual IEEE International Conference on, pages 447–452. IEEE, 2008.

[NK06] P. Nurmi e J. Koolwaaij. Identifying meaningful locations. In 20063rd Annual International Conference on Mobile and Ubiquitous Systems-Workshops, pages 1–8. IEEE, 2006.

[NSPGM04] M. Naaman, Y.J. Song, A. Paepcke e H. Garcia-Molina. Automatic orga-nization for digital photographs with geographic coordinates. In DigitalLibraries, 2004. Proceedings of the 2004 Joint ACM/IEEE Conference on,pages 53–62. IEEE, 2004.

[NSW94] A. Norman, N. Schilit e R. Want. Context-Aware Computing Applications.In Proceedings Workshop on Mobile Computing Systems and Applicationa,IEEE, 1994.

[PFKP05] D.J. Patterson, D. Fox, H. Kautz e M. Philipose. Fine-grained activity re-cognition by aggregating abstract object usage. In Wearable Computers,2005. Proceedings. Ninth IEEE International Symposium on, pages 44–51.IEEE, 2005.

84

REFERÊNCIAS

[PFP+04] M. Philipose, K.P. Fishkin, M. Perkowitz, D.J. Patterson, D. Fox, H. Kautze D. Hahnel. Inferring activities from interactions with objects. IEEE Per-vasive Computing, pages 50–57, 2004.

[PRL09] M. Perttunen, J. Riekki e O. Lassila. Context Representation and Reasoningin Pervasive Computing: a Review. International Journal of Multimediaand Ubiquitous Engineering, 4(4), 2009.

[Ras00] C.E. Rasmussen. The infinite Gaussian mixture model. Advances in neuralinformation processing systems, 12:554–560, 2000.

[RC03] Anand Ranganathan e RoyH. Campbell. An infrastructure for context-awareness based on first order logic. Personal and Ubiquitous Computing,7:353–364, 2003. 10.1007/s00779-003-0251-x.

[RDML05] N. Ravi, N. Dandekar, P. Mysore e M.L. Littman. Activity recognitionfrom accelerometer data. In Proceedings of the National Conference onArtificial Intelligence, volume 20, page 1541. Menlo Park, CA; Cambridge,MA; London; AAAI Press; MIT Press; 1999, 2005.

[RHC+02] M. Roman, C. Hess, R. Cerqueira, R.H. Campbell e K. Nahrstedt. Gaia:A middleware infrastructure to enable active spaces. In IEEE PervasiveComputing. Citeseer, 2002.

[Sch95] W.N. Schilit. A system architecture for context-aware mobile computing.PhD thesis, Columbia University, 1995.

[SSW94] K. Sagonas, T. Swift e D.S. Warren. XSB as an efficient deductive databaseengine. ACM SIGMOD Record, 23(2):442–453, 1994.

[STC+09] A.C. Santos, L. Tarrataca, J.M.P. Cardoso, D.R. Ferreira, P.C. Diniz eP. Chainho. Context inference for mobile applications in the upcase pro-ject. MobileWireless Middleware, Operating Systems, and Applications,pages 352–365, 2009.

[TIH+07] E.M. Tapia, S.S. Intille, W. Haskell, K. Larson, J. Wright, A. King e R. Fri-edman. Real-time recognition of physical activities and their intensitiesusing wireless accelerometers and a heart rate monitor. In Wearable Com-puters, 2007 11th IEEE International Symposium on, pages 37 –40, 2007.

[TOK+05] N. Toyama, T. Ota, F. Kato, Y. Toyota, T. Hattori e T. Hagino. Exploi-ting multiple radii to learn significant locations. Location-and Context-Awareness, pages 157–168, 2005.

[TSB06] A.Y. Turhan, T. Springer e M. Berger. Pushing doors for modeling contextswith OWL DL-a case study. In Pervasive Computing and CommunicationsWorkshops, 2006. PerCom Workshops 2006. Fourth Annual IEEE Interna-tional Conference on, pages 5–17. IEEE, 2006.

[WDC+02] X. Wang, J.S. Dong, C.Y. Chin, S.R. Hettiarachchi e D. Zhang. SemanticSpace: an infrastructure for smart spaces. Computing, 1(2):67–74, 2002.

85

REFERÊNCIAS

[WL+06] J.A. Ward, P. Lukowicz et al. Activity recognition of assembly tasks usingbody-worn microphones and accelerometers. IEEE Transactions on PatternAnalysis and Machine Intelligence, pages 1553–1567, 2006.

[WPP+07] S. Wang, W. Pentney, A.M. Popescu, T. Choudhury e M. Philipose. Com-mon sense based joint training of human activity recognizers. In Procee-dings of the 20th International Joint Conference on Artificial Intelligence,pages 2237–2242. Citeseer, 2007.

[YCY04] J. Yin, X. Chai e Q. Yang. High-level goal recognition in a wireless LAN.In PROCEEDINGS OF THE NATIONAL CONFERENCE ON ARTIFICIALINTELLIGENCE, pages 578–584. Menlo Park, CA; Cambridge, MA; Lon-don; AAAI Press; MIT Press; 1999, 2004.

[YSK+07] Naoharu Yamada, Kenji Sakamoto, Goro Kunito, Yoshinori Isoda, KenichiYamazaki e Satoshi Tanaka. Applying ontology and probabilistic model tohuman activity recognition from surrounding things. IPSJ Digital Courier,3:506–517, 2007.

[YYSL08] J. Yin, Q. Yang, D. Shen e Z.N. Li. Activity recognition via user-tracesegmentation. ACM Transactions on Sensor Networks (TOSN), 4(4):19,2008.

[ZBST07] C. Zhou, N. Bhatnagar, S. Shekhar e L. Terveen. Mining personally im-portant places from gps tracks. In Data Engineering Workshop, 2007 IEEE23rd International Conference on, pages 517–526. IEEE, 2007.

[ZFL+07] C. Zhou, D. Frankowski, P. Ludford, S. Shekhar e L. Terveen. Discoveringpersonally meaningful places: An interactive clustering approach. ACMTransactions on Information Systems (TOIS), 25(3):12, 2007.

[Zim03] A. Zimmermann. Context-awareness in user modelling: Requirementsanalysis for a case-based reasoning application. Case-Based Reasoning Re-search and Development, pages 1064–1064, 2003.

86

Anexo A

Modelos de Informação Inferida

A.1 Ruído, Luminosidade e Movimento

A informação que é enviada pelas fontes de contexto já existentes é na sua maioriaconstituída por um conjunto de dados que são obtidos directamente de várias API dis-poníveis e não são submetidos a qualquer tratamento específico. Veja-se, por exemplo,os dados que chegam da aplicação Android referida na Secção 5.1. Os valores brutos demovimento, luminosidade ou ruído, para além de dependerem dos dispositivos utilizados,não têm grande valor semântico. Quando se pretende definir regras sobre o contexto deuma pessoa, pretende-se de preferência saber se essa pessoa estará num sítio escuro ouiluminado, se estará silêncio ou barulho, se estará parado ou a andar e assim por diante.Encontra-se desde logo uma necessidade de traduzir os dados que chegam destes sensoresem informação mais significativa.Os esquemas representados nas Listagens A.1, A.2 e A.3 descrevem 3 novos tipos deinformação que foram definidos nesse âmbito.

A.2 Locais e Actividades

A Listagem seguinte apresenta o schema definido para a informação situacional infe-rida pelo sistema, conforme as categorias referidas na Secção 4.2.1.

87


1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/situation/noise"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/situation/noise">5

6 <complexType name="NoiseClassType">7 <sequence>8 <element name="classification" maxOccurs="1" minOccurs="1" type="tns:

NoiseClasses" />9 </sequence>

10 </complexType>11

12 <simpleType name=’NoiseClasses’>13 <restriction base=’string’>14 <enumeration value=’very silent’ />15 <enumeration value=’silent’ />16 <enumeration value=’moderate’ />17 <enumeration value=’loud’ />18 <enumeration value=’very loud’ />19 </restriction>20 </simpleType>21

22 <element name="noise" type="tns:NoiseClassType"></element>23 </schema>

Listagem A.1: Schema para a informação de alto nível do ruído.

1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/situation/accelerometer"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/situation/accelerometer">5

6 <complexType name="AccelLevelType">7 <sequence>8 <element name="level" maxOccurs="1" minOccurs="1" type="tns:AccelLevels" />9 </sequence>

10 </complexType>11

12 <simpleType name=’AccelLevels’>13 <restriction base=’string’>14 <enumeration value=’not moving’ />15 <enumeration value=’moving’ />16 <enumeration value=’moving fast’ />17 </restriction>18 </simpleType>19

20 <element name="accelerometer" type="tns:AccelLevelType"></element>21 </schema>

Listagem A.2: Schema para a informação de alto nível do acelerómetro.

88


1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/situation/light"3 xmlns="http://www.w3.org/2001/XMLSchema"4 xmlns:tns="http://iex.ptin.pt/ctx/situation/light">5

6 <complexType name="LightLevelType">7 <sequence>8 <element name="level" maxOccurs="1" minOccurs="1" type="tns:LightLevels" />9 </sequence>

10 </complexType>11

12 <simpleType name=’LightLevels’>13 <restriction base=’string’>14 <enumeration value=’very dark’ />15 <enumeration value=’dark’ />16 <enumeration value=’normal’ />17 <enumeration value=’bright’ />18 <enumeration value=’very bright’ />19 </restriction>20 </simpleType>21

22 <element name="light" type="tns:LightLevelType"></element>23 </schema>

Listagem A.3: Schema para a informação de alto nível da luminosidade.

89


1 <?xml version="1.0" encoding="UTF-8"?>2 <schema targetNamespace="http://iex.ptin.pt/ctx/situation" xmlns="http://www.w3.org

/2001/XMLSchema" xmlns:tns="http://iex.ptin.pt/ctx/situation">3

4 <complexType name="SituationType">5 <sequence>6 <element name="location" maxOccurs="1" minOccurs="1" type="tns:

LocationTypes" />7 <element name="activity" maxOccurs="1" minOccurs="1" type="tns:

ActivityTypes" />8 </sequence>9 </complexType>

10

11 <simpleType name=’LocationTypes’>12 <restriction base=’string’>13 <enumeration value=’UNDETERMINED’ />14 <enumeration value=’HOME’ />15 <enumeration value=’WORK’ />16 <enumeration value=’OTHER’ />17 <enumeration value=’SHOP’ />18 <enumeration value=’FOOD’ />19 <enumeration value=’STOP’ />20 <enumeration value=’ENTRETAINMENT’ />21 <enumeration value=’SPORTS’ />22 <enumeration value=’SCHOOL’ />23 </restriction>24 </simpleType>25

26 <simpleType name=’ActivityTypes’>27 <restriction base=’string’>28 <enumeration value=’UNDETERMINED’ />29 <enumeration value=’SLEEPING’ />30 <enumeration value=’WORKING’ />31 <enumeration value="WALKING" />32 <enumeration value="RUNNING" />33 </restriction>34 </simpleType>35

36 <element name="situation" type="tns:SituationType"></element>37 </schema>

Listagem A.4: Schema para a informação situacional.

90

Anexo B

Base de Dados

B.1 Índices

A tabela seguinte lista os índices utilizados em cada tabela da base de dados utili-zada no sistema implementado. Não estão incluídos os índices correspondentes às chavesprimárias, que são gerados automaticamente pelo InnoDB.

91

Base de Dados

Tabela B.1: Tabela de índices da base de dados

Tabela Índice Tipo

class_accelINDEX(user) HASHINDEX(init,final) B-TREEINDEX(level) B-TREE

class_lightINDEX(user) HASHINDEX(init,final) B-TREEINDEX(level) B-TREE

class_noiseINDEX(user) HASHINDEX(init,final) B-TREEINDEX(level) B-TREE

clusters INDEX(user) HASH

raw_accelINDEX(user) HASHINDEX(init,final) B-TREE

raw_connectivityINDEX(user) HASHINDEX(init,final) B-TREEINDEX(network) HASH

raw_gpsINDEX(user) HASHINDEX(init,final) B-TREEINDEX(cluster) HASH

raw_lightINDEX(user) HASHINDEX(init,final) B-TREEINDEX(dist_id) HASH

raw_noiseINDEX(user) HASHINDEX(init,final) B-TREE

situationINDEX(user) HASHINDEX(init,final) B-TREE

92

Anexo C

Regras de Inferência

C.1 Definição de Regras de Inferência

As regras utilizadas para inferência de contexto foram escritas manualmente numúnico ficheiro. As regras estão representadas na linguagem nativa do Jess. Os valoresutilizados para inferência sobre dados dos sensores foram baseados na leitura dos valo-res dos respectivos sensores no próprio dispositivo e em diversas situações e ambientesdiferentes.

1 (defrule not_moving2 (AccelRaw (user ?user) { ( speed < 1 ) || ( frequency < 2 ) } )3 =>4 (bind ?s (new AccelLevel))5 (?s setUser ?user)6 (?s setLevel 0)7 (add ?s))8

9 (defrule moving10 (AccelRaw (user ?user) { ( speed ≥ 1 ) && ( frequency > 2 ) } )11 =>12 (bind ?s (new AccelLevel))13 (?s setUser ?user)14 (?s setLevel 1)15 (add ?s))16

17 (defrule moving_fast18 (AccelRaw (user ?user) { ( speed ≥ 5 ) && ( frequency > 10 ) } )19 =>20 (bind ?s (new AccelLevel))21 (?s setUser ?user)22 (?s setLevel 2)23 (add ?s))

Listagem C.1: Regras sobre dados de movimento.

93


1 (defrule very_silent2 (NoiseRaw (user ?user) { amplitude < 1 } )3 =>4 (bind ?s (new NoiseLevel))5 (?s setUser ?user)6 (?s setLevel 0)7 (add ?s))8

9 (defrule silent10 (NoiseRaw (user ?user) { ( amplitude ≥ 1 ) && ( amplitude < 4 ) } )11 =>12 (bind ?s (new NoiseLevel))13 (?s setUser ?user)14 (?s setLevel 1)15 (add ?s))16

17 (defrule moderate18 (NoiseRaw (user ?user) { ( amplitude ≥ 4 ) && ( amplitude < 7 ) } )19 =>20 (bind ?s (new NoiseLevel))21 (?s setUser ?user)22 (?s setLevel 2)23 (add ?s))24

25 (defrule loud26 (NoiseRaw (user ?user) { ( amplitude ≥ 7 ) && ( amplitude < 10 ) } )27 =>28 (bind ?s (new NoiseLevel))29 (?s setUser ?user)30 (?s setLevel 3)31 (add ?s))32

33 (defrule very_loud34 (NoiseRaw (user ?user) { amplitude ≥ 10 } )35 =>36 (bind ?s (new NoiseLevel))37 (?s setUser ?user)38 (?s setLevel 4)39 (add ?s))

Listagem C.2: Regras sobre dados de ruído.

94


1 (defrule very_dark2 (LightRaw (user ?user) { brightness < 50 } )3 =>4 (bind ?s (new LightLevel))5 (?s setUser ?user)6 (?s setLevel 0)7 (add ?s))8

9 (defrule dark10 (LightRaw (user ?user) { ( brightness ≥ 50 ) && ( brightness < 100 ) } )11 =>12 (bind ?s (new LightLevel))13 (?s setUser ?user)14 (?s setLevel 1)15 (add ?s))16

17 (defrule normal18 (LightRaw (user ?user) { ( brightness ≥ 100 ) && ( brightness < 1000 ) } )19 =>20 (bind ?s (new LightLevel))21 (?s setUser ?user)22 (?s setLevel 2)23 (add ?s))24

25 (defrule bright26 (LightRaw (user ?user) { ( brightness ≥ 1000 ) && ( brightness < 10000 ) } )27 =>28 (bind ?s (new LightLevel))29 (?s setUser ?user)30 (?s setLevel 3)31 (add ?s))32

33 (defrule very_bright34 (LightRaw (user ?user) { brightness ≥ 10000 } )35 =>36 (bind ?s (new LightLevel))37 (?s setUser ?user)38 (?s setLevel 4)39 (add ?s))

Listagem C.3: Regras sobre dados de iluminação.

95


1 (defrule sleeping2 (AccelLevel (user ?user) ( level 0 ) )3 (NoiseLevel (user ?user) ( level 0 ) )4 (LightLevel (user ?user) ( level 0 ) )5 ?s <- (Situation (user ?user) ( location "HOME" ) )6 =>7 (?s setActivity "SLEEPING")8 (update ?s))9

10 (defrule working11 (AccelLevel (user ?user) ( level 0 ) )12 ?s <- (Situation (user ?user) ( location "WORK" ) )13 =>14 (?s setActivity "WORKING")15 (update ?s))16

17 (defrule walking18 (AccelLevel (user ?user) ( level 1 ) )19 (NoiseLevel (user ?user) { level > 0 } )20 ?s <- (Situation (user ?user) ( location "UNDETERMINED" ) )21 =>22 (?s setActivity "WALKING")23 (update ?s))24

25 (defrule running26 (AccelLevel (user ?user) ( level 2 ) )27 (NoiseLevel (user ?user) { level > 0 } )28 ?s <- (Situation (user ?user) ( location "UNDETERMINED" ) )29 =>30 (?s setActivity "RUNNING")31 (update ?s))

Listagem C.4: Regras de inferência de situações.

96

inferência situacional em sistemas baseados em informação de … · sibilita ainda uma fácil...

Documents