Tesi di Laurea - elite.polito.itelite.polito.it/files/thesis/fulltext/costabello.pdf · Tesi di...

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 Scopo della tesi ..................................................................................................7

1.2 Servizi Context-Aware e la piattaforma CA......................................................7

1.3 I blog e la generazione automatica di contenuti context-aware.........................8

1.4 Architettura di riferimento.................................................................................8

1.5 Organizzazione della tesi.................................................................................10

2 Il diario giornaliero context-aware: tecniche di generazione note....................13

2.1 Pepys................................................................................................................13

2.2 MobiLife Life Blogging ..................................................................................14

2.3 ActionLog........................................................................................................14

2.4 Context awareness and User Models...............................................................15

2.5 Altri lavori .......................................................................................................16

3 Applicazioni Context-Aware ................................................................................17

3.1 La Context-Awareness.....................................................................................17

3.2 Il contesto di un utente.....................................................................................18

3.3 Scenari applicativi ...........................................................................................20

4 Context-Aware Platform.......................................................................................21

4.1 Descrizione generale........................................................................................21

4.2 Architettura funzionale, server side.................................................................21

4.3 Context Brokering: i componenti ....................................................................23

4.4 Context Provider..............................................................................................24

4.5 Piattaforma client side .....................................................................................26

4.6 Il linguaggio ContextML.................................................................................28

4.7 Tecnologie usate ..............................................................................................30

5 Raccolta e clustering dei dati di contesto.............................................................33

5.1 Panoramica generale........................................................................................33

Indice

6

5.2 Raccolta dei dati di contesto............................................................................34

5.3 I dati di contesto: caratteristiche generali. .......................................................38

5.4 Cluster Analysis applicata al tracking di un utente .........................................41

5.5 Algoritmo “Compare&Merge”........................................................................43

5.6 Algoritmo “MultiLevel Sliding Window” (MLSW).......................................45

5.7 Il clustering e la percezione dell’utente...........................................................50

5.8 Implementazione .............................................................................................52

6 Generazione e pubblicazione dei Blog Post.........................................................53

6.1 Introduzione.....................................................................................................53

6.2 La struttura del testo ........................................................................................54

6.3 Personalizzare il testo ......................................................................................58

6.4 Natural Language Generation..........................................................................59

6.5 Il blog strutturato: Microformats .....................................................................62

6.6 Integrare elementi multimediali: TeamLife Portal ..........................................69

6.7 La piattaforma di Blogging: WordPress MU ..................................................74

6.8 Il blog post pubblicato .....................................................................................76

6.9 Implementazione .............................................................................................76

7 La creazione del VideoBlog ..................................................................................79

7.1 Architettura generale .......................................................................................79

7.2 Il VideoBlogML..............................................................................................80

7.3 La Libreria MING ...........................................................................................82

7.4 Creare il Videoblog .........................................................................................84

7.5 Pubblicare il VideoBlog ..................................................................................88

8 Scenari abilitati......................................................................................................91

9 Conclusioni e sviluppi futuri ................................................................................93

9.1 Risultati ottenuti ..............................................................................................93

9.2 Problemi aperti ................................................................................................94

9.3 Sviluppi futuri..................................................................................................94

10 Bibliografia.............................................................................................................97

11 Ringraziamenti ....................................................................................................101

Introduzione

7

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.

Introduzione

8

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 context-

aware

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).

Introduzione

9

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.

Context Clusters

Data gathering and

Cluster algorithms

Video Blog

Creator

TILab CA Platform

Natural text

generation

Context Raw Data

Introduzione

10

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.

Introduzione

11

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.

Introduzione

12

Il diario giornaliero context–aware: tecniche di generazione note

13

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.


14

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


15

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


16

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).

Applicazioni Context-Aware

17

3 Applicazioni Context-Aware

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).


18

Figura 3.1.1 Modello a livelli logici di Context Awareness

- 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.

3.2 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”.


19

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.


20

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 context-

aware è 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).

Context-Aware Platform

21

4 Context-Aware Platform

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).


22

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.


23

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


24

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]


25

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.

User Data

User Profile

User Preference

User Device/ User Device Parameter

User Service Profile

User Places (Virtual Places)

Service Catalog

Device Capability Catalog


26

- 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.


27

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


28

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.


29

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”:


30

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

<?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>


31

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.


32

Raccolta e clustering dei dati di contesto

33

5 Raccolta e clustering dei dati di contesto

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).


34

5.2 Raccolta dei dati di contesto

La raccolta dei dati di contesto avviene nei passi in Figura 5.2.1.

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.

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

Cattura dei dati di contesto grezzi

Incrocio con Virtual Places

CLUSTERING

Completamento dei cluster

CH

CA Platform

AUP

LP

UPP

2007-09-07 09:24:08.0 222-1-61101-72162201 0c6d6ff64;0006c6040e66

Timestamp GSM CGI Dispositivi Bluetooth nei paraggi


35

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).

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).

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

office cgi-gsm 222-1-61101-72162201 TILab

Categoria Tecnologia usata Descrizione Elemento da etichettare

My office

Canteen

TILab


36

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).

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).

<?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>userVirtualPlace</scope> <timestamp>2007-10-04T14:33:39+02:00</timestamp> <expires>2007-10-04T14:38:39+02:00</expires> <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>


37

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.

<?xml version="1.0" encoding="UTF-8"?> <contextMLxmlns="http://ContextML/1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema instance"xsi:schemaLocation="http://ContextML/1.2 http://cark3.cselt.it/schemas/ContextML-1.2.xsd">

<ctxEls> <ctxEl>

<contextProvider id="LP" v="1.1.6"/> <entity id="unknown" type="unknown"/> <scope>position</scope> <timestamp>2007-10-04T15:47:40+02:00</timestamp> <expires>2007-10-04T15:49:40+02:00</expires> <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>


38

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.

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

2007-09-07 09:24 222-1-61101-72162201 office,tilab ownoffice,b1043 Oscar,friend;

Timestamp GSM CGI Nearby buddies

Virtual Place Bluetooth

Virtual place CGI

<?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="UPP" v="1.0.0"/> <entity id="lukostaz" type="userName"/> <scope>userProximity</scope> <timestamp>2007-10-04T15:18:29+02:00</timestamp> <expires>2007-10-04T15:18:34+02:00</expires> <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>


39

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,


40

che complicano l’analisi e il raggruppamento dei dati. Rilevare la

staticità di un utente in questi casi è più complesso (Figura 5.3.2).

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.

Figura 5.3.3 Distribuzione dei dati di contesto in caso di spostamento rapido

2007-09-30 17:42:02.0 222-1-34649-34079 2007-09-30 17:41:38.0 222-1-34649-17921 2007-09-30 17:41:24.0 222-1-34649-34079 2007-09-30 17:40:30.0 222-1-34649-17921 2007-09-30 17:39:11.0 222-1-34649-34079 2007-09-30 17:39:06.0 222-1-34649-34097 2007-09-30 17:38:04.0 222-1-34649-17921 2007-09-30 17:36:29.0 222-1-34649-31622 2007-09-30 17:36:19.0 222-1-34649-34097 2007-09-30 17:36:03.0 222-1-61101-72165119 2007-09-30 17:35:26.0 222-1-34649-17921 2007-09-30 17:35:01.0 222-1-34649-34079 2007-09-30 17:33:42.0 222-1-34649-31622 2007-09-30 17:33:26.0 222-1-34649-34097

2007-10-02 19:01:59.0 222-1-61104-72377238 2007-10-02 19:01:48.0 222-1-24650-12180 2007-10-02 19:01:06.0 222-1-61104-72377245 2007-10-02 18:57:50.0 222-1-61103-72310599 2007-10-02 18:57:09.0 222-1-61103-72305291 2007-10-02 18:56:40.0 222-1-61103-72305290 2007-10-02 18:55:09.0 222-1-61103-72306615 2007-10-02 18:54:28.0 222-1-61103-72306617 2007-10-02 18:54:17.0 222-1-61103-72328636 2007-10-02 18:54:05.0 222-1-61103-72328635 2007-10-02 18:53:07.0 222-1-61103-72307084 2007-10-02 18:52:53.0 222-1-61103-72307083 2007-10-02 18:52:42.0 222-1-61103-72288628 2007-10-02 18:51:54.0 222-1-61103-72305303 2007-10-02 18:50:38.0 222-1-61103-72305302 2007-10-02 18:49:53.0 222-1-61103-72328629


41

- 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.

5.4 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).

Figura 5.4.1 Il processo di clustering dei dati di contesto

2007-10-03 11:02:33.0 222-1-61101-72162201 office,tilab 2007-10-03 10:59:09.0 222-1-61101-72162201 office,tilab 2007-10-03 10:55:46.0 222-1-61101-72162201 office,tilab 2007-10-03 10:52:41.0 222-1-61101-72162201 office,tilab 2007-10-03 10:48:59.0 222-1-61101-72162201 office,tilab 2007-10-03 10:45:34.0 222-1-61101-72162201 office,tilab 2007-10-03 10:42:11.0 222-1-61101-72162201 office,tilab 2007-10-03 10:38:47.0 222-1-61101-72162201 office,tilab 2007-10-03 10:37:47.0 222-1-61101-72162201 office,tilab 2007-10-03 09:27:01.0 222-1-61101-72157899 office,tilab 2007-10-03 08:58:11.0 222-1-61104-72386176 n/a,n/a 2007-10-03 08:56:28.0 222-1-24650-121 n/a,n/a 2007-10-03 08:56:05.0 222-1-24650-122 n/a,n/a 2007-10-03 08:54:20.0 222-1-54650-923 n/a,n/a 2007-10-03 08:51:31.0 222-1-61104-72395762 n/a,n/a 2007-10-03 08:49:16.0 222-1-61104-72384437 n/a,n/a 2007-10-03 08:48:47.0 222-1-61104-72395762 n/a,n/a 2007-10-03 08:48:18.0 222-1-61104-72384437 n/a,n/a 2007-10-03 08:47:50.0 222-1-61104-72395762 n/a,n/a 2007-10-03 08:47:21.0 222-1-61104-72395762 n/a,n/a 2007-10-03 08:46:51.0 222-1-61104-72384437 n/a,n/a 2007-10-03 08:46:20.0 222-1-61104-72376116 n/a,n/a 2007-10-03 08:45:15.0 222-1-61104-72395763 n/a,n/a 2007-10-03 08:44:02.0 222-1-61104-72400263 n/a,n/a 2007-10-03 08:42:33.0 222-1-61104-72395770 n/a,n/a 2007-10-03 08:42:02.0 222-1-61104-72400262 n/a,n/a 2007-10-03 08:40:08.0 222-1-24650-1281 residence,home 2007-10-03 08:36:26.0 222-1-24650-1281 residence,home 2007-10-03 08:33:02.0 222-1-24650-1281 residence,home 2007-10-03 08:29:46.0 222-1-24650-1281 residence,home 2007-10-03 08:26:15.0 222-1-24650-1281 residence,home 2007-10-03 08:22:51.0 222-1-24650-1281 residence,home 2007-10-03 08:19:34.0 222-1-24650-1281 residence,home 2007-10-03 08:16:10.0 222-1-24650-1281 residence,home 2007-10-03 08:12:59.0 222-1-24650-1281 residence,home 2007-10-03 08:09:17.0 222-1-24650-1281 residence,home 2007-10-03 08:05:53.0 222-1-24650-1281 residence,home

Cluster 1 (Statico)

Start 08:58

End 11:02

CGI 222-1-61101-162201

VP CGI 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

Cluster 2 ( Movimento)

Start 08:42 End 08:56 CGI From 222-1-24550-1281 CGI To 222-1-24650-121 VP CGI From

Residence, home

VP CGI To Office, TILab VP Bth Not available


42

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.


43

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).

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

foreach ContextEntry ce{ if (ce.location == clusterTemp.location) clusterTemp.addContextEntry(ce); else{

tempList.add(clusterTemp ); clusterTemp = new Cluster(ce);

} } return tempList;


44

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.

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

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;


45

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.

5.6 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).


46

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

2007-10-03 11:02:33.0 222-1-61101-72162201 office,tilab

2007-10-03 10:59:09.0 222-1-61101-72162201 office,tilab

2007-10-03 10:55:46.0 222-1-61101-72162201 office,tilab

2007-10-03 10:52:41.0 222-1-61101-72162201 office,tilab

2007-10-03 10:48:59.0 222-1-61101-72162201 office,tilab

2007-10-03 10:45:34.0 222-1-61101-72162201 office,tilab

2007-10-03 10:42:11.0 222-1-61101-72162201 office,tilab

2007-10-03 10:38:47.0 222-1-61101-72162201 office,tilab

2007-10-03 10:37:47.0 222-1-61101-72162201 office,tilab

2007-10-03 09:27:01.0 222-1-61101-72157899 office,tilab

2007-10-03 08:58:11.0 222-1-61104-72386176 n/a,n/a

2007-10-03 08:56:28.0 222-1-24650-121 n/a,n/a

2007-10-03 08:56:05.0 222-1-24650-122 n/a,n/a

2007-10-03 08:54:20.0 222-1-54650-923 n/a,n/a

2007-10-03 08:51:31.0 222-1-61104-72395762 n/a,n/a

2007-10-03 08:49:16.0 222-1-61104-72384437 n/a,n/a

2007-10-03 08:48:47.0 222-1-61104-72395762 n/a,n/a

2007-10-03 08:48:18.0 222-1-61104-72384437 n/a,n/a

2007-10-03 08:47:50.0 222-1-61104-72395762 n/a,n/a

2007-10-03 08:47:21.0 222-1-61104-72395762 n/a,n/a

2007-10-03 08:46:51.0 222-1-61104-72384437 n/a,n/a

2007-10-03 08:46:20.0 222-1-61104-72376116 n/a,n/a

2007-10-03 08:45:15.0 222-1-61104-72395763 n/a,n/a

2007-10-03 08:44:02.0 222-1-61104-72400263 n/a,n/a

2007-10-03 08:42:33.0 222-1-61104-72395770 n/a,n/a

2007-10-03 08:42:02.0 222-1-61104-72400262 n/a,n/a

2007-10-03 08:40:08.0 222-1-24650-1281 residence,home

2007-10-03 08:36:26.0 222-1-24650-1281 residence,home

2007-10-03 08:33:02.0 222-1-24650-1281 residence,home

2007-10-03 08:29:46.0 222-1-24650-1281 residence,home

Sliding window, Iterazione 1

(durata: 24 minuti)

Sliding window, Iterazione 2

(durata: 57 minuti)


47

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:

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:

// 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;


48

- 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.


49

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.


50

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

Sì Sì

Situazione di utilizzo ottimale

“Situazioni note” (presenza di Virtual Place, celle GSM senza particolari problemi di switch,

ecc…)

Giornate vissute in luoghi anche non etichettati da Virtual

Place.

Situazioni critiche Casi di switch spuri tra celle in

situazioni statiche Nessuna in particolare

Precisione Molto buona nelle situazioni ottimali (inferiore ad un update di contesto).

Dipende dalle dimensioni della finestra scorrevole. Una window lunga 30 minuti garantisce errori contenuti

(< 10 minuti).

Durata minima delle situazioni identificate

Impostabile dall’utente

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:


51

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


52

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.

Generazione e pubblicazione dei blog post

53

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.


54

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.

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

Figura 6.2.2 Situazione statica

Context Clusters

Action Detector

_______

_______

_______

_______

Testo Naturale

Realiser

Frasi statiche

Frasi statiche (compl. ogg)

Frasi di Movimento

Context

Cluster

NLG

User

preference

s

Blog Post Generation

Soggetto Verbo Durata, inizio e fine Buddies

I stayed at home for 4 hours, from 18:43 to 22:52, and there I met Marco.

Luogo


55

- 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.

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.

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).

Soggetto Verbo Inizio e Fine Buddies

I had a four hour lesson in classroom 4 with Marco, from 10:30 to 14:30.

Compl. Oggetto Luogo

Soggetto Verbo 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.

Provenienza Destinazione Mezzo


56

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”.

airport wait bar enjoy cafe relax office work hotel rest shopping-area shop default stay ... ...


57

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…


58

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.

Figura 6.3.1 Blog post creato con livelli di dettaglio diversi

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.


59

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


60

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


61

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.

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.

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).

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.

Realiser

_________________________

Testo Naturale

Verbo Soggetto Complementi Avverbi

Frase

Frase Paragrafo

Verbo Soggetto Complementi Avverbi

..........

..........

Strutture dati del sistema NLG

in memoria

NLG


62

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.


63

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).


64

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).

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

<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>


65

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).

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).

<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>

span.street-address{ display: none;

} span.locality{

display: none; } span.country-name{

display: none; }

(a)

(b)

TILab

(c)


66

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).

Figura 6.5.6 XFN Microformat

<a href="http://blog.com/wasvel" rel="colleague met">Walter</a>

<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>

div.org{ display: none;

} div.tel{

display: none; } a.url{

display: none; }

(c)

(a)

(b)

Mario Rossi


67

XFN è 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).

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

<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>


68

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].


69

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).


70

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].


71

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.

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):

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.

http://ca.tilab.com/tl/rss.php?album=usertags&username=lukostaz&tag=Torino

RSS Parsing

Assegnazione ai cluster

Creazione del contenuto HTML

Blog Generator


72

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).

http://ca.tilab.com/tl/rss.php?album=lastupby&username=wasvel&newer_than=1


73

Figura 6.6.5 Un esempio di come gli elementi multimediali sono trasformati in codice HTML e

successivamente visualizzati nel blog post.

<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.jpg" 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.jpg" class="thumb" title="Gibitrio" alt="Gibitrio" /></a>

</span></div>


74

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].


75

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.

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

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); }


76

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).


77

Figura 6.9.1 Esempio di pubblicazione di blog post


78

La creazione del VideoBlog

79

7 La creazione del VideoBlog

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).

Figura 7.1.1 Generazione del VideoBlog: integrazione tra componenti

Context Cluster

Cluster & Blog entry

Generator

Video Blog Generator

VideoBlogML

HTTP

Flash Video Blogs

MING library


80

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.


81

Figura 7.2.1 Lo schema del VideoBlogML


82

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

<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>

http://ca.tilab.com/tl/albums/userpics/10027/normal_20070929T180022.jpg </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>

http://ca.tilab.com/tl/albums/userpics/10027/normal_20070929T200831.jpg </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>

http://ca.tilab.com/tl/albums/userpics/10027/normal_20070929T220210.jpg </pictureURL> <title>Che felicita' la borsa nuova!</title> </mediaElement> </mediaElements>

</ctxCluster> </ctxClusters> </videoData>


83

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].


84

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

// 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");


85

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.

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):

$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);


86

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.

Barra delle informazioni

Area principale


87

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):

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.

Temp files (3gp, mp4)

Audio files (mp3)

Video files (flv)

Multiplexing Video files (swf)

Concatenazione in video

slideshow

HTTP GET


88

- 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.

7.5 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


89

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


90

Scenari abilitati

91

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ò

Scenari abilitati

92

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).

Conclusioni e sviluppi futuri

93

9 Conclusioni e sviluppi futuri

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.


94

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


95

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.


96

Bibliografia

97

10 Bibliografia

[1] 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.

[2] 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

[3] L.W. Goix, M. Valla, L. Cerami, P. Falcarin: “Situation inference for

mobile users: a rule based approach”, 2007.

[4] 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.

[5] A.K. Dey: "Understanding and Using Context", Personal and Ubiquitous

Computing, Vol. 5, 4-7, 2001.

[6] 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

[7] RFC 4480. Online su http://www.rfc-archive.org/getrfc.php?rfc=4480.

[8] C. Venour, E. Reiter, “A tutorial for SimpleNLG (version 3.3)”. Maggio

2007, online su http://www.csd.abdn.ac.uk/~ereiter/simplenlg/simplenlg-

v34.zip

[9] ACL Special Interest Group on Generation, online su

http://www.siggen.org/resources/

[10] SimpleNLG, online su http://www.csd.abdn.ac.uk/~ereiter/simplenlg/

[11] J. Allsopp, “Microformats: empowering your markup fow Web 2.0”,

Marzo 2007

[12] Microformats official blog, online su http://microformats.org

Bibliografia

98

[13] Firefox Add-ons, online su https://addons.mozilla.org/

[14] Wordpress, online su http://wordpress.org/

[15] Wordpress mu, online su http://mu.wordpress.org/

[16] XML-RPC home page, online su http://www.xmlrpc.com/

[17] The Apache XML-RPC Client, online su

http://ws.apache.org/xmlrpc/client.html

[18] MING, a SWF output library and PHP module, online su

http://ming.sourceforge.net/

[19] Ming functions for flash – Manual, online su http://us2.php.net/ming

[20] SimpleXML functions – Manual, online su

http://us2.php.net/manual/en/ref.simplexml.php

[21] FFmpeg, online su http://ffmpeg.mplayerhq.hu/

[22] Orangoo Labs, GreyBox, online su http://orangoo.com/labs/GreyBox/

[23] 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.

[24] 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

[25] 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.

[26] 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

[27] 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.

[28] H. E. Byun, K. Cheverst, “Exploiting User Models and Context-

Awareness to Support Personal Daily Activities”. Workshop in UM2001

on User Modelling for Context-Aware Applications, Sonthofen, Germany,

2001.

[29] E. Reiter, C. Mellish, J. Levine: “Automatic Generation of Technical

Documentation” in Applied Artificial Intelligence vol 9, 1995.

[30] 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.

Bibliografia

99

[31] GeoNames webservice and data download, on line su

http://www.geonames.org/export/

[32] S. Guha, R. Rastogi, K. Shim: “ROCK: A Robust Clustering Algorithm for

Categorical Attributes”. In 15th International Conference on Data

Engineering, 1999.

[33] 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.

Bibliografia

100

Ringraziamenti

101

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.

Tesi di Laurea - elite.polito.itelite.polito.it/files/thesis/fulltext/costabello.pdf · Tesi di...

Documents

Transcript of Tesi di Laurea - elite.polito.itelite.polito.it/files/thesis/fulltext/costabello.pdf · Tesi di...