III Facoltà di Ingegneria. Corso di laurea specialistica in Ingegneria Informatica. Tesi di Laurea

Transcript

1 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

2

3 Ai miei Genitori

4

5 Indice 1 Introduzione Scopo della tesi Servizi Context-Aware e la piattaforma CA I blog e la generazione automatica di contenuti context-aware Architettura di riferimento Organizzazione della tesi Il diario giornaliero context-aware: tecniche di generazione note Pepys MobiLife Life Blogging ActionLog Context awareness and User Models Altri lavori Applicazioni Context-Aware La Context-Awareness Il contesto di un utente Scenari applicativi Context-Aware Platform Descrizione generale Architettura funzionale, server side Context Brokering: i componenti Context Provider Piattaforma client side Il linguaggio ContextML Tecnologie usate Raccolta e clustering dei dati di contesto Panoramica generale...33

6 Indice 5.2 Raccolta dei dati di contesto I dati di contesto: caratteristiche generali Cluster Analysis applicata al tracking di un utente Algoritmo Compare&Merge Algoritmo MultiLevel Sliding Window (MLSW) Il clustering e la percezione dell utente Implementazione Generazione e pubblicazione dei Blog Post Introduzione La struttura del testo Personalizzare il testo Natural Language Generation Il blog strutturato: Microformats Integrare elementi multimediali: TeamLife Portal La piattaforma di Blogging: WordPress MU Il blog post pubblicato Implementazione La creazione del VideoBlog Architettura generale Il VideoBlogML La Libreria MING Creare il Videoblog Pubblicare il VideoBlog Scenari abilitati Conclusioni e sviluppi futuri Risultati ottenuti Problemi aperti Sviluppi futuri Bibliografia Ringraziamenti

7 Introduzione 1 Introduzione 1.1 Scopo della tesi Il presente lavoro di tesi è stato svolto all interno del progetto Context Awareness and Ambient Intelligence del Telecom Italia Lab e ha avuto come obiettivo la progettazione e lo sviluppo di un generatore automatico di blog contestualizzato. Il software crea quotidianamente i blog post che descrivono le azioni svolte durante la giornata dagli utenti registrati al servizio, includendo anche i contenuti multimediali acquisiti. Tutto questo avviene in modo completamente automatico. Oltre ai blog post in forma testuale, il generatore mette a disposizione degli utenti un video-diario, anche questo generato automaticamente. Il software realizzato si appoggia alla piattaforma Context Awareness sviluppata da Telecom Italia Lab per permettere la creazione di servizi in grado di reagire al contesto in cui si trovano gli utenti. La tesi si occupa non solo di spiegare le scelte progettuali che hanno portato allo sviluppo del generatore di blog, ma descrive anche le soluzioni implementative più significative. 1.2 Servizi Context-Aware e la piattaforma CA Le applicazioni context-aware permettono di fornire contenuti, informazioni e servizi personalizzati in base al contesto in cui l utente si trova. Con il termine contesto si indica appunto un insieme di dati relativi sia allo stato dell utente che all ambiente in cui questo si trova (Capitolo 3). I servizi context-aware hanno l obiettivo di fornire informazioni coerenti con la situazione in cui è immerso l utilizzatore, adattandosi a possibili variazioni delle circostanze. Il progetto Context Awareness and Ambient Intelligence di Telecom Italia Lab ha sviluppato e implementato un prototipo di piattaforma software context aware. Il progetto è costituito da due componenti distinte: la prima è un client in esecuzione sui dispositivi portatili degli utenti (PDA, smartphone), mentre la seconda è composta da numerosi componenti server-side intercomunicanti, che si occupano di elaborare, riorganizzare ed effettuare reasoning sui dati acquisiti dai client. 7

8 Introduzione Grazie alle API messe a disposizione dalla piattaforma CA, è possibile sviluppare applicativi context aware, come nel caso del generatore di blog contestualizzato. 1.3 I blog e la generazione automatica di contenuti contextaware La pubblicazione di contenuti generati direttamente dagli utenti è uno dei motori alla base della grande crescita delle dimensioni del web. La diffusione dei blog personali è senza dubbio uno degli aspetti che più hanno avvicinato il grande pubblico alla rete. In molti casi i contenuti pubblicati contengono informazioni personali legate al contesto in cui l utente si è trovato, come, ad esempio, le azioni svolte durante la giornata. Tipicamente queste informazioni sono arricchite dalle foto scattate con il proprio telefono cellulare, o da video. L obiettivo principale del generatore di blog è proprio quello di automatizzare queste operazioni. Grazie all utilizzo di paradigmi tipici della context-awareness, il software è in grado di sollevare gli utenti dalla generazione dei contenuti che descrivono le loro giornate. In questo modo è possibile ottenere blog con testo naturale, foto e video diari, che descrivono in dettaglio le situazioni in cui ci si è trovati durante l arco di tempo desiderato. 1.4 Architettura di riferimento La generazione di un blog post si articola in più passi, ognuno eseguito da un modulo funzionale (Figura 1.4.1). 8

9 Introduzione Natural text generation Video Blog Creator Data gathering and Cluster algorithms Context Clusters Context Raw Data TILab CA Platform Figura Architettura generale. In grigio i moduli del generatore di blog. La prima operazione necessaria è l integrazione con la piattaforma CA, dalla quale il generatore di blog acquisisce i dati di contesto della giornata di un utente (posizioni, persone nei paraggi, ecc ). Le informazioni collezionate vengono elaborate da algoritmi di clustering sviluppati ad hoc. Questa operazione permette di ricostruire le azioni che l utente ha compiuto durante la giornata: è così possibile sapere dove una persona è stata e per quanto tempo. Gli algoritmi sono inoltre in grado di individuare i movimenti effettuati dagli utenti. Dopo aver raggruppato i dati, si procede con la conversione degli stessi in testo naturale. Questo passo si effettua utilizzando un realizzatore di linguaggio naturale. Il testo generato sarà successivamente arricchito dai contenuti multimediali acquisiti dall utente durante le azioni compiute nella giornata. Fotografie e filmati sono prelevate da un portale web, TeamLife Media Sharing, precedentemente sviluppato all interno del progetto Context Awareness and Ambient Intelligence [23]. La creazione di un testo naturale non è però l unico modo in cui le informazioni di contesto dell utente vengono presentate: il modulo di generazione del videoblog si occupa infatti di trasformare i cluster di contesto in un animazione Flash. Le azioni che l utente ha compiuto durante la giornata sono organizzate nel filmato come i titoli di testa di un telegiornale: nel video sono integrati anche tutti i contenuti multimediali acquisiti dall utente, arricchiti ovviamente dalle informazioni di contesto ottenute grazie agli algoritmi di raggruppamento. Il blog testuale e il video-diario sono infine pubblicati sul web, grazie all utilizzo di una piattaforma di blogging pre-esistente. 9

10 Introduzione 1.5 Organizzazione della tesi Prima di descrivere i dettagli progettuali ed implementativi del generatore di blog, si analizzano alcuni aspetti fondamentali per comprendere al meglio il contesto in cui l applicazione è stata sviluppata. E prima di tutto necessario descrivere alcuni approcci alla generazione automatica di diari personali context-aware trovati in letteratura. Il capitolo 2 analizza alcuni progetti dalle caratteristiche simili a ciò che si è realizzato nel presente lavoro di tesi: se ne elencano i punti più interessanti e si sottolineano le differenze con il generatore di blog contestualizzato. Il capitolo 3 descrive i concetti base della Context Awareness e delle caratteristiche delle applicazioni sviluppate in tale filone. Si parla in modo più rigoroso ed approfondito della definizione di contesto di un utente e si presentano infine alcuni scenari applicativi per servizi context-aware in generale. Le definizioni generali elencate e spiegate nel capitolo 3 trovano un applicazione concreta nella descrizione dell architettura della Context Aware Platform TILab. All interno del capitolo 4 si descrivono i componenti della piattaforma, le loro funzioni e le soluzioni adottate per garantire l interoperabilità tra i vari moduli che la compongono, enfatizzando le componenti usate nella generazione del blog [4]. A questo proposito, il capitolo ospita la descrizione del linguaggio di scambio dati utilizzato dalla piattaforma, il ContextML. Si parla inoltre delle tecnologie adottate per l implementazione della CA Platform e delle necessità che hanno spinto a tali scelte. Il capitolo 5, già oggetto dell attività di tesi, si occupa di descrivere le tecniche utilizzate per acquisire e raggruppare i dati di contesto (posizione degli utenti, timestamp associati, presenza di amici nelle vicinanze, ecc ). La piattaforma CA mette infatti a disposizione per ogni utente una grande mole di informazioni: sono gli algoritmi di aggregazione a dare un significato a questi dati. All interno del capitolo si descrivono le caratteristiche più significative dei dati di contesto su cui gli algoritmi operano (sia a livello di formato che di contenuti) e si analizzano i problemi da affrontare e gli obiettivi da raggiungere per ottenere un raggruppamento delle informazioni soddisfacente per l'utente finale. Le tecnologie utilizzate per la localizzazione giocano un ruolo fondamentale sulla scelta delle tecniche di clustering da adottare: la decisione di operare con informazioni di posizione basate su cella GSM/UMTS oppure su identificativi Bluetooth è stata determinante nella decisione di sviluppare due algoritmi di raggruppamento ad hoc (Compare&Merge e MultiLevel Sliding Window). I due procedimenti nascono per lavorare su pattern di dati differenti e sono quindi da considerarsi complementari. I risultati della fase di raggruppamento dei dati di contesto sono comparati con la percezione che gli utenti hanno delle loro giornate: si descrivono gli aspetti più importanti da rispettare per ricalcare in modo soddisfacente le azioni compiute dagli utenti durante la giornata. 10

11 Introduzione Dopo aver eseguito gli algoritmi di clustering è necessario creare e pubblicare i blog post. Il capitolo 6 descrive il processo seguito per la generazione del testo naturale relativo alle giornate degli utenti. Si analizzano la struttura delle frasi da costruire e il procedimento che trasforma semplici informazioni di contesto in un testo. Uno dei passi cardine della procedura prevede l utilizzo di un natural language generator: si descrivono i motivi che hanno spinto ad utilizzare tale tecnologia e se ne valutano i pregi e i difetti. Il testo è inoltre arricchito dalla presenza di MicroFormats, uno standard per il markup semantico che permette la creazione di blog post strutturati [11] [12]. Il capitolo descrive inoltre l integrazione con TeamLife Portal, un content management system sviluppato dal gruppo Context Awareness TILab, che permette la condivisione di contenuti multimediali contestualizzati [23]. Il generatore di blog utilizza le API esposte dall applicativo per arricchire il testo del diario quotidiano con le foto e i filmati acquisiti dall utente durante la giornata. Il capitolo termina con la descrizione della piattaforma di blogging utilizzata per pubblicare i blog post, WordPress Multi User [15]. Come già anticipato, il generatore è in grado di presentare la giornata di un utente nella forma di animazione video. Nel capitolo 7 si elencano le scelte tecnologiche adottate e le soluzioni implementative più significative, in particolare per quanto riguarda l architettura generale del modulo, sviluppato in linguaggio PHP a partire dalla libreria open source Ming [18], in grado di creare animazioni in formato Flash. Il capitolo 8 elenca invece alcuni possibili scenari di utilizzo del generatore di blog, come la condivisione delle proprie esperienze con amici e parenti oppure il supporto alla memoria umana. 11

12 Introduzione 12

13 Il diario giornaliero context aware: tecniche di generazione note 2 Il diario giornaliero context-aware: tecniche di generazione note La generazione automatica dei log delle azioni degli utenti è una tematica su cui la comunità lavora ormai da molti anni. Vale la pena di citare alcune soluzioni seguite da progetti con obiettivi simili al generatore di blog contestualizzato. 2.1 Pepys E stato uno dei primi approcci al tracciamento automatico degli utenti finalizzato alla generazione di log giornalieri [25]. Nonostante tecnologie di localizzazione dalle caratteristiche limitate (Pepys è stato sviluppato nel 1991), l approccio è molto simile a quanto realizzato nel Generatore di Blog Contestualizzato. L obiettivo primario del sistema è di agire come supporto alla memoria umana: i log delle giornate serviranno quindi all utente stesso per poter ricordare le proprie azioni. Il sistema, grazie all utilizzo di badge a radiofrequenza, raccoglie informazioni sulla posizione degli utenti in ambienti interni (in questo caso, una palazzina di uffici). Viene rilevata anche la presenza di altri utenti nelle vicinanze. Questi dati sono utilizzati per costruire un Diario degli episodi personali [25], un log che riassume in forma testuale le azioni compiute da un utente durante la giornata. Pepys utilizza algoritmi per l analisi dei dati di contesto relativi ai singoli utenti: il quorum spotter [25], individua le situazioni in cui molti utenti sono presenti nella stessa stanza (gathering). Così facendo l applicazione riesce ad individuare situazioni di staticità significative, caratterizzate dalla presenza di molti utenti contemporaneamente. Pepys è inoltre in grado di riconoscere casi di movimento, grazie ad un algoritmo dedicato, il travel agent [25]. Il riconoscimento degli spostamenti è un aspetto ripreso e approfondito dal generatore di blog. La fase di aggregazione dei risultati termina con l utilizzo del diary episode builder, un modulo che si occupa di astrarre ulteriormente i risultati ottenuti ai punti precedenti, riducendo, quando necessario, il dettaglio della lista di azioni compiute dall utente [25]. In alcuni casi [25], è inoltre prevista una procedura di gap filling che si occupa di inferire l azione dell utente in base alle posizione precedente e successiva. 13

14 Il diario giornaliero context aware: tecniche di generazione note 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 ai rispettivi utenti. 2.2 MobiLife Life Blogging Il progetto MobiLife (a cui ha partecipato anche il gruppo Context Awareness TILab) propone Life Blogging [24], un approccio per molti versi analogo a quanto fatto da Pepys, ma rivisitato in chiave più moderna. Anche in questo caso, si tratta di un applicazione in grado di creare un diario giornaliero di un utente a partire da un insieme di informazioni di contesto. Nel caso di Life Blogging, queste informazioni sono acquisite grazie all utilizzo di un client (Context Watcher) in esecuzione sui terminali mobili degli utenti [24]. Il software è in grado di fornire informazioni di posizione (basate su cella GSM oppure GPS), fotografie, dati corporei come il battito cardiaco, ecc Le informazioni di contesto sono alla base della generazione automatica del diario dell utente, che in questo caso viene presentato sotto forma di blog, utilizzabile principalmente per condividere contenuti contestualizzati con amici, parenti e colleghi. Un altro possibile scenario di utilizzo proposto consiste nella creazione di statistiche personali sul proprio stile di vita [24]. Il sistema si basa sul concetto di clustering delle informazioni di contesto (un aspetto ripreso, in modo più approfondito, anche dal generatore di blog): grazie ad algoritmi di aggregazione, si riesce dunque a ricostruire le azioni compiute da un utente durante la giornata (anche se non si considera la dimensione temporale, aspetto invece fondamentale per il generatore di blog contestualizzato). A differenza di quanto accadeva in Pepys, il diario personale di Mobilife Life Blogging non è composto da un semplice elenco di azioni: l approccio seguito prevede infatti di creare del testo il più possibile naturale [24], ed è quindi più simile al generatore di blog sviluppato. 2.3 ActionLog Come nel caso di Pepys e Life Blogging, anche ActionLog [27] è un sistema orientato alla generazione automatica di un diario giornaliero, finalizzato allo scambio di informazioni tra utenti con contesti simili. Il sistema è stato testato grazie allo 14

15 Il diario giornaliero context aware: tecniche di generazione note sviluppo di un prototipo (ActionLog for Conference [27]), sviluppato espressamente per supportare lo scambio di informazioni durante conferenze accademiche. Anche in questo caso si opera a partire da un set di dati di contesto (in particolare relativi alla posizione e alle persone nelle vicinanze). A partire da questi dati, ActionLog costruisce una lista di azioni compiute dall utente. Ad ogni azione corrisponderà una bozza di frase testuale, generata automaticamente. Questa idea è stata ripresa dal generatore di blog. Gli utilizzatori possono personalizzare le proprie entry e inoltre hanno il compito di validarle prima che appaiano sul blog: si tratta dunque di una pubblicazione semi-automatica. Come in Life Blogging, i contenuti vengono condivisi in ordine cronologico tramite blog post, ma la generazione di queste informazioni avviene subito dopo che l azione si è conclusa e non giorno per giorno come nel caso di Pepys o del generatore di blog contestualizzato. Inoltre, anche se è prevista a posteriori una fase di aggregazione dei contenuti, questa si limita a raggruppare le entry generate in contesti simili e non a sostituirle con frasi che condensano e astraggono le azioni puntuali. 2.4 Context awareness and User Models Alcuni progetti, nonostante non siano finalizzati direttamente alla creazione del diario giornaliero, hanno offerto spunti interessanti, in particolare per quanto riguarda il rapporto tra dati di contesto e informazioni ricavate direttamente dagli utenti. SPECTER [26] è un software che opera da assistente personale dell utente, adattandosi dinamicamente al contesto in cui questo si trova. Nel realizzare queste funzionalità, gioca un ruolo centrale il personal journal, il modulo che si occupa di ricordare le azioni compiute nel passato. L efficacia dell assistente personale si basa infatti in gran parte sull analisi delle situazioni in cui si è trovato l utente: grazie alle informazioni sulle azioni passate, SPECTER è in grado di fornire i consigli e i suggerimenti corretti. Il personal journal è senza dubbio il componente più interessante da analizzare ai fini della generazione di blog contestualizzati. E utile in particolare analizzare l approccio seguito nel coinvolgere gli utenti ad arricchire le informazioni di contesto acquisite automaticamente [26]. Il personal journal si basa infatti su un modello ibrido, definito in parte dall utente (che può aggiungere a mano alcune azioni che ha compiuto durante la giornata), ed in parte generato automaticamente. Viene quindi data particolare enfasi al ruolo che l utente ricopre nel generare il modello. SPECTER permette inoltre la modifica manuale delle entry generate in automatico, per poter aggiungere informazioni aggiuntive o correggere eventuali errori. L interazione dell individuo, che specifica direttamente le proprie azioni, non può che aumentare la precisione e il livello di dettaglio del personal journal, ma allo stesso tempo è fondamentale focalizzarsi sulla 15

16 Il diario giornaliero context aware: tecniche di generazione note generazione automatica del log delle azioni, per evitare un eccessiva pesantezza del processo di correzione manuale. Il personal journal è costituito in gran parte da entry generate automaticamente a partire dai dati ricavati dai sensori dei device portatili. Si sottolinea come queste informazioni debbano essere corrette, pena la perdita di fiducia nel sistema da parte degli utilizzatori[26]. L idea di coinvolgere gli utenti nella personalizzazione dei propri post è stata ripresa dal generatore di blog, in particolare per quanto riguarda la gestione delle etichette attribuite alle posizioni geografiche (Capitolo 5.2). Un altro sistema interessante è descritto in [28]. Anche in questo caso si tratta di un assistente personale context-aware. Come in SPECTER, è stato analizzato il rapporto tra context awareness e informazioni ricavate da tecniche più tradizionali basate su uno user model [28]: si è giunti alla conclusione, già seguita da SPECTER, di lavorare su entrambe le categorie. Il Personal Digital Secretary utilizza quindi non solo i dati ricavati dal contesto, ma anche le informazioni prelevate dal profilo degli utenti. I dati di contesto, come accade in altri sistemi analizzati in precedenza (Pepys, Life Blogging) vengono processati da un modulo, il context synthetizer, che si occupa di aggregare le informazioni per aumentare il livello di astrazione finale. L importanza data da [26] e [28] all interazione con le informazioni direttamente introdotte dagli utenti ha portato alla formulazione di alcune linee guida per gli sviluppi futuri del generatore di blog, come l integrazione con l agenda dell utente (Capitolo 9.3). 2.5 Altri lavori Uno spunto interessante per lo sviluppo del generatore di blog viene da IDAS [29]. Il progetto, seppur discostandosi dai lavori visti in precedenza (legati sempre in qualche modo ai concetti di context awareness), introduce l utilizzo di un Natural Language Generator per creare automaticamente dei documenti tecnici. La generazione di testo naturale tramite un sistema NLG sarà la strada seguita anche dal generatore di blog contestualizzato. Il progetto MyLifeBits [30], è invece alla base dell idea dell integrazione con contenuti multimediali contestualizzati. MyLifeBits è un sistema sperimentale rivolto alla raccolta di tutti i contenuti digitali creati durante la vita dell utente, ai fini di supportare la memoria degli individui. L enfasi del progetto è però rivolta in particolare ai metodi per organizzare questa mole di dati, e non tanto a creare delle rappresentazioni testuali che condensino i dati raccolti (aspetto questo che è invece fondamentale nella creazione del blog contestualizzato). 16

17 Applicazioni Context-Aware 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, , ecc ). Il tipo di servizi che la piattaforma può fornire dipende non solo da quanti e quali dati sono stati raccolti, ma anche da come questi vengono processati ed analizzati. Per poter offrire applicazioni context aware è quindi necessaria un architettura articolata sui seguenti livelli: [4] (Figura 3.1.1). 17

18 Applicazioni Context-Aware Figura 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. 18

19 Applicazioni Context-Aware Occorre poi sottolineare l importanza della dimensione temporale, grazie alla quale è possibile pensare ad una vera e propria context history, utile per l identificazione e la previsione di pattern di comportamento degli utenti. Il contesto di un entità è caratterizzato da dati eterogenei, provenienti da numerose fonti. In base alla dimensione temporale si distinguono due categorie di parametri di contesto: - dati statici: sono fissi, oppure variano molto lentamente (dati anagrafici, ecc ). Sono solitamente ricavati dal profilo dell utente; - dati dinamici: localizzazione, velocità, dispositivi nelle vicinanze, ecc La loro cattura avviene di solito attraverso software attivo sul dispositivo mobile utilizzato dall utente. E possibile suddividere ulteriormente in gruppi di parametri necessari per definire il contesto di un utente: [1] (Figura 3.2.1) Figura 3.2.1: Gruppi di parametri per la definizione del contesto - user profile: identità e profilo dell utente; - spazio: posizione, direzione di movimento, velocità e accelerazione; - tempo: ora, data, stagione; - tipo di device: tipo di display, batteria, banda disponibile; - service profile; - ambiente: inteso come temperatura, rumore, inquinamento, ecc; - risorse nelle vicinanze: altri utenti, stampanti, videoproiettori, access point; - presence: la disponibilità all interazione (online/busy/on the phone); - misure fisiologiche: ad esempio la pressione sanguigna e arteriosa, il battito cardiaco ed il tono della voce; - attività in corso: come, ad esempio, parlare, leggere, camminare o correre. 19

20 Applicazioni Context-Aware 3.3 Scenari applicativi L obiettivo primario di un applicativo context aware è di adattarsi e fornire informazioni all utente in base al contesto in cui questo si trova. Tutto questo è reso possibile dalla capillarità della copertura della rete radiomobile e dalle nuove potenzialità introdotte dai recenti dispositivi mobili (PDA, smartphone, telefoni cellulari, ecc ). E possibile riassumere le tipologie di servizi context aware nelle seguenti classi: - Context Tagging automatico di contenuti personali e condivisione (ad esempio, fotoalbum o videoalbum, oppure blog contestualizzato generato automaticamente); - Service advertising permette di ottenere l elenco dei servizi personalizzati in base al contesto dell utente. In questo filone si inseriscono anche le applicazioni di pubblicità context-based. - Personal Communication avanzata, ovvero il trattamento delle chiamate e dei messaggi in base al contesto. - E-tourism, tramite la condivisione di informazioni contestualizzate tra utenti e l utilizzo di recommender per negozi, ristoranti, musei, locali notturni, ecc Queste tipologie di nuovi servizi rappresentano importanti scenari applicativi per la context awareness, e allo stesso tempo permettono all operatore di rete di sfruttare la grande mole di informazioni di contesto in suo possesso. E sufficiente pensare alle informazioni di posizione su base cella GSM/UMTS: grazie alle applicazioni contextaware è possibile utilizzare questi dati per fornire servizi innovativi agli utenti, senza la necessità di investire in una nuova infrastruttura di rete. Il generatore di blog oggetto del presente lavoro di tesi si inserisce proprio nello scenario dei servizi context-aware, grazie alle informazioni di contesto acquisite dalla piattaforma sviluppata presso il TILab (Capitolo 4). 20

21 Context-Aware Platform 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). 21

22 Context-Aware Platform Figura 4.2.1: CA Platform, architettura funzionale Il livello inferiore dell architettura (utilizzato dal generatore di blog per acquisire i dati grezzi) fornisce informazioni di contesto di basso livello ed è composto dai cosiddetti context enablers. Le fonti da cui si provengono i dati sono eterogenee: [4] - dispositivi mobili: PDA, smartphone, telefoni cellulari; - sensori intelligenti: sensori interfacciati col corpo umano (che, ad esempio, sono in grado di rilevare la frequenza del battito cardiaco), sensori ambientali di umidità, temperatura, luce, videocamere e sensori di movimento (basati su ricevitori GPS, accelerometri, bussole e giroscopi); - network enablers: ad esempio address book provider (rubrica centralizzata), location provider (capace di restituire al chiamante l indirizzo civico di una posizione), user proximity provider (restituisce l elenco degli altri utenti nelle prossimità), calendar provider (da cui è possibile ricavare informazioni sugli impegni in agenda dell utente). Questi componenti sono interrogati direttamente dal generatore di blog. 22

23 Context-Aware Platform Il core della piattaforma context aware ha il compito di ottenere informazioni di contesto più astratte a partire dai dati ricavati dagli enablers del livello sottostante. Si elencano di seguito i componenti più importanti di questo livello: - catalogues/profile management: modella e gestisce il profilo degli utenti e della loro social network (una rete di utenti interconnessi tra loro attraverso relazioni interpersonali di diverse tipologie, come amicizia, parentela, rapporti di lavoro, ecc...). Si occupa anche di fornire le informazioni sui device associati agli utenti e le rispettive caratteristiche tecniche; - context reasoning: sono i componenti che implementano le logiche di reasoning della piattaforma. Il componente si articola principalmente in due sotto livelli principali. Il recommender layer opera per mezzo di algoritmi di tipo collaborative filtering, trust aware, rule based, ecc Il context interpretation/aggregation layer, si occupa invece di estrarre informazioni di alto livello utilizzando algoritmi di clustering, pattern recognition, machine learning oppure lavorando con un approccio rule based. Per quanto riguarda le tecniche rule based, la strada seguita è stata quella di lavorare su un situation provider, un componente che si occupa di inferire situazioni astratte (a partire dai dati grezzi) utilizzando un processo di reasoning basato su un motore a regole; [3] - context brokering: si occupa di adattare le informazioni grezze alle necessità dei livelli superiori della piattaforma. Gestisce inoltre una cache dei dati e si occupa della gestione dello storico dei dati di contesto, la context history (vedere Capitolo 4.3). - exposure layer: è l interfaccia della piattaforma verso le applicazioni context aware vere e proprie. La piattaforma CA è alla base del livello applicativo, che racchiude i servizi e le applicazioni context aware destinate agli utenti finali (photo-sharing, videoblog contestualizzato, e-tourism, context aware advertising, ecc ) 4.3 Context Brokering: i componenti Il livello si occupa di adattare e riorganizzare le informazioni grezze di contesto per renderle disponibili ai piani superiori della piattaforma. (Figura 4.3.1). Si tratta di un architettura distribuita, i cui componenti sono ospitati su server differenti. Il Context Broker ha il compito di recuperare le informazioni di contesto da tutti i provider, mantenerle per un certo periodo in una context cache interna e distribuirle agli altri componenti della piattaforma. I dati raccolti dai provider sono eterogenei e provengono da molte fonti, quindi, per poter essere distribuiti, devono essere codificati in un formato comune sia al CB che a tutti gli altri provider. Si è così sviluppato un 23

24 Context-Aware Platform 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). 4.4 Context Provider Figura 4.3.1: Il Context Broker e i Provider della piattaforma. Alcuni componenti software della piattaforma ricoprono il ruolo di Provider. Queste entità forniscono un tipo (scope) di informazioni di contesto. Ogni context provider espone delle interfacce grazie alle quali il CB oppure altri consumer possono recuperare nuovi dati di contesto. Il generatore di blog contestualizzato, agendo come un Context Consumer [4], recupera le informazioni di contesto attraverso una richiesta esplicita al Context Provider desiderato: un consumer può infatti interrogare direttamente un provider, tramite i metodi esposti dalle interfacce di quest ultimo. La piattaforma permette di recuperare informazioni di contesto eterogenee. L elenco sottostante riporta le funzionalità dei CP più importanti: - Advanced User Profile (AUP): fornisce informazioni sul profilo dell utente. (Figura 4.4.1) [1] 24

25 Context-Aware Platform User Data User Profile User Preference User Device/ User Device Parameter User Service Profile User Places (Virtual Places) Service Catalog Device Capability Catalog Figura 4.4.1: informazioni fornite dall'aup - User Profile comprende l identità dell utente, informazioni finanziarie, abilità personali, inabilità psicofisiche e titoli di studio. - Le User Preference consistono invece in informazioni relative ai gusti musicali dell utente, generi letterari, sport, programmi televisivi, ecc - La parte di User Device/Device Parameter contiene informazioni sui dispositivi mobili registrati dall utente nel sistema e i relativi dettagli, come applicazioni aggiuntive, espansioni di memoria, ecc (l elenco completo delle possibili caratteristiche tecniche dei dispositivi è contenuto nel Device Capability Catalog). Un dispositivo può appartenere ad un solo utente per volta, ma un utente può registrare diversi device. - User service profile contiene invece informazioni sui tipi di servizi context aware a cui un utente si è registrato. Questi servizi possono essere gestiti e sviluppati dall operatore (media sharing, generatore di Blog Contestualizzato, ecc ) oppure servizi di terze parti come l upload di contenuti multimediali contestualizzati su Youtube o su FlickR (l elenco dei servizi abilitati è contenuto nel Service Catalog). - La parte relativa agli User Places (anche chiamati Virtual Places) contiene l elenco dei luoghi personali di ogni utilizzatore della piattaforma (Capitolo 5.2). Ad un utente è infatti permesso associare un etichetta ad una zona geografica desiderata (esempio: casa propria, ufficio, stadio,ecc ). - Location Provider (LP): data un informazione geografica di basso livello (coordinate GPS, identificativo di cella GSM/UMTS), ne restituisce l indirizzo, fornendo quindi via, città, codice postale, provincia (o entità analoghe in caso di paesi esteri) e stato. 25

26 Context-Aware Platform - 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 si rappresenta l architettura funzionale della piattaforma Context Awareness lato client. 26

27 Context-Aware Platform Figura 4.5.1: CA Platform lato client Dalla figura si riconoscono funzionalità analoghe alla parte server. Anche in questo caso l architettura logica è organizzata in tre livelli distinti: - Raccolta di dati di contesto: è la parte che si occupa di recuperare le informazioni di contesto di basso livello. E possibile ricavare i seguenti dati grezzi: - Sensor/Device info: dati provenienti dai sensori integrati nel dispositivo oppure a cui questo è collegato (fotocamera, antenna GPS, sensori fisiologici, ecc ); - Network info: dati ricavati dalla rete a cui il device è collegato (GSM/UMTS, Bluetooth, ecc ); - Integrated Location Info: dati di rete specifici per la localizzazione. Sono distinti per tipo di rete a cui il device è agganciato, e fanno quindi riferimento a piattaforme di risoluzione geografica diverse, anche queste sviluppate presso il TILab (es: NIMBLE, per quanto riguarda la localizzazione GSM/UMTS); - Presence SIP: modulo utilizzato per invio/ricezione di istant messaging e per comunicazione con il Context Broker lato server; - Address Book: informazioni inserite dall utente nella sua agenda personale sul device; - Eventuale Storage che può contenere, ad esempio, cartografia di terze parti. A partire da questi dati di base, è possibile ricavare, lato client, numerose funzionalità tecniche del dispositivo mobile in uso. E possibile così scoprire le 27

28 Context-Aware Platform capabilities del device, informazioni sull hardware e sul software correnti, i canali radio GSM/UMTS o WiFi disponibili. Si possono anche individuare altri dispositivi Bluetooth nelle vicinanze, i cui ID saranno risolti dalla parte server della piattaforma. Inoltre è possibile implementare meccanismi di triggering, per avvisare le user application del cambiamento di contesto dell utente in tempo reale. Infine, diventa possibile tracciare il dispositivo basandosi su tecnologie di rete diverse, ad esempio GSM/UMTS o Bluetooth, con un conseguente diverso livello di precisione. - Local Context Broker: è l elemento centrale dell architettura lato client. Le sue funzioni fondamentali comprendono: - raccogliere i dati grezzi di contesto raccolti nel livello sottostante; - agisce da unico punto di contatto verso il Context Broker lato server, a cui invia update di dati di contesto aggiornati e da cui riceve informazioni su come effettuare l update di questi dati verso la piattaforma CA; - agisce da unico punto di contatto anche verso le applicazioni utente in esecuzione sul dispositivo. - Application layer: è lo strato di applicazioni utente in esecuzione sul dispositivo portatile. Una funzionalità applicativa rilevante è il tagging di contenuti multimediali (foto, video, audio, documenti). Si associano a questi file meta-dati di contesto, in modo che risultino inscindibili dall informazione contenuta nel file stesso. E stata sviluppata inoltre un applicazione che permette all utente di gestire alcune policy. E possibile quindi modificare direttamente dal device impostazioni legate alla privacy, al profilo utente e all impostazione di altre applicazioni. L utente è inoltre in grado di gestire e di ottimizzare le policy di update delle informazioni di contesto verso il Context Broker lato server. 4.6 Il linguaggio ContextML Per ottenere la piena interoperabilità tra i Provider, il Context Broker e le applicazioni context aware, è necessario utilizzare un formalismo comune per la rappresentazioni delle informazioni, che, come visto,sono eterogenee tra loro. E stato così sviluppato il ContextML, un linguaggio XML-based per rappresentare le informazioni di contesto all interno della piattaforma CA. I Provider devono offrire informazioni utilizzando questo formalismo [4]. A causa della loro natura eterogenea, i dati di contesto sono stati raggruppati in scope. Ad esempio, lo scope position comprende le informazioni di latitudine e longitudine di una certa entità, mentre lo scope userprofile è composto dai dati del profilo dell utente. E possibile anche definire scope aggregati, che comprendono cioè più scope atomici. 28

29 Context-Aware Platform 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 riporta la risposta dell Advanced User Profile Provider (AUP), in linguaggio ContextML, alla richiesta del profilo dell utente lukostaz : 29

30 Context-Aware Platform <?xml version="1.0" encoding="utf-8"?> <contextml xmlns=" xmlns:xsi=" xsi:schemalocation=" <ctxels> <ctxel> <contextprovider id="aup" v="1.0.0"/> <entity type="username" id="lukostaz"/> <scope>userprofile</scope> <timestamp> t15:12:29+02:00</timestamp> <expires> t15: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"> t00:00:00+01:00</par> <par n="civilstatus">celibe</par> <par n="fiscalcode"> </par> <par n="nationality">italiana</par> </pars> </para> </datapart> </ctxel> </ctxels> </contextml> 4.7 Tecnologie usate Figura Profilo dell'utente lukostaz, ContextML La piattaforma di Context Awareness è caratterizzata da un architettura distribuita. Il context Broker e i Provider risiedono su server indipendenti. Per poter interagire con gli altri componenti, oltre all utilizzo del linguaggio ContextML, ogni modulo espone un interfaccia basata sullo stile architetturale HTTP-REST [7]. È possibile, oltre che invocare il Context Broker che fa da tramite e da aggregatore, anche invocare direttamente i provider. Utilizzare il design REST, caratterizzato da un interazione stateless tra client e server, permette di considerare il webservice come una vera e propria risorsa, identificata dal suo URL. Alle applicazioni che desiderano utilizzare il webservice (come, ad esempio, il generatore di Blog contestualizzato) viene offerto un set di metodi remoti che permettono di eseguire le azioni offerte dal webservice stesso. Applicazione client e webservice devono però essere d accordo out-of-band sul formato che descrive i 30

31 Context-Aware Platform dati (in questo caso il ContextML), in quanto REST non offre un modo formale per descrivere l interfaccia del webservice. Un importante vantaggio dell approccio REST accoppiato ad HTTP riguarda il limitato utilizzo di banda: i messaggi non vengono infatti appesantiti dallo strato SOAP, e ciò è importante in particolare per quanto riguarda i dispositivi mobili,caratterizzati da una disponibilità limitata di risorse. Occorre inoltre aggiungere che il design REST permette un implementazione più semplice dei componenti architetturali [2]. L interfaccia REST è fornita grazie ad una Servlet ed utilizza degli EJB che implementano i metodi del Provider e che permettono a quest ultimo di gestire un eventuale collegamento con sistemi di back end, garantendo inoltre una maggiore flessibilità in termini di architettura software. Il Context Broker, che utilizza la stessa tecnologia dei Provider, utilizza un database relazionale (MySQL) per gestire la Context Cache e i cataloghi degli scope e dei provider. 31

32 Context-Aware Platform 32

33 Raccolta e clustering dei dati di contesto 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). 33

34 Raccolta e clustering dei dati di contesto 5.2 Raccolta dei dati di contesto La raccolta dei dati di contesto avviene nei passi in Figura Cattura dei dati di contesto grezzi CH Incrocio con Virtual Places AUP CLUSTERING Completamento dei cluster LP UPP Figura Raccolta dei dati e Clustering CA Platform 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 :24: c6d6ff64;0006c6040e66 Timestamp GSM CGI Dispositivi Bluetooth nei paraggi Figura Dati di contesto grezzi Incrocio dei dati grezzi con Virtual Places: gli utenti della piattaforma CA possono etichettare celle GSM, indirizzi Bluetooth e zone delimitate da coordinate GPS come luoghi notevoli (Virtual Place). Ogni VP appartiene ad 34

35 Raccolta e clustering dei dati di contesto una categoria ben definita, in conformità allo standard definito nella RFC 4480 [7] (es: residence, office, school, ecc ). Inoltre ai VP è associata una descrizione, scelta dall utente (Figura 5.2.3). office cgi-gsm TILab Categoria Tecnologia usata Elemento da etichettare Descrizione Figura Virtual Place Utilizzare Virtual Place definiti su tecnologie di localizzazione diverse (in questo caso GSM e Bluetooth) permette di definire Virtual Place annidati: un VP definito su una o più celle GSM può ad esempio contenerne un altro legato ad un identificativo Bluetooth (Figura 5.2.4). My office Canteen TILab Figura Virtual Place muti-tecnologia annidati L etichettatura di intere zone in cui l utente ha soggiornato (oppure è transitato) può semplificare notevolmente il compito degli algoritmi di clustering e contribuisce ad un analisi più precisa delle attività dell utente. Ad esempio, un luogo con superficie molto ampia, come un università, può essere coperto da più celle GSM: se l utente etichetta queste celle come appartenenti allo stesso Virtual Place, l algoritmo di clustering le aggregherà, lavorando con l informazione aggiunta dall utente. Definire Virtual Place aiuta anche a mitigare il fenomeno di switch spuri tra celle (Capitolo 5.3). L Advanced User Profile, AUP (Capitolo 4.4), è il componente che contiene l elenco dei Virtual Place degli utenti. Gli elementi di contesto ricavati dalla Context History sono quindi incrociati con i VP di ogni utente, tramite 35

36 Raccolta e clustering dei dati di contesto 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). <?xml version="1.0" encoding="utf-8"?> <contextml xmlns=" xmlns:xsi=" xsi:schemalocation=" <ctxels> <ctxel> <contextprovider id="aup" v="1.0.0"/> <entity type="username" id="lukostaz"/> <scope>uservirtualplace</scope> <timestamp> t14:33:39+02:00</timestamp> <expires> t14: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"> </par> <par n="placename">home</par> </pars> <pars n="virtualplace"> <par n="placetype">office</par> <par n="placeinfotype">cgi-gsm</par> <par n="placeinfo"> </par> <par n="placename">tilab</par> </pars> </para> </datapart> </ctxel> </ctxels> </contextml> Figura Virtual Place di un utente in codifica ContextML Completamento dei Cluster: dopo aver eseguito il raggruppamento delle informazioni di contesto con gli algoritmi descritti in seguito (Capitoli 5.5 e 5.6), si procede con la rifinitura delle informazioni dei cluster ottenuti. In primo luogo si procede con la risoluzione in indirizzo civico degli identificativi di cella GSM. La piattaforma mette a disposizione il Location Provider, LP. Questo componente è in grado di restituire l indirizzo civico di una Base Station a partire dal CGI (Cell Global Identify) di quest ultima (Figura 5.2.6). 36

37 Raccolta e clustering dei dati di contesto <?xml version="1.0" encoding="utf-8"?> <contextmlxmlns=" xmlns:xsi=" instance"xsi:schemalocation=" <ctxels> <ctxel> <contextprovider id="lp" v="1.1.6"/> <entity id="unknown" type="unknown"/> <scope>position</scope> <timestamp> t15:47:40+02:00</timestamp> <expires> t15:49:40+02:00</expires> <datapart> <par n="latitude"> </par> <par n="longitude"> </par> <par n="accuracy">541</par> <par n="locmode">nimblecgi</par> <par n="room"/> <par n="corridor"/> <par n="floor"/> <par n="building"/> <par n="street">via Guglielmo Reiss Romoli 239 </par> <par n="postalcode">10148</par> <par n="city">torino</par> <par n="subdivision">to</par> <par n="country">italy</par> </datapart> </ctxel> </ctxels> </contextml> Figura Risoluzione della cella Ogni cluster contiene una lista di identificativi Bluetooth, che elenca tutti i dispositivi che si sono trovati nelle vicinanze dell utente durante il periodo di tempo indicato. La lista contiene gli id di tutti i dispositivi Bluetooth nei paraggi dell utente che hanno volontariamente scelto di rendersi visibili e che quindi non nascondono il proprio identificativo. Ad ogni utente della piattaforma sono associati dei device personali (nel profilo di un utente, AUP). Lo User Proximity Provider (UPP) permette di associare il nome di una persona ad un identificativo bluetooth della lista, garantendo quindi di ottenere l elenco dei buddy incontrati in un cluster. Ovviamente questi individui devono essersi volontariamente registrati in precedenza presso la piattaforma CA. Il provider restituisce non solo il nome della persona incontrata, ma anche la relazione che l utente ha con questi individui: friend, colleague, ecc (Figura 5.2.7). E prevista in futuro un estensione che permetterà di inserire nei propri blog post soltanto alcune categorie di utenti: ad esempio, sarà possibile visualizzare i nomi dei propri amici ma non quelli dei colleghi. Si rimanda al Capitolo 6.5 per maggiori informazioni. 37

38 Raccolta e clustering dei dati di contesto <?xml version="1.0" encoding="utf-8"?> <contextml xmlns=" xmlns:xsi=" xsi:schemalocation=" /schemas/contextml-1.1.xsd"> <ctxels> <ctxel> <contextprovider id="upp" v="1.0.0"/> <entity id="lukostaz" type="username"/> <scope>userproximity</scope> <timestamp> t15:18:29+02:00</timestamp> <expires> t15: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> Figura 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 vediamo il formato tipico dei dati di contesto con cui lavorano gli algoritmi di clustering : office,tilab ownoffice,b1043 Oscar,friend; Timestamp GSM CGI Virtual place Virtual Place Nearby CGI Bluetooth buddies Figura Formato dei dati di contesto incrociati Come spiegato nel Capitolo 5.2, il generatore di blog ricava le informazioni di contesto dai provider della piattaforma. La CA Platform riceve ed elabora i context 38

39 Raccolta e clustering dei dati di contesto update dai terminali associati agli utenti equipaggiati con il client TeamLife (Capitolo 4.5). Frequenza degli update Il client effettua update di dati di contesto con una frequenza non costante nel tempo, che dipende dalle policy di update scelte dall utente. Il terminale comunica con la piattaforma nelle seguenti situazioni: - Cambio di contesto: il device si aggancia ad una base station diversa, quindi è necessario comunicare il nuovo CGI al server. - Refresh Periodico: il client rinfresca periodicamente il proprio contesto, anche nel caso in cui ci si trova in condizioni statiche. Due parametri configurabili dall utente controllano la frequenza degli update: - Bluetooth scan interleaving: espresso in secondi, è il periodo che intercorre tra gli aggiornamenti relativi alla presenza di device bluetooth nei paraggi. - Cell cycle: è un intero che, moltiplicato con il Bluetooth Scan Interleaving, definisce l intervallo in secondi con cui il device effettua un update della cella CGI-GSM. Gli algoritmi di clustering sviluppati tengono in considerazione le possibili differenze di impostazioni tra i terminali, in particolare per quanto riguarda la frequenza degli update di contesto (che, inoltre, può essere modificata dall utente direttamente dal device). Ad esempio, discriminare tra una situazione di movimento e una statica può essere più o meno semplice a seconda della frequenza del refresh del contesto (Capitolo 5.4). Occorre inoltre considerare che, durante una giornata, possono esserci dei periodi in cui non si sono verificati update di contesto. L utente può infatti spegnere il proprio device per un certo periodo di tempo, può disattivare il client oppure può trovarsi in un area non coperta dalla rete GSM/UMTS. Tipi di location I dati di contesto seguono un andamento diverso a seconda del luogo in cui l utente si trova. È utile analizzare due situazioni distinte, all interno delle quali si analizza sia il caso in cui l utente è fermo, sia il caso in cui è in movimento. - Aree urbane: la concentrazione di Base Station GSM/UMTS è maggiore e le singole celle hanno un raggio di copertura di qualche centinaio di metri. In questo caso la localizzazione su base cella sarà ovviamene più precisa. - Situazioni statiche: in una zona densamente abitata le Base Station si sovrappongono ed è più probabile trovarsi a cavallo tra molte celle. Nonostante l utente sia fermo in un luogo ben preciso è molto probabile che il suo terminale non rimanga sempre agganciato alla stessa Base Station. Si verificano cambi tra celle più o meno rapidi, 39

40 Raccolta e clustering dei dati di contesto che complicano l analisi e il raggruppamento dei dati. Rilevare la staticità di un utente in questi casi è più complesso (Figura 5.3.2) :42: :41: :41: :40: :39: :39: :38: :36: :36: :36: :35: :35: :33: :33: Figura 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 :01: :01: :01: :57: :57: :56: :55: :54: :54: :54: :53: :52: :52: :51: :50: :49: Figura Distribuzione dei dati di contesto in caso di spostamento rapido 40

41 Raccolta e clustering dei dati di contesto - 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) :02: office,tilab :59: office,tilab :55: office,tilab :52: office,tilab :48: office,tilab :45: office,tilab :42: office,tilab :38: office,tilab :37: office,tilab :27: office,tilab :58: n/a,n/a :56: n/a,n/a :56: n/a,n/a :54: n/a,n/a :51: n/a,n/a :49: n/a,n/a :48: n/a,n/a :48: n/a,n/a :47: n/a,n/a :47: n/a,n/a :46: n/a,n/a :46: n/a,n/a :45: n/a,n/a :44: n/a,n/a :42: n/a,n/a :42: n/a,n/a :40: residence,home :36: residence,home :33: residence,home :29: residence,home :26: residence,home :22: residence,home :19: residence,home :16: residence,home :12: residence,home :09: residence,home :05: residence,home Cluster 1 (Statico) Start 08:58 End 11:02 CGI VP CGI VP Bth Office, TILab Not available Cluster 2 ( Movimento) Start 08:42 End 08:56 CGI From CGI To VP CGI From Residence, home VP CGI To Office, TILab VP Bth Not available Cluster 3 (Statico) Start 08:05 End 08:40 CGI VP CGI Residence, home VP Bth Not available Figura Il processo di clustering dei dati di contesto 41

42 Raccolta e clustering dei dati di contesto Le dimensioni interessate nel raggruppamento sono due: il tempo e la posizione. Il generatore di blog contestualizzato deve rilevare sia situazioni statiche che dinamiche. E quindi necessario definire due tipologie di cluster: i cluster statici e quelli di movimento. Un cluster statico è caratterizzato dai seguenti attributi: - Timestamp di inizio e di fine - GSM-CGI della cella eletta come centro del cluster - Virtual Place CGI legato al CGI in precedenza scelto come centro del cluster (se presente) - Virtual Place Bluetooth (se presente) - Elenco delle persone incontrate (se presente) Un Cluster di movimento ha invece queste caratteristiche: - Timestamp di inizio e di fine - GSM-CGI della cella di partenza - GSM-CGI della cella di arrivo - Virtual Place CGI della cella di partenza (se presente) - Virtual Place CGI della cella di arrivo (se presente) - Virtual Place Bluetooth che identifica il mezzo di trasporto utilizzato. Una situazione di movimento può infatti essere accompagnata da un identificativo bluetooth che indica il tipo di veicolo utilizzato nello spostamento, ad esempio la propria auto, un treno, un bus, ecc (Capitolo 6.2). - Elenco delle persone incontrate (se presente) Come detto in precedenza, il processo di raggruppamento avviene rispettando l ordinamento cronologico degli update di contesto. Occorre ovviamente che le tecniche di raggruppamento operino anche sulla posizione geografica dell utente. Sia la localizzazione GSM-CGI che quella basata sull etichettatura dei Virtual Place sono effettuate a partire da attributi categorici (stringhe). Non è quindi possibile operare con tecniche di clustering tradizionali (ad esempio, K-Means [33]) che raggruppano gli elementi in base alla distanza euclidea, in quanto non è possibile definire un concetto di distanza sia tra identificativi GSM-CGI che tra le etichette dei Virtual Place. Inoltre, utilizzare algoritmi di clustering noti in letteratura che operano esclusivamente su attributi categorici (es: ROCK, [32]) sarebbe scorretto, perché si ignorerebbe la dimensione temporale, di cui si deve invece tenere conto per mantenere la cronologia degli eventi. E stato quindi necessario sviluppare un algoritmo ad hoc, che soddisfi tutte le esigenze elencate in precedenza. L analisi delle Context History degli utenti, ha portato alla decisione di sviluppare due algoritmi diversi, che differiscono sia per situazioni di utilizzo, che per precisione dei risultati. 42

43 Raccolta e clustering dei dati di contesto 5.5 Algoritmo Compare&Merge L algoritmo analizza le entry di contesto nell ordine con cui queste sono restituite dalla piattaforma (dalla più recente alla più vecchia). In questo modo si evita un ulteriore ri-ordinamento della lista, che è tipicamente composta, nel caso di una giornata tipo, da centinaia di record. E possibile raggruppare le informazioni basandosi su GSM-CGI, oppure, se impostati dall utente, si può operare a livello di Virtual Place CGI o Bluetooth, trascurando in questo modo i problemi introdotti dalla tecnologia di localizzazione su base cella (Capitolo 5.3). La procedura di raggruppamento dei dati si articola in due passi fondamentali: 1. Scansione preliminare della Context History dell utente e aggregazione delle entry vicine temporalmente con stessa location (Figura 5.5.1). foreach ContextEntry ce{ if (ce.location == clustertemp.location) clustertemp.addcontextentry(ce); else{ templist.add(clustertemp ); clustertemp = new Cluster(ce); } } return templist; Figura Scansione preliminare delle entry di contesto In questo passo si individuano le situazioni statiche non ambigue, cioè i casi in cui l utente ha effettuato degli update di contesto consecutivi con posizioni uguali (stesso CGI, oppure un gruppo di celle GSM o identificativi Bluetooth etichettati con lo stesso Virtual Place). Analizzando i pattern dei dati di contesto, è infatti emerso che nella maggior parte dei casi, questa è una delle situazioni più frequenti e significativa per l utente: è quindi molto importante identificarla correttamente. Al termine dell analisi preliminare si ottiene una lista formata da due tipologie di cluster temporanei: - Cluster con durata lunga: identificano sicuramente una situazione statica. - Cluster brevi e consecutivi, composti da poche entry di contesto: possono far parte di una situazione di movimento, oppure l utente si trova in condizioni di staticità, ma con frequenti switch di cella (Capitolo 5.3). 2. Merge dei cluster temporanei consecutivi brevi per creare, eventualmente, cluster di movimento. Si analizza la lista dei cluster temporanei creata al punto 1 e la si trasforma nell elenco dei cluster definitivi. Ci si sofferma in particolare sull elenco dei 43

44 Raccolta e clustering dei dati di contesto 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 descrive lo pseudocodice della parte principale del metodo. foreach Cluster currcluster{ // se cluster breve if (currcluster.duration < durationthreshold){ tempcluster.extend(currcluster); } // se cluster lungo else{ // se troppo poche posizioni diverse if (tempcluster.locationscount < locationsthreshold) tempcluster.moving = true; finallist.add(tempcluster); finallist.add(currcluster); } } return finallist; Figura Merge dei cluster temporanei brevi In Figura si notano due parametri importanti utilizzati dall algoritmo: - durationthreshold è la durata minima che un cluster deve avere per poter essere aggiunto alla lista finale. Attraverso questa soglia è possibile comunicare al generatore di blog che si desidera tenere traccia soltanto di eventi abbastanza lunghi. Situazioni di durata inferiore alla soglia vengono inglobate in cluster più ampi. Modificando il parametro è possibile quindi scegliere il livello di dettaglio desiderato. - locationsthreshold è invece la soglia legata alle diverse posizioni geografiche che un cluster può contenere. Se le posizioni diverse sono molte, allora si tratta di una situazione di movimento. La scelta di questo parametro dipende non solo dall area geografica in cui l utente si trova (Capitolo 5.3) ma anche dalle preferenze e dalle abitudini dell utente stesso (Capitolo 5.7) Caratteristiche principali Le caratteristiche più importanti dell algoritmo sono riassunte nell elenco sottostante: - Nel caso in cui l utente abbia effettuato un etichettatura diffusa e precisa dei luoghi preferiti, si ottiene una precisione elevata. Le situazioni vengono 44

45 Raccolta e clustering dei dati di contesto 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). 45

46 Raccolta e clustering dei dati di contesto Sliding window, Iterazione 1 (durata: 24 minuti) :02: office,tilab :59: office,tilab :55: office,tilab :52: office,tilab :48: office,tilab :45: office,tilab :42: office,tilab :38: office,tilab :37: office,tilab :27: office,tilab :58: n/a,n/a :56: n/a,n/a :56: n/a,n/a :54: n/a,n/a :51: n/a,n/a :49: n/a,n/a :48: n/a,n/a :48: n/a,n/a :47: n/a,n/a :47: n/a,n/a :46: n/a,n/a :46: n/a,n/a :45: n/a,n/a :44: n/a,n/a :42: n/a,n/a :42: n/a,n/a :40: residence,home :36: residence,home :33: residence,home :29: residence,home Sliding window, Iterazione 2 (durata: 57 minuti) Figura Sliding Window (durata massima della finestra: 60 minuti) La finestra temporale ha lunghezza massima fissa, determinata da un parametro espresso in minuti. Nel caso della Figura 5.6.1, questo valore è di 60 minuti. La prima entry di contesto dell esempio è delle ore 11:02:33. La finestra scorrevole selezionata può lavorare su entry non più vecchie delle ore 10:02:33 (la durata massima permessa è di 60 minuti). I dati dell esempio hanno però un buco, dalle ore 10:37:47 alle 09:27:01 (l utente potrebbe aver spento il terminale). L ultimo dato che può far parte della prima iterazione della finestra è quindi quello datato 10:37:47, in quanto, per scelta progettuale, l algoritmo non inferisce la posizione dell utente in assenza di update di contesto. Il dato successivo, datato 09:27:01 genererebbe una finestra di durata superiore ai 60 minuti concessi: occorre quindi fermarsi alle ore 10:37:47. La durata della prima finestra sarà di 24 minuti. Al momento dello spostamento, la sliding window partirà dalla prima entry esclusa, quella delle ore 09:27:01 e, in modo analogo 46

47 Raccolta e clustering dei dati di contesto 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 descrive il metodo principale dell algoritmo: // creo finestra iniziale List windowelements = getwindowelements(0); // ciclo sugli elementi di contesto while (windowelements.size() > 0){ level = detectlevel(); ismoving = detectmovement(); centre = detectcentre(level); if ( comparecentres(centre,clutemp,level) && getgaptimespan(clutemp,windowelements)< offlinetimespan){ // estendo il cluster temporaneo corrente clutemp = extendclutemp(windowelements); }else{ // salvo cluster temporaneo corrente clusterlist.add(clutemp); // creo nuovo cluster temporaneo clutemp = converttocluster(windowelements); } // faccio avanzare la finestra windowelements = getwindowelements(windowelements.size()); } smooth(); return clusterlist; Figura MLSW, metodo principale Dopo aver creato una finestra della durata desiderata, si analizzano gli elementi di contesto che questa contiene con i seguenti metodi: 47

48 Raccolta e clustering dei dati di contesto - detectlevel(): per ogni finestra, l algoritmo individua il livello a cui deve lavorare. Si analizzano tutti gli elementi della finestra: se una certa percentuale ha impostato il Virtual Place Bluetooth, si opera a questo livello. Altrimenti, si ricade sul livello a priorità inferiore, i Virtual Place CGI. Se anche in questo caso non c è un numero sufficientemente alto di entry con questo valore impostato, si ripiega sull identificativo di cella (CGI) che, comunque, è sempre presente. La percentuale minima ottimale di entry con la stessa posizione è stata scelta grazie a tentativi successivi: inizialmente si è impostato il limite ad una percentuale del 70%, ma si tratta di un valore troppo elevato. I dati di contesto, anche a causa del problema degli switch di cella (Capitolo 5.3), necessitano di percentuali molto più tolleranti. Prove successive hanno dimostrato che l algoritmo funziona in modo ottimale con una percentuale di soglia pari ad un terzo delle entry totali della finestra (33%). Questo valore è comunque modificabile, nel caso si decidesse di utilizzare l algoritmo in modo più restrittivo. E bene ricordare però che valori alti di questo parametro rendono Multilevel Sliding Window più sensibile ai problemi di switch spuri di celle. - detectmovement(): la funzione rileva se la finestra sta evidenziando una situazione di movimento, lavorando esclusivamente a livello CGI. E infatti sembrato fondamentale rilevare spostamenti su scala geografica, mentre è trascurabile ai fini della generazione del blog scoprire movimenti interni ad una cella individuati da una successione rapida di diversi Id Bluetooth (es: si è deciso di non considerare situazioni di movimento tra due stanze equipaggiate con due diversi beacon Bluetooth). Per rilevare del movimento, si associa un contatore ad ogni CGI trovato nella finestra. Se nessuna posizione ricorre per più di un terzo delle entry totali, ci troviamo in una situazione di movimento (questo valore è stato ritenuto il più ragionevole, ma può comunque essere modificato) (Figura 5.3.3). - detectcentre() individua la posizione più frequente all interno della finestra. La funzione lavora al livello selezionato da detectlevel(), e può quindi ritornare un Virtual Place Bluetooth/CGI oppure un identificativo CGI. Ad ogni iterazione, gli elementi di una finestra sono inseriti nel cluster temporaneo precedentemente creato solo se la posizione eletta come centro della finestra è la stessa del centro del cluster temporaneo stesso. Si controlla inoltre che dal termine del cluster temporaneo all inizio della nuova finestra non sia trascorso un tempo più lungo di un parametro predefinito. In base ai test effettuati si è scelto di impostare questo valore ad un ora, ma è comunque possibile modificarlo. E infatti lecito supporre che un periodo di tale durata senza ricevere update di contesto dia origine ad un nuovo cluster, poiché sarebbe troppo sommario inferire la posizione in cui l utente si è trovato per un lasso di tempo così lungo. 48

49 Raccolta e clustering dei dati di contesto Intervalli temporali senza informazioni di contesto non sono quindi descritti da alcun cluster. Smooth() si occupa di armonizzare le sequenze di cluster statici e di movimento, facendo combaciare, (se è possibile) la posizione di arrivo e di partenza delle situazioni di movimento con i luoghi in cui l utente ha stazionato nei cluster che seguono o precedono lo spostamento. Caratteristiche principali Le caratteristiche più importanti dell algoritmo possono essere riassunte nei seguenti punti: - MLSW è particolarmente efficace nei casi di situazioni statiche, con molti switch di cella. La presenza della finestra scorrevole mitiga infatti l effetto dei saltellamenti da una cella all altra. - E in grado di individuare cluster di movimento. - E possibile configurare a piacere il numero di livelli gestibili e le loro rispettive priorità. - E utile soprattutto nei casi in cui gli utenti non abbiano creato molti Virtual Place, in particolare nelle aree urbane fittamente coperte da celle GSM/UMTS. - L algoritmo è meno preciso rispetto a Compare&Merge per quanto riguarda le decisioni prese sull inizio e la fine dei cluster. Maggiore è la dimensione della finestra scorrevole, maggiore sarà l errore commesso nello stabilire i margini di un cluster. Una finestra di breve durata permette di lavorare con una maggiore precisione ma, allo stesso tempo, non dà la possibilità di ignorare i cluster più brevi, come i piccoli spostamenti oppure le soste nei pressi di access point Bluetooth etichettati come Virtual Place dall utente (Capitolo 5.7). - Come anticipato nel punto precedente, l algoritmo MLSW permette di ignorare le situazioni più brevi (e quindi trascurabili ai fini della generazione del blog). Per ottenere questo risultato è sufficiente impostare una lunghezza della finestra adeguata. La natura dell algoritmo non permette però di impostare direttamente una durata minima per i cluster, come accade invece in Compare&Merge. 49

50 Raccolta e clustering dei dati di contesto Figura riassume le caratteristiche principali di entrambi gli algoritmi sviluppati: Compare&Merge Multilevel Sliding Window Tipologia Parametri utilizzati per il raggruppamento Raggruppamento di attributi categorici con gestione della dimensione temporale. GSM/UMTS CGI, Bluetooth, Virtual Place impostati dall utente. Identificazione situazioni di movimento Situazione di utilizzo ottimale Situazioni critiche Precisione Durata minima delle situazioni identificate Sì Situazioni note (presenza di Virtual Place, celle GSM senza particolari problemi di switch, ecc ) Casi di switch spuri tra celle in situazioni statiche Molto buona nelle situazioni ottimali (inferiore ad un update di contesto). Impostabile dall utente Sì Giornate vissute in luoghi anche non etichettati da Virtual Place. Nessuna in particolare Dipende dalle dimensioni della finestra scorrevole. Una window lunga 30 minuti garantisce errori contenuti (< 10 minuti). Non direttamente impostabile. Dipende in modo indiretto dalle dimensioni della finestra scorrevole Figura Caratteristiche principali degli algoritmi a confronto Nello sviluppare gli algoritmi di clustering, non si è tenuto conto del tempo di esecuzione. Questo aspetto non è così importante per il generatore di blog. I set di dati di contesto su cui gli algoritmi operano sono composti infatti da qualche centinaio di record. Lavorare con dataset di queste dimensioni non vincola lo sviluppatore a cercare soluzioni particolarmente orientate alle prestazioni. Come già anticipato (Capitolo 5.2), il collo di bottiglia del processo di generazione di un blog post è la fase di raccolta dei dati dalla piattaforma CA. 5.7 Il clustering e la percezione dell utente L analisi della giornata di un utente tramite tecniche di raggruppamento dei dati di contesto, spinge a formulare alcune considerazioni. Il generatore di blog e gli algoritmi sviluppati hanno l obiettivo di ricostruire la giornata in modo che questa sia il più possibile simile alla percezione e ai ricordi dell utente. L utilizzo del software su un gruppo di utenti per alcuni mesi ha permesso di capire che, per ottenere un buon risultato finale, occorre tenere in considerazione i seguenti aspetti: 50

51 Raccolta e clustering dei dati di contesto 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 minuti, permette comunque di ricalcare fedelmente le azioni compiute durante una giornata. Durata minima dei cluster Il testing dell applicazione ha permesso di tarare gli algoritmi in modo da scartare i cluster troppo brevi. Il problema è presente in particolare nel caso in cui l utente stazioni ripetutamente per brevi periodi in Virtual Place Bluetooth, quindi poco estesi (es: un palazzo in cui ogni ufficio è equipaggiato con il proprio beacon Bluetooth). Le persone tendono infatti a trascurare gli spostamenti o le soste non abbastanza lunghe. Nella maggior parte dei test effettuati, gli utenti sembrano dare poca rilevanza alle situazioni con durata inferiore ai 30 minuti. Alzare eccessivamente questa soglia significa invece perdere troppi dettagli significativi. Dipendenza dal provisioning utente Entrambi gli algoritmi di clustering sviluppati sono in grado di operare su dati di contesto generati senza l intervento dell utente. Dall utilizzo dell applicativo è però emerso che l efficacia del raggruppamento (in particolare se si utilizza Compare&Merge) aumenta notevolmente con il numero di Virtual Place impostati. Un set esteso di VP permette infatti di mitigare i problemi causati dalla localizzazione 51

52 Raccolta e clustering dei dati di contesto basata su GSM/UMTS (Capitolo 5.3). Gli algoritmi si comportano quindi meglio se utilizzati in situazioni note, etichettate dall utente con i Virtual Place adatti (esempio, le giornate lavorative, passate tra casa e ufficio). Inoltre, il provisioning dell utente è utile per assegnare ad ogni luogo una categoria corretta (Capitolo 6.5). Individuare il movimento Come già spiegato nella descrizione degli algoritmi, la decisione di creare una situazione di movimento avviene nel caso in cui il cluster possieda un numero di posizioni diverse superiore ad una certa soglia. Nello scegliere questo parametro è importante tenere conto di come gli utenti percepiscono il movimento. Ad esempio, alcune persone non considerano come spostamento una passeggiata in centro città, ma la cluster analysis in questo caso potrebbe etichettare la situazione come un movimento. Inoltre i pattern dei dati di contesto variano molto in base alla velocità degli spostamenti: movimenti rapidi sono identificati da una chiara sequenza di identificativi di cella diversi, mentre quelli lenti (ad esempio una passeggiata) sono più ambigui (Capitolo 5.3). In base all esperienza maturata in questi mesi, sembra ragionevole utilizzare una soglia di 5 CGI diversi per Compare&Merge (Capitolo 5.5), mentre è opportuno che nessuna entry della finestre di MSLW abbia una frequenza superiore al 33% (Capitolo 5.6). Inter-cluster gap E possibile, per alcuni motivi, che la piattaforma non riceva update di contesto per un certo periodo. Il terminale o il client possono infatti essere disattivati dall utente per il lasso di tempo desiderato. Al termine di una situazione del genere (ovviamente, il problema si pone in caso di stazionarietà) è ancora lecito considerare le nuove entry di contesto come parte del vecchio cluster? Gli algoritmi prendono in considerazione questa situazione, attraverso soglie che definiscono la durata massima accettabile di questi periodi senza update; tipicamente questi valori corrispondono a 60 minuti. Oltre questa soglia si crea un nuovo cluster anche se la posizione è la stessa del gruppo di entry precedente. Come già anticipato in precedenza (Capitolo 5.6), gli intervalli temporali senza informazioni di contesto non sono descritti da alcun cluster. 5.8 Implementazione Il processo di acquisizione delle informazioni di contesto dalla piattaforma CA e gli algoritmi di raggruppamento dei dati sono implementati come classi Java. 52

53 Generazione e pubblicazione dei blog post 6 Generazione e pubblicazione dei Blog Post 6.1 Introduzione In seguito alla fase di raccolta dei dati di contesto e di clustering (Capitolo 5), occorre generare il blog post vero e proprio. Effettuare questa operazione prevede alcuni passaggi (Figura 6.1.1). Per prima cosa si analizza l organizzazione del testo di un blog post, con particolare enfasi sulle strutture sintattiche che lo compongono. Si descrivono in seguito le tecniche utilizzate per trasformare in testo naturale i dati contenuti nei cluster di contesto. L implementazione di questo passaggio avviene attraverso l utilizzo di un Natural Language Generator (NLG). Alcune informazioni presenti nel testo del blog post (indirizzi, persone nelle vicinanze dell utente) sono inoltre arricchite tramite l uso di particolari strutture di markup semantico note come Microformats. Una volta creato il testo, è necessario aggiungere i contenuti multimediali acquisiti dall utente durante la sua giornata. Il generatore di blog è così integrato con le informazioni provenienti dal portale di media sharing TeamLife, un altra applicazione sviluppata nel progetto di Context Awareness [23]. Infine, occorre pubblicare i post sul web: in questo caso si utilizza una piattaforma per il personal blogging in grado di gestire una community di utenti, Wordpress Multi User: grazie a questo software, ogni utente può dispone del proprio blog contestualizzato. 53

54 Generazione e pubblicazione dei blog post Blog Post Generation NLG Context Cluster User preference s 6.2 La struttura del testo Figura La generazione dei blog post, schema generale Per generare un blog post è necessario convertire i cluster di contesto in frasi in linguaggio naturale. Frasi statiche Context Clusters Action Detector Frasi statiche (compl. ogg) Realiser Frasi di Movimento Testo Naturale Figura Processo di generazione del testo naturale Questo passaggio necessita della definizione di alcuni costrutti standard. È possibile distinguere tre tipi di strutture, in base al tipo di azione eseguita dall utente: - Statiche: la persona è stata ferma in un luogo per tutta la durata del cluster. È il caso più frequente e viene generato a partire da un cluster statico. Il costrutto assume la struttura in (Figura 6.2.2). Come spiegato successivamente, il verbo scelto dipende dal tipo del luogo in cui l utente si è trovato Soggetto Verbo Luogo Durata, inizio e fine Buddies I stayed at home for 4 hours, from 18:43 to 22:52, and there I met Marco. Figura Situazione statica 54

55 Generazione e pubblicazione dei blog post - Statiche con complemento oggetto: l utente è stato fermo in un luogo e ha partecipato ad un evento di durata pari a quella del cluster (es: riunione, convegno, lezione, ecc ). È generato a partire da un cluster statico. Soggetto Verbo Compl. Oggetto Luogo Buddies Inizio e Fine I had a four hour lesson in classroom 4 with Marco, from 10:30 to 14:30. Figura Situazione statica con complemento oggetto - Movimento: l utente si è spostato da un luogo ad un altro. Ovviamente questa tipologia di costrutti sintattici è generata a partire da un cluster di movimento. Soggetto Verbo Provenienza Destinazione Mezzo Durata, Inizio e Fine Buddies Luca and I moved from home to my office by car for one hour, from 08:27 to 09:28, and there I met Antonio. Figura Situazione di movimento È utile elencare le caratteristiche principali dei blocchi che compongono le frasi di un blog post: Verbi Per scegliere il verbo associato ad un cluster occorre analizzare due diversi fattori: il movimento e la possibile presenza di Virtual Place impostati dagli utenti. - Presenza di movimento: in una situazione dinamica è necessario un verbo che descriva il tipo di movimento dell utente. Si utilizza il predicato generico move. Se il cluster ha un Virtual Place Bluetooth (che, nelle situazioni di movimento identifica il mezzo di trasporto utilizzato) sarebbe però possibile utilizzare altri verbi più specifici. Ad esempio per un automobile si potrebbe utilizzare drive. Non è purtroppo possibile capire se l utente sta veramente guidando oppure è un passeggero. Per non creare una frase semanticamente errata, occorre utilizzare sempre il verbo più generico possibile (move). Per specificare il mezzo di trasporto si utilizza un complemento indiretto ad hoc. - Virtual Place: se non è presente un VP, si utilizza il verbo generico stay. Se invece un cluster statico possiede un VP occorre analizzarne il Place Type. Ogni luogo virtuale appartiene infatti ad una categoria ben precisa, come specificato in RFC 4480 [7] (Capitolo 5.2). Ad ogni tipo di VP è associato un verbo diverso, corrispondente all azione più probabile compiuta dall utente in quel luogo (Figura 6.2.5). 55

56 Generazione e pubblicazione dei blog post airport wait bar enjoy cafe relax office work hotel rest shopping-area shop default stay Buddies Figura 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. Se l utente ha incontrato altre persone registrate nella piattaforma, è necessario introdurre un complemento di compagnia. I cluster contengono infatti le informazioni relative ai buddies (Capitolo 5.2). Ai fini di migliorare l accuratezza del testo, occorre verificare la frequenza con cui un altro utente appare nel cluster. Se un buddy è presente solo per una piccola percentuale di tempo, significa che si tratta di un semplice incontro. Una percentuale molto alta dimostra invece che la persona ha partecipato in modo prolungato all azione. Occorre quindi differenziare queste due situazioni con costrutti sintattici diversi: - Frequenza bassa: si appende una frase subordinata con l elenco delle persone incontrate durante l azione ( and I met Luca, Oscar and Walter ). - Frequenza alta: le persone che hanno partecipato per molto tempo all azione sono aggiunte nel soggetto della frase ( Luca, Oscar, Walter and I worked in my office for 8 hours. ). Viene spontaneo impostare la soglia di frequenza su valori molto elevati (ad esempio, 90%). Durante la fase di testing del software questa assunzione è stata però smentita. Il ricordo che le persone hanno della loro giornata è tale per cui, affinché un altro utente sia considerato come protagonista dell azione è sufficiente che superi soglie molto più basse. Numerosi tentativi in varie situazioni hanno portato a scegliere 60% come valore di default (questa percentuale è comunque personalizzabile dall utente). Supponiamo, ad esempio, di aver lavorato nel proprio ufficio per tutta la giornata, ma di essere stati in compagnia del collega Alberto solo durante la mattina. L azione sarà ovviamente modellata da un unico cluster. La presenza di Alberto nel cluster non arriverà certo a valori dell 80-90%, ma sarà decisamente inferiore. Quindi, nonostante sia lecito affermare Oggi ho incontrato Alberto, è decisamente più vicino ai ricordi dell utente affermare Oggi io e Alberto abbiamo lavorato insieme. 56

57 Generazione e pubblicazione dei blog post Per quanto riguarda le persone incontrate per un breve periodo, si è invece scelto di non impostare una soglia minima di presenza: se un cluster contiene una persona che è stata nei paraggi per una sola entry di contesto, significa che questo individuo si è trovato comunque nelle vicinanze dell utente, ed è quindi corretto segnalarlo nel blog post, per aderire in modo più fedele ai ricordi della persona. Come descritto meglio nel capitolo 6.5, la piattaforma CA fornisce anche il tipo di relazioni che intercorrono tra gli utenti della piattaforma (amici, colleghi, parenti, ecc ). Grazie a queste informazioni sarà possibile, in un estensione futura, pubblicare nel blog post solo le categorie di buddies selezionate dall utente (Capitolo 6.5). Complemento di Tempo È possibile aggiungere alla frase anche la durata e l ora d inizio e di fine dell azione. Per quanto riguarda la durata, si genera una locuzione temporale in linguaggio naturale a partire dai timestamp del cluster ( for a few minutes, for half an hour, for 4 hours and a half, ecc ). Complemento di luogo Le frasi contengono ovviamente anche delle informazioni sul luogo in cui l azione si è svolta. Se è impostato un Virtual Place, verrà visualizzato il suo nome, altrimenti si ripiega sull indirizzo civico del centro del cluster (Capitolo 5.2). I cluster di movimento hanno ovviamente informazioni sia sul luogo di partenza che su quello di arrivo. Per maggiori dettagli si rimanda al Capitolo 6.5 Complemento oggetto Alcuni Virtual Place permettono di risalire quasi senza ambiguità all azione compiuta. Ad esempio, se un utente è stato in una meeting room per tutta la durata del cluster, è altamente probabile che abbia partecipato ad una riunione. Per rendere il testo più vario e naturale, è possibile, utilizzando ovviamente un verbo transitivo, aggiungere alla frase un complemento oggetto, a cui viene associato anche un aggettivo di durata temporale. Ad esempio, invece della frase I stayed in meetingroom B for 4 hours with Carlo and Walter è possibile abbinare alla tipologia del VirtualPlace (meetingroom) il complemento oggetto che corrisponde alla situazione in cui si è trovato l utente (in questo caso, una riunione). La frase creata diventa quindi I had a four hour meeting in meeting room B with Carlo and Walter. Complemento di Mezzo I cluster di movimento possono contenere un Virtual Place Bluetooth, che identifica il mezzo di trasporto. Anche in questo caso, grazie ai place type elencati in [7] è possibile discriminare tra il tipo di veicolo utilizzato. Le frasi create saranno quindi accompagnate dalla locuzione by car oppure by bus, ecc 57

58 Generazione e pubblicazione dei blog post 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 si presenta la stesso blog post generato con diversi livelli di dettaglio. Today I stayed at home until 08:00. I moved from home to tilab for one hour from 08:07 to 09:07. Oscar Rodriguez, Cristina Fra and I worked at tilab for 8 hours and a half from 09:08 to 17:31, and there we met Walter Goix and Marco Test. I moved from tilab to Piazza Vittorio Veneto in Pinerolo, TO for one hour from 17:37 to 18:38. I stayed in Piazza Vittorio Veneto in Pinerolo, TO for one hour from 18:44 to 19:43. I stayed at home from 20:04. Today I stayed at home. I moved from home to tilab. I worked at tilab. I moved from tilab to Piazza Vittorio Veneto in Pinerolo, TO. I stayed in Piazza Vittorio Veneto in Pinerolo, TO. I stayed at home. Figura Blog post creato con livelli di dettaglio diversi 58

59 Generazione e pubblicazione dei blog post 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 Architettura tipica di un NLG - Document planner: decide quali informazioni appaiono nel testo finale in base all obiettivo richiesto dagli utenti. In questo passo si definisce inoltre l ordine delle parti del discorso all interno del testo. - Microplanner: in questo step si decide quali parole e quali strutture sintattiche devono essere utilizzate per esprimere il contenuto. Si sceglie 59

60 Generazione e pubblicazione dei blog post inoltre in che forma devono apparire alcune entità del testo (ad esempio, il formato delle date). Infine, grazie ad una procedura di aggregazione si decide come mappare le informazioni su frasi e paragrafi. - Surface Realiser: si occupa della realizzazione linguistica, ovvero la conversione di entità fino a questo momento astratte in testo. Si effettua inoltre una realizzazione della struttura del testo. Questa fase prevede la conversione di frasi e paragrafi astratti in punteggiatura. Viene così completata la costruzione sintattica del testo finale. Il generatore di blog necessita esclusivamente delle funzionalità di surface realising. I passi precedenti esulano dall obiettivo dell applicazione. SimpleNLG Tra i molti generatori disponibili in rete [9], la scelta è ricaduta su SimpleNLG [10]. Si tratta di un realiser di una grammatica inglese relativamente ristretta [10], implementato come libreria Java. È in grado di effettuare realizzazioni linguistiche e strutturali. È stato specificatamente creato per applicazioni che richiedono una conversione dei propri dati in testo naturale. SimpleNLG non sceglie i termini da utilizzare nel testo. Si occupa però della creazione di frasi grammaticalmente corrette, utilizzando le parole scelte dagli altri moduli del generatore di blog (Capitolo 6.2). SimpleNLG solleva il programmatore dalla gestione delle operazioni più ripetitive che coinvolgono la generazione del linguaggio naturale come, ad esempio: - Ortografia: inserisce gli spazi giusti tra frasi e paragrafi. Gestisce correttamente la punteggiatura (es: I stayed in Washington D.C. invece di I stayed in Washington D.C.. ). Si occupa inoltre di formattare correttamente le liste ( Marco, Giuseppe, and Diego. ). - Morfologia: coniuga i verbi al tempo desiderato, gestendo i verbi irregolari. Utilizza la forma del verbo corretta in base alla persona del soggetto. - Grammatica: permette di concatenare automaticamente in modo corretto i blocchi logici contenenti i termini definiti dall utente (che, in questo caso, si tratta del generatore di blog). Per generare del testo naturale, SimpleNLG mette a disposizione delle classi che modellano: - Paragrafi - Frasi - Verbi - Complementi diretti e soggetti - Complementi indiretti 60

61 Generazione e pubblicazione dei blog post 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 si presenta un esempio di output. Verbo Soggetto Complementi Avverbi Frase Verbo Soggetto Complementi Avverbi... Frase... Paragrafo Strutture dati del sistema NLG in memoria Realiser NLG Testo Naturale Figura La generazione del blog post. Il box grigio evidenzia le strutture dati che il sistema NLG costruisce in memoria prima di realizzare la stringa di testo naturale. Today Oscar Rodriguez and I worked at TILab until 18:18, and there we met Elio Paschetta, Walter Goix and Marco Marengo. I moved from TILab to Sumi's for one hour from 18:21 to 19:20. I stayed at Sumi's for 3 hours and a half from 19:23 to 23:06. I stayed at home from 23:07. Figura Il testo di un blog post di esempio L utilizzo di un sistema NLG richiede un carico elaborativo maggiore rispetto alla semplice concatenazione di stringhe. Il ritardo introdotto è però tale da non influenzare le prestazioni complessive del generatore di blog (il cui collo di bottiglia consiste nella fase di acquisizione dei dati di contesto dalla piattaforma CA, Capitolo 5.2). 61

62 Generazione e pubblicazione dei blog post 6.5 Il blog strutturato: Microformats Il problema della semantica Uno degli aspetti più significativi della ricerca applicata al Web, consiste nell introdurre delle tecniche per standardizzare il modo in cui alcune categorie di informazioni vengono pubblicate nel codice (X)HTML (posizioni geografiche, indirizzi, dettagli su persone, eventi, ecc ). L imponente mole di documenti presente sul web è infatti composta per la maggior parte da pagine HTML [11]: queste informazioni vengono indicizzate già da molti anni dai motori di ricerca tradizionali. I dati su cui questi software lavorano e l output prodotto sono però piatti : è consuetudine effettuare delle ricerche sul web in base a semplici parole chiave, ma la rapida crescita delle dimensioni del web stesso e la necessità di perfezionare i risultati delle ricerche, stanno spingendo la ricerca a pensare a nuove tecniche per aiutare i software a trovare le informazioni desiderate in base al significato semantico. A differenza degli esseri umani, il software non è però molto abile a comprendere la semantica di un testo scritto (parsificare il linguaggio naturale è un operazione molto complessa, e poco scalabile sulle dimensioni sempre maggiori del web). Per permettere un processing automatico più efficiente di una pagina web, occorre quindi pensare a delle tecniche per standardizzare il modo in cui vengono presentate le informazioni. I Microformats: definizione I microformats sono uno dei possibili approcci per risolvere il problema di creare pagine web con markup semantico [11]. In [12], si trova una definizione di Microformats: un set di semplici standard di formati dati [ ] creati per migliorare la pubblicazione di blog strutturati e di altri microcontenuti in generale.. Uno dei principi guida nella definizione dei Microformats è il concetto di riuso di tecnologie già esistenti (ad esempio alcuni microformati si basano sullo standard vcard). Il principio del riuso è evidente se si analizzano le tecnologie su cui i Microformats sono basati. A livello tecnico infatti, un Microformat altro non è che un riutilizzo di elementi e di attributi XHTML (ad esempio <div> o <span>), con alcuni valori ben definiti di attributo class. Si è pensato inoltre ad un approccio che risolvesse il problema del markup semantico senza stravolgere non solo il contenuto del web, ma anche l architettura dei browser sul mercato. Un altro aspetto da tenere in considerazione, è il fatto che gli sviluppatori, nell adottare i microformats, possono riutilizzare le loro conoscenze. 62

63 Generazione e pubblicazione dei blog post 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 Tipi di Microformat [12] Più avanti nel capitolo si analizzeranno i Microformats utilizzati dal Blog Contestualizzato. I vantaggi dei Microformats Creare un testo XHTML arricchito dall uso di Microformats porta quindi molti vantaggi [11]: - Un formato standard per la rappresentazione facilita la scalabilità ai software di indicizzazione distribuiti, e permette un parsing con un significato semantico aggiunto. - Il codice delle pagine web diventa più uniforme e standardizzato, in quanto non sarà più necessario definire classi personalizzate per elementi come indirizzi, contatti, recensioni, ecc - E possibile permettere una nuova interoperabilità tra applicazioni Desktop e contenuto web-based. Ad esempio, grazie al Microformat hcard, è possibile esportare informazioni sui contatti pubblicati in una pagina web direttamente nei programmi di gestione delle rubriche e posta elettronica (es: MS Outlook). 63

64 Generazione e pubblicazione dei blog post 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 I campi del formato vcard relativi a all'indirizzo civico [11]. Questo formalismo viene mappato in HTML dal microformat adr. Non è importante il tipo degli elementi utilizzati (per i microformats composti si può utilizzare indifferentemente <div> o <span>) ma, affinchè il microformat sia parsificato correttamente, è fondamentale che gli attributi class si attengano ai valori definiti nello standard vcard. L elemento root deve inoltre essere di classe adr (Figura 6.5.3). <div class="adr"> <div class="street-address">2560 Ninth Street </div> <div class="extended-address">suite 219</div> <span class="locality">berkeley</span>, <span class="region">ca</span> <span class="postal-code">94710</span> <div class="country-name">usa</div> </div> Figura 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 a). adr non permette infatti di definire la tipologia di un 64

65 Generazione e pubblicazione dei blog post 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 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 c). <span class="adr">tilab <span class="street-address"> Via Guglielmo Reiss Romoli 239</span> <span class="locality">torino</span> <span class="country-name">italy</span> </span> (a) span.street-address{ display: none; } span.locality{ display: none; } span.country-name{ display: none; } (b) TILab (c) Figura 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 a). 65

66 Generazione e pubblicazione dei blog post <div class="vcard"> <div class="fn">mario Rossi</div> <div class="org">societa di esempio</div> <div class="tel"> </div> <a class="url" href=" </div> div.org{ display: none; } div.tel{ display: none; } a.url{ display: none; } (a) Mario Rossi (b) (c) Figura 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 e l URL personale di ogni buddy incontrato. Queste informazioni sono annegate nel blog post attraverso l uso di un apposito CSS (Figura b), come già fatto nel caso del MicroFormat adr per non rendere la lettura del blog post difficoltosa. Queste informazioni non visibili rispettano però la sintassi di hcard: un parser di Microformat sarà in grado di catturarle e permetterà ai visitatori della pagina di fruirne in molti modi. Sarà ad esempio possibile, in modo intuitivo e rapido, esportare i contatti presenti nel blog verso applicazioni di gestione rubrica, come Outlook. Markup per le relazioni tra utenti: XFN XHTML Friends Network (XFN) è stato il primo Microformat ad essere sviluppato. Il suo utilizzo permette di creare una social network, ovvero una rete di link che non solo collega individui, ma che specifica anche le relazioni umane tra gli utenti. Grazie ad XFN è infatti possibile descrivere in che modo si è legati alla persona puntata dal link (Figura 6.5.6). <a href=" rel="colleague met">walter</a> Figura XFN Microformat 66

67 Generazione e pubblicazione dei blog post 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). <a href=" " rel="colleague"> <span class="vcard"> <span class="fn">mario Rossi</span> <span class="org">societa di esempio</span> <span class="tel"> </span> <a class="url" href=" </span> </a> Strumenti per il parsing Figura Una combinazione di XFN e hcard I più importanti browser presenti tutt ora sul mercato (Internet Explorer, FireFox, Opera, Safari, ecc ) non offrono ancora nativamente la possibilità di parsificare le pagine web per trovare e utilizzare i Microformat. Per parsificare una pagina che contiene microformati è però possibile utilizzare i seguenti tool [13]: - Operator: è un estensione per Firefox 2. Si installa sottoforma di barra aggiuntiva nell interfaccia del browser. Tramite un opportuno parsing, permette di individuare e localizzare i microformat di molti tipi all interno 67

68 Generazione e pubblicazione dei blog post 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 Uno screenshot della barra di Operator - Tails: è un altra estensione di Firefox 2. E meno ricco di funzioni di Operator, ma permette comunque di esportare gli hcard e gli adr (che, si ricorda, sono entrambi basati sullo standard vcard). - XFN Dumper: è un bookmarklet in grado di effettuare il parsing della pagina per cercare ed evidenziare Microformat XFN. Si segnala inoltre che la tecnologia di parsing alla base di Operator potrebbe essere utilizzata in modo nativo dalla prossima versione di Firefox (3.0) [13]. 68

69 Generazione e pubblicazione dei blog post 6.6 Integrare elementi multimediali: TeamLife Portal Il generatore di blog contestualizzato si occupa anche di integrare il testo dei blog post con le immagini e i filmati che l utente ha creato utilizzando il proprio dispositivo mobile durante la giornata. Questi contenuti non sono pubblicati a caso, ma sono abbinati alla frase corretta, e quindi al periodo giusto della giornata (cluster) in cui sono stati catturati. Per ottenere questo risultato, è ovviamente necessaria una procedura per prelevare i contenuti multimediali degli utenti. Per risolvere questo problema, il generatore di blog si interfaccia con un altra applicazione fornita dalla piattaforma CA: il Portale Teamlife [23]. TeamLife Media Sharing Content Management System Si tratta di un CMS che permette agli utenti della piattaforma CA di condividere i propri contenuti (multimediali e non). In particolare, il servizio è caratterizzato da una forte integrazione con il client TeamLife in esecuzione sui device mobili. Come anticipato nel Capitolo 4.5 questo software, oltre ad effettuare periodicamente update di contesto verso la piattaforma, si occupa anche di gestire l upload di foto e video verso il portale. In questo modo, gli utenti registrati al servizio (Capitolo 4.4), se lo desiderano, possono direttamente pubblicare i contenuti multimediali catturati col proprio device sul portale, per permetterne la condivisione con gli altri utenti registrati. È comunque presente un sistema di controllo di accesso, che dà libertà ad ogni utente di impostare la visibilità desiderata ad ogni file caricato sulla piattaforma (pubblica, friends only, privata, ecc ). Ad ogni file caricato sul portale, vengono associate delle informazioni: timestamp di upload, ora di acquisizione per le immagini JPEG, modello di device che ha scattato una foto, risoluzione, ecc Ciò che differenzia TeamLife Portal da servizi analoghi già presenti sul mercato (ad esempio Flickr), è però l utilizzo delle informazioni di contesto messe a disposizione dalla piattaforma CA. Al momento dell upload di un contenuto, il client invia infatti al portale anche tutte le informazioni che descrivono il contesto dell utente nell istante in cui ha scattato la foto oppure ha catturato un filmato (Capitolo 3.2). I contenuti multimediali sono così arricchiti da molte informazioni di contesto, in modo completamente automatico: non è più necessario che l utente intervenga, anche se è comunque sempre possibile aggiungere tag personalizzati. Le informazioni di contesto aggiunte automaticamente dall applicazione sono, ad esempio, l indirizzo civico in cui la foto è stata scattata, oppure i buddy nelle vicinanze. (Figura 6.6.1). 69

70 Generazione e pubblicazione dei blog post Figura TeamLife Portal: dettagli di un immagine con tag di contesto I dati di contesto sono assegnati ad un contenuto multimediale nella forma di tag. Una foto, ad esempio, sarà etichettata automaticamente con l indirizzo, il nome della città e la provincia in cui è stata scattata. Se la foto è stata presa in un Virtual Place definito dall utente (Capitolo 5.2), verranno aggiunti come tag anche il place type e il place name (ad esempio, office, TILab ). Le immagini sul portale sono inoltre etichettate con i nomi degli altri utenti della piattaforma che si trovavano nei paraggi. (Figura 6.6.1). Il portale offre inoltre una procedura di ricerca basata sui tag: in questo modo è possibile, in modo rapido ed intuitivo, trovare altri file a cui sono associate le stesse etichette. È così possibile utilizzare le informazioni di contesto per trovare i contenuti che ci interessano. Ad esempio, è possibile trovare tutte le foto scattate in un Virtual Place da un certo utente, oppure si possono ottenere tutti i filmati girati presso un indirizzo in un preciso periodo di tempo, ecc Inoltre, se un utente effettua il login nel portale TeamLife, potrà fruire di una delle funzioni più significative del CMS, cioè la possibilità di visualizzare tutti i contenuti catturati nello stesso contesto in cui l utente si trova nell istante stesso in cui sta visualizzando la pagina web. Per maggiori informazioni sul Portale Teamlife si rimanda a [23]. 70

71 Generazione e pubblicazione dei blog post 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 Esempio di GET HTTP per creare un feed RSS (tutte le foto scattate a Torino dall utente lukostaz) Il generatore di blog ha la necessità di ricavare le foto e i video creati dall utente durante la giornata precedente. Le caratteristiche offerte dai feed RSS soddisfano questo problema. Per ogni utente, la procedura per integrare le immagini in un blog post segue questi passi (Figura 6.6.3): RSS Parsing Assegnazione ai cluster Creazione del contenuto HTML Blog Generator Figura Il processo di integrazione con le informazioni multimediali - Ottenere il feed: il blog generator richiede l RSS desiderato a TeamLife, attraverso una HTTP GET (Figura 6.6.4). Il feed deve contenere tutte le informazioni sui contenuti multimediali catturati dall utente nella giornata precedente. 71

72 Generazione e pubblicazione dei blog post Figura Esempio di feed RSS utilizzato dal Blog Generator - RSS parsing: il generatore di blog parsifica il contenuto del feed per ricavare i dati desiderati. Il feed contiene l elenco dei contenuti della giornata per l utente. Per ogni immagine/video il Blog Generator ha bisogno delle seguenti informazioni: - URL della pagina TeamLife che presenta i dettagli della foto/video (Figura 6.6.1) - URL della thumbnail del file desiderato (la miniatura è creata direttamente dal CMS) - Titolo della foto/video - Data e ora in cui l immagine/video è stata creata. Per creare questa informazione, TeamLife utilizza le informazioni EXIF per le immagini JPG. Se questi dati non sono disponibili, si usa un timestamp inviato dal client. Il generatore di blog crea in memoria una lista di oggetti multimediali che contengono le informazioni elencate in precedenza. - Assegnazione ai cluster: ogni oggetto multimediale viene associato al cluster di contesto giusto. Il generatore di blog confronta la data e l ora dell immagine con i timestamp di inizio e fine del cluster. L oggetto verrà associato al cluster se è stato catturato in questo lasso di tempo. - Creazione del contenuto HTML: in quest ultima fase si effettua la conversione in codice HTML degli oggetti multimediali. Il codice così creato è aggiunto al blog post durante la generazione del testo naturale. Ogni thumbnail è un link alla pagina del portale TeamLife con i dettagli dell immagine/video. Le immagini sono inoltre precedute da una frase introduttiva (Figura 6.6.5). 72

73 Generazione e pubblicazione dei blog post <div><span> <a href=" src=" class="thumb" title="gibi" alt="gibi" /></a> <a href=" src=" pg" class="thumb" title="gibi trio" alt="gibi trio" /></a> <a href=" src=" pg" class="thumb" title="gibitrio" alt="gibitrio" /></a> </span></div> Figura Un esempio di come gli elementi multimediali sono trasformati in codice HTML e successivamente visualizzati nel blog post. 73

74 Generazione e pubblicazione dei blog post 6.7 La piattaforma di Blogging: WordPress MU Dopo aver creato il blog post (composto da testo e contenuti multimediali), occorre pubblicare queste informazioni sul web. Il generatore di blog non si occupa di gestire la presentazione dei contenuti. È stata presa la decisione di affidarsi ad una piattaforma di blogging, un CMS creato ad hoc per gestire i blog di uno o più utenti. La scelta è ricaduta su una delle piattaforme più diffuse sul mercato: Wordpress. In particolare, si è scelta una variante che permette di gestire una community di blog, Wordpress Multi User (mu). La scelta di affidarsi a questo prodotto è stata determinata da alcuni fattori, elencati al punto successivo. WordPress: caratteristiche generali Wordpress [14] è una piattaforma di blogging scritta in linguaggio PHP e basata sull uso di un database MySQL. Si tratta di un software opensource, distribuito con licenza GPL. Permette una gestione semplice ed efficiente dei propri blog post, che vengono organizzati con una struttura a permalink. In questo modo, Wordpress garantisce ai motori di ricerca la possibilità di indicizzare le proprie pagine. E bene elencare alcune caratteristiche importanti di Wordpress: - Installazione semplice - Ambiente di esecuzione: è solito utilizzare la piattaforma in ambiente Linux, utilizzando Apache come Web Server, MySQL come DB Manager e PHP come linguaggio di scripting (l ambiente è informalmente noto come LAMP). - Licenza GPL - Disponibilità di plugin e personalizzazione: il software ha la possibilità di essere esteso. Esiste già un grande numero di plugin disponibili in rete. Sono stati sviluppati inoltre molti theme, ed è possibile crearne ovviamente di personalizzati. - Community: Wordpress gode di una community di sviluppatori molto estesa; il suo sviluppo è quindi costante e gli aggiornamenti sono frequenti. - Documentazione: la piattaforma è documentata nel dettaglio sul sito web ufficiale [14]. Gestire una community di utenti Come già anticipato, le funzionalità di Wordpress sono orientate alla gestione di un solo blog personale e non sono sufficienti per lavorare con una comunità di utenti, cosa di cui invece abbiamo bisogno. E stata quindi scelta una versione di WordPress, WordPress Multi User (mu), che, nonostante mantenga praticamente inalterato il modo di gestione dei contenuti, il layout e le interfacce, permette di creare e mantenere una community di blog in modo semplice ed efficace [15]. 74

75 Generazione e pubblicazione dei blog post 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 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 si riporta il metodo utilizzato per pubblicare il blog post su Wordpress, che, come si vede dal codice, necessita anche dei parametri necessari per effettuare l autenticazione dell utente. private XmlRpcClient client; public Integer post(string contents) throws XmlRpcException { Object[] params = new Object[] { bloginfo.getblogid(), bloginfo.getusername(), bloginfo.getpassword(), contents, }; return (Integer) client.execute(post_method_name, params); } Figura Metodo per pubblicare i contenuti attraverso chiamata XML-RPC Wordpress e i Microformats Un ultimo aspetto da considerare su WordPress, riguarda la pubblicazione di Microformats nelle entry dei blog post. I contenuti postati sulla piattaforma (sia 75

76 Generazione e pubblicazione dei blog post 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 Per informazioni sul VideoBlog si rimanda al Capitolo Implementazione Il modulo di creazione dei blog post è implementato in codice Java. Fa uso delle classi create per acquisire informazioni di contesto dalla piattaforma CA e per effettuare il processo di clustering (Capitolo 5.8). Il codice del prototipo del generatore di blog è eseguito ogni giorno ad un ora prestabilita. I post sono generati per tutti gli utenti registrati al servizio in modalità batch. In attesa di estensioni future (Capitolo 9.3), si è deciso di schedulare l esecuzione del software alle ore 5:00 di ogni mattina. Il prototipo considera inoltre la stessa ora come l inizio di una nuova giornata per ogni utente. Ad ogni esecuzione, il generatore di blog raccoglierà quindi le informazioni di contesto degli utenti fino alle ore 5:00 del giorno precedente: questi dati saranno utilizzati per costruire il blog post vero e proprio. La scelta delle ore 5:00 è sembrata la più ragionevole, in quanto precede di qualche ora il momento del risveglio della maggior parte degli utenti e garantisce allo stesso tempo l assegnazione delle informazioni di contesto raccolte nelle prime ore della notte alla giornata precedente. Le esperienze vissute dopo la mezzanotte, nonostante appartengano ovviamente ad una nuova giornata, vengono percepite dalla maggior parte degli utenti come parte della giornata precedente (ad esempio, una persona che esce con gli amici e torna a casa alcune ore dopo la mezzanotte). 76

77 Generazione e pubblicazione dei blog post Figura Esempio di pubblicazione di blog post 77

78 Generazione e pubblicazione dei blog post 78

79 La creazione del VideoBlog 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). Context Cluster HTTP MING library VideoBlogML Cluster & Blog entry Generator Video Blog Generator Flash Video Blogs Figura Generazione del VideoBlog: integrazione tra componenti 79

80 La creazione del VideoBlog 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 si presenta un esempio di codice VideoBlogML. 80

81 La creazione del VideoBlog Figura Lo schema del VideoBlogML 81

82 La creazione del VideoBlog <videodata xmlns=" xmlns:xsi=" xsi:schemalocation=" ca.tilab.com/blog/videoblog <userid>lukostaz</userid> <date> </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> </pictureurl> <title>capitano70</title> </mediaelement> <mediaelement> <pictureurl> </pictureurl> <title>punizione contro</title> </mediaelement> </mediaelements> </ctxcluster> <ctxcluster moving="true"> <starttime>15:33</starttime> <endtime>23:44</endtime> <people></people> <locationfrom>n/a;borgata Azzari in San Germano Chisone, TO</locationFrom> <locationto>residence;home</locationto> <mediaelements> <mediaelement> <pictureurl> </pictureurl> <title>il miglior bar di pinerolo</title> </mediaelement> <mediaelement> <pictureurl> </pictureurl> <title>e finisce 3-1 x noi!!</title> </mediaelement> <mediaelement> <pictureurl> </pictureurl> <title>che felicita' la borsa nuova!</title> </mediaelement> </mediaelements> </ctxcluster> </ctxclusters> </videodata> 7.3 La Libreria MING Figura Un esempio di VideoBlogML Ming è una libreria C, utilizzata per generare filmati Flash (SWF) [18]. Il progetto, completamente open source e cross-platform, offre un set di wrapper non solo per C++, ma anche per un buon numero di linguaggi di scripting, come PHP, Perl, Python e Ruby. (a partire dalla versione 0.4 esistono in realtà anche dei wrapper Java, ma tramite 82

83 La creazione del VideoBlog il loro utilizzo non è possibile effettuare alcune delle operazioni più sofisticate richieste dal videoblog, Capitolo 7.4). Il progetto Ming supporta quasi tutte le caratteristiche di Flash 4 [19]: forme, sfumature, immagini importate (jpg e png), morphing di forme, testo, pulsanti, video importati, aggiunta di audio in formato mp3. La libreria include inoltre un modulo in grado di compilare un subset del linguaggio ActionScript. Per realizzare il generatore di videoblog, è stata utilizzata la versione 0.4. A causa delle limitazioni relative ai wrapper Java, è stato necessario lavorare con le estensioni Ming compilate come libreria-modulo per l interprete PHP in ambiente Linux-Apache (Capitolo 7.1). Un animazione Flash creata con la libreria Ming è tipicamente composta dai seguenti oggetti: - SWFMovie: è la classe che modella l intero filmato Flash. È il contenitore di tutti gli altri elementi dell animazione. A questo oggetto è associata la timeline principale del video. - SWFShape: è una classe che modella una forma geometrica. - SWFText e SWFFont: rappresentano, rispettivamente, una stringa di testo ed il font utilizzato per il rendering. - SWFBitmap: è una classe utilizzata per importare e visualizzare immagini in formato Jpeg. - SWFPreBuiltClip permette di aggiungere ad un animazione Flash un altro filmato già compilato in formato swf. - SWFButton e SWFAction: il primo è un pulsante cliccabile, mentre il secondo è l azione (in linguaggio ActionScript) da eseguire. A titolo di esempio si riporta in figura il codice per creare una semplice animazione contenente un quadrato [18]. 83

84 La creazione del VideoBlog // a red square... // this sets the scale to a similar format as that used in flash Ming_setScale(20); // publish this movie for the flash 6 player ming_useswfversion(6); // create a movie, here we call it $movie $movie=new SWFMovie(); // 550 by 400 is the default in flash $movie->setdimension(550,400); // background set to grey $movie->setbackground(0xcc,0xcc,0xcc); // frame rate of 12 is the default in flash $movie->setrate(12); // create a shape, here we call it $squareshape $squareshape=new SWFShape(); // give it a red fill $squareshape->setrightfill(255,0,0); // draw that shape in a clockwise direction $squareshape->drawline(100,0); # draw the top line $squareshape->drawline(0,100); # draw the right line $squareshape->drawline(-100,0); # draw the bottom line $squareshape->drawline(0,-100); # draw the left line // add $squareshape to the movie and create a reference // to it called $squaresymbol so we can move it later $squaresymbol=$movie->add($squareshape); // now we can move $squareshape $squaresymbol->moveto(100,100); // save $movie to disk, here we call it square.swf $movie->save("square.swf"); Figura Creare un quadrato con Ming [18] 7.4 Creare il Videoblog La creazione vera e propria del videoblog attraversa alcune fasi. In questo capitolo vedremo una descrizione generale dei passi che gli script devono compiere per ottenere il risultato finale. Dai Cluster di contesto al VideoBlogML Il generatore di blog ha il compito di trasformare i context cluster di un utente in codice XML, secondo lo schema descritto nel Capitolo 7.2. Queste informazioni saranno successivamente inviate, tramite una POST HTTP, agli script PHP che generano il filmato. Parsing del VideoBlogML La prima operazione che lo script PHP deve compiere è il parsing del VideoBlogML ricevuto dal generatore di blog Java. Per effettuare questa operazione, sono state utilizzate le estensioni SimpleXML di PHP [20]. Dopo aver effettuato il parsing, lo script crea in memoria un array di oggetti ContextCluster. Questa classe contiene le 84

85 La creazione del VideoBlog informazioni necessarie per trasformare un cluster in un animazione contestualizzata: Le istanze contengono infatti: - Timestamp di inizio e fine del cluster - Flag che indica se si tratta di un cluster di movimento - Location (oppure, se è un cluster di movimento, si usano i campi locationfrom e locationto) - Nomi delle persone incontrate durante il cluster - Lista degli URL dei contenuti multimediali compresi in un cluster. Setup del video e Creazione del Player Dopo aver impostato frame rate e dimensioni dell animazione, lo script si occupa della creazione del corpo principale del VideoBlog che include anche la barra dei controlli per il video (Figura 7.4.2). I pulsanti sono creati a partire da un immagine png, grazie al tool png2dbl offerto da Ming [18]. Grazie al codice ActionScript associato ad ogni pulsante (Figura 7.4.1), l utente può controllare il flusso della riproduzione: non è quindi necessario utilizzare player esterni, in quanto il filmato swf offre tutti i controlli necessari per la riproduzione dei suoi contenuti. $actionpause = "_root.stop(); for(obj in _root){ if(typeof(_root[obj])=="movieclip"){ _root[obj].stop(); } }"; $actionplay = "_root.play(); for(obj in _root){ if(typeof(_root[obj])=="movieclip"){ _root[obj].play(); } }"; $buttonstop->addaction(new SWFAction($actionPause), SWFBUTTON_MOUSEDOWN); $buttonstart->addaction(new SWFAction($actionPlay), SWFBUTTON_MOUSEDOWN); Figura Il codice associato ai pulsanti della barra di controllo Trasformare un Cluster di contesto in video : panoramica generale La realizzazione in video di un cluster di contesto è composta fondamentalmente da due parti distinte (Figura 7.4.2): 85

86 La creazione del VideoBlog Area principale Barra delle informazioni Figura Visualizzazione di un cluster all'interno del videoblog. L icona nell area principale è associata al Virtual Place di tipo office - Barra delle informazioni: l area è utilizzata per visualizzare le informazioni testuali relative al cluster visualizzato. Fanno parte di quest area del video il luogo in cui l utente si è trovato (nel caso di un cluster di movimento vengono visualizzati il posto di partenza e quello di arrivo), gli altri utenti della piattaforma incontrati, e l ora di inizio e di fine dell azione. - Area principale: oltre allo slideshow di foto e filmati, l area principale dell animazione viene utilizzata per visualizzare un icona che sintetizza il tipo di azione compiuta dall utente durante il cluster. Il processo è analogo con quanto accade per la scelta dei verbi del blog testuale (Capitolo 6.2): la selezione dell immagine avviene in base alla categoria del Virtual Place. Se la posizione del cluster non è stata etichettata come tale, verrà visualizzata un icona di default. SlideShow di immagini Se un cluster di contesto contiene delle immagini, sarà compito del generatore di videoblog visualizzare questi contenuti sottoforma di slideshow. Lo script, a valle dell operazione di parsing del VideoBlogML è a conoscenza dell URL dell immagine da visualizzare (il collegamento punta ad un permalink offerto dal portale TeamLife Media Sharing). Ogni immagine visualizzata (con relativo effetto di transizione) è accompagnata dal proprio titolo (Figura 7.4.3). Tutti i contenuti acquisiti dall utente sono così presentati, anche in questo caso, all interno del contesto in cui l utente si trovava. 86

87 La creazione del VideoBlog Il Video SlideShow Figura Un'immagine all'interno dello slideshow Analogamente a quanto accade per le immagini, i cluster del video blog possono anche contenere uno slideshow dei filmati girati durante la giornata. Il processo per la generazione di una sequenza di video e l integrazione all interno del flusso Flash è però più complesso rispetto al caso delle fotografie, e si articola nei seguenti passaggi (Figura 7.4.4): HTTP GET Audio files (mp3) Temp files (3gp, mp4) Multiplexing Video files (swf) Video files (flv) Concatenazione in video slideshow Figura Il processo di integrazione nel videoblog dei filmati girati dall utente - Salvataggio dei video: lo script scarica i video dal portale Teamlife e li salva in locale. 87