Tesi di Laurea - e-Lite

Transcript

POLITECNICO DI TORINO
III Facoltà di Ingegneria
Corso di laurea specialistica in Ingegneria Informatica
Tesi di Laurea
Blog multimediale automatico di azioni
contestualizzate di utenti mobili
Candidato:
Luca Costabello
Relatore:
Prof. Fulvio Corno
Tutor aziendale:
Laurent Walter Goix
Novembre 2007
Ai miei Genitori
Indice
1
Introduzione .............................................................................................................7
1.1
1.2
1.3
1.4
1.5
2
Il diario giornaliero context-aware: tecniche di generazione note....................13
2.1
2.2
2.3
2.4
2.5
3
La Context-Awareness.....................................................................................17
Il contesto di un utente.....................................................................................18
Scenari applicativi ...........................................................................................20
Context-Aware Platform.......................................................................................21
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5
Pepys................................................................................................................13
MobiLife Life Blogging ..................................................................................14
ActionLog ........................................................................................................14
Context awareness and User Models...............................................................15
Altri lavori .......................................................................................................16
Applicazioni Context-Aware ................................................................................17
3.1
3.2
3.3
4
Scopo della tesi ..................................................................................................7
Servizi Context-Aware e la piattaforma CA......................................................7
I blog e la generazione automatica di contenuti context-aware.........................8
Architettura di riferimento.................................................................................8
Organizzazione della tesi.................................................................................10
Descrizione generale........................................................................................21
Architettura funzionale, server side.................................................................21
Context Brokering: i componenti ....................................................................23
Context Provider..............................................................................................24
Piattaforma client side .....................................................................................26
Il linguaggio ContextML .................................................................................28
Tecnologie usate ..............................................................................................30
Raccolta e clustering dei dati di contesto.............................................................33
5.1
Panoramica generale........................................................................................33
Indice
5.2
5.3
5.4
5.5
5.6
5.7
5.8
6
Raccolta dei dati di contesto............................................................................34
I dati di contesto: caratteristiche generali........................................................38
Cluster Analysis applicata al tracking di un utente .........................................41
Algoritmo “Compare&Merge”........................................................................43
Algoritmo “MultiLevel Sliding Window” (MLSW).......................................45
Il clustering e la percezione dell’utente...........................................................50
Implementazione .............................................................................................52
Generazione e pubblicazione dei Blog Post.........................................................53
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
7
Introduzione.....................................................................................................53
La struttura del testo ........................................................................................54
Personalizzare il testo ......................................................................................58
Natural Language Generation..........................................................................59
Il blog strutturato: Microformats .....................................................................62
Integrare elementi multimediali: TeamLife Portal ..........................................69
La piattaforma di Blogging: WordPress MU ..................................................74
Il blog post pubblicato .....................................................................................76
Implementazione .............................................................................................76
La creazione del VideoBlog ..................................................................................79
7.1
7.2
7.3
7.4
7.5
Architettura generale .......................................................................................79
Il VideoBlogML ..............................................................................................80
La Libreria MING ...........................................................................................82
Creare il Videoblog .........................................................................................84
Pubblicare il VideoBlog ..................................................................................88
8
Scenari abilitati......................................................................................................91
9
Conclusioni e sviluppi futuri ................................................................................93
9.1
9.2
9.3
Risultati ottenuti ..............................................................................................93
Problemi aperti ................................................................................................94
Sviluppi futuri..................................................................................................94
10
Bibliografia.............................................................................................................97
11
Ringraziamenti ....................................................................................................101
6
Introduzione
1
Introduzione
1.1
Scopo della tesi
Il presente lavoro di tesi è stato svolto all’interno del progetto Context Awareness
and Ambient Intelligence del Telecom Italia Lab e ha avuto come obiettivo la
progettazione e lo sviluppo di un generatore automatico di blog contestualizzato. Il
software crea quotidianamente i blog post che descrivono le azioni svolte durante la
giornata dagli utenti registrati al servizio, includendo anche i contenuti multimediali
acquisiti. Tutto questo avviene in modo completamente automatico. Oltre ai blog post in
forma testuale, il generatore mette a disposizione degli utenti un video-diario, anche
questo generato automaticamente.
Il software realizzato si appoggia alla piattaforma Context Awareness sviluppata da
Telecom Italia Lab per permettere la creazione di servizi in grado di reagire al contesto
in cui si trovano gli utenti.
La tesi si occupa non solo di spiegare le scelte progettuali che hanno portato allo
sviluppo del generatore di blog, ma descrive anche le soluzioni implementative più
significative.
1.2
Servizi Context-Aware e la piattaforma CA
Le applicazioni context-aware permettono di fornire contenuti, informazioni e servizi
personalizzati in base al contesto in cui l’utente si trova. Con il termine contesto si
indica appunto un insieme di dati relativi sia allo stato dell’utente che all’ambiente in
cui questo si trova (Capitolo 3). I servizi context-aware hanno l’obiettivo di fornire
informazioni coerenti con la situazione in cui è immerso l’utilizzatore, adattandosi a
possibili variazioni delle circostanze.
Il progetto Context Awareness and Ambient Intelligence di Telecom Italia Lab ha
sviluppato e implementato un prototipo di piattaforma software context aware. Il
progetto è costituito da due componenti distinte: la prima è un client in esecuzione sui
dispositivi portatili degli utenti (PDA, smartphone), mentre la seconda è composta da
numerosi componenti server-side intercomunicanti, che si occupano di elaborare,
riorganizzare ed effettuare reasoning sui dati acquisiti dai client.
7
Introduzione
Grazie alle API messe a disposizione dalla piattaforma CA, è possibile sviluppare
applicativi context aware, come nel caso del generatore di blog contestualizzato.
1.3
I blog e la generazione automatica di contenuti contextaware
La pubblicazione di contenuti generati direttamente dagli utenti è uno dei motori alla
base della grande crescita delle dimensioni del web. La diffusione dei blog personali è
senza dubbio uno degli aspetti che più hanno avvicinato il grande pubblico alla rete. In
molti casi i contenuti pubblicati contengono informazioni personali legate al contesto in
cui l’utente si è trovato, come, ad esempio, le azioni svolte durante la giornata.
Tipicamente queste informazioni sono arricchite dalle foto scattate con il proprio
telefono cellulare, o da video. L’obiettivo principale del generatore di blog è proprio
quello di automatizzare queste operazioni. Grazie all’utilizzo di paradigmi tipici della
context-awareness, il software è in grado di sollevare gli utenti dalla generazione dei
contenuti che descrivono le loro giornate. In questo modo è possibile ottenere blog con
testo naturale, foto e video diari, che descrivono in dettaglio le situazioni in cui ci si è
trovati durante l’arco di tempo desiderato.
1.4
Architettura di riferimento
La generazione di un blog post si articola in più passi, ognuno eseguito da un modulo
funzionale (Figura 1.4.1).
8
Introduzione
Video Blog
Creator
Natural text
generation
Data gathering and
Cluster algorithms
Context
Clusters
Context Raw
Data
TILab CA Platform
Figura 1.4.1 Architettura generale. In grigio i moduli del generatore di blog.
La prima operazione necessaria è l’integrazione con la piattaforma CA, dalla quale il
generatore di blog acquisisce i dati di contesto della giornata di un utente (posizioni,
persone nei paraggi, ecc…).
Le informazioni collezionate vengono elaborate da algoritmi di clustering sviluppati
ad hoc. Questa operazione permette di ricostruire le azioni che l’utente ha compiuto
durante la giornata: è così possibile sapere dove una persona è stata e per quanto tempo.
Gli algoritmi sono inoltre in grado di individuare i movimenti effettuati dagli utenti.
Dopo aver raggruppato i dati, si procede con la conversione degli stessi in testo
naturale. Questo passo si effettua utilizzando un realizzatore di linguaggio naturale. Il
testo generato sarà successivamente arricchito dai contenuti multimediali acquisiti
dall’utente durante le azioni compiute nella giornata. Fotografie e filmati sono prelevate
da un portale web, TeamLife Media Sharing, precedentemente sviluppato all’interno del
progetto Context Awareness and Ambient Intelligence [23].
La creazione di un testo naturale non è però l’unico modo in cui le informazioni di
contesto dell’utente vengono presentate: il modulo di generazione del videoblog si
occupa infatti di trasformare i cluster di contesto in un’animazione Flash. Le azioni che
l’utente ha compiuto durante la giornata sono organizzate nel filmato come i titoli di
testa di un telegiornale: nel video sono integrati anche tutti i contenuti multimediali
acquisiti dall’utente, arricchiti ovviamente dalle informazioni di contesto ottenute grazie
agli algoritmi di raggruppamento.
Il blog testuale e il video-diario sono infine pubblicati sul web, grazie all’utilizzo di
una piattaforma di blogging pre-esistente.
9
Introduzione
1.5
Organizzazione della tesi
Prima di descrivere i dettagli progettuali ed implementativi del generatore di blog, si
analizzano alcuni aspetti fondamentali per comprendere al meglio il contesto in cui
l’applicazione è stata sviluppata.
E’ prima di tutto necessario descrivere alcuni approcci alla generazione automatica di
diari personali context-aware trovati in letteratura. Il capitolo 2 analizza alcuni progetti
dalle caratteristiche simili a ciò che si è realizzato nel presente lavoro di tesi: se ne
elencano i punti più interessanti e si sottolineano le differenze con il generatore di blog
contestualizzato.
Il capitolo 3 descrive i concetti base della Context Awareness e delle caratteristiche
delle applicazioni sviluppate in tale filone. Si parla in modo più rigoroso ed
approfondito della definizione di contesto di un utente e si presentano infine alcuni
scenari applicativi per servizi context-aware in generale.
Le definizioni generali elencate e spiegate nel capitolo 3 trovano un’applicazione
concreta nella descrizione dell’architettura della Context Aware Platform TILab.
All’interno del capitolo 4 si descrivono i componenti della piattaforma, le loro funzioni
e le soluzioni adottate per garantire l’interoperabilità tra i vari moduli che la
compongono, enfatizzando le componenti usate nella generazione del blog [4]. A questo
proposito, il capitolo ospita la descrizione del linguaggio di scambio dati utilizzato dalla
piattaforma, il ContextML. Si parla inoltre delle tecnologie adottate per
l’implementazione della CA Platform e delle necessità che hanno spinto a tali scelte.
Il capitolo 5, già oggetto dell’attività di tesi, si occupa di descrivere le tecniche
utilizzate per acquisire e raggruppare i dati di contesto (posizione degli utenti,
timestamp associati, presenza di amici nelle vicinanze, ecc…). La piattaforma CA mette
infatti a disposizione per ogni utente una grande mole di informazioni: sono gli
algoritmi di aggregazione a dare un significato a questi dati. All’interno del capitolo si
descrivono le caratteristiche più significative dei dati di contesto su cui gli algoritmi
operano (sia a livello di formato che di contenuti) e si analizzano i problemi da
affrontare e gli obiettivi da raggiungere per ottenere un raggruppamento delle
informazioni soddisfacente per l'utente finale. Le tecnologie utilizzate per la
localizzazione giocano un ruolo fondamentale sulla scelta delle tecniche di clustering da
adottare: la decisione di operare con informazioni di posizione basate su cella
GSM/UMTS oppure su identificativi Bluetooth è stata determinante nella decisione di
sviluppare due algoritmi di raggruppamento ad hoc (Compare&Merge e MultiLevel
Sliding Window). I due procedimenti nascono per lavorare su pattern di dati differenti e
sono quindi da considerarsi complementari. I risultati della fase di raggruppamento dei
dati di contesto sono comparati con la percezione che gli utenti hanno delle loro
giornate: si descrivono gli aspetti più importanti da rispettare per ricalcare in modo
soddisfacente le azioni compiute dagli utenti durante la giornata.
10
Introduzione
Dopo aver eseguito gli algoritmi di clustering è necessario creare e pubblicare i blog
post. Il capitolo 6 descrive il processo seguito per la generazione del testo naturale
relativo alle giornate degli utenti. Si analizzano la struttura delle frasi da costruire e il
procedimento che trasforma semplici informazioni di contesto in un testo. Uno dei passi
cardine della procedura prevede l’utilizzo di un natural language generator: si
descrivono i motivi che hanno spinto ad utilizzare tale tecnologia e se ne valutano i
pregi e i difetti. Il testo è inoltre arricchito dalla presenza di MicroFormats, uno standard
per il markup semantico che permette la creazione di blog post strutturati [11] [12]. Il
capitolo descrive inoltre l’integrazione con TeamLife Portal, un content management
system sviluppato dal gruppo Context Awareness TILab, che permette la condivisione
di contenuti multimediali contestualizzati [23]. Il generatore di blog utilizza le API
esposte dall’applicativo per arricchire il testo del diario quotidiano con le foto e i filmati
acquisiti dall’utente durante la giornata. Il capitolo termina con la descrizione della
piattaforma di blogging utilizzata per pubblicare i blog post, WordPress Multi User
[15].
Come già anticipato, il generatore è in grado di presentare la giornata di un utente
nella forma di animazione video. Nel capitolo 7 si elencano le scelte tecnologiche
adottate e le soluzioni implementative più significative, in particolare per quanto
riguarda l’architettura generale del modulo, sviluppato in linguaggio PHP a partire dalla
libreria open source Ming [18], in grado di creare animazioni in formato Flash.
Il capitolo 8 elenca invece alcuni possibili scenari di utilizzo del generatore di blog,
come la condivisione delle proprie esperienze con amici e parenti oppure il supporto
alla memoria umana.
11
Introduzione
12
Il diario giornaliero context–aware: tecniche di generazione note
2
Il diario giornaliero context-aware:
tecniche di generazione note
La generazione automatica dei log delle azioni degli utenti è una tematica su cui la
comunità lavora ormai da molti anni. Vale la pena di citare alcune soluzioni seguite da
progetti con obiettivi simili al generatore di blog contestualizzato.
2.1
Pepys
E’ stato uno dei primi approcci al tracciamento automatico degli utenti finalizzato
alla generazione di log giornalieri [25]. Nonostante tecnologie di localizzazione dalle
caratteristiche limitate (Pepys è stato sviluppato nel 1991), l’approccio è molto simile a
quanto realizzato nel Generatore di Blog Contestualizzato. L’obiettivo primario del
sistema è di agire come supporto alla memoria umana: i log delle giornate serviranno
quindi all’utente stesso per poter ricordare le proprie azioni.
Il sistema, grazie all’utilizzo di badge a radiofrequenza, raccoglie informazioni sulla
posizione degli utenti in ambienti interni (in questo caso, una palazzina di uffici). Viene
rilevata anche la presenza di altri utenti nelle vicinanze. Questi dati sono utilizzati per
costruire un “Diario degli episodi personali” [25], un log che riassume in forma testuale
le azioni compiute da un utente durante la giornata.
Pepys utilizza algoritmi per l’analisi dei dati di contesto relativi ai singoli utenti: il
quorum spotter [25], individua le situazioni in cui molti utenti sono presenti nella stessa
stanza (gathering). Così facendo l’applicazione riesce ad individuare situazioni di
staticità significative, caratterizzate dalla presenza di molti utenti contemporaneamente.
Pepys è inoltre in grado di riconoscere casi di movimento, grazie ad un algoritmo
dedicato, il travel agent [25]. Il riconoscimento degli spostamenti è un aspetto ripreso e
approfondito dal generatore di blog. La fase di aggregazione dei risultati termina con
l’utilizzo del diary episode builder, un modulo che si occupa di astrarre ulteriormente i
risultati ottenuti ai punti precedenti, riducendo, quando necessario, il dettaglio della lista
di azioni compiute dall’utente [25]. In alcuni casi [25], è inoltre prevista una procedura
di gap filling che si occupa di inferire l’azione dell’utente in base alle posizione
precedente e successiva.
13
Il costruttore del diario personale utilizza i risultati ottenuti nella fase di analisi dei
dati per creare l’elenco delle azioni giornaliere dell’utente. Il testo creato è molto
sintetico e schematico, ma il sistema permette comunque all’utente di aggiungere
commenti personali.
La creazione dei log è implementata come un’applicazione batch ed è schedulata
quotidianamente alle ore 4:00 (idea che è stata ripresa dal generatore di blog) . I risultati
sono inviati via email ai rispettivi utenti.
2.2
MobiLife Life Blogging
Il progetto MobiLife (a cui ha partecipato anche il gruppo Context Awareness TILab)
propone Life Blogging [24], un approccio per molti versi analogo a quanto fatto da
Pepys, ma rivisitato in chiave più moderna. Anche in questo caso, si tratta di
un’applicazione in grado di creare un diario giornaliero di un utente a partire da un
insieme di informazioni di contesto.
Nel caso di Life Blogging, queste informazioni sono acquisite grazie all’utilizzo di
un client (Context Watcher) in esecuzione sui terminali mobili degli utenti [24]. Il
software è in grado di fornire informazioni di posizione (basate su cella GSM oppure
GPS), fotografie, dati corporei come il battito cardiaco, ecc…
Le informazioni di contesto sono alla base della generazione automatica del diario
dell’utente, che in questo caso viene presentato sotto forma di blog, utilizzabile
principalmente per condividere contenuti contestualizzati con amici, parenti e colleghi.
Un altro possibile scenario di utilizzo proposto consiste nella creazione di statistiche
personali sul proprio stile di vita [24].
Il sistema si basa sul concetto di clustering delle informazioni di contesto (un aspetto
ripreso, in modo più approfondito, anche dal generatore di blog): grazie ad algoritmi di
aggregazione, si riesce dunque a ricostruire le azioni compiute da un utente durante la
giornata (anche se non si considera la dimensione temporale, aspetto invece
fondamentale per il generatore di blog contestualizzato).
A differenza di quanto accadeva in Pepys, il diario personale di Mobilife Life
Blogging non è composto da un semplice elenco di azioni: l’approccio seguito prevede
infatti di creare del testo il più possibile naturale [24], ed è quindi più simile al
generatore di blog sviluppato.
2.3
ActionLog
Come nel caso di Pepys e Life Blogging, anche ActionLog [27] è un sistema
orientato alla generazione automatica di un diario giornaliero, finalizzato allo scambio
di informazioni tra utenti con contesti simili. Il sistema è stato testato grazie allo
14
sviluppo di un prototipo (ActionLog for Conference [27]), sviluppato espressamente per
supportare lo scambio di informazioni durante conferenze accademiche.
Anche in questo caso si opera a partire da un set di dati di contesto (in particolare
relativi alla posizione e alle persone nelle vicinanze). A partire da questi dati,
ActionLog costruisce una lista di azioni compiute dall’utente. Ad ogni azione
corrisponderà una bozza di frase testuale, generata automaticamente. Questa idea è stata
ripresa dal generatore di blog. Gli utilizzatori possono personalizzare le proprie entry e
inoltre hanno il compito di validarle prima che appaiano sul blog: si tratta dunque di una
pubblicazione semi-automatica. Come in Life Blogging, i contenuti vengono condivisi
in ordine cronologico tramite blog post, ma la generazione di queste informazioni
avviene subito dopo che l’azione si è conclusa e non giorno per giorno come nel caso di
Pepys o del generatore di blog contestualizzato. Inoltre, anche se è prevista a posteriori
una fase di aggregazione dei contenuti, questa si limita a raggruppare le entry generate
in contesti simili e non a sostituirle con frasi che condensano e astraggono le azioni
puntuali.
2.4
Context awareness and User Models
Alcuni progetti, nonostante non siano finalizzati direttamente alla creazione del
diario giornaliero, hanno offerto spunti interessanti, in particolare per quanto riguarda il
rapporto tra dati di contesto e informazioni ricavate direttamente dagli utenti.
SPECTER [26] è un software che opera da assistente personale dell’utente,
adattandosi dinamicamente al contesto in cui questo si trova. Nel realizzare queste
funzionalità, gioca un ruolo centrale il personal journal, il modulo che si occupa di
ricordare le azioni compiute nel passato. L’efficacia dell’assistente personale si basa
infatti in gran parte sull’analisi delle situazioni in cui si è trovato l’utente: grazie alle
informazioni sulle azioni passate, SPECTER è in grado di fornire i consigli e i
suggerimenti corretti.
Il personal journal è senza dubbio il componente più interessante da analizzare ai fini
della generazione di blog contestualizzati. E’ utile in particolare analizzare l’approccio
seguito nel coinvolgere gli utenti ad arricchire le informazioni di contesto acquisite
automaticamente [26]. Il personal journal si basa infatti su un modello ibrido, definito in
parte dall’utente (che può aggiungere a mano alcune azioni che ha compiuto durante la
giornata), ed in parte generato automaticamente. Viene quindi data particolare enfasi al
ruolo che l’utente ricopre nel generare il modello. SPECTER permette inoltre la
modifica manuale delle entry generate in automatico, per poter aggiungere informazioni
aggiuntive o correggere eventuali errori. L’interazione dell’individuo, che specifica
direttamente le proprie azioni, non può che aumentare la precisione e il livello di
dettaglio del personal journal, ma allo stesso tempo è fondamentale focalizzarsi sulla
15
generazione automatica del log delle azioni, per evitare un’eccessiva pesantezza del
processo di correzione manuale. Il personal journal è costituito in gran parte da entry
generate automaticamente a partire dai dati ricavati dai sensori dei device portatili. Si
sottolinea come queste informazioni debbano essere corrette, pena la perdita di fiducia
nel sistema da parte degli utilizzatori[26]. L’idea di coinvolgere gli utenti nella
personalizzazione dei propri post è stata ripresa dal generatore di blog, in particolare per
quanto riguarda la gestione delle etichette attribuite alle posizioni geografiche (Capitolo
5.2).
Un altro sistema interessante è descritto in [28]. Anche in questo caso si tratta di un
assistente personale context-aware. Come in SPECTER, è stato analizzato il rapporto tra
context awareness e informazioni ricavate da tecniche più tradizionali basate su uno
user model [28]: si è giunti alla conclusione, già seguita da SPECTER, di lavorare su
entrambe le categorie. Il Personal Digital Secretary utilizza quindi non solo i dati
ricavati dal contesto, ma anche le informazioni prelevate dal profilo degli utenti. I dati
di contesto, come accade in altri sistemi analizzati in precedenza (Pepys, Life Blogging)
vengono processati da un modulo, il context synthetizer, che si occupa di aggregare le
informazioni per aumentare il livello di astrazione finale.
L’importanza data da [26] e [28] all’interazione con le informazioni direttamente
introdotte dagli utenti ha portato alla formulazione di alcune linee guida per gli sviluppi
futuri del generatore di blog, come l’integrazione con l’agenda dell’utente (Capitolo
9.3).
2.5
Altri lavori
Uno spunto interessante per lo sviluppo del generatore di blog viene da IDAS [29]. Il
progetto, seppur discostandosi dai lavori visti in precedenza (legati sempre in qualche
modo ai concetti di context awareness), introduce l’utilizzo di un Natural Language
Generator per creare automaticamente dei documenti tecnici. La generazione di testo
naturale tramite un sistema NLG sarà la strada seguita anche dal generatore di blog
contestualizzato.
Il progetto MyLifeBits [30], è invece alla base dell’idea dell’integrazione con
contenuti multimediali contestualizzati. MyLifeBits è un sistema sperimentale rivolto
alla raccolta di tutti i contenuti digitali creati durante la vita dell’utente, ai fini di
supportare la memoria degli individui. L’enfasi del progetto è però rivolta in particolare
ai metodi per organizzare questa mole di dati, e non tanto a creare delle rappresentazioni
testuali che condensino i dati raccolti (aspetto questo che è invece fondamentale nella
creazione del blog contestualizzato).
16
Applicazioni Context-Aware
3
3.1
La Context-Awareness
Le applicazioni context-aware permettono di fornire contenuti, informazioni e servizi
personalizzati in base al contesto in cui l’utente si trova nel modo il più possibile
trasparente. [1]
Un’architettura software orientata alla context-awareness è in grado di conferire un
importante valore aggiunto non solo all’infrastruttura broadband su rete cablata, ma
anche al mondo delle telecomunicazioni mobili GSM/UMTS, tipicamente più ricco di
informazioni di contesto. E’ possibile infatti sviluppare una gamma di nuovi servizi, che
si articola fondamentalmente nelle seguenti tre categorie: [2]
- presentazione di informazioni: all’utente vengono presentate informazioni legate
al contesto in cui si trova. Il cliente può eseguire azioni che gli vengono proposte
in base all’ambiente e alla situazione attuale;
- esecuzione di comandi: ad ogni cambiamento di contesto il sistema può eseguire
determinate procedure o assumere particolari configurazioni;
- tagging di informazioni: gli applicativi sono in grado di associare informazioni
ed oggetti della vita reale (documenti, foto, filmati, sale riunioni, stampanti, pc,
ecc..) con informazioni di contesto (ora, posizione, attività svolta, ecc…);
Identificare la situazione di un utente mobile ed adattarla alle sue necessità è
possibile solo grazie alla raccolta e all’elaborazione di informazioni di contesto, che
molto spesso provengono da fonti eterogenee [3]. Oltre ai dati provenienti dal terminale
mobile e dai suoi sensori (ad esempio la fotocamera), sono necessarie informazioni
ricavate dalla rete dell’operatore telefonico, come l’identificativo di cella GSM/UMTS
presso il quale il dispositivo è registrato in un certo istante. E’ inoltre indispensabile la
conoscenza del profilo dell’utente, oltre ad informazioni relative ad altri servizi
tradizionali (calendario, e-mail, ecc…).
Il tipo di servizi che la piattaforma può fornire dipende non solo da quanti e quali
dati sono stati raccolti, ma anche da come questi vengono processati ed analizzati.
Per poter offrire applicazioni context aware è quindi necessaria un’architettura
articolata sui seguenti livelli: [4] (Figura 3.1.1).
17
Figura 3.1.1 Modello a livelli logici di Context Awareness
-
-
-
3.2
context data capturing: questo passo prevede la raccolta dei dati grezzi relativi
all’utente e provenienti per la maggior parte da sensori. I dati devono essere
convertiti in un formato eterogeneo, per poter essere in seguito processati;
context analysis/reasoning: permette di migliorare la qualità delle informazioni
ricavate dai dati grezzi. E’ quindi utile definire, attraverso un’ontologia, un
modello del contesto. Appoggiandosi a questa formalizzazione è così possibile
individuare pattern all’interno della mole dei dati grezzi, utilizzando algoritmi di
learning oppure di data mining. Infine, si effettua del reasoning sui risultati
ottenuti, per ottenere informazioni di alto livello sul contesto dell’utente;
service integration: il contesto dell’utente viene sfruttato dai vari servizi che si
appoggiano sulla piattaforma.
Il contesto di un utente
La Context Awareness permette di offrire all’utente le informazioni e i servizi di cui
ha bisogno in un certo contesto.
Nasce quindi la necessità di definire in modo formale che cosa si intende per
contesto. Secondo A.K. Dey [5] “Contesto è una qualunque informazione che può
essere usata per caratterizzare lo stato di un’entità, sia essa una persona, un luogo
oppure un oggetto considerato rilevante per l’interazione tra l’utente e l’applicazione”.
Un’altra definizione interessante è stata data da Schmidt et al.[6]: “Contesto è la
conoscenza riguardo lo stato in cui si trova l’utente e lo stato dei suoi dispositivi,
incluse informazioni sull’ambiente circostante e la relativa localizzazione”.
18
Occorre poi sottolineare l’importanza della dimensione temporale, grazie alla quale è
possibile pensare ad una vera e propria context history, utile per l’identificazione e la
previsione di pattern di comportamento degli utenti. Il contesto di un’entità è
caratterizzato da dati eterogenei, provenienti da numerose fonti. In base alla dimensione
temporale si distinguono due categorie di parametri di contesto:
- dati statici: sono fissi, oppure variano molto lentamente (dati anagrafici, ecc…).
Sono solitamente ricavati dal profilo dell’utente;
- dati dinamici: localizzazione, velocità, dispositivi nelle vicinanze, ecc… La loro
cattura avviene di solito attraverso software attivo sul dispositivo mobile
utilizzato dall’utente.
E’ possibile suddividere ulteriormente in gruppi di parametri necessari per definire il
contesto di un utente: [1] (Figura 3.2.1)
Figura 3.2.1: Gruppi di parametri per la definizione del contesto
-
user profile: identità e profilo dell’utente;
spazio: posizione, direzione di movimento, velocità e accelerazione;
tempo: ora, data, stagione;
tipo di device: tipo di display, batteria, banda disponibile;
service profile;
ambiente: inteso come temperatura, rumore, inquinamento, ecc;
risorse nelle vicinanze: altri utenti, stampanti, videoproiettori, access point;
presence: la disponibilità all’interazione (online/busy/on the phone);
misure fisiologiche: ad esempio la pressione sanguigna e arteriosa, il battito
cardiaco ed il tono della voce;
attività in corso: come, ad esempio, parlare, leggere, camminare o correre.
19
3.3
Scenari applicativi
L’obiettivo primario di un applicativo context aware è di adattarsi e fornire
informazioni all’utente in base al contesto in cui questo si trova. Tutto questo è reso
possibile dalla capillarità della copertura della rete radiomobile e dalle nuove
potenzialità introdotte dai recenti dispositivi mobili (PDA, smartphone, telefoni
cellulari, ecc…).
E’ possibile riassumere le tipologie di servizi context aware nelle seguenti classi:
- Context Tagging automatico di contenuti personali e condivisione (ad
esempio, fotoalbum o videoalbum, oppure blog contestualizzato generato
automaticamente);
- Service advertising permette di ottenere l’elenco dei servizi personalizzati
in base al contesto dell’utente. In questo filone si inseriscono anche le
applicazioni di pubblicità context-based.
- Personal Communication avanzata, ovvero il trattamento delle chiamate e
dei messaggi in base al contesto.
- E-tourism, tramite la condivisione di informazioni contestualizzate tra utenti
e l’utilizzo di recommender per negozi, ristoranti, musei, locali notturni,
ecc…
Queste tipologie di nuovi servizi rappresentano importanti scenari applicativi per la
context awareness, e allo stesso tempo permettono all’operatore di rete di sfruttare la
grande mole di informazioni di contesto in suo possesso. E’ sufficiente pensare alle
informazioni di posizione su base cella GSM/UMTS: grazie alle applicazioni contextaware è possibile utilizzare questi dati per fornire servizi innovativi agli utenti, senza la
necessità di investire in una nuova infrastruttura di rete.
Il generatore di blog oggetto del presente lavoro di tesi si inserisce proprio nello
scenario dei servizi context-aware, grazie alle informazioni di contesto acquisite dalla
piattaforma sviluppata presso il TILab (Capitolo 4).
20
Context-Aware Platform
4
4.1
Descrizione generale
L’implementazione TILab della Context Aware Platform si suddivide in due parti: il
lato server e la piattaforma residente sui client.
La parte server implementa tutti i livelli logici descritti nel capitolo 3.1: il context
capturing è effettuato in particolare sulle informazioni di posizionamento ricavate dalla
rete GSM/UMTS, ma interessa anche molti altri dati (dispositivi Bluetooth nelle
vicinanze, GPS, fotografie, video, ecc…). Il context reasoning si declina in varie
componenti come il motore a regole, gli algoritmi di clustering, tecniche di pattern
recognition, ecc… Infine, il livello di service integration permette di rendere fruibili alle
applicazioni context aware i risultati delle elaborazioni dei livelli sottostanti.
La parte client, che viene eseguita direttamente sui device portatili, ricopre una
notevole importanza in particolare per quanto riguarda la raccolta delle informazioni di
contesto sul campo, grazie soprattutto all’interazione con i sensori del device che la
ospita.
4.2
Architettura funzionale, server side
L’architettura generale della piattaforma si articola in tre blocchi fondamentali: il
livello dei context enablers, la context aware platform vera e propria e l’application
layer (Figura 4.2.1).
21
Figura 4.2.1: CA Platform, architettura funzionale
Il livello inferiore dell’architettura (utilizzato dal generatore di blog per acquisire i
dati grezzi) fornisce informazioni di contesto di basso livello ed è composto dai
cosiddetti context enablers. Le fonti da cui si provengono i dati sono eterogenee: [4]
- dispositivi mobili: PDA, smartphone, telefoni cellulari;
- sensori intelligenti: sensori interfacciati col corpo umano (che, ad esempio,
sono in grado di rilevare la frequenza del battito cardiaco), sensori ambientali
di umidità, temperatura, luce, videocamere e sensori di movimento (basati su
ricevitori GPS, accelerometri, bussole e giroscopi);
- network enablers: ad esempio address book provider (rubrica centralizzata),
location provider (capace di restituire al chiamante l’indirizzo civico di una
posizione), user proximity provider (restituisce l’elenco degli altri utenti nelle
prossimità), calendar provider (da cui è possibile ricavare informazioni sugli
impegni in agenda dell’utente). Questi componenti sono interrogati
direttamente dal generatore di blog.
22
Il core della piattaforma context aware ha il compito di ottenere informazioni di
contesto più astratte a partire dai dati ricavati dagli enablers del livello sottostante. Si
elencano di seguito i componenti più importanti di questo livello:
- catalogues/profile management: modella e gestisce il profilo degli utenti e
della loro social network (una rete di utenti interconnessi tra loro attraverso
relazioni interpersonali di diverse tipologie, come amicizia, parentela,
rapporti di lavoro, ecc...). Si occupa anche di fornire le informazioni sui
device associati agli utenti e le rispettive caratteristiche tecniche;
- context reasoning: sono i componenti che implementano le logiche di
reasoning della piattaforma. Il componente si articola principalmente in due
sotto livelli principali. Il recommender layer opera per mezzo di algoritmi di
tipo collaborative filtering, trust aware, rule based, ecc… Il context
interpretation/aggregation layer, si occupa invece di estrarre informazioni di
alto livello utilizzando algoritmi di clustering, pattern recognition, machine
learning oppure lavorando con un approccio rule based. Per quanto riguarda
le tecniche rule based, la strada seguita è stata quella di lavorare su un
situation provider, un componente che si occupa di inferire situazioni astratte
(a partire dai dati grezzi) utilizzando un processo di reasoning basato su un
motore a regole; [3]
- context brokering: si occupa di adattare le informazioni grezze alle necessità
dei livelli superiori della piattaforma. Gestisce inoltre una cache dei dati e si
occupa della gestione dello storico dei dati di contesto, la context history
(vedere Capitolo 4.3).
- exposure layer: è l’interfaccia della piattaforma verso le applicazioni context
aware vere e proprie.
La piattaforma CA è alla base del livello applicativo, che racchiude i servizi e le
applicazioni context aware destinate agli utenti finali (photo-sharing, videoblog
contestualizzato, e-tourism, context aware advertising , ecc…)
4.3
Context Brokering: i componenti
Il livello si occupa di adattare e riorganizzare le informazioni grezze di contesto per
renderle disponibili ai piani superiori della piattaforma. (Figura 4.3.1). Si tratta di
un’architettura distribuita, i cui componenti sono ospitati su server differenti.
Il Context Broker ha il compito di recuperare le informazioni di contesto da tutti i
provider, mantenerle per un certo periodo in una context cache interna e distribuirle agli
altri componenti della piattaforma. I dati raccolti dai provider sono eterogenei e
provengono da molte fonti, quindi, per poter essere distribuiti, devono essere codificati
in un formato comune sia al CB che a tutti gli altri provider. Si è così sviluppato un
23
linguaggio XML-based che prende il nome di ContextML (Capitolo 4.6). Per maggiori
informazioni sul ruolo che il Context Broker ricopre all’interno della piattaforma CA, si
rimanda a [4].
Il generatore di blog, per il momento, non utilizza il Context Broker per acquisire i
dati di contesto. Il prototipo sviluppato, per ottenere le informazioni necessarie,
interroga direttamente le interfacce messe a disposizione dai provider, senza appoggiarsi
alla mediazione del broker.
Come spiegato nel capitolo 4.4, il generatore di blog fa però largo uso della Context
History, la base dati gestita e aggiornata dal broker che contiene lo storico delle
informazioni di contesto degli utenti (Figura 4.3.1).
Figura 4.3.1: Il Context Broker e i Provider della piattaforma.
4.4
Context Provider
Alcuni componenti software della piattaforma ricoprono il ruolo di Provider. Queste
entità forniscono un tipo (scope) di informazioni di contesto. Ogni context provider
espone delle interfacce grazie alle quali il CB oppure altri consumer possono recuperare
nuovi dati di contesto.
Il generatore di blog contestualizzato, agendo come un Context Consumer [4],
recupera le informazioni di contesto attraverso una richiesta esplicita al Context
Provider desiderato: un consumer può infatti interrogare direttamente un provider,
tramite i metodi esposti dalle interfacce di quest’ultimo.
La piattaforma permette di recuperare informazioni di contesto eterogenee. L’elenco
sottostante riporta le funzionalità dei CP più importanti:
- Advanced User Profile (AUP): fornisce informazioni sul profilo dell’utente.
(Figura 4.4.1) [1]
24
User Data
User Profile
User Preference
Service
Catalog
User Device/ User Device
Parameter
User Service Profile
Device
Capability
Catalog
User Places
(Virtual Places)
Figura 4.4.1: informazioni fornite dall'AUP
-
-
User Profile comprende l’identità dell’utente, informazioni finanziarie,
abilità personali, inabilità psicofisiche e titoli di studio.
- Le User Preference consistono invece in informazioni relative ai gusti
musicali dell’utente, generi letterari, sport, programmi televisivi, ecc…
- La parte di User Device/Device Parameter contiene informazioni sui
dispositivi mobili registrati dall’utente nel sistema e i relativi dettagli,
come applicazioni aggiuntive, espansioni di memoria, ecc… (l’elenco
completo delle possibili caratteristiche tecniche dei dispositivi è
contenuto nel Device Capability Catalog). Un dispositivo può appartenere
ad un solo utente per volta, ma un utente può registrare diversi device.
- User service profile contiene invece informazioni sui tipi di servizi
context aware a cui un utente si è registrato. Questi servizi possono essere
gestiti e sviluppati dall’operatore (media sharing, generatore di Blog
Contestualizzato, ecc…) oppure servizi di terze parti come l’upload di
contenuti multimediali contestualizzati su Youtube o su FlickR (l’elenco
dei servizi abilitati è contenuto nel Service Catalog).
- La parte relativa agli User Places (anche chiamati Virtual Places)
contiene l’elenco dei luoghi personali di ogni utilizzatore della
piattaforma (Capitolo 5.2). Ad un utente è infatti permesso associare
un’etichetta ad una zona geografica desiderata (esempio: casa propria,
ufficio, stadio,ecc…).
Location Provider (LP): data un’informazione geografica di basso livello
(coordinate GPS, identificativo di cella GSM/UMTS), ne restituisce l’indirizzo,
fornendo quindi via, città, codice postale, provincia (o entità analoghe in caso di
paesi esteri) e stato.
25
-
User Proximity Provider (UPP): analizza una lista di identificativi di device
Bluetooth rilevati nelle vicinanze dell’utente e determina, per ogni id, se a questo
corrisponde una persona nota all’utente stesso.
- Situation Provider (SP): il provider sfrutta altri provider per ricavare
informazioni sul contesto dell’utente ed interagisce con il motore a regole della
piattaforma per inferire la situation dell’utente, che viene poi restituita tramite
l’interfaccia esposta [3].
- Address Book Provider: fornisce informazioni sui contatti dell’utente. Questi
sono memorizzati in un repository conforme allo standard OMA XDM (XML
Document Management), migliorato da un’estensione XML che permette di
specificare la relazione che lega l’utente con i suoi contatti (“friend”, “family”,
“colleague”, ecc…).
- Calendar Provider (CP): opera da proxy nei confronti di applicazioni di terze
parti (ad esempio, Google Calendar) e restituisce informazioni sugli impegni
dell’utente.
Può agire da provider anche il Context History DB (CH), la cui interfaccia permette
di recuperare l’elenco delle informazioni di contesto di un certo utente per il periodo di
tempo desiderato. Il generatore di blog utilizza pesantemente questo componente che, in
generale, è proprio utilizzato per operazioni di post-processing oppure di reasoning.
4.5
Piattaforma client side
Mentre la piattaforma Context Aware lato server si occupa di reperire informazioni
dalla rete (posizionamento dei device degli utenti, informazioni di presence, dati
ricavati da Calendar provider, ecc…), la parte client side ha il compito di catturare
informazioni di contesto direttamente dai device (ID Bluetooth di altri dispositivi nelle
vicinanze, dati provenienti da sensori on board, capabilities del dispositivo mobile,
ecc…). [2] In Figura 4.5.1 si rappresenta l’architettura funzionale della piattaforma
Context Awareness lato client.
26
Figura 4.5.1: CA Platform lato client
Dalla figura si riconoscono funzionalità analoghe alla parte server. Anche in questo
caso l’architettura logica è organizzata in tre livelli distinti:
- Raccolta di dati di contesto: è la parte che si occupa di recuperare le informazioni
di contesto di basso livello. E’ possibile ricavare i seguenti dati grezzi:
- Sensor/Device info: dati provenienti dai sensori integrati nel dispositivo
oppure a cui questo è collegato (fotocamera, antenna GPS, sensori fisiologici,
ecc…);
- Network info: dati ricavati dalla rete a cui il device è collegato (GSM/UMTS,
Bluetooth, ecc…);
- Integrated Location Info: dati di rete specifici per la localizzazione. Sono
distinti per tipo di rete a cui il device è agganciato, e fanno quindi riferimento
a piattaforme di risoluzione geografica diverse, anche queste sviluppate
presso il TILab (es: NIMBLE, per quanto riguarda la localizzazione
GSM/UMTS);
- Presence SIP: modulo utilizzato per invio/ricezione di istant messaging e per
comunicazione con il Context Broker lato server;
- Address Book: informazioni inserite dall’utente nella sua agenda personale
sul device;
- Eventuale Storage che può contenere, ad esempio, cartografia di terze parti.
A partire da questi dati di base, è possibile ricavare, lato client, numerose
funzionalità tecniche del dispositivo mobile in uso. E’ possibile così scoprire le
27
capabilities del device, informazioni sull’hardware e sul software correnti, i canali
radio GSM/UMTS o WiFi disponibili. Si possono anche individuare altri dispositivi
Bluetooth nelle vicinanze, i cui ID saranno risolti dalla parte server della piattaforma.
Inoltre è possibile implementare meccanismi di triggering, per avvisare le user
application del cambiamento di contesto dell’utente in tempo reale. Infine, diventa
possibile tracciare il dispositivo basandosi su tecnologie di rete diverse, ad esempio
GSM/UMTS o Bluetooth, con un conseguente diverso livello di precisione.
- Local Context Broker: è l’elemento centrale dell’architettura lato client. Le sue
funzioni fondamentali comprendono:
- raccogliere i dati grezzi di contesto raccolti nel livello sottostante;
- agisce da unico punto di contatto verso il Context Broker lato server, a cui
invia update di dati di contesto aggiornati e da cui riceve informazioni su
come effettuare l’update di questi dati verso la piattaforma CA;
- agisce da unico punto di contatto anche verso le applicazioni utente in
esecuzione sul dispositivo.
- Application layer: è lo strato di applicazioni utente in esecuzione sul dispositivo
portatile. Una funzionalità applicativa rilevante è il tagging di contenuti
multimediali (foto, video, audio, documenti). Si associano a questi file meta-dati
di contesto, in modo che risultino inscindibili dall’informazione contenuta nel file
stesso. E’ stata sviluppata inoltre un’applicazione che permette all’utente di gestire
alcune policy. E’ possibile quindi modificare direttamente dal device impostazioni
legate alla privacy, al profilo utente e all’impostazione di altre applicazioni.
L’utente è inoltre in grado di gestire e di ottimizzare le policy di update delle
informazioni di contesto verso il Context Broker lato server.
4.6
Il linguaggio ContextML
Per ottenere la piena interoperabilità tra i Provider, il Context Broker e le
applicazioni context aware, è necessario utilizzare un formalismo comune per la
rappresentazioni delle informazioni, che, come visto,sono eterogenee tra loro. E’ stato
così sviluppato il ContextML, un linguaggio XML-based per rappresentare le
informazioni di contesto all’interno della piattaforma CA. I Provider devono offrire
informazioni utilizzando questo formalismo [4].
A causa della loro natura eterogenea, i dati di contesto sono stati raggruppati in
scope. Ad esempio, lo scope “position” comprende le informazioni di latitudine e
longitudine di una certa entità, mentre lo scope “userProfile” è composto dai dati del
profilo dell’utente. E’ possibile anche definire scope aggregati, che comprendono cioè
più scope atomici.
28
Il ContextML, grazie al concetto di scope, permette inoltre di interoperare facilmente
con gli standard di rappresentazione delle informazioni, come, ad esempio, i
MicroFormats, utilizzati dal generatore di blog (Capitolo 6.5).
Lo schema del ContextML è così definito:
- ctxEls: contiene i dati di contesto;
- ctxAdvs: contiene l’advertisment delle caratteristiche del provider;
- scopeEls: contiene la risposta del Context Broker se invocato per ottenere
l’elenco degli scope disponibili;
- ctxPrvEls: contiene la risposta del Broker se invocato per ottenere l’elenco
dei provider disponibili.
Ogni Provider restituisce dati di contesto all’interno di un documento ContextML
costituito dai seguenti elementi:
- contextProvider: nome univoco del provider che ha fornito i dati;
- entità: identificatore dell’entità a cui sono associati i dati di contesto;
- scope: scope dei dati di contesto;
- timestamp e expires: istante temporale in cui la risposta è stata generata e
scadenza della validità dei dati di contesto;
- dataPart: è la parte del documento che contiene i dati di contesto veri e
propri. I singoli parametri di contesto sono elementi <par>, ma è possibile
anche avere parametri strutturati, <parS>, oppure array di parametri, <parA>.
Figura 4.6.1 riporta la risposta dell’Advanced User Profile Provider (AUP), in
linguaggio ContextML, alla richiesta del profilo dell’utente “lukostaz”:
29
<?xml version="1.0" encoding="UTF-8"?>
<contextML xmlns="http://ContextML/1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ContextML/1.1
http://cark3.cselt.it/schemas/ContextML-1.1.xsd">
<ctxEls>
<ctxEl>
<contextProvider id="AUP" v="1.0.0"/>
<entity type="userName" id="lukostaz"/>
<scope>userProfile</scope>
<timestamp>2007-05-04T15:12:29+02:00</timestamp>
<expires>2007-05-04T15:17:29+02:00</expires>
<dataPart>
<parA n="users">
<parS n="user">
<par n="userName">lukostaz</par>
<par n="firstName">Luca</par>
<par n="lastName">Costabello</par>
<par n="gender">m</par>
<par n="birthCity">Pinerolo</par>
<par n="birthCountry">Italy</par>
<par n="birthZip">10064</par>
<par n="birthState">Torino</par>
<par n="birthDate">1983-03-20T00:00:00+01:00</par>
<par n="civilStatus">Celibe</par>
<par n="fiscalCode">12345678901</par>
<par n="nationality">Italiana</par>
</parS>
</parA>
</dataPart>
</ctxEl>
</ctxEls>
</contextML>
Figura 4.6.1 Profilo dell'utente lukostaz, ContextML
4.7
Tecnologie usate
La piattaforma di Context Awareness è caratterizzata da un’architettura distribuita. Il
context Broker e i Provider risiedono su server indipendenti. Per poter interagire con gli
altri componenti, oltre all’utilizzo del linguaggio ContextML, ogni modulo espone
un’interfaccia basata sullo stile architetturale HTTP-REST [7]. È possibile, oltre che
invocare il Context Broker che fa da tramite e da aggregatore, anche invocare
direttamente i provider.
Utilizzare il design REST, caratterizzato da un’interazione stateless tra client e
server, permette di considerare il webservice come una vera e propria risorsa,
identificata dal suo URL. Alle applicazioni che desiderano utilizzare il webservice
(come, ad esempio, il generatore di Blog contestualizzato) viene offerto un set di metodi
remoti che permettono di eseguire le azioni offerte dal webservice stesso. Applicazione
client e webservice devono però essere d’accordo out-of-band sul formato che descrive i
30
dati (in questo caso il ContextML), in quanto REST non offre un modo formale per
descrivere l’interfaccia del webservice. Un importante vantaggio dell’approccio REST
accoppiato ad HTTP riguarda il limitato utilizzo di banda: i messaggi non vengono
infatti appesantiti dallo strato SOAP, e ciò è importante in particolare per quanto
riguarda i dispositivi mobili,caratterizzati da una disponibilità limitata di risorse.
Occorre inoltre aggiungere che il design REST permette un’implementazione più
semplice dei componenti architetturali [2].
L’interfaccia REST è fornita grazie ad una Servlet ed utilizza degli EJB che
implementano i metodi del Provider e che permettono a quest’ultimo di gestire un
eventuale collegamento con sistemi di back end, garantendo inoltre una maggiore
flessibilità in termini di architettura software.
Il Context Broker, che utilizza la stessa tecnologia dei Provider, utilizza un database
relazionale (MySQL) per gestire la Context Cache e i cataloghi degli scope e dei
provider.
31
32
Raccolta e clustering dei dati di contesto
5
5.1
Panoramica generale
Il primo passo necessario alla generazione del blog automatico consiste nella raccolta
dei dati di contesto per ogni utente. Queste informazioni sono generate dal client in
esecuzione su ogni device e si ottengono interrogando le interfacce esposte dai provider
della piattaforma CA (Capitolo 4). Occorre successivamente incrociare informazioni
provenienti da diversi provider per ottenere la base dati su cui operano gli algoritmi di
clustering.
Fondamentalmente, ogni vettore di dati di contesto (Context Update) è caratterizzato
da un timestamp, da informazioni spaziali (identificativo di cella GSM, etichette
assegnate dall’utente a particolari luoghi, ecc…) e da un elenco di dispositivi Bluetooth
nelle vicinanze.
Gli algoritmi di clustering aggregano le informazioni di contesto, generando delle
situazioni in cui l’utente si è trovato durante la giornata (ma è possibile anche operare su
più giorni, settimane o mesi). Per ottenere questo risultato, è ovviamente necessario
aggregare le informazioni tenendo conto della dimensione temporale. Sono stati
sviluppati due diversi algoritmi di clustering per venire incontro alle esigenze emerse
durante la fase di analisi dei pattern delle informazioni di contesto. Il loro
funzionamento verrà spiegato in seguito.
I dati di contesto contengono informazioni sulla posizione degli utenti. Nonostante la
piattaforma CA sia in grado di operare anche con tecnologia GPS (Capitolo 4), la
minore diffusione dei terminali mobili equipaggiati con GPS rispetto a smartphone e
PDA tradizionali ha portato per il momento ad escludere la localizzazione satellitare. Le
tecniche adottate dal generatore di blog utilizzano informazioni di cella GSM/UMTS e
Bluetooth. Entrambe le tecnologie localizzano gli utenti con attributi categorici (codici
di cella e id Bluetooth) e possono venire raggruppate dallo stesso algoritmo. Una delle
estensioni previste è proprio l’integrazione con algoritmi di clustering GPS, già
sviluppati e implementati in precedenza nel progetto Context Awareness TILab. Queste
funzioni dovranno essere adattate a lavorare con la dimensione temporale (Capitolo 9).
33
5.2
Raccolta dei dati di contesto
La raccolta dei dati di contesto avviene nei passi in Figura 5.2.1.
Cattura dei dati di
contesto grezzi
CH
Incrocio con Virtual
Places
AUP
CLUSTERING
LP
Completamento dei
cluster
UPP
CA Platform
Figura 5.2.1 Raccolta dei dati e Clustering
•
Cattura dei dati di contesto: i dati grezzi di contesto vengono ricavati da
Context History (CH) per ogni utente (Figura 5.2.2). CH viene interrogata sulle
interfacce REST che espone. I dati sono restituiti in formato ContextML.
2007-09-07 09:24:08.0 222-1-61101-72162201
Timestamp
GSM CGI
0c6d6ff64;0006c6040e66
Dispositivi Bluetooth
nei paraggi
Figura 5.2.2 Dati di contesto grezzi
•
Incrocio dei dati grezzi con Virtual Places: gli utenti della piattaforma CA
possono etichettare celle GSM, indirizzi Bluetooth e zone delimitate da
coordinate GPS come “luoghi notevoli” (Virtual Place). Ogni VP appartiene ad
34
una categoria ben definita, in conformità allo standard definito nella RFC 4480
[7] (es: residence, office, school, ecc…). Inoltre ai VP è associata una
descrizione, scelta dall’utente (Figura 5.2.3).
office
Categoria
cgi-gsm
Tecnologia usata
222-1-61101-72162201
Elemento da etichettare
TILab
Descrizione
Figura 5.2.3 Virtual Place
Utilizzare Virtual Place definiti su tecnologie di localizzazione diverse (in
questo caso GSM e Bluetooth) permette di definire Virtual Place annidati: un VP
definito su una o più celle GSM può ad esempio contenerne un altro legato ad un
identificativo Bluetooth (Figura 5.2.4).
My office
Canteen
TILab
Figura 5.2.4 Virtual Place muti-tecnologia annidati
L’etichettatura di intere zone in cui l’utente ha soggiornato (oppure è
transitato) può semplificare notevolmente il compito degli algoritmi di clustering
e contribuisce ad un’analisi più precisa delle attività dell’utente. Ad esempio, un
luogo con superficie molto ampia, come un’università, può essere coperto da più
celle GSM: se l’utente etichetta queste celle come appartenenti allo stesso
Virtual Place, l’algoritmo di clustering le aggregherà, lavorando con
l’informazione aggiunta dall’utente. Definire Virtual Place aiuta anche a
mitigare il fenomeno di switch spuri tra celle (Capitolo 5.3).
L’Advanced User Profile, AUP (Capitolo 4.4), è il componente che contiene
l’elenco dei Virtual Place degli utenti. Gli elementi di contesto ricavati dalla
Context History sono quindi incrociati con i VP di ogni utente, tramite
35
l’invocazione di un’opportuna interfaccia REST offerta dal provider di AUP.
Anche in questo caso l’output è presentato in codifica ContextML (Figura 5.2.5).
xsi:schemaLocation="http://ContextML/1.1
<ctxEls>
<ctxEl>
<contextProvider id="AUP" v="1.0.0"/>
<entity type="userName" id="lukostaz"/>
<scope>userVirtualPlace</scope>
<dataPart>
<parA n="virtualPlaces">
<parS n="virtualPlace">
<par n="placeType">residence</par>
<par n="placeInfoType">cgi-gsm</par>
<par n="placeInfo">222-1-24650-1281</par>
<par n="placeName">home</par>
</parS>
<parS n="virtualPlace">
<par n="placeType">office</par>
<par n="placeInfoType">cgi-gsm</par>
<par n="placeInfo">222-1-61101-72162201</par>
<par n="placeName">tilab</par>
</parS>
</parA>
</dataPart>
</ctxEl>
</ctxEls>
</contextML>
Figura 5.2.5 Virtual Place di un utente in codifica ContextML
•
Completamento dei Cluster: dopo aver eseguito il raggruppamento delle
informazioni di contesto con gli algoritmi descritti in seguito (Capitoli 5.5 e 5.6),
si procede con la rifinitura delle informazioni dei cluster ottenuti.
In primo luogo si procede con la risoluzione in indirizzo civico degli
identificativi di cella GSM. La piattaforma mette a disposizione il Location
Provider, LP. Questo componente è in grado di restituire l’indirizzo civico di
una Base Station a partire dal CGI (Cell Global Identify) di quest’ultima (Figura
5.2.6).
36
<contextMLxmlns="http://ContextML/1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema
instance"xsi:schemaLocation="http://ContextML/1.2
<ctxEls>
<ctxEl>
<contextProvider id="LP" v="1.1.6"/>
<entity id="unknown" type="unknown"/>
<scope>position</scope>
<dataPart>
<par n="latitude">45.1104525</par>
<par n="longitude">7.675246666666667</par>
<par n="accuracy">541</par>
<par n="locMode">NimbleCGI</par>
<par n="room"/>
<par n="corridor"/>
<par n="floor"/>
<par n="building"/>
<par n="street">Via Guglielmo Reiss Romoli 239
</par>
<par n="postalCode">10148</par>
<par n="city">Torino</par>
<par n="subdivision">TO</par>
<par n="country">Italy</par>
</dataPart>
</ctxEl>
</ctxEls>
</contextML>
Figura 5.2.6 Risoluzione della cella 222-1-61101-72162201
Ogni cluster contiene una lista di identificativi Bluetooth, che elenca tutti i
dispositivi che si sono trovati nelle vicinanze dell’utente durante il periodo di
tempo indicato. La lista contiene gli id di tutti i dispositivi Bluetooth nei paraggi
dell’utente che hanno volontariamente scelto di rendersi visibili e che quindi non
nascondono il proprio identificativo. Ad ogni utente della piattaforma sono
associati dei device personali (nel profilo di un utente, AUP). Lo User Proximity
Provider (UPP) permette di associare il nome di una persona ad un identificativo
bluetooth della lista, garantendo quindi di ottenere l’elenco dei “buddy”
incontrati in un cluster. Ovviamente questi individui devono essersi
volontariamente registrati in precedenza presso la piattaforma CA. Il provider
restituisce non solo il nome della persona incontrata, ma anche la relazione che
l’utente ha con questi individui: friend, colleague, ecc… (Figura 5.2.7). E’
prevista in futuro un’estensione che permetterà di inserire nei propri blog post
soltanto alcune categorie di utenti: ad esempio, sarà possibile visualizzare i nomi
dei propri amici ma non quelli dei colleghi. Si rimanda al Capitolo 6.5 per
maggiori informazioni.
37
xsi:schemaLocation="http://ContextML/1.1 http://cark3.cselt.it
/schemas/ContextML-1.1.xsd">
<ctxEls>
<ctxEl>
<contextProvider id="UPP" v="1.0.0"/>
<entity id="lukostaz" type="userName"/>
<scope>userProximity</scope>
<dataPart>
<parA n="users">
<parS n="user">
<par n="userName">marcomarchetti</par>
<par n="fullName">Marco Marchetti</par>
<par n="tech">BT</par>
<par n="rel">unknown</par>
<par n="interm"/>
</parS>
</parA>
</dataPart>
</ctxEl>
</ctxEls>
</contextML>
Figura 5.2.7 UPP, esempio di risoluzione di Bluetooth proximity addresses list
Occorre infine sottolineare come la fase di raccolta dei dati sia il processo più
costoso in termini di prestazioni per il generatore di blog. Recuperare tutti i dati
necessari è un’operazione che necessita molte chiamate alla piattaforma CA. Interrogare
le API, disponibili come webservice REST (Capitolo 4), è quindi il vero collo di
bottiglia della catena di operazioni necessarie alla creazione di un blog post.
5.3
I dati di contesto: caratteristiche generali.
Dopo una fase preliminare di raccolta dei dati di contesto da più provider, si ottiene
un dataset di informazioni che interessano la giornata che dovrà essere descritta. In
Figura 5.3.1 vediamo il formato tipico dei dati di contesto con cui lavorano gli algoritmi
di clustering.
2007-09-07 09:24 222-1-61101-72162201 office,tilab
Timestamp
GSM CGI
ownoffice,b1043 Oscar,friend;
Virtual place
CGI
Virtual Place
Bluetooth
Nearby
buddies
Figura 5.3.1 Formato dei dati di contesto incrociati
Come spiegato nel Capitolo 5.2, il generatore di blog ricava le informazioni di
contesto dai provider della piattaforma. La CA Platform riceve ed elabora i context
38
update dai terminali associati agli utenti equipaggiati con il client TeamLife (Capitolo
4.5).
Frequenza degli update
Il client effettua update di dati di contesto con una frequenza non costante nel tempo,
che dipende dalle policy di update scelte dall’utente. Il terminale comunica con la
piattaforma nelle seguenti situazioni:
- Cambio di contesto: il device si aggancia ad una base station diversa, quindi
è necessario comunicare il nuovo CGI al server.
- Refresh Periodico: il client rinfresca periodicamente il proprio contesto,
anche nel caso in cui ci si trova in condizioni statiche. Due parametri
configurabili dall’utente controllano la frequenza degli update:
- Bluetooth scan interleaving: espresso in secondi, è il periodo che
intercorre tra gli aggiornamenti relativi alla presenza di device
bluetooth nei paraggi.
- Cell cycle: è un intero che, moltiplicato con il Bluetooth Scan
Interleaving, definisce l’intervallo in secondi con cui il device effettua
un update della cella CGI-GSM.
Gli algoritmi di clustering sviluppati tengono in considerazione le possibili
differenze di impostazioni tra i terminali, in particolare per quanto riguarda la frequenza
degli update di contesto (che, inoltre, può essere modificata dall’utente direttamente dal
device). Ad esempio, discriminare tra una situazione di movimento e una statica può
essere più o meno semplice a seconda della frequenza del refresh del contesto (Capitolo
5.4). Occorre inoltre considerare che, durante una giornata, possono esserci dei periodi
in cui non si sono verificati update di contesto. L’utente può infatti spegnere il proprio
device per un certo periodo di tempo, può disattivare il client oppure può trovarsi in
un’area non coperta dalla rete GSM/UMTS.
Tipi di location
I dati di contesto seguono un andamento diverso a seconda del luogo in cui l’utente si
trova. È utile analizzare due situazioni distinte, all’interno delle quali si analizza sia il
caso in cui l’utente è fermo, sia il caso in cui è in movimento.
- Aree urbane: la concentrazione di Base Station GSM/UMTS è maggiore e le
singole celle hanno un raggio di copertura di qualche centinaio di metri. In
questo caso la localizzazione su base cella sarà ovviamene più precisa.
- Situazioni statiche: in una zona densamente abitata le Base Station si
sovrappongono ed è più probabile trovarsi a cavallo tra molte celle.
Nonostante l’utente sia fermo in un luogo ben preciso è molto
probabile che il suo terminale non rimanga sempre agganciato alla
stessa Base Station. Si verificano cambi tra celle più o meno rapidi,
39
che complicano l’analisi e il raggruppamento dei dati. Rilevare la
staticità di un utente in questi casi è più complesso (Figura 5.3.2).
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
2007-09-30
17:42:02.0
17:41:38.0
17:41:24.0
17:40:30.0
17:39:11.0
17:39:06.0
17:38:04.0
17:36:29.0
17:36:19.0
17:36:03.0
17:35:26.0
17:35:01.0
17:33:42.0
17:33:26.0
222-1-34649-34079
222-1-34649-17921
222-1-34649-34079
222-1-34649-17921
222-1-34649-34079
222-1-34649-34097
222-1-34649-17921
222-1-34649-31622
222-1-34649-34097
222-1-61101-72165119
222-1-34649-17921
222-1-34649-34079
222-1-34649-31622
222-1-34649-34097
Figura 5.3.2 Switch tra celle in una situazione statica in zona urbana coperta da molte
celle GSM/UMTS (Via Roma, Torino)
-
Situazioni di movimento: è la situazione duale della precedente: in una
zona con una fitta copertura di celle GSM, è possibile tracciare più
agilmente il movimento dell’utente. È utile evidenziare che una
situazione di movimento rapida (viaggio in automobile, treno, ecc…)
è più facile da individuare rispetto al caso in cui l’utente si sposta a
piedi. Nel primo caso otteniamo una chiara sequenza di CGI diversi,
aggiornata ad ogni cambio di cella (Figura 5.3.3). Se un utente si
sposta a piedi, otteniamo, in alcuni casi, un pattern simile a quello di
staticità in presenza di switch di cella spuri.
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
2007-10-02
19:01:59.0
19:01:48.0
19:01:06.0
18:57:50.0
18:57:09.0
18:56:40.0
18:55:09.0
18:54:28.0
18:54:17.0
18:54:05.0
18:53:07.0
18:52:53.0
18:52:42.0
18:51:54.0
18:50:38.0
18:49:53.0
222-1-61104-72377238
222-1-24650-12180
222-1-61104-72377245
222-1-61103-72310599
222-1-61103-72305291
222-1-61103-72305290
222-1-61103-72306615
222-1-61103-72306617
222-1-61103-72328636
222-1-61103-72328635
222-1-61103-72307084
222-1-61103-72307083
222-1-61103-72288628
222-1-61103-72305303
222-1-61103-72305302
222-1-61103-72328629
Figura 5.3.3 Distribuzione dei dati di contesto in caso di spostamento rapido
40
-
5.4
Località rurali: sono coperte da un numero minore di Base Station. Sono
inoltre caratterizzate da un raggio di copertura di qualche Km. La
localizzazione dell’utente è dunque meno precisa.
- Situazioni statiche: sono più facili da individuare rispetto al caso
urbano. Le celle hanno infatti un raggio più ampio, e la probabilità di
trovarsi a cavallo tra una cella e l’altra è minore. Nel caso questo si
verifichi per un tempo abbastanza lungo c’è però il rischio di essere
localizzati in una zona lontana anche qualche Km, a causa della
maggiore distanza tra le Base Station.
- Situazioni di movimento: la localizzazione dell’utente su base GSM,
non permette di distinguere il movimento all’interno di una cella.
Nelle zone rurali, è possibile che un utente effettui del movimento
senza mai uscire dalla stessa cella. In questi casi, non è possibile
discriminare tra una situazione di staticità o una di movimento.
Cluster Analysis applicata al tracking di un utente
Gli algoritmi di clustering sviluppati hanno l’obiettivo di raggruppare i dati di
contesto di un utente, per individuare le azioni che questo ha compiuto durante la
giornata con la massima precisione possibile (Figura 5.4.1).
Cluster 1 (Statico)
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
11:02:33.0
10:59:09.0
10:55:46.0
10:52:41.0
10:48:59.0
10:45:34.0
10:42:11.0
10:38:47.0
10:37:47.0
09:27:01.0
08:58:11.0
08:56:28.0
08:56:05.0
08:54:20.0
08:51:31.0
08:49:16.0
08:48:47.0
08:48:18.0
08:47:50.0
08:47:21.0
08:46:51.0
08:46:20.0
08:45:15.0
08:44:02.0
08:42:33.0
08:42:02.0
08:40:08.0
08:36:26.0
08:33:02.0
08:29:46.0
08:26:15.0
08:22:51.0
08:19:34.0
08:16:10.0
08:12:59.0
08:09:17.0
08:05:53.0
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72157899 office,tilab
222-1-61104-72386176 n/a,n/a
222-1-24650-121 n/a,n/a
222-1-24650-122 n/a,n/a
222-1-54650-923 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72376116 n/a,n/a
222-1-61104-72395763 n/a,n/a
222-1-61104-72400263 n/a,n/a
222-1-61104-72395770 n/a,n/a
222-1-61104-72400262 n/a,n/a
222-1-24650-1281 residence,home
Start
08:58
End
11:02
CGI
222-1-61101-162201
VP CGI
Office, TILab
VP Bth
Not available
Cluster 2 ( Movimento)
Start
08:42
End
08:56
CGI From
222-1-24550-1281
CGI To
222-1-24650-121
VP CGI
Residence, home
From
VP CGI To Office, TILab
VP Bth
Not available
Cluster 3 (Statico)
Start
08:05
End
08:40
CGI
222-1-24550-1281
VP CGI
Residence, home
VP Bth
Not available
Figura 5.4.1 Il processo di clustering dei dati di contesto
41
Le dimensioni interessate nel raggruppamento sono due: il tempo e la posizione.
Il generatore di blog contestualizzato deve rilevare sia situazioni statiche che
dinamiche. E’ quindi necessario definire due tipologie di cluster: i cluster statici e quelli
di movimento.
Un cluster statico è caratterizzato dai seguenti attributi:
- Timestamp di inizio e di fine
- GSM-CGI della cella eletta come centro del cluster
- Virtual Place CGI legato al CGI in precedenza scelto come centro del cluster
(se presente)
- Virtual Place Bluetooth (se presente)
- Elenco delle persone incontrate (se presente)
Un Cluster di movimento ha invece queste caratteristiche:
- Timestamp di inizio e di fine
- GSM-CGI della cella di partenza
- GSM-CGI della cella di arrivo
- Virtual Place CGI della cella di partenza (se presente)
- Virtual Place CGI della cella di arrivo (se presente)
- Virtual Place Bluetooth che identifica il mezzo di trasporto utilizzato. Una
situazione di movimento può infatti essere accompagnata da un identificativo
bluetooth che indica il tipo di veicolo utilizzato nello spostamento, ad
esempio la propria auto, un treno, un bus, ecc… (Capitolo 6.2).
- Elenco delle persone incontrate (se presente)
Come detto in precedenza, il processo di raggruppamento avviene rispettando
l’ordinamento cronologico degli update di contesto.
Occorre ovviamente che le tecniche di raggruppamento operino anche sulla
posizione geografica dell’utente. Sia la localizzazione GSM-CGI che quella basata
sull’etichettatura dei Virtual Place sono effettuate a partire da attributi categorici
(stringhe). Non è quindi possibile operare con tecniche di clustering tradizionali (ad
esempio, K-Means [33]) che raggruppano gli elementi in base alla distanza euclidea, in
quanto non è possibile definire un concetto di distanza sia tra identificativi GSM-CGI
che tra le etichette dei Virtual Place. Inoltre, utilizzare algoritmi di clustering noti in
letteratura che operano esclusivamente su attributi categorici (es: ROCK, [32]) sarebbe
scorretto, perché si ignorerebbe la dimensione temporale, di cui si deve invece tenere
conto per mantenere la cronologia degli eventi.
E’ stato quindi necessario sviluppare un algoritmo ad hoc, che soddisfi tutte le
esigenze elencate in precedenza. L’analisi delle Context History degli utenti, ha portato
alla decisione di sviluppare due algoritmi diversi, che differiscono sia per situazioni di
utilizzo, che per precisione dei risultati.
42
5.5
Algoritmo “Compare&Merge”
L’algoritmo analizza le entry di contesto nell’ordine con cui queste sono restituite
dalla piattaforma (dalla più recente alla più vecchia). In questo modo si evita un
ulteriore ri-ordinamento della lista, che è tipicamente composta, nel caso di una giornata
tipo, da centinaia di record. E’ possibile raggruppare le informazioni basandosi su
GSM-CGI, oppure, se impostati dall’utente, si può operare a livello di Virtual Place
CGI o Bluetooth, trascurando in questo modo i problemi introdotti dalla tecnologia di
localizzazione su base cella (Capitolo 5.3).
La procedura di raggruppamento dei dati si articola in due passi fondamentali:
1. Scansione preliminare della Context History dell’utente e aggregazione
delle entry vicine temporalmente con stessa location (Figura 5.5.1).
foreach ContextEntry ce{
if (ce.location == clusterTemp.location)
clusterTemp.addContextEntry(ce);
else{
tempList.add(clusterTemp );
clusterTemp = new Cluster(ce);
}
}
return tempList;
Figura 5.5.1 Scansione preliminare delle entry di contesto
In questo passo si individuano le situazioni statiche non ambigue, cioè i casi
in cui l’utente ha effettuato degli update di contesto consecutivi con posizioni
uguali (stesso CGI, oppure un gruppo di celle GSM o identificativi Bluetooth
etichettati con lo stesso Virtual Place). Analizzando i pattern dei dati di
contesto, è infatti emerso che nella maggior parte dei casi, questa è una delle
situazioni più frequenti e significativa per l’utente: è quindi molto importante
identificarla correttamente.
Al termine dell’analisi preliminare si ottiene una lista formata da due
tipologie di cluster temporanei:
- Cluster con durata lunga: identificano sicuramente una situazione
statica.
- Cluster brevi e consecutivi, composti da poche entry di contesto:
possono far parte di una situazione di movimento, oppure l’utente si
trova in condizioni di staticità, ma con frequenti switch di cella
(Capitolo 5.3).
2. Merge dei cluster temporanei consecutivi brevi per creare, eventualmente,
cluster di movimento.
Si analizza la lista dei cluster temporanei creata al punto 1 e la si trasforma
nell’elenco dei cluster definitivi. Ci si sofferma in particolare sull’elenco dei
43
cluster brevi: questi vengono aggregati in ordine cronologico in un cluster più
grande. Al momento dell’aggiunta di questo nuovo cluster alla lista finale si
analizza l’omogeneità delle location che questo contiene. Se ad un cluster
appartiene un numero di posizioni diverse superiore ad una certa soglia,
allora si tratta di una situazione di movimento ( per maggiori dettagli si
consiglia il Capitolo 5.7, alla voce “Individuare il movimento”). Nel caso in
cui questo non avvenga, il cluster individua una situazione statica: occorre
quindi impostare come centro del cluster la posizione che ricorre più
frequentemente all’interno del cluster stesso. Figura 5.5.2 descrive lo
pseudocodice della parte principale del metodo.
foreach Cluster currCluster{
// se cluster breve
if (currCluster.duration < durationThreshold){
tempCluster.extend(currCluster);
}
// se cluster lungo
else{
// se troppo poche posizioni diverse
if (tempCluster.locationsCount < locationsThreshold)
tempCluster.moving = true;
finalList.add(tempCluster);
finalList.add(currCluster);
}
}
return finalList;
Figura 5.5.2 Merge dei cluster temporanei brevi
In Figura 5.5.2 si notano due parametri importanti utilizzati dall’algoritmo:
- durationThreshold è la durata minima che un cluster deve avere per
poter essere aggiunto alla lista finale. Attraverso questa soglia è
possibile comunicare al generatore di blog che si desidera tenere
traccia soltanto di eventi abbastanza lunghi. Situazioni di durata
inferiore alla soglia vengono “inglobate” in cluster più ampi.
Modificando il parametro è possibile quindi scegliere il livello di
dettaglio desiderato.
- locationsThreshold è invece la soglia legata alle diverse posizioni
geografiche che un cluster può contenere. Se le posizioni diverse sono
molte, allora si tratta di una situazione di movimento. La scelta di
questo parametro dipende non solo dall’area geografica in cui l’utente
si trova (Capitolo 5.3) ma anche dalle preferenze e dalle abitudini
dell’utente stesso (Capitolo 5.7)
Caratteristiche principali
Le caratteristiche più importanti dell’algoritmo sono riassunte nell’elenco
sottostante:
- Nel caso in cui l’utente abbia effettuato un’etichettatura diffusa e precisa dei
luoghi preferiti, si ottiene una precisione elevata. Le situazioni vengono
44
-
5.6
rilevate correttamente, e l’errore temporale introdotto dall’algoritmo è
trascurabile.
L’algoritmo è in grado di creare cluster di movimento. E’quindi possibile
individuare gli spostamenti compiuti da un utente.
Grazie al parametro durationThreshold è possibile scartare con precisione
le situazioni troppo brevi.
L’algoritmo perde però di efficacia nelle zone non contrassegnate come
Virtual Place in cui si verificano frequenti switch tra celle (Capitolo 5.3). In
questo caso, se il numero di celle diverse è maggiore di
locationsThreshold, la procedura può erroneamente etichettare la
situazione come cluster di movimento.
Algoritmo “MultiLevel Sliding Window” (MLSW)
Compare&Merge è messo in crisi da particolari pattern di dati. Nel capitolo 5.3 si
parla dei problemi legati ai frequenti switch di cella che possono avvenire anche nel
caso in cui l’utente è fermo, e della difficoltà a distinguere questi casi da pattern di
movimento lento. Queste situazioni, se troppo durature, possono mettere in crisi
l’algoritmo, causando un decadimento nella fedeltà dei cluster generati. E’ possibile
mitigare questo problema assegnando alle celle coinvolte negli switch lo stesso virtual
place, ma questa soluzione non è sempre realizzabile (non è pensabile che l’utente si
occupi di etichettare tutti i nuovi luoghi visitati!).
Per risolvere questi problemi si è sviluppato così un nuovo algoritmo. MultiLevel
Sliding Window lavora a partire dalle stesse informazioni di contesto utilizzate da
Compare&Merge. E’ quindi possibile raggruppare i dati in base ai Virtual Place definiti
dall’utente, sia con tecnologia Bluetooth che con GSM-CGI. Se i VP non sono presenti,
il procedimento opererà a livello di identificativo CGI. Per rispettare l’ordinamento
temporale degli eventi, i dati di contesto vengono analizzati in ordine cronologico
inverso.
Per analizzare la Context History di ogni utente si utilizza una finestra scorrevole
(Figura 5.6.1).
45
Sliding window,
Iterazione 1
(durata: 24 minuti)
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
2007-10-03
11:02:33.0
10:59:09.0
10:55:46.0
10:52:41.0
10:48:59.0
10:45:34.0
10:42:11.0
10:38:47.0
10:37:47.0
09:27:01.0
08:58:11.0
08:56:28.0
08:56:05.0
08:54:20.0
08:51:31.0
08:49:16.0
08:48:47.0
08:48:18.0
08:47:50.0
08:47:21.0
08:46:51.0
08:46:20.0
08:45:15.0
08:44:02.0
08:42:33.0
08:42:02.0
08:40:08.0
08:36:26.0
08:33:02.0
08:29:46.0
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72162201 office,tilab
222-1-61101-72157899 office,tilab
222-1-61104-72386176 n/a,n/a
222-1-24650-121 n/a,n/a
222-1-24650-122 n/a,n/a
222-1-54650-923 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72395762 n/a,n/a
222-1-61104-72384437 n/a,n/a
222-1-61104-72376116 n/a,n/a
222-1-61104-72395763 n/a,n/a
222-1-61104-72400263 n/a,n/a
222-1-61104-72395770 n/a,n/a
222-1-61104-72400262 n/a,n/a
Sliding window,
Iterazione 2
(durata: 57 minuti)
Figura 5.6.1 Sliding Window (durata massima della finestra: 60 minuti)
La finestra temporale ha lunghezza massima fissa, determinata da un parametro
espresso in minuti. Nel caso della Figura 5.6.1, questo valore è di 60 minuti. La prima
entry di contesto dell’esempio è delle ore 11:02:33. La finestra scorrevole selezionata
può lavorare su entry non più vecchie delle ore 10:02:33 (la durata massima permessa
è di 60 minuti). I dati dell’esempio hanno però un “buco”, dalle ore 10:37:47 alle
09:27:01 (l’utente potrebbe aver spento il terminale). L’ultimo dato che può far parte
della prima iterazione della finestra è quindi quello datato 10:37:47, in quanto, per
scelta progettuale, l’algoritmo non inferisce la posizione dell’utente in assenza di update
di contesto. Il dato successivo, datato 09:27:01 genererebbe una finestra di durata
superiore ai 60 minuti concessi: occorre quindi fermarsi alle ore 10:37:47. La durata
della prima finestra sarà di 24 minuti. Al momento dello spostamento, la sliding
window partirà dalla prima entry esclusa, quella delle ore 09:27:01 e, in modo analogo
46
a quanto spiegato in precedenza, determinerà l’ultimo dato di contesto che potrà fare
parte della finestra, cioè quello delle ore 08:29:46.
Si lavora quindi in relazione al tempo, e non al numero di entry coperte dalla finestra.
Come spiegato nel Capitolo 5.3, il client in esecuzione sui device aggiorna le
informazioni di contesto con intervalli che non sono noti a priori e che possono essere
non costanti, oltre che riconfigurabili dall’utente a seconda della policy di update
desiderata: non sarebbe quindi corretto definire la lunghezza della finestra in termini di
numero di entry. La durata della finestra è comunque legata alla policy di update scelta
dall’utente: infatti, per lavorare nelle condizioni migliori, la finestra deve contenere un
numero significativo di entry: se si effettuano update con frequenza minore, è bene
aumentare anche la durata della finestra. (nel capitolo 5.7 si discute sui valori più adatti
da assegnare alla sliding window).
E’ possibile raggruppare i dati in base a diversi parametri, organizzati in modo
gerarchico (Capitolo 5.3). L’algoritmo dà la massima priorità ai Virtual Place Bluetooth
definiti dall’utente. Se questi non sono presenti, si scende automaticamente al livello
inferiore, che corrisponde ai Virtual Place GSM-CGI. Se i VP non esistono, si lavora a
livello di identificativo CGI. Il numero e il tipo di livelli sono comunque riconfigurabili
a piacere: lo stesso algoritmo può venire utilizzato anche in altri scenari con un numero
diverso di livelli di annidamento.
Figura 5.6.2 descrive il metodo principale dell’algoritmo:
// creo finestra iniziale
List windowElements = getWindowElements(0);
// ciclo sugli elementi di contesto
while (windowElements.size() > 0){
level = detectLevel();
isMoving = detectMovement();
centre = detectCentre(level);
if ( compareCentres(centre,cluTemp,level) &&
getGapTimeSpan(cluTemp,windowElements)<
offlineTimeSpan){
// estendo il cluster temporaneo corrente
cluTemp = extendCluTemp(windowElements);
}else{
// salvo cluster temporaneo corrente
clusterList.add(cluTemp);
// creo nuovo cluster temporaneo
cluTemp = convertToCluster(windowElements);
}
// faccio avanzare la finestra
windowElements = getWindowElements(windowElements.size());
}
smooth();
return clusterList;
Figura 5.6.2 MLSW, metodo principale
Dopo aver creato una finestra della durata desiderata, si analizzano gli elementi di
contesto che questa contiene con i seguenti metodi:
47
-
detectLevel():
per ogni finestra, l’algoritmo individua il livello a cui deve
lavorare. Si analizzano tutti gli elementi della finestra: se una certa
percentuale ha impostato il Virtual Place Bluetooth, si opera a questo livello.
Altrimenti, si ricade sul livello a priorità inferiore, i Virtual Place CGI. Se
anche in questo caso non c’è un numero sufficientemente alto di entry con
questo valore impostato, si ripiega sull’identificativo di cella (CGI) che,
comunque, è sempre presente. La percentuale minima ottimale di entry con la
stessa posizione è stata scelta grazie a tentativi successivi: inizialmente si è
impostato il limite ad una percentuale del 70%, ma si tratta di un valore
troppo elevato. I dati di contesto, anche a causa del problema degli switch di
cella (Capitolo 5.3), necessitano di percentuali molto più tolleranti. Prove
successive hanno dimostrato che l’algoritmo funziona in modo ottimale con
una percentuale di soglia pari ad un terzo delle entry totali della finestra
(33%). Questo valore è comunque modificabile, nel caso si decidesse di
utilizzare l’algoritmo in modo più restrittivo. E’ bene ricordare però che
valori alti di questo parametro rendono Multilevel Sliding Window più
sensibile ai problemi di switch spuri di celle.
- detectMovement(): la funzione rileva se la finestra sta evidenziando una
situazione di movimento, lavorando esclusivamente a livello CGI. E’ infatti
sembrato fondamentale rilevare spostamenti su scala geografica, mentre è
trascurabile ai fini della generazione del blog scoprire movimenti interni ad
una cella individuati da una successione rapida di diversi Id Bluetooth (es: si
è deciso di non considerare situazioni di movimento tra due stanze
equipaggiate con due diversi beacon Bluetooth). Per rilevare del movimento,
si associa un contatore ad ogni CGI trovato nella finestra. Se nessuna
posizione ricorre per più di un terzo delle entry totali, ci troviamo in una
situazione di movimento (questo valore è stato ritenuto il più ragionevole, ma
può comunque essere modificato) (Figura 5.3.3).
- detectCentre() individua la posizione più frequente all’interno della
finestra. La funzione lavora al livello selezionato da detectLevel(), e può
quindi ritornare un Virtual Place Bluetooth/CGI oppure un identificativo
CGI.
Ad ogni iterazione, gli elementi di una finestra sono inseriti nel cluster temporaneo
precedentemente creato solo se la posizione eletta come centro della finestra è la stessa
del centro del cluster temporaneo stesso.
Si controlla inoltre che dal termine del cluster temporaneo all’inizio della nuova
finestra non sia trascorso un tempo più lungo di un parametro predefinito. In base ai test
effettuati si è scelto di impostare questo valore ad un’ora, ma è comunque possibile
modificarlo. E’ infatti lecito supporre che un periodo di tale durata senza ricevere
update di contesto dia origine ad un nuovo cluster, poiché sarebbe troppo sommario
inferire la posizione in cui l’utente si è trovato per un lasso di tempo così lungo.
48
Intervalli temporali senza informazioni di contesto non sono quindi descritti da alcun
cluster.
Smooth() si occupa di armonizzare le sequenze di cluster statici e di movimento,
facendo combaciare, (se è possibile) la posizione di arrivo e di partenza delle situazioni
di movimento con i luoghi in cui l’utente ha stazionato nei cluster che seguono o
precedono lo spostamento.
Caratteristiche principali
Le caratteristiche più importanti dell’algoritmo possono essere riassunte nei
seguenti punti:
- MLSW è particolarmente efficace nei casi di situazioni statiche, con molti
switch di cella. La presenza della finestra scorrevole mitiga infatti
l’effetto dei saltellamenti da una cella all’altra.
- E’ in grado di individuare cluster di movimento.
- E’ possibile configurare a piacere il numero di livelli gestibili e le loro
rispettive priorità.
- E’ utile soprattutto nei casi in cui gli utenti non abbiano creato molti
Virtual Place, in particolare nelle aree urbane fittamente coperte da celle
GSM/UMTS.
- L’algoritmo è meno preciso rispetto a Compare&Merge per quanto
riguarda le decisioni prese sull’inizio e la fine dei cluster. Maggiore è la
dimensione della finestra scorrevole, maggiore sarà l’errore commesso
nello stabilire i margini di un cluster. Una finestra di breve durata
permette di lavorare con una maggiore precisione ma, allo stesso tempo,
non dà la possibilità di ignorare i cluster più brevi, come i piccoli
spostamenti oppure le soste nei pressi di access point Bluetooth etichettati
come Virtual Place dall’utente (Capitolo 5.7).
- Come anticipato nel punto precedente, l’algoritmo MLSW permette di
ignorare le situazioni più brevi (e quindi trascurabili ai fini della
generazione del blog). Per ottenere questo risultato è sufficiente impostare
una lunghezza della finestra adeguata. La natura dell’algoritmo non
permette però di impostare direttamente una durata minima per i cluster,
come accade invece in Compare&Merge.
49
Figura 5.6.3 riassume le caratteristiche principali di entrambi gli algoritmi sviluppati:
Compare&Merge
Multilevel Sliding Window
Tipologia
Raggruppamento di attributi categorici con gestione della
dimensione temporale.
Parametri utilizzati per il
raggruppamento
GSM/UMTS CGI, Bluetooth, Virtual Place impostati dall’utente.
Identificazione situazioni
di movimento
Situazione di utilizzo
ottimale
Situazioni critiche
Sì
Sì
“Situazioni note” (presenza di
Virtual Place, celle GSM senza
particolari problemi di switch,
ecc…)
Casi di switch spuri tra celle in
situazioni statiche
Precisione
Molto buona nelle situazioni ottimali
(inferiore ad un update di contesto).
Durata minima delle
situazioni identificate
Impostabile dall’utente
Giornate vissute in luoghi
anche non etichettati da Virtual
Place.
Nessuna in particolare
Dipende dalle dimensioni della
finestra scorrevole. Una
window lunga 30 minuti
garantisce errori contenuti
(< 10 minuti).
Non direttamente impostabile.
Dipende in modo indiretto
dalle dimensioni della finestra
scorrevole
Figura 5.6.3 Caratteristiche principali degli algoritmi a confronto
Nello sviluppare gli algoritmi di clustering, non si è tenuto conto del tempo di
esecuzione. Questo aspetto non è così importante per il generatore di blog. I set di dati
di contesto su cui gli algoritmi operano sono composti infatti da qualche centinaio di
record. Lavorare con dataset di queste dimensioni non vincola lo sviluppatore a cercare
soluzioni particolarmente orientate alle prestazioni. Come già anticipato (Capitolo 5.2),
il collo di bottiglia del processo di generazione di un blog post è la fase di raccolta dei
dati dalla piattaforma CA.
5.7
Il clustering e la percezione dell’utente
L’analisi della giornata di un utente tramite tecniche di raggruppamento dei dati di
contesto, spinge a formulare alcune considerazioni. Il generatore di blog e gli algoritmi
sviluppati hanno l’obiettivo di ricostruire la giornata in modo che questa sia il più
possibile simile alla percezione e ai ricordi dell’utente. L’utilizzo del software su un
gruppo di utenti per alcuni mesi ha permesso di capire che, per ottenere un buon
risultato finale, occorre tenere in considerazione i seguenti aspetti:
50
Analisi dell’errore
L’errore complessivo è composto da due componenti separate.
Occorre in primo luogo tenere conto dell’incertezza introdotta dalle tecnologie
utilizzate per la localizzazione dell’utente. Ad esempio, se un utente compie movimenti
all’interno della stessa cella CGI, questi saranno invisibili alla piattaforma (Capitolo
5.3). Inoltre, occorre tenere conto delle discrepanze tra i Virtual Place e gli stessi luoghi
nella realtà: abbandonare il Virtual Place “office” significa tipicamente uscire dalla cella
GSM/UMTS associata, cosa che può accadere (nei casi peggiori) anche a qualche Km di
distanza dal luogo virtuale nella realtà.
Esiste inoltre una componente di errore legata all’azione degli algoritmi di clustering.
Compare&Merge commette un errore quasi nullo nelle transizioni in cui compaiono
Virtual Place. La presenza di un VP mitiga infatti i problemi legati agli switch tra una
base station e l’altra (Capitolo 5.3). L’errore commesso nei casi in cui la transizione
avviene tra cluster con posizioni specificate soltanto dalla cella GSM è al massimo di
alcuni minuti (Capitolo 5.5). L’errore commesso da MLSW non dipende invece dalla
distribuzione dei dati contesto, ma dalla dimensione della finestra scorrevole (Capitolo
5.6). Per limitare l’incertezza massima dei cluster ad alcuni minuti, i test effettuati
suggeriscono di utilizzare una sliding window di durata pari a mezz’ora. Finestre più
lunghe determinano errori più consistenti, e quindi i risultati dell’algoritmo sono più
sommari.
Occorre sottolineare che il ricordo che gli utenti hanno della loro giornata è, nella
maggior parte dei casi, abbastanza sommario. In generale, tollerare un errore massimo
di circa 10-15 minuti, permette comunque di ricalcare fedelmente le azioni compiute
durante una giornata.
Durata minima dei cluster
Il testing dell’applicazione ha permesso di tarare gli algoritmi in modo da scartare i
cluster troppo brevi. Il problema è presente in particolare nel caso in cui l’utente
stazioni ripetutamente per brevi periodi in Virtual Place Bluetooth, quindi poco estesi
(es: un palazzo in cui ogni ufficio è equipaggiato con il proprio beacon Bluetooth). Le
persone tendono infatti a trascurare gli spostamenti o le soste non abbastanza lunghe.
Nella maggior parte dei test effettuati, gli utenti sembrano dare poca rilevanza alle
situazioni con durata inferiore ai 30 minuti. Alzare eccessivamente questa soglia
significa invece perdere troppi dettagli significativi.
Dipendenza dal provisioning utente
Entrambi gli algoritmi di clustering sviluppati sono in grado di operare su dati di
contesto generati senza l’intervento dell’utente. Dall’utilizzo dell’applicativo è però
emerso che l’efficacia del raggruppamento (in particolare se si utilizza
Compare&Merge) aumenta notevolmente con il numero di Virtual Place impostati. Un
set esteso di VP permette infatti di mitigare i problemi causati dalla localizzazione
51
basata su GSM/UMTS (Capitolo 5.3). Gli algoritmi si comportano quindi meglio se
utilizzati in “situazioni note”, etichettate dall’utente con i Virtual Place adatti (esempio,
le giornate lavorative, passate tra casa e ufficio). Inoltre, il provisioning dell’utente è
utile per assegnare ad ogni luogo una categoria corretta (Capitolo 6.5).
Individuare il movimento
Come già spiegato nella descrizione degli algoritmi, la decisione di creare una
situazione di movimento avviene nel caso in cui il cluster possieda un numero di
posizioni diverse superiore ad una certa soglia. Nello scegliere questo parametro è
importante tenere conto di come gli utenti percepiscono il movimento. Ad esempio,
alcune persone non considerano come spostamento una passeggiata in centro città, ma
la cluster analysis in questo caso potrebbe etichettare la situazione come un movimento.
Inoltre i pattern dei dati di contesto variano molto in base alla velocità degli
spostamenti: movimenti rapidi sono identificati da una chiara sequenza di identificativi
di cella diversi, mentre quelli lenti (ad esempio una passeggiata) sono più ambigui
(Capitolo 5.3). In base all’esperienza maturata in questi mesi, sembra ragionevole
utilizzare una soglia di 5 CGI diversi per Compare&Merge (Capitolo 5.5), mentre è
opportuno che nessuna entry della finestre di MSLW abbia una frequenza superiore al
33% (Capitolo 5.6).
Inter-cluster gap
E’ possibile, per alcuni motivi, che la piattaforma non riceva update di contesto per
un certo periodo. Il terminale o il client possono infatti essere disattivati dall’utente per
il lasso di tempo desiderato. Al termine di una situazione del genere (ovviamente, il
problema si pone in caso di stazionarietà) è ancora lecito considerare le nuove entry di
contesto come parte del vecchio cluster? Gli algoritmi prendono in considerazione
questa situazione, attraverso soglie che definiscono la durata massima accettabile di
questi periodi senza update; tipicamente questi valori corrispondono a 60 minuti. Oltre
questa soglia si crea un nuovo cluster anche se la posizione è la stessa del gruppo di
entry precedente. Come già anticipato in precedenza (Capitolo 5.6), gli intervalli
temporali senza informazioni di contesto non sono descritti da alcun cluster.
5.8
Implementazione
Il processo di acquisizione delle informazioni di contesto dalla piattaforma CA e gli
algoritmi di raggruppamento dei dati sono implementati come classi Java.
52
Generazione e pubblicazione dei blog post
6
Generazione e pubblicazione dei Blog
Post
6.1
Introduzione
In seguito alla fase di raccolta dei dati di contesto e di clustering (Capitolo 5),
occorre generare il blog post vero e proprio. Effettuare questa operazione prevede alcuni
passaggi (Figura 6.1.1).
Per prima cosa si analizza l’organizzazione del testo di un blog post, con particolare
enfasi sulle strutture sintattiche che lo compongono. Si descrivono in seguito le tecniche
utilizzate per trasformare in testo naturale i dati contenuti nei cluster di contesto.
L’implementazione di questo passaggio avviene attraverso l’utilizzo di un Natural
Language Generator (NLG). Alcune informazioni presenti nel testo del blog post
(indirizzi, persone nelle vicinanze dell’utente) sono inoltre arricchite tramite l’uso di
particolari strutture di markup semantico note come Microformats. Una volta creato il
testo, è necessario aggiungere i contenuti multimediali acquisiti dall’utente durante la
sua giornata. Il generatore di blog è così integrato con le informazioni provenienti dal
portale di media sharing TeamLife, un’altra applicazione sviluppata nel progetto di
Context Awareness [23]. Infine, occorre pubblicare i post sul web: in questo caso si
utilizza una piattaforma per il personal blogging in grado di gestire una community di
utenti, Wordpress Multi User: grazie a questo software, ogni utente può dispone del
proprio blog contestualizzato.
53
Blog Post
Generation
NLG
Context
Cluster
User
preference
s
Figura 6.1.1 La generazione dei blog post, schema generale
6.2
La struttura del testo
Per generare un blog post è necessario convertire i cluster di contesto in frasi in
linguaggio naturale.
Frasi statiche
Context
Clusters
Action
Detector
Frasi statiche
(compl. ogg)
Realiser
Frasi di
Movimento
_______
_______
_______
_______
Testo
Naturale
Figura 6.2.1 Processo di generazione del testo naturale
Questo passaggio necessita della definizione di alcuni costrutti standard. È possibile
distinguere tre tipi di strutture, in base al tipo di azione eseguita dall’utente:
- Statiche: la persona è stata ferma in un luogo per tutta la durata del cluster. È
il caso più frequente e viene generato a partire da un cluster statico. Il
costrutto assume la struttura in (Figura 6.2.2). Come spiegato
successivamente, il verbo scelto dipende dal tipo del luogo in cui l’utente si è
trovato
Soggetto
Verbo
Luogo
Durata, inizio e fine
Buddies
I stayed at home for 4 hours, from 18:43 to 22:52, and there I met Marco.
Figura 6.2.2 Situazione statica
54
-
Statiche con complemento oggetto: l’utente è stato fermo in un luogo e ha
partecipato ad un evento di durata pari a quella del cluster (es: riunione,
convegno, lezione, ecc…). È generato a partire da un cluster statico.
Soggetto
Verbo
Compl. Oggetto
Luogo
Buddies
Inizio e Fine
I had a four hour lesson in classroom 4 with Marco, from 10:30 to 14:30.
Figura 6.2.3 Situazione statica con complemento oggetto
-
Movimento: l’utente si è spostato da un luogo ad un altro. Ovviamente
questa tipologia di costrutti sintattici è generata a partire da un cluster di
movimento.
Soggetto Verbo Provenienza Destinazione Mezzo Durata, Inizio e Fine Buddies
Luca and I moved from home to my office by car for one hour, from 08:27 to 09:28,
and there I met Antonio.
Figura 6.2.4 Situazione di movimento
È utile elencare le caratteristiche principali dei blocchi che compongono le frasi di un
blog post:
Verbi
Per scegliere il verbo associato ad un cluster occorre analizzare due diversi
fattori: il movimento e la possibile presenza di Virtual Place impostati dagli utenti.
- Presenza di movimento: in una situazione dinamica è necessario un verbo
che descriva il tipo di movimento dell’utente. Si utilizza il predicato generico
move. Se il cluster ha un Virtual Place Bluetooth (che, nelle situazioni di
movimento identifica il mezzo di trasporto utilizzato) sarebbe però possibile
utilizzare altri verbi più specifici. Ad esempio per un’automobile si potrebbe
utilizzare drive. Non è purtroppo possibile capire se l’utente sta veramente
guidando oppure è un passeggero. Per non creare una frase semanticamente
errata, occorre utilizzare sempre il verbo più generico possibile (move). Per
specificare il mezzo di trasporto si utilizza un complemento indiretto ad hoc.
- Virtual Place: se non è presente un VP, si utilizza il verbo generico stay. Se
invece un cluster statico possiede un VP occorre analizzarne il Place Type.
Ogni luogo virtuale appartiene infatti ad una categoria ben precisa, come
specificato in RFC 4480 [7] (Capitolo 5.2). Ad ogni tipo di VP è associato un
verbo diverso, corrispondente all’azione più probabile compiuta dall’utente in
quel luogo (Figura 6.2.5).
55
airport
bar
cafe
office
hotel
shopping-area
default
...
wait
enjoy
relax
work
rest
shop
stay
...
Figura 6.2.5 Alcune associazioni tra PlaceType (RFC 4480) e verbi
I Virtual Place permettono quindi di generare blog entry più accurate: la
partecipazione dell’utente è dunque molto importante per migliorare la
qualità e la gradevolezza del testo generato. Inoltre, come possibile
estensione futura, si è pensato di permettere agli utenti di abbinare un verbo
personalizzato ad ogni tipologia di Virtual Place.
Buddies
Se l’utente ha incontrato altre persone registrate nella piattaforma, è necessario
introdurre un complemento di compagnia. I cluster contengono infatti le informazioni
relative ai buddies (Capitolo 5.2). Ai fini di migliorare l’accuratezza del testo, occorre
verificare la frequenza con cui un altro utente appare nel cluster. Se un buddy è presente
solo per una piccola percentuale di tempo, significa che si tratta di un semplice incontro.
Una percentuale molto alta dimostra invece che la persona ha partecipato in modo
prolungato all’azione. Occorre quindi differenziare queste due situazioni con costrutti
sintattici diversi:
- Frequenza bassa: si appende una frase subordinata con l’elenco delle
persone incontrate durante l’azione (“… and I met Luca, Oscar and Walter”).
- Frequenza alta: le persone che hanno partecipato per molto tempo all’azione
sono aggiunte nel soggetto della frase (“Luca, Oscar, Walter and I worked in
my office for 8 hours.”).
Viene spontaneo impostare la soglia di frequenza su valori molto elevati (ad
esempio, 90%). Durante la fase di testing del software questa assunzione è stata però
smentita. Il ricordo che le persone hanno della loro giornata è tale per cui, affinché un
altro utente sia considerato come protagonista dell’azione è sufficiente che superi soglie
molto più basse. Numerosi tentativi in varie situazioni hanno portato a scegliere 60%
come valore di default (questa percentuale è comunque personalizzabile dall’utente).
Supponiamo, ad esempio, di aver lavorato nel proprio ufficio per tutta la giornata, ma di
essere stati in compagnia del collega Alberto solo durante la mattina. L’azione sarà
ovviamente modellata da un unico cluster. La presenza di Alberto nel cluster non
arriverà certo a valori dell’80-90%, ma sarà decisamente inferiore. Quindi, nonostante
sia lecito affermare “Oggi ho incontrato Alberto”, è decisamente più vicino ai ricordi
dell’utente affermare “Oggi io e Alberto abbiamo lavorato insieme”.
56
Per quanto riguarda le persone incontrate per un breve periodo, si è invece scelto di
non impostare una soglia minima di presenza: se un cluster contiene una persona che è
stata nei paraggi per una sola entry di contesto, significa che questo individuo si è
trovato comunque nelle vicinanze dell’utente, ed è quindi corretto segnalarlo nel blog
post, per aderire in modo più fedele ai ricordi della persona.
Come descritto meglio nel capitolo 6.5, la piattaforma CA fornisce anche il tipo di
relazioni che intercorrono tra gli utenti della piattaforma (amici, colleghi, parenti,
ecc…). Grazie a queste informazioni sarà possibile, in un’estensione futura, pubblicare
nel blog post solo le categorie di buddies selezionate dall’utente (Capitolo 6.5).
Complemento di Tempo
È possibile aggiungere alla frase anche la durata e l’ora d’inizio e di fine dell’azione.
Per quanto riguarda la durata, si genera una locuzione temporale in linguaggio naturale
a partire dai timestamp del cluster (“for a few minutes”, “for half an hour”, “for 4 hours
and a half ”, ecc…).
Complemento di luogo
Le frasi contengono ovviamente anche delle informazioni sul luogo in cui l’azione si
è svolta. Se è impostato un Virtual Place, verrà visualizzato il suo nome, altrimenti si
ripiega sull’indirizzo civico del centro del cluster (Capitolo 5.2). I cluster di movimento
hanno ovviamente informazioni sia sul luogo di partenza che su quello di arrivo. Per
maggiori dettagli si rimanda al Capitolo 6.5
Complemento oggetto
Alcuni Virtual Place permettono di risalire quasi senza ambiguità all’azione
compiuta. Ad esempio, se un utente è stato in una meeting room per tutta la durata del
cluster, è altamente probabile che abbia partecipato ad una riunione. Per rendere il testo
più vario e naturale, è possibile, utilizzando ovviamente un verbo transitivo, aggiungere
alla frase un complemento oggetto, a cui viene associato anche un aggettivo di durata
temporale. Ad esempio, invece della frase “I stayed in meetingroom B for 4 hours with
Carlo and Walter” è possibile abbinare alla tipologia del VirtualPlace (meetingroom) il
complemento oggetto che corrisponde alla situazione in cui si è trovato l’utente (in
questo caso, una riunione). La frase creata diventa quindi “I had a four hour meeting in
meeting room B with Carlo and Walter.”
Complemento di Mezzo
I cluster di movimento possono contenere un Virtual Place Bluetooth, che identifica
il mezzo di trasporto. Anche in questo caso, grazie ai place type elencati in [7] è
possibile discriminare tra il tipo di veicolo utilizzato. Le frasi create saranno quindi
accompagnate dalla locuzione “by car” oppure “by bus”, ecc…
57
6.3
Personalizzare il testo
Il testo che descrive la giornata può essere generato con diversi livelli di dettaglio. È
possibile infatti creare blog post omettendo il nome delle persone incontrate.
La piattaforma CA permette inoltre di conoscere la relazione che l’utente del blog ha
con queste persone: grazie a queste informazioni sarebbe possibile visualizzare nel blog
post solo gli utenti della piattaforma che possiedono una determinata relazione con il
possessore del blog (Capitolo 6.5) (questa caratteristica sarà una delle future estensioni
del generatore di blog). Si può anche scegliere un valore a piacere per la soglia che
determina se abbiamo compiuto un’azione con un utente oppure no (Capitolo 6.2). Si
possono inoltre non pubblicare informazioni temporali (durata, ora d’inizio e di fine).
Un discorso analogo vale per i contenuti multimediali (Capitolo 6.6), che possono
quindi essere inclusi o meno nel blog post.
L’utente può inoltre decidere se arricchire i suoi post con l’utilizzo di Microformats
(Capitolo 6.5) oppure è possibile creare un testo semplice, senza informazioni
semantiche aggiuntive.
In Figura 6.3.1 si presenta la stesso blog post generato con diversi livelli di dettaglio.
Today I stayed at home until 08:00. I moved from home to tilab
for one hour from 08:07 to 09:07. Oscar Rodriguez, Cristina Fra
and I worked at tilab for 8 hours and a half from 09:08 to
17:31, and there we met Walter Goix and Marco Test. I moved
from tilab to Piazza Vittorio Veneto in Pinerolo, TO for one
hour from 17:37 to 18:38. I stayed in Piazza Vittorio Veneto in
Pinerolo, TO for one hour from 18:44 to 19:43. I stayed at home
from 20:04.
Today I stayed at home. I moved from home to tilab. I worked at
tilab. I moved from tilab to Piazza Vittorio Veneto in
Pinerolo, TO. I stayed in Piazza Vittorio Veneto in Pinerolo,
TO. I stayed at home.
Figura 6.3.1 Blog post creato con livelli di dettaglio diversi
58
6.4
Natural Language Generation
Dopo aver descritto i blocchi logici delle frasi corrispondenti ai cluster di contesto e
le relative informazioni da visualizzare (Capitolo 6.2), occorre creare le frasi in
linguaggio naturale. È ovviamente possibile seguire un approccio “tradizionale”: dopo
aver creato i blocchi di testo corrispondenti a soggetto, verbo e complementi, si procede
con la loro concatenazione per creare le frasi da pubblicare nel blog post. Questa strada
prevede però la gestione manuale di tutti i problemi connessi con la realizzazione di un
testo in linguaggio naturale, come la corretta divisione in paragrafi, la punteggiatura o la
gestione delle liste di sostantivi.
La creazione di un testo naturale può essere invece demandata ad un generatore di
linguaggio naturale.
Natural Language Generator, architettura generale.
Un NLG è un software in grado di creare del testo naturale a partire da una
rappresentazione non linguistica [8]. Tipicamente un sistema NLG è composto da tre
componenti, che operano in cascata (Figura 6.4.1) [8].
Figura 6.4.1 Architettura tipica di un NLG
-
-
Document planner: decide quali informazioni appaiono nel testo finale in
base all’obiettivo richiesto dagli utenti. In questo passo si definisce inoltre
l’ordine delle parti del discorso all’interno del testo.
Microplanner: in questo step si decide quali parole e quali strutture
sintattiche devono essere utilizzate per esprimere il contenuto. Si sceglie
59
inoltre in che forma devono apparire alcune entità del testo (ad esempio, il
formato delle date). Infine, grazie ad una procedura di aggregazione si decide
come mappare le informazioni su frasi e paragrafi.
- Surface Realiser: si occupa della realizzazione linguistica, ovvero la
conversione di entità fino a questo momento astratte in testo. Si effettua
inoltre una realizzazione della struttura del testo. Questa fase prevede la
conversione di frasi e paragrafi astratti in punteggiatura. Viene così
completata la costruzione sintattica del testo finale.
Il generatore di blog necessita esclusivamente delle funzionalità di surface realising.
I passi precedenti esulano dall’obiettivo dell’applicazione.
SimpleNLG
Tra i molti generatori disponibili in rete [9], la scelta è ricaduta su SimpleNLG [10].
Si tratta di un realiser di una grammatica inglese relativamente ristretta [10],
implementato come libreria Java. È in grado di effettuare realizzazioni linguistiche e
strutturali. È stato specificatamente creato per applicazioni che richiedono una
conversione dei propri dati in testo naturale.
SimpleNLG non sceglie i termini da utilizzare nel testo. Si occupa però della
creazione di frasi grammaticalmente corrette, utilizzando le parole scelte dagli altri
moduli del generatore di blog (Capitolo 6.2). SimpleNLG solleva il programmatore
dalla gestione delle operazioni più ripetitive che coinvolgono la generazione del
linguaggio naturale come, ad esempio:
- Ortografia: inserisce gli spazi giusti tra frasi e paragrafi. Gestisce
correttamente la punteggiatura (es: “I stayed in Washington D.C.” invece di
“I stayed in Washington D.C..”). Si occupa inoltre di formattare
correttamente le liste (“Marco, Giuseppe, and Diego.”).
- Morfologia: coniuga i verbi al tempo desiderato, gestendo i verbi irregolari.
Utilizza la forma del verbo corretta in base alla persona del soggetto.
- Grammatica: permette di concatenare automaticamente in modo corretto i
blocchi logici contenenti i termini definiti dall’utente (che, in questo caso, si
tratta del generatore di blog).
Per generare del testo naturale, SimpleNLG mette a disposizione delle classi che
modellano:
- Paragrafi
- Frasi
- Verbi
- Complementi diretti e soggetti
- Complementi indiretti
60
Creare il testo
Dopo aver costruito in memoria la struttura logica del testo, si può procedere con la
procedura di realizzazione, che permette di creare il testo naturale in forma di stringa.
Ogni cluster viene così trasformato in una frase, composta dai blocchi visti al
Capitolo 6.2. I blocchi logici sono utilizzati da SimpleNLG per costruire la struttura
delle frasi in memoria. I costrutti sono successivamente concatenati tra loro, formando
in questo modo il paragrafo desiderato. La procedura per la creazione del testo è
riassunta in forma grafica in Figura 6.4.2, mentre in Figura 6.4.3 si presenta un esempio
di output.
Verbo
Soggetto
Complementi
Avverbi
Verbo
Soggetto
Complementi
Avverbi
Frase
Frase
Paragrafo
Realiser
..........
..........
Strutture dati
del sistema NLG
in memoria
_____
_____
_____
_____
_____
Testo
Naturale
NLG
Figura 6.4.2 La generazione del blog post. Il box grigio evidenzia le strutture dati che il sistema NLG
costruisce in memoria prima di realizzare la stringa di testo naturale.
Today Oscar Rodriguez and I worked at TILab until 18:18, and
there we met Elio Paschetta, Walter Goix and Marco Marengo. I
moved from TILab to Sumi's for one hour from 18:21 to 19:20.
I stayed at Sumi's for 3 hours and a half from 19:23 to
23:06. I stayed at home from 23:07.
Figura 6.4.3 Il testo di un blog post di esempio
L’utilizzo di un sistema NLG richiede un carico elaborativo maggiore rispetto alla
semplice concatenazione di stringhe. Il ritardo introdotto è però tale da non influenzare
le prestazioni complessive del generatore di blog (il cui collo di bottiglia consiste nella
fase di acquisizione dei dati di contesto dalla piattaforma CA, Capitolo 5.2).
61
6.5
Il blog strutturato: Microformats
Il problema della semantica
Uno degli aspetti più significativi della ricerca applicata al Web, consiste
nell’introdurre delle tecniche per standardizzare il modo in cui alcune categorie di
informazioni vengono pubblicate nel codice (X)HTML (posizioni geografiche, indirizzi,
dettagli su persone, eventi, ecc…).
L’imponente mole di documenti presente sul web è infatti composta per la maggior
parte da pagine HTML [11]: queste informazioni vengono indicizzate già da molti anni
dai motori di ricerca tradizionali. I dati su cui questi software lavorano e l’output
prodotto sono però “piatti”: è consuetudine effettuare delle ricerche sul web in base a
semplici parole chiave, ma la rapida crescita delle dimensioni del web stesso e la
necessità di perfezionare i risultati delle ricerche, stanno spingendo la ricerca a pensare
a nuove tecniche per aiutare i software a trovare le informazioni desiderate in base al
significato semantico. A differenza degli esseri umani, il software non è però molto
abile a comprendere la semantica di un testo scritto (parsificare il linguaggio naturale è
un’operazione molto complessa, e poco scalabile sulle dimensioni sempre maggiori del
web). Per permettere un processing automatico più efficiente di una pagina web,
occorre quindi pensare a delle tecniche per standardizzare il modo in cui vengono
presentate le informazioni.
I Microformats: definizione
I microformats sono uno dei possibili approcci per risolvere il problema di creare
pagine web con markup semantico [11].
In [12], si trova una definizione di Microformats: “un set di semplici standard di
formati dati […] creati per migliorare la pubblicazione di blog strutturati e di altri
microcontenuti in generale.”.
Uno dei principi guida nella definizione dei Microformats è il concetto di riuso di
tecnologie già esistenti (ad esempio alcuni microformati si basano sullo standard
vCard). Il principio del riuso è evidente se si analizzano le tecnologie su cui i
Microformats sono basati. A livello tecnico infatti, un Microformat altro non è che un
riutilizzo di elementi e di attributi XHTML (ad esempio <div> o <span>), con alcuni
valori ben definiti di attributo class.
Si è pensato inoltre ad un approccio che risolvesse il problema del markup semantico
senza stravolgere non solo il contenuto del web, ma anche l’architettura dei browser sul
mercato. Un altro aspetto da tenere in considerazione, è il fatto che gli sviluppatori,
nell’adottare i microformats, possono riutilizzare le loro conoscenze.
62
Inoltre, grazie ai microformats, i programmi sono in grado di estrarre informazioni
dal testo XHTML, garantendo comunque un’alta comprensibilità da parte delle persone
che leggono.
Un programma capace di parsificare del codice XHTML contenente dei
Microformats è così in grado di estrarre i dati con markup semantico contenuti nella
pagina stessa. Ad esempio, un parser adeguato potrà riconoscere che un Microformat di
tipo adr contiene un indirizzo civico. Potrà così utilizzare questa informazione per i
propri scopi (ad esempio, visualizzare l’indirizzo su una mappa).
Esistono molti tipi di Microformats. Fondamentalmente si differenziano tra
Elemental Microformats, composti cioè da un unico elemento XHTML e compound
microformats, che comprendono invece più di un elemento [12].
Figura 6.5.1 Tipi di Microformat [12]
Più avanti nel capitolo si analizzeranno i Microformats utilizzati dal Blog
Contestualizzato.
I vantaggi dei Microformats
Creare un testo XHTML arricchito dall’uso di Microformats porta quindi molti
vantaggi [11]:
- Un formato standard per la rappresentazione facilita la scalabilità ai software
di indicizzazione distribuiti, e permette un parsing con un significato
semantico aggiunto.
- Il codice delle pagine web diventa più uniforme e standardizzato, in quanto
non sarà più necessario definire classi personalizzate per elementi come
indirizzi, contatti, recensioni, ecc…
- E’ possibile permettere una nuova interoperabilità tra applicazioni Desktop e
contenuto web-based. Ad esempio, grazie al Microformat hCard, è possibile
esportare informazioni sui contatti pubblicati in una pagina web direttamente
nei programmi di gestione delle rubriche e posta elettronica (es: MS
Outlook).
63
Come descritto successivamente, quest’ultimo aspetto è senza dubbio il più
importante per quanto riguarda l’introduzione dei Microformats nel blog
contestualizzato.
Il blog contestualizzato e i Microformats
Il blog contestualizzato fa uso di Microformats per il markup di luoghi (indirizzi
civici oppure Virtual Place) e di persone. Si utilizzano i Microformats adr, hCard, e
XFN.
Markup di luoghi: adr Microformat
In HTML non esiste un modo standard per marcare un indirizzo. Se intendiamo
attribuire un significato semantico a indirizzi civici, occorre quindi utilizzare il
Microformat composto adr. Rispettando la filosofia del riuso di standard preesistenti,
adr fa uso delle specifiche del formato vCard relative agli indirizzi (Figura 6.5.2) [11]:
Figura 6.5.2 I campi del formato vCard relativi a all'indirizzo civico [11].
Questo formalismo viene mappato in HTML dal microformat adr. Non è importante
il tipo degli elementi utilizzati (per i microformats composti si può utilizzare
indifferentemente <div> o <span>) ma, affinchè il microformat sia parsificato
correttamente, è fondamentale che gli attributi class si attengano ai valori definiti
nello standard vCard. L’elemento root deve inoltre essere di classe “adr” (Figura 6.5.3).
<div class="adr">
<div class="street-address">2560 Ninth Street </div>
<div class="extended-address">Suite 219</div>
<span class="locality">Berkeley</span>,
<span class="region">CA</span>
<span class="postal-code">94710</span>
<div class="country-name">USA</div>
</div>
Figura 6.5.3 adr Microformat
Il blog contestualizzato utilizza adr sia per marcare gli indirizzi civici dei luoghi non
etichettati da Virtual Place, sia per i VP stessi. Tra un elemento e l’altro di un
MicroFormat composto è infatti possibile aggiungere del testo, come il place name del
Virtual Place (Figura 6.5.4 a). adr non permette infatti di definire la tipologia di un
64
luogo. Come spiegato in seguito, l’utilizzo di un parser di Microformats, permette, ad
esempio, di individuare facilmente questi luoghi su una mappa, sfruttando, grazie ad un
opportuno software, le API di Google Maps.
Grazie all’utilizzo di un opportuno CSS (Figura 6.5.4 b), è possibile formattare a
piacimento il contenuto di un MicroFormat, garantendo la piena separazione tra la
struttura dei dati e il codice necessario per la visualizzazione. Nel caso dei Virtual Place
(Figura 6.5.4), sarà necessario formattare il Microformat adr in modo da nascondere le
informazioni aggiuntive, per non appesantire il testo prodotto (Figura 6.5.4 c).
<span class="adr">TILab
<span class="street-address">
Via Guglielmo Reiss Romoli 239</span>
<span class="locality">Torino</span>
<span class="country-name">Italy</span>
</span>
(a)
span.street-address{
display: none;
}
span.locality{
display: none;
}
span.country-name{
display: none;
}
TILab
(b)
(c)
Figura 6.5.4 Un Virtual Place marcato con un Microformat adr(a), il CSS associato (b) e la sua
visualizzazione nel testo (c)
Markup di contatti e relazioni: hCard
Il microformat composto hCard riutilizza il formalismo dello standard vCard,
utilizzato per scambiare informazioni sui contatti in rubrica [11]. L’attributo class
dell’elemento root del Microformat deve avere il valore “vcard” e i nomi delle classi
degli elementi figli devono rispettare lo standard vCard (Figura 6.5.5 a).
65
<div class="vcard">
<div class="fn">Mario Rossi</div>
<div class="org">Societa’ di esempio</div>
<div class="tel">011-546829</div>
<a class="url"
href="http://ca.tilab.com/blog/mrossi">Myblog</a>
</div>
(a)
div.org{
display: none;
}
div.tel{
display: none;
}
a.url{
display: none;
}
Mario Rossi
(c)
(b)
Figura 6.5.5 hCard Microformat (a), CSS associato (b) e visualizzazione nel testo del blog post (c).
Come descritto in precedenza (Capitolo 6.2), nel blog post di un utente possono
apparire i nomi delle altre persone registrate nella piattaforma e incontrate durante la
giornata.
L’utilizzo del microformat hCard, permette di fruire di tutte le altre informazioni del
profilo utente che la piattaforma CA mette a disposizione attraverso l’Advanced User
Profile (Capitolo 4.4). Oltre al nome e cognome, il generatore di blog possiede infatti
molte altre informazioni sugli utenti, come, ad esempio, il telefono, l’indirizzo email e
l’URL personale di ogni buddy incontrato. Queste informazioni sono “annegate” nel
blog post attraverso l’uso di un apposito CSS (Figura 6.5.5 b), come già fatto nel caso
del MicroFormat adr per non rendere la lettura del blog post difficoltosa. Queste
informazioni non visibili rispettano però la sintassi di hCard: un parser di Microformat
sarà in grado di catturarle e permetterà ai visitatori della pagina di fruirne in molti modi.
Sarà ad esempio possibile, in modo intuitivo e rapido, esportare i contatti presenti nel
blog verso applicazioni di gestione rubrica, come Outlook.
Markup per le relazioni tra utenti: XFN
XHTML Friends Network (XFN) è stato il primo Microformat ad essere sviluppato. Il
suo utilizzo permette di creare una social network, ovvero una rete di link che non solo
collega individui, ma che specifica anche le relazioni umane tra gli utenti. Grazie ad XFN
è infatti possibile descrivere in che modo si è legati alla persona puntata dal link (Figura
6.5.6).
<a href="http://blog.com/wasvel" rel="colleague met">Walter</a>
Figura 6.5.6 XFN Microformat
66
è un Microformat molto semplice: consiste in un set ridotto di valori ammessi
per il tag rel dell’elemento HTML <a> . Alcune possibili relazioni tra utenti sono
friend, colleague, neighbor, parent, met ( cioè qualcuno che abbiamo incontrato), ecc…
(per un elenco completo si rimanda a [11]). E’ possibile assegnare più valori di
relazione nello stesso attributo rel.
La piattaforma CA, attraverso lo User Proximity Provider (UPP) (Capitolo 4.5)
permette di ottenere, oltre allo username e al nome completo, anche la relazione con
tutti i buddy incontrati in un cluster (Capitolo 5.2). Questa informazione viene utilizzata
per costruire una social network che lega tra loro gli utenti del servizio di blog
contestualizzato. Inoltre, la conoscenza delle relazioni tra utenti può dare la possibilità
al generatore di filtrare la lista dei buddies. Per personalizzare ulteriormente i blog post
si potrebbero infatti pubblicare soltanto gli utenti met, oppure solo i colleagues.
Ogni utente presente in un cluster viene pubblicato nel blog post sottoforma di
elemento <a>. Il link punta all’URL del blog contestualizzato del buddy, mentre
l’attributo rel è quello ricavato dalla piattaforma CA (Figura 6.5.6).
Fino a questo punto abbiamo considerato i due Microformat legati alle persone,
hCard e XFN, come entità separate. Nulla vieta però di integrare i due costrutti: il blog
contestualizzato presenta le informazioni relative agli altri utenti della piattaforma
proprio in questo modo (Figura 6.5.7). Questo modo compatto di rappresentare i dati sui
buddy dimostra la flessibilità e le potenzialità del markup semantico basato su
microformat. Anche in questo caso, i Microformat sono formattati grazie alle
informazioni contenute nel foglio di stile (Figura 6.5.5).
XFN
<a href=" http://ca.tilab.com/blog/mrossi " rel="colleague">
<span class="vcard">
<span class="fn">Mario Rossi</span>
<span class="org">Societa’ di esempio</span>
<span class="tel">011-546829</span>
<a class="url" href="http://ca.tilab.com/blog/mrossi">MyBlog</a>
</span>
</a>
Figura 6.5.7 Una combinazione di XFN e hCard
Strumenti per il parsing
I più importanti browser presenti tutt’ora sul mercato (Internet Explorer, FireFox,
Opera, Safari, ecc…) non offrono ancora nativamente la possibilità di parsificare le
pagine web per trovare e utilizzare i Microformat.
Per parsificare una pagina che contiene microformati è però possibile utilizzare i
seguenti tool [13]:
- Operator: è un’estensione per Firefox 2. Si installa sottoforma di barra
aggiuntiva nell’interfaccia del browser. Tramite un opportuno parsing,
permette di individuare e localizzare i microformat di molti tipi all’interno
67
della pagina visualizzata. I formati supportati sono, per il momento adr,
hCard, hCalendar, geo, tag, xFolk ed RDF. Per ogni microformat è inoltre
possibile eseguire delle azioni: ad esempio, i microformat hCard possono
essere esportati su Outlook, mentre gli adr possono essere localizzati sulle
Mappe di Google o di Yahoo. E’ inoltre possibile personalizzare il menù
delle azioni, scrivendo degli handler personalizzati per poter eseguire altre
operazioni che coinvolgono i dati racchiusi nei microformat (Figura 6.5.8).
Figura 6.5.8 Uno screenshot della barra di Operator
-
Tails: è un’altra estensione di Firefox 2. E’meno ricco di funzioni di
Operator, ma permette comunque di esportare gli hCard e gli adr (che, si
ricorda, sono entrambi basati sullo standard vCard).
- XFN Dumper: è un bookmarklet in grado di effettuare il parsing della pagina
per cercare ed evidenziare Microformat XFN.
Si segnala inoltre che la tecnologia di parsing alla base di Operator potrebbe essere
utilizzata in modo nativo dalla prossima versione di Firefox (3.0) [13].
68
6.6
Integrare elementi multimediali: TeamLife Portal
Il generatore di blog contestualizzato si occupa anche di integrare il testo dei blog
post con le immagini e i filmati che l’utente ha creato utilizzando il proprio dispositivo
mobile durante la giornata. Questi contenuti non sono pubblicati a caso, ma sono
abbinati alla frase corretta, e quindi al periodo giusto della giornata (cluster) in cui sono
stati catturati. Per ottenere questo risultato, è ovviamente necessaria una procedura per
prelevare i contenuti multimediali degli utenti. Per risolvere questo problema, il
generatore di blog si interfaccia con un’altra applicazione fornita dalla piattaforma CA:
il Portale Teamlife [23].
TeamLife Media Sharing Content Management System
Si tratta di un CMS che permette agli utenti della piattaforma CA di condividere i
propri contenuti (multimediali e non).
In particolare, il servizio è caratterizzato da una forte integrazione con il client
TeamLife in esecuzione sui device mobili. Come anticipato nel Capitolo 4.5 questo
software, oltre ad effettuare periodicamente update di contesto verso la piattaforma, si
occupa anche di gestire l’upload di foto e video verso il portale. In questo modo, gli
utenti registrati al servizio (Capitolo 4.4), se lo desiderano, possono direttamente
pubblicare i contenuti multimediali catturati col proprio device sul portale, per
permetterne la condivisione con gli altri utenti registrati. È comunque presente un
sistema di controllo di accesso, che dà libertà ad ogni utente di impostare la visibilità
desiderata ad ogni file caricato sulla piattaforma (pubblica, friends only, privata, ecc…).
Ad ogni file caricato sul portale, vengono associate delle informazioni: timestamp di
upload, ora di acquisizione per le immagini JPEG, modello di device che ha scattato una
foto, risoluzione, ecc…
Ciò che differenzia TeamLife Portal da servizi analoghi già presenti sul mercato (ad
esempio Flickr), è però l’utilizzo delle informazioni di contesto messe a disposizione
dalla piattaforma CA. Al momento dell’upload di un contenuto, il client invia infatti al
portale anche tutte le informazioni che descrivono il contesto dell’utente nell’istante in
cui ha scattato la foto oppure ha catturato un filmato (Capitolo 3.2). I contenuti
multimediali sono così arricchiti da molte informazioni di contesto, in modo
completamente automatico: non è più necessario che l’utente intervenga, anche se è
comunque sempre possibile aggiungere tag personalizzati. Le informazioni di contesto
aggiunte automaticamente dall’applicazione sono, ad esempio, l’indirizzo civico in cui
la foto è stata scattata, oppure i buddy nelle vicinanze. (Figura 6.6.1).
69
Figura 6.6.1 TeamLife Portal: dettagli di un immagine con tag di contesto
I dati di contesto sono assegnati ad un contenuto multimediale nella forma di tag.
Una foto, ad esempio, sarà etichettata automaticamente con l’indirizzo, il nome della
città e la provincia in cui è stata scattata. Se la foto è stata presa in un Virtual Place
definito dall’utente (Capitolo 5.2), verranno aggiunti come tag anche il place type e il
place name (ad esempio, “office, TILab”). Le immagini sul portale sono inoltre
etichettate con i nomi degli altri utenti della piattaforma che si trovavano nei paraggi.
(Figura 6.6.1) .
Il portale offre inoltre una procedura di ricerca basata sui tag: in questo modo è
possibile, in modo rapido ed intuitivo, trovare altri file a cui sono associate le stesse
etichette. È così possibile utilizzare le informazioni di contesto per trovare i contenuti
che ci interessano. Ad esempio, è possibile trovare tutte le foto scattate in un Virtual
Place da un certo utente, oppure si possono ottenere tutti i filmati girati presso un
indirizzo in un preciso periodo di tempo, ecc… Inoltre, se un utente effettua il login nel
portale TeamLife, potrà fruire di una delle funzioni più significative del CMS, cioè la
possibilità di visualizzare tutti i contenuti catturati nello stesso contesto in cui l’utente si
trova nell’istante stesso in cui sta visualizzando la pagina web.
Per maggiori informazioni sul Portale Teamlife si rimanda a [23].
70
Utilizzare i contenuti TeamLife per il blogging
Teamlife Portal permette di fruire dei contenuti pubblicati, non solo attraverso
interfaccia web, ma offre anche la possibilità di ottenere le stesse informazioni
attraverso feed (RSS, ATOM, oppure in formato KML).
Il portale permette di creare feed molto flessibili: è infatti possibile filtrare i contenuti
in base al tempo (ad esempio, è possibile visualizzare solo le foto caricate negli ultimi
giorni), oppure in base all’utente che li ha creati. In generale, si può filtrare il contenuto
di un feed a partire da qualsiasi tag caricato sul portale (Figura 6.6.2): in questo modo si
può offrire un alto livello di flessibilità alle applicazioni esterne che utilizzano i feed,
come il blog contestualizzato.
http://ca.tilab.com/tl/rss.php?album=usertags&username=lukostaz&tag=Torino
Figura 6.6.2 Esempio di GET HTTP per creare un feed RSS (tutte le foto scattate a Torino dall’utente
lukostaz)
Il generatore di blog ha la necessità di ricavare le foto e i video creati dall’utente
durante la giornata precedente. Le caratteristiche offerte dai feed RSS soddisfano questo
problema. Per ogni utente, la procedura per integrare le immagini in un blog post segue
questi passi (Figura 6.6.3):
RSS
Parsing
Assegnazione ai
cluster
Creazione del
contenuto HTML
Blog Generator
Figura 6.6.3 Il processo di integrazione con le informazioni multimediali
-
Ottenere il feed: il blog generator richiede l’RSS desiderato a TeamLife,
attraverso una HTTP GET (Figura 6.6.4) . Il feed deve contenere tutte le
informazioni sui contenuti multimediali catturati dall’utente nella giornata
precedente.
71
http://ca.tilab.com/tl/rss.php?album=lastupby&username=wasvel&newer_than=1
Figura 6.6.4 Esempio di feed RSS utilizzato dal Blog Generator
-
-
-
RSS parsing: il generatore di blog parsifica il contenuto del feed per ricavare
i dati desiderati. Il feed contiene l’elenco dei contenuti della giornata per
l’utente. Per ogni immagine/video il Blog Generator ha bisogno delle
seguenti informazioni:
- URL della pagina TeamLife che presenta i dettagli della foto/video
(Figura 6.6.1)
- URL della thumbnail del file desiderato (la miniatura è creata
direttamente dal CMS)
- Titolo della foto/video
- Data e ora in cui l’immagine/video è stata creata. Per creare questa
informazione, TeamLife utilizza le informazioni EXIF per le
immagini JPG. Se questi dati non sono disponibili, si usa un
timestamp inviato dal client.
Il generatore di blog crea in memoria una lista di oggetti multimediali che
contengono le informazioni elencate in precedenza.
Assegnazione ai cluster: ogni oggetto multimediale viene associato al cluster
di contesto giusto. Il generatore di blog confronta la data e l’ora
dell’immagine con i timestamp di inizio e fine del cluster. L’oggetto verrà
associato al cluster se è stato catturato in questo lasso di tempo.
Creazione del contenuto HTML: in quest’ultima fase si effettua la
conversione in codice HTML degli oggetti multimediali. Il codice così creato
è aggiunto al blog post durante la generazione del testo naturale. Ogni
thumbnail è un link alla pagina del portale TeamLife con i dettagli
dell’immagine/video. Le immagini sono inoltre precedute da una frase
introduttiva (Figura 6.6.5).
72
<div><span>
<a href="http://ca.tilab.com/tl/displayimage.php?pos=-9265"><img src="
http://ca.tilab.com/tl/albums/userpics/10027/thumb_20071013T222553.jpg"
class="thumb" title="gibi" alt="gibi" /></a>
<a href="http://ca.tilab.com/tl/displayimage.php?pos=-9267"><img
src="http://ca.tilab.com/tl/albums/userpics/10027/thumb_20071013T230133.j
pg" class="thumb" title="Gibi trio" alt="Gibi trio" /></a>
<a href="http://ca.tilab.com/tl/displayimage.php?pos=-9262"><img
src="http://ca.tilab.com/tl/albums/userpics/10027/thumb_20071013T221410.j
pg" class="thumb" title="Gibitrio" alt="Gibitrio" /></a>
</span></div>
Figura 6.6.5 Un esempio di come gli elementi multimediali sono trasformati in codice HTML e
successivamente visualizzati nel blog post.
73
6.7
La piattaforma di Blogging: WordPress MU
Dopo aver creato il blog post (composto da testo e contenuti multimediali), occorre
pubblicare queste informazioni sul web. Il generatore di blog non si occupa di gestire la
presentazione dei contenuti. È stata presa la decisione di affidarsi ad una piattaforma di
blogging, un CMS creato ad hoc per gestire i blog di uno o più utenti. La scelta è
ricaduta su una delle piattaforme più diffuse sul mercato: Wordpress. In particolare, si è
scelta una variante che permette di gestire una community di blog, Wordpress Multi
User (mu). La scelta di affidarsi a questo prodotto è stata determinata da alcuni fattori,
elencati al punto successivo.
WordPress: caratteristiche generali
Wordpress [14] è una piattaforma di blogging scritta in linguaggio PHP e basata
sull’uso di un database MySQL. Si tratta di un software opensource, distribuito con
licenza GPL. Permette una gestione semplice ed efficiente dei propri blog post, che
vengono organizzati con una struttura a permalink. In questo modo, Wordpress
garantisce ai motori di ricerca la possibilità di indicizzare le proprie pagine.
E’ bene elencare alcune caratteristiche importanti di Wordpress:
- Installazione semplice
- Ambiente di esecuzione: è solito utilizzare la piattaforma in ambiente Linux,
utilizzando Apache come Web Server, MySQL come DB Manager e PHP
come linguaggio di scripting (l’ambiente è informalmente noto come LAMP).
- Licenza GPL
- Disponibilità di plugin e personalizzazione: il software ha la possibilità di
essere esteso. Esiste già un grande numero di plugin disponibili in rete. Sono
stati sviluppati inoltre molti theme, ed è possibile crearne ovviamente di
personalizzati.
- Community: Wordpress gode di una community di sviluppatori molto estesa;
il suo sviluppo è quindi costante e gli aggiornamenti sono frequenti.
- Documentazione: la piattaforma è documentata nel dettaglio sul sito web
ufficiale [14].
Gestire una community di utenti
Come già anticipato, le funzionalità di Wordpress sono orientate alla gestione di un
solo blog personale e non sono sufficienti per lavorare con una comunità di utenti, cosa
di cui invece abbiamo bisogno. E’ stata quindi scelta una versione di WordPress,
WordPress Multi User (mu), che, nonostante mantenga praticamente inalterato il modo
di gestione dei contenuti, il layout e le interfacce, permette di creare e mantenere una
community di blog in modo semplice ed efficace [15].
74
Pubblicare i contenuti
La piattaforma deve inoltre permettere la pubblicazione dei contenuti non solo
attraverso l’interfaccia web, ma anche tramite l’esposizione di opportune API.
WordPress offre un’interfaccia XML-RPC [16], che permette ad altre applicazioni di
pubblicare contenuti sulla piattaforma (Figura). XML-RPC è un protocollo molto
semplice basato sui concetti di remote procedure call, che codifica i dati in XML e
utilizza come trasporto il protocollo HTTP [16] (Figura 6.7.1).
Figura 6.7.1 Il protocollo XML-RPC [16]
Wordpress, attraverso lo script xmlrpc.php agisce da server ed espone le interfacce per
la pubblicazione dei blog post. Il generatore di blog implementa le funzionalità del
client: è stata utilizzata la libreria XML-RPC Client messa a disposizione da Apache
Software Foundation [17]. In Figura 6.7.2 si riporta il metodo utilizzato per pubblicare
il blog post su Wordpress, che, come si vede dal codice, necessita anche dei parametri
necessari per effettuare l’autenticazione dell’utente.
private XmlRpcClient client;
public Integer post(String contents) throws XmlRpcException {
Object[] params = new Object[] {
blogInfo.getBlogId(),
blogInfo.getUserName(),
blogInfo.getPassword(),
contents,
};
return (Integer) client.execute(POST_METHOD_NAME, params);
}
Figura 6.7.2 Metodo per pubblicare i contenuti attraverso chiamata XML-RPC
Wordpress e i Microformats
Un ultimo aspetto da considerare su WordPress, riguarda la pubblicazione di
Microformats nelle entry dei blog post. I contenuti postati sulla piattaforma (sia
75
attraverso interfaccia web, che tramite XML-RPC) sono infatti sottoposti a più
procedure di code sanitizing [14]. Nonostante esistano alcuni plugin creati per gestire
tematiche legate ai Microformats [14], nessuno di questi tiene in considerazione i post
pubblicati attraverso XML-RPC. Inoltre, non sono gestiti tutti i tipi di Microformat
utilizzati dal generatore di blog.
E’ stato dunque necessario editare gli script di Wordpress che si occupano di filtrare
il codice postato, per permettere, ad esempio, di pubblicare gli attributi class degli
elementi utilizzati per definire i Microformats (Capitolo 6.5).
6.8
Il blog post pubblicato
Dopo aver percorso tutta la catena di operazioni legate alla creazione del blog post, si
ottiene un risultato finale simile a quello in Figura 6.9.1. Per informazioni sul
VideoBlog si rimanda al Capitolo 7.
6.9
Implementazione
Il modulo di creazione dei blog post è implementato in codice Java. Fa uso delle
classi create per acquisire informazioni di contesto dalla piattaforma CA e per effettuare
il processo di clustering (Capitolo 5.8).
Il codice del prototipo del generatore di blog è eseguito ogni giorno ad un’ora
prestabilita. I post sono generati per tutti gli utenti registrati al servizio in modalità
batch. In attesa di estensioni future (Capitolo 9.3), si è deciso di schedulare l’esecuzione
del software alle ore 5:00 di ogni mattina. Il prototipo considera inoltre la stessa ora
come l’inizio di una nuova giornata per ogni utente. Ad ogni esecuzione, il generatore di
blog raccoglierà quindi le informazioni di contesto degli utenti fino alle ore 5:00 del
giorno precedente: questi dati saranno utilizzati per costruire il blog post vero e proprio.
La scelta delle ore 5:00 è sembrata la più ragionevole, in quanto precede di qualche ora
il momento del risveglio della maggior parte degli utenti e garantisce allo stesso tempo
l’assegnazione delle informazioni di contesto raccolte nelle prime ore della notte alla
giornata precedente. Le esperienze vissute dopo la mezzanotte, nonostante appartengano
ovviamente ad una nuova giornata, vengono percepite dalla maggior parte degli utenti
come parte della giornata precedente (ad esempio, una persona che esce con gli amici e
torna a casa alcune ore dopo la mezzanotte).
76
Figura 6.9.1 Esempio di pubblicazione di blog post
77
78
La creazione del VideoBlog
7
7.1
Architettura generale
Oltre alla realizzazione testuale (Capitolo 6), il generatore di blog offre la possibilità
di presentare i risultati ottenuti dalla fase di clustering (Capitolo 5) anche nella forma di
animazione video. L’idea di fondo è quella di creare un filmato simile ai titoli di testa di
un telegiornale, dove le azioni che l’utente ha compiuto durante la giornata vengono
presentate come delle notizie. Il video è ovviamente composto non solo dai dati di
contesto dell’utente, ma anche dai contenuti multimediali acquisiti durante la giornata:
anche in questo caso foto e video sono prelevate da TeamLife Portal [23].
Per creare l’animazione è stata utilizzata una libreria PHP open source, Ming [18], in
grado di generare output in formato Adobe Flash (Capitolo 7.3). È stato dunque
necessario pensare ad un modo per comunicare con il codice visto fin’ora (il generatore
di blog testuale è infatti implementato come applicazione J2SE, capitoli 5.8 e 6.9).
L’applicazione Java trasmette i dati necessari al videoblog utilizzando un API basata su
HTTP POST. Il trasferimento avviene con un formato XML definito ad hoc, il
VideoBlogML (Capitolo 7.2).
Gli script PHP generano così il video diario quotidiano dell’utente e lo mettono a
disposizione dei visitatori del blog (Capitoli 7.4 e 7.5).
Context
Cluster
HTTP
MING library
VideoBlogML
Cluster & Blog entry
Generator
Video Blog Generator
Flash
Video
Blogs
Figura 7.1.1 Generazione del VideoBlog: integrazione tra componenti
79
7.2
Il VideoBlogML
Le informazioni necessarie per la costruzione del videoblog, vengono trasmesse
dall’applicazione Java in codifica XML. È stato necessario definire uno schema su cui
validare il codice XML creato dal generatore di blog ed inviato agli script che creano il
video diario. I dati sono organizzati nei seguenti elementi (Figura 7.2.1):
-
userId
date
-
ctxClusters:
lista di Context Cluster
ctxCluster: è l’elemento che contiene le informazioni su un cluster di
contesto
- startTime: inizio del cluster
- stopTime: fine del cluster
- people: elenco dei nomi delle persone incontrate nel cluster. Nel videoblog
non si utilizzano, per il momento, altre informazioni sui buddies. Questo
aspetto potrebbe essere preso in considerazione negli sviluppi futuri
dell’applicazione.
- location: è presente solo nei cluster statici. Se si tratta di un Virtual Place,
conterrà sia il place type che il place name.
- locationFrom e locationTo: presenti al posto di location nel caso di
movimento
- moving: flag che segnala se il cluster è di movimento oppure no
- mediaElements: lista di mediaElement
- mediaElement: contiene informazioni su un contenuto multimediale
acquisito all’interno del cluster.
- pictureURL: è l’URL presso cui recuperare il contenuto multimediale
desiderato. Il link punta al CMS TeamLife Portal
- title: è il titolo della foto/video.
In Figura 7.2.2 si presenta un esempio di codice VideoBlogML.
80
Figura 7.2.1 Lo schema del VideoBlogML
81
<videoData
xmlns="http://ca.tilab.com/blog/videoblog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
ca.tilab.com/blog/videoblog http://ca.tilab.com/blog/videoblog/videoblog.xsd">
<userID>lukostaz</userID>
<date>29-09-2007</date>
<ctxClusters>
<ctxCluster moving="false">
<startTime>13:43</startTime>
<endTime>14:59</endTime>
<people></people>
<location>n/a;Borgata Azzari in San Germano Chisone, TO</location>
<mediaElements>
<mediaElement>
<pictureURL>
http://ca.tilab.com/tl/albums/userpics/10027/normal_20070929T165445.jpg
</pictureURL>
<title>Capitano70</title>
</mediaElement>
<mediaElement>
<pictureURL>
</pictureURL>
<title>Punizione contro</title>
</mediaElement>
</mediaElements>
</ctxCluster>
<ctxCluster moving="true">
<startTime>15:33</startTime>
<endTime>23:44</endTime>
<people></people>
<locationFrom>n/a;Borgata Azzari in San Germano Chisone, TO</locationFrom>
<locationTo>residence;home</locationTo>
<mediaElements>
<mediaElement>
<pictureURL>
</pictureURL>
<title>Il miglior bar di pinerolo</title>
</mediaElement>
<mediaElement>
<pictureURL>
http://ca.tilab.com/tl/albums/userpics/10027/20070929T184146.mp4
</pictureURL>
<title>E finisce 3-1 x noi!!</title>
</mediaElement>
<mediaElement>
<pictureURL>
</pictureURL>
<title>Che felicita' la borsa nuova!</title>
</mediaElement>
</mediaElements>
</ctxCluster>
</ctxClusters>
</videoData>
Figura 7.2.2 Un esempio di VideoBlogML
7.3
La Libreria MING
Ming è una libreria C, utilizzata per generare filmati Flash (SWF) [18]. Il progetto,
completamente open source e cross-platform, offre un set di wrapper non solo per C++,
ma anche per un buon numero di linguaggi di scripting, come PHP, Perl, Python e
Ruby. (a partire dalla versione 0.4 esistono in realtà anche dei wrapper Java, ma tramite
82
il loro utilizzo non è possibile effettuare alcune delle operazioni più sofisticate richieste
dal videoblog, Capitolo 7.4).
Il progetto Ming supporta quasi tutte le caratteristiche di Flash 4 [19]: forme,
sfumature, immagini importate (jpg e png), morphing di forme, testo, pulsanti, video
importati, aggiunta di audio in formato mp3. La libreria include inoltre un modulo in
grado di compilare un subset del linguaggio ActionScript.
Per realizzare il generatore di videoblog, è stata utilizzata la versione 0.4. A causa
delle limitazioni relative ai wrapper Java, è stato necessario lavorare con le estensioni
Ming compilate come libreria-modulo per l’interprete PHP in ambiente Linux-Apache
(Capitolo 7.1).
Un’animazione Flash creata con la libreria Ming è tipicamente composta dai seguenti
oggetti:
- SWFMovie: è la classe che modella l’intero filmato Flash. È il contenitore di
tutti gli altri elementi dell’animazione. A questo oggetto è associata la
timeline principale del video.
- SWFShape: è una classe che modella una forma geometrica.
- SWFText e SWFFont: rappresentano, rispettivamente, una stringa di testo
ed il font utilizzato per il rendering.
- SWFBitmap: è una classe utilizzata per importare e visualizzare immagini in
formato Jpeg.
- SWFPreBuiltClip permette di aggiungere ad un’animazione Flash un
altro filmato già compilato in formato swf.
- SWFButton e SWFAction: il primo è un pulsante cliccabile, mentre il
secondo è l’azione (in linguaggio ActionScript) da eseguire.
A titolo di esempio si riporta in figura il codice per creare una semplice animazione
contenente un quadrato [18].
83
// a red square...
// this sets the scale to a similar format as that used in flash
Ming_setScale(20);
// publish this movie for the flash 6 player
ming_useswfversion(6);
// create a movie, here we call it $movie
$movie=new SWFMovie();
// 550 by 400 is the default in flash
$movie->setDimension(550,400);
// background set to grey
$movie->setBackground(0xcc,0xcc,0xcc);
// frame rate of 12 is the default in flash
$movie->setRate(12);
// create a shape, here we call it $squareshape
$squareshape=new SWFShape();
// give it a red fill
$squareshape->setRightFill(255,0,0);
// draw that shape in a clockwise direction
$squareshape->drawLine(100,0); # draw the top line
$squareshape->drawLine(0,100); # draw the right line
$squareshape->drawLine(-100,0); # draw the bottom line
$squareshape->drawLine(0,-100); # draw the left line
// add $squareshape to the movie and create a reference
// to it called $squaresymbol so we can move it later
$squaresymbol=$movie->add($squareshape);
// now we can move $squareshape
$squaresymbol->moveTo(100,100);
// save $movie to disk, here we call it square.swf
$movie->save("square.swf");
Figura 7.3.1 Creare un quadrato con Ming [18]
7.4
Creare il Videoblog
La creazione vera e propria del videoblog attraversa alcune fasi. In questo capitolo
vedremo una descrizione generale dei passi che gli script devono compiere per ottenere
il risultato finale.
Dai Cluster di contesto al VideoBlogML
Il generatore di blog ha il compito di trasformare i context cluster di un utente in
codice XML, secondo lo schema descritto nel Capitolo 7.2. Queste informazioni
saranno successivamente inviate, tramite una POST HTTP, agli script PHP che
generano il filmato.
Parsing del VideoBlogML
La prima operazione che lo script PHP deve compiere è il parsing del VideoBlogML
ricevuto dal generatore di blog Java. Per effettuare questa operazione, sono state
utilizzate le estensioni SimpleXML di PHP [20]. Dopo aver effettuato il parsing, lo
script crea in memoria un array di oggetti ContextCluster. Questa classe contiene le
84
informazioni necessarie per trasformare un cluster in un’animazione contestualizzata:
Le istanze contengono infatti:
- Timestamp di inizio e fine del cluster
- Flag che indica se si tratta di un cluster di movimento
- Location (oppure, se è un cluster di movimento, si usano i campi
locationFrom e locationTo)
- Nomi delle persone incontrate durante il cluster
- Lista degli URL dei contenuti multimediali compresi in un cluster.
Setup del video e Creazione del Player
Dopo aver impostato frame rate e dimensioni dell’animazione, lo script si occupa
della creazione del corpo principale del VideoBlog che include anche la barra dei
controlli per il video (Figura 7.4.2).
I pulsanti sono creati a partire da un’immagine png, grazie al tool png2dbl offerto da
Ming [18]. Grazie al codice ActionScript associato ad ogni pulsante (Figura 7.4.1),
l’utente può controllare il flusso della riproduzione: non è quindi necessario utilizzare
player esterni, in quanto il filmato swf offre tutti i controlli necessari per la riproduzione
dei suoi contenuti.
$actionPause =
"_root.stop();
for(obj in _root){
if(typeof(_root[obj])=="movieclip"){
_root[obj].stop();
}
}";
$actionPlay =
"_root.play();
for(obj in _root){
if(typeof(_root[obj])=="movieclip"){
_root[obj].play();
}
}";
$buttonStop->addAction(new SWFAction($actionPause),
SWFBUTTON_MOUSEDOWN);
$buttonStart->addAction(new SWFAction($actionPlay),
SWFBUTTON_MOUSEDOWN);
Figura 7.4.1 Il codice associato ai pulsanti della barra di controllo
Trasformare un Cluster di contesto in video : panoramica generale
La realizzazione in video di un cluster di contesto è composta fondamentalmente da
due parti distinte (Figura 7.4.2):
85
Area
principale
Barra delle
informazioni
Figura 7.4.2 Visualizzazione di un cluster all'interno del videoblog. L’icona nell’area principale è
associata al Virtual Place di tipo “office”
-
-
Barra delle informazioni: l’area è utilizzata per visualizzare le informazioni
testuali relative al cluster visualizzato. Fanno parte di quest’area del video il
luogo in cui l’utente si è trovato (nel caso di un cluster di movimento
vengono visualizzati il posto di partenza e quello di arrivo), gli altri utenti
della piattaforma incontrati, e l’ora di inizio e di fine dell’azione.
Area principale: oltre allo slideshow di foto e filmati, l’area principale
dell’animazione viene utilizzata per visualizzare un’icona che sintetizza il
tipo di azione compiuta dall’utente durante il cluster. Il processo è analogo
con quanto accade per la scelta dei verbi del blog testuale (Capitolo 6.2): la
selezione dell’immagine avviene in base alla categoria del Virtual Place. Se
la posizione del cluster non è stata etichettata come tale, verrà visualizzata
un’icona di default.
SlideShow di immagini
Se un cluster di contesto contiene delle immagini, sarà compito del generatore di
videoblog visualizzare questi contenuti sottoforma di slideshow. Lo script, a valle
dell’operazione di parsing del VideoBlogML è a conoscenza dell’URL dell’immagine
da visualizzare (il collegamento punta ad un permalink offerto dal portale TeamLife
Media Sharing). Ogni immagine visualizzata (con relativo effetto di transizione) è
accompagnata dal proprio titolo (Figura 7.4.3). Tutti i contenuti acquisiti dall’utente
sono così presentati, anche in questo caso, all’interno del contesto in cui l’utente si
trovava.
86
Figura 7.4.3 Un'immagine all'interno dello slideshow
Il Video SlideShow
Analogamente a quanto accade per le immagini, i cluster del video blog possono
anche contenere uno slideshow dei filmati girati durante la giornata. Il processo per la
generazione di una sequenza di video e l’integrazione all’interno del flusso Flash è però
più complesso rispetto al caso delle fotografie, e si articola nei seguenti passaggi
(Figura 7.4.4):
HTTP GET
Audio
files
(mp3)
Temp files
(3gp, mp4)
Multiplexing
Video
files
(swf)
Video
files
(flv)
Concatenazione in
video
slideshow
Figura 7.4.4 Il processo di integrazione nel videoblog dei filmati girati dall’utente
-
Salvataggio dei video: lo script scarica i video dal portale Teamlife e li salva
in locale.
87
-
-
-
7.5
Integrazione nel videoblog: i filmati scaricati sono in formato di
compressione 3gp oppure mp4. La libreria Ming non permette l’integrazione
diretta di file in questi formati all’interno di un flusso video composto da
oggetti “sintetici” generati dalla libreria stessa (grafica, testo, ecc…). L’unica
strada da percorrere è dunque trasformare ogni video in un filmato swf
singolo (animazione flash compilata), da aggiungere successivamente al
videoblog. Questi flussi video sono temporanei e saranno cancellati al
termine della generazione del blog.
Conversione di formati audio/video: Ming permette di creare
un’animazione Flash (senza oggetti sintetici) a partire da un filmato. Il flusso
di partenza deve essere però Flash Video (flv), un formato proprietario
Adobe/Macromedia utilizzato per lo streaming in rete e basato sullo standard
H.263 (nelle versioni più recenti si utilizza H.264). Occorre quindi convertire
i video acquisiti da TeamLife in formato flv. Lo script utilizza il tool FFmpeg
[21]: il software permette la conversione nel formato desiderato. Le
limitazioni della libreria Ming impongono però una doppia conversione. A
partire dal video di partenza (3gp/mp4), occorre infatti creare sia un flusso
video (in formato flv) che un flusso audio mp3. A questo punto, lo script
effettuerà un multiplexing di questi file per creare il filmato in Flash video
compilato (swf)
Concatenazione dei filmati temporanei: a questo punto, i filmati swf creati
al punto precedente possono essere aggiunti al videoblog grazie all’oggetto
Ming SWFPreBuiltClip (Capitolo 7.3). Si ottiene quindi un vero e proprio
slideshow di filmati girati dall’utente. Questi contenuti, come nel caso delle
immagini, sono arricchiti dai loro titoli e dalle informazioni di contesto del
cluster in cui sono stati girati.
Pubblicare il VideoBlog
Una volta salvato su disco, il videoblog deve essere reso disponibile ai visitatori del
blog. Come anticipato al punto 7.1, la libreria Ming permette di effettuare streaming per
filmati convertiti in formato flv. Ming non offre però la possibilità di salvare le
animazioni che genera nello stesso formato (con la libreria è possibile esclusivamente
creare video in swf compilato). Questa limitazione impedisce di effettuare lo streaming
dei videoblog.
Occorre quindi offrire i contenuti video in forma di podcast. Il filmato, prima di
essere visto, deve essere quindi scaricato interamente dal browser del visitatore della
pagina web. È possibile inserire i video direttamente nei blog post, tramite l’utilizzo del
tag HTML <object>. Una soluzione simile sarebbe però poco scalabile. Tipicamente
88
Wordpress visualizza nella stessa pagina web molti blog post: se ognuno includesse il
proprio videoblog, il caricamento della pagina sarebbe troppo lento (i filmati possono
avere dimensioni non trascurabili).
Si è quindi deciso di inserire all’inizio di ogni post un semplice link verso il
videoblog corrispondente. In questo modo si dà la possibilità all’utente di fruire
dell’animazione Flash senza appesantire il caricamento della pagina in cui sono
pubblicati i post. Per visualizzare il video diario si utilizza un plugin di Wordpress,
Greybox [22]. Il plugin permette di visualizzare il videoblog in un popup modale,
implementato sotto forma di <div> e lanciato al click sul link presente in ogni blog
post (Figura 7.5.1).
Figura 7.5.1 Visualizzare il video all'interno di un blog post
89
90
Scenari abilitati
8
Scenari abilitati
Il generatore automatico di blog contestualizzato può essere adattato ad uno o più
scenari applicativi.
L’utilizzo tipico per cui il sistema è stato pensato ricade nel filone del personal
blogging. La creazione di un blog personale automatico, che contiene le azioni compiute
durante la giornata, arricchite da informazioni di contesto, permette ad ogni utente di
poter condividere le proprie esperienze con amici, parenti o colleghi. Un tipico scenario
applicativo di questo filone può essere il racconto di una vacanza. L’utente, in modo del
tutto trasparente, ottiene un blog personale con il racconto delle proprie esperienze
giorno per giorno. Video ed immagini sono presentati nel testo accompagnati dalle
relative informazioni di contesto. Anche il videoblog si rivela essere un’efficace forma
di presentazione dei contenuti personali: la propria vacanza viene raccontata con un
approccio simile ad un tg televisivo, in cui tutti gli elementi multimediali sono arricchiti
dalle informazioni sul contesto utente in cui sono stati acquisiti. Il video diario potrebbe
anche venire utilizzato come podcast, oppure come tg su una piattaforma di web tv. La
condivisione di un blog contestualizzato può essere uno scenario interessante anche
all’interno di una comunità di amici, interessati allo scambio di informazioni personali:
per un utente della piattaforma CA è possibile, ad esempio, visualizzare il blog di amici
o parenti lontani, per conoscere i luoghi in cui vivono e il loro stile di vita quotidiano.
Un altro campo di utilizzo importante è il supporto alla memoria umana. Possedere
un blog contestualizzato giornaliero significa ovviamente mantenere un log preciso
delle azioni compiute, arricchite dai contenuti multimediali acquisiti. A distanza di anni
(ma anche semplicemente dopo qualche mese) il blog può tornare molto utile per
ricordare eventi e situazioni del passato, descritte con il livello di dettaglio offerto dagli
algoritmi di clustering. Sottoscriversi al servizio di blog contestualizzato può quindi
prevedere anche la semplice fruizione personale dei contenuti, mantenendo quindi
privati i dati generati dal sistema. In questo filone si possono citare inoltre utilizzi legati
a campi professionali di nicchia, come la creazione di log per lavoratori che hanno
bisogno di funzionalità automatiche per tenere traccia del proprio lavoro. Ad esempio, il
generatore di blog potrebbe essere utile per descrivere la giornata lavorativa di un
agente rappresentante, di un reporter o di un capo cantiere o architetto.
Un servizio di blog contestualizzato esteso a molti utenti può inoltre permettere di
scoprire punti di interesse comuni con altri utilizzatori del servizio. Un pendolare può
91
Scenari abilitati
ad esempio scoprire (sempre ovviamente che entrambe le parti lo desiderino) che
un’altra persona segue lo stesso tragitto per andare al lavoro. Diventa così possibile
creare una community di utenti che condividono le proprie informazioni di contesto.
Un utilizzo interessante del servizio di blog è legato al profiling a posteriori degli
utenti. I diari giornalieri di un utente possono infatti essere utilizzati per il determinare il
profilo dell’utente. I blog post ripercorrono infatti le azioni compiute dagli utilizzatori,
fornendo anche informazioni temporali. Questo aspetto, unito alla conoscenza della
posizione, dell’azione svolta e degli altri utenti nei paraggi, può permettere di
estrapolare pattern ricorrenti per uno o più utenti. Grazie all’utilizzo di tecniche come
gli alberi di decisione, è infatti possibile categorizzare gli utilizzatori della piattaforma
in base alle loro occupazioni quotidiane. E’ inoltre ovviamente possibile incrociare i
dati di più utenti per individuare eventuali similarità.
Oltre agli scenari di utilizzo elencati in precedenza, il generatore di blog permette un
riuso dei propri componenti, grazie all’architettura modulare con cui è stato progettato e
sviluppato.
Gli algoritmi di clustering (Capitolo 5) possono infatti essere utilizzati in altri
scenari: il raggruppamento cronologico basato su cella GSM permette, previa
un’ulteriore analisi dei risultati, di scoprire, su un arco temporale lungo, quali sono i
luoghi più frequentati da un utente e quanto tempo ha speso in ogni posizione. Si
potrebbe quindi potenziare il meccanismo di scoperta semi-automatica dei luoghi
“personali” di un utente (funzionalità che è in parte già offerta dalla piattaforma CA)
(Capitolo 3).
Un altro componente riutilizzabile in un’ottica diversa è il generatore di videoblog
(Capitolo 7). Il codice che genera l’animazione flash può infatti essere usato
direttamente da TeamLife Portal [23] per creare slideshow personalizzati dei propri
contenuti multimediali. Le animazioni possono venire offerte come podcast, oppure
direttamente inserite nella pagina HTML (Capitolo 7).
92
Conclusioni e sviluppi futuri
9
9.1
Risultati ottenuti
Il presente lavoro di tesi descrive le caratteristiche progettuali di un prototipo di
generatore di blog contestualizzato e ne elenca le soluzioni implementative più
significative. L’applicazione ha permesso non solo di evidenziare le potenzialità messe
a disposizione dalla piattaforma Context Awareness di Telecom Italia Lab, ma è anche
stata in grado di conferire un valore aggiuntivo ai dati di contesto offerti dalla
piattaforma stessa. Il generatore di blog ha inoltre permesso di formulare alcune
considerazioni sull’approccio degli utenti ai servizi context aware in generale.
Gli algoritmi di clustering progettati ed implementati hanno permesso di raggruppare
le informazioni di posizione degli utenti a partire dall’elenco degli identificativi delle
celle GSM/UMTS: nel fare questo è stato necessario gestire le problematiche legate alla
distribuzione dei dati che tale tecnologia offre (Capitolo 5). Le caratteristiche delle
informazioni di contesto degli utenti hanno portato così alla decisione di sviluppare due
algoritmi di raggruppamento separati, utilizzati per analizzare differenti pattern di dati
generati dagli stili di vita degli utenti (Capitolo 5). Le osservazioni effettuate e i
feedback degli utenti coinvolti nella sperimentazione del servizio hanno inoltre
permesso di tarare gli algoritmi con parametri ottimali (Capitolo 5).
Il processo di clustering e la successiva creazione di testo naturale hanno favorito la
formulazione di alcune considerazioni sulla memoria che gli utenti hanno delle loro
giornate (Capitolo 6). Queste informazioni sono state utilizzate per adattare la struttura
del testo e il relativo livello di dettaglio alle esigenze emerse dalla fase di test del
progetto.
La creazione di un’architettura per la generazione del video blog (Capitolo 7) ha
infine permesso di presentare i risultati dell’elaborazione dei dati di contesto in un modo
alternativo, il tutto utilizzando tecnologie open source, sia per la conversione dei
contenuti multimediali, che per la costruzione dell’animazione stessa.
93
9.2
Problemi aperti
Il problema della riservatezza è sembrato essere uno dei punti chiave su cui lavorare
in futuro, anche in seguito a sperimentazioni interne e demo in eventi pubblici in cui il
software è stato dimostrato (ad esempio durante la notte bianca della ricerca 2007).
Occorre tenere in considerazione la percezione che gli utenti hanno della propria
privacy. In alcuni casi, infatti, l’applicazione è sembrata troppo invasiva: molte persone
non gradiscono che le proprie azioni vengano tracciate.
Inoltre, è sembrato necessario pensare ad un meccanismo di gestione del livello di
privatezza di ogni blog post, un aspetto non ancora implementato nel prototipo
sviluppato. Grazie a questa funzionalità, ogni utente sarà in grado di impostare la
visibilità che più gradisce per i propri articoli (privati, solo per amici, pubblici) e anche
il livello di dettaglio delle informazioni da pubblicare.
9.3
Sviluppi futuri
L’integrazione con altri provider della piattaforma, come il Calendar Provider
(Capitolo 3) [4] è una delle possibili estensioni del generatore di blog. Il componente,
utilizzato a sua volta anche dal Situation Provider, permette infatti l’aggiunta nei blog
post delle informazioni sugli impegni che ogni utente aggiunge nella propria agenda.
Queste informazioni, generate direttamente dagli utilizzatori, sono molto importanti per
aumentare la fedeltà dei blog post contestualizzati.
E’ da tenere in considerazione anche una possibile integrazione diretta con il
Situation Provider [1]. Il modulo interagisce con il motore a regole della piattaforma
CA per scoprire la situazione in cui si trova l’utente (Capitolo 3). Un aggancio alle API
fornite da questo componente permetterebbe non solo una migliore integrazione con i
servizi già offerti dalla piattaforma, ma contribuirebbe a migliorare la qualità del testo
dei blog post: il generatore avrebbe infatti a disposizione uno strato di reasoning
aggiuntivo offerto dal provider, grazie al quale sarebbe possibile creare del testo più
vario ed accurato.
La modalità di schedulazione del generatore di blog, lanciato come applicazione
batch alle ore 5:00 di ogni mattina, è da considerarsi provvisoria: il software deve essere
integrato con gli altri servizi della piattaforma, in particolare con AUP (Capitolo 3). In
questo modo si potrà permettere ad ogni utente di comunicare al generatore di blog l’ora
di inizio del diario quotidiano. Questa caratteristica è fondamentale per utenti che si
trovano in fusi orari diversi da quello del paese in cui risiede la macchina che ospita il
generatore di blog.
Per arricchire ulteriormente i blog post, realizzando in questo modo una sorta di
“mashup” tra servizi diversi, sarebbe interessante integrare informazioni provenienti da
webservice di terze parti. Si potrebbero infatti aggiungere dati meteorologici dei luoghi
94
visitati dall’utente, informazioni sugli eventi nelle vicinanze, link a pagine Wikipedia
che descrivono il territorio che l’utente ha visitato, ecc… [31]
Si è presa anche in considerazione l’idea di collegare tra loro i blog post quotidiani di
un utente. In questa prima versione, il generatore, nel creare il testo, non considera i
blog post già creati. Sarebbe interessante invece tenere conto di queste informazioni, per
creare del testo di raccordo più fluido tra le entry, dando quindi un senso di maggiore
naturalezza ai visitatori del blog.
Un’altra estensione ipotizzata è la possibilità di generare automaticamente blog post
con un livello di dettaglio variabile in base al tipo di giornata che l’utente ha trascorso e
alle azioni che ha compiuto.
Gli algoritmi di clustering utilizzati operano su identificativi di cella GSM. Per poter
utilizzare informazioni di posizione basate su tecnologia GPS, occorre ricorrere ad
algoritmi che raggruppano i dati in base alla distanza euclidea. Una delle linee di
sviluppo future prevede infatti di adattare algoritmi già noti in letteratura alle necessità
del generatore di blog.
Sarebbe interessante inoltre integrare il videoblog con un avatar in grado di
raccontare le azioni giornaliere dell’utente, grazie all’utilizzo di tecniche Text to
Speech.
Come già anticipato nel Capitolo 6, un’altra estensione necessaria è il supporto
multilingue. Al momento i blog post sono generati in inglese: si stanno valutando
alcune soluzioni, tra le quali l’utilizzo di sistemi NLG in altre lingue, la creazione di
testo naturale senza l’utilizzo di un sistema NLG oppure la traduzione a valle dei blog
post tramite tool dedicati.
95
96
Bibliografia
10 Bibliografia
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
L. Cerami: “Applicazione di tecniche di reasoning per integrazione dati di
profilo e di contesto in servizi context-aware”, Tesi di Laurea Specialistica
in Ingegneria delle Telecomunicazioni, Politecnico di Torino, novembre
2006.
M. Marengo, N. Salis, M. Valla: “Context Awareness: servizi mobili su
misura”, Notiziario Tecnico Telecom Italia, marzo 2007. Online su:
http://www.telecomitalia.it/TIPortale/docs/innovazione/012007/Pag11_22
%20contextawareness.pdf
L.W. Goix, M. Valla, L. Cerami, P. Falcarin: “Situation inference for
mobile users: a rule based approach”, 2007.
L. Lamorte, C.A Licciardi, M. Marengo, A. Salmeri, P. Mohr, G. Raffa, L.
Soffia, M. Pettinari, T. Salmon Cinotti: “A platform for enabling context
aware telecommunication services”, in CAPS 2007, Third Workshop on
Context Awareness for Proactive Systems. Guildford, UK, 2007.
A.K. Dey: "Understanding and Using Context", Personal and Ubiquitous
Computing, Vol. 5, 4-7, 2001.
A. Schmidt, M. Beigl, H-W. Gellersen, “There is more context than
location”, Telecooperation Office (TecO), University of
Karlsruhe,Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany, 2005.
On-line su
http://www.comp.lancs.ac.uk/~albrecht/pubs/pdf/schmidt_cug_elsevier_12
-1999-context-is-more-than-location.pdf
RFC 4480. Online su http://www.rfc-archive.org/getrfc.php?rfc=4480.
C. Venour, E. Reiter, “A tutorial for SimpleNLG (version 3.3)”. Maggio
2007, online su http://www.csd.abdn.ac.uk/~ereiter/simplenlg/simplenlgv34.zip
ACL Special Interest Group on Generation, online su
http://www.siggen.org/resources/
SimpleNLG, online su http://www.csd.abdn.ac.uk/~ereiter/simplenlg/
J. Allsopp, “Microformats: empowering your markup fow Web 2.0”,
Marzo 2007
Microformats official blog, online su http://microformats.org
97
Bibliografia
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
Firefox Add-ons, online su https://addons.mozilla.org/
Wordpress, online su http://wordpress.org/
Wordpress mu, online su http://mu.wordpress.org/
XML-RPC home page, online su http://www.xmlrpc.com/
The Apache XML-RPC Client, online su
http://ws.apache.org/xmlrpc/client.html
MING, a SWF output library and PHP module, online su
http://ming.sourceforge.net/
Ming functions for flash – Manual, online su http://us2.php.net/ming
SimpleXML functions – Manual, online su
http://us2.php.net/manual/en/ref.simplexml.php
FFmpeg, online su http://ffmpeg.mplayerhq.hu/
Orangoo Labs, GreyBox, online su http://orangoo.com/labs/GreyBox/
O. Rodriguez Rocha: “Teamlife, a Web 2.0 portal to represent
contextualized multimedia content.”, Master in Wireless Systems and
Related Technologies thesis, Politecnico di Torino, 2006.
J. Koolwaaij, A. Tarlano, M. Luther, P. Nurmi, B. Mrohs, A. Battestini,
R.Vaidya: “Context Watcher - Sharing context information in everyday
life”. In Proceedings of WTAS 2006, Calgary, Canada, 2006
W. M. Newman, M. A. Eldridge, M. G. Lamming: “PEPYS: generating
autobiographies by automatic tracking”. In Proceedings of the second
conference on European Conference on computer-supported cooperative
work, Amsterdam, The Netherlands, 1991.
A. Kröner, S. Baldes, A Jameson, M. Bauer “Using an Extended Episodic
Memory Within a Mobile Companion”. In Proceedings of Pervasive WS
on Memory and Sharing of Experience (MSE2004), 2004
K. Numaa, H. Takedab, H. Uematsuc, T. Nishimurad, Y. Matsuod, M.
Hamasakid, N. Fujimurad, K. Ishidad, T. Hoped, Y. Nakamurad, S.
Fujiyoshif, K. Sakamotof, H. Nagatag, O. Nakagawag, E. Shinborig: “A
Weblog Grounded to the Real World”. In Proceedings of AAAI-2006
Spring Symposium on Computational Approaches to Analyzing Weblogs,
Stanford, USA, marzo 2006.
H. E. Byun, K. Cheverst, “Exploiting User Models and ContextAwareness to Support Personal Daily Activities”. Workshop in UM2001
on User Modelling for Context-Aware Applications, Sonthofen, Germany,
2001.
E. Reiter, C. Mellish, J. Levine: “Automatic Generation of Technical
Documentation” in Applied Artificial Intelligence vol 9, 1995.
J. Gemmell, G. Bell, R. Lueder, S. Drucker, C. Wong: "MyLifeBits:
Fulfilling the Memex Vision". In Proceedings of the tenth ACM
international conference on Multimedia, Juan-les-Pins, France, 2002.
98
Bibliografia
[31]
[32]
[33]
GeoNames webservice and data download, on line su
http://www.geonames.org/export/
S. Guha, R. Rastogi, K. Shim: “ROCK: A Robust Clustering Algorithm for
Categorical Attributes”. In 15th International Conference on Data
Engineering, 1999.
J. B. MacQueen: "Some Methods for classification and Analysis of
Multivariate Observations", In Proceedings of 5-th Berkeley Symposium
on Mathematical Statistics and Probability, Berkeley, University of
California Press, 1:281-297, 1967.
99
Bibliografia
100
Ringraziamenti
11 Ringraziamenti
Un ringraziamento speciale va a tutto il gruppo Context Awareness and Ambient
Intelligence del Telecom Italia Lab in cui il presente lavoro di tesi è stato svolto. Un
grazie particolare a Carlo Alberto Licciardi e a Laurent Walter Goix, che hanno
supervisionato il mio lavoro guidandomi in questi mesi trascorsi all’interno del gruppo.
Vorrei ringraziare tutti i “beta tester” del blog contestualizzato: Carlo Alberto
Licciardi, Laurent Walter Goix, Massimo Valla, Marco Marengo, Sergio Rolando,
Danilo Dolfini e Nicoletta Salis. Durante questi mesi hanno dato preziosi consigli su
come migliorare l’applicazione (e risolvere i bug!).
Un grazie affettuoso va ovviamente a tutti i miei compagni di ufficio: Oscar
Rodriguez Rocha, Carmen Criminisi, Claudio Venezia, Hegazy Nizar e Danilo Dolfini.
Grazie anche ad Alessia Salmeri, Cristina Frà, Luca Lamorte, Marco Marchetti e
Anna Papurello per i consigli e il supporto che mi avete dato.
Un ringraziamento (e un in bocca al lupo!) anche a Maurizio, Federica, Paolo e
Carmen Catalano.
Sumita si merita un ringraziamento speciale… Grazie per avermi sempre appoggiato
e motivato in questi anni passati insieme. D’ora in poi non avrò più la scusa degli
esami!
Grazie ovviamente ai miei genitori. E’ merito del vostro affetto se sono arrivato fin
qui: grazie di cuore.
Grazie anche a Marco che mi sopporta da sempre! Posso solo dirti che ora è il tuo
turno, fratellino!
Volevo anche ringraziare lo zio d’America Prusso, Diego, Tony, Paolino, Bergie,
Tane, Bully, Panna e tutti gli altri ragazzi del corso: grazie per l’amicizia e il sostegno
che mi avete dato in questi anni.
Infine, un ringraziamento speciale va al Torre70, senza il quale non avrei mai potuto
provare l’ebrezza della ricostruzione di un legamento crociato anteriore, ma neanche la
felicità della vittoria del prestigioso campionato amatoriale… grazie di cuore anche a
voi.
101

Tesi di Laurea - e-Lite

Transcript

Documenti analoghi

case history sloggi - Kiosko - Servizi per le Agenzie di Pubblicità

Passione e oltre - Gremese Editore

Visualizza

Pages VEGETECTURE

Dal 19 luglio in libreria LE PAROLE MUTE DEL TEMPO di Giovanni

Schema delle Alpi

FreeZone Ok per pdf.qxd

Note e Salute: E` nato il 118AIR, società Italiana di

Informazioni sulla rappresentazione teatrale dell