Politecnico di Milano

Scuola di Ingegneria Industriale e dell'Informazione

Corso di Laurea in Ingegneria Informatica Dipartimento diElettronica, Informazione e Bioingegneria

SVILUPPO DI UNO STRUMENTO DI BUSINESSINTELLIGENCE PER LA GESTIONE DELLE EMERGENZE,

NELL'AMBITO DEL PROGETTO TORCIA

Relatore: Prof. Chiara Francalanci

Tesi di Laurea di:

Marco Brambilla

Matricola 681247

Anno Accademico 2013-2014

2

Ringraziamenti

Un sentito ringraziamento va alla Prof.sa Chiara Francalanci per avermi costantementeseguito nella realizzazione di questo lavoro con cordialità e professionalità.

Desidero ringraziare anche due amici e colleghi, Andrea Salvi e Simone Carminati, chehanno condiviso con me il percorso di studi: assieme abbiamo superato i momenti didifficoltà e gli esami che sembravano impossibili.

Infine, un ringraziamento speciale va a tutta la mia famiglia, che mi ha fatto capirel'importanza dello studio e mi ha sempre sostenuto lungo il mio percorso.

3

IndiceRINGRAZIAMENTI......................................................................................................3

INDICE.............................................................................................................................4

INDICE DELLE FIGURE..............................................................................................8

INDICE DELLE TABELLE...........................................................................................9

ABSTRACT....................................................................................................................10

CAPITOLO 1 – INTRODUZIONE.............................................................................11

CAPITOLO 2 – STATO ELL'ARTE...........................................................................13

2.1 – La gestione delle emergenze.............................................................................13

2.1.1 – Ciclo di vita delle emergenze..................................................................14

2.1.2 – Il piano d'emergenza................................................................................16

2.1.3 – Classificazione delle emergenze..............................................................16

2.2 – I social network e il loro ruolo nella gestione delle emergenze.....................19

2.2.1 – I social network.......................................................................................19

2.2.1.1 – Twitter......................................................................................21

2.2.2 – Il Crowdsourcing....................................................................................23

2.2.2.1 – Il Crowdsourcing e le fasi dell'emergenza..............................23

2.2.3 – Utilizzo dei social network nella gestione delle emergenze: casi reali...24

2.2.3.1 – Una nuova strategia di comunicazione: il caso NORAD- NORTHCOM............................................................................24

2.2.3.2 – Uragano Gustav in Louisiana (Agosto 2008)..........................25

2.2.3.3 – Eruzione del vulcano Eyjafjöll in Islanda (Aprile 2010).........25

2.2.3.4 – Terremoto, tsunami e diastro nucleare in Giappone (Marzo 2011).......................................................................................26

2.2.3.5 – Terremoto dell'Emilia (Maggio 2012)......................................26

2.2.3.6 – Uragano Sandy (Ottobre 2012)................................................27

4

2.2.3.7 – Alluvione in Sardegna (Novembre 2013).................................28

2.2.3.8 – Alluvione a Senigallia (Maggio 2014).....................................28

2.2.3.9 - American Red Cross Digital Operation Center........................29

2.2.3.10 – Una piattaforma di crowdsourcing: Ushaidi........................30

2.3 – La Business Intelligence..................................................................................31

2.3.1 – Definizione di Business Intelligence.......................................................31

2.3.2 – Componenti dei sistemi di Business Intelligence....................................31

2.3.2.1 – I sistemi OLAP e i Data warehouse.........................................33

2.3.2.2 – Data mining.............................................................................38

2.4 – Emergency Situation Awareness – Automated Web Text Mining (ESA – AWTM)...........................................................................................................42

CAPITOLO 3 – IL PROGETTO TORCIA: OBIETTIVI E ARCHITETTURA TECNOLOGICA............................................................................43

3.1 – Il progetto TORCIA.........................................................................................43

3.1.1 – I partner del progetto...............................................................................44

3.1.2 – Motivazioni e obiettivi.............................................................................45

3.1.3 – Le attività core del sistema......................................................................46

3.1.4 – L'architettura core del sistema.................................................................47

3.1.5 – Contesto specifico di analisi del progetto................................................49

3.2 – Il Motore Semantico.........................................................................................52

3.2.1 – Funzionamento generale..........................................................................52

3.2.2 - Architettura del Motore Semantico.........................................................53

3.2.2.1 – Il Web Service...........................................................................54

3.2.2.2 – Il Classificatore........................................................................57

3.2.2.3 – Entity Discovery.......................................................................60

3.3 – Database............................................................................................................64

3.4 – Introduzione allo strumento di Business Intelligence.......................................68

CAPITOLO 4 – UNO STRUMENTO DI SOCIAL MEDIA INTELLIGENCE PER LA GESTIONE DELLE EMERGENZE.......................................69

5

4.1 – Framework dello strumento............................................................................69

4.1.1 – Utenti dello strumento.............................................................................70

4.1.2 – Analisi dei dati longitudinali....................................................................70

4.1.3 – Analisi multidimensionali........................................................................71

4.1.4 – Key Performance Indicator......................................................................72

4.1.5 – Rappresentazione grafica dei dati............................................................73

4.2 – Torcia Monitor...................................................................................................73

4.2.1 – Architettura di Torcia Monitor.................................................................74

4.2.2 – Lo strumento di Business Intelligence.....................................................75

4.3 – Analisi effettuate...............................................................................................78

4.3.1 – Casi di studio...........................................................................................78

4.3.1.1 – Nubifragio Catania..................................................................78

4.3.1.2 – Alluvione Vicenza.....................................................................79

4.3.1.3 – Alluvione nelle Marche e a Senigallia......................................80

4.3.1.4 – Grandinata a Reggio Emilia ed esondazione del Seveso.........81

4.3.1.5 – Seconda esondazione del Seveso.............................................83

4.3.1.6 – Osservazioni............................................................................85

4.3.2 – Analisi future..........................................................................................87

4.3.2.1 – Taratura del peso delle sorgenti.............................................87

4.3.2.2 – Analisi effettuabili sulle classi................................................87

4.4 – Sviluppi futuri.................................................................................................88

4.4.1 – Aggregazione dei Luoghi.......................................................................88

4.4.2 – Diverse tipologie di emergenza..............................................................89

4.4.3 – Profilazione degli utenti..........................................................................90

4.4.4 – Integrazione con l'applicativo mobile.....................................................90

CAPITOLO 5 – CONCLUSIONI................................................................................92

APPENDICE A - CATEGORIE DI CLASSIFICAZIONE......................................94

A.1 – Categorie di partenza.................................................................................94

6

A.2 – Categorie migliorate..................................................................................96

BIBLIOGRAFIA...........................................................................................................98

7

Indice delle FigureFigura 2.1 – Ciclo di vita delle emergenze......................................................................14

Figura 2.2 – Esempio di cubo multidimensionale...........................................................36

Figura 2.3 – Schematizzazione delle operazioni di Slice & Dice...................................37

Figura 2.4 – Esempio di schema a stella.........................................................................38

Figura 3.1 – Architettura del sistema TORCIA...............................................................47

Figura 3.2 – Architettura del Motore Semantico.............................................................54

Figura 3.3 – Architettura del servizio Push Tweet...........................................................55

Figura 3.4 – Struttura XSD per la trasmissione dei tweet...............................................56

Figura 3.5 – Struttura XSD per la trasmissione dei Luoghi Notevoli.............................57

Figura 3.6 – Relazione tra le entità nell'algoritmo di classificazione..............................58

Figura 3.7 – Struttura XSD per la trasmissione delle segnalazioni.................................63

Figura 3.8 – Struttura del Database.................................................................................64

Figura 4.1 – Livelli di aggregazione della dimensione Tempo........................................71

Figura 4.2 – Schema architetturale di Torcia Monitor.....................................................74

Figura 4.3 – Interfaccia dello strumento di BI di Torcia Monitor...................................75

Figura 4.4 – Nubifragio Catania......................................................................................78

Figura 4.5 – Alluvione Vicenza.......................................................................................79

Figura 4.6 – Alluvione Marche e Senigallia....................................................................80

Figura 4.7 – Grandinata di Reggio Emilia ed esondazione del Seveso...........................81

Figura 4.8 – Distribuzione dei tweet del 7 Luglio...........................................................82

Figura 4.9 – Distribuzione dei tweet dell'8 Luglio..........................................................82

Figura 4.10 – Distribuzione dei tweet dalle ore 6 alle ore 7............................................83

Figura 4.11 – Volumi relativi al periodo 23 – 28 Luglio.................................................83

Figura 4.12 – Distribuzione dei tweet del 26 Luglio.......................................................84

Figura 4.13 – Livelli di aggregazione per la dimensione Località..................................89

8

Indice delle tabelleTabella 3.1 – Tipologie dei messaggi contenuti nelle Classi...........................................53

Tabella 3.2 – Composizione delle categorie pre modifica..............................................59

Tabella 3.3 – Esempi di termini contenuti nella blacklist...............................................62

9

Abstract

Il questo lavoro di tesi è stato sviluppato e realizzato uno strumento di BusinessIntelligence per la gestione delle emergenze, inserito nell'ambito del progetto TORCIA.

Il progetto TORCIA, finanziato da Regione Lombardia, si prefigge lo scopo di fornireun supporto alla gestione delle emergenze sfruttando i social network, sia per acquisirele informazioni necessarie all'individuazione di una situazione critica, sia come mezzodi comunicazione tra cittadini e Autorità competenti.

Dopo aver fornito il background informativo sulla gestione delle emergenze, sui socialnetwork e sulla Business Intelligence, verrà presentato il progetto TORCIA,descrivendone architettura e finalità.

Verrà poi descritto nel dettaglio lo strumento di Business Intelligence realizzato inquesta tesi. Verranno mostrate le sue caratteristiche e le tipologie di analisi che è ingrado di compiere, presentando alcuni casi di studio.

Infine, verranno proposte alcune idee per gli sviluppi futuri di questo strumento.

10

Capitolo 1

Introduzione

Il presente lavoro di tesi ha affrontato lo sviluppo e della realizzazione di uno strumentodi Business Intelligence per la gestione delle emergenze, inserito nell'ambito delprogetto TORCIA.

La gestione delle emergenze è un argomento quanto mai importante e di attualità.Eventi naturali di notevole intensità si stanno verificando con sempre maggiorefrequenza, in netto contrasto con le statistiche disponibili, causando danni ingenti e inmolti casi anche delle vittime.

Questa nuova situazione ha portato allo sviluppo di nuove metodologie di approccio alproblema.

Il progetto TORCIA, finanziato da Regione Lombardia, si prefigge lo scopo di fornireun supporto alla gestione delle emergenze sfruttando i social network, sia per acquisirele informazioni necessarie all'individuazione di una situazione critica, sia come mezzodi comunicazione tra cittadini e Autorità competenti.

Sempre più persone utilizzano i social network, condividendo spontaneamente leinformazioni più disparate, tra cui le segnalazioni che riguardano situazionid'emergenza, divenendo così una sorta di grande “rete di sensori” sparsa su tutto ilterritorio. Inoltre, la diffusione delle reti sociali le rende il canale ideale per raggiungereil maggior numero possibile di utenti dovunque si trovino, in quanto queste applicazionivengono spesso utilizzate su dispositivi mobili.

La grande quantità di informazioni che TORCIA raccoglie ed elabora, rimane però adisposizione anche successivamente alla conclusione della fase critica dell'emergenza.

11

Si è quindi pensato di progettare e realizzare uno strumento di Business Intelligence percompiere analisi su questi dati, concentrandosi sul volume dei messaggi elaborati, conl'obiettivo di migliorare le prestazioni del sistema TORCIA e la gestione delle situazionidi emergenza da parte degli Enti che ne faranno uso.

I capitoli che seguono tratteranno nel Capitolo 2 l'analisi dello stato dell'arte, indicandoil background informativo relativo alla gestione delle emergenze, all'utilizzo dei socialnetwork all'interno di tale contesto e alla Business Intelligence. Il Capitolo 3 invecepresenterà il progetto TORCIA, contesto in cui si inserisce questo lavoro di tesi. Infineil Capitolo 4 si occuperà dello strumento di Business Intelligence sviluppato in questolavoro, descrivendone il framework, la realizzazione, la sua integrazione all'interno diTORCIA e le analisi che esso è in grado di compiere. Verranno presentati anche dei casidi studio basati su alcune delle emergenze rilevate da TORCIA e i miglioramenti che sipotranno apportare in futuro a questo strumento.

12

Capitolo 2

Stato dell'arte

Questo capitolo definisce il background informativo riguardante la gestione delleemergenze, l'utilizzo dei social network all'interno di tale contesto, la BusinessIntelligence e le sue applicazioni nell'ambito della gestione delle emergenze.

La sezione 2.1 definisce cosa si intende per gestione delle emergenze, descrivendo neldettaglio quali attività la caratterizzano.

La sezione 2.2 si focalizza sulla descrizione dei social network e sul loro uso nellagestione delle emergenze.

La sezione 2.3 tratta l'argomento Business Intelligence, dandone una definizione eintroducendo le componenti principali dei sistemi che implementano il suo paradigma.

La sezione 2.4 presenta un'applicazione di successo che utilizza le tecniche dellaBusiness Intelligence per fornire un supporto decisionale per la gestione delleemergenze.

2.1 La gestione delle emergenze

La gestione dell'emergenza può essere vista come un lungo processo di collaborazionetra enti e soggetti che risulta, nella sua rappresentazione classica, in un processo ciclicoformato da diverse fasi, come mostrato nella sezione 2.1.1. L'elemento che si ritrova intutte le fasi è il piano d'emergenza, che viene steso precedentemente all'emergenza verae propria e utilizzato successivamente in fase operativa. La corretta stesura del pianod'emergenza richiede la classificazione dei diversi tipi di eventi che possono generarel'emergenza in modo da concentrarsi sulle loro caratteristiche, al fine di creare un pianooperativo il più possibile efficiente. Le modalità di classificazione degli eventi sarannooggetto della sezione 2.1.3.

13

2.1.1 Ciclo di vita delle emergenze

Nella rappresentazione classica delle emergenze, si è normalmente portati a considerarel'emergenza come un processo ciclico formato da diverse fasi che, nell'insieme,costituiscono quello che viene definito “ciclo di vita delle emergenze”. La suddivisionein fasi consente di pianificare al meglio tutte le strategie e le decisioni che permettono laminimizzazione dei danni e il ripristino nel minor tempo possibile della situazione dinormalità.

Si possono dunque individuare quattro fasi principali che si susseguono l'una dopol'altra,come mostrato in Figura 2.1.

Figura 2.1: Ciclo di vita delle emergenze

I passaggi tra le fasi sono scanditi da eventi che li determinano in modo più o menonetto.

Preparedness

La fase di preparedness, chiamata anche fase preventiva, persegue l'obiettivo di creareun adeguato livello di prontezza nel rispondere alle emergenze che possono verificarsinel territorio. Gran parte delle conoscenze utilizzate in questa fase derivano da eventiprecedenti che hanno permesso l'acquisizione di un know-how sempre più specificosulle diverse emergenze.

L'obiettivo deve essere raggiunto a tutti i livelli organizzativi e decisionali (governo,regioni, comunità, individui) attraverso la rigorosa analisi dei rischi sul territorio, lacircolazione delle informazioni e la creazione di piani di risposta condivisi, seguiti dalladiffusione alla comunità della conoscenza acquisita, in modo da fornire i primistrumenti di autodifesa al verificarsi dell'evento (punti di raccolta, comportamenti daseguire e da evitare...).

14

Response

Durante la fase di response, che ha inizio nel momento in cui accade l'eventocalamitoso, vengono attuate le procedure previste nei piani di emergenza, finalizzate alcontenimento della situazione di crisi e alla limitazione dei danni. All'interno di questafase trovano quindi spazio le attività legate all'attivazione delle risorse disponibili perfronteggiare l'emergenza, alla ricerca di feriti e superstiti, alla predisposizione di rifugi ealloggi, alla creazione di centri di coordinamento e controllo, nonché al passaggio aregimi di legislazione propri della gestione delle emergenze.

Nella response è possibile valutare la bontà delle decisioni prese nella fase precedente alfine di individuare eventuali correzioni, come ad esempio lo stanziamento di nuovifondi o la dotazione di nuovi strumenti, fremo restando che in questa fase è spessonecessario prendere decisioni che differiscono dal protocollo stabilito, come nel caso delverificarsi di situazioni impreviste o inattese.

Recovery

La fase di recovery si attiva nel momento in cui si considera conclusa l'emergenza insenso stretto, ovvero nel momento in cui si è provveduto a mettere in sicurezza personee patrimonio colpiti dall'evento calamitoso.

Detta anche comunemente “ricostruzione”, ha come obiettivo il ritorno alla situazione dinormalità nel minor tempo possibile nei vari ambiti (economico/produttivo, sociale,urbanistico/paesaggistico).

Durante la fase di recovery è necessario gettare le basi per evitare il ripetersidell'emergenza o, nel caso l'evento fosse incontrollabile, limitarne i danni, attraverso unmiglioramento delle strutture distrutte dal disastro.

Mitigation

La fase di mitigation, o mitigazione, è la fase di chiusura del processo. Si tratta di unafase di lungo periodo durante la quale gli enti preposti si attivano per ricercare lecontromisure necessarie ad evitare il ripetersi dell'evento critico o per ridurne leconseguenze, come naturale prosecuzione della fase precedente. Tale operazione puòessere svolta agendo in modi differenti a seconda del rischio presente nell'area, come larealizzazione di opere d'ingegneria sugli elementi ambientali a rischio (per esempio ilrinforzo degli argini di un fiume), o il tentativo di modifica degli stili di vita dellepersone al fine di renderli edotti al rischio (ad esempio con esercitazioni).

La mitigazione sfocia in una nuova fase di preparedness, iniziando così un nuovo ciclo,fornendo nuove conoscenze per il miglioramento delle strategie di prevenzioneriguardanti l'emergenza già fronteggiata.

15

2.1.2 Il piano d'emergenza

Il piano d'emergenza rappresenta un documento finalizzato alla salvaguardia deicittadini e dei beni. Esso è il risultato di uno studio approfondito sulla vulnerabilità delterritorio, sul rischio che esso sia investito da un evento calamitoso e sui punti critici cheall'interno del territorio possono risentire del verificarsi dell'evento. Assume dunque laforma di un progetto che si occupa di definire i dettagli e le strategie riguardanti leseguenti operazioni fondamentali:

• affidamento di responsabilità ad amministrazioni, strutture tecniche,organizzazioni e individui per l'attivazione di azioni specifiche in caso diemergenza o pericolo incombente;

• definizione di scenari di evento e di danneggiamento rispetto alle diversetipologie di rischio;

• definizione della catena di comando e delle modalità di coordinamentonecessarie all'individuazione e attuazione degli interventi urgenti;

• individuazione delle risorse umane e materiali necessarie per il superamentodella situazione di emergenza.

Durante il ciclo di vita del piano d'emergenza devono essere svolte in manieracontinuativa tre attività:

1. aggiornamento periodico del piano stesso, in quanto lo scenario di rischio risentedella dinamicità dell'assetto del territorio;

2. l'attuazione di esercitazioni al fine di verificare la sua validità;

3. trasmissione dell'informazione alla popolazione, in modo che essa sia aconoscenza del rischio e addestrata all'evenienza.

Il piano d'emergenza, la cui redazione è affidata alla Protezione Civile, si basa sul“Metodo Augustus”, creato dal geologo Elvezio Galanti e inquadrato dalla legge255/92[1]. Tale metodo è lo strumento di riferimento per la pianificazione nel campodelle emergenze.

2.1.3 Classificazione delle emergenze

Eseguire una classificazione delle emergenze significa indicarne i parametrifondamentali come origine, evoluzione ed entità coinvolte. È un'operazioneestremamente utile per definire le strategie atte a contenere e risolvere le emergenze,che scaturisce dalla constatazione che non tutti gli eventi critici che si verificano sulterritorio richiedono piani di intervento predefiniti: alcuni possono essere incidentibanali che possono essere risolti senza una preparazione preventiva, altre volte invece sipossono verificare casi più critici che richiedono piani operativi mirati e più elaborati.

16

Per questo motivo sono stati definiti diversi criteri di classificazione [15]:

Secondo il Grado di Impatto: Fornisce la misura sia quantitativa che qualitativa dellapotenza intrinseca di un certo evento critico. Viene descritto dalle seguenti dimensionidi analisi:

• livello di gravità;

• estensione geografica;

• durata temporale.

Il grado di impatto viene classificato in base ai valori assunti dalle tre dimensioni dianalisi come lieve, moderato o alto.

Secondo la Scala: Questo criterio di classificazione, variante del criterioprecedentemente esposto, si concentra maggiormente sulla dimensione socialeall'interno del quale l'evento critico impatta. Le dimensioni di analisi che vengonoconsiderate sono:

• magnitude, ovvero l'ampiezza dei soggetti ai quali l'evento ha imposto unasostanziale modifica delle abitudini di vita;

• scope, cioè i confini geografici e sociali coinvolti;

• duration, cioè la durata degli effetti sociali.

Secondo queste dimensioni, è possibile classificare il parametro di scala in emergenza,disastro o catastrofe.

Secondo il Tipo: Indica che cosa viene colpito. La suddivisione avviene tra disastricomunitari, dove viene colpito un ampio insieme di risorse fisiche e umane, e disastrisettoriali, dove viene colpito un segmento specifico della comunità.

Secondo l'Anticipabilità: Gli effetti prodotti da un evento sono molto diversi a secondadi quanto l'evento risulti più o meno atteso, ovvero in base al livello di preparazioneraggiunto dalle organizzazioni riguardo ad esso.

L'anticipabilità viene valutata in base a due dimensioni di analisi:

• predicibilità, cioè quanto l'evento è predicibile;

• influenzabilità, cioè quanto sono realistiche le strategie di riduzione dei dannicausati dall'evento.

La combinazione di queste dimensioni origina quattro diverse tipologie di evento:

1. convenzionale, facilmente influenzabile e predicibile

2. inaspettato, facilmente influenzabile ma difficilmente predicibile

17

3. intrattabile, difficilmente influenzabile ma facilmente predicibile

4. fondamentale, difficilmente influenzabile e predicibile

Una classificazione più generale è data dalla suddivisione degli eventi critici in duetipologie [15]:

• eventi di origine naturale;

• eventi di origine umana/tecnologica.

Eventi di origine naturale

Con eventi di origine naturale si intendono tutti gli eventi generati da fenomeni naturali.Sono moltissimi e di diversa natura, spesso strettamente connessi tra loro poichépossono generarsi contemporaneamente o come conseguenza uno dell'altro. I principalisono:

• Inondazioni e alluvioni: si tratta di un allagamento di un'area ben definita eabitualmente asciutta da parte di una massa d'acqua, che avviene solitamente intempi brevi. Si parla di alluvione nel caso di inondazione provocata dallatracimazione di corsi d'acqua ingrossati dalle piogge elevate;

• Terremoti: sono improvvise vibrazioni o oscillazioni della crosta terrestreprovocate dallo spostamento di una massa rocciosa nel sottosuolo. Sono glieventi naturali più potenti che possono causare gravi distruzioni e perdite di viteumane, nonché originare altri eventi calamitosi come inondazioni, frane, incendio fuoriuscite di materiali pericolosi. Se i terremoti si generano sotto la superficieoceanica possono generare maremoti o tsunami;

• Uragano e tornado: un uragano è un ciclone tropicale, ovvero di un sistematempestoso caratterizzato da un largo centro di bassa pressione e da numerositemporali che producono forti venti e pesanti piogge. La tromba d'aria o tornadoè invece un violento vortice d'aria che si genera alla base di un cumulonembo egiunge a toccare il suolo. I tornado che si formano sopra a distese d'acquaprendono il nome di trombe d'acqua o trombe marine, che generano venti divelocità simile a quella dei tornado terrestri, ma a causa dell'assenza di ostacolisul loro percorso si formano con maggiore facilità e si dissolvono piùlentamente;

• Eruzioni vulcaniche: consistono in fuoriuscite di magma tramite eruzione daspaccature delle superficie terrestre. Possono causare distruzioni e danni ingenti;

• Frane: con il termine frane si indicano tutti i fenomeni di movimento o caduta dimateriale roccioso causati dalla rottura di un equilibrio statico preesistente.Possono causare danni e perdite di vite umane e, se avvengono in prossimità dicorsi d'acqua, possono provocare esondazioni.

18

Eventi di origine umana/tecnologica

Questi tipi di eventi sono dovuti all'innovazione tecnologica e allo sviluppo umano.Possono essere causati volontariamente o involontariamente dall'uomo e spesso hannouna concausa naturale. I principali sono:

• Dighe: sono sbarramenti costruiti per modificare il corso dei fiumi o per ilcontenimento di bacini idrici. Queste strutture possono cedere a causa di erroridi progettazione o di manutenzione inadeguata, provocando danni ingenti. Leforti piogge e le inondazioni possono originare uno straripamento o, nel caso incui l'acqua assuma una forza dirompente, la distruzione della diga stessa.

• Caduta di edifici: può essere causata da una cattiva progettazione o da eventinaturali quali frane, terremoti e inondazioni;

• Epidemie: sono malattie infettive che sorgono in relazione a specifichecondizioni igienico-sanitarie.

2.2 I social network e il loro ruolo nella gestione delle emergenze

In questa sezione verranno trattati i social network e il loro utilizzo nella gestione delleemergenze.

La trattazione inizierà con una loro descrizione generale, spiegando quali caratteristicheli accomunano e le teorie sviluppate su di essi. Ci si concentrerà quindi su di unparticolare soclial network, Twitter, spiegando il suo funzionamento e le ragioni del suo“successo” sia in Italia che nel mondo.

Successivamente si esporrà il concetto di crowdsourcing, concetto fortemente legato aisocial network, approfondendo il suo utilizzo nelle quattro fasi del ciclo di vita delleemergenze.

La trattazione si concluderà mostrando diversi casi emblematici, dove l'utilizzo deisocial network ha avuto un ruolo predominante nella gestione delle emergenze.

2.2.1 I social network

I social network, in italiano reti sociali, sono definiti come gruppi di individui connessitra loro da diversi legami sociali. Tali legami posso essere di varia natura: vincolifamiliari, amicizia, rapporti di lavoro, interessi comuni o anche conoscenze casuali.

Lo studio dei social network è iniziato nel lontano 1900 grazie al filosofo e sociologoGeorg Simmel, autore di una prima teoria per l'interpretazione dei fenomeni sociali [18].Nel 1964 lo psicologo Moreno propose la prima rappresentazione formale dei socialnetwork come combinazione di archi e nodi [13], rappresentazione ripresa e sfruttata in

19

seguito da Haray e Cartwright per la creazione di sociogrammi derivanti dalla teoria deigrafi [7]. Basandosi su tale rappresentazione, iniziarono a essere teorizzati i complessimodelli sociali che si trovano alla base dei social network.

Da qui si svilupparono due diverse scuole di pensiero:

• l'approccio sociocentrico, focalizzato sull'individuazione di sottogruppi dipersone appartenenti alla medesima rete sociale e sullo studio delle relazioni cheintercorrono tra essi;

• l'approccio egocentrico, focalizzato sullo studio dell'intera comunità.

A questa seconda scuola di pensiero apparteneva lo psicologo statunitense StanleyMilgram, che enfatizzò l'importanza delle reti sociali come strumento di condivisione diinformazioni e conoscenza. Milgram inoltre ideò e condusse un esperimento atto adimostrare la Teoria del mondo piccolo, teoria secondo la quale tutte le persone delmondo sono collegate da una rete di conoscenze e che presa una qualsiasi coppia dipersone sono sufficienti pochi “passaggi intermedi” per giungere da una personaall'altra.

L'esperimento di Milgram, svolto negli Stati Uniti, dimostrò che il numero di passaggiintermedi richiesti per collegare due persone oscillava mediamente tra 5 e 7, contro laprevisione di almeno un centinaio di passaggi formulata dai promotori dell'esperimento.

Questi risultati portarono alla formulazione della famosa teoria dei “sei gradi diseparazione”, oggi applicata in svariate aree quali la trasmissione delle malattie, lateoria dei grafi e le telecomunicazioni [12].

Con la diffusione del web e del termine social network sono sorte delle ambiguità disignificato. Infatti le reti sociali vere e proprie sono nate come reti sociali fisiche mentrequelle basate sul web sono considerate come forme di comunicazione in rete: talipiattaforme web permettono l'organizzazione delle relazioni umane in una mappainformatica.

Secondo la definizione data dagli studiosi Boyd e Ellison [4] si possono definire i socialnetwork sites come servizi Web che permettono di:

• creare un profilo pubblico o semi-pubblico all'interno di un sistema vincolato;

• articolare una lista di altri utenti con cui avere una connessione;

• vedere la lista dei propri contatti e ciò che fanno all'interno del sistema.

I social network sites che a livello mondiale e italiano sono più diffusi e hanno ilmaggior numero di utenti sono Facebook, Twitter e LinkedIn [19]. I servizi essenzialiche questi social network mettono a disposizione sono:

• creazione di un profilo utente, contente una serie di dati in parte inseriti

20

dall'utente e in parte creati automaticamente in base all'utilizzo della piattaforma.In base alla tipologia di social network site il profilo può essere reso pubblico,semi-pubblico o privato agli utenti della rete;

• creazione di gruppi: consente una condivisione mirata di conoscenza e contenuti;

• ricerca contatti: è possibile ricercare altri utenti dalle liste di contatti degli amicio da una lista pubblica.

Lo sviluppo sempre più massiccio degli samrtphone ha ulteriormente modificato ilpanorama dei social network. Secondo uno studio condotto da “BI Intelligence” nel2013, in media, la percentuale del traffico generato da dispositivi mobili rispetto aquello totale è pari al 40%, percentuale che sale al 50% per Facebook e al 70% perTwitter [11].

Più in generale, i social network sites rientrano nel più ampio gruppo dei social media,l'insieme di tutte le tecnologie e pratiche online usate dalle persone per condividerecontenuti testuali, immagini, audio e video.

2.2.1.1 Twitter

Twitter è uno dei social network sites più diffusi a livello mondiale. E' un servizioonline gratuito di social networking e microblogging e dà la possibilità agli utenti dipubblicare e leggere messaggi testuali di lunghezza massima di 140 caratteri, chiamati“tweet”. Ogni utente ha un profilo personale che può aggiornare mediante messaggi distato, che diventano immediatamente disponibili, una volta inseriti, su di esso e negliaggiornamenti di stato di tutti coloro che sono follower dell'utente. Infatti la relazioneche intercorre tra gli utenti è una relazione monodirezionale di follower/following con leseguenti caratteristiche:

• un utente può vedere gli aggiornamenti di stato e i profili personali di tutti ifollowing (utenti che egli “segue”). Potrà commentare un tweet specifico,pubblicato da loro, tramite la funzionalità di mention (@) o condividerlomediante la funzionalità di retweet (RT);

• il profilo personale dell'utente e tutti gli aggiornamenti di stato sono, invece,visibili solo dai suoi follower, cioè da tutti gli utenti che hanno deciso di“seguirlo”.

Nonostante non esista in Twitter il concetto di “conversazione”, è comunque possibileraggruppare i tweet mediante l'utilizzo di un hashtag (#). Gli hashtag definisconol'argomento della discussione e aiutano nella ricerca di tutti i tweet recenti riferiti adesso. Tale ricerca può essere effettuata anche tramite keyword e restituisce un insieme dimessaggi pubblici contenenti tale keyword scritti da diversi utenti, indipendentementedal fatto che chi ha eseguito la ricerca sia loro follower. Questo dimostra il carattere

21

giornalistico di questo social network e di come sia diventato una piattaforma diriferimento per la diffusione di news.

Twitter è interamente costruito su architettura Open Source e mette a disposizione oltreal social network site anche una social network mobile app, scaricabile gratuitamentedai più popolari store, e numerose API, che permettono a varie applicazioni di utilizzareal loro interno i suoi servizi1.

Twitter rappresenta un ottimo strumento per la diffusione delle informazioni, mediantela struttura basata su follower, che stimola la condivisione e genera il fenomeno socialedella influence: una minoranza di utenti, chiamati influencers, eccellono nelconvincimento di tutti gli altri. Tale meccanismo non dipende, essenzialmente, dalnumero di follower di un utente, ma dalla stima percepita verso l'autore che stimola lafunzione di mention (risposta/citazione di un tweet) e dal valore intrinseco del tweetstesso che provoca i retweet. Questo porta alla teoria fondamentale chiamata “millionfollower fallacy”, la quale afferma che non è il numero di follower a garantirel'influenzabilità di un utente, ma piuttosto la pertinenza delle cose che scrive [9].

Twitter in Italia

A livello mondiale Twitter è il social network con la più veloce crescita di utenti attivi.Secondo una statistica2 condotta nel Dicembre 2013, a livello mondiale dal 2010 adoggi il numero di utenti Twitter è aumentato da 172 milioni a più di 500 milioni. AdAprile 2014 Twitter si colloca al quarto posto nella classifica del traffico web generatodalle piattaforme social a livello mondiale, con una quota del 7,3%, dietro a Facebook,Pinterest e Tumblr. La maggioranza degli utenti di Twitter è solita connettersi viamobile. Sempre in riferimento ai dati di Aprile 2014, la percentuale di traffico di Twitterrelativa ai soli dispositivi mobili è del 13,08%, contro il 4,36% da pc e il 7,15% datablet, collocandosi al terzo posto dietro a Facebook e Pinterest3.

In Italia, nel 2010, erano presenti circa 1.3 milioni di utenti registrati, 350 mila dei qualieffettivamente attivi. Nel 2013 il numero di utenti registrati ha superato i 9.5 milioni e aFebbraio 2014 il 41% degli italiani che utilizza i social network possiede un accountTwitter.

In uno studio meno recente, si osserva invece la natura dei tweet pubblicati: durante iprimi sei mesi del 2012 in Italia sono stati lanciati in rete 60 milioni di tweet, di cui il26% contenente un link, il 19% è un retweet, il 26% ha un hashtag e solo il 5% ègeolocalizzato. Facendo un'analisi più approfondita risulta inoltre che Twitter vieneutilizzato soprattutto per scopi seri come la testimonianza e la condivisione di fatti dicronaca : esempi significativi sono i tweet riferiti alla bomba di Brindisi e al terremoto

1 http://dev.twitter.com2 http://wearesocial.it/blog/2013/12/latest-3-years-twitter-34-milioni-di-utenti-attivi-italia/3 http://www.agopress.it/i-social-media-piu-usati-in-italia-e-nel-mondo/6892

22

che ha colpito l'Emilia Romagna. A dimostrazione di ciò sono significative le paroledette dal direttore de “Il Post”, un quotidiano online italiano: “Noi al Post sappiamo lecose che accadono nel mondo prima da Twitter e poi dalle agenzie. E ciò non riguardasolo il tempismo ma anche l'affidabilità” [2].

2.2.2 Il Crowdsourcing

Il crowdsourcing secondo la definizione di Estellés e Gonzàlez [10]:

“Il crowdsourcing è una tipologia di attività online partecipativa nella quale unapersona, istituzione, organizzazione, non a scopo di lucro o azienda propone ad ungruppo di individui, mediante un annuncio aperto e flessibile, la realizzazione libera evolontaria di un compito specifico. La realizzazione di tale compito, di complessità emodularità variabile, e nella quale il gruppo di riferimento deve partecipare apportandolavoro, denaro, conoscenze e/o esperienza, implica sempre un beneficio per ambo leparti. L'utente otterrà, in cambio della sua partecipazione, il soddisfacimento sociale, diautostima, o di sviluppo di capacità personali; il crowdsourcerer, d'altro canto, otterrà eutilizzerà a proprio beneficio il contributo offerto dall'utente,la cui forma dipenderà daltipo di attività realizzata”.

Quindi il crowsourcing può essere visto come un modello di produzione e risoluzione diproblemi dove la soluzione viene richiesta ad un gruppo non definito di persone, la“crowd”, che normalmente si riuniscono in comunità online. Spesso gli utenti chehanno fornito il loro contributo nel trovare la soluzione vengono ricompensati in denaroo con premi e riconoscimenti. Grazie allo sviluppo di Internet e del Web, oggi ilcrowdsourcing viene mutuato solo attraverso questi canali.

2.2.2.1 Il Crowdsourcing e le fasi dell'emergenza

L'informazione sociale garantita attraverso il crowdsourcing può essere molto utile nellagestione delle emergenze. Queste informazioni possono essere di supporto in tutto ilciclo delle emergenze e possono essere di natura diversa.

Vediamo, quindi, ogni fase da che tipo di informazione può essere caratterizzata.

Preparedness

In questa fase i cittadini possono fornire informazioni relative allo stato di rischio delterritorio e identificando le infrastrutture critiche. Normalmente, le segnalazioniraggiungono le autorità sotto forma di lamentela ed è necessario che vengano sfruttate alfine di elaborare un migliore piano di emergenza e in particolare di effettuare unamigliore analisi del rischio. In questa fase risulta molto utile l'attivazione da parte delleautorità del crowdfeeding, cioè l'attivazione di una serie di strumenti per istruire icittadini su cosa fare in caso di emergenze.

23

Response

Essendo la fase più critica le informazioni che provengono dai cittadini sono molto

significative e devono essere utilizzate a supporto delle decisioni strategiche nelmomento di risoluzione dell'emergenza. Queste informazioni possono contenere unadescrizione della situazione generale del territorio, dati relativi allo stato dei cittadinicolpiti oppure richieste d'intervento.

Recovery

Durante la fase di recovery i cittadini possono informare le autorità relativamente aquali siano gli interventi necessari per la ricostruzione post emergenza. Il crowdsourcingpuò essere inoltre dalle autorità per consultare esperti esterni per le problematicherelative alla ricostruzione.

Mitigation

Durante questa lunga fase, il crowdsourcing può essere utile per raccogliere lamentele eproblematiche sociali derivanti dall'evento. Questi dati devono essere sfruttati nellasuccessiva fase di preparazione.

2.2.3 Utilizzo dei social network nella gestione delle emergenze: casi reali

In questa sezione si mostreranno una serie di esempi significativi che possano fornireuna testimonianza concreta di come i social network possano essere utilizzati duranteuno scenario reale di emergenza, risultando importanti se non addirittura fondamentalinella loro gestione e risoluzione.

Si spiegherà come le reti sociali possano rappresentare una nuova strategia dicomunicazione e come possano fornire una distribuzione più efficiente delleinformazioni rispetto ai sistemi tradizionali che si affidano al mezzo stampa.

Si analizzeranno eventi passati nei quali i social network hanno avuto un ruolopredominante nella diffusione di informazioni da parte delle autorità e hanno permessoalle persone in difficoltà di richiedere assistenza o semplicemente rimanere informatesul quadro dell'emergenza.

Infine si descriveranno alcuni sistemi adottati da enti e organizzatori, sia estere cheitaliane, per estrarre informazioni sociali dai messaggi presenti nei social network percostruire dati aggregati utili per la prevenzione e la risoluzione di eventi disastrosi.

2.2.4.1 Una nuova strategia di comunicazione: il caso NORAD NORTHCOM

NORAD (North American Aerospace Defence Command) e NORTHCOM (U.S.

24

Northern Command) sono e principali agenzie militari americane per la difesa eadottano strategie intelligenti per lo sfruttamento dei social media.

Nel piano di comunicazione proposto nel 2010 sono stati associati ai canali tradizionali(agenzie di stampa) account sui principali social network (Twitter, Facebook, Youtube eFlickr) e un blog gestito dal comandante per informazioni importanti e tempestive.

Il meccanismo di diffusione delle informazioni sfrutta le ricondivisioni assumendo unamodalità esponenziale: il comando invia i messaggi ad una rete di dipendenti interni, iquali a loro volta li devono ricondividere con la propria rete privata di contatti.Ovviamente anche questi ultimi eseguiranno la medesima operazione e di conseguenzal'informazione tenderà ad espandersi in maniera esponenziale, raggiungendo un'elevatapercentuale di cittadini.

Si può assumere che le informazioni più importanti, cioè quello relative a situazioni diemergenza, siano quelle che verranno ricondivise in maniera spontanea e che avrannoun maggior “successo sociale”.

2.2.4.2 Uragano Gustav in Louisiana (Agosto 2008)

L'uragano Gustav fu il settimo ciclone tropicale e il secondo uragano maggiore nellastagione degli uragani atlantici del 2008. Il governo, memore della tragedia avvenutaanni prima, decise di far evacuare l'intero stato per evitare vittime. Il Dipartimento diSicurezza Americano chiese aiuto al social network MySpace, allora molto popolare,richiedendo lo sviluppo di un widget, un'applicazione predefinita, al fine di coordinareal meglio gli spostamenti. In particolare, il widget aveva l'obiettivo di aiutare nellaricerca delle persone scomparse con un sistema di geolocalizzazione, permettere diseguire in tempo reale l'avanzamento dell'uragano verso la costa e donare fondi.L'utilizzo di tale widget fu di grande aiuto nella fase di evacuazione, permettendoinoltre una riduzione del traffico telefonico d'emergenza.

I social network, soprattutto Facebook, risultarono utili anche per gli Stati chiamati adaccogliere gli sfollati della Louisiana per contattare i volontari, al fine di rispondere inmodo celere alla chiamata di emergenza.

2.2.4.3 Eruzione del vulcano Eyjafjöll in Islanda (Aprile 2010)

Il 20 Maro 2010 iniziò una serie di eventi di natura vulcanica sul vulcano Eyjafjöll inIslanda, culminati nell'eruzione del 14 Aprile 2010. Essa provocò seri problemi altraffico aereo fino al 23 Aprile, con conseguenti chiusure degli aeroporti del nordEuropa.

Si rese perciò necessaria una strategia di comunicazione nei confronti dei lavoratori edei turisti bloccati a terra. Tale strategia di comunicazione ebbe come mezzo principale isocial network: le principali compagnie aeree si unirono alle conversazioni dei

25

maggiori social network per raggiungere più facilmente i propri clienti e fornire unservizio di assistenza funzionale. In particolare su Twitter, alcuni hashtag ebbero unanotevole diffusione, raggiungendo oltre 55000 mention. Anche la piattaforma Flickrdiede il suo contributo alla diffusione delle informazioni tramite immagini scattatedurante l'emergenza.

I danni registrati delle compagnie aeree nei primi sette giorni dell'emergenzaammontarono a 1.7 miliardi di dollari, ma la cifra sarebbe potuta essere maggiore senzal'adozione di un'adeguata strategia di comunicazione. Ciò testimonia l'importanza deisocial network nella diffusione delle informazioni utili.

2.2.4.4 Terremoto, tsunami e disastro nucleare in Giappone (Marzo 2011)

Nel Marzo 2011, il nord-est del Giappone venne colpito da un sisma di magnitudo 9 conepicentro sul fondo marino dell'oceano Pacifico, a circa 500 km da Tokio. Si generò inseguito uno tsunami con onde alte circa 10 metri che penetrarono fino a 10 kmnell'entroterra.

Il sisma provocò anche lo spegnimento di undici centrali nucleari tramite un sistema diemergenza automatico. Tuttavia, a causa del cattivo funzionamento dei meccanismi diraffreddamento danneggiati dal sisma, alcuni dei reattori della centrale di Fukushimaesplosero, creando una fuga radioattiva particolarmente pericolosa, in quanto uno deireattori esplosi era alimentato con un combustibile contenete plutonio. Comeconseguenza di tali eventi, venne imposta l'evacuazione per più di 110 mila personeintorno a Fukushima, oltre ad un alto numero di persone che dovettero abbandonare leproprie case in seguito ai danni subiti per il sisma ed il maremoto.

La comunicazione tramite reti telefoniche divenne praticamente inaccessibile, a causadelle migliaia di richieste. La rete Internet, però, risultò funzionante, dando la possibilitàalle persone di comunicare tramite social network ed usufruire delle informazioni disupporto diffuse dagli account delle principali città ai propri cittadini.

La rete venne sfruttata anche per il lancio di iniziative benefiche a favore degli sfollati eper le relative raccolte fondi. Inoltre il web developer Ysuke Wada creò un database perraccogliere informazioni provenienti da Twitter riguardo le persone scomparse e,sempre tramite i social network, reclutò 200 volontari per aiutarlo nella gestione delsistema.

2.2.4.5 Terremoto dell'Emilia (Maggio 2012)

Il 20 Maggio 2012 un terremoto di magnitudo 5.9 con epicentro a Finale Emilia (MO),colpì l'Emilia Romagna provocando 7 morti, circa 50 feriti, 5000 sfollati e danni stimatia 13 miliardi di euro.

26

Per l'evento, venne istituito un sito internet coordinato da persone comuni, che divenneil canale ufficiale di contatto tra cittadini e istituzioni e che raccolse inoltre oltre610.000 euro di donazioni. Alcuni canali informativi non ufficiali però, permisero ladiffusione di informazioni generiche e a volte addirittura false. Per questo il sindaco diSan Felice sul Panaro richiese la certificazione dei post da parte delle istituzioni al finedi non creare falsi allarmismi.

I social network si rivelarono utili per l'invio di richieste di aiuto e di fondi. Inoltrevennero creati su Facebook alcuni gruppi con lo scopo di raccogliere riferimenti dipersone o famiglie bisognose di un posto letto.

2.2.4.6 Uragano Sandy (Ottobre 2012)

L'uragano Sandy è stato il decimo uragano del 2012 e ha colpito molti stati americanitra cui Cuba, la Giamaica, le Bahamas e la costa orientale degli Stati Uniti. Con undiametro di circa 1850 km è uno dei più grandi uragani mai osservati ed il secondo piùdistruttivo (in termini economici) della storia, dietro solo all'uragano Katrina. Sandy sì èsviluppato il 22 Ottobre 2012 da un'onda tropicale nel Mare dei Caraibi occidentale,rafforzandosi nei giorni successivi fino ad essere classificato come uragano il 24Ottobre.

Il giorno 29 Ottobre l'uragano è giunto a New York, causando danni ingenti. MentreManhattan era al buio, le linee telefoniche erano in tilt e molti siti internet crahavano, ilsolo strumento che non ha mai smesso di rivelarsi utile è stato il social network Twitter:difatti è stato utilizzato come vera e propria linea di soccorso e ha permesso ladiffusione di comunicazioni istituzionali, foto in tempo reale dei luoghi allagati erichieste di aiuto.

Twitter era già stato utilizzato anche nei giorni precedenti da molte agenzie governativee organi ufficiali, come l'Ente federale per la gestione delle emergenze, il governatore diNew York Andrew Cuomo e l'account ufficiale per la gestione delle emergenze nellacittà di New York NotifyNYC, per inviare aggiornamenti e ordini di evacuazione.

Il giorno dell'emergenza gli account della Croce Rossa Americana e dei Vigili del Fuocosono stati presi d'assalto, con richieste di qualunque tipo, ma di cui la maggioranzaerano richieste d'aiuto. Grazie a questi dati la Croce Rossa Americana è riuscita atracciare una mappa delle emergenze nella metropoli, individuando le aree in cui eranecessario concentrare i soccorsi.

Per l'occasione, Twitter ha messo a disposizione dei cittadini strumenti che sonoriservati solitamente agli inserzionisti pubblicitari: per la prima volta, l'azienda ha creatouna pagine evento con hashtag “#Sandy” in modo da raggruppare tutti i tweet relativiall'uragano e permettere ai suoi utenti di essere informati in tempo reale sugli ultimiaggiornamenti sul da farsi. Inoltre, è stata data la possibilità alle istituzioni di pubblicare

27

tweet promossi, ovvero tweet normalmente riservati ad inserzionisti e usati perraggiungere un pubblico più vasto possibile, e una serie di servizi basati sul codicepostale dell'utente, in modo da raggiungere un pubblico residente in una data area.

Twitter ha fatto sì che venisse utilizzato anche il sito di photo sharing Instagram, che haraccolto migliaia di scatti riguardanti i disastri causati da Sandy.

Purtroppo sono stati postati anche scatti clamorosamente falsi, come la foto di un suball'interno della metropolitana allagata o quella di squali che nuotavano nei cortili delNew Jersey. Ma nonostante il fatto che sul social network non fosse stato impostatonessun meccanismo di censura o altro, gli account maggiormente prolifici di notiziefalse sono stati immediatamente individuati e ogni messaggio fasullo è statosmascherato in breve tempo. Twitter insomma, come ha riferito un esperto di socialmedia su BuzzFeed, è una grande “fact-processing machine”, una macchina cheprocessa velocemente informazioni e che si libera altrettanto velocemente di quellesbagliate [17].

2.2.4.7 Alluvione in Sardegna (Novembre 2013)

Nel mese di Novembre 2013 la tempesta Cleopatra ha investito la Sardegna con unamole d'acqua mai vista prima. Si sono registrati danni in diverse zone delle regione,come Olbia, Terralba, Bitti e Arzachena e un totale di 16 vittime. Questa terra, piùabituata alla siccità che ai diluvi, non era pronta a un evento di simile portata.

Il capo della protezione civile Gabrielli disse che in Sardegna aveva trovato più buonavolontà che organizzazione. Anche se lo stato d'emergenza era stato dichiarato pertempo, la macchina statale è stata troppo lenta nel mettersi in moto.

Gli abitanti della Sardegna pensarono allora di darsi da fare per aiutare chi era rimastosenza casa e non aveva più un posto dove ripararsi: coloro che avevano a disposizioneun alloggio libero potevano dare la propria disponibilità per ospitare chi aveva bisogno.L'iniziativa è stata portata avanti sul social network Facebook tramite la pagina“Apriamo le case ai nostri concittadini”, sulla quale comparirono numerosi messaggi dicittadini volenterosi che misero a disposizione villette al mare, Bed and Breakfast,camere libere nelle proprie case o che si offrivano di curare i bambini delle famigliecolpite del disastro.

2.2.4.8 Alluvione a Senigallia (Maggio 2014)

Il 3 Maggio 2014 a Senigallia si è manifestata una delle peggiori alluvioni nella storiadella città. Una particolare situazione meteorologica ha scatenato nell'area una serie diviolenti nubifragi che hanno provocato l'esondazione del fiume Misa, sommergendo iquartieri a sud del fiume e dell'hinterland. L'alluvione ha provocato due vittime e danni,a Settembre 2014, per 99 milioni di euro.

28

Durante l'emergenza i social network sono stati utilizzati sia dalle autorità che daicittadini. Il sindaco ed il comune hanno lanciato numerosi messaggi su Twitter persegnalare quali erano le zone pericolose da evitare. I cittadini dal canto loro hannoaperto sul social network Facebook il gruppo “SOS Alluvione Senigallia”, che si èproposto come canale non ufficiale di condivisione di informazioni tra Senigalliesi, alloscopo di aiutarsi vicendevolmente e fornire la propria disponibilità, in maniera simile aquanto realizzato per l'alluvione in Sardegna. Inoltre, i social network sono statiutilizzati, assieme ad altri canali, per pubblicizzare raccolte a scopo benefico in favoredegli alluvionati.

2.2.4.8 American Red Cross Digital Operations Center

La Croce Rossa Americana creò nel 2012, il primo centro operativo digitale per lagestione delle emergenze basato sul monitoraggio costante e intelligente dei socialnetwork. All'interno del centro, i monitor forniscono costantemente dati aggregatiricavati delle informazioni provenienti dai principali social network, utilizzati perprevenire e gestire al meglio, in ogni fase, le emergenze.

Al centro operativo è sempre presente una persona fisica, ma i dati sono disponibilitramite il Web per i volontari, che, in caso di emergenza, hanno accesso ad un front-endtelematico mediante il quale possono informare gli altri sulle situazioni di pericolo oricevere istruzioni su come muoversi condividendo la propria identità e posizione. Inquesto modo è possibile richiamare i volontari fuori dall'orario di servizio e far si che ilsistema di segnalazione risulti tempestivo.

I dati registrati costituiscono un supporto informativo per le decisioni strategiche. Incaso di disastri di grandi dimensioni, viene usato il Disaster Operations Center, uncentro operativo che permette sia l'aggregazione intelligente dei dati, l'invio diinformazioni push a tutti gli utenti dell'app della Croce Rossa per smartphone o sonoiscritti ai suoi account nei diversi social network. Il Disaster Operations Centerpermette inoltre di inviare in maniera continua report alle centrali operative ecomunicare direttamente con gli operatori mediante specifiche console.

I dati aggregati vengono presentati agli operatori attraverso diversi formati divisualizzazione:

• heat map: illustra il volume delle conversazioni sulla mappa, permettendol'identificazione dei punti caldi;

• community: illustra i profili delle persone che parlano di un certo topic e qualisono gli utenti con più follower;

• universe: illustra i volumi di conversazione attuali riguardanti topic specifici,permettendo di effettuare sentiment analysis su di essi;

29

• conversation dashboard: illustra i volumi di traffico lungo un arco temporale,evidenziando quando certi topic specifici smettono di generare traffico.

I dati così visualizzati consentono di costruire i topic profiles, ovvero profili diconversazione relativi ad uno specifico avvenimento. Tali profili sono molto importanti,in quanto rappresentano un insieme di informazioni mirate.

La app della Croce Rossa Americana

La applicazione mobile della Croce Rossa Americana, sviluppata su piattaforma iOS, èun supporto di carattere puramente informativo per il cittadino. In essa sono raccoltitutti i punti di ricovero (gli shelters) raggiungibili e ai quali è possibile chiedereaccoglienza in caso di eventi critici. Tali punti sono visualizzati all'interno di unamappa, con le relative informazioni specifiche sul ricovero.

Inoltre, è possibile visualizzare una seria di news attraverso un collegamento diretto alsito della Croce Rossa, fornendo così al cittadino informazioni dettagliate e precise.

2.2.4.9 Una piattaforma di crowdsourcing: Ushahidi

Ushahidi, il cui significato in Swahili è “testimonianza”, è un sito inizialmente nato alloscopo di costruire una mappa degli episodi di violenza verificatisi in Kenya dopo leelezioni del 2008. Oggi Ushahidi Inc. è un'azienda no-profit con sede in Kenya chesviluppa software open source gratuito per la raccolta, visualizzazione egeolocalizzazione interattiva di informazioni. L'azienda mira a sfruttare il paradigma delcrowdsourcing rivolto all'attivismo sociale e alla responsabilità pubblica. Offre, quindi,la possibilità ai cittadini di inviare attraverso smartphone o rete internet informazioniutili, al fine di creare archivi temporali e geospaziali di eventi di interesse pubblico.

Il concetto base del sito creato da Ushaidi4 è quello di rendere visibile agli utenti mappedi dominio pubblico, contenenti dati mirati in riferimento ad un evento specifico sceltoda colui che genera la mappa, con la possibilità per chiunque di offrire segnalazioni.

I dati così raccolti possono essere utilizzati sia dai cittadini, per identificare le aree dipericolosità, sia dalle istituzioni per la risoluzione delle emergenze e a supporto delledecisioni critiche.

Il software è stato utilizzato in varie situazioni che necessitavano attenzione, in diversisettori e in varie parti del Mondo. Alcuni esempi sono il terremoto di Haiti nel 2010,durante le proteste democratiche in Medio Oriente nel 2011 e le elezioni parlamentari inArmenia nel 2012. Ushahidi ha ricevuto vari premi, tra cui il MacArthur Award per lasua effettiva efficacia e la sua innovatività nell'aiuto per la risoluzione di problemi diinteresse globale.

4 http://www.ushahidi.com

30

Utilizzo di Ushahidi durante il terremoto di Haiti (Gennaio 2010)

La piattaforma di crowdsourcing Hushaidi è stata utilizzata durante la situazione diemergenza creatasi in seguito al terremoto di Haiti nel 2010, tramite la partecipazione dinumerosi volontari e organizzazioni umanitarie al Ushaidi Haiti Project (UHP).

UHP permise la raccolta e le diffusione di informazioni relative ai luoghi colpiti,facilitando gli spostamenti attraverso la creazione di mappe stradali sulle quali furonosegnalati i precorsi sicuri e le zone praticabili.

La piattaforma venne utilizzata anche dell'esercito e dal Dipartimento StataleAmericano per conoscere nello specifico la situazione locale e organizzare le operazionidi soccorso al meglio. L'aspetto più importante del suo utilizzo nasce dal fatto che èl'unico e il più completo aggregatore di informazioni riguardanti le zone colpite, in unterritorio in cui supporti informatici efficienti sono piuttosto carenti. Numeroseinterviste a responsabili ufficiali hanno testimoniato il reale apporto di Ushahidi nelsalvataggio di numerose vite umane.

Non sono mancati purtroppo alcuni problemi nell'utilizzo della piattaforma: in alcunezone la connessione internet era totalmente assente o troppo lenta ed inoltrel'aggregazione dei dati fornita da Ushahidi non era corrispondente a quella richiestadalle autorità per prendere decisioni concrete e pertanto numerose informazioni nonpoterono essere sfruttate per tempo.

2.3 La Business Intelligence

Questa sezione si occuperà della Business Intelligence.

Dopo averne dato una definizione, verranno introdotte le componenti principali deisistemi di Business Intelligence utilizzati all'interno di TORCIA e in alcune applicazionisviluppate nel contesto del supporto alla gestione delle situazioni d'emergenza.

2.3.1 Definizione di Business Intelligence

Il termine “Business Intelligence”, cui spesso ci si riferisce con l'abbreviazione BI, ècomparso per la prima volta nel 1958 nell'articolo “A business intelligence system” diHans Peter Luhn, ricercatore e inventore tedesco, che all'epoca lavorava per IBM.Nell’articolo, Luhn parla di un “automatic method to provide current awarenessservices to scientists and engineers”.

La prima vera definizione di Business Intelligence è stata però proposta molti anni dopo,nel 1989, per opera di Howard Dresner, analista di Gartner Group, per descrivere glistrumenti informatici in grado di soddisfare le esigenze dei manager aziendali.

La definizione originale di Dresner è la seguente: “Business Intelligence describes theenterprise’s ability to access and explore information, often contained in a Data

31

Warehouse, and to analyze that information to develop insights and understanding,which leads to improved and informed decision making. BI tools includes: ad hocquery, report writing, decision support systems (DDSs), executive information systems(EISs) and, often, techniques such as statistical analysis and on line analyticalprocessing (OLAP)”5.

Questa prima definizione mostra già quanto sia ampio il concetto di BusinessIntelligence, incorporando molti strumenti e funzionalità diverse.

Infatti, la Business Intelligence assume significati diversi, a seconda del punto di vistadi chi la definisce. Essa può indicare:

• i processi aziendali di creazione delle informazioni, oppure gli elementitecnologici (hardware e software) che sono utilizzati per tali processi;

• l'insieme stesso delle informazioni che il management utilizza per intraprenderele proprie azioni;

• un'architettura di applicazioni di supporto alle decisioni;

Esistono inoltre numerose definizioni fornite dai vendor di strumenti di BI, quasisempre influenzate dalla volontà dei produttori di evidenziare gli aspetti positivi deipropri software [16].

Un'altra definizione è la seguente, che pone l'accento sull'aspetto fondamentale diestrazione della conoscenza dai dati:

“La business intelligence è il processo, e la tecnologia alla base, che permette latrasformazione di dati in informazioni, informazioni in conoscenza e conoscenza inpiani che orientano il processo decisionale ai vari livelli dell’organizzazione.”6

La Business Intelligence rappresenta, quindi, lo strumento chiave dell’evoluzione versouna gestione sempre più efficace e strategica delle informazioni.

2.3.2 Componenti dei sistemi di Business Intelligence

Come visto nel paragrafo precedente, la definizione di Business Intelligence è moltoampia, e, a seconda dei punti di vista, può includere una moltitudine di sistemi efunzionalità. Nel seguito di questo paragrafo verranno presentate le componentifondamentali dei sistemi di BI che riguardano da vicino il progetto TORCIA, che verràintrodotto nel prossimo capitolo.

Per primi, verranno presentati i sistemi OLAP e i Data Warehouse, che costituiscono ilpunto di partenza per tutte le analisi che rientrano nella Business Intelligence.Successivamente si parlerà del Data Mining, processo di elaborazione che poggia sui

5 http://www.gartner.com6 http://www.bistrategy.it/app_bi_origini_definizione.aspx

32

dati immagazzinati nel Data Warehouse, utilizzato all'interno di TORCIA e anche inaltre applicazioni create per il supporto alla gestione delle emergenze.

2.3.2.1 I sistemi OLAP e i Data Warehouse

Come già accennato nel paragrafo precedente, il punto di partenza per le attivitàanalitiche che fanno parte della Business Intelligence è avere una base di dati ricca diinformazioni.

Le basi di dati transazionali, adoperate dalla organizzazioni per accumulare dati relativialla loro gestione operativa, utilizzano una tecnologia finalizzata prevalentemente allagestione affidabile ed efficiente di dati “in linea”. Questi sistemi, che prendono il nomedi On Line Transactional Processing (OLTP), non si sono però rivelati altrettanto validiper supportare l'analisi dei dati. Per questo motivo, sono stati sviluppati dei sistemidedicati in maniera esclusiva all'elaborazione e all'analisi dei dati, chiamati On LineAnalytical Processing (OLAP). Elemento principale dell'architettura OLAP è unaparticolare base di dati chiamata Data Warehouse (magazzino di dati), nella qualevengono raccolte tutte le informazioni che, opportunamente analizzate, possono fornireun supporto alle decisioni. La diffusione di interfacce di OLAP sempre più semplici,inoltre, ha fatto sì che l'utilizzo di tali strumenti non fosse più riservato solo a deglispecialisti (gli “analisti”), ma disponibile ad una più ampia platea di utenti, rendendocosì più immediata ed efficace l'attività decisionale, senza la necessità di passareattraverso degli intermediari.

Gli ambienti OLTP e OLAP convivono all'interno delle architetture definite aseparazione degli ambienti: in questo contesto il sistema OLTP funge da sorgente diinformazioni per quello OLAP.

Caratteristiche di un Data warehouse

I Data warehouse possiedono alcune caratteristiche peculiari, che in parte le distinguonodalle basi di dati usate nei sistemi OLTP:

• Integrazione: il Data warehouse contiene dati provenienti da diverse sorgentiinformative, sia interne all'organizzazione (i database operazionali) che esterne,fornendo così un punto di accesso unificato per i dati;

• Gestione separata: il Data warehouse viene sempre mantenuto fisicamenteseparato dalle sorgenti informative, in quanto il mantenimento dei dati storici,l'aggregazione e l'analisi richiedono organizzazioni speciali e metodi di accessospecifici;

• Informazioni a carattere storico/temporale: a differenza delle basi di datioperazionali, il Data warehouse non contiene solo il valore corrente delleinformazioni, ma contiene una serie di valori lungo un certo arco temporale,

33

permettendo l'osservazione dell'evoluzione storica delle informazioni;

• Aggregazione: i dati sono memorizzati in forma aggregata, rispetto adopportune coordinate, per effettuare stime e valutazioni;

• Non-volatilità: il Data warhouse contiene sono un'immagine rielaborata dei dati;i dati originali sono contenuti negli archivi;

• Fuori linea: i meccanismi di importazione dei dati sono normalmente di tipoasincrono e periodico, in modo da non penalizzare le prestazioni delle sorgentidi dati, specie se si tratta di sistemi OLTP con prestazioni critiche. In tal caso, ilDW non contiene dati perfettamente aggiornati, ma un disallineamentocontrollato dei dati è in genere ritenuto attendibile per molte applicazioni dianalisi.

Alimentazione del Data Warehouse

Questo livello è formato da processi che seguono il ciclo denominato ETL (Extract,Transform, Load). Le attività di base svolte all'interno di questo ciclo sono le seguenti:

• Estrazione: selezione ed estrazione delle informazioni dalle sorgenti;

• Pulizia dei dati: questa operazione viene applicata ai dati estratti dalle sorgentiinformative prima del loro caricamento nel Data warehouse e consiste nellaverifica della correttezza dei dati, ricercando errori, conflitti e incompletezze;

• Trasformazione: questo processo si occupa di riconciliare le eterogeneitàpresenti nelle sorgenti informative, predisponendo così i dati all'uso operativo;

• Caricamento: il caricamento dei dati nel Data Warehouse può essere effettuatoin due modi:

◦ Acquisizione completa: viene acquisito periodicamente l'interocontenuto del Data Warehouse. Questa modalità viene utilizzatasolo per applicazioni caratterizzate da un numero limitato di dati;

◦ Allineamento incrementale dei dati: vengono propagate al DataWarehouse le modifiche effettuate sulle sorgenti dei dati. A suavolta, questo metodo può essere realizzato tramite due tecniche.La prima, detta invio dei dati (data shipping), prevede l'uso ditrigger nelle tabelle sorgenti dei database transazionali, mentre laseconda, chiamata invio delle transazioni (transaction shipping),monitora il log dei database transazionali propagando lemodifiche al Data warehuse.

Il modello multidimensionale

I dati presenti in un Data warehouse vengono presentati all'utente tramite una

34

rappresentazione di alto livello che ne favorisce l'analisi. Questa rappresentazione fariferimento ad un particolare modello, noto come modello multidimensionale. Talemodello, si basa su tre concetti fondamentali:

• Fatto: concetto della realtà di interesse sul quale centrare l'analisi;

• Misura: proprietà specifica del caso da analizzare;

• Dimensione: descrive una prospettiva lungo la quale effettuare l'analisi; i valoripossibili per una dimensione sono detti membri.

Le dimensioni, a loro volta, sono organizzate in livelli gerarchici. Una tipica gerarchiaper la dimensione “tempo” è, ad esempio, giorno → mese → trimestre → anno.

Una volta fissate tutte le dimensioni di un fatto e scelto un livello di aggregazione perciascuna di esse, è possibile definire una istanza di un fatto come insieme dei valori diciascuna misura del fatto, assegnata ad ogni combinazione valida di membri dei livelliselezionati.

Per rappresentare graficamente le istanze dei fatti si fa generalmente uso di cubimultidimensionali, costituiti da elementi atomici, le celle. Un esempio di cubomultidimensionale, riferito alle vendite di un negozio, è mostrato in figura 2.2.

Ciascuna dimensione del cubo corrisponde ad una dimensione del fatto a una certolivello di aggregazione, mentre le celle del cubo contengono le istanze del fatto. L'interoData warehouse è logicamente costituito da un insieme di cubi chiamati data mart,ciascuno dei quali rappresenta un sottoinsieme logico/fisico dell'intero Data warehouse.

Per il modello multidimensionale sono state definite alcune operazioni di analisifondamentali che si applicano ai cubi, e che restituiscono nuovi cubi, nonnecessariamente con lo stesso numero di dimensioni.

Verranno ora esposte le operazioni più frequenti.

Roll-up

Questa operazione consente di ottenere dati aggregati secondo una o più dimensioni delcubo, risalendo la gerarchia di aggregazione. Una variante di questa operazione consistenell'eliminare una delle dimensioni del cubo aggregando i dati considerando per ladimensione eliminata una sorta di valore massimo, denominato “all”. L'aggregazioneviene effettuata tramite una funzione opportuna, tipicamente la somma, ma ne sonopossibili altre (ad esempio la media pesata).

35

Figura 2.2: Esempio di cubo multidimensionale7

Drill-down

Il drill-down è l'operazione inversa del roll-up. Consente di disaggregare i dati,passando da un livello di dettaglio più alto ad uno più basso, scendendo nella gerarchiadi aggregazione di una o più dimensioni. Il livello di dettaglio massimo che si puòraggiungere è quello del livello di granularità minima minima dei dati presenti nel DataWarehouse. In maniera analoga al roll-up, il drill-down può consistere nell'aggiunta diuna dimensione ad un cubo.

Slice & Dice

L'operazione di slice & dice permette di selezionare una parte del cubomultidimensionale di interesse per l'analisi. In particolare, lo “slice” consiste nelselezionare una fetta del cubo mediante restrizioni su una delle dimensioni, mentre il“dice” estrae un cubo più piccolo, tramite restrizioni su due o più dimensioni. La figuraseguente esemplifica queste due operazioni:

7 http://caccio.blogdns.net/archives/101

36

Figura 2.3: Schematizzazione delle operazioni di Slice & Dice

Pivoting

Questa operazione re-orienta il cubo, senza modificarlo, permettendo di vedereagevolmente tutte le sue facce.

Tecnologia dei sistemi OLAP

Le tecnologie dei sistemi OLAP vengono classificate secondo le strutture utilizzate. Sidistinguono tre soluzioni:

• Relational OLAP (ROLAP): utilizza la tecnologia delle basi di dati relazionali,opportunamente adattata ed estesa, organizzando i dati in modo da dare una vistamultidimensionale;

• Multidimensional OLAP (MOLAP): i dati vengono memorizzati direttamente informa multidimensionale, attraverso speciali strutture dati;

• Hybrid OLAP (HOLAP): è una soluzione ibrida; si tratta di sistemi ROLAP chepermettono la memorizzazione di alcuni data mart in speciali strutture MOLAP.

Nella tecnologia ROLAP, la rappresentazione multidimensionale viene implementatacon una struttura relazionale detta schema dimensionale o schema a stella (starschema). In questo tipo di schema sono presenti una tabella principale, la tabella deifatti, che memorizza le istanze di un fatto, e varie tabelle ausiliarie chiamate tabelledimensione che, come suggerisce il nome, rappresentano le dimensioni da considerareper le analisi. La figura 2.4 contiene un esempio di schema a stella:8

8 http://www.business-intelligence.org

37

Figura 2.4: Esempio di schema a stella

La tabella dei fatti, presente in forma normalizzata, ha una chiave composta da attributiche sono riferimenti alle chiavi delle tabelle dimensione, più altri attributi, solitamentenumerici, che rappresentano le misure del fatto. Le tabelle dimensione, generalmentenon normalizzate, hanno una chiave semplice, più altri attributi che rappresentano ilivelli di aggregazione o delle proprietà della misura stessa. Esse sono in genere moltopiù piccole della tabella dei fatti, anche si diversi ordini di grandezza.

Uno schema derivato dallo schema a stella è lo schema a fiocco di neve, che si ottienedal primo normalizzando le tabelle dimensione. Questa soluzione consente di ottenereun risparmio di spazio, a scapito però dell'efficienza, in quanto sono necessarie piùoperazioni di join rispetto allo schema a stella per ricostruire le informazioni richieste.

2.3.2.2 Data Mining

Data Mining è il processo di estrazione di conoscenza da banche dati di grandidimensioni tramite l'applicazione di algoritmi che individuano le associazioni"nascoste" tra le informazioni e le rendono visibili. In altre parole, col nome DataMining si intende l'applicazione di una o più tecniche che consentono l'esplorazione digrandi quantità di dati, con l'obiettivo di individuare le informazioni più significative edi renderle disponibili e direttamente utilizzabili nell'ambito del decision making.9

9 www.cineca.it/sites/default/files/DataM.pdf

38

L'estrazione di conoscenza (informazioni significative) avviene tramite l'individuazionedi associazioni, o "patterns", o sequenze ripetute, o regolarità, nascoste nei dati.

Problemi di data mining

Esistono varie tipologie di problemi di Data mining, ciascuna delle quali possiede dellecaratteristiche specifiche che differenziano le une dalle altre. Tuttavia, negli ultimi anni,sono stati riconosciuti alcuni problemi di struttura ricorrente, per i quali sono statidefiniti e realizzati algoritmi specifici.

Di seguito, verranno descritti alcuni di questi problemi [3].

Regole di associazione

Le regole di associazione si applicano a dati descritti mediante una tabella relazionale,partizionata tramite una clausola di raggruppamento. L'esempio classico è una tabellache descrive gli acquisti di un grande magazzino, raggruppati per transizioni d'acquisto.

Una regola di associazione è costituita da una premessa e da una conseguenza, ed ha laforma premessa → conseguenza. Premesse e conseguenze possono essere valori oinsiemi di valori presenti nella tabella. Ad esempio, la regola: sci → bastoncini indicache l'acquisto di sci (premessa) è spesso accompagnato dell'acquisto di bastoncini(conseguenza).

Le regole di associazione si definiscono utilizzando la probabilità. In particolare, siusano due misure:

• il supporto: è la probabilità che in una transazione siano presenti sia lapremessa sia la conseguenza;

• la confidenza: è la probabilità che in una transazione in cui è presente laconseguenza di una regola sia presente anche la premessa.

Il supporto misura quindi l'importanza di una regola, ovvero quanto spesso premessa econseguenza sono presenti insieme in tuple della tabella; la confidenza invece, nemisura l'affidabilità, cioè tra tutte le tuple della tabella in cui è presente la premessa,quanto spesso è presente anche la conseguenza. Il problema di Data mining relativo allascoperta delle regole di associazione, può quindi essere enunciato nel modo seguente:trovare tutte le regole di associazione con supporto e confidenza superiori a valoriprefissati.

Una variante del problema è quello della ricerca di pattern sequenziali, che consistenello studio dell'andamento temporale di un certo evento, al fine di trovare due eventiche accadono in sequenza. Un pattern sequenziale che viene riscontrato frequentemente,ad esempio, è l'acquisto del lettore di DVD poco dopo l'acquisto del televisore.

Il campo in cui più comunemente vengono applicate le regole di associazione e i pattern

39

sequenziali è la Market Basket Analysis, che ha lo scopo di identificare le relazioniesistenti tra un vasto numero di prodotti acquistati da differenti consumatori.Appartengono a questa categoria di analisi gli esempi esposti in precedenza.

Ci sono però anche altri ambiti di utilizzo per queste tecniche, tra cui la medicina: èpossibile, ad esempio, dare indicazioni su quali resistenze antibiotiche sonocontemporaneamente presenti in un antibiogramma, oppure scoprire che il diabete puòportare a una forte diminuzione della vista dopo dieci anni dalla sua insorgenza.

Classificazione

La classificazione mira alla catalogazione di un fenomeno in un insieme di classipredefinite. Il punto di partenza è un dataset contenente un certo numero di osservazioni(sample) di quel fenomeno. L'algoritmo che svolge la classificazione è dettoclassificatore. Esso viene costruito automaticamente partendo da un insieme di dati diprova (detto training set) costituito da un insieme di fenomeni già classificati; viene poiapplicato per la classificazione di fenomeni generici.

I classificatori si presentano spesso come alberi di decisione. Ai nodi di questi alberi siassociano dei predicati che consentono di prendere decisioni sulla base dei valoripresenti nel record di osservazioni elementari che rappresenta il fenomeno.

Quando i fenomeni sono descritti da un gran numero di attributi i classificatori sioccupano inoltre di determinare quali sono quelli significativi, separandoli da quelliirrilevanti.

Anche il Motore Semantico, uno dei componenti del sistema TORCIA, fa uso di unclassificatore. Se ne parlerà diffusamente nel prossimo capitolo nel paragrafo 3.2.

Clustering

L'obiettivo del clusering è quello di suddividere un insieme di fenomeni osservati ingruppi omogenei, detti cluster, in modo che i fenomeni dello stesso gruppo presentinoun comportamento simile rispetto ad alcuni attributi di riferimento. A differenza delproblema di classificazione, in questo caso si assume di non avere nessuna conoscenzapregressa sulle possibili aggregazioni. I cluster ottenuti possono essere sovrapposti eorganizzati gerarchicamente.

Gli algoritmi di clustering possono essere utilizzati in diverse applicazioni, tra cui:

• individuazione di popolazioni omogenee di clienti in basi di dati di marketing;

• valutazione di esperimenti clinici;

• in genetica, per l'organizzazione dei geni in gruppi (cluster) con simili pattern diespressione (geni coespressi);

• studio dei terremoti, identificando le zone a rischio tramite clustering degli

40

epicentri rilevati nei precedenti episodi;

• come fase preliminare di una successiva attività di classificazione, per avere unsupporto all'individuazione delle classi di riferimento.

Text Mining

Il Text Mining consiste nell'applicazione di tecniche di Data Mining a testi nonstrutturati (agenzie stampa, pagine web, e-mail, ecc.) e più in generale a qualsiasi corpusdi documenti, allo scopo di10:

• individuare i principali gruppi tematici

• classificare i documenti in categorie predefinite

• scoprire associazioni nascoste (legami tra argomenti, o tra autori, trendtemporali, ...)

• estrarre informazioni specifiche (es: nomi di geni, nomi di aziende, ...)

• addestrare motori di ricerca

• estrarre concetti per la creazione di ontologie (ontology learning).

Il processo di Text Mining solitamente si struttura in tre fasi:

1. Scelta e preparazione dei dati

2. Analisi dei dati

3. Analisi dei risultati

La preparazione di dati consiste nell'effettuare un'analisi lessicale del testo,comprendente due aspetti:

• analisi morfo-sintattica per eliminare le ambiguità dei termini,

• analisi semantica per trovare sinonimi, espandere acronimi, raggruppare variantigrafiche (come “visto” e “veduto”) ed estrarre espressioni composte (ad esempio“carta di credito”).

La seconda fase consiste nell'applicare un algoritmo di Data Mining ai dati cosìpreparati, scelto in base all'obiettivo da raggiungere. Esso è generalmente un algoritmodi clustering nel caso si voglia effettuare un raggruppamento tematico, che consistenell'organizzazione dei documenti in gruppi tematici, fornendo una panoramica deicontenuti e permettendo l'individuazione di nuovi argomenti e di relazioni tra areetematiche.

La terza e ultima fase consiste nel calcolo di misure di efficacia e/o nell'interpretazionedei risultati ottenuti, aiutandosi con mappe, istogrammi o tabelle rappresentanti i

10 http://www.cineca.it/it/content/text-mining

41

risultati dell'analisi.

Il Text Mining viene frequentemente applicato in diversi settori, tra cui marketing,sicurezza e il monitoraggio dei social media.

2.4 Emergency Situation Awareness – Automated WebText Mining (ESA- AWTM)

A conclusione del capitolo, si vuole presentare un'applicazione di successo delletecniche di Business Intelligence a supporto della gestione delle situazioni diemergenza: l'Emergency Situation Awareness – Automated Web Text Mining.

ESA-AWTM è un sistema di data mining creato per dare un supporto decisionale aicentri di coordinamento crisi presenti in tutti i centri urbani dell'Australia. I dativengono prelevati dal social network Twitter e dopo essere stati collezionati, revisionati,aggregati ed organizzati, vengono analizzati per trovare dati specifici riguardanti eventiche possono avere impatto sulla sicurezza dei cittadini.

Il problema principale nella costruzione del sistema è convertire il grande flusso dimessaggi in informazioni utili, in maniera veloce, pratica ed efficiente. Le funzioni,quindi, implementate includono:

• sintesi e indicizzazione dei messaggi: creazione tramite motori esterni di clusterdi tweet che parlano del medesimo argomento;

• ricerca di incidenti: il sistema esamina le parole che sono contenute nei tweet eusa dati storici per costruire un modello statistico per la ripetizione di termini;

• classificazione e revisione dei tweet importanti: sviluppo di un sistema statisticoche permetta la classificazione di tweet in base all'interesse che vienedeterminato da fattori quali la ricondivisione o la presenza di keyword ad altosignificato semantico;

• identificazione, tracciamento e gestione dei problemi: algoritmo che si occupa diunire, dividere o cancellare cluster con contenuto simile lungo medesimi architemporali,

• analisi forense: allarmi memorizzati in un database storico per analisi future.

L'output di ESA-AWTM permette la creazione di una mappa che consente diposizionare tutti i tweet importanti e indicare quali sono le zone di possibili incidenti.Vengono indicati anche altri dati statistici come il volume dei tweet catturati.

Durante il periodo di prova di questo sistema, durato nove mesi, sono state gestite inmodo più efficace dodici importanti situazioni di emergenza in diverse città australiane[5].

42

Capitolo 3

Il progetto TORCIA: obiettivi e architettura tecnologica

In questo capitolo verrà presentato il progetto TORCIA, un sistema che fa uso delletecnologie del Web 2.0 per fornire un supporto, sia agli organi competenti che aicittadini, per la gestione delle situazioni di emergenza. Tale sistema costituisce ilcontesto in cui si inserisce questo lavoro di tesi.

La sezione 3.1 introduce il sistema TORCIA, presentando i partner del progetto, la suaarchitettura, gli obiettivi e le attività principali.

La sezione 3.2 descrive il Motore Semantico, componente che può essere considerato ilcuore del sistema.

La sezione 3.3 si occupa del Database, un componente fondamentale su cui siappoggiano sia il Motore Semantico che il Torcia Monitor, che verrà introdotto nelcapitolo successivo.

La sezione 3.4, infine, fornisce una collocazione all'interno di TORCIA dello strumentodi Business Intelligence sviluppato nell'ambito di questa tesi.

3.1 Il progetto TORCIA

Il progetto TORCIA – PiaTtafORma di gestione CollaborativA delle emergenze- è unprogetto finanziato da Regione Lombardia e ha come obiettivo quello di utilizzare letecnologie del Web 2.0 a supporto dei processi di pianificazione e di controllo nella

43

gestione delle emergenze, garantendo la resilienza nelle infrastrutture di trasporto. Ilteam di progetto mira a definire un sistema integrato che possa utilizzare l'informazionesociale proveniente dai cittadini, informazione che viene organizzata e opportunamenteinterpretata, per poi essere fornita a supporto di enti e organizzazioni che si occupano digestione delle emergenze.

L'aspetto innovativo del progetto sta nell'utilizzo dei social network in modo completo,cioè sia per acquisire e interpretare informazioni in fase di emergenza, sia per fornirlealle autorità componenti. In tal modo gli utenti del Web 2.0 diventano protagonisti nelfornire, mediante i social network, informazioni georeferenziate e dati utili per lagestione delle emergenze. Il progetto intende sfruttare al meglio queste informazionicreando un'infrastruttura che possa raccoglierle, interpretarle e opportunamentecondividerle. Tale infrastruttura di elaborazione e basata su piattaforme cloudgeograficamente distribuite e collegate tra di loro mediante una rete ottica ad elevatacapacità.

3.1.1 I partner del progetto

Alcatel -Lucent

Alcatel-Lucent (ALU) è il leader del progetto. Grazie alle consolidate strutture aziendalidi cui dispone e in virtù della sua storia e dimensione, riveste il ruolo di coordinatoreamministrativo del progetto. Dal punto di vista tecnico, ALU fornisce la rete otticabackbone che collega i diversi server. Fornisce inoltre un sistema di messaggisticainnovativo per informare le autorità e i cittadini del pericolo imminente in corso: ilframework UMB (Universal Message Broadcaster).

ACT Solutions

ACT Solutions è un'azienda specializzata nella fornitura di soluzioni basate su modellimatematici per il controllo di processi e il supporto alle decisioni. Avvalendosi della suaconsolidata esperienza in ambito di Ricerca Operativa, ACT Solutions è responsabiledella creazione e della messa a punto degli algoritmi per la rilevazione dell'emergenzapartendo dal monitoraggio dei dati raccolti.

Beta 80 Group

Beta 80 Group ha una consolidata esperienza nello sviluppo di soluzioni di cruscotti dimonitoraggio, Business Intelligence e integrazione di applicazioni. E' il leader in Italianella realizzazione di Centrali Operative soprattutto in alcuni ambiti come Sanità,Protezione Civile e Vigili del Fuoco. In virtù delle sue competenze e della suaprecedente esperienza in progetti regionali in collaborazione con altri Enti, Beta80fornisce il cruscotto di monitoraggio di TORCIA e il relativo applicativo mobile, ed èinoltre un partner fondamentale per tutta l'integrazione del progetto.

44

Vidiemme Services

Vidiemme Services è un'azienda che opera nel settore della cartografia e dei GIS(Geographical Information Systems). Le sue competenze specifiche sono necessarie nelprogetto, visto l'importante legame con il territorio dello strumento prodotto daTORCIA e la necessità di un supporto cartografico.

Dipartimento di Elettronica, Informazione e Bioingegneria del Politecnico diMilano

Il coordinamento scientifico del progetto è affidato al Politecnico di Milano, che hapartecipato e partecipa a numerosi progetti di ricerca in ambito regionale,nazionale edeuropeo, in collaborazione con imprese di tutte le dimensioni. I ricercatori delDipartimento di Elettronica, Informazione e Bioingegneria (DEIB), uno dei maggioridipartimenti universitari in Europa per dimensioni e qualità della ricerca, lavorano daanni su temi di qualità dei dati e analisi semantica del Web 2.0. Per questi motivi, ilDEIB ha il compito di realizzare il motore semantico Web 2.0, realizzando una strutturaWeb che possa essere facilmente letta dal sistema.

Fondazione Politecnico di Milano

La Fondazione Politecnico di Milano (FPM), voluta dal Politecnico e da altre aziendeper favorire le collaborazioni dei dipartimenti universitari con le aziende e la pubblicaamministrazione, vanta una consolidata esperienza in termini di disseminazione,gestione delle relazioni con i media e gli stakeholder e validazione dei risultati. Fortedella sua esperienza nel campo, FPM supporta Alcatel-Lucent nel coordinamento e nellagestione del progetto.

3.1.2 Motivazioni e obiettivi

Uno degli aspetti più critici da affrontare durante gli eventi di crisi è la resilienza delleinfrastrutture di trasporto. Infatti, l'accadimento di un fenomeno di tipo catastrofico cheporta alla non agibilità di specifiche reti stradali, potrebbe generare tutta una serie diconseguenze negative sulle cose, le attività e l'ambiente del sistema socioeconomico eterritoriale della regione circostante. All'atto dell'avvenimento catastrofico, lavoraresulla resilienza può significare garantire la circolazione e lo scorrimento delle arterieconsiderate più strategiche nell'area considerata.

In ambito di Protezione Civile per conseguire questo risultato si opera sui Piani diEmergenza, all'interno dei quali sono indicate le operazioni da effettuare, come adesempio la modifica del senso di circolazione e lo sgombero da parte della polizia localedi determinate arterie per consentirne l'utilizzo ai soli mezzi di soccorso. L'attuazionedel piano tuttavia deve essere tempestiva, perciò occorre una comprensione immediatadi quello che sta accadendo e l'elaborazione tempestiva delle comunicazioni daeffettuare. L'obiettivo è quello di capire il prima possibile che si rientra nelle condizioni

45

che devono attivare il Piano di Emergenza e comunicare prontamente alla cittadinanzale azioni intraprese, finalizzate a mantenere le condizioni di sicurezza e di percorribilitàdell'infrastruttura stradale.

Il progetto sfrutta le tecnologie attualmente disponibili per:

1. facilitare le operazioni di raccolta dati sul territorio

2. comprendere ciò che si sta verificando

3. dare una comunicazione tempestiva di quanto sta accadendo a delle iniziative dacompiere

Questo è reso possibile dalla combinazione congiunta dei social network e deglistrumenti mobile. Moltissime persone sono attualmente “always-on”. Esse fornisconocommenti in tempo reale su quanto sta accadendo e spesso possono essere localizzate,dal momento che i dispositivi che utilizzano per condividere i propri pensieri sonodotati di GPS.

L'obiettivo del progetto TORCIA è quello di fornire un supporto alla gestione delleemergenze tramite la raccolta di informazioni sul territorio e sulle infrastrutture ditrasporto, integrata dai contenuti pubblicati dai cittadini su siti Web 2.0. Il sistemastrutturerà poi questi dati in modo da renderli disponibili ai diversi attori coinvolti nellagestione dell'intervento, inclusi gli individui stessi colpiti dall'emergenza.L'infrastruttura tecnologica di TORCIA è stata progettata in modo da stimolare laproduzione di informazione ed erogare servizi informativi secondo un approccio diCrowndsourcing.

Dato che il sistema deve essere operativo durante le situazioni di emergenza, laresilienza rappresenta un aspetto fondamentale, soprattutto per quanto riguardal'infrastruttura di elaborazione a supporto del sistema. Per questo motivo, l'infrastrutturaè basata su piattaforme cloud geograficamente distribuite e collegate tra loro tramite unarete ottica resiliente ad alta capacità.

3.1.3 Le attività core del sistema

Le attività core del progetto si occupano principalmente dello sviluppo di un sistemache sia in grado di monitorare, interpretare e comunicare le informazioni provenienti daisocial network.

Monitoraggio

Il monitoraggio deve avvenire in tempo reale analizzando sia i dati provenienti daicanali tradizionali sia quelli raccolti tramite crawling sui social network, garantendo lapresenza di un cruscotto cartografico operativo.

46

Interpretazione

E' necessario interpretare immediatamente le informazioni relative a ciò che staaccadendo, in modo d avere indicazioni sull'impatto che questo avrà sull'infrastruttura ditrasporto locale e indicare le azioni da intraprendere per gestire l'evento critico.

Comunicazione

Dovranno essere fornite tutte le informazioni necessarie, sia a livello di istituzioni che alivello di cittadinanza, diffondendo i dati in ottica multicanale per poter rendereimmediate le iniziative che devono essere intraprese.

Al fine di rendere il sistema utilizzabile e funzionante anche in condizioni di maxi-emergenza ed eventi catastrofici, dovranno essere studiati metodi innovativi per rendereresiliente l'infrastruttura mediante cloud computing distribuito.

3.1.4 L'architettura core del sistema

In figura 3.1 è indicato uno schema ad alto livello dell'architettura del sistemaconsiderato.

Figura 3.1: Architettura del sistema torcia [15]

47

Input del sistema

Il sistema riceve in ingresso informazioni di natura diversa:

• Messaggi indiretti: comprendono tutti i messaggi non diretti alla centraleoperativa ma estratti da altre fonti, che normalmente non trattano informazionirelative alle emergenze. Rientrano in questa categoria tutti i messaggi estratti daisocial network Web-based che dovranno essere approfonditamente analizzati alfine di estrarne informazione strutturata.

• Messaggi diretti: comprendono tutti i messaggi indirizzati direttamente allacentrale operativa, inviati sia da fonti istituzionali che da persone private.Comprendono quindi tutte le chiamate agli operatori di emergenza e i messaggiinviati tramite applicazioni mobili apposite.

• Dati provenienti da dispositivi elettronici: si tratta di dati provenienti da sensorie telecamere, strumenti già installati e preposti al controllo del territorio. Questainformazione aggiuntiva viene utilizzata sia per permettere un'immediatalocalizzazione degli eventi, sia per valutarne la criticità.

L'analisi semantica

Il core del sistema racchiude tutte le operazioni volte all'analisi, la comprensione el'utilizzo delle informazioni giunte in input. Il Politecnico di Milano è responsabile dellosviluppo del motore di analisi che deve rispondere alle seguenti esigenze:

• Analisi semantica: viene effettuata dal Motore Semantico creato da LucaMuccignato e Federico Negri [14], il quale incorpora ed estende due strumenti:

▪ il tool di Classificazione, che permette la categorizzazione dei messaggiprelevati dai social media mediante un'ontologia creata specificamenteda Claudio Carcaci per la gestione delle emergenze [6]

▪ il tool di Entity Discovery, che sfrutta l'algoritmo di Giulia Cesana eAlfonso D'Ettorre, per rilevare le emergenze [8]

• Business Intelligence semantica: si occupa di individuare informazioni utili permigliorare l'efficienza del sistema e ridurre il rischio di future emergenze. Sibasa su tecniche di data mining semantico, permettendo l'individuazione dieventi.

• Crowdsourcing e analisi dei piani di emergenza: l'obiettivo è fornire soluzioniper la comunicazione tra le autorità competenti e l'aggiornamento collaborativodei piani di emergenza.

ACT Consulting si occuperà invece di sviluppare il motore di calcolo per la definizionedei percorsi e delle vie di fuga, minimizzando i tempi di percorrenza e la pericolosità dei

48

percorsi considerati.

Output del sistema

L'output del sistema dovrà essere utilizzato a supporto delle decisioni dai diversi entipreposti alla salvaguardia del cittadino. Esso permetterà una migliore comprensionedello scenario di emergenza, fornendo di conseguenza un valido aiuto per la definizionedelle azioni necessarie.

Il cruscotto di monitoraggio consente infatti di geolocalizzare le richieste di intervento,leggere tutte le informazioni associate alla segnalazione e visualizzarne leimmagini/fotografie.

Le funzionalità di output sfruttano l'UMB, sistema sviluppato da Alcatel-Lucent, chepermette l'invio di messaggi in broadcast attraverso le diverse piattaforme: socialnetwork, email, sms, allarmi, etc.

Destinatari del sistema

I destinatari dei messaggi generati dal sistema TORCIA appartengono a categoriediverse:

• Autorità, quali il Prefetto, il Presidente della Provincia, il Sindaco, etc.

• Squadre di emergenza, quali Vigili del Fuoco, Protezione Civile, ProntoSoccorso

• Cittadini

I messaggi di output del sistema vengono personalizzati in base alla categoria a cui sonorivolti: ad esempio i cittadini riceveranno solo informazioni relative all'evento in atto.

3.1.5 Contesto specifico di analisi del progetto

Scelta della sorgente

I social network hanno uno struttura di base comune ma, al tempo stesso, presentanomolti aspetti che li differenziano in maniera notevole gli uni dagli altri: per esempio lefunzionalità implementate, i tipi di informazioni che veicolano, gli aspetti tecnologici ele impostazioni di privacy. Le considerazioni su questi fattori hanno portato alla sceltadella sorgente [15]:

1. deve essere utilizzata da un gran numero di persone, con un'elevata conoscenzadel mezzo che stanno utilizzando;

2. deve possedere impostazioni di privacy ridotte, per consentire l'acquisizione delmaggior numero possibile di messaggi;

3. deve possedere un'interfaccia mediante la quale eseguire l'acquisizione;

49

4. deve permettere l'inserimento e la lettura di messaggi istantanea, senza unamoderazione a priori;

5. deve poter veicolare un'informazione piuttosto concisa;

6. deve permettere la geolocalizzazione del messaggio;

7. deve indicare in modo preciso la data e l'ora in cui un messaggio viene inserito;

8. deve possedere un meccanismo di ricondivisione per una maggior diffusionepossibile delle informazioni;

In base a queste considerazioni, la scelta è ricaduta sul social network Twitter.

Date le sue caratteristiche primarie, riesce a soddisfare tutti i punti precedentementeindicati. L'unica eccezione riguarda il geotagging (punto 6), che non è una funzionalitàobbligatoria per tutti i messaggi, ma è comunque impostabile opzionalmente dagliutenti.

Un'altra sorgente è l'applicativo mobile in corso di realizzazione da parte di Beta 80Group. Questa sorgente produce dei messaggi strutturati, in quanto sarà la app stessa aguidare l'utente nella creazione di un messaggio che sia il più semplice e significativopossibile.

I dati in input

La natura generale dell'informazione fornita dal social network Twitter e dall'app mobilein caso di emergenza può essere di due tipi:

• Estrinseca: è un tipo di informazione chiara e riferita al contesto, contenentedati precisi e puntuali, che non necessita quindi di manipolazioni (tipicamentesarà l'informazione proveniente dalla app mobile);

• Intrinseca: è un tipo di informazione che necessita di essere estratta einterpretata attraverso una serie di deduzioni che è possibile effettuare sullasintassi del messaggio (tipicamente quella proveniente da Twitter).

Va quindi considerato il fatto l'informazione sociale non può sempre essere dedotta eimmediatamente registrata, ma spesso tale operazione deve essere preceduta da una fasedi manipolazione. Inoltre, l'informazione intrinseca per sua natura non sempre puòessere dedotta e registrata, soprattutto da algoritmi informatici.

Per questi motivi, è stato deciso di sostituire le coordinate della geolocalizzazione deitweet, se presenti, con coordinate intrinseche della semantica del tweet stesso. Lecoordinate di un tweet diventano quindi quelle di un qualsiasi indirizzo presente neltesto di 140 caratteri disponibili (ad esempio: “Allagamento in via Golgi a Milano”).

L'informazione, poi, può essere:

50

• Completa: permette la registrazione di più dati, specifici ad un evento e quindimaggiormente efficaci per coloro che dovranno utilizzarli;

• Incompleta: questo tipo di informazione è comunque utile e interessante,soprattutto in caso in cui possa essere integrata o confrontata con quellaproveniente da altre segnalazioni.

Nonostante entrambi i tipi di informazioni siano utili, il sistema tratta preferenzialmentele informazioni complete rispetto a quelle incomplete, proprio perché sono quelle piùefficaci poi in fase operativa.

Scelta del contesto

Per poter effettuare una migliore analisi all'interno del progetto, è stata inizialmentescelta un'unica tipologia di evento.

L'evento deve produrre un certo volume di traffico in termini di messaggi e quindi devepotersi verificare con una elevata frequenza. Inoltre esso deve far sì che i messaggivengano prodotti non solo nella fase di emergenza, ma anche nelle fasi precedenti esuccessive. Le conseguenze dell'evento devono, poi, essere di molteplice natura inmodo da poter coinvolgere enti diversi e produrre un “chiacchiericcio” spontaneo suTwitter da parte dei cittadini.

Basandosi su queste considerazioni, Andrea Palla, tesista presso il Politecnico di Milanoe collaboratore del progetto, ha scelto come tipologia di evento di riferimento quelladelle alluvioni e allagamenti [15].

Ecco le motivazioni da lui fornite in merito a tale scelta:

• sono fenomeni che si possono verificare in ambito cittadino;

• sono fenomeni frequenti sull'intero territorio italiano: l'Italia dal 1980 al 2002 èstato il paese europeo con il più alto numero di morti e danni causati dallealluvioni;

• sono argomento di discussione frequente sui social media;

• giornali e organi di informazione se ne occupano pienamente, anche inprevisione di un'emergenza;

• cause, effetti, prevenzione e prevedibilità sono argomenti di discussione allaportata dei cittadini in quanto non richiedono una conoscenza specificadell'argomento.

51

3.2 Il Motore Semantico

Il Motore semantico, creato da Luca Muccignato e Federico Negri, è uno deicomponenti fondamentali del sistema TORCIA. La sua funzionalità è quella dianalizzare i messaggi provenienti dal Web e di riconoscere se l'informazione portata èrivelatrice di una potenziale emergenze imminente, in modo da trasmetter un segnale diallarme al resto del sistema e allertarne gli utilizzatori con anticipo.

Per semplicità, col termine “tweet” si farà riferimento sia ai messaggi strutturatiprovenienti dall'app mobile che ai tweet veri e propri, in quanto il loro formato è quasidel tutto identico. Nel caso si renda necessario, verrà specificato chiaramente a qualedelle due tipologie di messaggio ci si sta riferendo.

In questo paragrafo verranno presentate le caratteristiche salienti di questo componente,per una descrizione completa si rimanda all'elaborato di Luca Muccignato e FedericoNegri [14].

3.2.1 Funzionamento generale

Come indicato dai suoi creatori, l'obiettivo principale del Motore Semantico è quello diricevere e analizzare i messaggi provenienti dal Web per rilevare eventuali emergenze incorso o che stanno per verificarsi.

A questo scopo, il software utilizza tre moduli principali tra loro:

• Web Service

• Classificatore

• Entity Discovery

Queste tre componenti si appoggiano a un Database, creato dagli stessi autori, che ha ilcompito di conservare le informazioni (i tweet grezzi) e servire da struttura di appoggioper permettere una loro successiva rielaborazione.

Il Web Service riceve dei file, in formato XML prestabilito, contenenti i dati acquisiti daBeta80. Successivamente, questi dati verranno analizzati dal Classificatore che,mediante una prima valutazione semantica del testo salvato, assegnerà una o più Classia ogni nuovo tweet significativo, scelte tra le sette disponibili di:

1. Dove

2. Segnalazione

3. Conseguenze

4. Responsabilità

5. Viabilità

52

6. Warning

7. Post (Postemergenza)

Ognuna di queste corrisponde a una fase o a un attributo fondamentale legatoall'emergenza in corso e, nell'insieme, risultano ampiamente significative sia nella fasedi Emergenza in Corso che in fase di Emergenza Conclusa.

Le tipologie dei messaggi che rientrano in ciascuna Classe sono riportate nella tabella3.1.

Una volta che i tweet sono stati classificati, il programma di Enity Discovery, sempreutilizzando tecniche semantiche, analizza le informazioni raccolte e classificate in unlasso di tempo definito (al momento le ultime 24 ore). Il suo scopo è di ricercare dellecorrelazioni tra questi tweet e di controllare la presenza di parole chiave (d'ora in avantiKeyword), quali ad esempio “ALLAGAMENTI” o “NUBIFRAGIO”, legate ad areegeografiche italiane. Nel caso l'Entity Discovery trovi un riscontro, crea unaSegnalazione contenete tutti i tweet da cui si è generata, in un formato XML analogo aquello di ricezione. Il Web Service a questo punto la inoltrerà al Web Service di Beta80,da cui la segnalazione continuerà il suo iter all'interno del sistema TORCIA.

Oltre alla segnalazione di emergenze in corso, il Motore Semantico è in grado dirilevare l'arrivo di una potenziale emergenza, mediante l'algoritmo di ricerca delleAllerte all'interno dell'Entity Discovery.

Classe Tipologia dei messaggi contenuti

Dove Indicazione del luogo dell'evento

Segnalazione Segnalazione generica di un evento

Conseguenze Segnalazione relativa ai danni causati daun evento

Responsabilità Indicazione delle responsabilità di un datoevento

Viabilità Indicazione relativa alla modica dellaviabilità causata da un evento

Warning Segnalazione utile al fine di prevenireun'emergenza

Post Segnalazione post emergenza

Tabella 3.1: Tipologie dei messaggi contenuti nelle Classi

3.2.2 Architettura del Motore Semantico

53

L'architettura del sistema è costituita da due blocchi funzionali, uno dei quali a sua voltaraccoglie due processi di elaborazione che sono il core dell'intero Motore Semantico.

L'architettura del sistema, come mostrato nella figura 3.2 è quindi composta da:

• due Web Service per l'interfacciamento e l'integrazione con il Crawler di Beta80

• il Motore Semantico, a sua volta costituito da:

▪ il Classificatore, per la classificazione dei tweet

▪ Entity Discovery, per la rilevazione e segnalazione di allerte e/oemergenze

Figura 3.2 : Architettura del Motore Semantico

3.2.2.1 Il Web Service

I tweet provenienti dal Web vengono raccolti di Beta80 tramite il proprio Crawler, perpoi essere inviati al Motore Semantico del Politecnico. Questo interfacciamento èrealizzato utilizzando un Web Service di tipo REST, chiamato PUSH TWEET, cheaccetta in input un file XML contenente una lista di tutti i tweet raccolti in un certo arcotemporale. Il servizio inserisce automaticamente i tweet nel database del Politecnico.

Oltre a quello appena descritto è presente un altro Web Service, denominato PUSHLUOGHI, che, con gli stessi meccanismi, consente a Beta80 di inviare al Database delPolitecnico una lista di “Luoghi Notevoli”, ovvero quei punti geografici che hannoprecedenza rispetto agli altri nell'analisi semantica.

Il servizio Push Tweet

54

L'architettura del servizio Push Tweet è mostrata in figura 3.3.

Il servizio rimane sempre in ascolto per ricevere i dati in input, costituiti da un file XMLcontenente la lista dei tweet provenienti dal Crawler di Beta80, la cui struttura deverispettare il documento XSD in figura 3.4. L'invio dei tweet da parte di Beta80 avvienequando accade la prima delle seguenti situazioni:

• è passato un limite massimo di tempo dall'ultimo invio

• la finestra di tweet messi in coda dal Crawler è piena.

I valori di tempo massimo e dimensione della cosa sono stabiliti da Beta80, e non ènecessario siano conosciuti dal servizio, poiché esso è sempre in ascolto e pronto aricevere.

Figura 3.3: Architettura del servizio Push Tweet

Il servizio Push Tweet, una volta ricevuto il documento, lo apre, ne estrae ognielemento, ed effettua il caricamento della tabella Tweets del Database del Politecnico diMilano.

L'esito di ogni chiamata al servizio viene memorizzato nell'apposita tabella del Databasechiamata Log_caricamento. Oltre all'esito dell'operazione, vengono così memorizzateanche la data e l'indirizzo IP di chi ha fatto la richiesta.

55

Figura 3.4: Struttura XSD per la trasmissione dei Tweet

Il servizio Push Luoghi

L'architettura del servizio Push Luoghi è la medesima del servizio Push Tweet. Tuttavia,per questo servizio i dati possono provenire sia da Beta80 che dai cartografici. Questiultimi sono infatti i più interessati e indicati a riempire il Database con nuovi luoghi egeolocalizzazioni specifiche, per rendere il più semplice ed efficiente possibile il lorocompito di creazione delle mappe.

Anche in questo caso le informazioni sono fornite al servizio per mezzo di undocumento XML in un formato prestabilito, che deve rispettare le regole del documentoXSD illustrato nella figura 3.5.

56

Figura 3.5: Struttura XSD per la trasmissione dei Luoghi Notevoli

La funzionalità di questo servizio è quella di permettere a Beta80 di inserire nelDatabase del Politecnico una lista di Luoghi Notevoli. Per ognuno dei luoghi dovràessere indicato il NOME, la LATITUDINE e la LONGITUDINE.

Il servizio riprende in generale la struttura di Push Tweet, soprattutto per quantoriguarda gli standard di codifica utilizzati e le possibili risposte.

Poiché la maggioranza dei campi dei due documenti è presente anche nel Database, sirimanda alla sezione 3.3 per una loro descrizione. La spiegazione integrale può esserereperita all'interno della tesi di Muccignato e Negri [14].

3.2.2.2 Il Classificatore

Si tratta di un algoritmo sintattico che esegue una categorizzazione dei messaggiprelevati dai social media mediante un'ontologia appositamente creata,

Tale procedura è stata ideata da Claudio Carcaci, e viene sfruttata dal Classificatorerealizzato per il sistema TORCIA [6].

Algoritmo di Carcaci

Secondo quanto detto dall'autore nel suo elaborato di tesi “l'applicativo realizzato hacome obiettivo quello di fornire un'analisi guidata totalmente dalla sintassi chepermetta di classificare messaggi, post, tweet provenienti dai social network”.

L'analisi sintattica proposta è un processo volto ad analizzare uno stream continuo ininput, in modo da determinarne la struttura grammaticale grazie all'utilizzo di una

57

grammatica formale e una conseguente costruzione di un albero sintattico.

Le entità di riferimento su cui l'algoritmo agisce sono:

• testi

• termini

• classi

La procedura cerca di delineare le loro interrelazioni, secondo lo schema riportato infigura 3.6:

Figura 3.6: Relazione tra le entità nell'algoritmo di classificazione

Nel dettaglio, abbiamo:

Relazione tra testi e termini. Viene espressa mediante una matrice di rilevanza nelquale vengono inseriti dei valori, corrispondenti all'importanza che un dato termine haall'interno del testo.

Relazione tra termini e classi. Questa relazione è definibile mediante i Metadata,preventivamente definiti, che identificano una classe. I Metadata sono i termini che,opportunamente correlati all'interno di un testo, permettono al Classificatore diassegnare una o più categorie alla frase in esame.

Relazione tra testi e classi. Si tratta di ciò che l'algoritmo deve riuscire a definire,l'obiettivo ultimo che si pone.

Sostanzialmente, quello che l'algoritmo intende fare è suddividere i messaggi in diversecategorie, le classi, sulla base di termini, metadata, presenti in essi.

58

Classi

Ai fini del progetto TORCIA sono state identificate 7 classi caratterizzanti. Esse sonostate costruite da Andrea Palla nel proprio lavoro di tesi e sono state prettamente pensateper il contesto di analisi utilizzato [15]. Le classi, con alcuni metadata caratterizzanti,sono le seguenti:

Categorie Metadata

Dove Città, Centro, Via, Metro, Nord, Spagna,Venezia, Posto, Località, Zona

Segnalazione Allagamenti, Pioggia, Esondato, Fiume,Acqua, Tempesta, Nubifragio

Conseguenze Morti, Salvo, Frana, Evacuata, Inghiottiti,Situazione, Danni, Crollata

Responsabilità Polizia, Magistrato, Pattuglia, Autopompa,Ministri, Comune, Tilt, Capo

Viabilità Libera, Percorribile, Ripulita, Sgombra,Chiusa, Traffico, Percorsi, Frana

Warning Fogne, Intasato, Argini, Pericoloso,Previsti, Rischio, Allerta, Flusso

Post Risarcimento, Lamentela, Soldi, Assegni,Fondi, Denunce, Interventi

Tabella 3.2 Composizione delle categorie pre modifica

Si rimanda alla consultazione della tesi di Andrea Palla per tutti i dettagli sullametodologia adottata per la costruzione di tali classi e per la definizione dei metadata adessi associati [15].

Le classi effettivamente utilizzate sono state modificate con l'introduzione di nuovimetadata al fine di ottimizzare i valori delle metriche adottate per la valutazione dellaqualità del classificatore.

Per la descrizione completa della metodologia utilizzata per il miglioramento delleclassi si rimanda alla tesi di Cesana e D'Ettorre [8]. L'elenco completo dei metadatarelativi alle sette classi, prima e dopo il processo di ottimizzazione, si può trovarenell'appendice A.

Modifiche al Tool di Classificazione

Il tool di classificazione e il suo relativo algoritmo sono stati creati da Caludio Carcacicon scopi diversi da quelli per cui viene impiegato all'interno di TORCIA. Si sono

59

pertanto rese necessarie alcune modifiche importanti, che ne hanno permesso unaspecifica personalizzazione [6].

I cambiamenti apportati al tool sono i seguenti:

1. Poiché Twitter fornisce la funzionalità di retweet, è stato fondamentale far sì cheil tool non li scartasse, ma che li classificasse come un qualunque messaggionormale. Questo aspetto è inoltre fondamentale per il funzionamento dell'EntityDiscovery, altro componente fondamentale del Motore Semantico.

2. Il tool, oltre ad eseguire la funzione di classificazione, effettua anche unfiltraggio dei messaggi. Il tool scarta i messaggi che non rientrano in nessunadelle categorie, ovvero i messaggi che non hanno al loro interno termini chedimostrano la loro appartenenza ad una specifica classe. Poiché i termini checaratterizzano la categoria “Dove” sono termini molto generici, spesso alcunimessaggi vengono classificati come appartenenti a tele classe, anche se noncoerenti con il contesto di applicazione del progetto. Per questo motivo,l'algoritmo originale è stato modificato in modo da scartare i messaggi che sonoassociati solamente alla categoria “Dove”. Nonostante possa apparire unamodifica drastica, i miglioramenti, visibili dalle metriche di valutazione del tool,hanno dimostrato la sua efficacia.

3.2.2.3 Entity Discovery

L'obiettivo principale dell'Entity Discovery e quello di scoprire ed estrarre, mediantel'analisi dei dati, delle entità rappresentanti eventi critici in atto. Il suo funzionamentoparte dallo studio di informazione sociale corrispondente ad un picco di parlato sullapiattaforma social Twitter e sui messaggi provenienti dagli utenti utilizzatoridell'applicativo mobile TORCIA, al fine di ricercare e scoprire l'avvenimento che lo haprodotto. In corrispondenza di una situazione di emergenza, si crea un “trend” nel mododi riferirsi all'evento critico, grazie al rimbalzo social continuo e preciso: le espressioniadottate sono composte in prevalenza da una Keyword, indicante la natura del fatto,associata al Luogo dell'accadimento.

L'aspetto interessante risiede nel fatto che la Keyword è spesso la medesima o, più ingenerale, è scelta all'interno di un insieme ristretto. Per tali motivi, la ricerca dell'Entityviene effettuata per mezzo di questa associazione di termini, individuando le Keywordpiù utilizzate e la parola indicante il Luogo dell'evento. Il risultato finale è un'entità deltipo Keyword + Luogo.

Una volta trovata l'Entity, essa viene utilizzata per aggregare i tweet riferiti all'evento,cioè quelli che hanno permesso la sua identificazione. In questo modo, viene dato unvalore aggiunto ai dati: gli operatori potranno consultare solamente i tweet di interesse,cioè quelli riferiti all'accadimento in atto, al fine di intervenire in maniera più celere

60

possibile; i cittadini, inoltre, vengono facilitati nella visione delle informazioni, poichéle potranno esaminare, filtrandole per occorrenza di evento. Per di più, avere leinformazioni aggregate per evento può essere utile alle autorità in fase di Mitigation, inquanto sarà possibile effettuare un'analisi più mirata su ciò che è accaduto durantel'emergenza e quindi dedurre gli eventuali miglioramenti che è necessario apportare alpiano di emergenza.

Dato che l'Entity identificata è formata da un'associazione di termini tra cui anche illuogo dell'evento critico, tale strumento può essere utilizzato, oltre che per lageolocalizzazione del fatto, anche per aumentare manualmente la specificità geografica,modificando, in tempo reale, i metadata componenti le classi. Ciò permette di avere unaclassificazione sempre più efficace e quindi di generare dati e informazionimaggiormente utili all'intervento delle autorità. In questo modo il Tool diClassificazione e di Entity Discovery interagiscono in maniera indiretta tra di loro,cooperando nell'analisi e nella generazione di informazione valida ed efficiente.

Ricerca del Luogo

Durante la ricerca delle emergenze e delle allerte, il tool di Entity Discovery utilizza duecomponenti: la tabella dei Luoghi Notevoli e il servizio Google Places API.

Il tool, come primo passo, consulta la tabella dei Luoghi Notevoli, che, come si vedrànella sezione 3.3, contiene nomi di luoghi con le relative coordinate di latitudine elongitudine. Nel caso ci sia un riscontro con uno degli elementi della tabella non sarànecessario effettuare richieste a servizi online: il nome del luogo verrà assunto comeLuogo e utilizzato nella costruzione dell'Entity, mentre le sue coordinate verrannoinserite negli appositi campi nell'XML della segnalazione e poi caricati nel Database.

La consultazione in primo luogo della tabella Luoghi Notevoli è dovuto al fatto che inquesta tabella è possibile inserire localizzazioni geografiche relative a fiumi, laghi e, ingenerale, a tutte quelle zone che potrebbero essere a rischio in caso di un'emergenzacome un alluvione che non possono essere geolocalizzate dal sistema Google Places inquanto non corrispondenti a delle Regioni o Città.

Nell'area milanese, ad esempio, in caso di forti piogge gli utenti di Twitter parlanospesso di “ESONDAZIONE SEVESO” in riferimento al fiume Seveso che scorre aNord della città. Senza l'utilizzo di questa tabella, il tool avrebbe rilevato la potenzialesegnalazione identificando però il Luogo “Seveso” come il comune di Seveso, localitàvicina a Milano, ma non collegata all'emergenza.

La tabella dei Luoghi Notevoli ha permesso invece di associare al termine “Seveso"delle coordinate ben precise relative all'Area del Niguarda, dove il fiume Seveso e solitoappunto esondare durante le forti piogge, provocando dei disagi e rischi per i cittadini.

Nel caso in cui la tabella dei Luoghi Notevoli non dia riscontri, il Tool di Entity

61

Discovery procede alla chiamata del servizio web esterno Google Places API. Google,mediante queste API, fornisce una serie di servizi per ottenere informazioni riguardantiluoghi, tramite richieste HTTP. In particolare, l'Entity Discovery sfrutta le API GooglePlaces Autocomplete, che, attraverso un'appropriata richiesta, permettono di stabilire seuna stringa corrisponda ad una città.

Quando viene intrapresa questa modalità di individuazione del Luogo è necessarioconsultare anche la tabella Blacklist, contenente alcuni termini comuni corrispondenti anomi di città e parole utilizzate oltre la norma. Il suo utilizzo si rende necessario proprioperché esistono molti termini comuni che corrispondono a nomi di città, che potrebberoessere considerati dal tool come luoghi, come ad esempio la parola “nomi” che è ancheun comune in provincia di Trento. Inoltre, è necessario evitare di richiedere troppevalutazioni di termini frequentemente utilizzati dalla gente, ma che si è sicuri non essereindicativi di un Luogo, per evitare di raggiungere la soglia massima di richieste.

L'utilizzo della blacklist non crea problemi nell'esecuzione dell'algoritmo. Infatti, è pocoprobabile che accada un evento nei luoghi identificati da termini in essa presenti, inquanto spesso si tratta di piccoli paesi o frazioni di città di dimensioni molto limitate eche su Twitter non sarebbero utilizzati come Luogo di riferimento, prediligendo invece,come minimo, il comune di cui fanno parte.

La tabella Blacklist contiene anche termini che non corrispondono a luoghi ma chespesso sono presenti nel testo dei tweet. L'esempio più emblematico viene dato dal“termine” http, il cui numero di occorrenze è molto elevato a causa della presenza dilink all'interno dei messaggi.

La tabella 3.3 contiene alcuni esempi di termini contenuti nella blacklist.

Blacklist

Termini comuni che corrispondono a nomidi città

Calcio, Amore, Vita, Ora, Tromba, Fallo,Piscina, Pero, Noci, Nomi, Pigna, Gallo,

Purgatorio

Termini spesso presenti all'interno deitweet

Http, Scuola, Nave, Serva, Cmq, Xkè, Con

Tabella 3.3: Esempi di termini contenuti nella blacklist

Allerte

Un'Allerta è una potenziale emergenza che non ha ancora raggiunto un livello di parlatotale da impensierire ed essere considerata un'emergenza vera e propria. Il suo formatodifferisce da quello di una normale segnalazione, per due aspetti:

62

• L'entità che viene salvata è del tipo “ALLERTA” + Luogo; questo poiché inquesta fase, non si sa ancora quale sarà (se ci sarà) la Keyword dominante, percui si raggruppano tutte sotto un più generico termine “ALLERTA”.

• Il campo “ACTIVE”, presente nella tabella delle Segnalazioni, viene settato a 2,in modo da distinguerle da segnalazioni sia vecchie (ACTIVE = 0) che nuove(ACTIVE = 1).

La ricerca delle Allerte non fa parte dei requisiti del progetto TORCIA, infatti esse nonvengono notificate alle altre parti del sistema, ma sono state inserite dagli autori delMotore Semantico come possibile sviluppo futuro del sistema.

Invio della segnalazione

Una volta che l'Entity Discovery ha individuato un'emergenza o un' allerta, provvede acreare una Segnalazione e a inviarla sotto forma di file XML, attivando il servizio diPUSH del Web Service di Beta80, in maniera analoga al servizio descritto nella sezione3.2.2.1.

La sua struttura è la seguente:

Figura 3.7: Struttura XSD per la trasmissione delle segnalazioni

63

Anche per questo documento, il significato dei campi verrà illustrato nel paragrafo 3.3che tratta il Database.

3.3 Database

Il Database riveste un ruolo di primaria importanza nel progetto TORCIA. Infatti, nonsolo è al centro dell'architettura del Motore Semantico, come illustrato nella figura 3.2,ma è anche alla base delle funzionalità di Business Intelligence del tool di monitoraggio.Infatti esso conserva tutti i dati raccolti ed elaborati durante le fasi di emergenza,permettendone così un'analisi ad emergenza conclusa.

Il Database, progettato da Luca Muccignato e Federico Negri [4], è un databaseMySQL, realizzato tenendo conto:

• dei documenti utilizzati da Carcaci, Cesana e D'Ettorre come input e output deiloro algoritmi [6][8];

• del formato dei documenti XML che vengono scambiati per l'interfacciamentocon Beta80.

La figura 3.8 mostra la struttura del Database:

Figura 3.8: Struttura del Database

Di seguito verranno descritte le tabelle che lo compongono.

Tweets

Gli attributi della tabella Tweets rispecchiano sostanzialmente i campi specificati nei

64

documenti XSD di interfacciamento tra Beta80 e Politecnico (figura 3.4).

• ID_TWEET: chiave primaria che identifica univocamente il messaggio.

• CD_CRAWLING_SOURCE : indica qual'è la sorgente dell'informazione.

• CD_MATCHING_DOMAIN : è il dominio di applicazione dell'informazione.Beta80 preleva dalla rete dei tweet che appartengono ad un determinatocontesto, o meglio che contengano determinate parole chiave che li fanno risalireal contesto in esame (es. ALLAGAMENTO, NUBIFRAGIO). Sarà poi compitodel Motore Semantico capire se il tweet in questione e effettivamente relativo adun'emergenza oppure no.

• CD_USER_NAME : identificativo dell'autore del messaggio.

• DS_TEXT : il testo del messaggio.

• DT_EXTRACTION : la data e l'ora in cui Beta80 ha prelevato il messaggiodalla rete.

• DT_REFERENCE : la data e l'ora di digitazione del messaggio.

• ID_EXTRACTED_INFO : è il numero che identifica il messaggio tra i varipartner di TORCIA. E' possibile che i singoli partner diano ai messaggi degli IDinterni univoci nel loro database, ma quando l'informazione deve circolare tratutti gli attori allora deve essere identificata mediante questo campo.

• IS_VALIDATED : indica se l'informazione che è stata ricevuta è validata omeno dall'ipotetico Operatore che lavora sul Cruscotto di Beta80; questo valorenon deve essere in alcun modo modificato dal Motore Semantico.

• VL_POSITION LATITUDE e VL_POSITION_LONGITUDE : sono lecoordinate date dalla geolocalizzazione del tweet. Questi sono campi opzionali,in quanto non tutti i tweet contengono una propria geolocalizzazione quandovengono postati. Per sopperire all'assenza di queste coordinate e stata introdottala funzionalità di Geolocalizzazione Semantica del Motore Semantico, illustratanella precedente sezione sull'Entity Discovery.

• DS_SEMANTIC_TOPICS : questo campo non viene mai inviato da Beta80, inquanto è compito del Motore Semantico calcolare le Classi da inserirvi, nelformato “classe1,classe2,...", come spiegato nel paragrafo 3.2.2.2 relativo alClassificatore. Nonostante questo però, il formato XML deve già contenerel'indicazione della sua esistenza, poiché l'XSD dei tweet è definito unico e fissoper ogni parte di progetto.

• ID_SEMANTIC_SIGNALING : contiene un intero che identifica lasegnalazione alla quale è stato allegato il messaggio; se il messaggio non è stato

65

allegato ad alcuna segnalazione, il campo assume il valore “null”.

Signals

Come per la tabella Tweets, anche i campi di questa tabella rispecchiano quelli deldocumento XSD relativo all'invio delle segnalazioni (figura 3.7).

• ID_SEMANTIC_SIGNALING : chiave primaria, identifica univocamente lasegnalazione.

• DS_TEXT : testo dell'Entity legata alla segnalazione.

• CD_MATCHING_DOMAIN : dominio dell'emergenza rilevato dall'EntityDiscovery (la Keyword).

• DT_CREATION : indica la data in cui la segnalazione e stata creata.

• CD_SIGNALING_STATUS : indica lo stato della segnalazione all'interno delsistema TORCIA; viene inizializzato da altre componenti del sistema e nonviene modificato o utilizzato dal Motore Semantico.

• DT_SIGNALING_STATUS : indica la data in cui la segnalazione è stataaggiornata l'ultima volta.

• VL_ACCURACY : campo che permette di inserire la precisione percentualedella segnalazione; viene inizializzato e utilizzato dal sistema TORCIA piùavanti, non viene modificato o utilizzato dal Motore Semantico.

• DS_SIGNALING_POSITION : indica il luogo in cui l'Entity Discovery harilevato l'emergenza.

• ACTIVE : descrive in ogni momento lo stato di un'emergenza rilevata dalsistema, e può assumere i tre valori seguenti:

▪ 0 : l'emergenza è terminata

▪ 1 : l'emergenza è attiva

▪ 2 : si tratta di un'allerta e non di un'emergenza vera e propria

• DT_LAST_EDIT : contiene la data dell'ultima volta in cui il Motore Semanticorileva che si è parlato su una delle sorgenti di quell'emergenza.

Dopo aver inviato la segnalazione, il valore del campo ID_SEMANTIC_SIGNALINGdi ogni tweet è resto negativo (es. da “25” a “-25”) in modo da non perdere lacorrelazione tra tweet ed emergenza (l'ID è semplicemente l'opposto), ma successiviriscontri della stessa Entity inviino nella notifica solo i tweet appena arrivati e non quelligià trasmessi.

Sorgenti

66

Questa tabella contiene i nomi delle sorgenti utilizzate dal sistema, assieme al peso conil quale conteggiare i loro messaggi. Per ora il sistema TORCIA si è avvalso unicamentedel social network Twitter, ma in futuro vi si aggiungeranno nuove sorgenti qualil'applicativo mobile in corso di sviluppo da parte di Beta80 e YouReporter.

Il peso è un numero decimale che rappresenta la rilevanza che hanno per il sistema imessaggi provenienti da una determinata sorgente. Il valore impostato per Twitter è0.01, mentre quello dell'applicativo mobile dovrà essere impostato ad un valore più alto,in quanto i suoi utenti saranno, almeno in teoria, persone interessate e attive, cheforniranno informazioni più precise e strutturate rispetto alla massa confusa dei tweet.

Al momento di prelevare le informazioni dal Database, l'Entity Discovery effettuaquindi una conversione dei pesi, semplicemente moltiplicando questo dato per 100, inmodo da ottenere un numero intero. In questo modo ogni tweet, il peso fisso basilare è0.01, conterà come un'unità di informazione, mentre ogni messaggio realizzato conl'applicativo verrà considerato come 10, 20 o anche 50 tweet, a seconda del valore chel'Operatore avrà dato al peso di questa fonte.

Questa tabella viene sincronizzata con i pesi stabiliti dall'Operatore che utilizza ilCruscotto di Beta80 che possono anche variare, quindi, in tempo reale per meglioadattarsi a una specifica emergenza.

Metainfo

La tabella Metainfo raccoglie le categorie per la classificazione e le parole chiaveassociate ad ognuna delle categoria, i Metadata. L'utilità e il contenuto di questa tabellariguardano il Classificatore (sezione 3.2.2.2).

Keywords e Blacklist

Queste due tabelle hanno la medesima struttura e contengono, rispettivamente:

• le parole che devono essere considerate per la rilevazione di eventualiemergenze (tabella Keyword)

• le parole che non devono essere considerate per la rilevazione di eventualiemergenze (tabella Blacklist)

Luoghi notevoli

La tabella luoghi notevoli è stata introdotta per dare una priorità di ricerca a determinatezone di interesse. Ogni luogo è identificato dal nome e dalle sue coordinate geografiche,ed inserito da Beta80 tramite il servizio Push Luoghi, introdotto nella sezione 3.2.2.1.

Log_caricamento

67

La tabella Log_caricamento costituisce, di fatto, un registro degli eventi per quandoBeta80 interroga il servizio Push Tweet. Viene salvato l'indirizzo IP da cui provengono imessaggi, la data, il numero di tweet salvati correttamente e l'esitodell'interfacciamento, sia esso positivo che negativo.

3.4 Introduzione allo strumento di Business Intelligence

Per svolgere il suo compito, il sistema TORCIA raccoglie grandi quantità di dati, sottoforma di messaggi provenienti dai social media. Queste informazioni, opportunamenteelaborate, consentono al sistema di individuare le situazioni di emergenza e migliorarnela gestione. Questi dati, conservati nel Database, rappresentano però anche una preziosafonte di informazioni che può essere sfruttata ad emergenza conclusa.

Partendo da questi presupposti, viene naturale pensare ad un potenziamento del sistemaTORCIA, dotandolo di uno strumento di Business Intelligence in grado di svolgereanalisi sui dati raccolti durante la fase critica. Con riferimento al ciclo di vita delleemergenze introdotto nel paragrafo 2.1.1, l'utilizzo di questo strumento avviene,pertanto, durante le fasi di mitigation e preparedness, lontano dall'emergenza vera epropria.

Per inserire questo nuovo tool all'interno di TORCIA, sì è deciso di modificare uncomponente già esistente, e quindi già integrato, del sistema chiamato Torcia Monitor.

La descrizione di Torcia Monitor e delle sue funzionalità nell'ambito della BusinessIntelligence saranno oggetto del prossimo capitolo.

68

Capitolo 4

Uno strumento di social mediaintelligence per la gestione delleemergenze

Questo capitolo si occuperà dello strumento di Business Intelligence sviluppatonell'ambito del progetto TORCIA.

La sezione 4.1 presenterà le caratteristiche possedute dallo strumento di BusinessIntelligence realizzato in questo lavoro di tesi.

La sezione 4.2 si occuperà di Torica Monitor, componente del sistema TORCIA cheimplementa le caratteristiche introdotte nel paragrafo 4.1.

La sezione 4.3 si concentrerà sulle analisi che possono essere compiute con questostrumento.

La sezione 4.4, infine, proporrà alcune idee per lo sviluppo futuro di questo Tool.

4.1 Framework dello strumento

Tutti gli strumenti di Business Intelligence possiedono delle caratteristiche e dellacapacità capacità comuni, che si differenziano solamente per l'ambito specifico in cui lostrumento si trova ad operare.

69

In particolare, si segnalano le seguenti:

• capacità di compiere analisi longitudinali;

• capacità di eseguire analisi multidimensionali;

• capacità di fornire indicatori di prestazione

• capacità di rappresentazione grafica dei dati

In questa sezione verranno illustrate queste caratteristiche, calandole nel contestospecifico dello strumento di BI realizzato per la gestione delle emergenze nell'ambito diTORCIA.

4.1.1 Utenti dello strumento

Il destinatario principale di questo strumento di analisi, in quanto componente delsistema TORCIA, sarà la Protezione Civile italiana.

Il Tool potrà ovviamente essere utilizzato, in futuro, anche da qualsiasi Ente che sioccupi della gestione delle situazioni d'emergenza, anche fuori dai confini nazionali,qualora il sistema TORCIA venga adottato da tali organizzazioni.

Oltre che gli Enti preposti alla gestione delle situazioni di emergenza, ci sono anchealtre categorie di soggetti che possono essere interessate alle analisi effettuate da questostrumento, tra cui giornalisti, ricercatori, business analyst e consulenti esterni. Ciascunadi queste categorie pone il suo interesse su un particolare aspetto dell'analisi, che nonnecessariamente riveste la stessa importanza per le altre. Per il progetto dellefunzionalità del Tool è quindi fondamentale scegliere a quale categoria di utenti ci siintende rivolgere, fermo restando che la priorità va assegnata alle esigenze dellaProtezione Civile.

In questo lavoro di tesi è stato scelto di considerare unicamente il destinatario principaledel progetto TORCIA, anche se alcune delle funzionalità implementate possono fornirerisultati utili anche ad alcune delle categorie sopra menzionate.

4.1.2 Analisi dei dati longitudinali

I dati longitudinali sono dati organizzati in modo tale da poter seguire i soggettianalizzati nel corso del tempo. Essi sono diventati di primaria importanza in molticampi, come l'economia, la sociologia e la demografia.

Lo strumento di Business Intelligence di TORCIA è in grado di analizzare tutte leemergenze registrate a partire del periodo di attivazione del sistema, differenziandosicosì dal cruscotto di monitoraggio sviluppato da Beta 80 progettato per gestire lasingola emergenza.

70

4.1.3 Analisi multidimensionali

Le analisi multidimensionali che il Tool è in grado di realizzare sono centrate sui volumidi messaggi memorizzati nel Database di TORCIA. Nel seguito del paragrafo verrannopresentate le dimensioni lungo le quali si sviluppa l'analisi.

Tempo

Questa dimensione assume una particolare importanza, in quanto, a differenza dellealtre, è sempre presente. Essa possiede quattro livelli di aggregazione, secondo loschema di figura 4.1:

Figura 4.1: Livelli di aggregazione della dimensione Tempo

Il livello di aggregazione massimo viene indicato con il termine “INTERVALLO” inquanto esso non ha un valore fissato. Infatti, per garantire una corretta visualizzazionegrafica dei risultati, il Tool aggrega i volumi in modo tale da lasciare nell'area divisualizzazione al più 10 colonne, come verrà maglio chiarito quando verrà presentato ilTorcia Monitor.

Sorgenti

Le sorgenti considerate sono quelle contenute nell'omonima tabella del Database. Anchese fino ad ora TORCIA si è avvalso solo del social network Twitter, sono state prese inconsiderazione altre due sorgenti di prossima integrazione: l'applicativo mobile diBeta80 e il social media YouReporter.

Keyword

Anche per questa dimensione, i suoi valori sono quelli della tabella Keyword delDatabase.

71

Segnalazioni e classi

La dimensione “segnalazioni” può assumere due valori: messaggio allegato ad unasegnalazione oppure messaggio non allegato ad alcuna segnalazione (quindi ritenutonon utile).

La dimensione “classi” ha invece come valori le sette classi introdotte nel terzo capitolo,all'interno del paragrafo riguardante il Classificatore, ovvero: Dove, Segnalazione,Conseguenze, Responsabilità, Viabilità, Warning, Post.

Queste due dimensioni sono collegate tra loro, in quanto solamente ai messaggi allegatia qualche segnalazione viene attribuita una classe.

4.1.4 Key Performance Indicator

Le prestazioni di un sistema o di un processo vengono misurati attraverso degliindicatori chiamati Key Performance Indicator o KPI. Essi sono caratterizzati da unametrica, che specifica la formula di calcolo attraverso cui è ottenuto l'indicatore, e unaunità di misura.

I KPI che lo strumento è in grado di fornire sono descritti di seguito.

Quantità di parlato

Metrica: Totale di messaggi allegati ad una segnalazione

Unità di misura: Numero di messaggi (volume)

La quantità di parlato di per sé non è significativa, in quanto è dipendente da diversialtri fattori, come la densità di popolazione dell'area colpita e il periodo in cui avvienel'emergenza. Tuttavia se, considerati questi fattori, il volume di messaggi si rivela essereparticolarmente basso, esso potrebbe indicare un disagio dei cittadini, che addiritturarinunciano a segnalare l'accaduto.

Questa problematica è stata evidenziata durante la conferenza “La collaborazione fraICT e Geoscienze nella gestione dei Rischi Naturali e delle Emergenze” tenutasi alPolitecnico di Milano il 25 Settembre 2014, e coinvolge l'aspetto sociologico dellagestione delle emergenze, che deve andare di pari passo con quello tecnico.

Qualità del parlato

Metrica: Messaggi allegati alla segnalazione

Messaggi totali

Unità di misura: Percentuale (%)

Tempo di gestione di un'emergenza rispetto alla richiesta social

Metrica: Tempo che intercorre tra la segnalazione dell'emergenza sui social media e la

72

gestione dell'emergenza da parte della Protezione Civile. Può essere riferito ad unasingola emergenza oppure come valore medio tra tutti quelli rilevati. In futuro, quandoTORCIA sarà in grado di gestire diversi tipi di emergenza oltre ai nubifragi e allealluvioni, questo valore potrà essere calcolato per le diverse tipologie di emergenza,aiutando a comprendere quali sono le situazioni critiche in cui è necessario migliorare.

Unità di misura: Ore (h)

Questo Indicatore è di primaria importanza, però non può essere ottenuto con i soli datiora a disposizione. Infatti, anche se l'analisi del parlato sociale può portare adindividuare l'istante in cui si scaturisce la richiesta dai social media, sono necessarianche i dati relativi alle tempistiche di gestione dell'emergenza da parte della ProtezioneCivile.

4.1.5 Rappresentazione grafica dei dati

Gli strumenti di Business Intelligence offrono varie rappresentazioni grafiche deirisultati delle analisi, allo scopo di semplificarne l'interpretazione, tra cui linee,istogrammi, torte, ecc.

I risultati dell'analisi multidimensionale vengono rappresentati da Torica Monitormediante un istogramma bidimensionale. Sull'asse delle ascisse è presente il Tempo, inuno dei suoi livelli di aggregazione, mentre sull'asse delle ordinate si trova il numero dimessaggi (ovvero il volume).

Grazie alla possibilità di esportare i risultati dell'analisi tramite un file CSV, saràpossibile ottenere altri tipi di rappresentazione usando altri software.

4.2 Torcia Monitor

Web Service e Motore Semantico sono entrambe applicazioni predisposte per essereeseguite in background. Il Servizio PUSH TWEET è un vero e proprio servizio web cherimane in ascolto sulla porta 8080 del server TORCIA, mentre i sorgenti Java delMotore Semantico sono stati wrappati per poter essere eseguiti come un Servizio diWindows. Per entrambi i blocchi funzionali ci sono dei meccanismi di log checonsistono in una tabella del Database, per quanto riguarda il Servizio Push Tweet, e inun file di log (“ms-log.log”), per il Motore Semantico. Per rendere più pratica laconsultazione di tali registri, così come per poter agevolmente fermare e riavviare ilMotore Semantico, Luca Muccignato e Federico Negri hanno realizzato un software dimonitoraggio chiamato Torcia Monitor [14].

Il software è un'applicazione Windows con interfaccia grafica sviluppata con illinguaggio C# che, oltre alle funzionalità appena citate, comprende, nella versioneoriginale, dei grafici che riguardano statistiche sui dati ricevuti e sui risultati ottenuti dalMotore Semantico.

73

Questa parte è stata però riprogettata in questo lavoro di tesi, rendendo il tool dimonitoraggio uno strumento di Business Intelligence integrato nel sistema TORCIA, lecui caratteristiche sono state introdotte nella sezione precedente.

4.2.1 Architettura di Torcia Monitor

Il tool di monitoraggio, per svolgere il suo compito, interagisce con i registri del MotoreSemantico e con il Database. Quest'ultimo viene consultato sia per leggere il registro delServizio Push Tweet (tabella “Log_caricamento”), sia per le funzionalità di BusinessIntelligence, prelevando i dati dalla tabella Tweets.

Uno degli aspetti fondamentali di Torcia Monitor è il suo totale disaccoppiamento con ilcodice sorgente degli altri blocchi funzionali.

Per lanciare o arrestare il Motore Semantico, Torcia Monitor esegue una nuova Consolee da essa inserisce i comandi adatti per l'operazione desiderata. Ogni altra operazione diprelievo di informazioni dal Database, per effettuare delle statistiche, non implicaalcuna interazione tra l'esecuzione del Web Service e del Motore Semantico.

La figura 4.2 descrive l'architettura di Torcia Monitor:

Figura 4.2: Schema architetturale di Torcia Monitor

Dal momento che la funzionalità di monitoraggio dei registri del Servizio Push Tweet edel Motore Semantico esula dal contesto di questa tesi e la componente relativa allestatistiche è stata significativamente modificata, nel seguito ci si concentreràsull'oggetto di questo lavoro di tesi, rimandando per tutti gli altri aspetti all'elaborato diMuccignato e Negri [14].

74

4.2.2 Lo strumento di Business Intelligence

La figura 4.3 seguente mostra l'interfaccia dello strumento di Business Intelligence diToricia Monitor:

Figura 4.3: L'interfaccia dello strumento di BI di Torcia Monitor

Una volta impostati i valori desiderati per i parametri, lo strumento interroga il Databasetramite una query SQL e, una volta ottenuto il risultato, lo rappresenta sotto forma diistogramma.

Con riferimento alla figura 4.3, verranno introdotte tutte le sue componenti.

1: Selezione periodo

I due controlli “Da” e “A” permettono di selezionare, rispettivamente, la data di inizio ela data di fine del periodo del quale si vogliono visualizzare i volumi di messaggi. Essisono pertanto correlati alla dimensione Tempo, introdotta nel paragrafo 4.1.3. Il livellodi aggregazione con la quale vengono mostrati i volumi cambia in modo automatico aseconda della lunghezza del periodo selezionato. Questa operazione si rende necessariain quanto la scelta di periodi particolarmente lunghi potrebbe rendere larappresentazione inutilizzabile, per via dell'eccessivo numero di colonne presentinell'area di visualizzazione. Per questo motivo, il tool opera nel modo seguente:

• mostra i volumi aggregandoli giornalmente per periodi inferiori o uguali a 10giorni;

• aggrega i volumi per un numero di giorni tale da mantenere al più 10 colonnenell'area di visualizzazione; tale numero di giorni è il livello di aggregazione

75

“INTERVALLO” precedentemente introdotto.

La scelta del numero di colonne è stata fatta sperimentalmente, cercando di trovare ilmiglior compromesso tra dettaglio (inteso come minor numero possibile di giorniaccorpati) e leggibilità del grafico.

Se entrambi i selettori della data hanno lo stesso valore (ovvero il periodo si riduce aduna singola giornata), il livello di aggregazione per la dimensione Tempo passa allivello di Ora. Quando si verifica questa situazione, si attiva il controllo “Ora”.

2: Selezione ora

Questo controllo, normalmente disabilitato, diviene utilizzabile solo quando sì è sceltauna singola giornata tramite i controlli della data. Esso permette effettuare un'ulterioredrill-down lungo la dimensione tempo, scendendo al livello minimo. Vengono cosìmostrati i volumi di messaggi relativi all'ora selezionata raggruppati in sei intervalli dadieci minuti ciascuno.

3: Pulsante Go

E' il pulsante che avvia la visualizzazione dei risultati dell'analisi con i parametriimpostati.

4: Selezione della sorgente

Questo gruppo di controlli permette di lavorare sulla dimensione Sorgenti del modellomultidimensionale.

Il bottone “Tutte” considera tutte le sorgenti simultaneamente, i cui volumi verrannovisualizzati in colonne adiacenti per ciascun intervallo di tempo.

Premendo il bottone “Singola” si abilita il controllo “Sorgente”, tramite il qualel'operatore può scegliere una delle sorgenti di TORCIA oppure il valore “all”. Nel primocaso, viene effettuato uno slice del cubo multidimensionale rispetto alla sorgente scelta,nel secondo, viene effettuato un roll-up che elimina questa dimensione dall'analisi.

5: Selezione della keyword

Questo controllo consente di scegliere la keyword in base alla quale filtrare i messaggi,oppure l'opzione “all” per effettuare un roll-up che elimina questa dimensionedall'analisi.

6: Segnalazioni e classi

Questo gruppo di controlli permette la gestione delle dimensioni “Segnalazioni” e“Classi” che, come visto, sono collegate.

Per le “Segnalazioni” sono disponibili tre bottoni:

76

• Allegati: vengono scelti solo i messaggi allegati ad una segnalazione;

• Non allegati: vengono scelti solo i messaggi che non sono stati allegati ad alcunasegnalazione;

• Tutti i messaggi: compie l'operazione di roll-up eliminando questa dimensionedall'analisi e, di conseguenza, anche quella relativa alle classi

Quando viene premuto il bottone “Allegati” diviene attivo il controllo “Classi”,disabilitato negli altri casi. Tramite questo controllo, l'operatore può scegliere una dellesette classi, ed ottenere il volume di messaggi che le appartengono. Anche per questadimensione, è disponibile l'opzione “all” per effettuare il roll-up che la toglie dal cubomultidimensionale.

7: Affianca totali

Quando questo flag è selezionato, alle colonne già presenti viene affiancata quellarelativa al volume totale di messaggi in quello stesso periodo di temporale. In questomodo è semplice per l'operatore rendersi conto, ad esempio, di quanti messaggiprovengono da Twitter rispetto al totale.

8: Visualizzazione messaggi

Questo pulsante apre una finestra con un tabella che contiene informazioni sui messaggiche corrispondono ai parametri impostati. Queste informazioni sono un sottoinsiemedegli attributi della tabella “Tweets”, scelto per fornire subito all'operatore i dati salientiche possono risultargli utili, senza appesantirlo con dati interni del sistema contenuti inquella stessa tabella, come ad esempio il numero che identifica il messaggio tra i varipartner di TORCIA.

I campi della tabella sono:

• ID_TWEET: contiene il valore dell'omonimo campo della tabella “Tweets” delDatabase, in modo che l'operatore possa facilmente risalire a tutte leinformazioni relative al messaggio presenti nel Database, qualora lo si rendanecessario;

• UTENTE: identificativo dell'autore del messaggio;

• TESTO: testo del messaggio;

• DATA: data e ora in cui è stato digitato il messaggio;

• SORGENTE: la sorgente del messaggio.

9: Esporta come file CSV

Premendo questo pulsante verrà creato un file nel formato Comma-Separated Values(CSV) contenente i dati corrispondenti ai volumi visualizzati, in modo tale che essi

77

possano essere importati da un software esterno per eventuali ulteriori elaborazioni.

10: Area di visualizzazione

Area dello schermo in cui appare il grafico.

4.3 Analisi effettuate

Questa sezione si occuperà delle analisi che possono essere effettuate con questosoftware.

La prima parte presenterà dei casi di studio riferiti ad alcune emergenze verificatesi nelcorso del 2013 e del 2014, con le relative conclusioni.

La seconda parte invece descriverà le analisi che lo strumento potrà compiere nonappena saranno disponibili i dati opportuni.

4.3.1 Casi di studio

In questo paragrafo verranno presentati alcuni casi di studio. Utilizzando il software diBusiness Intelligence sono state analizzate alcune emergenze scoperte dal sistemaTORCIA nel corso del 2013 e del 2014. Le dimensioni considerate sono il Tempo e leSegnalazioni. Per ciascuna emergenza verrà mostrato il grafico fornito in output dalTool e verranno calcolati i KPI introdotti nel paragrafo 4.1.4.

Con riferimento all'output di Torcia Monitor, i volumi di tweet allegati alle segnalazionisono disegnati in azzurro, mentre in rosso sono raffigurati i volumi totali di messaggipresenti nel Database in quella giornata.

Al termine, verranno presentate alcune osservazioni in merito ai risultati ottenuti.

4.3.1.1 Nubifragio Catania

Nei giorni 21 e 22 Febbraio 2013 si è abbattuto sulla città di Catania un violentonubifragio. La figura 4.4 si riferisce a tale emergenza:

Figura 4.4: Nubifragio Catania

78

21 Febbraio

Quantità di parlato: 1856 messaggi allegati.

Qualità del parlato: 1856 / 4142 = 45%

22 Febbraio

Quantità di parlato: 836 messaggi allegati

Qualità del parlato: 836 / 3366 = 25%

4.3.1.2 Alluvione Vicenza

Nei giorni 15, 16 e 17 Maggio 2013 il Veneto è stato interessato da forti precipitazioni,che hanno causato un alluvione nella città di Vicenza, a cui si riferisce la figura 4.5:

Figura 4.5: Alluvione Vicenza

15 Maggio

Quantità di parlato: 89 messaggi allegati

Qualità del parlato: 89 / 860 = 10%

16 Maggio

Quantità di parlato: 1765 messaggi allegati

Qualità del parlato: 1765 / 4388 = 40%

17 Maggio

Quantità di parlato: 212 messaggi allegati

Qualità del parlato: 212 / 2892 = 7%

79

4.3.1.3 Alluvione nelle Marche e a Senigallia

Nel primi giorni di Maggio 2014 le Marche sono state interessate da un forte maltempo,che ha provocato nella città di Senigallia una delle peggiori alluvioni delle sua storia. Ilpicco delle segnalazioni si trova nel giorno 3 Maggio, giorno dell'alluvione, e nel giornosuccessivo. Nei giorni a seguire i messaggi hanno toccato diversi argomenti, dalleiniziative per aiutare gli alluvionati alla denuncia di episodi di sciacallaggio.

La figura 4.6 mostra l'andamento dei volumi nel periodo 2 – 9 Maggio:

Figura 4.6: Alluvione Marche e Senigallia

2 Maggio

Quantità di parlato: 16 messaggi allegati

Qualità del parlato: 16 / 4588 = 0.3%

3 Maggio

Quantità di parlato: 12212 messaggi allegati

Qualità del parlato: 12212 / 27844 = 44%

4 Maggio

Quantità di parlato: 5399 messaggi allegati

Qualità del parlato: 5399 / 11517 = 47%

5 Maggio

Quantità di parlato: 1462 messaggi allegati

Qualità del parlato: 1462 / 4727 = 31%

6 Maggio

Quantità di parlato: 949 messaggi allegati

80

Qualità del parlato: 949 / 3599 = 26%

7 Maggio

Quantità di parlato: 678 messaggi allegati

Qualità del parlato: 678 / 2646 = 26%

8 Maggio

Quantità di parlato: 438 messaggi allegati

Qualità del parlato: 438 / 2378 = 18%

9 Maggio

Quantità di parlato: 304 messaggi allegati

Qualità del parlato: 304 / 1716 = 18%

4.3.1.4 Grandinata a Reggio Emilia ed esondazione del Seveso

Le giornate del 7 e 8 Luglio 2014 sono state caratterizzate da forte maltempo, che hacausato due diverse situazioni di emergenza rilevate da TORCIA, una a Reggio Emilia euna a Milano. Queste emergenze hanno generato un volume considerevole di parlatosociale, come mostrato dalla figura 4.7.

Figura 4.7: Grandinata di Reggio Emilia ed esondazione del Seveso

Il 7 Luglio, verso le ore 16:30, una violenta grandinata ha colpito la città di ReggioEmilia. Nel giro di venti minuti sono caduti dai 25 ai 35 millimetri di pioggia egrandine, con chicchi grandi anche 4 centimetri, creando sul suolo uno strato spesso, inalcune zone, anche più di 7 centimetri.11

La figura 4.8 mostra in dettaglio i tweet relativi alla giornata del 7 Luglio. Come si puònotare, vi è un picco di messaggi dalle 17 alle 18, appena dopo l'evento.

11 http://www.centrometeoitaliano.it/grandine-reggio-emilia-citta-completamente-imbiancata-07-07-2014-16775/

81

Figura 4.8: Distribuzione dei tweet del 7 Luglio

Il giorno 8 Luglio, dopo otto ore di pioggia, si è verificata l'esondazione del fiumeSeveso a Milano, provocando danni e disagi nel quartiere Niguarda. L'esondazione,avvenuta nel cuore della notte, ha paralizzato l'intera area. Il picco di messaggi, come sipuò notare dalla figura 4.9, si ha dalle 6 alle 7, in quanto i Milanesi al loro risveglio sisono trovati il quartiere allagato ed hanno dovuto affrontare notevoli disagi per andareal lavoro.

Figura 4.9: Distribuzione dei tweet dell'8 Luglio

La figura 4.10 mostra il dettaglio dei volumi rilevati nell'ora di picco:

82

Figura 4.10: Distribuzione dei volumi dalle ore 6 alle ore 7

7 Luglio

Quantità di parlato: 18273 messaggi allegati

Qualità del parlato: 18273 / 156364 = 12%

8 Luglio

Quantità di parlato: 3577 messaggi allegati

Qualità del parlato: 3577 / 83655 = 4%

4.3.1.5 Seconda esondazione del Seveso

Nel periodo 23 - 28 Luglio 2014 è di nuovo protagonista l'esondazione del fiumeSeveso a Milano. L'andamento dei messaggi è riportato in figura 4.11.

Figura 4.11: Volumi relativi al periodo 23 – 28 Luglio

Nei giorni 23, 24 e 25 Luglio si è registrato un piccolo volume di messaggi relativo allaprecedente esondazione di inizio mese, in quanto in quei giorni è stato aperto losportello del Comune per il censimento dei danni.

Il 26 Luglio, intorno alle 7:30, è avvenuta una nuova esondazione, che ha colpito gli

83

stessi quartieri della precedente. Si è inoltre aperta una voragine di grandi dimensioni,profonda circa 12 metri.12 Come si può vedere dalla figura 4.12, il picco di parlato si hatra le 6 e le 8, scendendo progressivamente nelle ore successive.

Figura 4.12: Distribuzione dei tweet del 26 Luglio

I messaggi dei giorni successivi riguardano per lo più la voragine apertasi nel mantostradale e la notizia dell'apertura di un'indagine sulle sue possibili cause.

23 Luglio

Quantità di parlato: 26 messaggi allegati

Qualità del parlato: 26 / 2064 = 1%

24 Luglio

Quantità di parlato: 29 messaggi allegati

Qualità del parlato: 29 / 1665 = 2%

25 Luglio

Quantità di parlato: 24 messaggi allegati

Qualità del parlato: 24 / 1619 = 1%

26 Luglio

Quantità di parlato: 683 messaggi allegati

Qualità del parlato: 683 / 4564 = 15%

27 Luglio

Quantità di parlato: 38 messaggi allegati

Qualità del parlato: 38 / 2153 = 2%

12 http://www.today.it/cronaca/seveso-esondato-milano-26-luglio-2014.html

84

28 Luglio

Quantità di parlato: 21 messaggi allegati

Qualità del parlato: 21 / 996 = 2%

4.3.1.6 Osservazioni

In questo paragrafo verranno presentate alcune osservazioni riguardati i casi di studiopresentati.

La prima osservazione riguarda l'andamento dei volumi. In tutti i casi analizzati si puòriscontrare un andamento similare, che cresce fino a raggiungere il picco nei giorni delvivo dell'emergenza e che decresce progressivamente nei giorni successivi. Questatendenza si riscontra anche nell'andamento giornaliero dei volumi, con il picco checoincide con l'ora in cui avviene disastro o con il momento di maggior disagio da partedei cittadini. Questo andamento quindi segue la tendenza che si viene a creare per ognitipo di evento o notizia, con un momento di picco a cui segue un progressivo calo diinteresse.

Per quanto riguarda gli Indicatori di Performance è possibile osservare che:

• Il nubifragio di Catania e l'alluvione di Vicenza hanno caratteristiche simili: laquantità di parlato è pressoché la medesima, e la qualità del parlato si confermabuona, con un valore medio del 36% per l'emergenza di Catania e del 25% perquella di Vicenza, che ha un picco del 40% il giorno 4 Maggio;

• L'alluvione nelle Marche e a Senigallia presenta un volume elevato nei giorni dimaggiore crisi, con percentuali di messaggi utili alla segnalazione che in queigiorni superano il 40%, come per Catania e Vicenza;

• La grandinata a Reggio Emilia presenta un volume di messaggi molto piùelevato degli altri casi, ma con una qualità del parlato sensibilmente più bassa(12%);

• La prima esondazione del Seveso ha una quantità di parlato molto più bassa diquella generata solo il giorno prima dalla grandinata a Reggio Emilia, con unaqualità del parlato appena del 4%. Anche il volume di messaggi creato a finemese per l'apertura dell'ufficio del censimento dei danni presenta lo stesso trend.

• La seconda esondazione del Seveso presenta nel giorno dell'accadimento unaquantità di parlato di soli 683 messaggi, anche se la percentuale di messaggiallegati del 15% è migliore rispetto al precedente episodio.

Per una maggiore comprensione della qualità del parlato, sono stati analizzati tramite lafunzionalità “Visualizza” di Torcia Monitor i messaggi scartati negli stessi giorni in cuisono avvenute le emergenze oggetto dei casi di studio.

85

Questa analisi, ha portato all'identificazione di alcune categorie in cui far rientrare imessaggi scartati, di seguito esposte.

Una tipologia di messaggi che è sempre presente e che può essere definito come unaspecie di “rumore di fondo”. Il Crawler infatti preleva tutti i messaggi che contengonodeterminate parole chiave che possono riferirsi a situazioni di emergenza;successivamente è il Motore Semantico che si occupa di stabilire se c'è effettivamenteun'emergenza in corso e scegliere i messaggi che verranno inclusi alla relativasegnalazione. Pertanto, i messaggi contenti tali parole vengono considerati ma poiscartati. Appartengono a questa categoria tutti i messaggi relativi alla soap opera“Tempesta d'amore”, presenti in tutti casi considerati, oltre ai tweet più disparati, comead esempio “Io la chiamo tempesta. Pensa era la più tranquilla della cucciolata”.

Ci sono poi degli avvenimenti o messaggi legati a persone famose che generano ungrande parlato su Twitter e che utilizzano le parole chiave di interesse per TORCIA, purnon essendo relativi a situazioni critiche. Con riferimento ai casi di studioprecedentemente illustrati, si segnalano i seguenti:

• numerosi retweet ai messaggi dell'utente MarroneEmma, presenti in vari giorniche comprendono la parola “Tempesta”, ad esempio “La vita non è aspettareche passi la tempesta...ma imparare a ballare sotto la pioggia.”

• grande volume di messaggi relativi allo spettacolo teatrale “Casta away – Latempesta imperfetta” di Enrico Bertolino (7 Luglio)

• notevole quantitativo di retweet al cinguettio dell'utente “jaxofficial”: “Causaalluvione il DjSet di stasera al Sabbiadoro di Monopoli è annullato” (27Luglio).

Un'altra tipologia di messaggi non idonei è quella dei messaggi veramente riferiti ad unaemergenza, ma che non contengono il luogo a cui si riferiscono, come il seguente,postato durante i giorni del nubifragio a Catania: “La mia adorata città sommersadall'alluvione”.

Alcune delle emergenze considerate come casi di studio sono avvenute negli stessigiorni in cui ne sono avvenute altre anni prima, che vengono ricordate. Tali messagginon vanno ovviamente messi in allegato. A titolo di esempio, vi sono i tweet del giorno5 Maggio 2014 inerenti alla targa ricordo dell'alluvione del 1924 a Praiano, sullacostiera Amalfitana.

Infine, si segnalano quei messaggi che sarebbero idonei per gli scopi di TORCIA, mache sono sporadici, quindi non superano le soglie fissate dal sistema, oppure nonriguardano l'Italia. Appartengono a quest'ultimo caso la frana avvenuta in Afghanistannegli stessi giorni dell'alluvione nelle Marche, che ha generato un parlato considerevole,o la tempesta di sabbia verificatasi a Phoenix, negli Stati Uniti, menzionata il 26 Luglio.

86

Alla luce di queste considerazioni sono spiegabili le percentuali molto basse rilevate nelmese di Luglio, in quanto oltre al “rumore di fondo” si sono aggiunti i tweet nonrilevanti riconducibili a personaggi famosi e alle molte segnalazioni riguardanti l'esteroo comunque le varie zone d'Italia colpite dal maltempo senza però superare le soglie.

La quantità di parlato delle due esondazioni del Seveso potrebbe però rappresentare uncampanello di allarme. Anche se la seconda esondazione è avvenuta di sabato e a finemese con la città in parte svuotata, la quantità di parlato così bassa potrebbe indicare cheormai le esondazioni del Seveso “non fanno più notizia”, riconducendosi all'aspettosociale della gestione delle emergenze.

Come ultima osservazione, si può pronosticare che la qualità del parlato che dovrebbeessere prodotto dagli utenti dell'applicativo mobile dovrebbe essere molto alta. Essainfatti è stata specificamente progettata per la gestione delle emergenze e dovrebbepoter contare su utenti attivi e interessati a queste problematiche, escludendo così lapresenza di messaggi non utili appartenenti almeno ad alcune delle tipologie menzionatepoc'anzi.

4.3.2 Analisi future

Il Tool di Business Intelligence è predisposto per operare analisi anche su dati non almomento non disponibili. Queste analisi verranno descritte nei prossimi paragrafi.

4.3.2.1 Taratura del peso delle sorgenti

A ciascuna delle sorgenti di TORCIA, come visto nel paragrafo 3.3, è associato un peso,che indica quanto sono rilevanti per il sistema i messaggi provenienti da quella sorgente.Questo valore è stato fissato per Twitter, mentre andrà impostato per le altre sorgenti. Inparticolare, si presume che il peso da assegnare all'applicazione mobile debba esseresensibilmente più alto, in quanto i suoi utenti dovrebbero essere persone interessate eattive, che contribuiranno con informazioni più precise rispetto a quelle della massa deitweet.

L'analisi della qualità del parlato osservata lungo un arco di tempo opportuno sarà unvalido strumento per verificare le ipotesi fatte sull'importanza delle varie sorgenti, e perdefinire in maniera precisa il peso da assegnare loro, migliorando così le prestazioni delsistema.

L'analisi potrà anche essere raffinata in futuro differenziando le varie tipologie diemergenza, portando eventualmente a definire dei pesi differenziati in base a tipo dievento catastrofico.

4.3.2.2 Analisi effettuabili sulle Classi

Dal momento che il sistema TORCIA è ancora in fase di realizzazione, i dati contenuti

87

nel Database non sono completi. In particolare, non sono presenti le Classi alle qualiappartengono i messaggi allegati alle segnalazioni.

Le Classi sono molto importanti per le finalità di Business Intelligence, soprattutto lacategoria Warning, che contiene messaggi utili alla prevenzione dell'emergenza (quindiassociata alla fase di Preparedness) e la categoria Responsabilità, in cui rientrano imessaggi indicanti le responsabilità di un dato evento (associata pertanto alla fase diMitigation).

Quando i dati conterranno l'indicazione delle Classi lo strumento di BusinessIntelligence potrà consentire la selezione dei volumi ad esse relativi e, tramite lafunzionalità “Visualizza”, l'Operatore potrà raccogliere le indicazioni degli utentiriguardo alla prevenzione o alle responsabilità.

Si osserva infine che queste analisi possono fornire utili indicazioni per lo sviluppo el'evoluzione dell'applicativo mobile: ad esempio, valori al di sotto delle aspettativepotrebbero essere dovuti a dei problemi nell'usabilità dell'applicazione.

4.4 Sviluppi futuri

In questa sezione verranno proposte alcune idee per i possibili sviluppi futuri delsoftware di Business Intelligence di TORCIA.

4.4.1 Aggregazione dei Luoghi

Come visto nel capitolo precedente, il Motore Semantico associa ad ogni segnalazioneun Luogo, che viene inserito nel Database assieme agli altri dati ad essa relativi. Unpossibile miglioramento di cui potrebbero beneficiare le analisi consiste nel fornire unanuova dimensione di analisi, costituita dalle Località in cui si verificano le emergenze.

Una possibile gerarchia per questa dimensione, schematizzata nella figura 4.13,potrebbe avere come livello minimo di aggregazione il Luogo memorizzato nelDatabase con la segnalazione, passando poi alla Città o Comune in cui esso si trova, allaProvincia (o Entità governativa che ne prenderà il posto), alla Regione, fino ad arrivaread una eventuale livello massimo che potrebbe essere Italia Nord Occidentale, NordOrientale, Centrale, Meridionale, Insulare13.

13 http://www.comuni-italiani.it/zona/

88

Figura 4.13: Livelli di aggregazione per la dimensione Località

Nel caso in cui il Luogo sia una Città o una Regione, allora alcuni livelli diaggregazione non saranno disponibili, poiché non è mai possibile disaggregare unadimensione al di sotto del livello di granularità dei dati presenti nel Database.

4.4.2 Diverse tipologie di emergenza

Il sistema TORCIA, allo stato attuale, opera solamente con una tipologia di evento,ovvero le alluvioni e allagamenti. In futuro però il sistema sarà in grado di gestiremolteplici tipologie di eventi, tra cui, ad esempio, incendi e terremoti.

Quando verrà raggiunto questo livello di maturità, potrebbe rivelarsi utile analizzare ilnumero di occorrenze di ciascuna tipologia di evento, secondo le seguenti dimensioni:

• Tempo: è possibile prendere in considerazione tutto il periodo di funzionamentodel sistema, oppure selezionare un periodo di riferimento in modo analogo aquanto accade per i volumi.

• Zona: nel caso in cui venga implementata la dimensione Località introdotta nelparagrafo 4.4.1, sarà possibile aggregare le emergenze in base alle zone in cuiesse si verificano.

La rappresentazione grafica può essere anche in questo caso un semplice istogramma,ma è anche possibile implementarne una di maggiore effetto, costituita da una cartinageografica sulla quale sono segnalati i luoghi delle emergenze con la tipologia ed ilnumero di occorrenze.

89

4.4.3 Profilazione degli utenti

Un'altra analisi che potrebbe risultare di interesse riguarda gli autori dei messaggiutilizzati da TORCIA. Si potrebbe creare una classifica degli utenti più attivi, ottenutaconsiderando il numero di post o retweet riferiti ad emergenze o allerte.

Le possibili dimensioni di analisi sono le seguenti:

• Tempo: la classifica può essere effettuata sulle segnalazioni riferite ad unperiodo di tempo impostato dall'operatore, in maniera analoga a quanto avvieneper i volumi;

• Zona: limita le segnalazioni da prendere in considerazione alla zona selezionata;anche questa dimensione necessita dell'aggregazione dei Luoghi descritta nelparagrafo 4.1.1;

• Sorgenti: si focalizza l'analisi su di una delle sorgenti di TORCIA

Il passo successivo a queste analisi, effettuabili a partire dai dati presenti nel DatabaseTORCIA, potrebbe essere quello di cercare di comprendere chi sono gli utenti ai primiposti di queste classifiche. In questo senso, sarebbe interessante sapere se essi sono, adesempio, dei giornalisti piuttosto che semplici cittadini volenterosi, se sono o menodegli influencer o se possiedono account su più sorgenti.

Tale identificazione però va oltre le possibilità di TORCIA e richiede l'accesso allecredenziali in possesso degli amministratori dei social media utilizzati come sorgente. Ilnome utente infatti, di per sé non è significativo, in quanto in ambito social è purtroppodiffuso il fenomeno dei falsi profili, ovvero profili che in realtà non appartengono allapersona a cui si riferiscono.

La validazione di un profilo utente potrebbe consentire l'aggiunta di informazione utileda includere in una segnalazione. Durante l'analisi dei casi di studio sono infatti emersidiversi tweet che sono stati scartati perché privi di un riferimento ad una località, come iseguenti: “Dopo l'alluvione: scuole chiuse lunedì e martedì”, “E' morta dopo il trasportoall'ospedale. Iris Conti è la terza vittima dell'alluvione.”. Entrambi i messaggi sonodell'utente “v_senigallia” e sono stati postati, rispettivamente, il 4 e il 6 Maggio 2014.Se “v_senigallia” venisse autenticato come profilo ufficiale del quotidiano VivereSenigallia i suoi messaggi potrebbero essere ritenuti validi anche se non contengonotutti gli elementi normalmente considerati al fine di decidere se un messaggio vada omeno allegato ad una segnalazione.

4.4.4 Integrazione con l'applicativo mobile

Un ulteriore sviluppo futuro per il software di Business Intelligence consiste nella suaintegrazione con l'applicativo mobile di TORCIA.

90

In questo modo, tutti i cittadini e gli operatori della Protezione Civile che usufruisconodella App potranno ottenere i propri quadri di sintesi e consultarli tramite dispositivomobile in qualunque momento e qualsiasi luogo.

Questa nuova funzionalità aumenterà la qualità delle informazioni a disposizione degliutenti, migliorando la loro consapevolezza con ripercussioni positive sul loro grado diprontezza e preparazione per le situazioni di emergenza.

91

Capitolo 5

Conclusioni

In questo lavoro di tesi è stato progettato ed implementato uno strumento di BusinessIntelligence pensato per migliorare la gestione delle emergenze, nell'ambito del progettoTORCIA.

E' stato definito il framework di questo strumento, calando nel contesto specifico lecapacità possedute dagli strumenti di Business Intelligence, quali analisi longitudinali,definizione di Key Performance Indicator, analisi longitudinali e rappresentazionegrafica dei risultati.

E' stato poi descritto il software realizzato per implementare tali funzionalità,specificando come esso si integra all'interno di TORCIA.

Tale strumento, è stato utilizzato per analizzare alcune emergenze rilevate dal sistemaTORCIA nel corso del 2013 e del 2014. Anche se i dati a disposizione sono incompleti,sono stati raggiunti risultati incoraggianti. E' stato infatti possibile identificare unandamento comune del volume dei messaggi nel tempo, quantificare la percentuale dimessaggi utili alle segnalazioni delle varie emergenze e individuare e classificare lecaratteristiche dei messaggi ritenuti non utili.

Sono state inoltre presentate le analisi che lo strumento è già in grado di compiere, nonappena saranno disponibili i dati opportuni, e suoi possibili sviluppi futuri.

Questo strumento ha ampi margini di estensione, che andranno di pari passo con lacrescita del sistema TORCIA, in particolare con la sua capacità di individuare piùtipologie di emergenza e di integrare nuove sorgenti di informazioni. L'utilizzo dellostrumento da parte della Protezione Civile in situazioni reali inoltre, potrà suggerire

92

miglioramenti da apportare all'interfaccia o alla presentazione dei risultati. Anche ilpossibile utilizzo dei risultati delle analisi per ricerche in ambito sociologico non deveessere trascurato.

93

Appendice A

Categorie di classificazione

In questo appendice verranno mostrati i dettagli relativi al perfezionamento dellecategorie.

La sezione A.1 riporterà le categorie di partenza.

La sezione A.2 riporterà il risultato delle modifiche apportate.

A.1 Categorie di partenza

Dove

Monitora, Monitorare, Città, Centro, Via, Viale, Piazza, Vie, Dintorni, Vicinanze,Vicino, Periferia, Periferica, Periferico, Zona, Quartiere, Regione, Limitrofo, Limitrofa,Adiacente, Adiacenze, Lontano, Distante, Posto, Località, Locale, Milano, Roma,Pescara, Genova, Lipari, Palermo, Borgogna, Liguria, Salento, Campania, Salerno,Metro, Nord, Sud, Ovest, Est, Venezia, Spagna, Lunigiana, Piazza, Tuscia, Messina,Bologna, Salernitano, Rieti, Arcore, Italia;

Segnalazione

Allagamenti, Allagamento, Allagata, Allagato, Allagati, Temporale, Temporali, Pioggia,Piogge, Diluvio, Alluvione, Esondazione, Esondato, Esondare, Fiume, Piena, Acqua,Fango, Tombini, Tombino, Nubifragio, Nubifragi, Tempesta, Uragani, Inondazione,

94

Inondazioni, Grandine, Grandinata, Allagando, Uragano, Bufera, Grandinare, Inondato,Perturbazione;

Conseguenze

Alluvionati, Morti, Morto, Feriti, Ferito, Vittima, Vittime, Sfollati, Sfollate, Sfollato,Evacuazione, Evacuata, Evacuato, Ucciso, Deceduto, Uccisa, Deceduta, Annegamenti,Annegamento, Annegato, Annegata, Salvata, Salvato, Salvo, Salva, Salvi, Recuperato,Recuperata, Recuperati, Danni, Crollato, Crollata, Crollati, Pericoloso, Pericolante,Pericolanti, Rischio, Rischioso, Tende, Tendopoli, Casa, Case, Frana, Franato, Franata,Crollata, Crollate, Crolli, Inghiottito, Inghiottite, Inghiottiti, Chiuse, Chiusa, Chiusi,Chiuso, Allagamento, Allagamenti, Situazione, Disagi, Calamità, Inondazioni,Ginocchio;

Responsabilità

Vigili, Vigile, Vigilessa, Polizia, Magistrato, Forze, Ordine, Fuoco, Pattuglia,Autopompa, Volante, Gazzella, Carabinieri, Carabiniere, Poliziotto, Poliziotta,Protezione, Civile, Capo, Comandante, Stato, Napolitano, Gabrielli, Bertolaso,Parlamento, Parlamentari, Senato, Ministro, Ministri, Piove, Alemanno, Gasparri,Sindaco, Comune, Ritardi, Tilt;

Viabilità

Percorribile, Percorribili, Libera, Libere, Liberata, Liberate, Pulita, Pulite, Ripulita,Ripulite, Sgombra, Sgombre, Chiusa, Chiusi, Chiuse, Chiuso, Via, Strada, Tangenziale,Tang, Traco, Frana, Percorsi;

Warning

Intasato, Intasati, Intasata, Fogne, Fogna, Fognatura, Argini, Argini, Letto, Flusso,Attenzione, Pericolo, Pericoloso, Pericolose, Pericolosi, Inondazioni, Allagamento,Allagamenti, Avvertita, Temporali, Temporale, Diluviando, Piovendo, Esondazione,Spostamenti, Uragano, Allerta, Prevedono, Rischio, Previsti;

Post

Risarcimento, Risarcimenti, Ricostruzione, Lamenta, Lamentele, Lamentela,Assicurazione, Assicurazioni, Assicurati, Denaro, Soldi, Assegni, Assistenza,Alluvionati, Protesta, Protestano, Rimborso, Rimborsi, Interventi, Ripristino, Disagi,Fondi, Denunce, Sicurezza;

95

A.2 Categorie migliorate

Dove

Monitora, Monitorare, Città, Centro, Via, Viale, Piazza, Vie, Dintorni, Vicinanze,Vicino, Periferia, Periferica, Periferico, Zona, Quartiere, Regione, Limitrofo, Limitrofa,Adiacente, Adiacenze, Lontano, Distante, Posto, Località, Locale, Milano, Roma,Pescara, Genova, Lipari, Palermo, Borgogna, Liguria, Salento, Campania, Salerno,Metro, Nord, Sud, Ovest, Est, Venezia, Spagna, Lunigiana, Piazza, Tuscia, Messina,Bologna, Salernitano, Rieti, Arcore, Italia, Area, Valle, Galleria, Stazione, Ponte,Sottopasso, Sottovia, Arezzo, Valdarno, Toscana, Portici, Sanremo, Imperia, Spezia,capitale, Firenze, Napoli, Cinque Terre, Siracusa, Modena, Pescara, Inghilterra, Galles,Sarno, Piento, Badesse, Elba, Isola, Abruzzo, Bretagna, Sesto, Viareggio,Castelsardo,Sicilia, Terni, Pakistan, Canobbio, Sanremo, Friuli, Triste, Nocera, Rossana,Mestre, Emilia, Bergamo, India, Feltrino, Umbria, Isole, Trapani, Eolie, Metaponino,NewYork, Alghero, Canarie, Azzorre, Cilento, Sommalombardo, Zurigo, Trieste;

Segnalazione

Allagamenti, Allagamento, Allagata, Allagato, Allagati, Temporale, Temporali, Pioggia,Piogge, Diluvio, Alluvione, Esondazione, Esondato, Esondare, Fiume, Piena, Acqua,Fango, Tombini, Tombino, Nubifragio, Nubifragi, Uragano, Uragani, Inondazione,Inondazioni, Grandine, Grandinata, Allagando, Uragano, Bufera, Grandinare, Inondato,Perturbazione, Alluvioni, Maltempo, Frane, Franato, Franata, Inondata, Grandinato,Grandinate, Inondare, Inondando, Allagare, Esondando, Franare, Franando, Alluvionato,Alluvionate, Alluvionata, Grandinando;

Conseguenze

Alluvionati, Morti, Morto, Feriti, Ferito, Vittima, Vittime, Sfollati, Sfollate, Sfollato,Evacuazione, Evacuata, Evacuato, Ucciso, Deceduto, Uccisa, Deceduta, Annegamenti,Annegamento, Annegato, Annegata, Salvata, Salvato, Salvo, Salva, Salvi, Recuperato,Recuperata, Recuperati, Danni, Crollato, Crollata, Crollati, Pericoloso, Pericolante,Pericolanti, Rischiosa, Rischioso, Tende, Tendopoli, Franato, Franata, Crollata, Crollate,Inghiottito, Inghiottite, Inghiottiti, Chiuse, Chiusa, Chiusi, Chiuso, Disagi, Calamità,Inondato, Inondata, Ginocchio, Danno, Caduto, Caduta, Caduti, Disastro, Disastri;

Responsabilità

Vigili, Vigile, Vigilessa, Polizia, Magistrato, Forze, Ordine, Fuoco, Pattuglia,Autopompa, Volante, Gazzella, Carabinieri, Carabiniere, Poliziotto, Poliziotta,Protezione, Civile, Capo, Comandante, Stato, Napolitano, Gabrielli, Bertolaso,

96

Parlamento, Parlamentari, Senato, Ministro, Ministri, Alemanno, Gasparri, Sindaco,Comune, Ritardi, Accuse, Accusa, Squadre, Volontari, Volontariato, Interventi,Polverini, Briguglio, Fiorito, De Filippo, Moratti, Formigoni, Provincia, ComuneMilano;

Viabilità

Percorribile, Percorribili, Libera, Libere, Liberata, Liberate, Pulita, Pulite, Ripulita,Ripulite, Sgombra, Sgombre, Chiusa, Chiusi, Chiuso, Strada, Strade, Tangenziale, Tang,Traffico, Percorsi, Statale, Ss, Autostrada, Rallentamenti, Rallentato, Rallentata,Galleria, Sottopasso, Ponte, Tilt, Circolazione, Regolare, Sottovia, Sospesa, Sospeso,A1,A3, A22, Metropolitana, Tram, Treno, Treni, Metropolitane, Ritardo, Ritardi, Piazza,Via, Vie,Duomo, Nullo, Quartiere, Viale;

Warning

Intasato, Intasati, Intasata, Fogne, Fogna, Fognatura, Argini, Argini, Letto, Flusso,Attenzione, Pericolo, Pericoloso, Pericolose, Pericolosi, Avvertita, Diluviando,Piovendo, Spostamenti, Allerta, Prevedono, Rischio, Previsti, Probabili, Possibili,Possibile, Probabile, Rischia, Arrivo, Previsto, Prevista, Previste, Domani, Allarme,Attesa;

Post

Risarcimento, Risarcimenti, Ricostruzione, Lamenta, Lamentele, Lamentela,Assicurazione, Assicurazioni, Assicurati, Denaro, Soldi, Assegni, Assistenza,Alluvionati, Protesta, Protestano, Rimborso, Rimborsi, Interventi, Ripristino, Fondi,Denunce, Crisi, Disdette, Indagato, Indagati, Indagata, Interpellanza, Sicurezza, Piano,Lavori, Risolto, Risolti, Euro, Polemica, Polemiche;

97

Bibliografia

[1] Il metodo Augustus. http://www.ispro.it/wiki/images/9/95/Metodo_Augustus.pdf, 2008.

[2] Social Media Week di Torino. 2012.

[3] P. Atzeni, S. Ceri, P. Fraternali, S. Paraboschi, R. Torlone. Basi di dati: architetture e linee di evoluzione, Seconda edizione. McGraw-Hill, 2007.

[4] D. M. Boyd, N. B. Ellison. Social network sites: Denition, history, and scholarship. Journal of Computer-Mediated Communication, 13:11, 2007.

[5] M. Cameron, R. Power, B. Robinson, and J.Yin. Emergency situation awareness from twitter for crisis managment. In SWDM Workshop, pages 305-308, Lyon, France, 2012.

[6] C. Carcaci. Classificazione sintattica con metodi insiemistici. Master's thesis, Politecnico di Milano, 2012.

[7] D. Cartwright, F. Harary, and R.Z. Norman. Structural Models: An introduction to the Theory of Directed Graphs. 1965.

[8] G.Cesana, A.D'Ettorre. Analisi, metodologia e sviluppo di un sistema integrato per la gestione delle emergenze in ambito social. Master's thesis, Politecnico di Milano, 2013.

[9] M.Cha, H.Haddadi, F.Benevenuto, and K.P.Gummadi. Measuring user influence in twitter: The million follower fallacy. In ICWSM 2010: Proceedings of international AAAI Conference on Weblogs and Social, 2010.

[10] E.Estellés, F.González. Towards an integrated crowdsourcing definition. Journal of Information Science, 38(2):189-200, 2012.

[11] J.Luger. Here's how mobile social networks have become. Business Insider, 2013.

[12] S. Milgram. The small world problem. Psycology today, 2:60-67, 1967.

[13] J. L. Moreno. Who shall survive?: A new approach to the problem of human interrelations. 1934.

[14] L.Muccignato, F.Negri. Sviluppo ed integrazione di un motore semantico per il rilevamento e la geolocalizzazione di emergenze, nell'ambito del progetto

98

TORCIA. Master's thesis, Politecnico di Milano, 2014.

[15] A. Palla. Metodologia per la gestione di emergenze basata su informazione sociale. Master's thesis, Politecnico di Milano, 2012.

[16] A. Rezzani. Business Intelligence. Apogeo, 2012.

[17] G. Shih. In hurricane, Twitter proves a lifeline despite pranksters. Reuters, 2012.

[18] G. Simmel. Soziologie: Untersuchungen über die Formen der Vergesellschaftung. Ducker & Humblot, 1908.

[19] Social Media Manager. I social network piu popolari in italia: Facebook, Twitter,Linkedin. Socia Media Manager, Aprile 2013.

99