O modelo de referência para classificação de informações contextuais

informações contextuais, foi desenvolvido um novo modelo de referência para a representação e classificação dessas informações. O modelo desenvolvido é, na verdade, uma sumarização de outros modelos para representação de informações contextuais disponíveis na literatura. Como será visto a seguir, o modelo incorporou os tipos de informações contextuais propostos por Henricksen e co-autores em [Hen02], agregando a eles uma série de atributos e relações (que não tinham sido definidos pelos autores no artigo citado).

Como forma de representação, optou-se pelo uso de ontologias. De maneira simplificada, o modelo de referência pode ser considerado como uma ontologia geral que pode ser estendida por ontologias de domínio (ou ontologias mais específicas). A utilização de ontologias para representar informações contextuais, embora ainda não seja um consenso na literatura, tende a facilitar o compartilhamento de conhecimento e a interpretação por agentes de software, visto que as ontologias estabelecem uma terminologia comum para o entendimento dos conceitos de um domínio.

Os conceitos do modelo de referência proposto são apresentados graficamente na Figura 3.1 através de um diagrama de classes UML estereotipado, conforme sugerido pelo OMG (Object Management Group) em [OMG00]. O Apêndice B apresenta o código OWL [W3C11] da ontologia gerada.

Tabela 3.1 – Abordagens para a modelagem de contexto encontradas na literatura.

Abordagem Aspectos positivos Aspectos negativos Recuperação das

Informações Exemplos de Propostas Key-value models  Fácil de gerenciar [Str04].

 Boa aplicabilidade em ambientes existentes [Str04].

 Não é uma estrutura sofisticada que permite o uso de algoritmos de recuperação de contexto eficientes [Str04].  Difícil de validar [Str04]

Busca linear Context _Toolkit

Markup Scheme Models

 Fácil validação [Str04].

 Boa aplicabilidade em ambientes ubíquos cuja infra-estrutura seja centrada em marcação [Str04].

 A ambigüidade e as informações incompletas são tratadas

só em nível da aplicação [Str04]. Markup Language Query

Context Fabric

Modelos gráficos  Úteis para estruturar as informações [Str04].  Aplicáveis na derivação de um modelo ER [Str04].

 Não são utilizados no nível de instâncias [Str04].  Dificuldades para composições distribuídas [Str04].  Baixo formalismo [Str04]. Transformação Modelos orientados a objetos  Encapsulamento e reusabilidade [Str04]

 São simples, fáceis de programar e eficientes [Roc05].

 Dificuldade de representar aspectos dinâmicos do contexto [Str04].

 O acesso a informações contextuais só é possível através de interfaces específicas [Str04].

 Necessita de infra-estruturas para suportar todas as operações sobre as informações contextuais [Roc05].  Dificuldades para representar as características temporais

das informações e expressar relações como dependência [Hen02].

 A invisibilidade (em conseqüência do encapsulamento) prejudica a formalização [Str04].

 Requerem um alto nível de concordância (agreement) entre as aplicações para poder ter interoperabilidade [Kru07].

Inferencing

Modelos baseados em

lógica  Alto grau de formalismo [Str04].

 Dispositivos computacionais ubíquos geralmente não

apresentam um reasoner lógico completo [Str04]. Algoritmo

Modelos baseados em ontologias

 Rica expressividade e suporte aos aspectos de evolução das informações contextuais [Roc05]  Permitem a realização de inferência sobre as

informações contextuais disponíveis [Hef03, Kru07].

 Permitem que entidades não projetadas para trabalhar em conjunto cooperem [Hef03].

 Restrito a ambientes capazes de trabalhar com OWL para a representação de conhecimento [Str04].

 Uso inapropriado ou modelagem errônea podem limitar o impacto e o uso de ontologias para modelar o contexto [Kru07].

Reasoning Gaia Cobra

A classe Context, como o próprio nome sugere, representa a situação ou contexto de uma entidade. A definição do conceito contexto seguida neste trabalho está apresentada na Seção 2.1.1. O contexto é formado por uma série de informações contextuais (classe ContextualInformation). Cada informação contextual possui um valor (atributo lastUpdatedValue). A auto-associação isCreatedBasedOn (na classe Context) indica que o contexto atual de uma entidade pode ser gerado com base em seus contextos anteriores.

Uma entidade (classe Entity) representa qualquer coisa que se possa falar sobre. De acordo com Dey e Abowd [Dey99], uma entidade pode ser uma pessoa, um lugar ou um objeto. Para os autores deste trabalho, entidades podem representar também dispositivos, agentes de software e outros. Entidades podem se relacionar com outras entidades: elas podem trabalhar de forma cooperativa, podem prestar serviços umas para as outras, podem estar em localizações próximas, podem conter outras entidades, entre outros. A possibilidade de relacionamento entre as entidades é prevista pelo relacionamento hasRelationshipWith do modelo proposto.

No modelo, assim como em [Hen02], há dois tipos principais de informações: as informações atemporais (representadas pela classe NonTemporalInformation) e as informações temporais (classe TemporalInformation). Optou-se pela nomenclatura “temporal” e “atemporal” para enfatizar questões referentes ao tempo de vida das informações (em [Hen02] são utilizadas as nomenclaturas “estática” e “dinâmica”). O contexto atual de uma entidade pode ser formado de informações temporais e atemporais.

As informações temporais possuem três atributos: fator de confiança, precisão e indicador de hora de geração (timestamp). Os atributos fator de confiança e precisão devem ser medidos durante a aquisição ou geração da informação, uma vez que as informações contextuais podem apresentar falhas por razões como: conhecimento parcial do contexto, atraso entre a geração da informação e o seu uso, problemas nos sensores ou erros nos algoritmos e regras para deduzir novas informações. Tais atributos das informações contextuais temporais não são citados por Henricksen e co-autores em [Hen02].

Segundo Henricksen et al. [Hen02] (e corroborado por Cortese e co-autores [Cor05]), há três tipos de informações dinâmicas ou temporais: as informações sentidas (que no modelo proposto são produzidas pelos monitores de fontes de informação –

classe InformationSourceMonitor), as explicitadas (informadas explicitamente pelas entidades) e as inferidas (criadas a partir de interpretações sobre o conjunto de informações contextuais disponíveis). Os tipos de informações dinâmicas podem ser visualizados nas especializações da classe TemporalInformation.

Figura 3.1 – Modelo de referência para a representação de informações contextuais proposto.

Na próxima subseção será apresentado um exemplo teórico de uso do modelo proposto. O exemplo mostra uma releitura do modelo apresentado por Li em [Li06] (Figura 3.2), que traz exemplos de informações contextuais para aplicações centradas em pessoas. Utilizou-se um modelo encontrado na literatura para mostrar que com o modelo de referência proposto é possível descrever outros modelos.

3.1.3.1. Exemplo de uso

A Figura 3.3 apresenta uma releitura do modelo de Li baseada no modelo de referência proposto. A maioria dos conceitos-chave propostos por Li (classes Place, Person e Device), foram mapeados como especializações da classe Entity. O conceito Service foi mapeado como um tipo de informação temporal da entidade Device, uma vez que se considerou que cada dispositivo oferece uma série de serviços já conhecidos a priori. Os demais atributos da classe Device foram transformados em informações atemporais da nova entidade Device. O mesmo aconteceu com o atributo da classe Place (PlaceName foi transformado em uma informação atemporal da nova entidade Place). Já os atributos da classe Person foram mapeados para dois diferentes tipos de informações da nova entidade Person. Os atributos Name, Tel e Address foram considerados informações atemporais. Já o atributo Activity foi considerado uma informação explícita, visto que a atividade precisa ser indicada pelo indivíduo durante a execução da aplicação.

A escolha do tipo de informação para representar a atividade de uma pessoa é uma questão bastante subjetiva e representa uma decisão de projeto. Neste caso, optou- se por classificar a atividade como uma informação explícita porque não é citado no modelo nenhum elemento que possibilite que essa informação seja sentida e também não há outras informações atemporais ou temporais a partir das quais a atividade de uma pessoa possa ser deduzida.

Os relacionamentos entre as entidades foram mantidos conforme indicado por Li. A existência de relacionamentos entre as entidades é prevista no modelo proposto pela auto-associação hasRelationshipWith da classe Entity. Assim, as relações entre as classes Place, Device e Person estão representadas na Figura 3.3 como sub- propriedades de hasRelationshipWith (relacionamento permitido na linguagem OWL). As especializações das classes Place e Device não estão representadas na figura, a fim de melhorar sua visibilidade.