contex-aware data management - Facoltà di Ingegneria · conoscere lo stato in cui gli utenti si...

Elaborato finale in Basi di dati

Context-Aware data management

Anno Accademico 2012/2013

Candidato:

Antonio Ambrosio

matr. N46000018

Indice

Introduzione 1

Capitolo 1. Introduzione al contesto

1.1 Il concetto di contesto 31.2 Definizione di contesto 41.3 La context-awareness 51.3.1 Definizione di context-aware 61.3.2 Applicazioni context aware 61.3.3 L'importanza delle applicazioni context-aware nella società futura 8

Capitolo 2. Context-Aware data management

2.1 Introduzione 112.2 Categorizzazione e acquisizione del contesto 112.3 Modellazione del contesto 132.3.1 Introduzione al concetto di ontologia 142.3.2 Modellazione del contesto mediante l'utilizzo delle ontologie 142.4 Strategie per la context-aware data management 172.5 Struttura di un sistema per la context-aware data management 202.5.1 Context-aware querying 22

Conclusioni 24Bibliografia 25

III

Introduzione

Con l'avanzare del tempo e dello sviluppo tecnologico, gli oggetti di uso quotidiano

saranno in grado di elaborare sempre più informazioni in modo del tutto trasparente alle

persone che, di fatto, diventeranno degli utenti inconsapevoli di un ambiente sempre più

intelligente e pronto a prendersi cura di loro, tenendo conto dei gusti e dei bisogni specifici

di ognuno. Tale modello di interazione uomo macchina o HCI (dall'inglese human-

computer interaction) viene chiamato “Ubiquitous computing” oppure “Ambient

Intelligence” (AmI). Quindi, un ambiente di questo tipo, dovrà essere consapevole,

soprattutto, del contesto in cui gli utenti stanno operando (context awareness).

Ad esempio, per un utente che utilizza un navigatore satellitare, potrebbe essere

desiderabile, in un orario di punta, ottenere un percorso che aggiri le zone più

congestionate dal traffico automobilistico nell'istante in cui viene sottoposta la richiesta.

Oppure, per un utente impegnato in una visita turistica in un museo, potrebbe risultare

stimolante avere un dispositivo mobile che, all'avvicinarsi ad una particolare opera,

fornisca informazioni aggiuntive in un formato congeniale al luogo in cui ci si trova,

come, ad esempio, sotto forma di messaggio di testo se ci si trova in un luogo in cui è

richiesto un certo silenzio, oppure, in caso contrario, tramite un messaggio vocale.

Di conseguenza risulta chiaro che una gestione dei dati consapevole del contesto

applicativo in cui si trovano gli utenti (context-aware data management), è di

fondamentale importanza, in quanto, per creare un vero ambiente intelligente bisogna

conoscere lo stato in cui gli utenti si vengono a trovare, così da poter comprendere i loro

desideri e le loro richieste.

Il seguente lavoro di tesi si compone di due parti fondamentali:

la prima parte (corrispondente al primo capitolo), ha l'obiettivo di introdurre il lettore al

concetto di contesto e di applicazione context-aware, nonché di spiegare quale sia

l'importanza delle applicazioni context-aware nella società del futuro.

Invece, la seconda parte (corrispondente al secondo capitolo), fornirà al lettore una

1

panoramica generale sulla context-aware data management (proponendo diversi approcci e

tecniche), con un occhio di riguardo alla parte riguardante il meccanismo di interrogazione

negli ambienti context-aware.

2

Context-aware data management

Capitolo 1Introduzione al contesto

In questo capitolo verrà spiegato in breve cos'è il contesto, come esso influenza le nostre

vite e perché risulterà fondamentale nel futuro dell'informatica. Inoltre verrà spiegato il

concetto di context-awareness e quali sono le caratteristiche che una applicazione context-

aware deve avere.

1.1 Il concetto di contesto

L'essere umano ha sempre sfruttato il concetto di contesto, esso è una componente

fondamentale della comunicazione tra individui, anche se, molto spesso, le persone non

sono in grado di dare una definizione completa di tale concetto. Il contesto rientra in quel

genere di concetti compresi dalla maggior parte delle persone, ma difficilmente

descrivibili a parole.

Tra i primi a parlare di contesto e di context-awareness nel campo dell'informatica,

possiamo annoverare Bill Schilit, Norman Adams e Roy Want [1] , essi affermano che i

tre principali aspetti del contesto sono:

“where you are” (dove ti trovi), “who you are with” (con chi sei) e “what resurces are

nearby” (quali risorse ci sono nelle vicinanze). Se mettiamo insieme le tre frasi appena

citate, ci rendiamo conto che possono essere viste come una prima definizione di contesto

basata su alcune caratteristiche osservabili. Un'altra definizione di contesto fu proposta

da Ryan et al. [2], essi affermarono che il contesto può essere definito tramite una serie di

caratteristiche ambientali (environment), come ad esempio il luogo, la temperatura e

l'identità dell'utente preso in considerazione.

In letteratura sono state proposte altre definizioni molto simili, ma tutte si basano su

caratteristiche particolari o sinonimi del contesto, non risultando molto funzionali da un

3


punto di pratico. Per questo, nel paragrafo successivo sarà proposta una definizione più

funzionale del contesto.

1.2 Definizione di contesto

La definizione di contesto che sarà presa in considerazione in questo tesi è quella che fu

proposta da Dey e Abowd nel 1999 [3] e viene riproposta di seguito:

Context is any information that can be used to characterize the

situation of an entity. An entity is a person, place, or object that is

considered relevant to the interaction between a user and an application,

including the user and applications themselves.

Analizzando tale definizione ci si rende conto che ha un carattere decisamente più

generale rispetto alle precedenti, visto che non esiste più nessuna dipendenza da una serie

di caratteristiche enumerate e considerate come contesto, ma si considera contesto ogni

informazione che può essere utile per caratterizzare e descrivere uno scenario in cui si

trova una particolare entità, dove per entità si intende un soggetto (persone, oggetti,

luoghi) considerato rilevante per l'interazione tra l'utente che sottopone la richiesta e

l'applicazione, dove le entità possono essere l'utente o/e l'applicazione stessa. Riguardo la

definizione di Dey e Abowd, si può fare un'ulteriore osservazione:

spesso quando una persona pensa al contesto crede che esso sia formato solamente dalle

informazioni implicite dell'ambiente circostante (un po' come succedeva nelle precedenti

definizioni), mentre grazie a quest'ultima informazione abbiamo capito che anche le

informazioni esplicite, se caratterizzanti, possono essere considerate contesto a tutti gli

effetti. Ad esempio consideriamo il seguente scenario:

supponiamo di voler fare, trovandoci in Italia, un acquisto in un negozio on-line

internazionale, evidentemente i dati di log-in al negozio saranno considerati un

informazione di contesto esplicito, mentre il paese da cui si effettua la transazione è una

4


informazione implicita che, ad esempio, potrebbe essere sfruttata per rappresentare i prezzi

di tutti i prodotti in euro.

1.3 La context-awareness

L'espressione context-awareness significa letteralmente “consapevolezza del contesto”,

quindi quando si parla di applicazioni context-aware, ci si riferisce ad applicativi che in

qualche modo hanno la consapevolezza del contesto in cui l'utente si trova. Come riportato

da Dey e Abowd [3] i primi a proporre una definizione di elaborazione context-aware

furono Schilit e Theimer nel 1994 [4], essi affermarono che la context-aware computing è

l'abilità di una applicazione di rilevare e reagire ai cambiamenti dell'ambiente in cui è

situata. In particolare il lavoro di Schilit e Theimer si occupava del caso particolare dei

mobile users che dovevano costantemente monitorare l'ambiente circostante per effettuare

operazioni come:

1. rilevare oggetti “interessanti” nelle vicinanze del mobile user;

2. tenere un registro degli oggetti e delle persone incontrate;

3. rilevare specifiche informazioni di territorio, come messaggi lasciati all'utente

oppure messaggi pubblici (una sorta di bacheca elettronica di prossimità);

4. rilevare se ci sono delle periferiche vicine che possono essere sfruttate da qualche

particolare applicativo del mobile user (come delle foto sul cellulare che vogliono

essere visualizzate in un televisore);

5. per rilevare persone o oggetti che possono essere utilizzati come trigger per un

applicativo del mobile user.

La definizione precedente è fortemente legata al concetto di contesto in prossimità

dell'user, per rispondere al bisogno di avere una definizione più generale e non dipendete

dalla prossimità, nel prossimo paragrafo sarà illustrata la definizione che danno Dey e

Abowd.

Inoltre, è doveroso ricorcare, che il primo progetto di context-aware computing fu

5


l'Olivetti active badge realizzato nel 1992.

1.3.1 Definizione di context-aware

Di seguito si riporta la definizione di sistema context-aware data da Dey e Abowd nel

1999 [3]:

A system is context-aware if it uses context to provide relevant information

and/or services to the user, where relevancy depends on the user’s task.

In pratica, Dey e Abowd affermano che un sistema si può definire context aware quando

sfrutta il contesto per fornire importati informazioni o/e servizi all'untente, dove

l'importanza dipende dalla richiesta dell'utente.

Analizzando tale definizione, possiamo subito notare che ha un carattere molto generale e,

quindi, non dipendente da particolari tipi di contesto (come invece accadeva con la

definizione di Schilit e Theimer).

1.3.2 Applicazioni context-aware

Dopo aver definito in modo preciso cosa si intende per contesto e context-awareness, si

può cominciare a parlare delle varie tipologie di applicazioni context-aware.

Nel corso degli anni sono state proposte molte classificazioni riguardo le applicazioni

context-aware, tra i primi ci furono Schilit, Adams e Want [1] nel 1994, essi distinguevano

fondamentalmente in tre classi:

1. Proximate Selection, che significa letteralmente “selezione di prossimità”, è una

tecnica di interfacciamento che prevede che l'utente si avvicini ad un particolare

luogo per poter ricevere delle informazioni rilevanti o/e eseguire elaborazioni, sia

su richiesta che automaticamente.

2. Automatic contextual reconfiguration, è il processo di aggiunta di nuove

6


componenti, rimozioni di componenti già esistenti o l'alterazione di connessione fra

componenti di un sistema. Di fatto si ha la mutazione del sistema in base al

contesto. Tipicamente, i componenti possono comprendere: moduli driver

scaricabili direttamente dall'utente, moduli di programmi (Es: un programma che si

aggiorna in base ad informazioni di contesto), elementi hardware ecc.

3. Contextual informations and commands, spesso le operazioni che le persone

eseguono possono essere predette, infatti, solitamente, ci sono alcune operazioni

ricorrenti che si effettuano quando ci si trova in particolari luoghi (es: università,

biblioteche, uffici ecc.). Le applicazioni che sfruttano questo tipo di “contextual

information” sono fatte in modo da eseguire determinati comandi (contextual

commands) al posto dell'utente sulla base del contesto.

4. Context-triggered actions, sono quelle applicazioni che eseguono automaticamente

una operazione quando si viene a creare una particolare condizione (trigger) nel

contesto.

Con il passare del tempo, sono nati altri tipi di classificazioni, come ad esempio, quella

proposta da Pascoe [5] nel 1998, essa, sotto alcuni aspetti, non si differenzia molto dalla

precedente tassonomia, infatti esiste una parziale sovrapposizione, ma persistono alcune

significative differenze. La classificazione di Pascoe si compone di quattro principali

classi di applicazioni context-aware:

1. contextual sensing, che rappresenta la capacità di una applicazione di rilevare le

informazioni di contesto e di presentarle in modo adeguato all'utente. Come si può

notare, questo tipo di applicazione non è molto differente dalla proximate selection

proposta da Schilit, Adams e Want, con la sostanziale differenza che, nel caso

della contextual sensing, l'utente non deve per forza selezionare uno degli oggetti

del contesto per ottenere più informazioni.

2. Contextual adaption, coincide con la context-triggered actions proposta da Schilit,

Adams e Want.

7


3. contextual resource discovery, coincide con la automatic contextual

reconfiguration proposta da Schilit, Adams e Want.

4. contextual augmentation, è la possibilità, da parte dello user, di associare

informazioni digitali al contesto. Come esempio, possiamo pensare ad un ambiente

in cui ci sia la possibilità di lasciare dei messaggi per gli utenti che

sopraggiungeranno in un secondo momento.

Successivamente (1999), Dey e Abowd [3] proposero una tassonomia che mirava a

combinare i punti di forza dei due approcci precedentemente visti, tale classificazione

viene riportata di seguito:

1. presentation, è la combinazione della proximate selection e della contextual

sensing. In pratica si sfrutta il concetto di prossimita introdotto da Schillit, Adams e

Want, unito all'interfacciamento introdotto da Pascoe.

2. Automatic execution of a service, coincide con la context-triggered actions e la

Contextual adaption.

3. tagging of context, coincide con la contextual augmentation proposta da Pascoe.

E' importante precisare che, una applicazione context-aware, non deve per forza

appartenere precisamente ad una delle categorie elencate, ma è possibile avere delle

applicazioni “ibride” che hanno le caratteristiche di più categorie.

1.3.3 L'importanza delle applicazioni context-aware nella società futura

Da qualche anno si sente parlare sempre più spesso di di ambienti intelligenti (AmI) atti al

miglioramento della qualità della vita, sia in ambito domestico (domotica), che in ambito

cittadino. In particolare, esiste una espressione che ricorre molto nei vari mass-media, tale

espressione è “smart city”. Le smart cities sono le così dette città intelligenti, tale

argomento è interdisciplinare e abbraccia tutti i campi:

dal risparmio energetico, al miglioramento della vita, all'accesso più veloce e naturale alle

8


informazioni. E' proprio in questi ultimi due campi che si inseriscono le applicazioni

context-aware, infatti, nelle città del futuro, ci saranno sempre più spazi intelligenti

(domestici e non), che si prenderanno cura degli utenti e che renderanno loro più semplice

e immediato l'accesso alle informazioni e che, sotto determinate condizioni, saranno in

grado di prevedere i desideri dell'utente e quindi di anticipare alcune operazioni per conto

dell'utente.

In un futuro non troppo lontano, possiamo aspettarci un radicale cambiamento delle

interfacce uomo macchina, probabilmente le interfacce desktop che utilizziamo al giorno

d'oggi ci sembreranno “preistoria informatica”, si pensi che nel giro di un periodo di

tempo relativamente breve si è passato dai grossi mainframe, in dotazione solo alle grosse

organizzazioni, a più di un personal computer per ogni casa.

Come esempio di ambiente intelligente, possiamo pensare ad una stanza che ha la capacità

di regolare automaticamente la temperatura dell'ambiente in base ai gusti dell'utente,

oppure, attraverso un impianto stereo centralizzato, si può variare la musica in base alle

preferenze dell'utente.

E ancora, potremmo pensare ad un parco pubblico in cui le persone, tramite tagging,

possono lasciare i propri messaggi su di una bacheca virtuale, in modo che in futuro, gli

utenti dello stesso parco, possano usufruire dei consigli di chi è stato precedentemente in

quel luogo.

Un altro esempio potrebbe essere quello di un centro commerciale intelligente, dove

quando un utente entra in un negozio, riceve direttamente le informazioni sulla merce

scontata che potrebbe interessargli, tale elaborazione può essere fatta sulla base degli

acquisti precedenti o/e di una serie di indicazioni rilasciate dall'utente stesso (ad esempio

tramite un questionario elettronico messo a disposizione del centro commerciale).

Questo tipo di applicazioni possono diventare molto importanti anche nel campo del

miglioramento della vita delle persone diversamente abili, infatti è possibile studiare degli

ambienti che mutino in base allo specifico bisogno. Ad esempio, consideriamo un persona

affetta da cecità che entra in un edificio pubblico intelligente, tale ambiente, dopo aver

9


recepito le informazioni di contesto relative all'utente, deve essere in grado di guidarlo

verso la sua meta attraverso l'utilizzo di messaggi audio.

Nel prossimo capitolo si studierà un approccio alla gestione dei dati per rendere

realizzabile, almeno in parte, questa avveniristica visione della società futura.

10


Capitolo 2Context-Aware Data Management

2.1 Introduzione

Precedentemente si è parlato delle applicazioni context-aware e della loro importanza nel

futuro della società, in questo capitolo si cercherà di approfondire l'aspetto che riguarda

più propriamente la gestione dei dati in ambienti contex-aware.

In particolare, in ogni paragrafo si parlerà di uno degli aspetti essenziali per rendere

possibile la context-aware data management, fino ad arrivare ad un modello che spiega il

processo di querying in tali ambienti.

2.2 Categorizzazione e acquisizione del contesto

Prima di addentrarsi nel modello di context-aware data management adottato, per una

corretta progettazione di un ambiente context-aware è importante determinare quali sono

le categorie di contesto che si vogliono prendere in considerazione ed attraverso quali

strumenti sia possibile acquisire questi diversi tipi di contesto.

Come esempio sarà mostrata una categorizzazione proposto da Feng et al. nel 2004 [6].

Essi affermano che si possono distinguere due categorie di contesto, una chiamata user-

centric context, tale categoria mette al centro tutta quella parte del contesto che riguarda

esclusivamente l'utente, e l'altra chiamata enviromental context, tale categoria riguarda

tutta quella parte del contesto che proviene dall'ambiente circostante.

Queste due categorie possono essere, a loro volta, divise in diverse sotto-categorie.

L'user-centric context, può essere diviso nelle seguenti sotto-categorie:

• Background, che può comprendere informazioni come:

interessi personali, preferenze (es: culinarie, artistiche, letterarie ecc.), area di

11


lavoro, opinioni soggettive, amicizie, gruppi di interesse ecc. Tutte queste

informazioni possono essere acquisite, ad esempio, collegandosi ai profili personali

che l'utente ha nei vari social network.

• Dynamic Behavior, si riferisce alla variazione dinamica che può avere il

comportamento dell'utente, come, ad esempio, le intenzioni che l'utente ha per il

prossimo futuro, i compiti dell'utente, le attività recenti ecc. Questo tipo di

informazione può essere dedotta dall'agenda dell'utente, oppure, in parte, da uno

storico delle attività dell'utente (come ad esempio le bacheche nei social network).

• Physiological state, questa categoria di contesto comprende tutti gli stati fisiologici

dell'utente, come la temperatura corporea, il battito cardiaco ed altri indicatori

corporei. Tali informazioni possono essere ricavate attraverso dei sensori corporei,

ad esempio, posizionati in una polsiera mentre si fa jogging e collegati ad uno

smartphone.

• Emotional state, come: allegria, tristezza, disgusto, paura, rabbia, sorpresa, calma

ecc. Questo tipo di contesto è uno dei più difficili da ottenere, infatti, per tentare di

ottenere lo stato emozionale dell'utente bisogna analizzare tutta una serie di fattori

corporei e non, come, ad esempio, l'analisi delle espressioni facciali (attraverso dei

software di elaborazione delle immagini), oppure, l'analisi dei suoni emessi

dell'utente (Es: riconoscimento di una risata o di un tono rabbioso).

Unito a quanto detto precedentemente, si può analizzare anche il cambiamento della

frequenza cardiaca e della temperatura corporea dell'utente, infatti, quando ci si trova in

particolari stati emozionali è possibile rilevare cambiamenti fisiologici di questo tipo.

L'enviromental context, può essere diviso nelle seguenti categorie:

• Physical environment, in tale categoria sono raggruppati i fattori fisici, come, ad

esempio, la data e l'ora, la posizione geografica, la temperatura, l'umidità, il rumore

di sottofondo, la quantità di luce, le vibrazioni del terreno, la pressione atmosferica

ecc. Questo tipo di informazioni possono essere ricavate attraverso dei dispositivi

12


GPS, uniti a tutta una serie di altri dispositivi e sensori che possono trovarsi in

prossimità dell'utente (es: stazioni meteorologiche in prossimità dell'user), oppure

si possono trovare integrati in altri dispositivi che l'utente porta con se, come

smartphone e orologi.

• Social environment, questa categoria si riferisce a tutti quei tipi di contesto che

hanno a che fare con entità diverse dall'utente, come ad esempio, il traffico

automobilistico e le persone in prossimità dell'utente. Tali informazioni possono

essere ottenute, ad esempio, dai fornitori dei vari servizi nella zona, senza

analizzare le attività dell'utente.

• Computational environment, questa categoria di contesto si riferisce a tutte le

attività che si trovano in prossimità dell'utente, come ad esempio, le attività

commerciali di interesse della zona in cui si trova l'utente, centri sportivi ecc.

L'acquisizione di tale tipo di contesto dovrebbe avvenire attraverso infrastrutture

messe a disposizione dalle stesse attività interessate, ad esempio mediante

colonnine wireless che comunicano le proprie informazioni alle periferiche mobili

nelle vicinanze.

Come si è appena visto, la categorizzazione del contesto e l'acquisizione sono due attività

estremamente complesse, dove il tipo di contesto dipende fortemente dalla realtà che si

vuole trattare e l'acquisizione risulta una operazione molto ardua, soprattutto quando si

coinvolgono gli aspetti emozionali delle persone. Ad esempio, si pensi al riconoscitore di

emozioni precedentemente citato, che sfrutta, per rilevare le emozioni, l'analisi delle

espressioni facciali e di alcuni parametri fisiologici.

2.3 Modellazione del contesto

Dopo aver parlato delle varie categorie del contesto, nel seguente paragrafo si parlerà di

come il contesto viene modellato.

Nel corso degli anni sono stati proposti vari tipi di modellazione del contesto, ad esempio,

13


Feng et al. [6] definiscono formalmente il contesto nel seguente modo:

sia {a1,a2, … , an} un set di contextual attributes, posiamo rappresentare il dominio di

ogni attributo come Dom(a1), Dom(a2), …, Dom(an). Il contesto può essere visto come un

vettore n-dimensionale, denotato con [[Context]], che si ottiene dal prodotto cartesiano

[[Context]]: a1 x a2 x … x an dei contextual attributes, su tale contesto è possibile definire

delle funzioni che hanno come parametri i contextual attributes.

Per quanto la precedente definizione si corretta formalmente e lascia spazio alla

definizione di funzioni sul contesto, negli ultimi anni si è imposto un altro tipo di

modellazione che risulta avere molti più vantaggi in confronto ai modelli precedentemente

presentati in letteratura, tale modellazione si basa sul concetto di ontologia.

2.3.1 Introduzione al concetto di ontologia

La parola ontologia deriva dal greco e significa, letteralmente, <<discorso sull'essere>>.

Più in generale, con il termine ontologia, ci si riferisce a quella branca della filosofia che si

propone di studiare l'ente in quanto ente [7], dove per ente si intende “qualcosa che è”

(qualcosa che esiste).

La definizione di ontologia utilizzata in ambito informatico deriva direttamente da quella

filosofica. In particolare, nel campo della gestione dell'informazione, si può dare la

seguente definizione:

si definisce ontologia, la conoscenza condivisa di un dominio di interesse, che può

essere rappresentata attraverso un insieme di entità, relazioni, funzioni, assiomi

ed istanze.

Tale definizione ricalca fedelmente quella proposta da Wang et al. [8].

2.3.2 Modellazione del contesto mediante l'utilizzo delle ontologie

L'utilizzo delle ontologie nella modellazione del contesto presenta molteplici vantaggi [8]:

• la possibilità di condividere la conoscenza, infatti l'utilizzo di un modello

14


ontologico facilita l'adozione di un modello unico del contesto per le entità che

partecipano nell'ambito della ubiquitous computing, quando devono comunicano

fra di loro.

• Inferenza logica, attraverso l'utilizzo di un modello ontologico, le applicazioni

context-aware possono applicare efficacemente molti meccanismi di resoning, per

dedurre, a partire dal contesto di basso livello (raw cotext), un contesto di alto

livello. Inoltre, utilizzando un modello ontologico, è facile accorgersi e risolvere le

rilevazioni errate di un contesto di basso livello (Es: rilevazioni erronee da parte di

un sensore), visto che con le ontologie è facile mettere in evidenza le inconsistenze.

• Riutilizzo della conoscenza, grazie al modello ontologico è possibile riutilizzare

dei modelli ontologici condivisi (Es: condivisi in internet), per non partire da zero

nella creazione di un modello ontologico più ampio.

Di seguito analizzeremo nel dettaglio un modello estensibile, basato sulle ontologie, per la

rappresentazione del contesto, tale tipo di modellazione prende il nome di CONON

(COtext ONtology) e fu proposto per la prima volta da Wang et al. [8] nel 2004.

Possiamo dire, realisticamente, che non è pensabile formalizzare tutto il contesto in cui ci

si viene a trovare, ma è possibile individuare alcune contextual entity fondamentali, in

CONON esse sono: location, user, activity e computational entity, ed insieme formano

la così detta Upper Ontology che rappresenta una parte comune a tutti i tipi di contesto,

mentre per modellare le particolarità di ogni contesto è stata prevista una estensione

chiamata Domain-Specific Ontology.

Nel campo dell'ubiquitous computing, solitamente, le applicazioni e i servizi sono

raggruppati in sotto-domini dei vari ambienti intelligenti (es: casa, uffici, parchi ecc.). Da

ciò è possibile individuare l'importanza della Upper ontology, infatti, essa non rappresenta

solo una ossatura di base che il contesto deve avere, ma può essere usata come indice alle

informazioni e per individuare alcune similitudini tra contesti apparentemente molto

15


differenti. Inoltre, tale struttura incoraggia il riutilizzo dei contesti già individuati e

definisce una interfaccia estremamente flessibile per gli specifici domini applicativi.

L'immagine che viene mostrata di seguito riassume quanto appena detto e definisce delle

specializzazioni per le context entity precedentemente citate:

16


La metologia CONON, con le sue entità e relazioni, può essere memorizzata mediante

l'utilizzo del linguaggio OWL, tale linguaggio di markup (derivante da RDF) è stato

studiato appositamente per la rappresentazione delle ontologie, però tale trattazione

specifica esula dagli scopi di questa tesi.

2.4 Strategie per la context-Aware data management

Nel seguente paragrafo si discuteranno quali possono essere le varie strategie per la

context-Aware data management, tali strategie si applicano a seconda del tipo di

interrogazione sottoposta dall'utente. Le cinque seguenti categorie furono proposte da

Feng et al. nel 2004 [6].

1. Context as Present On-the-Spot Query Condition, le applicazioni che seguono tale

strategia sottoporranno ai database solamente interrogazioni in base al contesto

17


corrente (come suggerito dal termine “On-the-Spot). E' consigliabile utilizzare tale

strategia negli ambienti dinamici, con un'alta reattività in cui l'utente viene spinto ad

fare richieste ad-hoc. Un esempio potrebbe essere una query del tipo <<il percorso

che mi porti nel minor tempo possibile, tenendo conto di fattori ambientali (come

traffico, interruzioni stradali ecc.), dal punto in cui mi trovo al mio ristorante

preferito>>.

2. Context as Past Recall-Based Query Condition/Target, in tale strategia si sfrutta il

fatto che spesso ci si ricorda del contesto in cui un dato è stato assimilato che del

dato stesso. Ad esempio, quando si legge un giornale, dopo diversi giorni, risulta più

facile ricordarsi alcune informazioni di contesto (come le persone che erano presenti

o le condizioni atmosferiche), che le notizie che si stavano leggendo. Quindi, le

query che seguono questa strategia, avranno come parametri di ingresso il contesto

passato e restituiranno i relativi dati.

3. Context as Query Constraint, che può essere tradotto con “il contesto come un

vincolo sulle interrogazioni”. In tale strategia, le informazioni di background

dell'utente possono essere utilizzate come un vincolo sulle richieste di informazioni.

Per realizzare tale strategia bisogna processare la richiesta dell'utente secondo le

seguenti fasi:

• Capire quali sono le reali intenzioni dell'utente quando ha sottoposto la query.

Questo passo è essenziale, visto che, non sempre, l'interrogazione sottoposta

dall'utente corrisponde esattamente a ciò che l'utente aveva in mente (si pensi alle

ricerche in internet utilizzando i motori di ricerca attuali). Ad esempio, un untente

che sta guidando e che ha bisogno di cenare in poco tempo, quasi certamente

chiederà al proprio sistema di navigazione di essere condotto al ristorante più

vicino, il sistema dovrà rispondere fornendo il percorso più breve verso il ristorante

aperto più vicino, anche se il particolare dell'apertura non era stato specificato.

• Personalizzare le richieste dell'utente. Solitamente l'utilità dei dati è dipendente

dal contesto in cui ci si trova. Personalizzare le richieste dell'utente significa che, se

18


ad esempio, l'utente sottopone al database la richiesta di cercare un percorso per

tornare a casa durante un'ora di punta, si preferirà fornire all'utente un percorso che

eviti i centri cittadini, così da avere una maggiore probabilità di evitare il traffico

automobilistico, di contro, un utente che guida di notte, prediligerà percorsi

illuminati e centrali per questioni di sicurezza personale.

• Tarare le query in base al desiderio dell'utente. Ad esempio, se un utente

richiede al database delle fotografie ed ha a disposizione un tablet con una elevata

risoluzione dello schermo, è presumibile che preferisca ricevere le foto con una

risoluzione elevata, viceversa, un utente che richiede le stesse fotografie, ma ha a

disposizione un dispositivo con una bassa risoluzione, preferirà ricevere fotografie

a bassa risoluzione. Oppure, in un ambiente domestico intelligente, se un utente

effettua la richiesta di un film dal proprio smartphone ed ha, nelle sue prossimità,

anche un televisore, allora si può presumere che preferisca che il film sia trasmesso

attraverso il televisore.

4. Context as Criteria for Query Result Measurement, in questa strategia il contesto

viene usato come un criterio per la presentazione dei risultati delle interrogazioni

all'utente. Ad esempio, se l'utente richiede al database la lista dei negozi presenti nel

centro commerciale che sta visitando, automaticamente il sistema risponderà con una

lista di negozi, tale lista sarà ordinata in base ai gusti e alle preferenze dell'utente, tali

preferenze possono essere ricavate in base agli acquisti che l'utente ha effettuato in

passato, oppure, sotto precise direttive dell'utente stesso.

5. Context as Guide to Query Result Delivery, che letteralmente significa: “il contesto

come una guida per la consegna del risultato della query”, indica che, in tale strategia,

i risultati di una query sul contesto dovrebbero essere consegnati all'utente in un modo

adeguato al contesto stesso. Facciamo alcuni esempi: supponiamo che un utente si

trovi in una città per motivi turistici, è possibile che una delle prime query che

effettuerà riguarda alcune informazioni storiche sulla città, il database system dovrà

essere in grado di capire quale sia il modo più adeguato di presentare tali informazioni,

19


ad esempio, se l'utente si trova alla guida di un'automobile, il database system dovrà

rispondere con un messaggio vocale, viceversa, se l'utente si trova in un luogo sicuro,

tali informazioni potranno essere recapitate anche in forma testuale. Oppure, se un

utente si trova in riunione per motivi lavorativi, e non vuole essere disturbato, allora, il

sistema, dovrebbe capire che, qualora all'utente arrivassero chiamate o messaggi sul

cellulare, essi dovranno essere recapitati con la vibrazione o in modalità silenziosa.

2.5 Struttura di un sistema per la context-aware da ta management

La seguente infrastruttura è stata proposta da Feng et al. [6], e mostra una possibile

infrastruttura per la context-aware data management. Si noti che un sistema di questo tipo

può essere visto come una sorta di middleware, posto tra l'utente e i database tradizionali,

per la gestione delle interrogazioni sul contesto.

20


chiamate: public data manager e private data manager. La prima delle due rappresenta i

database convenzionali che, come è noto, consentono un accesso pubblico dei dati

(qualora gli utenti abbiano i permessi appropriati), questo tipo di strutture prediligono un

accesso efficiente ai dati, visto che tali dati possono essere acceduto da molti utenti.

Invece, la private data manager risiede sulle periferiche dell'utente (es: tablet, smartphone

ecc.) e si occupa di gestire tutte le informazioni private dell'utente utilizzando dei database

personali, ed accedendo, qualora fosse necessario, a vari public data manager. In

quest'ultimo caso si prediligono l'usabilità e l'accesso facilitato, invece dell'efficienza

nell'accesso ai dati.

Di seguito sono descritte nel dettaglio tutte le sotto-componenti che formano la private

data manager:

• il context manager, tale componente si occupa di mantenere un context-space

(spazio del contesto) e di facilitare l'utilizzo del contesto attraverso acquisizioni real

time ed inizializza gli attributi relativi al contesto.

• Il profile manager, si occupa di gestire il profilo personale dell'utente e di fornire

gli altri componenti i dati relativi a tale profico, come, ad esempio: informazioni

d'identità, interessi, appuntamenti in agenda, i luoghi preferiti dall'utente ecc.

• agenda manager, si occupa di gestire l'agenda degli impegni dell'utente.

All'occorrenza è in grado di fornire informazioni sulle attività passate e il contesto

in cui si sono verificate, infatti, si può pensare di predire alcune azioni dell'utente

analizzando l'agenda e, in particolare, le attività eseguite di recente.

• context-aware query coordinator, si occupa di applicare e controllare

l'esecuzione di una delle cinque strategie per la context-aware data management,

precedentemente proposte.

• Log manager, si occupa di memorizzare e gestire lo storico delle azioni compiute

dall'utente, questo componente collabora con l'agenda manager per ricavare il

contesto passato e, inoltre, fornisce supporto al context-aware query coordinator.

• Database service communicator, è il componente che si occupa della

21


comunicazione tra il private data manager e gli eventuali public data manager

esterni. Tale componente risulta fondamentale, visto che si occupa di gestire

l'eterogeneità dei database esterni e di fornire, all'interno del private data manager,

una visione uniforme dei dati così da conformarsi al database schema in uso.

• Multi-modal interface , tale componente si occupa di presentare le informazioni

all'utente in modo che esse siano coerenti con il contesto. Ad esempio, tale

componente potrebbe convertire i messaggi testuali in audio quando l'utente sta

compiendo una operazione che non gli permette la lettura del messaggio (es:

l'utente è alla guida della propria automobile).

2.5.1 Context-aware querying

Le classiche interrogazioni ai database erano delle query che dipendevano solamente dallo

stato del database stesso, quindi, una stessa query eseguita da persone diverse, in luoghi

diversi o in tempi diversi restituisce il medesimo risultato, a patto che non sia variato lo

stato del database.

Se invece consideriamo anche il contesto, possiamo definire context-aware query, una

query che non dipende solamente dallo stato del database, ma anche dal contesto in cui

viene eseguita. Di conseguenza, una query di questo tipo può essere denotata con:

CQ(database, context) → A

dove CQ sta per Context Query ed A è la risposta all'interrogazione. Dato che questa

query dipende dal contesto, la stessa identica query eseguita in momenti, luoghi o da

persone differenti può restituire una risposta totalmente diversa.

Per completezza, possiamo dire che una normale query (non dipendente dal contesto) può

essere denotata con:

Q(database) → B

dove B è la risposta che resta uguale anche in condizioni di contesto differenti.

Di seguito, in riferimento alla infrastruttura presentata nel paragrafo precedente, si

22


mostrerà quali operazioni vengono effettuate quando un utente sottopone una

interrogazione in un ambente context-aware. La procedura di query processing si divide in

tre fasi:

• Query pre-processing

Tale fase si divide ulteriormente in due sotto-fasi: query refinement e context-

binding. Nella prima delle due fasi si determina quali saranno i contextual attribute

della query (parametri di contesto per la query), mentre nella fase di context

binding si contatta il context manager che, attraverso la comunicazione con

componenti quali l'agenda manager, il profile manager, il log manager o

eventualmente i database privati dell'utente restituisce i valori aggiornati del

contesto.

• Query execution

In tale fase si esegue la query definita nella fase di pre-processing, tenendo

presente il contesto e contattando le pubblic data manager tramite il database

service communicator, qualora la query ne avesse bisogno.

• Query post-processing

Dopo la fase di query execution, i risultati ottenuti verranno prima ordinati

utilizzando il contesto come criterio di ordinamento (Result Sorting) e poi,

attraverso la multi modal interface si può decidere quale sia il modo più

conveniente di presentare i risultati all'utente (Result delivery).

Le tre fasi precedentemente descritte vengono coordinate dal context-aware query

coordinator.

23


Conclusioni

Come si è potuto vedere precedentemente, la context-awareness rappresenta il futuro

dell'informatica, un futuro in cui le interfacce uomo-macchina saranno totalmente diverse

da quelle che sono al giorno d'oggi, tali interfacce saranno sempre più evolute e

sfrutteranno sempre più il contesto che circonda l'utente. Ovviamente, quando si parla di

ambienti context-aware, necessariamente si deve parlare delle soluzioni per una adeguata

context-aware data management.

L'approccio che è stato utilizzato in tale tesi ha due punti di forza:

1. visto che ci troviamo in ambienti in cui si è realizzato il concetto di ubiquitous

computing, l'utilizzo delle ontologie per la modellazione del contesto rende più

semplice la comunicazione tra le entità che partecipano all'elaborazione. Tale

approccio porta con se una serie di vantaggi, tra i quali possiamo citare una

maggiore semplificazione delle operazioni reasoning e una maggiore velocità di

reazione alle richieste dell'utente.

2. Un altro vantaggio dell'approccio utilizzato è la struttura a due livelli per la

gestione del sistema di querying. Tale struttura, oltre ad essere molto semplice da

implementare (si tratta di aggiungere un ulteriore strato software), ha il vantaggio

di riutilizzare e sfruttare le infrastrutture tecnologiche tutt'ora esistenti (come i

database ad accesso pubblico), così da rendere meno traumatico il passaggio dagli

attuali paradigmi ad un ambiente totalmente intelligente.

In definitiva possiamo dire che, nel prossimo futuro, ci dovrà essere un grosso sforzo

intellettuale da parte degli addetti del settore tecnologico, dal momento che dovranno

abbandonare quasi del tutto la concezione che oggi abbiamo della tecnologia per

abbracciare un ideale tecnologico che punta a rendere intelligente, e capace di elaborare

molte informazioni, ogni oggetto che partecipa alla quotidianità delle persone.

24

Bibliografia

[1] Bill Schilit, Norman Adams, Roy Want (1994) “Context-Aware Computing

Applications”

[2] Nick Ryan, Jason Pascoe and David Morse (1997) “Enhanced Reality Fieldwork:

the Context Aware Archaeological Assistant”

[3] Anind K. Dey, Gregory D. Abowd (1999) “Towards a Better Understanding of

Context and Context-Awareness”

[4] Bill Schilit, Marvin M. Theimer (1994) “Disseminating Active Map Informationto Mobile Hosts”

[5] Pascoe, J. (1998) “Adding Generic Contextual Capabilities to Wearable

Computers”

[6] Ling Feng, Peter M.G. Apers, e Willem Jonker (2004) “Towards Context-Aware

Data Management for Ambient Intelligence”

[7] Enciclopedia Treccani on-line - http://www.treccani.it/enciclopedia/ontologia/

[8] Xiao Hang Wang, Tao Gu, Da Qing Zhang, Hung Keng Pung (2004) “Ontology

Based Context Modeling and Reasoning using OWL”

25

contex-aware data management - Facoltà di Ingegneria · conoscere lo stato in cui gli utenti si...

Documents

Transcript of contex-aware data management - Facoltà di Ingegneria · conoscere lo stato in cui gli utenti si...