Dissertação de Hugo Feitosa de Figueirêdodocs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/... · 2010. 5. 12. · Resumo As aplicac¸oes cientes de contexto est˜ ˜ao se

Universidade Federal de Campina Grande

Centro de Engenharia Eletrica e Informatica

Coordenacao de Pos-Graduacao em Informatica

Uma Infraestrutura de Suporte a Aplicacoes Cientes

de Contexto com o Enfoque no Usuario Final

Hugo Feitosa de Figueiredo

Dissertacao submetidaa Coordenacao do Curso de Pos-Graduacao em

Ciencia da Computacao da Universidade Federal de Campina Grande -

Campus I como parte dos requisitos necessarios para obtencao do grau

de Mestre em Ciencia da Computacao.

Area de Concentracao: Ciencia da Computacao

Linha de Pesquisa: Sistemas de Informacao e Banco de Dados

Claudio de Souza Baptista

(Orientador)

Campina Grande, Paraıba, Brasil

c©Hugo Feitosa de Figueiredo, 18 de Setembro de 2009

FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG

F475i Figueirêdo, Hugo Feitosa de

Uma infraestrutura de suporte a aplicações cientes de contexto com o enfoque no usuário final / Hugo Feitosa de Figueirêdo ─ Campina Grande, 2009.

115 f.

Dissertação (Mestrado em Ciência da Computação)- Universidade Federal de Campina Grande, Centro de Engenharia Elétrica e Informática.

Referências. Orientador: Prof. Dr. Cláudio de Souza Baptista.

1. Dispositivos Móveis 2. Aplicação Cientes de Contexto 3. Ontologias I. Título.

CDU 004.65 (043)

Resumo

As aplicacoes cientes de contexto estao se tornando populares, como consequencia de

avancos tecnologicos em dispositivos moveis, sensores e comunicacao de redes sem fio.

Entretanto, desenvolver um sistema ciente de contexto envolve varios desafios. Por exem-

plo, quais serao as informacoes contextuais, como representar, adquirir e processar essas

informacoes e como estas serao utilizadas pelo sistema. Alguns frameworks e middlewares

foram propostos na literatura para auxiliar programadoresa superar esses desafios, porem

ainda faltam mecanismos que auxiliem usuarios finais na personalizacao dessas aplicacoes.

Al em disso, a maioria das solucoes propostas nao possui um modelo de contexto extensıvel

baseado em ontologias ou nao utiliza uma comunicacao que permita aproveitar as potenci-

alidades dos modelos que seguem esta abordagem. Este trabalho propoe uma infraestrutura

de suporte a aplicacoes cientes de contexto que possui um modelo de contexto extensıvel

baseado em ontologias e comunicacao entre os elementos utilizando SPARQL e SPARQL

Update. Tambem sao propostas ferramentas para usuarios finais criarem e validarem visual-

mente regras contextuais.

i

Abstract

Context-aware applications have become popular as a consequence of the technological ad-

vances on mobile devices, sensors, and wireless network communication. However, there

are many challenges in the development of these applications. For instance, which contex-

tual information will be used, how to represent, capture, proccess and use the context in the

system are some of such application development challenges. Frameworks and middlewares

to improve context-aware application development have been proposed, but they still lack

helping users in customizing their applications. Furthemore most proposed solutions do not

have an extensible ontology-based context model and an efficient communication which ena-

bles to explore the main features of such approach. This workproposes an infrastructure to

support context-aware applications, which uses an extensible ontology-based context mo-

del and communication through SPARQL and SPARQL Update. Also there are visual tools

aiming to help end-users in the creation and validation of context rules.

ii

Agradecimentos

Ao meu orientador e amigo, Claudio Baptista, pelos muitos gritos e broncas, por ter me

ensinado muito de como ser um pesquisador e pela paciencia que teve comigo (ou nao? :-P).

A minha esposa, Julliana, por ter aguentado a falta de atencao que lhe dei durante a

redacao desta dissertacao e por ter me incentivado nos momentos em que precisei.

Em especial, a meu filho Igor, que me deu muitas alegrias e muita forca nos momentos

difıceis.

A minha mae, por ter me indicado o caminho a ser seguido, pelo apoio financeiro e por

ter me ajudado a entender as broncas do meu orientador.

A minha irma, Marcella, por ter ficado com Igor varios finais de semana para que eu

terminasse meu mestrado.

A toda minha famılia.

Ao meu grande amigo e parceiro de pesquisas, Yuri Lacerda, com quem realizei bons

trabalhos de pesquisa e tomei poucas cervejas durante o perıodo de mestrado.

Aos meus grandes amigos, Claudio Campelo e Daniel Fireman.

Aos colegas de Laboratorio, Damiao, Fabio Leite, Fabio Gomes, Michael, Ricardo, Lu-

ciana, Felipe, Carlos Augusto, Welmisson Jammesson, Tiago (pelas risadas) e Halley.

Aos alunos de graduacaodo LSI, Tiago, Eliael e Diego, por terem contribuıdo de alguma

forma com o prototipo desenvolvido na minha pesquisa.

A CAPES e ao CNPQ, pelo apoio financeiro.

iii

Conteudo

1 Introduc ao 1

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Metodologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Estrutura da Dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Fundamentacao Teorica 5

2.1 Computacao Ubıqua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Contexto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Servicos Baseados em Localizacao . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Representacao do Conhecimento, Ontologias e Web Semantica . . . . . . . 11

2.5 Modelagem de Contexto. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Trabalhos Relacionados 17

3.1 FLAME2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 WASP e Infraware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 MScape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 StreamSpin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 SOCAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 Context Toolkit e iCAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.7 Omnipresent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.8 Comparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32


iv

CONTEUDO v

4 VadeMecum 35

4.1 Visao Geral do Sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Servidor de Contexto do VadeMecum. . . . . . . . . . . . . . . . . . . . 36

4.2.1 Modelo de Contexto do VadeMecum. . . . . . . . . . . . . . . . 37

4.2.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3 Questoes de Implementacao . . . . . . . . . . . . . . . . . . . . . 44

4.3 Auxılio na criacao de regras pelos usuarios finais . . . . . . . . . . . . . . 50

4.3.1 Requisitos Funcionais. . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.2 Requisitos Nao Funcionais. . . . . . . . . . . . . . . . . . . . . . 52

4.3.3 CARE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.4 CARE Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.5 Questoes de Implementacao . . . . . . . . . . . . . . . . . . . . . 62

4.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5 Estudo de Caso 66

5.1 Outdoor Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Multimedia Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


6 Conclusao 78

6.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1.1 Servidor de Contexto do VadeMecum. . . . . . . . . . . . . . . . 79

6.1.2 Auxılio na Criacao de Regras Contextuais. . . . . . . . . . . . . . 80

6.2 Trabalhos Futuros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Referencias Bibliograficas 89

A Modelo de Contexto do VadeMecum 90

B Configuracao do Joseki 101

Lista de Abreviacoes

API - Application Programming Interface

CARE -Context-Aware Rule Editor

CC/PP -Composite Capability/Preference Profiles

CEP -Codigo de Enderecamento Postal

CLDC - Connected Limited Device Configuration

DAML - DARPA Agent Markup Language

DARPA - Defense Advanced Research Projects Agency

DIG - DL Implementation Group

FOAF - Friend of a Friend

GMLC - GatewayMobile Location Center

GPS -Global Positioning System

HP -Hewlett-Packard

HTTP -Hypertext Transfer Protocol

JAD - Java Application Descriptor

JEE -Java Platform, Enterprise Edition JEE

JME - Java Platform, Micro Edition

JSR -Java Specification Request

LBS - Location Based Services

MIDP - Mobile Information Device Profile

MPC - Mobile Positioning Center

OGC -Open Geospatial Consortium

OIL - Ontology Inference Layer

OpenLS -Open Location Services Interface Standard

ORM - (Object Role Modeling)

vi

vii

OWL - Ontology Web Language

PDA - Personal Digital Assistants

RDF - Resource Description Framework

RDFS -Resource Description Framework Schema

RIA - Rich Internet Application

SIG -Sistemas de Informacoes Geograficas

SOAP -Simple Object Access Protocol

SPARQL -SPARQL Protocol and RDF Query Language

SWRL - Semantic Web Rule Language

UML - Unified Modeling Language

W3C - The World Wide Web Consortium

XML - eXtensible Markup Language

XSD - XML Schema Definition

Lista de Figuras

2.1 Eras computacionais propostas por Weiser.. . . . . . . . . . . . . . . . . . 6

2.2 Tendencias futuras em computacao(Adaptado de http://www.ubiq.com).. . 7

2.3 Camadas da Web Semantica (adaptada de http://www.w3.org/2001/sw).. . 12

3.1 Arquitetura do FLAME2008.. . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Plataforma WASP e seus relacionamentos. . . . . . . . . . . . . . . . . . 20

3.3 Arquitetura da plataforma WASP.. . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Arquitetura da plataforma Infraware.. . . . . . . . . . . . . . . . . . . . . 22

3.5 Componentes de um mediascape.. . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Ferramenta de criacao de mediascapes.. . . . . . . . . . . . . . . . . . . . 23

3.7 Arquitetura da plataforma StreamSpin.. . . . . . . . . . . . . . . . . . . . 26

3.8 Modelo baseado em ontologia com dois nıveis de hierarquia.. . . . . . . . 27

3.9 Arquitetura do SOCAM.. . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.10 Arquitetura do Context Toolkit.. . . . . . . . . . . . . . . . . . . . . . . . 29

3.11 Arquitetura do Omnipresent.. . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Esquema de criacao de regras. . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Contextos do modelo de contexto do VadeMecum.. . . . . . . . . . . . . 39

4.3 Ontologia superior do modelo de contexto.. . . . . . . . . . . . . . . . . . 40

4.4 Ontologia do VadeMecum para regras.. . . . . . . . . . . . . . . . . . . . 40

4.5 Arquitetura do servidor de contexto do VadeMecum.. . . . . . . . . . . . 41

4.6 Diagrama de classes da API para criacao de provedores de contexto.. . . . 43

4.7 Ferramenta Protege com o plugin OWL.. . . . . . . . . . . . . . . . . . . 45

4.8 Arquitetura do CARE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.9 Widgetpara selecao de elementos geograficos.. . . . . . . . . . . . . . . . 56

viii

LISTA DE FIGURAS ix

4.10 Interface do CARE.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.11 Tela do CARE para selecao da opcao para especificar o estado contextual.. 58

4.12 Tela do CARE para selecao da classe do tipoContextEntity. . . . . . . . . . 58

4.13 Tela do CARE para selecao do relacionamento da entidade.. . . . . . . . . 59

4.14 Arquitetura do CARE Emulator.. . . . . . . . . . . . . . . . . . . . . . . 61

4.15 Interface do CARE Emulator.. . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Diagrama de classes do provedor do contexto de localizaçao. . . . . . . . . 67

5.2 Ferramenta CARE com uma regra para o Outdoor Virtual.. . . . . . . . . 69

5.3 Ferramenta CARE com o widget do google maps. . . . . . . . . . . . . . 70

5.4 CARE Emulator validando a regra contextual criada para o Outdoor Virtual. 71

5.5 Aplicacao movel antes e depois da acao de mostra uma arquivo multimıdia. 72

5.6 Tela inicial do cliente movel. . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.7 Tela de escolha do tipo arquivo o usuario deseja criar.. . . . . . . . . . . . 75

5.8 Tela de criacao do arquivo de imagem.. . . . . . . . . . . . . . . . . . . . 76

5.9 Tela de escolha do tipo de armazenamento para o arquivo.. . . . . . . . . 76

Lista de Tabelas

2.1 Comparacao entre os tipos de computacao.. . . . . . . . . . . . . . . . . . 7

2.2 Comparacao entre abordagens para modelagem de contexto.. . . . . . . . 15

3.1 Comparacao entre os trabalhos relacionados.. . . . . . . . . . . . . . . . . 33

x

Lista de Codigos-Fonte

4.1 Regra contextual no VadeMecum.. . . . . . . . . . . . . . . . . . . . . . 44

4.2 Sintaxe das regras no Jena.. . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Exemplo de consulta em SPARQL SELECT.. . . . . . . . . . . . . . . . . 48

4.4 Resultado de uma consulta SPARQL na forma SELECT.. . . . . . . . . . 49

4.5 Atualizando o contexto utilizando SPARQL Update no VadeMecum. . . . . 49

4.6 Exemplo de arquivo com as funcoes permitidas pelo CARE nas regras.. . . 55

5.1 Regra criada no CARE para o Outdoor Virtual.. . . . . . . . . . . . . . . 68

5.2 Regra alterado do estudo de caso do Outdoor Virtual.. . . . . . . . . . . . 77

A.1 Modelo de contexto do VadeMecum descrito em OWL.. . . . . . . . . . . 90

B.1 Configuracao do Joseki no VadeMecum.. . . . . . . . . . . . . . . . . . . 101

xi

Capıtulo 1

Introduc ao

O poder de processamento e armazenamento dos computadores esta aumentando cada vez

mais. Tal evolucao nao esta so ocorrendo com os computadores pessoais, mas tambem com

os dispositivos moveis. Desta forma, estes dispositivos estao agregando cada vez mais fun-

cionalidades, permitindo que as pessoas possam realizar algumas tarefas com estes dispo-

sitivos enquanto se movimentam. Por exemplo, um investidorrecebe uma notıcia em seu

dispositivo sobre uma queda na bolsa de valores de Nova York e, rapidamente, vende algu-

mas acoes suas na Bovespa, antes que os efeitos dessa queda afetem suas cotacoes, sendo

toda a negociacao feita no seu dispositivo.

Por outro lado, uma grande variedade de sensores estao surgindo no mercado, sendo

possıvel acopla-los a dispositivos moveis atraves de entradas seriais,Bluetooth, IrDa, etc.

A fusao dos dispositivos moveis com esses sensores, torna possıvel o monitoramento da

situacao na qual o usuario esta inserido. Por exemplo, atraves de um sensor de temperatura

de uma pessoa,e possıvel descobrir se ela esta com febre. Estas informacoes, que podem

ser monitoradas a partir de sensores, sao conhecidas como informacoes contextuais, as quais

compoem um conjunto chamado de estado contextual[1].

O monitoramento do estado contextual pelas aplicacoes, permite que estas estejam cien-

tes de informacoes implıcitas na comunicacao entre o homem e a maquina e nao somente as

explıcitas. Com estas informacoes, as aplicacoes podem tomar decisoes com o intuito de per-

sonalizar os servicos a seus usuarios. Por exemplo, uma aplicacao pode alterar a temperatura

do ar-condicionado de acordo com as preferencias das pessoas localizadas no ambiente.

Uma das definicoes mais referenciadas para contexto foi proposta por Dey[2]:

1

2

“Contexto e qualquer informacao que pode ser utilizada para caracterizar a

situacao de uma entidade. Uma entidadee uma pessoa, lugar ou objeto quee

considerado relevante para a interacao entre o usuario e a aplicacao, incluindo

o proprio usuario e aplicacao.”

O contextoe um dos temas mais pesquisados na computacao ubıqua, que foi visionada

por Weiser[3]. Na visao de computacao ubıqua, e previsto que as pessoas serao auxili-

adas nas suas atividades cotidianas pelos computadores, demaneira que este auxılio nao

seja percebido pelos proprios usuarios. Para que os computadores consigam ajudar sem ser

percebidos,e necessario o monitoramento do contexto do usuario, de forma que suas neces-

sidades sejam atendidas automaticamente, quando algum determinado estado contextual for

atingido.

Com os avancos na capacidade de processamento e armazenamento dos dispositivos

moveis, muitos servicos poderao ser fornecidos nestes, havendo a possibilidade destes

servicos serem cientes de contexto. Dessa forma, surge a necessidade de pesquisas volta-

das para estaarea, para se superar alguns desafios provenientes desta visao.

Os Servicos Baseados em Localizacao (Location-Based Services- LBS) [4] podem ser

vistos como uma parte dos servicos cientes de contexto que podem ser oferecidos para dispo-

sitivos moveis. Estes servicos ja deixaram de ser uma visao do futuro para ser uma realidade

[5]. Por exemplo, existem diversas aplicacoes no mercado que oferecem a busca por uma

rota entre dois pontos geograficos. Alem disso, existem outras aplicacoes que permitem que

sejam criadas condicoes relacionadas aareas geograficas. Assim, quando o usuario estiver

dentro de alguma destasareas, uma acao sera executada.

Apesar de muitas aplicacoes cientes de contexto ja existirem, poucas possuem uma ar-

quitetura extensıvel, para facilitar a adicao de novos contextos ou servicos. Com isso, al-

gunsframeworks, middlewarese arquiteturas foram propostas na literatura para o auxiliona

criacao destas aplicacoes[6] [7] [8] [9] [10].

A maior parte das solucoes para facilitar a extensao de aplicacoes cientes de contexto,

porem, nao enfoca o usuario final, pois sao feitas para facilitar a extensao por programadores

– que conhecam bem a solucao. Deste modo, alguns pesquisadores propuseram algumas

ferramentas com o foco no usuario final, de forma que, ele proprio possa estender e alterar

a aplicacao [11] [12] [13]. Entretanto, a maioria destas ferramentas foram desenvolvidas

1.1 Objetivos 3

para sistemas de Casas inteligentes (Smart Home) e nao possuem um modelo de contexto

extensıvel ao qual as ferramentas se adaptem.

Este trabalho apresenta uma infraestrutura para facilitaro desenvolvimento de aplicacoes

cientes de contexto com o enfoque na personalizacao pelo usuario final. Fazem parte da

infraestrutura: um servidor de contexto, que realiza algumas tarefas comuns necessariasas

aplicacoes cientes de contexto; uma ferramenta que auxilia o usuario final na especificacao

de regras contextuais; e um emulador para validacao das regras.

Na proxima secao, serao apresentados os objetivos deste trabalho. Em seguida, nasecao

1.2, e descrita a metodologia que foi utilizada nesta pesquisa. Por fim, na secao1.3, e exposta

a estrutura do restante desta dissertacao.

1.1 Objetivos

O principal objetivo deste trabalhoe desenvolver uma infraestrutura para dar suportea

criacao de aplicacoes cientes de contexto, que permitam a personalizacao pelo usuario fi-

nal.

1.1.1 Objetivos Especıficos

Os objetivos especıficos deste trabalho sao:

• Obter um modelo de contexto baseado em ontologias;

• Obter um servidor de contexto para o tratamento das informaçoes contextuais;

• Obter uma ferramenta visual para geracao de regras, de forma que, esta tarefa possa

ser executada pelos usuarios finais da aplicacao;

• Obter um emulador do sistema para validacao pelo usuario final das regras criadas;

• Fazer com que a infraestrutura permita a extensao do modelo de contexto; e

• Obter aplicacoes cientes de contexto que validem a infraestrutura proposta neste tra-

balho.

1.2 Metodologia 4

1.2 Metodologia

A metodologia utilizada no trabalho descrito nesta dissertacao baseou-se em atividades de

estudos regulares em aplicacoes cientes de contexto, alem da realizacao de pesquisas nas

principais publicacoes naarea. Foram levantadas algumas ferramentas que possuem carac-

terısticas similares a este trabalho e estas foram analisadas para o levantamento das lacunas

existentes. A partir das analises realizadas nas ferramentas, foram levantados os requisitos

para o sistema. Em seguida, foi desenvolvido um prototipo e realizada uma validacao com

alguns estudos de casos de utilizacao do sistema em simulacoes de usos reais.

1.3 Estrutura da Dissertacao

O restante desta dissertacao esta estruturada da seguinte forma:

• Capıtulo 2: contem uma fundamentacao teorica necessaria para a compreensao

desta dissertacao, como as definicoes para contexto, aplicacoes cientes de contexto,

computacao ubıqua e ontologias;

• Capıtulo 3: contem uma discussao sobre os principais trabalhos relacionados naarea,

destacando os pontos relevantes, inspiradores e fracos de cada um;

• Capıtulo 4: e apresentada a infraestrutura VadeMecum, sendo descrito uma visao ge-

ral do sistema, o servidor de contexto e o processo de criacao e validacao de regras

contextuais pelo usuario final;

• Capıtulo 5: sao apresentados alguns estudos de caso de situacoes reais da utilizacao da

infraestrutura proposta neste trabalho; e

• Capıtulo 6: e concluıda esta dissertacao, sendo apresentadas as principais

contribuicoes obtidas e outros trabalhos que podem ser desenvolvidos no futuro.

Capıtulo 2

Fundamentacao Teorica

Neste capıtulo, apresenta-se a terminologia basica e os conceitos fundamentais utilizados du-

rante esta dissertacao. Questoes como distincao entre computacao pervasiva, ubıqua e movel

sao abordadas. Tambem sera introduzida uma nocao de Web Semantica, que representa um

dos elementos-chaves a serem considerados na modelagem do contexto.

O restante deste capıtulo esta organizado da seguinte forma, na secao 2.1, introduzem-

se os conceitos de computacao ubıqua. Na secao 2.2, apresentam-se algumas definicoes e

caracterısticas de contexto, como tambem, alguns exemplos de sistemas cientes de contexto.

Na secao2.3, discorre-se sobre servicos baseados em localizacao, que sao um caso especıfico

de servicos cientes de contexto. Posteriormente, na secao2.4, descrevem-se alguns conceitos

sobre representacao do conhecimento, ontologias e Web semantica. Em seguida, na secao

2.5, apresenta-se um estudo sobre modelagem de contexto. Por fim, sao citadas algumas

consideracoes finais do capıtulo naultima secao.

2.1 Computacao Ubıqua

Weiser[3], em 1991, idealizou um futuro – para o perıodo em que o artigo foi escrito – para

a computacao, a qual seria onipresente na vida das pessoas durante a realizacao de tarefas

do cotidiano. Entretanto, esta nao seria percebida pelos mesmos, devidoa naturalidade da

situacao. Esta ideia abriu caminho para uma nova linha de pesquisa ate entao inexplorada: a

computacao ubıqua.

Weiser[3] descreveu a computacao ubıqua como a terceira grande era dos computado-

5

2.1 Computacao Ubıqua 6

res, sendo as duas primeiras representadas pelosmainframese os computadores pessoais.

Na era domainframe, existiam poucos computadores de grande porte e imenso poder de

processamento para serem compartilhados por inumeros usuarios. Ja a era dos computa-

dores pessoais foi caracterizada pela utilizacao de micro-computadores para uso pessoal e

exclusivo. Porultimo, a era da computacao ubıqua seria caracterizada pela existencia de di-

versos dispositivos de pequeno porte que auxiliariam os usuarios nas suas tarefas cotidianas

sem ser percebidos. A Figura2.1apresenta o relacionamento com as cardinalidades das eras

propostas por Weiser e a Figura2.2mostra um grafico com as tres eras e suas tendencias.

Figura 2.1: Eras computacionais propostas por Weiser.

A computacao ubıqua muitas vezese equivocadamente confundida com computacao per-

vasiva; no entanto, estes referem-se a ramos distintos de pesquisa, apesar de possuırem uma

grande intersecao. A computacao movel trata da habilidade de utilizar dispositivos com-

putacionais mesmo quando em movimento. Enquanto, computaçao pervasiva refere-sea

colaboracao transparente entre dispositivos computacionais distribuıdos no ambiente fısico

para a obtencao de informacoes do meio para a construcao dinamica de novos modelos com-

putacionais. Por fim, a computacao ubıqua integra os avancos da computacao movel e da

computacao pervasiva[14]. Na Tabela2.1, confrontam-se os tres tipos de computacao cita-

dos com duas caracterısticas, a de imersao computacional – referentea distribuicao de dis-

2.1 Computacao Ubıqua 7

Figura 2.2: Tendencias futuras em computacao(Adaptado de http://www.ubiq.com).

Tabela 2.1: Comparacao entre os tipos de computacao.

Imersao Computacional Mobilidade

Computacao Tradicional - -

Computacao Pervasiva + -

Computacao Movel - +

Computacao Ubıqua + +

positivos computacionais para a captacao de informacoes do ambiente – e a de mobilidade

– referentea mobilidade dos dispositivos computacionais enquanto esta em funcionamento.

“+” indica que a computacao atendea caracterıstica e “-” que nao atende.

Jensen[15] afirma que a realidade na qual uma aplicacao sera utilizada deve ser pensada

quando estae desenvolvida para o futuro. Desta forma, o ideale se basear em algumas

referencias de pesquisadores sobre as tendencias no mundo computacional para o perıodo

em que a aplicacao sera utilizada. Por exemplo, basear-se na lei de Moore para estimar qual

sera o poder computacional no perıodo desejado ou, ate mesmo, nas visoes de Weiser[3].

A computacao ubıqua abrange diversos ramos de pesquisas, incluindo o dos sistemas

cientes de contexto, quee um passo inicial para o futuro visionado por Weiser[3]. Esses

sistemas serao descritos nas proximas secoes.

2.2 Contexto 8

2.2 Contexto

Com a proliferacao de dispositivos moveis, tais comosmartphonese PDA (Personal Di-

gital Assistants), os usuarios destes dispositivos podem se movimentar enquanto realizam

outras tarefas. Com isto, informacoes podem ser coletadas da situacao na qual o usuario esta

inserido para fornecer servicos e informacoes personalizadas, realizacoes automaticas de co-

mandos e armazenamento destas informacoes para uso posterior. Este tipo de informacao

utilizada para estas tomadas de decisoese chamado de contexto, sendo as aplicacoes que

utilizam este tipo de informacao as aplicacoes cientes de contexto.

Como visto anteriormente, na computacao ubıqua o usuario seria auxiliado por compu-

tadores em suas tarefas cotidianas, de forma que, estes nao fossem percebidos. Para este

objetivo ser alcancado,e necessario que o contexto seja monitorado constantemente, para a

tomada de decisao pelo computador, a fim de auxiliar o usuario em suas tarefas.

Existem diversos desafios relacionadosa utilizacao de contexto em sistemas, sendo al-

guns enumerados por Schmidt[16]:

• Entender o conceito de contexto.O conceito de contexto deve ser assimilado antes

de tentar usa-lo;

• Utilizar o contexto. E necessario saber como o contexto sera utilizado;

• Adquirir informac oes de contexto. Nesta parte entra os desafios relacionados a

captacao de informacoes de sensores;

• Conectar a aquisicao de contexto na utilizacao de contexto.A conexao da aquisicao

do contexto com a utilizacao deve ser feita de maneira uniforme, independente de qual

sensor a informacao foi capturada e onde o sensor esta localizado, sendo esta parte

abstraıda no momento de utilizacao do contexto;

• Entender a influencia da interacao entre o homem e o computador.Uma das

utilidades do contextoe facilitar a interacao entre o homem e o computador. Com isso,

e necessario entender como esta interacao ocorre para tentar melhora-la;

• Auxiliar na construc ao de sistemas ubıquos. A construcao de aplicacoes cientes de

contexto de maneiraad hocnao e trivial. Com isso, torna-se necessaria a construcao

2.2 Contexto 9

de mecanismos que auxilie na construcao destes; e

• Validar sistemas cientes de contexto.Para validar um sistema ciente de contexto,

e necessario testar o funcionamento deste em situacoes reais com alguns usuarios e

analisar os resultados.

Baldauf et al. [17] definem sensor como sendo qualquer fonte de dados que prove

informacoes contextuais. Considerando a maneira como os dados foram capturados, os

sensores podem ser classificados como: sensores fısicos, quando representam o hardware

utilizado para captar informacoes do ambiente; sensores virtuais, quando adquirem os dados

de aplicacoes ou servicos; e sensores logicos, quando utilizam um conjunto de outras fontes

de dados – incluindo outros sensores – para inferir novas informacoes. Por exemplo, o GPSe

um sensor fısico, enquanto que uma agenda de compromissos na Web que indica a atividade

que o usuario esta realizandoe um sensor virtual e um sistema que infere a localizacao do

usuario a partir de sua agenda de compromissose um sensor logico.

Schilit e Theimer[18] foram dois dos precursores na pesquisa envolvendo sistemascien-

tes de contexto, sendo dada por eles a seguinte definicao: ciente de contextoe a habilidade de

uma aplicacao de descobrir e reagiras mudancas no ambiente. Ja com relacaoa classificacao

de contexto, eles propuseram a seguinte:

• Contexto computacional.Este contexto esta associadoas informacoes do dispositivo

que esta sendo utilizado. Por exemplo: memoria disponıvel e tamanho do visor;

• Contexto do usuario. Este contexto esta associadoas informacoes do usuario. Por

exemplo: pressao sanguınea e temperatura corporal; e

• Contexto fısico. Este contexto esta associadoas informacoes do ambiente fısico ao

redor do usuario. Por exemplo: temperatura ambiente e pressao atmosferica.

Dentre os sistemas cientes de contexto, um dos tipos que maisestao sendo utilizados,

fora do ambito dos laboratorios de pesquisas, sao as aplicacoes nas quais o contexto de

localizacao do usuario e o foco[19]. Na proxima secao, serao descritas mais caracterısticas

dos Servicos Baseados em Localizacao (LBS).

2.3 Servicos Baseados em Localizacao 10

2.3 Servicos Baseados em Localizacao

Servicos que sao fornecidos baseados em alguma localizacao espacial sao chamados de

Servicos Baseados em Localizacao (LBS) [5]. Alguns exemplos de LBS sao sistemas de

navegacao de carros, sistemas de monitoramento de caminhoes, entre outros.

Segundo Schiller e Voisard[4], LBS pode ser definido como um servico que integra

localizacao ou posicao de um dispositivo movel com outras informacoes, para adicionar

valor para o usuario.

LBS tem sido umaarea bastante pesquisada devido ao barateamento dos equipamentos

necessarios para a utilizacao destes, como por exemplo, o GPS e smartphones. Alem disto, os

avancos tecnologicos tem permitido cada vez mais uma maior capacidade de armazenamento

e processamento em dispositivos moveis.

As aplicacoes LBS podem ser classificadas como do tipopull ou push, sendo as

aplicacoes do primeiro tipo as que fornecem servicos requisitadospelos usuarios, ou seja,

os usuarios possuem o controle de quando os servicos irao ser fornecidos. Por outro lado, no

servico do tipopush, os usuarios nao possuem o controle de quando este sera fornecido. Um

exemplo de servico do tipopull e o de procura de amigos, no qual o usuario pede para o sis-

tema localizar algum amigo. Como exemplo de servicopush, podem ser citados os servicos

de monitoramento de amigos, os quais lancam um alerta quando algum amigo esta proximo

do usuario.

Os servicospushresultam em um alto preco pela transparencia e comodidade oferecida,

sendo muito mais caros do que os servicospull. Este alto custoe devidoa maior quantidade

de recurso de rede necessario, pois a localizacao do usuario precisa ser atualizada constan-

temente. Alem disto, os servicospushpossuem a questao da privacidade do usuario, devido

ao monitoramento constante de sua localizacao por terceiros.

No momento de criacao de aplicacoes LBS, algumas caracterısticas do sistema a ser

implementado devem ser levadas em consideracao[5]. Algumas destas sao:

• A aplicacao sera baseada em servicospushoupull?

• Os perfis dos usuarios podem ser adquiridos indiretamente ou so diretamente?

• Quais informacoes do perfil do usuario serao disponıveis?

2.4 Representacao do Conhecimento, Ontologias e Web Semantica 11

• Quais os cenarios possıveis de interacao no sistema?

– Requisitante e provedor sao estacionarios?

– Um e estacionario e outro nao. Por exemplo, um carro que emite sua

localizacao pode ser visto como um provedor e o servidor LBS que consulta

essas informacoes como estacionario; e

– Os dois sao moveis. Por exemplo, um usuario que procura um amigo.

• Qual a fonte da informacao de localizacao?

• Qual o nıvel de precisao da localizacaoe necessario para a aplicacao?

• Sera mantido um historico do contexto e, caso seja, este historico sera utilizado para

tomadas de decisoes futuras?

• Qual o tipo de fonte de informacao?

– Estatica: banco de dados; e

– Dinamica: tempo, trafego.

2.4 Representacao do Conhecimento, Ontologias e Web

Semantica

Nesta secao, serao abordados conceitos importantes para aplicacoes cientes de contexto,

como a representacao do conhecimento, ontologias e Web Semantica.

A representacao de conhecimento atraves de ontologias tem ganhado forcas nosultimos

anos devidoa influencia da Web Semantica, que possui como um de seus pilares, a

representacao das informacoes na Web na forma de uma ontologia. Segundo Gruber[20], em

ciencia da computacao, ontologia define um conjunto de primitivas de representacao, com o

qual se modela um domınio de conhecimento, sendo este conjunto formado tipicamente por

classes, atributos e relacionamentos.

Ja a Web Semanticae considerada uma extensao da Web original, na qual a informacao

e dada com um significado bem definido, permitindo que computadores e pessoas trabalhem

2.4 Representacao do Conhecimento, Ontologias e Web Semantica 12

em cooperacao[21]. A Figura2.3apresenta as camadas da Web Semantica, como pode ser

observado uma das camadas superiorese formada por ontologias, as quais sao responsaveis

pela representacao do conteudo na Web de forma interpretavel por homens e maquinas. Na

camada acima das ontologias estao as regras, que definem como serao inferidos novos co-

nhecimentos na Web a partir dos ja conhecidos.

Figura 2.3: Camadas da Web Semantica (adaptada de http://www.w3.org/2001/sw).

Em aplicacoes simples, a escolha de uma representacao nao e importante, devidoa fa-

cilidade de manter um vocabulario consistente. Em aplicacoes complexas como as cientes

de contexto, porem, existe a necessidade de uma representacao mais geral e flexıvel. Con-

sequentemente, a forma como o conhecimentoe representado em aplicacoes cientes de con-

texto deve ser bem definida, sendo este processo conhecido como m odelagem de contexto.

O RDFS (RDF Schema)[22] e o OWL (Web Ontology Language)[23] estao entre as

principais linguagens de definicao e instanciacao de ontologias. RDFSe uma extensao

semantica do RDF (Resource Description Framework)[24] quee uma recomendacao W3C

para descrever recursos na Web. A estrutura de qualquer expressao RDFe uma colecao de

triplas, cada uma formada por um sujeito, um predicado (propriedade) e um objeto. O RDFS

possui um grande poder de descricao, porem, falta a capacidade de informar caracterısticas

das classes e propriedades, o quee possıvel com OWL. Por exemplo, informar que uma

propriedadee transitiva, simetrica, funcional ou inversa.

2.5 Modelagem de Contexto 13

O OWL e dividido em tres sublinguagens: OWL Lite, OWL DL e OWL Full. A expres-

sividade nestase aumentada na ordem apresentada. A OWL Litee a mais simples, sendo

todos os relacionamentos com cardinalidade zero ou um. Ja o OWL DL, permite o maximo

de expressividade sem perder a completude computacional – todos os vınculos sao garan-

tidos de serem computados – e a decidibilidade – as computacoes terminarao em tempo

finito – das maquinas de inferencia. Enquanto que o OWL Full, apesar de possuir a maior

expressividade, nao possui garantias de decidibilidade.

2.5 Modelagem de Contexto

Um modelo de contexto define os tipos, nomes, propriedades e atributos das entidades envol-

vidas nas aplicacoes cientes de contexto, como os usuarios, dispositivos moveis, contextos,

etc. O modelo tenta prover a representacao, busca, troca e interoperabilidade de informacao

contextual entre as aplicacoes.

Strang e Linnhoff[25] realizaram um estudo de comparacao entre as principais aborda-

gens para modelagem de contexto. Para tanto, foram considerados os seguintes requisitos:

1. Composicao distribuıda: capacidade do modelo de ser descrito de maneira dis-

tribuıda;

2. Validacao parcial: facilidade para deteccao de conhecimento contextual invalido, de

acordo com a descricao do modelo;

3. Riqueza e qualidade da informacao: o modelo de contexto utilizado deve permitir a

descricao da qualidade e riqueza da informacao fornecida, pois estae bastante variavel

em aplicacoes cientes de contexto;

4. Incompletude e ambiguidade:as informacoes contextuais descrevendo um ambiente,

geralmente, sao incompletas e ambıguas, quando envolvem uma rede de sensores.

Estes aspectos da informacao devem ser cobertos pelo modelo;

5. Nıvel de formalidade: e importante que haja um compreendimento compartilhado

dos significados das informacoes existentes no modelo, o que gera a necessidade de

um alto grau de formalismo na descricao deste; e

2.5 Modelagem de Contexto 14

6. Aplicabilidade em ambientes existentes:do ponto de vista da implementacao, o

modelo de contexto deve ser aplicavel ao ambiente tecnologico disponıvel para o de-

senvolvimento de aplicacoes cientes de contexto.

Adotando como criterio a estrutura de dados utilizada, as tecnicas para modelagem de

contexto podem ser classificadas em:

• Modelos Chave-Valor: este modeloe a estrutura de dados mais simples para mode-

lagem de contexto. O contextoe representado no formato de uma lista de pares de

chaves, como “temperatura”, e valores, como “370C”. Esta tecnica de modelagem foi

utilizada por Schilit et al.[26];

• Modelos Baseados em Esquemas de Marcacao: a principal linguagem para a

descricao das informacoes contextuais neste modelose o XML (eXtensible Markup

Language)[27], a qual organiza estas informacoes de maneira hierarquica atraves de

tagscom atributos e valores. Um dos representantes dos modelos desta categoriae o

CSCP[28] que estende o CC/PP da W3C[29];

• Modelos Graficos: Elementos graficos sao utilizados na modelagem feita utilizando

esta tecnica. Como exemplos de modelos que utilizam esta tecnica temos: o CMP

(Context UML Profile)[30], que utiliza a linguagem UML (Unified Modeling Lan-

guage) para descrever o modelo; e CML (Context Modelling Language) [31], que

utiliza ORM (Object Role Modeling)[32];

• Modelos Orientados a Objetos:Esta tecnica para modelagem de contexto permite

que sejam aproveitados os principais benefıcios das abordagens orientada a objetos,

que sao, a encapsulamento e a reusabilidade. Em Cheverstet al. [33], foi utilizada

uma abordagem de modelagem de contexto orientada a objetos para gerar o modelo

chamado deActive Object Model;

• Modelos Baseados em Logica: Nesta abordagem os modelos sao descritos atraves de

fatos, expressoes e regras, podendo novos fatos serem derivados a partir doprocesso

de inferencia sobre as regras. Como exemplos de modelos que utilizam esta tecnica

podemos citar o CASS[34] e o proposto por Niuet al. [35]; e

2.6 Consideracoes Finais 15

• Modelos Baseados em Ontologia:Esta abordagem utiliza ontologias para descrever

as entidades do sistemas e seus relacionamentos. Esta tecnicae uma das mais pro-

missoras, devido ao grande poder de descricao das ontologias. O Omnipresent[36],

o SOCAM [7] e o FLAME2008[10] sao bons exemplos de sistemas que utilizam

modelos de contexto baseados em ontologias.

Ainda no trabalho de Strang e Linnhoff[25], foi exposto que os modelos baseados em

ontologias sao os mais expressivos e preenchem todos os requisitos descritos anteriormente,

como pode ser observado na Tabela2.2, na qual ’++’ indica que a abordagem atende total-

mente ao requisito, ’+’ indica que atende parcialmente e ’-’que nao atende. Consequen-

temente, uma abordagem baseada em ontologiase a mais indicada para a modelagem de

contexto.

Tabela 2.2: Comparacao entre abordagens para modelagem de contexto (adaptado de[25]).

Abordagens/ Requisitos 1 2 3 4 5 6

Chave-Valor - - - - - +

Esquemas de Marcacao + ++ - - ++ +

Graficos - - + - + +

Orientado a Objetos ++ + + + + +

Logica ++ - - - ++ -

Ontologia ++ ++ + + ++ +

A utilizacao de ontologias para a modelagem de contexto tem sido um dos grandes temas

estudados por pesquisadores[7][10][37], devidoa necessidade de uma maior expressividade

na modelagem de contexto[9]. No entanto, ainda falta uma padronizacao na forma como o

contextoe modelado utilizando esta abordagem.

2.6 Consideracoes Finais

Neste capıtulo, foram apresentados alguns conceitos gerais necessarios para o entendimento

desta dissertacao, como a computacao ubıqua, contexto, representacao do conhecimento,

ontologias e modelagem de contexto. Em Baudaufet al. [17] e apresentada uma analise


sobre aplicacoes cientes de contexto, ondee possıvel obter mais informacoes sobre o tema.

No proximo capıtulo, serao apresentados alguns trabalhos relacionados.

Capıtulo 3

Trabalhos Relacionados

Neste capıtulo, serao abordadas algumas ferramentas propostas na literatura para o desen-

volvimento de aplicacoes cientes de contexto. Serao observadas nas aplicacoes suas arquite-

turas, contribuicoes e lacunas. Uma atencao especial foi dada as ferramentas de criacao de

aplicacoes cientes de contexto que possuem o foco no usuario final, por ser um dos principais

objetivos deste trabalho.

O restante do capıtulo esta organizado da seguinte forma: na proxima secao, sera apre-

sentada a plataforma FLAME2008. Na secao seguinte, serao apresentadas as plataformas

WASP e Infraware. Na secao 3.3, descreve-se a ferramenta MScape. Na secao seguinte,

e apresentado o sistema StramSpin. Ja na secao 3.5, apresenta-se omidlewareSOCAM.

Na secao 3.6 apresenta a ferramenta iCAP e oframeworkContext Toolkit. Para finalizar

a lista de trabalhos relacionados, na secao 3.7, e apresentado o Omnipresent. Em seguida,

e apresentada uma comparacao entre os trabalhos descritos. Por fim, sao apresentadas as

consideracoes finais deste capıtulo.

3.1 FLAME2008

O FLAME2008 [10] utiliza uma abstracao em relacao ao contexto, chamada de situacao,

que acontece quando algumas caracterısticas do contexto ficam inalteradas durante algum

intervalo de tempo. Devido a esta abstracao, os servicos sao chamados de cientes de situacao.

O FLAME2008 [10] e uma plataforma de servicos cientes de situacao, desenvolvida para

ser utilizada durante os jogos olımpicos de 2008 em Pequim. Nesta plataforma,e utilizado

17

3.1 FLAME2008 18

um nıvel semantico para identificar os servicos que mais se aproximam das demandas dos

usuarios, que nao necessitam procura-los.

Na Figura3.1, pode ser visualizada a arquitetura do FLAME2008, quee formada por

tres camadas, sendo a primeira camada formada pelos clientes,a segunda formada pela pla-

taforma de servicos e a terceira formada pelos fornecedores de conteudo. A plataformae

composta de um conjunto de servidores, que sao:

Figura 3.1: Arquitetura do FLAME2008 (adaptada de[10]).

• O servidor Logıstica de Informacao, que implementa os mecanismos de

comunicacao pushe pull, para o fornecimento de informacoes e servicos, baseado

no casamento semantico dos servicos com as situacoes, atraves do modulo Casamento

Semantico;

• O servidor Corretor de Conteudo, que possui os registros semanticos – atraves da

ontologia da aplicacao – e prove acesso aos conteudos;

• O servidor Perfis e Contextos, quee responsavel por fornecer informacoes – perfil e

contexto – do usuario para a deteccao de situacoes; e

• O servidor Verificador de Servicos[38], quee responsavel por fornecer os servicos

disponıveis naarea em que o usuario esta inserido e substituir os servicos disponibili-

zados quando a localizacao do usuario for alterada.

3.2 WASP e Infraware 19

No FLAME2008, os servicos nao sao acionados por regras e sim atraves de uma in-

ferencia semantica realizada sobre a descricao dos servicos e da situacao do usuario, sendo

analisada a semelhanca destes, para verificar quais serviços devem ser oferecidos.

Para habilitar a selecao flexıvel de servicos para os usuarios em um nıvel semantico,e

necessaria a descricao semantica das situacoes e dos servicos oferecidos. Assim, sao utili-

zadas ontologias para estas descricoes, podendo ser realizadas inferencias para a selecao de

servicos personalizados, que atendamas necessidades do usuario na sua situacao atual.

Todas as vezes que acontece alguma alteracao significante no contexto do usuario, e

realizada a procura por servicos que possuam semelhancaa situacao atual do usuario, sendo

todos os servicos resultantes enviados para o dispositivomovel do usuario.

As principais contribuicoes do FLAME2008 sao: o oferecimento de servicos personali-

zados baseados na situacao do usuario sem a necessidade da interferencia dele e a utilizacao

de ontologias para descrever semanticamente os perfis, servicos e situacoes, possibilitando a

inferencia para selecao de servicos.

Uma caracterıstica que falta no FLAME2008e o monitoramento de situacoes de ter-

ceiros, principalmente para o proposito que a plataforma foi criada – eventos com grande

concentracao de pessoas. Por exemplo, se o usuario desejar saber onde esta uma atleta para

pedir um autografo, necessitara monitorar o contexto dele.

No FLAME2008, nao ha a possibilidade do usuario se inscrever em algum servico, dessa

forma, o usuario nao possui o controle sobre os servicos fornecidos a ele, comisso, muitos

servicos que nao sao do seu interesse sao oferecidos.

No processo de desenvolvimento da plataforma de servicos para os Jogos Olımpicos de

Pequim, o FLAME2008 foi renomeado para COMPASS2008, sendo colocado um prototipo

em execucao e testado com usuarios[39].

3.2 WASP e Infraware

WASP (Web Architectures for Services Platforms)[9] e uma plataforma para servicos cientes

de contexto, que oferece o apoioa construcao e execucao dessas aplicacoes. Na Figura3.2,

sao mostrados os tres elementos com os quais a plataforma WASP possui relacionamentos,

sendo eles:


Figura 3.2: Plataforma WASP e seus relacionamentos (adaptada de[9]).

• Os Provedores de Contexto, que sao responsaveis por fornecer as informacoes de con-

texto provindas de sensores, estruturas computacionais ououtros provedores de con-

texto;

• Os Provedores de Servico, que sao entidades que fornecem servicosa plataforma,

havendo a necessidade dos servicos serem publicados e registrados; e

• As Aplicacoes WASP, que sao as aplicacoes sensıveis ao contexto, que utilizam a

plataforma WASP para ter acessoa assinatura de servicos e as informacoes contextuais

dos Provedores de Contexto.

As informacoes de contexto e os servicos sao definidos na plataforma WASP atraves de

ontologias, para auxiliar a criacao de novos servicos e a descricao de regras que ativarao os

servicos disponıveis pelos provedores de servicos. O monitoramento do contexto e das regras

e realizado pela plataforma, sendo algumas vezes necessario que informacoes de contexto

das aplicacoes sejam fornecidas atraves de provedores de contexto para a plataforma (ver

Figura3.3).

Para a descricao de regras, a plataforma WASP possui uma linguagem de comunicacao

entre as aplicacoes e a plataforma, para que as aplicacoes especifiquem como a plataforma

deve reagir a um determinado contexto.

Existe uma camada de Privacidade na plataforma WASP, a qual permite um controle so-

bre o fluxo de informacoes provindas dos provedores de contexto e servico, que sao utilizadas

pela plataforma e pelas aplicacoes.


Figura 3.3: Arquitetura da plataforma WASP (adaptada de[9]).

O Infraware[40] [41] e uma plataforma que esta dando continuidade ao projeto iniciado

com a plataforma WASP, sendo desenvolvida na Universidade Federal do Espırito Santo.

O Infraware pretende estender as funcionalidades da plataforma WASP com o objetivo de

tornar a arquitetura mais flexıvel, permitindo a adicao de novos servicos e a interpretacao

num nıvel mais abstrato do contexto. Na Figura3.4, pode ser observada a arquitetura do

Infraware, a qual possui modulos adicionais de manipulacao semantica em relacaoa arquite-

tura da plataforma WASP, sendo esta semantica utilizada, entre outras funcionalidades, para

a composicao de servicos.

Um dos problemas destes sistemase a falta de uma ferramenta que auxilie a criacao

de novos servicos e de criacao de regras, pois a utilizacao de uma semantica, atraves de

ontologias, naoe o suficiente para auxiliar na criacao de servicos e de regras para a aplicacao

cliente.

3.3 MScape 22

Figura 3.4: Arquitetura da plataforma Infraware (retiradade[40]).

3.3 MScape

MScape[42] e um projeto da HP, que tem como objetivo o auxılio na criacao, no comparti-

lhamento e na distribuicao de mediascapes por usuarios de dispositivos moveis. Mediascape

e uma experiencia multimıdia ciente de contexto que permite acionar conteudos multimıdia

baseados no contexto.

Um mediascape pode ser executado em um dispositivo movel que possua a aplicacao

instalada, sendo um arquivo de mıdia apresentado quando determinado contexto acontecer.

A existencia de um portal Web torna possıvel o compartilhamento e distribuicao dos

mediascapes pelos usuarios, alem de poderem trocar experiencias obtidas no processo de

criacao, atraves de um forum de discussao.

Na Figura3.5, podem ser observados os componentes basicos de um mediascape, que

sao: a parte logica, as entradas do usuario, os sensores e os arquivos de mıdia.

Para facilitar o processo de criacao de um mediascape por usuarios, foi desenvolvida

uma ferramenta para auxilia-los (ver Figura3.6). A ferramenta de construcao de mediascape

possui uma interface de construcao baseada em regras de contexto. Desta forma,e possıvel

criar regras do tipo: quando o usuario estiver inserido em uma determinadaarea geografica,

entao sera mostrado um determinado vıdeo sobre aquele local.

3.3 MScape 23

Figura 3.5: Componentes de um mediascape (adaptada de[42]).

Figura 3.6: Ferramenta de criacao de mediascapes (retirada de[42]).

3.3 MScape 24

Os seguintes requisitos foram utilizados para a criacao da ferramenta de construcao de

mediascape:

• Uma linguagem extensıvel para descrever o contexto.Existe uma linguagem de

script na ferramenta, com a qual o usuario pode manipular as informacoes recebidas

dos sensores.

• Especificacao de eventos contextuais e as suas consequencias. Atraves da lingua-

gem de scripte possıvel determinar consequencias de acordo com um estado contex-

tual no qual o usuario esta inserido.

• A representacao do estado contextual.Com eventos lancados quando o usuario “en-

tra” ou “sai” de um determinado contextoe possıvel representar os estados contextuais

possıveis e suas consequencias.

• O armazenamento e gerenciamento de arquivos de mıdia. Arquivos multimıdia

podem ser carregados no sistema, para posteriormente seremutilizados na geracao de

regras.

• Uma interface de criacao que permite nao programadores explorar novos generos

de mediascape.Atraves de uma interface visual de criacao de regrase possıvel que

usuarios nao programadores consigam criar mediascapes.

• Um emulador para testar as regras criadas.O emulador que acompanha a ferra-

menta de criacao possui ferramentas para simular informacoes retornadas por um GPS

e ativacoes de botoes no dispositivo, mas para haver o suporte a outro tipo de sensore

necessario a adicao de um plugina ferramenta.

As grandes contribuicoes do MScape sao: a liberdade oferecida para os usuarios cri-

arem suas proprias aplicacoes com uma ferramenta visual; a opcao de testar o funciona-

mento do mediascape criado em um emulador; e a existencia de um portal no qual pode-se

compartilhar e distribuir os mediascapes criados, alem de ser possıvel a discussao sobre as

experiencias na criacao.

Apesar da ferramenta de emulacao de mediascapes ser uma das grandes contribuicoes

do MScape, esta possui a limitacao de so permitir a simulacao do GPS, nao permitindo a

simulacao de outros sensores.

3.4 StreamSpin 25

Uma caracterıstica marcante que falta ao MScapee a possibilidade de adicao de arquivos

multimıdia pelo proprio dispositivo movel, podendo assim criar ou alterar mediascapes a

partir do proprio dispositivo movel. Por exemplo, um usuario poderia tirar uma foto e gerar

um mediascape com essa foto, de forma que, quando o usuario estivesse nesta mesmaarea

novamente a foto fosse mostrada.

Outro problema detectado no MScapee que a alteracao de um mediascape torna-se quase

inviavel, pois seria necessario utilizar a ferramenta de criacao de mediascape e novamente

adicionar no portal Web. Deste modo, pessoas que ja haviam baixado o mediascape desa-

tualizado teriam que substituir o mediscape antigo. Alem disto, o armazenamento de varios

mediascapes nos dispositivos moveis pode nao ser viavel, pois o espaco de armazenamento

nos dispositivos moveise reduzido. Assim sendo, seria mais interessante o armazenamento

em um servidor central. Desta forma, ao inves de baixar o mediascape para o dispositivo, os

usuarios iriam executa-lo de uma plataforma.

3.4 StreamSpin

O projeto StreamSpin desenvolvido na Universidade de Alborg [43] [13], tem como objetivo

criar um portal onde se concentrem os servicos disponıveis para os dispositivos moveis,

sendo estes servicos na sua grande maioria cientes de contexto. Com isso,e mantida uma

API para o desenvolvimento dos servicos e um sistema de cadastro de usuarios, os quais

podem gerenciar suas inscricoes nos servicos e adicionarem seus proprios servicos para a

comunidade.

Na Figura3.7, e apresentada a arquitetura do portal StreamSpin, a quale formada por

tres modulos: o modulo de Servicos Web, responsavel pelo gerenciamento dos servicos

disponıveis; o modulo do Sıtio Web, responsavel pelo gerenciamento dos usuarios no sis-

tema e pela distribuicao dos servicos; e o Nucleo, responsavel pela execucao de casamento

semantico e gerenciamento da distribuicao dos servicos.

O grande lema do projeto StreamSpine ser para servicos moveis o que o YouTubee

para os vıdeos. A grande contribuicao do projeto, segundo os autores,e facilitar criacao e

compartilhamento de servicos moveis.

Um dos grandes problemas do StreamSpine que para criar um servico, o usuario deve ser

3.5 SOCAM 26

Figura 3.7: Arquitetura da plataforma StreamSpin (adaptada de[13]).

um programador, pois so e fornecida uma API de desenvolvimento e nenhuma ferramenta

para auxiliar na criacao do servico. Devidoas grandes dificuldades de se construir uma

aplicacao ciente de contexto de maneiraad hoc, torna-se quase que inviavel a criacao de

servicos pelos usuarios finais. Alem disso, para a adicao de novos sensores para a captacao

de novos contextos,e necessario estender a API fornecida, o que exige experiencia do usuario

com programacao.

O controle de acesso e privacidadee quase inexistente. Desta forma, nao ha a possibili-

dade de um usuario acessar o contexto de outro usuario.

O fornecimento de mapase outro problema, pois deixa a responsabilidade para o servico

a ser criado, nao existindo um servico padrao de fornecimento de mapas.

3.5 SOCAM

O SOCAM (Service-Oriented Context-Aware Middleware)[7] e um intermediador para a

construcao de aplicacoes cientes de contexto, cujo modelo de contextoe baseado em ontolo-

gia.

Na Figura3.8, pode ser visualizado o modelo baseado em ontologia, quee formado

por dois nıveis de hierarquia. No nıvel inferior, estao contidas as ontologias de domınio

especıfico do sistema, como por exemplo, os domınios de uma casa e um veıculo. Ja o

nıvel superiore composto da ontologia geral do sistema, que possui conceitos gerais sobre

3.5 SOCAM 27

as outras ontologias. Desta forma, a ontologia de um domınio especıfico selecionada, pode

ser alterada dinamicamente. Por exemplo, quando o usuario esta em casa, entao a ontologia

de domınio selecionadae a de uma casa, mas se ele sair da casa e entrar em seu carro, entao

a ontologia selecionada sera a de um veıculo.

Figura 3.8: Modelo baseado em ontologia com dois nıveis de hierarquia (retirada de[7]).

Na Figura3.9, e apresentada a arquitetura do SOCAM, cujos elementos principais sao:

• Provedores de contexto: responsaveis pela separacao de um nıvel mais baixo de sen-

soriamento de um nıvel mais alto de manipulacao de contexto. Os provedores de

contexto necessitam ser registrados no Servico de Localizacao de Servico, para que

este possa ser utilizado por outros usuarios.

• Servico de localizacao de servico (SLS): servico responsavel pelo cadastro e

localizacao dos provedores de servico.

• Interpretador de contexto: responsavel pela interpretacao de contexto, para forne-

cer um nıvel mais alto de abstracao. O interpretador de contexto tambem pode ser

cadastrado no Servico de Localizacao de Servicos, para poder ser utilizado por outros

usuarios.

3.6 Context Toolkit e iCAP 28

Figura 3.9: Arquitetura do SOCAM (adaptada de[7]).

• Servicos moveis ciente de contexto: sao os servicos fornecidos ao usuario, com ou

sem o controle deste. Por exemplo, um servico de segurancade veıculo, nao pos-

sui controle do usuario, que recebe informacoes sobre as condicoes de transito nas

suas proximidades. Por outro lado, um servico de localizaçao de amigos, necessita da

requisicao do usuario para ser fornecido.

As principais contribuicoes do SOCAM sao: o modelo de contexto de dois nıveis

hierarquicos baseado em ontologia, devido ao alto nıvel semantico dado ao sistema; a capa-

cidade de alteracao dinamica da ontologia de domınio especıfico de acordo com o contexto;

e uma arquitetura orientada a servicos, que possibilita a adicao de novos servicos facilmente.

Por outro lado, a utilizacao somente de ontologias nao e o suficiente para o auxilio da

criacao de servicos. Alem disso, o SOCAM nao possui uma interface para os dispositivos

moveis, de maneira que, sejam utilizados os servicos fornecidos pelo sistema.

3.6 Context Toolkit e iCAP

O Context Toolkit[6] e um frameworkque auxilia na construcao de aplicacoes cientes de

contexto. Para isso, sao utilizados os seguintes conceitos: a separacao de preocupacoes, da

aquisicao e uso de contexto; a agregacao de contexto e a interpretacao de contexto.

Na Figura3.10, pode ser visualizada a arquitetura do Context Toolkit, quee composto

de tres elementos principais: oswidgets, que sao responsaveis pela coleta e encapsulamento

3.6 Context Toolkit e iCAP 29

das informacoes de contexto; o agregador, quee responsavel por agregar toda informacao

de contexto de uma entidade; e o interpretadoro, utilizado para abstrair as informacoes de

contexto.

Figura 3.10: Arquitetura do Context Toolkit (adaptada de[6]).

O Context Toolkite um framework para auxiliar na criacao de aplicacoes cientes de con-

texto num nıvel mais baixo de abstracao. Dessa forma, necessitando de outras ferramentas

para auxiliar na criacao de um sistema mais completo.

Um dos problemas do Context Toolkite a falta de um controle de privacidade das

informacoes de contexto. Alem disso, nao existe uma semantica para descrever o contexto e

as regras.

O Context-Aware Application Prototyper (iCAP)[11] e um sistema que permite usuarios

finais projetarem visualmente aplicacoes cientes de contexto. O iCAP permite que o usuario

descreva uma situacao e uma acao associada a esta. Para isso, possui uma interface de criaçao

de regras de forma visual, a qual utiliza o esquema de casamento de Pane e Myers[44] – que

representa o operadorANDna vertical e o operadorORna horizontal.

O iCAP possui uma boa interface com o usuario para a prototipacao e simulacao de

sistemas cientes de contexto pelos usuarios finais, utilizando o Context Toolkit. Entretanto,

foi desenvolvido focado mais naarea de Casas Inteligentes.

3.7 Omnipresent 30

3.7 Omnipresent

O Omnipresent[8] e um sistema ciente de contexto baseado em uma arquitetura orientada a

servico. Na Figura3.11, apresenta-se a arquitetura do Omnipresent quee formada por tres

camadas:

Figura 3.11: Arquitetura do Omnipresent (adaptada de[8]).

Na camada cliente, o Omnipresent possui duas formas de ser acessado, atraves de um

navegador Web ou em um dispositivo movel. Algumas funcionalidades podem ser acessadas

nas duas formas de acesso, que sao o monitoramento da localizacao de terceiros, a rota entre

dois pontos, a alteracao do contexto emocional e o status, o acesso de informacoes de pontos

de interesse, operacoes de aproximacao e deslocamento em um mapa e o recebimento de

alertas.

Por outro lado, algumas funcionalidades so podem ser acessadas em uma das formas de

acesso. Por exemplo, somente no navegador Webe possıvel criar regras sobre os estados

contextuais e somente no dispositivo movel e possıvel alterar os contextos fisiologicos e de

localizacao – atraves das informacoes captadas dos sensores.

E possıvel criar regras de estados contextuais – tanto do proprio usuario como de tercei-

3.7 Omnipresent 31

ros. As acoes podem ser no formato de alertas ou de e-mails, sendo que osalertas podem ser

visualizados tanto no dispositivo movel, quanto no navegador Web.

As regras de estados contextuais sao criadas no formato XML respeitando as definicoes

de um XSD, nao havendo uma forma visual de criar as regras. As acoes possıveis de uma

regra sao: o lancamento de alertas para o usuario desejado ou o envio de um e-mail.

Alguns servicos sao oferecidos no Omnipresent, sendo eles:

• O Servico de Apresentacao: utiliza o iGIS [45] para o fornecimento de mapa e de

informacoes sobre a localizacao. Este servicoe dividido em duas partes a WMS e a

WFS, que seguem os respectivos padroes da OGC[46][47];

• O Servico de Roteamento: servico que fornece o roteamento a partir de dois pontos;

• O Servico LBS: monitora os contextos de todos os usuarios, lancando alertas de

acordo com as regras criadas no sistema; e

• O Servico de Propaganda: servico para o lancamento de propagandas para o usuario

de acordo com suas preferencias e contexto.

As grandes contribuicoes do Omnipresent sao a proposta de uma arquitetura orientada a

servico, o monitoramento de diversos tipos de contextos alem da localizacao, a existencia de

um Sistema de Informacao Geografico no cliente, uma interface de gerenciamento de regras

pelo o usuario final e o monitoramento do contexto de terceiros.

O Omnipresent, porem, nao utiliza uma maquina de inferencia baseada em regras, ele

simplesmente compara informacoes de contexto atuais com os valores monitorados. Alem

disso, a extensao do modelo de contexto para suportar outros tipos de contextos e bastante

complicada, uma vez quee necessario a modificacao do codigo fonte e adicao de servicos

Web, que nao seguem um padrao. Outro problema refere-se aos servicos, uma vez que nao

e possıvel adicionar novos servicos em tempo de execucao, sendo necessario a criacao de

stubs1 e adicao do suporte destes no dispositivo movel.

O modelo de monitoramento de contexto e regras do Omnipresent [36] ao atualizar um

contexto que esta sendo monitorado, serao acionados todos que estao escutando as mudancas

neste. Entretanto, para a utilizacao eficiente deste modelo foi necessaria a nao utilizacao de

1Classes geradas automaticamente para abstrair as chamadasremotas de metodos.

3.8 Comparacao 32

uma maquina de inferencia e a simplificacao das regras contextuais possıveis no sistema,

restringindo as regras a um formato de arquivo XML que segue um XSD que da pouca

liberdade na criacao das regras, comparadaa complexidade de regras possıveis com o modelo

de contexto existente.

Outro problema detectado no Omnipresente que as acoes das regras que compoem os

servicospushso permitem enviar e-mail ou mandar um alerta, desta forma, limitando-se a

uma pequena diversidade de servicos.

3.8 Comparacao

Nesta secao, apresenta-se uma comparacao entre os trabalhos relacionados descritos neste

capıtulo. Para esta comparacao foram considerados as seguintes caracterısticas consideradas

relevantes para o proposito do trabalho ao qual trata esta dissertacao:

1. Modelo de contexto baseado em ontologias.Como descrito na secao2.5, uma abor-

dagem baseada em ontologiase a mais indicada para modelagem de contexto, devido

a sua grande expressividade e preenchimento de varios requisitos necessarios para um

modelo de contexto;

2. Extensibilidade do modelo de contexto.A natureza dinamica das aplicacoes cientes

de contexto geram mudancas rapidas e constantes nos requisitos destas aplicacoes[48],

consequentemente, o modelo de contexto deve se extensıvel para diminuir o tempo e

os custos no preenchimento dos novos requisitos;

3. Aquisicao de dados provindos de sensores fısicos, virtuais e logicos.As aplicacoes

cientes de contexto podem adquirir as informacoes contextuais de varios tipos de fon-

tes diferentes, gerando a necessidade das ferramentas que almejam dar suporte a estas

aplicacoes possuam uma forma de aquisicao desses varios tipos;

4. Interface grafica para criacao visual de regras contextuais. Para permitir que

usuarios finais possam criar regras contextuais, existe a necessidade de uma ferramenta

visual para este fim;


5. Emulador para validacao de regras contextuais.Apos criar regras contextuais, o

usuario necessita valida-las em um emulador antes de serem submetidas para o servi-

dor; e

6. Comunicacao entre os componentes que permita a adicao de novas informacoes

contextuais. Para permitir que o modelo de contexto seja estendido em tempo de

execucao, e necessario que a comunicacao entre os componentes do sistema permita

esta acao.

Na Tabela3.1, mostram-se quais trabalhos possuem as caracterısticas citadas anterior-

mente. Os campos marcados com ’+’ indicam que a ferramenta possui a determinada fun-

cionalidade, os marcados com ’-’ indicam que nao a possuem. Quando alguma ferramenta

possui parcialmente alguma funcionalidade, os campos sao marcados com ’+-’.

Tabela 3.1: Comparacao entre os trabalhos relacionados.


Neste capıtulo, foram descritos alguns trabalhos relacionados, sendo citadas suas principais

vantagens e desvantagens. Em seguida, foi apresentada uma comparacao entre os traba-

lhos, levando em consideracao algumas caracterısticas desejaveis para um sistema ciente de

contexto que permita a personalizacao pelo usuario final e seja extensıvel.

Algumas lacunas, referentesas caracterısticas citadas neste capıtulo, foram detectadas

nos trabalhos relacionados. Nenhum dos trabalhos possui uma comunicacao que facilite

a extensao do modelo de contexto, o que impede a modificacao do modelo em tempo de


execucao. Alem disto, somente dois trabalhos possuem uma forma visual decriacao de

regras contextuais, porem, estes nao possuem um modelo de contexto baseado em ontologias.

No proximo capıtulo, sera apresentado o servidor de contexto do VadeMecum e, no se-

guinte, as ferramentas CARE e CARE Emulator, as quais formam a infraestrutura proposta

neste trabalho, a qual possui todas as caracterısticas citadas neste capıtulo.

Capıtulo 4

VadeMecum

Este capıtulo apresenta o servidor de contexto do VadeMecum, quee responsavel pelo trata-

mento de informacoes contextuais. VadeMecume uma expressao latina que significa “vem

comigo”, sendo utilizada para indicar que o sistema acompanha o usuario onde quer que ele

esteja, remetendo para a ideia de computacao ubıqua.

O restante deste capıtulo esta organizado como segue. Na secao 4.1, descreve-se uma

visao geral do sistema proposto. Na secao seguinte,e apresentado o servidor de contexto

do VadeMecum. Na secao4.3, mostra-se o processo de criacao e validacao de regras con-

textuais pelo usuario final no VadeMecum. Por fim, naultima secao, sao apresentadas as

consideracoes finais do capıtulo.

4.1 Visao Geral do Sistema

Com o intuito de facilitar o desenvolvimento de aplicacoes cientes de contexto foi criada

a infraestrutura VadeMecum, quee formada pelo servidor de contexto do VadeMecum, a

ferramenta CARE, o CARE Emulator e uma aplicacao movel.

A Figura4.1 mostra a estrutura e o fluxo do sistema criado. O servidor de contexto do

VadeMecume responsavel pela aquisicao, armazenamento, inferencia e monitoramento das

informacoes contextuais. O funcionamento do servidore baseado em regras contextuais, que

indicam que as acoes devem ser executadas nas aplicacoes quando um determinado estado

contextual for atingido.

A adicao das regras contextuais no servidor de contexto do VadeMecume realizada pelo

35

4.2 Servidor de Contexto do VadeMecum 36

Figura 4.1: Esquema de criacao de regras

usuario final atraves da ferramenta CARE, que ira auxilia-lo no processo de especificacao

delas.

Apos criar as regras, o usuario possui a oportunidade de valida-las no CARE Emulator,

selecionando os estados contextuais possıveis e verificando se a acao desejada foi executada

quando um determinado estado foi escolhido. Em seguida, o usuario envia as regras criadas

para o servidor de contexto do VadeMecum, que ira monitorara-las juntamente com o estado

contextual do usuario.

4.2 Servidor de Contexto do VadeMecum

Segundo Costaet al. [48], a natureza dinamica das aplicacoes cientes de contexto e a

crescente integracao destas aplicacoes nas tarefas cotidianas das pessoas, geram mudancas

rapidas e constantes nos requisitos para as tecnologias de suporte a estas aplicacoes, alem de

nao ser possıvel prever totalmente essas mudancas. Por outro lado, desenvolver aplicacoes

cientes de contexto impacta em um alto custo e um grande consumo de tempo, devidoa

existencia de uma grande variedade de informacoes contextuais que podem ser utilizadas

nessas aplicacoes. Algumas dessas informacoes nao sao explıcitas ou nao podem ser obtidas


da leitura de um sensor, mas podem ser inferidas a partir de outras. Estes problemas tornam

bastante complexo o desenvolvimento dessas aplicacoes, sendo assim, o servidor de contexto

proposto neste capıtulo possui como objetivo solucionar alguns destes problemas.

O servidor de contexto do VadeMecum possui os seguintes requisitos funcionais: (i)

aquisicao de dados provindos de sensores fısicos, virtuais e logicos[17] [49]; (ii) processa-

mento dos dados brutos obtidos dos sensores para a transformacao em informacoes contextu-

ais; (iii) comunicacao entre os sensores com outros componentes da infraestrutura que estao

fisicamente dispostos de maneira distribuıda; (iv) armazenamento das informacoes contex-

tuais; (v) recuperacao das informacoes contextuais por servicos e aplicacoes; e (vi) monito-

ramento atraves de regras do estado contextual e lancamento de acoes para serem executadas

nas aplicacoes. Neste trabalho, nao foram considerados alguns pontos importantes, como

seguranca, privacidade e qualidade de contexto.

Para obter as funcionalidades (i) e (ii) foram construıdos os chamados provedores de

contexto, que possuem como finalidade a abstracao da aquisicao dos dados brutos dos sen-

sores, processar os dados para transformacao em informacoes contextuais e o envio destas

para o servidor de contexto. Ja para as funcionalidades (iii), (iv) e (v) foi construıdo um

modelo de contexto, o qual descreve logicamente como as informacoes sao armazenadas,

para a realizacao das operacoes de insercao, pelos provedores de contexto, e recuperacao,

pelas aplicacoes e servicos. Estas operacoes sao realizadas por uma comunicacao que segue

o protocolo HTTP (POST e GET) e as linguagens SPARQL Update e SPARQL, respectiva-

mente. Para a funcionalidade (vi),e utilizada uma maquina de inferencia baseada em regras

no servidor.

O restante desta secao esta organizada da seguinte forma: na proxima subsecao, sera

apresentado o modelo de contexto adotado para a construcao do sistema proposto neste tra-

balho. Na subsecao seguinte, sera apresentada a arquitetura proposta para o servidor de

contexto do VadeMecum. Na Subsecao4.2.3, serao descritas as questoes de implementacao.

Por fim, naultima subsecao, apresentam-se algumas consideracoes finais.

4.2.1 Modelo de Contexto do VadeMecum

Apoiando-se no estudo comparativo entre as abordagens paramodelagem de contexto apre-

sentado na secao2.5, foi utilizada uma abordagem baseada em ontologias para a modelagem


de contexto no VadeMecum, sendo o modelo proposto descrito na linguagem OWL (On-

tology Web Language)[23], devidoa alta expressividade desta, como informado na secao

2.4.

Al em das informacoes contextuais, o modelo proposto neste trabalho deve descrever as

entidades e relacionamentos envolvidos na criacao de regras e na apresentacao de acoes para

os usuarios. Outrossim, para prover uma maior interoperabilidade entre outros modelos e

facilitar o mapeamento entre estes, as classes da ontologiagerada utilizam vocabularios e

outras ontologias consagradas na literatura e industria, como o Dublin Core[50] e o FOAF

[51].

Para a representacao do contexto e das entidades que a possuem, foram criadas duas

classes,Contexte ContextEntity, respectivamente. A primeira deve ser estendida para a

adicao de um novo tipo de contexto no modelo. Ja a segunda deve ser estendida para a adicao

de uma nova entidade que possua algum contexto associado. Por exemplo, a classeUser –

representa o usuario no sistema – foi adicionada no sistema e esta estendeContextEntitye

a classeEnvironmentLocation– que representa a localizacao – estendeContext. No modelo

inicial ja foram adicionados alguns contextos baseado no trabalho deSchilit e Theimer[18],

que sao apresentados na Figura4.2.

Outro ponto importante no modeloe a propriedadehasContext, esta representa um re-

lacionamento entreContextEntitye Context. Para os subtipos deContextEntityrestricoes

devem existir para informar que informacoes contextuais esta entidade possui. Ja os contex-

tos possuem restricoes para os valores possıveis para cada um dos possıveis tipos. As classes

supracitadas e o relacionamento entre essas sao mostrados na Figura4.3.

As regras sao adicionadas no modelo, atraves da classe principalRule do modelo do

VadeMecum. A regrae composta de duas colecoes uma de pre-condicoes e outra de acoes,

sendo estas representadas pelas classesConditione Action, respectivamente. Na Figura4.4,

apresenta-se a parte da Ontologia do VadeMecum para a representacao de regras contextuais.

O modelo de contexto descrito nesta secao pode ser visto como um todo no ApendiceA.

4.2.2 Arquitetura

O servidor de contexto do VadeMecume responsavel pelo monitoramento do contexto e das

regras no sistema. Alem disto, este serve como um intermediario entre a aplicacao cliente

4.2

Se

rvido

rd

eC

on

textod

oV

ad

eM

ecu

m39

Figura 4.2: Contextos do modelo de contexto do VadeMecum.


Figura 4.3: Ontologia superior do modelo de contexto.

Figura 4.4: Ontologia do VadeMecum para regras.

no dispositivo movel e os servicos cientes de contexto disponıveis.

Os responsaveis por atualizar as informacoes contextuais no servidor sao os provedores

de contexto. Estes enviam as mudancas ocorridas no contexto para o servidor, ja indicando

no modelo qual contexto eles estao informando. Dessa forma, os provedores possuem a

tarefa de analisar informacoes provindas de sensores (GPS, pressao, temperatura corporal,

etc) ou outras informacoes externas (previsao do tempo, calendario, agenda, etc) e converter

em informacoes contextuais validas no modelo.

Outro ponto importante do servidor de contextoe a maquina de inferencia baseada em

regras utilizada para ativacao de acoes no sistema, sendo esta descrita na proxima subsecao.

Na Figura4.5, apresenta-se a arquitetura do servidor de contexto do VadeMecum, quee

composta pelo monitor de regras, pelo tratador de acoes, pelo Jena e pelo Joseki – os dois

ultimos serao descritos na secao 4.2.3. O monitor de regrase responsavel pelo monitora-

mento e gerenciamento das regras ativas no sistema, as quaisdevem ativar o tratador de

acoes quando alguma regra for satisfeita. O tratador de acoese o encarregado de adicionar

as acoes na base de dados e criar o relacionamento entre o usuario e a acao a ser mostrada.

O Jenae utilizado para a manipulacao do modelo e realizar a inferencia para a descoberta de


informacoes implıcitas. Ja o Josekie responsavel pela comunicacao com os provedores de

contexto, servicos e aplicacoes. Na proxima subsecao, sera discorrido sobre os provedores

de contexto e o papel deles na arquitetura do VadeMecum.

A base de conhecimento do VadeMecume formada pela base de fatos e a base de regras,

onde a primeira possui as informacoes contextuais e a segunda possui regras para a inferencia

de novas informacoes ou a ativacao de acoes que devem ocorrer quando um determinado

estado contextuale alcancado.

Figura 4.5: Arquitetura do servidor de contexto do VadeMecum.

Provedores de Contexto

Os provedores de contexto sao componentes distribuıdos responsaveis pelo tratamento de

dados brutos, transformando estes em informacoes contextuais para posterior adicao no ser-

vidor de contexto. No provedor de contexto naoe levado em consideracao a forma como o

contexto foi capturado, sendo adicionadas as informacoes contextuais na ontologia no servi-

dor de contexto atraves de uma comunicacao utilizando o SPARQL Update via o protocolo

HTTP Post.

O provedor de contexto assume a funcao de capturar os dados provindos dos sensores

e processa-los obtendo uma informacao de contexto tratada. Uma informacao de contexto

pode ser formada de um ou mais sensores, como tambem pode ser inferida, informada pelo


usuario ou entao recuperada do perfil descrito do objeto, que pode ser uma pessoa, um lugar

ou qualquer outra entidade que possua contexto. Dessa forma, o provedor de contexto pode

agrupar os dados sentidos de varios sensores para retornar uma informacao contextual.

O funcionamento dos provedores de contextoe baseado no padrao de projetoObserver

[52], sendo monitoradas alteracoes nos dados brutos dos sensores cadastrados, para quando

existir alguma alteracao nestes, os dados sejam processados de acordo com a implementacao

do provedor e retorne o contexto apropriado. Quando a informacao contextuale passada

pelo usuario, o provedor escuta da mesma forma o evento de alteracao de informacao e

envia o contexto processado para o servidor. Ja as informacoes inferidas, nao sao capturadas

por provedores de contexto, sendo da responsabilidade da maquina de inferencia a obtencao

destas informacoes.

Como pode ser observado exitem varias maneiras de se obter informacoes contextuais no

servidor de contexto VadeMecum, sendo elas:

• Atraves do processamento de dados brutos provindos de sensores por um provedor de

contexto;

• Pelo agrupamento de dados de sensores realizado por um provedor de contexto;

• Atraves de inferencia de um novo contexto realizado pela maquina de inferencia a

partir de regras cadastradas e o modelo de contexto;

• Captura de informacoes do perfil do usuario; e

• Informacao manual realizada pelo usuario.

Uma API foi criada com o intuito de facilitar a criacao de provedores de contexto, sendo

esta tarefa de responsabilidade de um desenvolvedor. NestaAPI, o provedor de contextoe

representado pela interfaceContextProviderIF, o qual possui tres metodos que devem ser

sobrescritos, o primeiroe responsavel por realizar o processamento adequado nos dados

brutos e retorna o contexto adequado, o segundo envia o contexto para o servidor de contexto

e o terceiroe olistenerque recebe as mudancas dos sensores que resultam no processamento

dos dados brutos para a geracao do contexto. A API ja fornece metodos para auxiliar a

geracao do codigo em SPARQL Update e para enviar este para o servidor.


Outras interfaces importantes disponibilizadas pela API para desenvolver provedores de

contexto sao: ContextIF, RawData, RawDataListener, RawDataProviderIF. Na Figura4.6,

mostra-se o diagrama de classes da API.

Figura 4.6: Diagrama de classes da API para criacao de provedores de contexto.

A API para criacao de provedores de contexto foi desenvolvida para a linguagem Java

nas suas plataformasStandard EditioneMicro Edition.

Modelo de inferencia baseado em regras

O servidor de contexto do VadeMecum utiliza um modelo de inferencia baseado em re-

gras para o monitoramento dos estados contextuais dos usuarios no sistema, dessa forma,e

possıvel adicionar regras que lancarao acoes caso essas sejam satisfeitas.

Uma regra no VadeMecume do tipo E-C-A (Event-Condition-Action), na qual o evento

e a atualizacao de alguma informacao contextual monitorada, a condicao e a descricao de

um estado contextual e a acaoe a operacao a ser executada quando a condicao for satisfeita.

Por exemplo, uma possıvel regrae: quando o usuario possuir algum contato proximo geo-

graficamente, entao a localizacao deste deve ser mostrada no mapa no dispositivo movel do

usuario. O Codigo Fonte4.1mostra a descricao formal da regra entendida pelo sistema.

Um usuario pode ter varias regras cadastradas, podendo ativa-las ou desativa-las a qual-


quer momento. Uma vez ativada a regra, esta sera avaliada todas as vezes que o subconjunto

do estado contextual contido na condicao for alterado e quando a condicao for satisfeita a

acao sera executada e a regra ficara desativada ate que o estado contextual nao seja mais

valido na condicao.

Codigo Fonte 4.1: Regra contextual no VadeMecum.

1 [ c o n t a c t N e a r : ( ? x h a sc o n t a c t John ) ( nea r ( ? x , John ) )−> showOnMap ( John , ? x ) ]

No servidor de contexto, estao disponıveis tres acoes possıveis: showMultimedia, que

recebe como parametro o usuario que recebera a acao e um arquivo multimıdia;showOnMap,

que recebe como parametro o usuario que recebera a acao e um objeto que sera mostrado

no mapa sua localizacao; esendMail, que recebe um endereco de e-mail e uma mensagem

para enviar ao destinatario. Entretanto,e possıvel que as acoes no VadeMecum acionem

servicos externos para que estes enviem alguma acao propria, podendo esta ser executada no

dispositivo movel de algum usuario ou nao.

4.2.3 Questoes de Implementacao

Nesta secao, serao discutidos as questoes de implementacao relacionadas ao servidor de

contexto do VadeMecum, sendo apresentadas as principais ferramentas utilizadas no desen-

volvimento desse sistema nas proximas subsecoes.

Protege

Para a descricao do modelo de contexto foi utilizada a ferramenta Protege [53] juntamente

com opluginpara OWL[54], esta auxilou a geracao da ontologia escrita em OWL. O Protege

e uma plataforma de codigo aberto desenvolvida pelo Stanford Center for Biomedical Infor-

matics Research para a criacao, visualizacao e manipulacao de ontologias em varios formatos

de representacao, como OWL, RDF e RDFS. Uma das principais caracterısticas dessa ferra-

mentae que ela permite a sua extensao atraves deplugins. Na Figura4.7, apresenta-se uma

imagem da interface do Protege com o modelo de contexto do VadeMecum aberto.

Apesar do Protege ser bastante utilizado pela comunidade cientıfica e ser uma das me-

lhores para a funcao a qual ela serve, esta possui diversas falhas e diferentesversoes para

situacoes diversas.


Figura 4.7: Ferramenta Protege com o plugin OWL.

Jena

O Jena[55] e umframeworkJava para a criacao de aplicacoes para a Web semantica. Este

possui uma API para manipulacao de ontologias escritas em RDF e OWL, permitindo o ar-

mazenamento destas em memoria principal ou secundaria. A realizacao de consultas sobre

os dados utilizando a linguagem SPARQL e um mecanismo de inferencia sao outras funcio-

nalidades importantes nesteframework.

O frameworkJena possui uma linguagem propria para a descricao de regras, as quais

podem ser executadas sobre uma base de dados em OWL utilizandoum mecanismo de in-

ferencia baseada em regras que vem contida no mesmo. Este mecanismo oferece tres mo-

delos distintos de execucao: o modeloforward chaining, o backward chaininge o modelo

hıbrido. O Codigo Fonte4.2resume a sintaxe informal das regras Jena, nas quais as vırgulas

sao opcionais.

Para as regras ficarem mais legıveis, Jena oferece suporte a utilizacao de namespaces

para URIs, necessitando apenas que estes sejam registrados previamente, sendo que alguns

namespaces ja sao incluıdos: RDF, RDFS, OWL, DAML e XSD (XML Schema).


Codigo Fonte 4.2: Sintaxe das regras no Jena.

1 Rule : = bare−r u l e .

2 or [ bare−r u l e ]

3 or [ ruleName : bare−r u l e ]

4

5 bare−r u l e : = term , . . . te rm−> hterm , . . . h term / / fo rward r u l e

6 or term , . . . te rm<− term , . . . te rm / / backward r u l e

7

8 hterm : = term

9 or [ bare−r u l e ]

10

11 te rm : = ( node , node , node ) / / t r i p l e p a t t e r n

12 or ( node , node , f u n c t o r ) / / ex tended t r i p l e p a t t e r n

13 or b u i l t i n ( node , . . . node ) / / i nvoke p r o c e d u r a l

14 / / p r i m i t i v e

15

16 f u n c t o r : = functorName ( node , . . . node ) / / s t r u c t u r e d l i t e ra l

17 node : = u r i−r e f / / e . g . h t t p : / / foo . com / eg

18 or p r e f i x : l o c a l n a m e / / e . g . r d f : t y p e

19 or ? varname / / v a r i a b l e

20 or ’a literal’ / / e i t h e r a s t r i n g or a

number

21 or number / / e . g . 42 or 25 .5

Joseki

Para o tratamento das consultas em SPARQL e das atualizacoes provindas dos provedores

de contexto em SPARQL Update via protocolo de comunicacao HTTP (GET e POST), foi

utilizado o servidor de SPARQL Joseki. Este sistema permite que a partir de alguns arquivos

de configuracao que descrevam o modelo ontologico a ser utilizado, seja possıvel realizar

consultas e atualizacoes no modelo utilizando o protocolo SPARQL.

O Joseki utiliza o Jena para a leitura em Java de ontologias descritas utilizando as lingua-

gens RDF e OWL. Alem disso, este permite que sejam utilizadas as maquinas de inferencia

existentes no Jena ou entao alguma externa.

Para o servidor de contexto do VadeMecum foram realizados testes com a maquina de


inferencia Pellet[56], esta permite realizar inferencias em ontologias descritas em OWL DL

atraves de DIG[57], que consiste de uma interface de comunicacao HTTP para envio de

mensagens em XML para uma maquina de inferencia externa. Entretanto, esta forma de

comunicacao nao permite a inferencia de regras, alem disso, o Pellet so da suporte a um

subconjunto de SWRL[58], chamado de DL-Safe Rules[59], nao sendo permitido neste a

utilizacao de primitivas, comoe possıvel com o Jena, que sao muitouteis nas regras con-

textuais, como na realizacao de operacoes topologicas sobre os dados espaciais[60] (ex.:

contatos que estao localizados no municıpio de Campina Grande).

Na descricao de um servico no Josekie possıvel descrever um modelo que possui outro

modelo interno, dessa forma,e possıvel especificar um modelo de inferencia baseado em

regras sobre outro modelo para inferencias no modelo OWL e outro descrevendo a base de

fatos, entretanto esta abordagem se mostrou muito lenta e pouco escalavel. A abordagem

utilizada para o servidor de contexto do VadeMecum, foi a utilizacao de um modelo de

inferencia baseada em regras com um subconjunto de regras de inferencia para modelos

descritos em OWL DL, desta forma, a solucao se tornou mais eficiente pois nao utiliza dois

modelos de inferencia diferentes.

O ApendiceB apresenta o arquivo de configuracao do Joseki com a descricao dos

servicos de consulta e atualizacao na base de conhecimento do VadeMecum e a especificacao

da maquina de inferencia baseada em regras.

SPARQL e SPARQL Update

SPARQL [61] e uma linguagem para consulta em RDF, a quale uma recomendacao da

W3C. Uma vez que OWL adiciona possibilidades mais referentes aopoder de inferencia –

por exemplo, igualdade, equivalencia e simetria de classes –, SPARQL tambem pode ser

utilizado para consultas a ontologias descritas em OWL.

Nesta linguagem, existem quatro formas diferentes de realizar consultas, podendo o re-

sultado ser no formato RDF ou XML, dependendo em qual das formas a consulta foi reali-

zada, sendo elas:

• SELECT: nas consultas realizadas com esta clausula sao retornados um conjunto de

variaveis que obedecem um determinado padrao de casamento no formato XML. O


Codigo Fonte4.3mostra um exemplo de consulta feita no VadeMecum utilizandoesta

forma;

• CONSTRUCT: e utilizado para a construcao de outros grafos RDF a partir do con-

sultado;

• ASK: retorna se existe um resultado para as condicoes desejadas, sendo retornado

apenas a resposta afirmativa ou negativa no formato XML; e

• DESCRIBE: e utilizado para adquirir informacoes sobre um recurso, sendo retorna

apenas um resultado no formato RDF.

Codigo Fonte 4.3: Exemplo de consulta em SPARQL SELECT.

1 PREFIX vade : <h t t p : / / www. l s i . dsc . u fcg . edu . br / vademecum . owl#>

2 PREFIX r d f : <h t t p : / / www. w3 . org /1999/02/22− rd f−syn tax−ns#>

3 SELECT ? u s e r ? c o n t e x t

4 WHERE {

5 ? u s e r vade : hasCon tex t ? c o n t e x t .

6 ? c o n t e x t r d f : t ype vade : Emotion .

7 }

O arquivo XML retornado quando sao realizadas consultas SELECT e ASK, obedece um

XSD especificado pela W3C[62]. No Codigo Fonte4.4, mostra-se um exemplo de XML

retornado por uma consulta SPARQL utilizando a clausula SELECT. Para uma consulta ASK

e retornada uma tag ”‘boolean”’ no lugar de ”‘results”’.

O servidor de contexto do VadeMecum aceita todas as formas deconsultas via SPARQL

descritas anteriormente. Nas aplicacoes moveis as consultas sao realizadas utilizando a

clausula SELECT, para a obtencao das acoes a serem executadas e de informacoes con-

textuais.

Da mesma forma que SPARQL via HTTP GETe utilizado para a obtencao das

informacoes contextuais,e necessaria uma maneira para adicionar estas no servidor de

contexto doVadeMecum, para isso, foi utilizada a linguagemSPARQL Update[63], esta

e uma extensao de SPARQL criada pela HP e submetida para a W3C como candidataa

recomendacao. No VadeMecum foram utilizadas tres formas de atualizacoes SPARQL Up-

date: INSERT, DELETE e MODIFY. A primeirae utilizada para adicionar informacoes


contextuais ainda nao existentes, a segundae utilizada para remover as existentes e aultima

e para a modificacao de informacoes ja existentes. No Codigo Fonte4.5, mostra-se uma

atualizacao feita no contexto de um usuario no servidor de contexto via SPARQL Update.

Codigo Fonte 4.4: Resultado de uma consulta SPARQL na forma SELECT.

1 <?xml v e r s i o n =”1.0”?>

2 <s p a r q l xmlns =” h t t p : / / www. w3 . org / 2 0 0 5 / s p a r q l− r e s u l t s #”>

3 <head>

4 <v a r i a b l e name=” u s e r ”/>

5 <v a r i a b l e name=” c o n t e x t ”/>

6 </head>

7 < r e s u l t s>

8 < r e s u l t>

9 

10 h t t p : / / www. l s i . dsc . u fcg . edu . br / vademecum . owl#Hugo

11 

12 

13 h t t p : / / www. l s i . dsc . u fcg . edu . br / vademecum . owl#happy

14 

15 </ r e s u l t>

16 . . .

17 </ r e s u l t s>

18 </ s p a r q l>

Codigo Fonte 4.5: Atualizando o contexto utilizando SPARQL Update no VadeMecum.

1 PREFIX vade : <h t t p : / / www. l s i . dsc . u fcg . edu . br / vademecum . owl#>

2 PREFIX r d f : <h t t p : / / www. w3 . org /1999/02/22− rd f−syn tax−ns#>

3 MODIFY

4 DELETE { vade : Hugo vade : hasCon tex t ? c}

5 INSERT { vade : Hugo vade : hasCon tex t vade : happy}

6 WHERE { vade : Hugo vade : hasCon tex t ? c .

7 ? c r d f : t ype vade : Emotion .}

4.3 Auxılio na criacao de regras pelos usuarios finais 50

4.3 Auxılio na criacao de regras pelos usuarios finais

As aplicacoes cientes de contexto baseadas em regras, sao solucoes que possuem por

definicao um alto grau de extensibilidade, entretanto, quando a tarefa de especificar as re-

gras ficam a criterio do desenvolvedor, estas perdem boa parte dessa caracterıstica, pois essa

atividade nao sera executada frequentemente. Portanto, essa tarefa deve serrealizada pe-

los maiores interessados no comportamento das aplicacoes, que sao os usuarios finais do

sistema, porem, existem diversas dificuldades na especificacao de regras contextuais, o que

gera a necessidade de uma ferramenta que auxilie o usuario final nesse processo. Com este

objetivo, foi criada a ferramenta CARE - Context-Aware Rule Editor.

A ferramenta CARE auxilia o usuario final a criar regras contextuais, tomando como foco

as aplicacoes para o servidor de contexto VadeMecum. Para cumprir o objetivo para o qual

foi proposto, o CARE usa o mesmo modelo de contexto do VadeMecum, sendo descobertas

as mudancas neste modelo em tempo de execucao e adaptando-seas alteracoes, tornando essa

ferramenta ideal para sistemas cientes de contexto, aos quais ocorrem mudancas constantes

no seu modelo devido ao surgimento de novos tipos de contexto.

Somando-sea ferramenta CARE, foi criado o CARE Emulator, que serve como um emu-

lador do funcionamento do servidor de contexto do VadeMecume permite que o usuario

valide as regras criadas antes de envia-las para o servidor. Este emulador permite que os

usuarios descrevam um determinado estado contextual e verifiquem se o resultado no dispo-

sitivo movel foi o esperado.

No restante desta secao, serao apresentadas as ferramentas CARE e CARE Emulator e

discutidas as questoes e os desafios relacionadosa criacao e validacao de regras contextuais

pelos usuarios finais. Inicialmente, na proxima subsecao, serao apresentados os requisitos

funcionais para as ferramentas expostas nesta secao. Em seguida, na subsecao seguinte,

serao descritos os requisitos nao funcionais. Nas subsecoes seguintes, serao apresentadas as

ferramentas CARE e CARE Emulator. Na subsecao4.3.5, serao descritas algumas questoes

de implementacao. Por fim, serao apresentadas as consideracoes finais da secao.


4.3.1 Requisitos Funcionais

Especificacao de eventos contextuais e suas consequencias

Sistemas cientes de contexto baseados em regras, possuem como elementos chaves a

especificacao de um estado contextual e uma consequencia associada. Um sistema que auxi-

lie o usuario na criacao de aplicacoes cientes de contexto desse tipo deve permitir a descricao

desses elementos.

Interface de criacao que permita nao-programadores especificar regras contextuais

Como o usuario que ira especificar as regras para as aplicacoes cientes de contexto nao

possuem habilidades de programador, entao a ferramenta devera possuir uma interface de

criacao visual que permita que o interessado consiga descrever asregras sem escrever ne-

nhuma linha de codigo.

Emulador para testar os estados contextuais e as consequencias

Apos descrever as regras contextuais que deseja que sejam executadas no VadeMecum, o

usuario necessitara valida-las antes de enviar para o servidor de contexto. Para executar

esta tarefa, o usuario precisara simular o estado contextual que foi utilizado na regra a ser

validada e verificar se a acao especificada sera executada. Assim uma ferramenta que emule

o funcionamento do servidor de contexto do VadeMecume almejada.

Descoberta de tipos de contexto e entidades que possuem estes em tempo de execucao

As alteracoes no modelo de contexto sao frequentes nos sistemas que dao suporte ao desen-

volvimento de aplicacoes cientes de contexto. Devido a este fato, a ferramenta para auxiliar

o usuario na especificacao de regras contextuais deve descobrir as entidades, os tipos de con-

texto e os relacionamentos existentes no sistema em tempo deexecucao, para nao precisar

que esta ferramenta seja modificada quando o modelo for alterado.

Descoberta de acoes permitidas nas regras em tempo de execucao

As acoes que podem ser executadas pelo sistemae outro ponto que deve ser descoberto em

tempo de execucao, pois a adicao de uma nova acao no sistema deve ser algo simples e rapido


de ser realizado.

Tratamento diferenciado para especificar alguns contextos

A maioria das informacoes contextuais podem ser representadas por tipos simples ou pri-

mitivos. Como exemplos, podem ser citados: a temperatura corporal ou do ambiente, os

batimentos cardıacos, o status de uma pessoa, etc. Porem algumas destas possuem uma

complexidade maior na sua especificacao, sendo este o caso do contexto de localizacao ge-

ografica, o qual pode ser representado por umaarea, ponto ou ate um lugar. Para estas

situacoes, a ferramenta deve permitir que sejam adicionados componentes especiais para o

tratamento destas, como botoes, janelas ou outros tipos destes na interface grafica com o

usuario.

Gerenciamento das regras

O gerenciamento das regrase outro ponto que a ferramenta deve suportar, permitindo a

adicao, remocao, edicao, habilitacao, desabilitacao e validacao de regras.

4.3.2 Requisitos Nao Funcionais

Utilizar o mesmo modelo de contexto do VadeMecum

A ferramenta proposta nesta pesquisa tem como objetivo servir como um auxiliador na

criacao de regras contextuais que seguem o modelo de cotexto do VadeMecum, portanto

este deve ser seguido pela ferramenta criada.

Aplicacao Web

A ferramenta deve executar na Web e abranger uma ampla gama debrowsers, para que seja

facilitado o acesso a essa, nao havendo a necessidade de instalacoes e atualizacoes dessa

pelos usuarios.


4.3.3 CARE

Com o intuito de auxiliar o usuario final na criacao de regras contextuais, a ferramenta

Context-Aware Rule Editor (CARE) foi criada. Este descobre elementos-chaves do modelo

de contexto do VadeMecum para criar uma interface visual na forma dewizardpara alcancar

seu objetivo.

Nesta secao, a ferramenta CARE sera descrita, sendo mostrada sua arquitetura, os princi-

pais elementos do modelo de contexto, a interface baseada emwidgets, o seu funcionamento,

outras funcionalidades para o CARE e algumas questoes de implementacao.

Arquitetura

Na Figura4.8, mostra-se um esboco da arquitetura do CARE, a quale formada por quatro

modulos principais: o tratador dowizard, o de gerenciamento de regras, o de gerenciamento

de funcoes e o interpretacao do modelo de contexto.

Figura 4.8: Arquitetura do CARE.

O tratador dowizard e responsavel por guiar o usuario na geracao da regra, buscando as


opcoes e mostrando-as na interface a cada passo seguido. Este tambem informa o conteudo

que estara contido em cada janela de criacao de regras, alem de gerenciar as variaveis de

cada sessao aberta pelos usuarios e manter o controle dewidgets.

Ja o gerenciador de regras tem a funcao de controle sobre as regras existentes na base de

dados, permitindo que as regras sejam enviadas para o CARE Emulator, removidas, editadas,

desabilitadas ou habilitadas no VadeMecum e adicionadas apos owizardde criacao.

O gerenciador de funcoese responsavel pela descoberta de funcoes que podem ser utili-

zadas nas regras, informando-as para o tratador dowizard. O modelo de contexto nao possui

informacoes sobre as funcoes permitidas pelas regras no VadeMecum, sendo estas descober-

tas a partir da leitura de um arquivo XML que possui a descricao destas. O Codigo Fonte4.6

apresenta um exemplo de arquivo XML contendo as funcoes que podem ser utilizadas pelas

regras no CARE.

Por ultimo, o interpretador do modelo de contexto faz a tarefa derealizar consultas no

modelo de contexto do VadeMecum, para descobrir os elementos chaves para a criacao de

regras contextuais. Por exemplo, quando o tratador dowizardnecessitar dos relacionamentos

de uma entidade, o interpretador ira buscar esta informacao no modelo.

Um modelo de contexto pode ser bastante complexo e possuir diversas informacoes nao

uteis para a criacao de regras contextuais, apenas uma parte do modelo de contexto do Va-

deMecume levado em consideracao. A parte quee lida pelo CARE sao as classes que

estendem duas classes chaves no modelo:Contexte ContextEntity. Estas representam os

elementos importantes do modelo de contexto do VadeMecum, representando o contexto e

as entidades que possuem contexto, respectivamente.

Com o modelo de contexto base simplificadoe possıvel dar uma maior liberdade para as

extensoes, alem de permitir que os sistemas fiquem fortemente acoplado a esse modelo e se

adaptem as suas modificacoes.

Interface Baseada em Widget

Alguns valores possıveis pelos relacionamentos nas regras contextuais no CARE sao trata-

dos de maneira especial. Estee o caso dos do tipoSpatialThing, quando um valor deste

deve ser selecionado, uma janelae aberta com um mapa, onde o usuario pode selecionar

qualquer ponto ouarea. O CARE foi criado de maneira que se algum outro tipo especial


seja necessario, entaoe possıvel adicionar umwidgetque sera acionado quando um valor do

tipo escolhido for ser selecionado. Owidget e um componente da interface grafica com o

usuario, como uma janela quee aberta ao clicar em um botao e retorna o valor selecionado

nesta.

Codigo Fonte 4.6: Exemplo de arquivo com as funcoes permitidas pelo CARE nas regras.

1 <?xml ve rs i on="1.0" encod ing ="iso-8859-1" ?>

2 <f uncoes>

3 <f uncao name ="greaterThan" a l i a s = "Maior Que" >

4 <params>

5 <param type ="http://www.w3.org/2001/XMLSchema#

int" name = "Primeiro valor" />

6 <param type ="http://www.w3.org/2001/XMLSchema#

int" name = "Segundo valor" />

7 < / params>

8 < / f uncao>

9 <f uncao name="near" a l i a s ="Pr oximo" >

10 <params>

11 <param name="Primeiro objeto georreferenciado"

t ype ="http://www.w3.org/2003/01/geo/wgs84_pos#

SpatialThing" />

12 <param name="Segundo objeto georreferenciado"

t ype ="http://www.w3.org/2003/01/geo/wgs84_pos#

SpatialThing" />

13 < / params>

14 < / f uncao>

15 <f uncao name="contains" a l i a s ="Est a Contido" >

16 <params>

17 <param name="Objeto Georreferenciado" t ype ="http:

//www.w3.org/2003/01/geo/wgs84_pos#

SpatialThing" />

18 <param name=" Area Geogr afica" t ype ="http://www.w3

.org/2003/01/geo/wgs84_pos#SpatialThing" />

19 < / params>

20 < / f uncao>

21 < / f uncoes>


Na Figura4.9, e mostrado owidgetpara selecao de elementos geograficos, sendo este

componente desenvolvido utilizando a API Flash do Google Maps.

Figura 4.9:Widgetpara selecao de elementos geograficos.

Para adicionar umwidget no CARE, e necessario criar os componentes da interface

grafica utilizando a linguagem ActionScript e configurar o tipode entidade que pode ser

selecionada. Como pode ser observado, esta nao e uma tarefa basica de ser executada. As-

sim, e necessario que o usuario possua experiencia com programacao para executa-la.

Funcionamento da Ferramenta

Na Figura4.10, e mostrada a interface do CARE, quee formada por duas partes principais:

a das pre-condicoes e a das acoes. Para montar uma regra, o usuario deve criar pelo menos

uma pre-condicao e acao, dessa forma, quando as pre-condicoes forem satisfeitas, as acoes

serao executadas.

Ao solicitar para criar uma pre-condicao, a tela mostrada na Figura4.11e apresentada

para o usuario, com as opcoes de criar uma condicao ou selecionar uma funcao. Caso seja

escolhida criar uma condicao, serao mostradas para o usuario todas as classes do tipoCon-


Fig

ura

4.10

:In

terf

ace

doC

AR

E.


textEntityexistentes no modelo (ver Figura4.12). Em seguida, o usuario podera selecionar

uma instancia da classe escolhida ou ir diretamente para escolha de um dos relacionamentos

listados, que tambem sao recuperados do modelo, como apresentado na Figura4.13. Apos

ter definido uma instancia e um relacionamento,e necessario que seja selecionado o valor

para o relacionamento.

Figura 4.11: Tela do CARE para selecao da opcao para especificar o estado contextual.

Figura 4.12: Tela do CARE para selecao da classe do tipoContextEntity.

Os valores possıveis para o relacionamento dependem do tipo especificado nomodelo

de contexto. Por exemplo, caso o usuario tenha selecionado o relacionamentohasContext,

entao sera mostrado para ele uma lista com os tipos de contextos possıveis para o domınio


Figura 4.13: Tela do CARE para selecao do relacionamento da entidade.

selecionado, no caso deUser seria mostrado as classes do tipoUserContext. Logo apos a

selecao do tipo de contexto, o usuario necessitara escolher uma instancia do tipo selecionado

ou entao uma faixa de valores, dependendo do tipo selecionado anteriormente.

Suponha-se que o usuario deseja especificar na regra que Jose possui statusidle. Entao,

os passos necessarios para realizar esta tarefa sao:

1. Selecao da classe User;

2. Selecao da instancia Jose;

3. Selecao do relacionamento hasContext;

4. Selecao da classe Status; e

5. Selecao do valor idle.

Para alguns valores,e possıvel efetuar a selecao de uma faixa. Por exemplo, para o

contexto temperaturae possıvel informar que o valor deste deve ser maior que 38◦C.

Nem sempre os valores de um relacionamento sao de um tipo primitivo (string, int, float,

etc), podendo ser uma classe definida no modelo. Neste caso, ainterface ira mostrar as

instancias ou relacionamentos que podem ser selecionados. Dessa forma, a interacao conti-

nuara ate que o usuario selecione um valor.


Outras funcionalidades para o CARE

O CARE foi criado inicialmente para a especificacao de regras contextuais pelos usuario

finais, informando que acoes deveriam ser executadas quando um determinado estado con-

textual for satisfeito. Porem, durante os estudos de casos foi percebido que esta ferramenta

pode ser utilizada tambem para servir como um descritor de sensores logicos e controle de

acesso.

Conforme dito no Capıtulo 2, os sensores logicos fornecem informacoes contextuais da

uniao de dois ou mais sensores ou da juncao de sensores com outras informacoes do perfil

do usuario. Os sensores desse tipo podem ser descritos atraves de regras, por exemplo, uma

regra pode indicar que se o usuario durante o horario comercial estiver no local de trabalho,

entao ele estara com o status ocupado. Por outro lado, a ferramenta CARE permite que o

usuario descreva nas condicoes de uma regra a uniao de contextos, sendo necessario somente

que no lado das acoes seja possıvel determinar o valor de um determinado contexto.

Ja para utilizar o CARE para controle de acesso, algumas funcoes necessitam ser imple-

mentadas no VadeMecum para permitir que um usuario conceda permissoes de acesso ao

seu contexto para outro usuario.

4.3.4 CARE Emulator

Para a validacao das regras criadas pelo usuario final foi criado um emulador do Sistema

VadeMecum, chamado de CARE Emulator. Este permite que todos osestados contextuais

contidos no modelo de contexto sejam simulados. Outro aspecto importantee que novos

contextos adicionados no modelo sao identificados em tempo de execucao, da mesma forma

que o CARE.

As regras criadas pelo CARE sao adicionadas no emulador e o usuario insere um valor

para os contextos desejados, a partir do momento que as pre-condicoes das regras sejam

satisfeitas, as acoes sao simuladas.

Na Figura4.14, mostra-se a arquitetura do CARE Emulator, que possui a mesma base

do VadeMecum, para realizar o monitoramento do contexto, entretanto a base de fatose

armazenada na sessao (ver Figura4.5).

O CARE Emulator possui como base o proprio servidor de contexto do VadeMecum,


sendo os provedores de contexto – responsaveis pela atualizacao das informacoes contextu-

ais no servidor – simulados pelos valores de contexto informados na interface pelo usuario.

O carregamento de regras contextuais no emulador acontece da mesma forma que no ser-

vidor de contexto, atraves do protocolo HTTP e utilizando a linguagem SPARQL Update,

adicionando instancias da classe vade:Rule na base de fatos. Para facilitar a utilizacao do

emulador, sem a participacao do CARE,e possıvel entrar com regras na propria interface.

Para emular as acoes executadas no dispositivo movel, estas sao capturadas por um “tratador

de acoes” (Action Handler) e mostradas para o usuario.

Figura 4.14: Arquitetura do CARE Emulator.

Funcionamento do Emulador

Na Figura4.15, mostra-se a interface do CARE Simulator, onde na parte central e seleci-

onado o contexto de localizacao das instancias selecionadas na parte inferior esquerda. Ja

na parte direita sao selecionados os valores dos outros tipos de contexto, sendo tratados de

maneira especial somente a localizacao e o tempo, que pode ser selecionado em uma janela


quee aberta, quando este for selecionado.

As acoes no CARE Emulator sao executadas na parte esquerda da interface, quando estao

executam algum comando no dispositivo movel dos usuarios do Sistema VadeMecum.

Para o usuario acompanhar o estado contextual de todos os usuarios no sistema que estao

sendo simulados, existe umaarvore de estados contextuais no lado direito na parte de baixo

da interface.

Para a selecao do estado contextual, o usuario segue os mesmos passos do CARE, se-

leciona a classe do tipo ContextEntity, em seguida sera mostrado os subtipos de Context

permitidos pelo domınio de hasContext selecionado e em seguidae selecionado o valor do

contexto. O usuario pode simular quantos contextos desejar, sendo o estadocontextual atu-

alizado naarvore simultaneamente, alem de ser monitorado, para verificar se alguma regra

foi satisfeita.

Para executar uma regra no CARE Emulator, existem duas formas:a primeirae quando

o usuario terminar de criar uma regra no CARE e clica num botao para validar a regras no

emulador; a segunda opcao e adicionar a regra manualmente na parte central inferior da

interface, no campo destinado para esse fim.

4.3.5 Questoes de Implementacao

A interface com o usuario no CARE foi feita utilizando Adobe Flex, quee uma tecnologia

que suporta o desenvolvimento de aplicacoes do tipo RIA (Rich Internet Application) para

a plataforma Adobe Flash. Ja para o servidor, foi utilizado a plataformaJava, Enterprise

Edition (JEE), sendo utilizado o BlazeDS1 para realizar o mapeamento de objetos de uma

plataforma para a outra.

Para a leitura do modelo de contexto do VadeMecum, foi utilizado o framework Jena.

Houve a tentativa de realizar a interpretacao do modelo de contexto utilizando a lingua-

gem SPARQL via o protocolo de comunicacao HTTP diretamente no servidor de contexto

do VadeMecum, entretanto, houve alguns problemas com relaçao as restricoes utilizadas

no modelo para restringir o conjunto imagem dos relacionamentos, alem da dificuldade na

interpretacao de objetos compostos por uma uniao de duas ou mais classe. Consequente-

mente, a adocao da leitura utilizando a mesma tecnologia do servidor de contexto – o fra-

1http://en.wikipedia.org/wiki/BlazeDS


Fig

ura

4.15

:In

terf

ace

doC

AR

EE

mul

ator

.

4.4 Consideracoes finais 64

mework Jena –, foi uma decisao tomada para facilitar o desenvolvimento do prototipo para

validacao de conceito proposto nesta dissertacao.

No CARE Emulator, esta disponıvel a apresentacao de tres acoes:showMultimedia, que

recebe como parametro o usuario que recebera a acao e um arquivo multimıdia;showOnMap,

que recebe como parametro o usuario que recebera a acao e um objeto que sera mostrado no

mapa sua localizacao; esendMail, que recebe um endereco de e-mail e uma mensagem para

enviar ao destinatario.

4.4 Consideracoes finais

O servidor de contexto do VadeMecum foi criado com o objetivode realizar o tratamento das

informacoes contextuais e disponibilizar estas atraves de uma comunicacao padrao. Outros

trabalhos na literatura tiveram a mesma proposta[6][7] [8][48], porem esta solucao destaca-

se pelo modelo de contexto baseado em ontologias, a comunicacao via HTTP para consultas

com SPARQL e atualizacoes com SPARQL Update e a facilidade de se adicionar novos tipos

de contexto, devido a um modelo de contexto extensıvel e um servidor de contexto que se

adaptaas mudancas no modelo.

Neste capıtulo, foi apresentado tambem a ferramenta CARE, quee um editor de regras

contextuais para usuarios finais, possuindo como principal objetivo o auxılio na criacao de

regras contextuais para o VadeMecum pelos usuarios finais. Alem disso, foi descrito o CARE

Emulator, que auxilia na validacao das regras pelos usuarios atraves da simulacao de estados

contextuais e a visualizacao das acoes que ocorrem nos dispositivos moveis.

Algumas ferramentas foram propostas na literatura com o intuito de auxiliar o usuario

final na criacao de aplicacoes cientes de contexto. Essas ferramentas podem ser divididas em

dois grupos principais, o que explora aplicacoes cientes de contexto para casas inteligentes

(smart homes), como o iCAP[11], a CAPpella[64] e o RuleCaster[65], e o que endereca

tais aplicacoes para dispositivos moveis, como o CAIPS[66], o MScape[42] e o StreamSpin

[13].

Nenhuma das ferramentas analisadas, porem, possui um modelo de contexto baseado

em ontologias, alem de nao permitirem a extensibilidade do modelo. Entretanto, estas ca-

racterısticas sao importantes devidoa grande quantidade de informacoes contextuais dis-

4.4 Consideracoes finais 65

ponıveis que podem ser utilizadas nas aplicacoes e nao foram previstas, alem de possibilitar

a inferencia de informacoes contextuais nao explıcitas na base de conhecimento.

Capıtulo 5

Estudo de Caso

Neste capıtulo, serao apresentadas algumas situacoes de uso da infraestrutura apresentada

nesta dissertacao que foram realizadas para verificacao do sistema proposto. As situacoes

descritas serao:

1. Outdoor Virtual : Uma aplicacao ciente de contexto que mostra propagandas mul-

timıdia no dispositivo do usuario de acordo com seu contexto; e

2. Multimedia Service: Uma aplicacao movel para a captura de aquivos multimıdia com

o contexto associado para posterior armazenamento e recuperacao destes a partir de

regras contextuais.

Para a criacao de aplicacoes cientes de contexto utilizando a infraestrutura apresentada

neste trabalho, foi desenvolvida uma aplicacao cliente generica para dispositivos moveis. A

aplicacao foi desenvolvida para a Plataforma Java Micro Edition (Java ME), sendo utilizada

a configuracao de dispositivo CLDC-1.1 (Connected Limited Device Configuration) e perfil

MIDP 2.0 (Mobile Information Device Profile). Para a criacao dos provedores de contexto

no dispositivo movel foi utilizada a API descrita na secao4.2.2.

Na Figura5.1, apresenta-se o diagrama de classes da implementacao do provedor de

contexto da localizacao do usuario no dispositivo movel, que captura os dados brutos pro-

vindos do GPS do dispositivo e os transforma em contexto para, em seguida, enviar para

o servidor de contexto do VadeMecum atraves do metodoupdateContextda classeLocati-

onContextProvider. Neste provedor, foi utilizada a especificacao JSR 179, que trata sobre

o acessoas informacoes sobre a localizacao geografica em dispositivos moveis, sendo esta

66

5.1 Outdoor Virtual 67

especificacaoe implementada na maioria dos smartphones disponıveis no mercado que pos-

suem GPS acoplado ou que utilizam outra forma para prover essa informacao, como por

exemplo, a triangulacao das antenas de celulares.

Figura 5.1: Diagrama de classes do provedor do contexto de localizacao.

Os nomes dos provedores que devem ser inicializados juntamente com a aplicacao sao

adicionados no arquivo descritor de aplicacoes no dispositivo movel, chamada de JAD (Java

Application Descriptor). Quando o MIDlet do cliente VadeMecume inicializado, sao instan-

ciadas todos os provedores de contexto contidos no descritor JAD do aplicativo atraves do

processo de reflexao[67], ou seja, uma instancia da classee criada a partir do nome desta.

No restante desta secao, serao descritas as aplicacoes criadas para os estudos de caso

citados no inıcio desta secao.

5.1 Outdoor Virtual

Nesta aplicacao, o usuario deseja que sejam exibidas propagandas multimıdia para possıveis

clientes de acordo com o contexto deles. Por exemplo, um possıvel cliente esta de ferias e

desocupado em Campina Grande durante o mes de junho e gosta de forro, entao os orga-

nizadores da festa de Sao Joao no municıpio criam uma regra para que quando este estado

5.1 Outdoor Virtual 68

contextual aconteca, seja exibido um vıdeo sobre o evento.

Para o funcionamento deste estudo de caso sao utilizados os seguintes provedores de

contexto:

• Provedor do contexto de localizacao geografica, quee obtida a partir de um sensor

fısico (GPS) no dispositivo movel do usuario;

• Provedor do status do usuario, que infere a partir da agenda de compromissos do

usuario este contexto, caracterizando um sensor logico; e

• Provedor das preferencias do usuario, quee obtido a partir de um sensor virtual que

capta informacoes do usuario no perfil descrito por ele.

Para o funcionamento deste estudo de caso, o usuario criara regras utilizando a ferra-

menta CARE, as quais indicarao que arquivos devem ser mostrados quando determinados

estados contextuais foram alcancados. A Figura5.2apresenta a interface do CARE com as

pre-condicoes necessarias para que a acao de mostrar um arquivo multimıdia seja executada.

Ja a Figura5.3 apresenta owidgetdo CARE para especificarareas geograficas nas regras

contextuais.

A regra contextual criada pelo usuario no CARE neste estudo de casoe descrita no

Codigo Fonte5.1.

Codigo Fonte 5.1: Regra criada no CARE para o Outdoor Virtual.

1 [ v i r t u a l O u t d o o r :

2 ( ? x vade : hasCon tex t vade : i d l e ) ,

3 ( ? x vade : hasCon tex t vade : v a c a t i o n ) ,

4 ( ? x vade : l i k e ” f o r ro ” ) ,

5 w i t h I n ( ” BBox( −7.224174 , −35.888900 , −7.22595 , −35.8848) ” , ?x )

6 −> showMul t imedia ( ? x , ” c a m p i n as a o j o a o . mp4 ” )

7 ]

Apos o usuario especificar as regras contextuais, ele podera valida-las no CARE Emu-

lator, simulando os estados contextuais necessarios para disparar uma regra e verificando

se a acao e executada no emulador do dispositivo como esperado. A Figura 5.4 mostra o

CARE Emulator validando a regra contextual criada, sendo o estado contextual simulado e

satisfazendo a regra, portanto, mostrando o arquivo multimıdia especificado na acao.

5.1

Ou

tdo

or

Virtu

al

69Figura 5.2: Ferramenta CARE com uma regra para o Outdoor Virtual.

5.1

Ou

tdo

or

Virtu

al

70

Figura 5.3: Ferramenta CARE com owidgetdo google maps para regra no Outdoor Virtual.

5.1

Ou

tdo

or

Virtu

al

71Figura 5.4: CARE Emulator validando a regra contextual criadapara o Outdoor Virtual.

5.2 Multimedia Service 72

A regra contextual passa a ser monitorada no servidor de contexto do VadeMecum apos

ser enviada. Quando o estado contextual do usuario satisfaz a regra contextual criada,e

disparada a acao de mostrar um arquivo multimıdia no dispositivo movel do usuario, como

apresentado na Figura5.5, aplicacao no dispositivo movel antes e depois da acao ser execu-

tada.

Figura 5.5: Aplicacao movel antes e depois da acao de mostra uma arquivo multimıdia.

5.2 Multimedia Service

O principal objetivo do Multimedia Servicee permitir que um usuario, a partir de um disposi-

tivo movel, armazene e recupere arquivos multimıdia com o contexto associado no servidor.

Por exemplo, o usuario captura uma fotografia a partir da camera do dispositivo movel dele

no Parque do Povo durante o evento de Sao Joao,as vinte e tres horas, enquanto a tempera-

tura era de vinte graus Celsius.

Al em de armazenar arquivos multimıdia, o usuario tambem pode fazer consultas a arqui-

vos existentes na base de dados a partir do dispositivo movel, podendo inclusive visualizar


os arquivos no proprio dispositivo e recuperar arquivos multimıdia que foram criados em um

contexto especıfico. Por exemplo, o usuario pode querer visualizar todas as fotografias que

Maria estava e foram capturadas pela camera de seu celular durante o evento “Maior Sao

Joao do Mundo” em Campina Grande.

O Multimedia Service fica responsavel pela parte de armazenamento dos arquivos mul-

timıdia num repositorio e o servidor de contexto do VadeMecum gerencia o contexto no qual

o arquivo foi capturado. Para ter o acessoas informacoes contextuais dos arquivos armaze-

nados na sua base de dados, o Multimedia Service realiza consultas em SPARQL, da mesma

forma que SPARQL Update para adicionar as informacoes contextuais no servidor de con-

texto do VadeMecum. Para que isto ocorra, a classeMultimediafoi adicionada no modelo

de contexto estendendoContextEntitypara indicar que possui um contexto associado.

Para o funcionamento deste estudo de caso sao utilizados os seguintes provedores de

contexto:

• Provedor da localizacao geografica citado anteriormente;

• Provedor de horario, que utiliza um sensor virtual para conhecer o horario no qual o

arquivo multimıdia foi capturado;

• Provedor de evento, que utiliza um sensor logico para inferir qual o evento no qual foi

o arquivo foi criado;

• Provedor de pessoas contidas numa fotografia, que utiliza umsensor virtual para captu-

rar as informacoes providas pelo usuario das pessoas que estavam presentes na fotogra-

fia. Para auxilar o usuario, pode ser utilizado um algoritmo de sugestoes de anotacoes

de pessoas[68], sendo elaborada uma lista com as pessoas mais provaveis de esta-

rem na fotografia a partir de um provedor de pessoas proximas, que utiliza um sensor

fısico (bluetooth) para identificar os dispositivos moveis que estao proximos e indicar

as pessoas que estao nas proximidades;

• Provedor de condicoes climaticas, que utiliza um sensor virtual para obter informacoes

climaticas da cidade em que o arquivo multimıdia foi capturado no momento que foi

criado; e


• Provedor de metadados, responsavel por capturar as informacoes dos metadados dos

arquivos multimıdia, como flash, modelo da camera, resolucao, fabricante da camera,

tamanho do arquivo, tempo do vıdeo/audio, entre outras.

Para a implementacao do Multimedia Service, foi utilizada a tecnologia Web Services

atraves da ferramenta Apache Axis 21, que utiliza o protocolo SOAP (Simple Object Access

Protocol)[69] para a comunicacao entre o dispositivo movel e o servico. Na aplicacao cliente

foi utilizado o JSR 172, que define de forma padrao como as aplicacoes moveis acessam Web

Services.

Inicialmente, na aplicacao e apresentada uma tela com as opcoes disponıveis nesta

aplicacao, como mostrado na Figura5.6, sendo as opcoes possıveis: criar um novo arquivo

multimıdia ou recuperar um arquivo ja armazenado no servidor. Caso a opcao selecionada

seja criar um novo arquivo multimıdia, entao sera apresentada a tela mostrada na Figura5.7,

na qual o usuario pode selecionar o tipo de arquivo multimıdia que deseja criar (fotografia,

vıdeo,audio ou texto).

Figura 5.6: Tela inicial do cliente movel.

1http://ws.apache.org/axis2/


Figura 5.7: Tela de escolha do tipo arquivo o usuario deseja criar.

Apos selecionar o tipo de arquivo a ser criado,e apresentado para o usuario a interface

para criacao do tipo selecionado. Na Figura5.8, apresenta-se a interface de captura de fo-

tografias na aplicacao, na qual o usuario visualiza as imagens provindas da camera do seu

dispositivo e informa quando a imagem deve ser capturada.

Logo apos a captura da nova imagem, o cliente movel confirma o interesse do usuario

em salva-la. Em seguida, serao mostradas as opcoes de onde armazena-la, podendo tambem

realizar esta tarefa com ou sem o contexto associado, como mostrado na Figura5.9.

Quando o arquivoe enviado para ser armazenado pelo Multimedia Service, essepodera

ser utilizado em regras contextuais criadas no CARE, inclusive utilizando as informacoes

contextuais associadas. Por exemplo, o usuario cria no CARE uma regra para que seja

mostrado um arquivo multimıdia quando o usuario estiver proximo da localizacao geografica

na qual o arquivo foi capturado. Desta forma, a regra modificada e apresentada no Codigo

Fonte5.2, onde foi criada uma variavel que representa todos os arquivos multimıdia.


Figura 5.8: Tela de criacao do arquivo de imagem.

Figura 5.9: Tela de escolha do tipo de armazenamento para o arquivo.


Codigo Fonte 5.2: Regra alterado do estudo de caso do Outdoor Virtual.

1 [ v i r t u a l O u t d o o r :

2 ( vade : Hugo vade : hasCon tex t vade : i d l e ) ,

3 ( vade : Hugo vade : hasCon tex t vade : happy ) ,

4 ( ? x r d f : t ype vade : Mul t imed ia ) ,

5 nea r ( vade : Hugo , ?x , 1000) ,

6 −> showMul t imedia ( vade : Hugo , ? x )

7 ]


Os estudos de caso apresentados neste capıtulo mostram a facilidade na construcao de

aplicacoes e servicos cientes de contexto utilizando o servidor decontexto do VadeMe-

cum, como tambem mostram situacoes de utilizacao da ferramenta CARE e CARE Emu-

lator para a especificacao e validacao de regras contextuais. Estes estudos de caso serviram

para verificar que a infraestrutura descrita nesta dissertacao destina-se a facilitar a criacao

de aplicacoes cientes de contexto e a personalizacao destas pelos usuarios finais atraves do

auxılio a especificacao de regras contextuais.

No proximo capıtulo, serao apresentadas as conclusoes desta dissertacao, como tambem

alguns trabalhos futuros que poderao ser realizados para a continuidade desta pesquisa.

Capıtulo 6

Conclusao

Neste capıtulo, sao apresentadas as conclusoes do trabalho exposto nesta dissertacao, como

tambem trabalhos futuros que sao recomendados a partir da experiencia obtida no desenvol-

vimento deste. O principal objetivo deste trabalho foi a criacao de uma infraestrutura para

facilitar o desenvolvimento de aplicacoes moveis cientes de contexto baseadas em regras e

prover auxılio ao usuario final na especificacao das regras nas quais o sistema se apoia. Esse

objetivo foi obtido com a construcao dos prototipos do servidor de contexto do VadeMecum

e das ferramentas CARE e CARE Emulator para prova de conceito.

O restante deste capıtulo esta dividido da seguinte maneira: na proxima secao, sao apre-

sentadas as contribuicoes obtidas; em seguida, sao apresentadas as proposicoes para traba-

lhos futuros.

6.1 Contribuicoes

O trabalho descrito nesta dissertacao teve como principal contribuicao a construcao de uma

infraestrutura para dar suporte ao desenvolvimento de aplicacoes cientes de contexto que

permitam a personalizacao pelos usuarios finais. Outras foram derivadas da contribuicao

principal, sendo divididas em dois topicos: aqueles os referentesa obtencao de um servidor

de contexto; e aqueles os relacionadosa construcao de uma ferramenta para auxiliar o usuario

final na especificacao de regras contextuais. No restante desta secao, serao discutidas as

contribuicoes relativas a ambos os topicos.

78

6.1 Contribuicoes 79

6.1.1 Servidor de Contexto do VadeMecum

Neste trabalho, foi apresentado o servidor de contexto do VadeMecum, quee responsavel

pelo armazenamento, inferencia, monitoramento e recuperacao de informacoes contextuais.

A seguir, serao detalhadas as contribuicoes alcancadas no desenvolvimento deste servidor.

Modelo de Contexto Baseado em Ontologias

Para o servidor de contexto do VadeMecum, foi desenvolvido um modelo de contexto base-

ado em ontologias. O modelo foi descrito utilizando uma linguagem para ontologias, cha-

mada de OWL, e permite que sejam adicionados novos contextos no sistema e que se abstraia

o processo de aquisicao das informacoes contextuais. Como foi relatado anteriormente, os

modelos de contextos baseados em ontologias sao os mais recomendados para a modelagem

de informacoes contextuais, assim comoe recomendada a utilizacao de vocabularios e on-

tologias consagrados na literatura e industria para aumentar interoperabilidade e facilitar o

mapeamento com outros modelos, sendo estas recomendacoes utilizadas na elaboracao do

modelo proposto neste trabalho, o que caracteriza a adocao e inspiracao de resultados obtidos

em outros trabalhos na literatura.

Arquitetura para o Servidor de Contexto

Com o intuito de elaborar uma infraestrutura para facilitar odesenvolvimento de aplicacoes

cientes de contexto, foi projetada uma arquitetura de umsoftwarepara este fim. A arquitetura

idealizada destaca-se pelo foco no modelo de contexto e na comunicacao com os interveni-

entes do sistema (servicos, aplicacoes moveis, provedores de contexto, entre outros).

Comunicacao Externa Utilizando Linguagens de Consulta e Atualizacao

Para realizar a comunicacao com os elementos interessados da arquitetura, sao utilizadas as

linguagens SPARQL – para consultasas informacoes contextuais – e SPARQL Update –

para a atualizacao das informacoes – atraves do protocolo HTTP (GET e POST).

6.1 Contribuicoes 80

Abstracao na Aquisicao de Contexto

Para a aquisicao das informacoes contextuais, sao utilizados os provedores de contexto, que

abstraem a complexidade envolvida no tratamento de dados brutos provindos de sensores

fısicos, logico e virtuais. A criacao de uma API facilitou a geracao de provedores de contexto

para o VadeMecum, tornando esta tarefa mais simples para os desenvolvedores.

6.1.2 Auxılio na Criacao de Regras Contextuais

Com a criacao de uma infraestrutura para auxiliar o usuario final na especificacao de re-

gras contextuais, a serem utilizadas na personalizacao de aplicacoes no VadeMecum, foram

incorporadas algumas contribuicoes-chaves a este trabalho, as quais serao detalhadas nesta

subsecao.

Criacao de Regras pelo Usuario Final

A ferramenta CARE auxilia o usuario final na criacao de regras contextuais para aplicacoes

cientes de contexto baseadas em regras, retirando a responsabilidade desta tarefa dos desen-

volvedores da aplicacao, o que pode gerar a popularizacao deste tipo de aplicacao.

Adaptacao ao Modelo de Contexto

Devido a natureza dinamica das aplicacoes cientes de contexto, o modelo de contexto

deve ser facilmente estendido no sistema. Consequentemente, a caracterıstica adaptativa

do CARE ao modelo de contexto torna mais facil a manutencao no sistema a alteracoes

ocorridas no modelo.

Validacao de Regras Contextuais

Como a tarefa de especificacao de regras contextuaise difıcil, a existencia de uma ferramenta

que ajude o usuario final a validar suas regras antes de envia-las para serem utilizadas nas

aplicacoes cientes de contextoe essencial. A ferramenta CARE Emulator permite que esta

validacao ocorra.

6.2 Trabalhos Futuros 81

6.2 Trabalhos Futuros

Para continuidade das pesquisas iniciadas neste trabalho,sao enumeradas proposicoes de

alguns trabalhos futuros:

• Desempenho e escalabilidade: a utilizacao de uma maquina de inferencia anexado a

um modelo de contexto baseado em ontologias tornou o sistemapouco escalavel e com

problemas de desempenho. Consequentemente, sao necessarios estudos adicionais

para resolver os problemas supracitados;

• Qualidade de contexto: como tecnologias de sensores nao sao totalmente precisas, as-

pectos como corretude, precisao e atualizacao, devem ser considerados pelos sistemas

que desejam facilitar o desenvolvimento de aplicacoes cientes de contexto, para que

nao sejam tomadas decisoes erradas baseadas em informacoes imprecisas;

• Controle de Acesso e Privacidade: para que exista um monitoramento do contexto de

um usuario por outro,e necessario um sistema de controle de acesso e privacidade, de

forma que as aplicacoes cientes de contexto nao se tornem ferramentas de espionagem

e invasao de privacidade;

• Historico de contexto e regras envolvendo aspectos temporais: as informacoes con-

textuais antigas sao importantes para algumas aplicacoes cientes de contexto, com

isso, devem ser armazenadas. Alem disso, a criacao de regras que envolvam estas

informacoes deve ser possıvel;

• Aprendizagem e predicao de situacoes contextuais: a partir do historico de

informacoes contextuais, pode existir uma predicao de situacoes futuras, assim exis-

tindo a possibilidade de tomada de decisoes baseadas em possıveis acontecimentos

futuros;

• Descoberta e composicao de servicos: os servicos devem ser descobertos automati-

camente atraves de descricoes semanticas, que possam ser entendidas por maquinas

e humanos, dessa forma, podendo haver um casamento semantico entre o servico de-

sejado pelo usuario com um publicado. Alem disso, muitas vezes, um servico nao

fornece por completo todos os requisitos desejados pelo usuario, com isso, deve haver

6.2 Trabalhos Futuros 82

uma forma de fazer composicao de servicos, para que os requisitos sejam atendidos.

Por exemplo, um usuario deseja saber a rota mais rapida para chegar a um determi-

nado ponto, para isso, seleciona um servico de roteamento,mas este servico nao possui

informacoes de trafego, dessa forma,e necessaria a composicao com um servico que

forneca estas informacoes;

• Testes de usabilidade: para certificar-se de que o VadeMecumfacilita a personalizacao

de aplicacoes cientes de contexto pelo usuario final, e necessario que seja realizado

alguns testes de usabilidade; e

• Acessibilidade: com a infraestrutura proposta nesta pesquisa possui um foco no

usuario final, e necessario um estudo para verificar como aumentar a acessibilidade

do sistema para que usuarios com limitacoes fısicas – principalmente visual – possam

utilizar o sistema para personalizacao de aplicacoes cientes de contexto.

Referencias Bibliograficas

[1] Dourish, P.Personal Ubiquitous Computing8(1), 19–30 (2004).

[2] Dey, A. K. Personal Ubiquitous Computing5(1), 4–7 (2001).

[3] Weiser, M.Scientific American265(3), 94–104 September (1991).

[4] Schiller, J., Voisard, A.Location Based Services. Morgan Kaufmann Publishers Inc.,

San Francisco, CA, USA, (2004).

[5] Satoh, I.International Journal on Digital Libraries6(3), 280–291 (2006).

[6] Dey, A. K., Abowd, G. D., Salber, D.Human-Computer Interaction Journal16(2),

97–166 (2001).

[7] Gu, T., Pung, H. K., Zhang, D. Q.Journal of Network and Computer Applications

28(1), 1–18 (2005).

[8] de Almeida, D. R., de Souza Baptista, C., da Silva, E. R., Campelo, C.E. C., de Fi-

gueiredo, H. F., Lacerda, Y. A. InAINA ’06: Proceedings of the 20th International Con-

ference on Advanced Information Networking and Applications- Volume 1 (AINA’06),

205–210 (IEEE Computer Society, Washington, DC, USA, 2006).

[9] Costa, P. D. Master’s thesis, University of Twente, Enschede, The Netherlands, (2003).

[10] Weißenberg, N., Gartmann, R., Voisard, A.Geoinformatica10(1), 55–90 (2006).

[11] Dey, A. K., Sohn, T., Streng, S., Kodama, J. InPervasive,Fishkin, K. P., Schiele, B.,

Nixon, P., Quigley, A. J., editors, volume 3968 ofLecture Notes in Computer Science,

254–271. Springer, (2006).

83

BIBLIOGRAFIA 84

[12] Hull, R., Clayton, B., Melamed, T. InUbicomp,Davies, N., Mynatt, E. D., Siio,

I., editors, volume 3205 ofLecture Notes in Computer Science, 125–142. Springer,

(2004).

[13] Jensen, C. S., Vicente, C. R., Wind, R.IEEE Computer41(12), 116–118 (2008).

[14] Lyytinen, K. Yoo, Y. Communications of the ACM45(12), 62–65 (2002).

[15] Jensen, C. S. In11th International Conference Database Systems for Advanced Appli-

cations,Lee, M.-L., Tan, K.-L., Wuwongse, V., editors, volume 3882 of Lecture Notes

in Computer Science, 6–19. Springer, (2006).

[16] Schmidt, A. Ubiquitous Computing - Computing in Context. PhD thesis, Computing

Department, Lancaster University, Lancaster, England, UK, November (2002).

[17] Baldauf, M., Dustdar, S., Rosenberg, F.International Journal of Ad Hoc and Ubiqui-

tous Computing2(4), 263–277 (2007).

[18] Schilit, B. Theimer, M.IEEE Network8(5), 22–32 Sep/Oct (1994).

[19] Oh, Y., Schmidt, A., Woo, W. InMUE ’07: Proceedings of the 2007 International

Conference on Multimedia and Ubiquitous Engineering, 1158–1163 (IEEE Computer

Society, Washington, DC, USA, 2007).

[20] Gruber, T. Encyclopedia of Database Systems, chapter Ontology. Springer (2008).

To appear. In: http://tomgruber.org/writing/ontology-definition-2007.htm, accessed in

June 2009.

[21] Berners-Lee, T., Hendler, J. A., Lassila, O.Scientific American284(5), 34–43 May

(2001).

[22] Brickley, D., Guha, R. V. W3C recommendation, W3C, February (2004). In:

http://www.w3.org/TR/rdf-schema, accessed in January 2009.

[23] McGuinness, D. L., van Harmelen, F. W3C recommendation, W3C, February (2004).

In: http://www.w3.org/TR/owl-features, accessed in January 2009.

BIBLIOGRAFIA 85

[24] Carroll, J. J., Klyne, G. W3C recommendation, W3C, February (2004). In:

http://www.w3.org/TR/rdf-concepts, accessed in January 2009.

[25] Strang, T., Linnhoff-Popien, C. InFirst International Workshop on Advanced Con-

text Modelling, Reasoning and Management, Sixth International Conference on Ubi-

Comp2004, (2004).

[26] Schilit, B., Adams, N., Want, R. InWMCSA ’94: Proceedings of the 1994 First

Workshop on Mobile Computing Systems and Applications, 85–90 (IEEE Computer


[27] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., Yergeau, F. W3C recom-

mendation, W3C, November (2008). In: http://www.w3.org/TR/xml/, accessed in May

2009.

[28] Buchholz, S., Hamann, T., Hubsch, G. InPERCOMW ’04: Proceedings of the Second

IEEE Annual Conference on Pervasive Computing and Communications Workshops,

43 (IEEE Computer Society, Washington, DC, USA, 2004).

[29] Klyne, G., Reynolds, F., Woodrow, C., Ohto, H., Hjelm, J., Butler, M. H., Tran, L.

W3C recommendation, W3C, January (2004). In: http://www.w3.org/TR/CCPP-struct-

vocab, accessed in May 2009.

[30] Simons, C., Wirtz, G.Journal of Visual Languages and Computing18(4), 420–439

(2007).

[31] Henricksen, K., Indulska, J.Pervasive and Mobile Computing2(1), 37–64 (2006).

[32] Halpin, T.Encyclopedia of Database Systems, chapter Object-Role Modeling. Springer

(2009). To appear. In: http://www.orm.net/pdf/EncDBS.pdf, accessed in June 2009.

[33] Cheverst, K., Mitchell, K., Davies, N.Communications of the ACM45(5), 47–51

(2002).

[34] Fahy, P., Clarke, S. InProceedings of the Second International Conference on Mobile

Systems, Applications, and Services (MobiSys 2004). Workshop on Context Awareness,

304–308. USENIX, June (2004).

BIBLIOGRAFIA 86

[35] Niu, W., Shi, Z., Chang, L. In5th IFIP International Conference on Intelligent Infor-

mation Processing, volume 288 ofIFIP Advances in Information and Communication

Technology, 7–16. Springer, (2008).

[36] de Almeida, D. R., de Souza Baptista, C., de Andrade, F. G. In17th International

Workshop on Database and Expert Systems Applications, 349–353 (IEEE Computer


[37] Ranganathan, A., Campbell, R. H.Personal Ubiquitous Computing7(6), 353–364

(2003).

[38] Gartmann, R., Holtkamp, B., Weissenberg, N. InSCC ’05: Proceedings of the 2005

IEEE International Conference on Services Computing, 121–128 (IEEE Computer So-

ciety, Washington, DC, USA, 2005).

[39] Uszkoreit, H., Xu, F., Liu, W., Steffen, J., Aslan, I., Liu, J., Muller, C., Holtkamp, B.,

Wojciechowski, M. InProceedings of The 12th International Conference on Human-

Computer Interaction Applications and Services (HCI (4)), volume 4553 ofLecture

Notes in Computer Science, 1047–1056. Springer, July (2007).

[40] de Farias, C. R. G., Leite, M. M., Calvi, C. Z., Pessoa, R. M., Filho,J. G. P. In

SAC ’07: Proceedings of the 2007 ACM Symposium on Applied Computing, 947–952

(ACM, New York, NY, USA, 2007).

[41] Goncalves, B., Filho, J. G. P., Guizzardi, G. InSAC ’08: Proceedings of the 2008 ACM

Symposium on Applied Computing, 1946–1952 (ACM, New York, NY, USA, 2008).

[42] Stenton, S. P., Hull, R., Goddi, P. M., Reid, J. E., Clayton, B. J. C., Melamed, T. J.,

Wee, S.IEEE MultiMedia14(3), 98–105 (2007).

[43] Jensen, C. S. InDatenbanksysteme in Business, Technologie und Web, volume 103 of

Lecture Notes in Informatics, 2–16. Gesellschaft fur Informatik e.V., (2007).

[44] Pane, J. F., Myers, B. A. InVL ’00: Proceedings of the 2000 IEEE International

Symposium on Visual Languages (VL’00), 157 (IEEE Computer Society, Washington,

DC, USA, 2000).

BIBLIOGRAFIA 87

[45] de Souza Baptista, C., Leite Jr., F. L., da Silva, E. R., de Paiva,A. C. In Proceedings of

The Third International Conference on Electronic Government (EGOV 2004), volume

3183 ofLecture Notes in Computer Science, 418–421. Springer, August (2004).

[46] de la Beaujardiere, J. Technical report, Open Geospatial Consortium.

Reference number: OGC 06-042. Version: 1.3.0, March (2006).In:

http://www.opengeospatial.org/standards/wms, accessed in January 2009.

[47] Vretanos, P. A. Technical report, Open Geospatial Consortium. Re-

ference number: OGC 04-094. Version: 1.1.0, May (2005). In:

http://www.opengeospatial.org/standards/wfs, accessed in January 2009.

[48] Costa, P. D., Pires, L. F., Sinderen, M. V., Broens, T. InProceedings of the Second

Workshop on Context Awareness for Proactive Systems (CAPS 2006), 153–166 (Kassel

University Press, Kassel, Germany, 2006).

[49] Mostefaoui, G. K., Pasquier-Rocha, J., Brezillon, P. InICPS ’04: Proceedings of the

The IEEE/ACS International Conference on Pervasive Services, 39–48 (IEEE Compu-

ter Society, Washington, DC, USA, 2004).

[50] Baker, T. Technical report, Corporation for National ResearchInitiatives, (2000).

[51] Brickley, D., Miller, L. Creative Commons Attribution License, October (2007). In:

http://xmlns.com/foaf/spec/20071002.html, accessed inMay 2009.

[52] Gamma, E., Helm, R., Johnson, R., Vlissides, J.Design patterns: elements of reusable

object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,

USA, (1995).

[53] Gennari, J. H., Musen, M. A., Fergerson, R. W., Grosso, W. E., Crubezy, M., Eriksson,

H., Noy, N. F., Tu, S. W. International Journal of Human-Computer Studies58(1),

89–123 (2003).

[54] Knublauch, H., Fergerson, R. W., Noy, N. F., Musen, M. A. InInternational Semantic

Web Conference,McIlraith, S. A., Plexousakis, D., van Harmelen, F., editors, volume

3298 ofLecture Notes in Computer Science, 229–243. Springer, (2004).

BIBLIOGRAFIA 88

[55] McBride, B. IEEE Internet Computing6(6), 55–59 (2002).

[56] Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., Katz, Y.Web Semantics: Science,

Services and Agents on the World Wide Web5(2), 51–53 (2007).

[57] Bechhofer, S. DIG Working Group, September (2006). In:

http://dig.cs.manchester.ac.uk, accessed in May 2009.

[58] Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., Dean, M. W3C

Member Submission, May (2004). In: http://www.w3.org/Submission/SWRL/, acces-

sed in January 2009.

[59] Motik, B., Sattler, U., Studer., R. InProc. of the 3rd International Semantic Web

Conference (ISWC 2004), volume 3298 ofLecture Notes in Computer Science, 549–

563. Springer, November (2004).

[60] Worboys, M., Duckham, M.GIS: A Computing Perspective, 2nd Edition. CRC Press,

Inc., Boca Raton, FL, USA, (2004).

[61] Prud’hommeaux, E., Seaborne, A. W3C recommendation, W3C, January (2008). In:

http://www.w3.org/TR/rdf-sparql-query, accessed in January 2009.

[62] Beckett, D., Broekstra, J. W3C recommendation, W3C, January (2008). In:

http://www.w3.org/TR/rdf-sparql-XMLres, accessed in January 2009.

[63] Seaborne, A., Manjunath, G., Bizer, C., Breslin, J., Das, S., Davis, I., Harris, S., Idehen,

K., Corby, O., Kjernsmo, K., Nowack, B. W3C Member Submission, July (2008). In:

http://www.w3.org/Submission/SPARQL-Update, accessed in March 2009.

[64] Dey, A. K., Hamid, R., Beckmann, C., Li, I., Hsu, D. InProceedings of the 2004 Con-

ference on Human Factors in Computing Systems (CHI 2004), 33–40. ACM, (2004).

[65] Bischoff, U., Sundrainoorthy, V., Kortuem, G. In3rd IET International Conference on

Intelligent Environments, 544–551 (IEEE Computer Society, Washington, DC, USA,

2007).

BIBLIOGRAFIA 89

[66] Beer, T., Rasinger, J., Hopken, W., Fuchs, M., Werthner, H. InProceedings of The

International Symposium on Advances in Rule Interchange and Applications (RuleML

2007), volume 4824 ofLecture Notes in Computer Science, 199–206. Springer, October

(2007).

[67] Sobel, J. M., Friedman, D. P. InProceedings of The Reflection’96 Conference, 1–19.

PARC, April (1996).

[68] Lacerda, Y. A., de Figueiredo, H. F., Baptista, C. S., de Paiva, A. C. InXIV Simposio

Brasileiro de Sistemas Multimıdia e Web (WebMedia2008)(SBC, Vila Velha, Brasil,

2008).

[69] Lafon, Y., Mitra, N. W3C recommendation, W3C, April (2007). In:

http://www.w3.org/TR/2007/REC-soap12-part0-20070427, accessed in June 2009.

Apendice A

Modelo de Contexto do VadeMecum

Codigo Fonte A.1: Modelo de contexto do VadeMecum descrito emOWL.

1 <?xml ve rs i on="1.0" ?>

2 <rdf :RDF

3 x m l n s : r d f ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

4 xmlns="http://www.lsi.dsc.ufcg.edu.br/vademecum.owl#"

5 xmlns :owl="http://www.w3.org/2002/07/owl#"

6 xmlns :xsd ="http://www.w3.org/2001/XMLSchema#"

7 x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#" >

8 <o w l : C l a s s r d f : I D ="Environment_context" >

9 < r d f s : s u b C l a s s O f>

10 <o w l : C l a s s r d f : I D ="Context" />

11 < / r d f s : s u b C l a s s O f>

12 < / o w l : C l a s s>

13 <o w l : C l a s s r d f : I D ="Video" >


15 <o w l : C l a s s r d f : I D ="Multimedia" />

16 < / r d f s : s u b C l a s s O f>

17 < / o w l : C l a s s>

18 <o w l : C l a s s r d f : I D ="User_heart_beat" >


20 <o w l : C l a s s r d f : I D ="Physiologic" />

21 < / r d f s : s u b C l a s s O f>

22 < / o w l : C l a s s>

23 <o w l : C l a s s r d f : I D ="Traffic_information" >


90

91

25 <o w l : C l a s s r d f : I D ="Social_environment" />

26 < / r d f s : s u b C l a s s O f>

27 < / o w l : C l a s s>

28 <o w l : C l a s s r d f : I D ="Luminosity_level" >


30 <o w l : C l a s s r d f : I D ="Physical_environment" />

31 < / r d f s : s u b C l a s s O f>

32 < / o w l : C l a s s>

33 <o w l : C l a s s r d f : I D ="Professional" >


35 <o w l : C l a s s r d f : I D ="Profile" />

36 < / r d f s : s u b C l a s s O f>

37 < / o w l : C l a s s>

38 <o w l : C l a s s r d f : I D ="Environment_location" >


40 <o w l : C l a s s r d f : a b o u t ="#Physical_environment" />

41 < / r d f s : s u b C l a s s O f>

42 < / o w l : C l a s s>

43 <o w l : C l a s s r d f : I D ="Shop_information" >


45 <o w l : C l a s s r d f : a b o u t ="#Social_environment" />

46 < / r d f s : s u b C l a s s O f>

47 < / o w l : C l a s s>

48 <o w l : C l a s s r d f : I D ="Status" >


50 <o w l : C l a s s r d f : I D ="User_context" />

51 < / r d f s : s u b C l a s s O f>

52 < / o w l : C l a s s>

53 <o w l : C l a s s r d f : I D ="Network_bandwidth" >


55 <o w l : C l a s s r d f : I D ="Computational_environment" />

56 < / r d f s : s u b C l a s s O f>

57 < / o w l : C l a s s>

58 <o w l : C l a s s r d f : a b o u t ="#Physical_environment" >

59 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Environment_context" />

60 < / o w l : C l a s s>

61 <o w l : C l a s s>

92

62 <owl :un ionOf r d f : p a r s e T y p e ="Collection" >

63 <o w l : C l a s s r d f : a b o u t ="#User_heart_beat" />

64 <o w l : C l a s s r d f : I D ="User_temperature" />

65 < / ow l :un ionOf>

66 < / o w l : C l a s s>

67 <o w l : C l a s s r d f : I D ="User" />

68 <o w l : C l a s s r d f : I D ="Users_within" >


70 <o w l : C l a s s r d f : I D ="Multimedia_context" />

71 < / r d f s : s u b C l a s s O f>

72 < / o w l : C l a s s>

73 <o w l : C l a s s r d f : a b o u t ="#User_temperature" >


75 <o w l : C l a s s r d f : a b o u t ="#Physiologic" />

76 < / r d f s : s u b C l a s s O f>

77 < / o w l : C l a s s>

78 <o w l : C l a s s r d f : I D ="Near_devices" >


80 <o w l : C l a s s r d f : a b o u t ="#Computational_environment" />

81 < / r d f s : s u b C l a s s O f>

82 < / o w l : C l a s s>

83 <o w l : C l a s s r d f : I D ="Image" >

84 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Multimedia" />

85 < / o w l : C l a s s>

86 <o w l : C l a s s r d f : a b o u t ="#Profile" >


88 <o w l : C l a s s r d f : a b o u t ="#User_context" />

89 < / r d f s : s u b C l a s s O f>

90 < / o w l : C l a s s>

91 <o w l : C l a s s r d f : I D ="Network_capacity" >


93 <o w l : C l a s s r d f : a b o u t ="#Computational_environment" />

94 < / r d f s : s u b C l a s s O f>

95 < / o w l : C l a s s>

96 <o w l : C l a s s r d f : a b o u t ="#Physiologic" >


98 <o w l : C l a s s r d f : a b o u t ="#User_context" />

93

99 < / r d f s : s u b C l a s s O f>

100 < / o w l : C l a s s>

101 <o w l : C l a s s r d f : I D ="Environment_temperature" >

102 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Physical_environment" />

103 < / o w l : C l a s s>

104 <o w l : C l a s s r d f : a b o u t ="#User_context" >

105 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Context" />

106 < / o w l : C l a s s>

107 <o w l : C l a s s r d f : I D ="Context_listener" />

108 <o w l : C l a s s r d f : I D ="Social" >

109 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Profile" />

110 < / o w l : C l a s s>

111 <o w l : C l a s s r d f : I D ="Schedule" >

112 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#User_context" />

113 < / o w l : C l a s s>

114 <o w l : C l a s s r d f : a b o u t ="#Computational_environment" >


116 < / o w l : C l a s s>

117 <o w l : C l a s s r d f : I D ="Emotion" >

118 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#User_context" />

119 < / o w l : C l a s s>

120 <o w l : C l a s s r d f : I D ="Near_contact" >

121 < r d f s : s u b C l a s s O f>

122 <o w l : C l a s s r d f : a b o u t ="#Social_environment" />

123 < / r d f s : s u b C l a s s O f>

124 < / o w l : C l a s s>

125 <o w l : C l a s s r d f : I D ="Text" >


127 < / o w l : C l a s s>

128 <o w l : C l a s s>


130 <o w l : C l a s s r d f : a b o u t ="#User_heart_beat" />

131 <o w l : C l a s s r d f : a b o u t ="#User_temperature" />


133 < / o w l : C l a s s>

134 <o w l : C l a s s r d f : a b o u t ="#Social_environment" >


94

136 < / o w l : C l a s s>

137 <o w l : C l a s s r d f : I D ="Noise_level" >


139 < / o w l : C l a s s>

140 <o w l : C l a s s r d f : a b o u t ="#Multimedia_context" >

141 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Context" />

142 < / o w l : C l a s s>

143 <o w l : C l a s s r d f : I D ="Interest" />

144 <o w l : C l a s s r d f : I D ="Personal" >

145 < r d f s : s u b C l a s s O f r d f : r e s o u r c e ="#Profile" />

146 < / o w l : C l a s s>

147 <o w l : C l a s s r d f : I D ="Sound" >


149 < / o w l : C l a s s>

150 <o w l : C l a s s r d f : I D ="Time" >


152 < / o w l : C l a s s>

153 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_image" >

154 < r d f s : s u b P r o p e r t y O f>

155 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_multimedia" />

156 < / r d f s : s u b P r o p e r t y O f>

157 <o w l : i n v e r s e O f>

158 <o w l : O b j e c t P r o p e r t y r d f : I D ="image_owner" />

159 < / o w l : i n v e r s e O f>

160 < r d f s : r a n g e r d f : r e s o u r c e ="#Image" />

161 < / o w l : O b j e c t P r o p e r t y>

162 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_video" >


164 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#has_multimedia" />


166 < r d f s : r a n g e r d f : r e s o u r c e ="#Video" />

167 <o w l : i n v e r s e O f>

168 <o w l : O b j e c t P r o p e r t y r d f : I D ="video_owner" />

169 < / o w l : i n v e r s e O f>


171 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#video_owner" >

172 <o w l : i n v e r s e O f r d f : r e s o u r c e ="#has_video" />

95


174 <o w l : O b j e c t P r o p e r t y r d f : I D ="multimedia_owner" />


176 <r d f s : d o m a i n r d f : r e s o u r c e ="#Video" />


178 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#has_contact" >

179 <r d f s : d o m a i n r d f : r e s o u r c e ="#User" />

180 < r d f s : r a n g e r d f : r e s o u r c e ="#User" />


182 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#image_owner" >

183 <o w l : i n v e r s e O f r d f : r e s o u r c e ="#has_image" />

184 <r d f s : d o m a i n r d f : r e s o u r c e ="#Image" />


186 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#multimedia_owner" />



189 <o w l : O b j e c t P r o p e r t y r d f : I D ="near" >




193 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_audio" >




197 < r d f s : r a n g e r d f : r e s o u r c e ="#Sound" />

198 <o w l : i n v e r s e O f>

199 <o w l : O b j e c t P r o p e r t y r d f : I D ="audio_owner" />

200 < / o w l : i n v e r s e O f>


202 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#audio_owner" >


204 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#multimedia_owner" />


206 <o w l : i n v e r s e O f r d f : r e s o u r c e ="#has_audio" />

207 <r d f s : d o m a i n r d f : r e s o u r c e ="#Sound" />


209 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_user" >

96

210 <r d f s : d o m a i n r d f : r e s o u r c e ="#Users_within" />



213 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_context" >

214 < r d f s : r a n g e r d f : r e s o u r c e ="#Context" />

215 <r d f s : d o m a i n>

216 <o w l : C l a s s>


218 <o w l : C l a s s r d f : a b o u t ="#User" />

219 <o w l : C l a s s r d f : a b o u t ="#Multimedia" />


221 < / o w l : C l a s s>

222 < / r d f s : d o m a i n>


224 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_text" >




228 < r d f s : r a n g e r d f : r e s o u r c e ="#Text" />

229 <o w l : i n v e r s e O f>

230 <o w l : O b j e c t P r o p e r t y r d f : I D ="text_owner" />

231 < / o w l : i n v e r s e O f>


233 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#multimedia_owner" >

234 <r d f s : d o m a i n r d f : r e s o u r c e ="#Multimedia" />


236 <o w l : i n v e r s e O f>


238 < / o w l : i n v e r s e O f>


240 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#has_multimedia" >

241 <o w l : i n v e r s e O f r d f : r e s o u r c e ="#multimedia_owner" />

242 < r d f s : r a n g e r d f : r e s o u r c e ="#Multimedia" />



245 <o w l : O b j e c t P r o p e r t y r d f : a b o u t ="#text_owner" >

246 <o w l : i n v e r s e O f r d f : r e s o u r c e ="#has_text" />

97

247 <r d f s : d o m a i n r d f : r e s o u r c e ="#Text" />

248 < r d f s : s u b P r o p e r t y O f r d f : r e s o u r c e ="#multimedia_owner" />


250 <o w l : O b j e c t P r o p e r t y r d f : I D ="has_interest" >

251 <r d f s : d o m a i n r d f : r e s o u r c e ="#Personal" />

252 < r d f s : r a n g e r d f : r e s o u r c e ="#Interest" />


254 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="x" >

255 < r d f s : r a n g e r d f : r e s o u r c e ="http://www.w3.org/2001/XMLSchema#float" />

256 <r d f s : d o m a i n r d f : r e s o u r c e ="#Environment_location" />

257 < / o w l : D a t a t y p e P r o p e r t y>

258 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="y" >

259 < r d f s : r a n g e r d f : r e s o u r c e ="http://www.w3.org/2001/XMLSchema#float" />

260 <r d f s : d o m a i n r d f : r e s o u r c e ="#Environment_location" />


262 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="idRule" >

263 <r d f s : d o m a i n r d f : r e s o u r c e ="#Context_listener" />

264 < r d f s : r a n g e r d f : r e s o u r c e ="http://www.w3.org/2001/XMLSchema#string" />


266 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="name" >

267 <r d f s : d o m a i n>

268 <o w l : C l a s s>


270 <o w l : C l a s s r d f : a b o u t ="#User" />

271 <o w l : C l a s s r d f : a b o u t ="#Restriction" />


273 < / o w l : C l a s s>

274 < / r d f s : d o m a i n>



277 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="ano" >

278 < r d f s : r a n g e r d f : r e s o u r c e ="http://www.w3.org/2001/XMLSchema#int" />


280 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="user_within_value" />

281 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="nome" >

282 <r d f s : d o m a i n r d f : r e s o u r c e ="#Product" />


98


285 <o w l : D a t a t y p e P r o p e r t y r d f : I D ="password" >




289 <owl :DataRange>

290 <owl :oneOf r d f : p a r s e T y p e ="Resource" >

291 < r d f : r e s t r d f : p a r s e T y p e ="Resource" >

292 < r d f : f i r s t r d f : d a t a t y p e ="http://www.w3.org/2001/XMLSchema#string"

293 >d i n n e r< / r d f : f i r s t>



296 < r d f : f i r s t r d f : d a t a t y p e ="http://www.w3.org/2001/XMLSchema#

string"

297 > i l l < / r d f : f i r s t>



string"

300 > l unch< / r d f : f i r s t>



303 < r d f : f i r s t r d f : d a t a t y p e ="http://www.w3.org/2001/

XMLSchema#string"

304 >s t a t u s n o t h i n g< / r d f : f i r s t>


306 < r d f : f i r s t r d f : d a t a t y p e ="http://www.w3.org/2001/

XMLSchema#string"

307 >work ing< / r d f : f i r s t>

308 < r d f : r e s t r d f : r e s o u r c e ="http://www.w3.org/1999/02/22-

rdf-syntax-ns#nil" />

309 < / r d f : r e s t>

310 < / r d f : r e s t>

311 < r d f : f i r s t r d f : d a t a t y p e ="http://www.w3.org/2001/XMLSchema

#string"

312 >s l e e p i n g< / r d f : f i r s t>

313 < / r d f : r e s t>

314 < / r d f : r e s t>

99

315 < / r d f : r e s t>


string"

317 > i d l e< / r d f : f i r s t>

318 < / r d f : r e s t>

319 < / r d f : r e s t>


321 >b r e a k f a s t< / r d f : f i r s t>

322 < / owl :oneOf>

323 < / owl :DataRange>






string"

329 >under< / r d f : f i r s t>

330 < r d f : r e s t r d f : r e s o u r c e ="http://www.w3.org/1999/02/22-rdf-syntax

-ns#nil" />

331 < / r d f : r e s t>


333 >upper< / r d f : f i r s t>

334 < / r d f : r e s t>


336 >e q u a l s< / r d f : f i r s t>

337 < / owl :oneOf>





342 > i d l e< / r d f : f i r s t>




string"

346 >s l e e p i n g< / r d f : f i r s t>

100

347 < r d f : r e s t r d f : r e s o u r c e ="http://www.w3.org/1999/02/22-rdf-syntax

-ns#nil" />

348 < / r d f : r e s t>


350 >work ing< / r d f : f i r s t>

351 < / r d f : r e s t>

352 < / owl :oneOf>


354 < / rdf :RDF>

Apendice B

Configuracao do Joseki

Codigo Fonte B.1: Configuracao do Joseki no VadeMecum.

1 @pref ix r d f s : <h t t p : / /www. w3 . org / 2 0 0 0 / 0 1 / rd f−schema#> .

2 @pref ix r d f : <h t t p : / /www. w3 . org /1999/02/22− rd f−syn tax−ns #> .

3 @pref ix x s d : <h t t p : / /www. w3 . org / 2 0 0 1 / XMLSchema#> .

4 @pref ix module : <h t t p : / / j o s e k i . o rg / 2 0 0 3 / 0 6 / module#> .

5 @pref ix j o s e k i : <h t t p : / / j o s e k i . o rg / 2 0 0 5 / 0 6 / c o n f i g u r a t i o n #> .

6 @pref ix j a : <h t t p : / / j e n a . hp l . hp . com / 2 0 0 5 / 1 1 / Assembler #> .

7

8 <> r d f s : l a b e l "VadeMecum Configuration File" .

9

10 <# s e r v e r>

11 r d f : t y p e j o s e k i : S e r v e r ;

12 j o s e k i : s e r v e r D e b u g"true" ;

13 j o s e k i : i n i t i a l i z a t i o n

14 [

15 modu le : imp lemen ta t i on

16 [

17 module :c lassName < j a v a : o r g . j o s e k i . u t i l .

S e r v i c e I n i t S i m p l e> ;

18 r d f s : l a b e l "VadeMecum

initializer" ;

19 ]

20 ] ;

21 .

22

101

102

23 <# s e r v i c e U d p a t e>

24 r d f : t y p e j o s e k i : S e r v i c e ;

25 r d f s : l a b e l "SPARQL/Update" ;

26 j o s e k i : s e r v i c e R e f "sparql_update" ;

27 j o s e k i : d a t a s e t <# vademecumIn fe renceBDatase t> ;

28 j o s e k i : p r o c e s s o r josek i :ProcessorSPARQLUpdate

29 .

30

31 <# s e r v i c e R e a d>

32 r d f : t y p e j o s e k i : S e r v i c e ;

33 r d f s : l a b e l "SPARQL" ;

34 j o s e k i : s e r v i c e R e f "sparql" ;

35 j o s e k i : d a t a s e t <# vademecumIn fe renceBDatase t> ;

36 j o s e k i : p r o c e s s o r josek i :ProcessorSPARQLFixedDS ;

37 .

38

39 <# vademecumDataset2> r d f : t y p e ja :RDFDatase t ;

40 r d f s : l a b e l "VadeMecum DB Dataset" ;

41 j a : d e f a u l t G r a p h <#vademecumDBModel> ;

42 .

43

44 <# vademecumIn fe renceBDatase t> r d f : t y p e ja :RDFDatase t ;

45 r d f s : l a b e l "VadeMecum SDB Inference Dataset"

;

46 j a : d e f a u l t G r a p h <#vademecumInfModel> ;

47 .

48

49 <#vademecumInfModel> r d f : t y p e j a : I n f M o d e l ;

50 j a : bas eM ode l <#vademecumDBModel> ;

51 j a : r e a s o n e r

52 [

53 j a : r easone rURL <h t t p : / / j e n a . hp l . hp . com / 2 0 0 3 /

Gener i cRu leReasoner> ;

54 j a : r u l e s F r o m < f i l e : / / / C: / Arqu ivos%20de%20

programas /CARE/ workspace / PlataformaVadeMecum2 /

WebContent / Ru les / i n f e r e n c er u l e s . r u l e s> ;

55 ] ;

103

56 .

57

58 <#vademecumDBModel> r d f : t y p e ja:RDBModel ;

59 j a : c o n n e c t i o n

60 [

61 j a : dbType "PostgreSQL" ;

62 ja:dbURL "jdbc:postgresql://localhost:5432/

vademecum" ;

63 j a : d b U s e r "vademecum" ;

64 j a : d b P a s s w o r d "vademecum" ;

65 j a : d b C l a s s "org.postgresql.Driver" ;

66 ] ;

67 ja :modelName "http://lsi.dsc.ufcg.edu.br/vademecum.owl"

68 .

69

70 j osek i :ProcessorSPARQLFixedDS

71 r d f s : l a b e l "SPARQL processor

for fixed datasets" ;

72 r d f : t y p e j o s e k i : P r o c e s s o r

;

73 modu le : imp lemen ta t i on joseki : ImplSPARQL ;

74 j o s e k i : a l l o w E x p l i c i t D a t a s e t "false" ˆ ˆ x s d : b o o l e a n ;

75 j o sek i : a l l owWebLoad ing "false" ˆ ˆ x s d : b o o l e a n ;

76 j o s e k i : l o c k i n g P o l i c y josek i : l ock ingPo l i cyMRSW

;

77 .

78

79 j osek i :ProcessorSPARQLUpdate

80 r d f s : l a b e l "SPARQL Udpate processor"

;

81 r d f : t y p e j o s e k i : P r o c e s s o r ;

82 modu le : imp lemen ta t i on joseki : ImplSPARQLUpdate ;

83 j o s e k i : l o c k i n g P o l i c y josek i : l ock ingPo l i cyMRSW ;

84 .

85

86 joseki : ImplSPARQL

87 r d f : t y p e j o s e k i : S e r v i c e I m p l ;

104

88 module :c lassName < j a v a : o r g . j o s e k i . p r o c e s s o r s .

SPARQL>

89 .

90

91 joseki : ImplSPARQLUpdate

92 r d f : t y p e j o s e k i : S e r v i c e I m p l ;

93 module :c lassName < j a v a : o r g . j o s e k i . p r o c e s s o r s .

SPARQLUpdate>

94 .

Documents

Dissertação de Hugo Feitosa de Figueirêdodocs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/... · 2010. 5. 12. · Resumo As aplicac¸oes cientes de contexto est˜ ˜ao se