Bachelor thesis Calmanovici

UNIVERSITÁ DI PISA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE
Corso di Laurea Triennale in Ingegneria Informatica
BURSDET: sistema di monitoraggio dell’odio
nei social network
Tesi di Laurea
Candidato: Relatori:
Alessandro Calmanovici Prof. Marco Avvenuti
Ing. Fabio Del Vigna
Ing. Maurizio Tesconi
Anno Accademico 2015/2016

Sommario
I social media, quali i social network, i forum di discussione, i progetti collaborativi e le
piattaforme giochi hanno subito una significativa impennata di utilizzo negli ultimi anni.
Tuttavia, non tutti gli utenti del mezzo effettuano un utilizzo corretto dello stesso. Infatti,
sempre più spesso, si osserva un utilizzo massivo dei social media, con riferimento particolare ai
social network, per diffondere messaggi d’odio, o incitare altre persone a manifestare odio verso
specifici gruppi razziali o culturali e fomentando in tal modo un pericoloso circolo vizioso che
può deflagrare anche in atti di violenza fisica al di fuori della piattaforma. Con Hate Speech
si intende una comunicazione che incita all’odio e alla violenza nei confronti di un gruppo
di persone percepite come nemico comune. Alla luce dell’importanza del fenomeno, è nata
l’esigenza di controllare o meglio ancora prevenire l’insorgere di tale manifestazione d’odio.
Monitorare il livello di hate speech nel tempo per fornire segnali di allerta può aiutare nel
prevenire serie conseguenze a cose o persone.
Per tale ragione questo lavoro propone lo sviluppo di un sistema per l’identificazione au-
tomatica di anomali utilizzi del linguaggio violento, ben oltre i livelli massimi tollerati. Il
problema, definito in lettereratura con il nome di "burst detection", è quello dell’identifica-
zione di un gran numero di osservazioni inaspettate all’interno di una finestra temporale, e
trova applicazione in questo contesto. Il lavoro svolto presso l’IIT (Istituto di Informatica e
Telematica) e l’ILC (Istituto di Linguistica Computazionale ) del CNR (Consiglio Nazionale
delle Ricerche) di Pisa consiste proprio nella realizzazione di uno strumento avente le carat-
teristiche sopra citate, parte di un progetto più complesso volto alla prevenzione dell’odio e
delle sue conseguenze nel mondo reale. Tale progetto prevede diverse fasi di realizzazione e
funzionamento. Inizialmente sono stati raccolti dati dai social network, in particolare com-
menti prelevati da pagine diverse come input per gli stadi successivi. Tale dataset è stato
ripartito in commenti contenenti odio e commenti privi di odio, mediante un classificatore
appositamente addestrato. Il lavoro descritto di seguito si colloca immediatamente dopo la
classificazione. Esso consiste in:
3

4
• Organizzazione degli input
• Rappresentazione mediante serie temporali del livello di hate speech
• Visualizzazione dei dati mediante Horizon Charts
• Applicazione di un algoritmo di burst detection per l’individuazione di valori anomali
di odio

Indice
1 Introduzione 8
1.1 Hate Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Hate Speech nei social media . . . . . . . . . . . . . . . . . . . . . . . 10
2 Related Work 11
2.1 Individuazione del linguaggio violento . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Data Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Geomapping Hate Speech . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Time Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Burst Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Algoritmi di burst detection . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Lavoro Svolto 19
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Ambiente R e analisi iniziali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Algoritmo di Kleinberg . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Visualizzazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Horizon Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Interfaccia Graﬁca Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Caso di studio 32
4.1 Dati di input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Workﬂow e Architettura di riferimento . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Visualizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Conclusioni 39
5.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5

Elenco delle figure
1.1 Utilizzo dei social-network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Visual Analytics Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Esempio di mappa con geomapping dell’hate . . . . . . . . . . . . . . . . . . . 14
2.3 Schema di un processo di analisi mediante Time-Series . . . . . . . . . . . . . 15
2.4 Esempio intuitivo di burst detection . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Esempio di grafico R con time-series e step di 30 minuti . . . . . . . . . . . . 21
3.2 Esempi di grafici R con time-series e step di 20 e 10 minuti . . . . . . . . . . 21
3.3 Esempio di esecuzione dell’algoritmo di Kleinberg . . . . . . . . . . . . . . . . 24
3.4 Grafico dei tempi di risposta dell’algoritmo di Kleinberg . . . . . . . . . . . . 26
3.5 Tecnica per realizzare una horizon chart . . . . . . . . . . . . . . . . . . . . . 27
3.6 Oggetto burst sulla console R . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Interfaccia Web senza burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Interfaccia Web con burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Burst Plot relativo alla pagina Facebook "Matteo Salvini" . . . . . . . . . . . 34
4.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Architettura di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Esempio interfaccia Web con dataset "Commenti Facebook" . . . . . . . . . . 38
6

Elenco delle tabelle
3.1 Risultati della simulazione dell’algortimo di Kleinberg. . . . . . . . . . . . . . 25
3.2 Tempi di risposta dell’algoritmo in base alla dimensione dell’input. . . . . . . 25
4.1 Pagine Facebook scelte per l’estrazione dei commenti . . . . . . . . . . . . . . 32
4.2 Tipi di odio rilevato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Numero di burst raccolti per livello su ciascuna pagina Facebook . . . . . . . 33
7

1. Introduzione
I social media hanno radicalmente cambiato il modo di interagire delle persone e hanno in-
fluenza sulla vita di tutti i giorni [1]. Velocità di comunicazione, elevati livelli di interazione
e facilità di accesso sono solo alcune delle caratterstiche che hanno portato alla loro vasta
diffusione. In figura 1.1 viene mostrata l’evoluzione del fenomeno tra il 2005 e il 2013 se-
condo l’indagine condotta dal centro di ricerca Pew1. Nell’era della globalizzazione, si parla
di "cultura della connettività" per indicare le correlazioni tra attività nella vita online e in
quella offline, nonchè della presenza quasi ossessiva dei social media nella vita moderna [2].
In questo contesto la tecnologia rappresenta anche un canale comunicativo attraverso cui è
possibile entrare in contatto con una moltitudine di individui: mediante i social è possibile
raggiungere un bacino di utenza molto ampio. Date queste considerazioni generali, ci si vuole
soffermare su due punti chiave.
1. I social media rappresentano un cambiamento nel modo in cui la gente legge e condivide
informazioni e contenuti.
2. Uno degli aspetti che contraddistingue i servizi messi a disposizione dai social media è
la centralità dell’user-generated content, i contenuti generati dagli utenti [3].
La disponibilità ad accettare in maniera poco controllata tali contenuti e la visibilità che
essi riescono ad acquisire in poco tempo apre la strada a diversi problemi, derivanti dunque
dalla natura stessa dei social e dalle libertà che potenzialmente vengono concesse agli utenti.
Ci vogliamo focalizzare su un problema attuale che ha suscitato negli ultimi anni numerose
polemiche, l’hate-speech.
1
http://www.pewinternet.org/three-technology-revolutions/
8

CAPITOLO 1. INTRODUZIONE 9
Figura 1.1: Utilizzo dei social-network suddiviso per fasce d’età tra il 2005 e il 2013.
1.1 Hate Speech
Non esiste una singola definizione accettata internazionalmente per definire l’hate speech. In
termini generali indica un genere di parole e discorsi che non hanno altra funzione a parte
quella di esprimere odio e intolleranza e che rischiano di provocare reazioni violente contro un
determinato soggetto. In [4], l’hate-speech viene identificato in tre maniere.
1. É rivolto a un gruppo di persone e non alla singola persona. I tipi più comuni di discorsi
odiosi si riferiscono all’etnia, alla religione, al genere, all’orientamento sociale e alla
disabilità.
2. Presenta alcune caratteristiche tipiche, quali suggerire ai lettori il fatto che devono
affrontare delle serie minacce o violenze da parte di un altro gruppo e che le persone
dell’altro gruppo stanno minando alla loro integrità o innocenza.
3. Spesso incoraggia i lettori a perdonare o commettere atti violenti nei confronti del gruppo
preso di mira.
É dunque una comunicazione che denigra persone sulla base della loro appartenenza a un
gruppo particolare.
Se l’articolo 10 della Convenzione Europea dei Diritti dell’Uomo1, difende strenuamente la
1
http://www.echr.coe.int/Documents/Convention_ITA.pdf

CAPITOLO 1. INTRODUZIONE 10
libertà d’espressione dell’individuo, l’articolo 14 e molti altri a seguire, condannano le di-
scriminazioni, in qualsiasi forma. La condanna dell’hate speech sta dunque in un equilibrio
elastico ma spesso problematico con la libertà di parola.
1.1.1 Hate Speech nei social media
I social media sono ricchi di hate speech. Basta dare una rapida occhiata ai commenti di
un video caricato su YouTube con contenuto razziale o scorrere qualche post presente sulle
pagine Facebook di personaggi politici per rendersi conto che il fenomeno è presente e tende
ad aumentare [5].
Secondo la Southern Poverty Law Center (SPLC), una organizzazione per i diritti civili che
monitora l’attività di gruppi che incitano all’odio negli Stati Uniti, c’è stato un incremento
dell’80% nel numero totale di gruppi attivi dal 2000 al 2015. Gran parte di questi hanno una
sostanziale presenza online1.
I maggiori social network, quali Facebook, Twitter e Google adottano ciascuno la propria
politica nei confronti dell’hate speech. Esse sono in continua evoluzione: col passare degli anni
le normative imposte dagli organi ufficiali internazionali sono variate, e le politiche stesse
riflettono tali cambiamenti. Facebook ha affidato tramite il sistema delle segnalazioni una
parte del lavoro alla comunità di utenti, che possono spontaneamente marcare un contenuto
come contenente odio e dunque portarlo all’attenzione di chi gestisce realmente il problema.
L’approccio di Twitter è tra i più permissivi, mentre YouTube vieta esplicitamente l’hate-
speech. In realtà c’è ancora poca trasparenza a riguardo, specialmente nel come tali politiche
vengano davvero applicate. Nel tardo 2012 Google è stata pubblicamente criticata per la sua
decisione di rimuovere da YouTube il film pro-hate "The Innocence of Muslims" in alcuni
paesi e non in altri. Tate film è stato considerato fortemente offensivo da parte di molti
Musulmani: Google ha bloccato il contenuto in sette paesi, inclusi Egitto e Libia, ma l’ha
mantenuto visibile in altri affermando che non rispettava la definizione di "hate speech"2. In
Pakistan, 19 persone sono state uccise nelle proteste risultanti, e la critica ha incolpato Google
per aver permesso la visone del contenuto3. Come affermato da [5], indipendentemente da chi
sia da colpevolizzare, questo incidente ha posto in rilievo l’enorme responsabilità derivante
dalle scelte dei colossi del Web. Si tratta dunque di questioni molto delicate, che alimentano
un dibattito attuale e sotto certi aspetti controverso.
1
https://www.splcenter.org/hate-map
2
http://www.nytimes.com/2012/09/15/world/middleeast/anti-american-protests-over-film-enter-4th-day.html
3
http://www.nytimes.com/2012/09/17/technology/on-the-web-a-fine-line-on-free-speech-across-globe.html

2. Related Work
In letteratura il problema dell’hate speech è studiato sotto diversi punti di vista e non esiste
un modo univoco per affrontare il problema. In particolare spesso è connesso al fenomeno
dei troll e del cyberbullismo, argomenti molto vicini a quello dell’hate speech. Il problema
della burst detection applicata all’hate-speech è molto recente. Normalmente le elaborazioni
dei dati a disposizione si fondano su una precente raccolta e organizzazione degli stessi [6].
Questa fase richiede:
• Una scelta dei social-media dai quali tratte le informazioni in formato ancora non
strutturato, tipicamente commenti presenti sui Social Network.
• Una pianificazione di un formato standard secondo cui riordinare i dati estratti, con lo
scopo di semplificare i passaggi computazionali successivi.
• Una classificazione degli input che soddisfi come requisito minimo quello di assegnare a
ciascun dato un’etichetta binaria (Contente Odio/Non Contenente Odio).
La visualizzazione di dati di diversa natura raccolti dai social-media è invece un argomento
ben più trattato e sono stati prodotti diversi risultati, tra cui [7, 8].
Vogliamo presentare una breve descrizione del contesto entro cui è stato svolto il lavoro e
le relative aree di interesse.
2.1 Individuazione del linguaggio violento
La realizzazione di uno strumento che automaticamente sia in grado di individuare e classifi-
care contenuti scritti prelevati dai social-media è fondamentale considerata la grande quantità
di dati con cui si lavora.
In letteratura sono state discusse e utilizzate più tecniche, tra cui il Natural Language
Processing NLP e l’Apprendimento Automatico [9, 10]. Il processo di analisi e visualizzazione
descritto in seguito si basa sul progetto realizzato presso l’IIT (Istituto di Informatica e
11

CAPITOLO 2. RELATED WORK 12
Telematica) e l’ILC (Istituto di Linguistica Computazionale) del CNR (Consiglio Nazionale
delle Ricerche) di Pisa. Come descritto in [11], il lavoro è stato suddiviso in varie fasi.
1. Definizione di tre livelli di odio assegnabile, Strong Hate, Weak Hate e No Hate e
creazione delle classi di odio. Sono state individuate sette categorie in cui smistare il
testo contente hate: religioso, politico, razziale, socio-economico, sessuale, handicap e
altro.
2. Scelta di alcune pagine Facebook in cui individuare i commenti in maniera eterogenea,
così da poter ritrovare odio appartenente a tutte le classi.
3. Raccolta dati tramite un crawler che sfrutta le Facebook Graph API1, rielaborando i
dati e salvandoli in formato JSON.
4. Campagna di annotazione dei contenuti raccolti, che consiste nel destinguere i commenti
in cui non viene individuato odio da quelli in cui viene individuato, per poi suddividerlo
in Weak Hate o Strong Hate.
5. Utilizzo di un classificatore NLP riadattato alle esigenze particolari. Tramite un insieme
di regole e un training corpus, è in grado di smistare automaticamente i commenti forniti
in uno dei tre livelli di odio grazie alla creazione di un modello statistico.
6. Utilizzo di una Linguistic Annotation Pipeline preesistente che fornisce le caratteristiche
sintattiche e morfosintattiche di cui ha bisogno il sistema per classificare i commenti.
I risultati ottenuti forniscono un insieme di dati su cui è possibile condurre simulazioni e
analisi statistiche. Tali dati si presentano ora in maniera strutturata, ciascun commento è
stato annotato e classificato e disponibile per essere memorizzato su database.
2.2 Data Visualization
L’obiettivo primario della visualizzazione dati è quello di comunicare informazioni chiaramente
ed efficacemente attraverso strumenti grafici. Si occupa dello studio della rappresentazione
visiva dei dati, ossia informazioni di cui è stata fatta una astrazione in forma schematica [12].
La visualizzazione è uno degli step fondamentali nell’analisi di dati: negli ultimi decenni
sono stati sviluppati numerosi metodi in grado di automatizzare questo compito. La natura
complessa di molti problemi rende indispensabile includere l’intelligenza umana in uno stadio
1
https://developers.facebook.com/docs/graph-api

iniziale nel processo di analisi dati. Ecco perchè è fondamentale avere a disposizione delle in-
terfacce grafiche interattive. L’uomo può interagire direttamente con esse e sfruttare al meglio
le proprie capacità cognitive, permettendogli di compiere scelte più immediate in situazioni
complesse. Come affermato da [13] , la "Visual Analytics" è la scienza del ragionamento
analitico supportato da interfacce interattive.
Figura 2.1: La figura mostra una panoramica astratta dei differenti stadi (rappresentati dagli ovali)
e delle loro transizioni (frecce) nel processo di analisi visuale.
Come evidenziato in figura 2.1, il processo che comporta lo sviluppo di una conoscenza
sulla base di dati a disposizione è ciclico. L’alternanza tra modelli visivi e automatizzati è
una caratteristica tipica della Visual Analytics e conduce a una continua rifinitura e verifica
dei risultati preliminari.
2.2.1 Geomapping Hate Speech
Un approccio basato su mappe dinamiche per la rappresentazione dell’intensità dell’odio è
documentato da un gruppo di studenti di geografia della Humboldt State University in Cali-
fornia1. Sono stati raccolti circa 150.000 Tweet tra Giugno 2012 e Aprile 2013 che contenessero
informazioni sulla geolocalizzazione dell’utente. Di questi sono stati selezionati quelli conten-
tenti parole razziste, omofobe o contro i disabili, per poi categorizzarli come odiosi o non
1
http://users.humboldt.edu/mstephens/hate/hate_map.html

(a) (b)
Figura 2.2: I toni caldi rappresentano una maggiore intensità di odio. In figura (a) viene mostrato
un livello di dettaglio inferiore rispetto alla figura (b), che si ottiene dalla (a) tramite zoom.
odiosi manualmente. Come mostrato in figura 2.2 , la mappa è interattiva e fornisce dettagli
più specifici aumentando il livello di zoom.
2.3 Time Series
Una Time Series, serie storica in italiano, è una serie di osservazioni o misurazioni indicizzate
nel dominio del tempo. Tipicamente, vengono utilizzate sequenze di punti successivi equispa-
ziati nel tempo. L’analisi delle time series comprende metodi per studiare dati e poter estrarre
risultati statistici significativi o altre caratteristiche da questi. Le time series sono ampiamente
sfruttate in letteratura per lo studio di fenomeni aventi un ordinamento temporale intrinseco
e per i quali è possibile effettuare misurazioni a intervalli fissati [14, 15, 16].
I metodi per l’analisi delle time series possono essere suddivisi in due classi principali: quelli
basati sul dominio della frequenza e quelli basati sul dominio del tempo [17]. Inoltre, un’altra
possibile differenziazione riguarda i metodi parametrici e quelli non parametrici. I primi
presuppongono che il processo sottostante abbia una certa struttura che possa essere descritta
tramite un numero limitato di parametri e l’obiettivo diventa proprio quello di individuare
tali parametri. I secondi invece non prevedono alcuna ipotesi a priori.

Figura 2.3: La figura mostra le fasi di un processo di analisi dati tramite time series e le sue possibili
applicazioni.
È importante descrivere i campi d’interesse e le motivazioni che stanno alla base dell’analisi
delle time series. Nel contesto della statistica, della finanza, della sismologia, della meteoro-
logia e così via l’obiettivo fondamentale è detto forecasting: si cerca di ottenere una buona
previsione dell’andamento futuro della grandezza studiata. Nel contesto dell’elaborazione nu-
merica dei segnali, dell’ingegneria del controllo e delle comunicazioni l’ analisi di time series
viene usata per l’approssimazione. Infine, nei campi del data mining, del pattern recognition
e della machine learning può essere utilizzata per il clustering, la classificazione e l’anomaly
detection.
2.4 Burst Detection
Molti aspetti della nostra vita sono descritti da eventi. Secondo la definizione fornita da [18],
un burst è un gran numero di eventi che si verificano all’interno di una specifica finestra tem-
porale o regione spaziale. Tale definizione suggerisce dunque un comportamento o un’attività
inusuale. È un fenomeno molto conosciuto in tanti processi naturali e sociali. Per esempio,
gli stock trader sono interessati ai burst nei volumi commerciali. Gli astrofisici, invece, si
interessano ai burst nei raggi gamma, che potrebbero riflettere il verificarsi di una supernova.
La rilevazione di picchi di intensità è oggetto di numerosi studi e ricerche. Queste includono
l’utilizzo di tecniche di intelligenza artificiale come le reti neurali [19] e estensioni di logiche

booleane quali la logica Fuzzy [20].
Figura 2.4: Esempio molto intuitivo della rilevazione di un burst nelle ricerche contenenti la parola
chiave "Halloween" sul motore di ricerca MSN da parte degli utenti [21].
In questo contesto vogliamo applicare un algoritmo di burst detection su un dataset co-
stituito da "Time Series". Nonostante sia facile identificare visivamente dei burst in una
piccola time-series, è necessario formalizzare la nozione di burst per evitare la soggettività
e progettare degli algoritmi in grado di identificare automaticamente dei burst in qualunque
time-series [22]. Questo punto è molto importante in applicazioni quali il monitoraggio di
data center dove centinaia di grandi time-series indicanti l’utilizzazione di CPU o di memoria
devono essere analizzate in tempo reale. Un altro esempio significativo per comprendere la
necessità di sviluppare algoritmi automatizzati è quello dei burst associati alle reti di distri-
buzione dell’acqua. Tali burst nei volumi di acqua nelle tubature possono provocare ingenti
costi economici e sociali e sono molto comuni a livello municipale. Tanti sistemi sono vecchi
e in condizioni scadenti, per cui lo stress meccanico e la corrosione sono la causa principale
della loro rottura. I danni provocati da un burst sono spesso proporzionali al tempo speso
per trovarlo e isolarlo. Tipicamente i consumatori riportano il verificarsi di un burst quando
l’acqua appare sulla superficie della terra. Il tempo che passa tra l’accadere dell’evento e l’i-
dentificazione del burst può essere molto lungo, specialmente considerando che può avvenire

durante la notte e in aree remote. Per una reazione veloce, il sistema di tubature deve essere
monitorato costantemente, da qui la necessità di un algoritmo di burst detection che agisca
in real-time. Uno studio approfondito della questione si trova in [23].
2.4.1 Algoritmi di burst detection
Un compito difficile è quello di monitorare l’occorrenza di burst di cui non si conosce a priori
la durata in un ambiente di data stream veloci. I risultati presentati in seguito sono tratti
dalla tesi di dottorato [24]. Tipicamente l’algoritmo viene definito sulla basa base di due fasi
iniziali.
1. Rappresentazione dei dati. In letteratura sono state ampiamente studiate tecniche per
realizzare questo compito. Possono essere categorizzate in tecniche nel dominio del
tempo/dominio della frequenza, con perdita/prive di perdita, numeriche/simboliche,
parametriche/non parametriche.
2. Preprocessing: riduzione o riepilogo dei dati. Questo compito può essere svolto in
due modi, riducendo la dimensione dei dati o riducendo la loro dimensionalità. Ogni
differente rappresentazione richiede una opportuna tecnica di preprocessing, queste due
fasi sono dunque dipendenti l’una dall’altra.
Poichè il compito è quello di individuare un gran numero di eventi inusuali, la burst detec-
tion appartiene a una categoria più ampia: in letteratura si parla di novelty/anomaly/ou-
tlier/surprise detection. Sebbene sia difficile fornire una definizione univoca, esistono delle
classificazioni anche per tali metodi: basati sulla profondità, basati sulla distribuzione, basati
sulla densità o basati sulla distanza. Riportiamo delle brevi descrizioni su tre metodi molto
conosciuti. Il CUSUM è una tecnica di analisi sequenziale che utilizza un parametro detto th-
reshold deducibile a posteriori mediante studio del valor medio e della varianza. Holt-Winters
è un metodo di previsione per serie storiche non stagionali che funziona mediante "exponen-
tial smoothing". STL invece è un metodo molto versatile e robusto per decomporre le time
series in tre parti: stagionalità, tendenza e rimanenti. Poichè tali metodi possono essere visti
come problemi di classificazione, negli ultimi anni sono state proposte soluzioni che sfruttano
il machine learning, tradotto in italiano come apprendimento automatico. I metodi appena
citati riescono a individuare anomalie nelle serie o a prevedere il loro comportamento in futuro
ma non a rilevare un numero di eventi inusuale. Per quanto riguarda gli algoritmi di burst-
detection, questi sono fortemente influenzati dal contesto in cui si trovano ad operare e dalla
definizione di burst adottata nel caso specifico. Per tante applicazioni del mondo reale, come

il traffico Ethernet, web, file-system o video, viene sfruttato un modello di comportamento
del burst a un parametro, detto b-model. Le time-series di queste applicazioni sono simili
rispetto alla scala temporale adottata e presentano un gran numero di burst. Altri algoritmi
sfruttano l’exponential moving average, detta EMA, per determinare regioni temporali in cui
si verifica un gran numero di eventi. Tipicamente questo viene fatto quando le finestre tem-
porali da analizzare sono in numero ridotto: così è stato studiato il comportamento dei log di
query sul motore di ricerca di MSN. Le finestre prese in considerazione sono solo due: quella a
breve termine e quella a lungo termine. Esistono inoltre algoritmi che sfruttano strutture dati
molto avanzate, come gli istogrammi esponenziali che fanno parte delle "synopsis structures".
Un esempio di applicazione è lo studio condotto per stimare il numero di 1 in uno stream
di 0/1. L’algoritmo utilizzato per la burst-detection dell’hate-speech è quello di Kleinberg.
Esso verrà descritto nel capitolo 3 e verranno evidenziate le motivazioni che hanno portato a
questa scelta.

3. Lavoro Svolto
3.1 Introduzione
In questo capitolo verrà presentata una sintesi del lavoro svolto, verranno esposti i problemi
riscontrati e le soluzioni adottate. Viene fatta una suddivisone del capitolo in sezioni: queste
rispettano l’ordine cronologico del lavoro svolto. La sezione 2 descrive l’utilizzo dell’ambiente
R, i risultati ottenuti con l’algortimo di Kleinberg e una simulazione con dataset casuale. Le
sezioni 3 e 4 si riferiscono invece alla realizzazione software dell’interfaccia Web che mostra
i risultati della burst detection. Il lavoro svolto per lo sviluppo dello strumento di burst
detection nella versione finale può essere suddiviso in quattro fasi:
• Organizzazione degli input.
• Rappresentazione sotto forma di "Time Series" dell’andamento dell’hate speech inteso
come variabile causale ordinata rispetto al tempo.
• Visualizzazione dei dati mediante Horizon Charts.
• Burst detection per l’individuazione dei picchi di odio.
3.2 Ambiente R e analisi iniziali
R è un ambiente software gratuito per l’analisi statistica e grafica. Uno dei suoi punti di forza
è la comodità con cui possono essere prodotti grafici di buona precisione e il totale controllo
su di questi da parte dell’utente. R è dotato di un linguaggio di programmazione semplice,
ben supportato ed efficace. Include inoltre una vasta collezione, integrata e coerente, di tool
per l’analisi dei dati. In questo lavoro traiamo beneficio dalla possibilità di eseguire facilmente
le operazioni di I/O e disporre di strumenti per l’analisi di time-series e burst detection. Per
R è disponibile un gran numero di moduli distribuiti con la licenza GPL e organizzati in un
apposito sito chiamato "CRAN". Questo è uno degli aspetti che giustificano la sua popolarità:
19

CAPITOLO 3. LAVORO SVOLTO 20
nel nostro caso sono stati sufficienti due package, bursts1 e rjson2.
Inizialmente sono state fatte delle sperimentazioni di burst detection su un insieme di dati
annotati manualmente salvati su un file csv. Questo contiene tutti i commenti prelevati da di-
verse pagine Facebook e annotati secondo l’etichetta "commento contenente odio"/"commento
non contenente odio", come descritto nella sezione 2. R permette di estrarre tutte le righe del
file mediante un semplice comando e le inserisce in una struttura dati chiamata data.frame,
alla quale si può accedere per riga o per colonna come se fosse una matrice. Ad ogni commento
è associato un timestamp, che corrisponde all’istante in cui è stato postato sul social-network.
L’insieme dei timestamp formano una colonna del data.frame. È stato determinato un inter-
vallo temporale di riferimento e suddiviso con una certa frequenza, in particolare la finestra
che va dalle 16:18 del 16/05/2016 alle 16:18 del 17/05/2016, con step di 30 minuti. Vogliamo
creare una time-series significativa che sia compresa all’interno di questa finestra temporale.
Tra tutti i timestamp dei commenti all’interno del data.frame, abbiamo selezionato i soli ti-
mestamp dei commenti con odio. Tra questi, è stata eseguita un’altra operazione di filtraggio
e sono stati selezionati solo quelli che ricadono all’interno della finestra temporale scelta. A
questo punto abbiamo effettuato un count sul numero di commenti che ricadono dentro cia-
scun intervallo della finestra. Il grafico ottenuto è mostrato in figura 3.4. Fissato lo step s,
il valore corrispondente sull’asse delle y a ogni istante temporale i è da interpretare come
#N = [Numero di commenti contenenti odio tra l’istante (i-s) e l’istante (i)]. Per
esempio, nel nostro caso il valore corrispondente all’istante 16:48 16/05/2016 è circa 8. Que-
sto vuoldire che tra le 16:18 del 16/05/2016 e le 16:48 del 16/05/2016 sono stati rilevati 8
commenti con odio.
1
https://cran.r-project.org/web/packages/bursts/index.html
2
https://cran.r-project.org/web/packages/rjson/index.html

Figura 3.1: Plot del totale dei commenti odiosi sull’intero insieme di pagine tra le 16:18 del
16/05/2016 e le 16:18 del 17/05/2016, con step di 30 minuti.
In questo caso non è stata fatta alcuna distinzione per singola pagina, ma valutato il totale
dei commenti contenenti odio sull’intero insieme di pagine presenti nel file csv. Sono stati poi
creati dei grafici per lo stesso dataset e le stessa finestra di 24 ore utilizzando step diversi. In
figura vengono mostrati due esempi con step di 20 e 10 minuti.
(a) (b)
Figura 3.2: Plot del totale dei commenti odiosi sull’intero insieme di pagine tra le 16:18 del
16/05/2016 e le 16:18 del 17/05/2016, con step di 20 minuti in (a) e 10 minuti in (b).
Il livello di dettaglio dei grafici è inversamente proporzionale allo step scelto a parità di am-
piezza della finestra temporale considerata. Presi due grafici che si differenziano solo per lo

step scelto, i valori sull’asse delle y corrispondenti allo stesso istante temporale sono inferiori
sul grafico avente lo step più piccolo. Questo è dovuto al fatto che il numero di commenti
odiosi iniziale viene ripartito tra tutti gli intervalli temporali individuati dallo step: più sono
gli intervalli temporali entro cui viene suddivisa la finestra, minore sarà il numero di commenti
odiosi in ciascun intervallo. Per step inferiori ai 10 minuti tutti i grafici vengono uguali, questo
è dovuto al fatto che R non riesce a plottare oltre una certa risoluzione quando la frequenza
degli intervalli si intensifica e supera una soglia prestabilita.
3.2.1 Algoritmo di Kleinberg
Come specificato nel capitolo 2, in letteratura sono stati sviluppati diversi algoritmi di burst
detection. Il più adatto è risultato l’algoritmo di Kleinberg [25], che prende il nome dal suo
ideatore. È stato sviluppato proprio con l’intento di studiare il comportamento dei burst negli
stream testuali, questi infatti generalmente presentano un comportamento gerarchico e incline
ai burst. Nella descrizione originale dell’algoritmo viene preso in considerazione il caso delle
email. Kleinberg suppone di avere una grande cartella di email su un singolo argomento. Il suo
obiettivo è di indentificare i burst solo quando questi hanno un’intensità abbastanza elevata
e in maniera tale da permettere al burst di persistere attraverso un pattern di arrivo delle
email non uniforme. Poichè l’hate speech consiste proprio in un flusso testuale di parole odiose
presenti all’interno di commenti, l’algoritmo di Kleinberg è risultato la scelta più naturale. Lo
stream viene modellato con un automa a stati infiniti che in qualunque istante temporale si
può trovare in uno degli stati del set sottostante e emette messaggi a rate differenti dipendenti
dallo stato stesso. L’automa ha un set di stati che corrispondono a tassi d’emissione sempre
più elevati: l’inizio di un burst è segnalato da una transizione da uno stato più basso ad uno
più alto. Assegnando un costo a tali transizioni, si può controllare la loro frequenza, in modo
da evitare di rilevare burst troppo brevi e rendere più semplice l’identificazione di burst lunghi
malgrado cambiamenti transitori nel tasso dello stream.
I burst associati a transizioni di stato formano una struttura naturalmente annidata, con
lunghi burst di breve intensità che potenzialmente possono contenere diversi burst di maggiore
intensità al loro interno (e così via, ricorsivamente). Questo fenomeno può fornire una decom-
posizione gerarchica dell’ordine temporale, con episodi di lunga durata che si intensificano in
altri più brevi secondo una naturale struttura ad albero. L’algoritmo di Kleinberg assume
che l’intervallo tra due eventi consecutivi segua una distribuzione esponenziale. Brevemente,
detto x il gap temporale stimato tra il verificarsi di due eventi consecutivi, la probabilità che il

prossimo gap sia maggiore di x è proporzionale a s−x. L’implementazione utilizzata prevista
dal package R "bursts" richiede tre parametri in ingresso:
• offsets: un vettore contenente i timestamp degli eventi da analizzare.
• s: la base dell’esponenziale usata per determinare la probabilità che il prossimo gap
superi quello stimato: deve essere maggiore o uguale a 1 e di default è pari a 2.
• gamma: un coefficiente che modifica il costo di una transazione verso uno stato supe-
riore, positivo e di default pari a 1.
Il funzionamento ad alto livello è questo: dopo ciascun evento, lo stato in cui si trova il
sistema determina in maniera probabilistica quando tempo passerà prima che si verifichi
un nuovo evento. Mentre il sistema è nello stato i, viene assunto che gli intervalli tra gli
eventi siano tratti da una distribuzione esponenziale con valore atteso proporzionale a s-i.
Valori maggiori di s aumentano la rigidità del criterio dell’algoritmo che stabilisce quanto
debba essere intenso un incremento di attività per essere considerato un burst. Il costo di
un cambiamento di stato invece è proporzionale all’incremento nel numero di stato. Questa
proporzione può essere modificata settando il parametro gamma. Valori maggiori significano
che i burst devono essere sostenuti per periodi di tempo più lunghi affinchè l’algoritmo sia in
grado di riconoscerli.
Il primo problema da affrontare per cominciare l’analisi con Kleinberg è stato quello di
poter avere come input due o più commenti aventi timestamp coincidenti. Infatti l’algoritmo
assume che non vi siano eventi che si verificano nello stesso istante temporale. R permette
di maneggiare le date con la precisione voluta dall’utente. I commenti prelevati da Facebook
presentano timestamp fino all’ordine dei secondi. Vogliamo separare temporalmente due ti-
mestamp contemporanei. Una volta organizzati tutti i timestamp all’interno di un array, è
stato effettuato un sort e per ciascun elemento contati gli elementi successivi uguali a lui.
Data la natura del problema questa operazione richiede un tempo circa proporzionale alla
dimensione dell’array, quindi lineare. Supponiamo di prendere in cosiderazione l’elemento di
indice i e di avere m elementi uguali a i consecutivi, esso incluso. Gli elementi uguali vanno
quindi dall’indice i all’indice i + m − 1. Abbiamo sommato all’elemento di indice i + j un
tempo pari a j/m secondi, con j che va da 0 a m − 1. In questo modo si sfasano i timestamp
di un intervallo insignificante rispetto alla definizione generale del problema e non si generano
mai due timestamp identici.

Figura 3.3: Risultati grafici dell’algortimo di Kleinberg applicati al dataset prelevato da csv.
A questo punto è stato possibile applicare l’algoritmo: in figura 3.3 viene mostrato il grafico
dei burst risultanti dallo stesso dataset con cui è stata generata la timeseries in figura 3.1.
Come si può osservare sono stati rilevati burst fino al livello 6, in questo caso la transizione
progressiva da uno stato all’altro subito dopo le 7:18 è stata molto veloce e ciò denota un
incremento di attività particolarmente anomalo.
Simulazione tramite dataset casuale
Prima di sviluppare l’interfaccia Web abbiamo testato il funzionamento dell’algoritmo di
Kleinberg su diversi dataset generati casualmente. I parametri su cui è possibile lavorare sono
la dimensione dell’input, la frequenza dei burst e l’intensità degli stessi quando si presentano.
La simulazione si basa sulla generazione casuale di interi che assumono diversi significati. Per
cominciare abbiamo una finestra temporale suddivisa per minuti. Ad ogni minuto corrisponde
un certo numero di eventi. Ci sono tre classi distinte, dette A, B e C. Ognuna è caratterizzata
da due parametri: Vmin e Vmax. Un oggetto classe è un numero di eventi compreso tra Vmin
e Vmax che si verificano tutti all’interno dello stesso minuto. Di base in ciascun minuto si
verifica un numero di eventi compreso tra 0 e 5. Tramite Na, Nb, Nc definiamo in quanti
minuti è presente un’istanza della classe A,B o C. Per esempio, consideriamo una finestra di
900 minuti. Se Nb = 100 significa che in 100 minuti diversi dei 900 si verificherà un numero di
eventi compreso tra Vminb e Vmaxb. Abbiamo calcolato i tempi di risposta forniti e contato
il numero di burst ottenuti suddivisi per livello: questi dati potrebbero rivelarsi utili in future

applicazioni real-time dell’algoritmo.
Minuti totali NA NB NC VMINA
VMAXA
VMINB
VMAXB
VMINC
VMAXC
Liv3 Liv4 Liv5 Liv6
900 100 10 1 6 15 16 40 41 100 6 2 1 -
900 300 30 3 6 15 16 40 41 100 23 11 - -
4800 100 10 1 6 15 16 40 41 100 7 4 1 -
900 100 10 1 6 40 41 100 101 300 39 10 5 1
Tabella 3.1: Risultati della simulazione dell’algortimo di Kleinberg.
NINPUT TIME(s)
325 1,003
707 2,079
2141 9,363
3842 29,448
5188 47,282
6814 60,621
9883 154,189
13099 231,889
19833 583.457
24925 932.798
Tabella 3.2: Tempi di risposta dell’algoritmo in base alla dimensione dell’input.
Si possono tratte delle conclusioni generali interessanti da questi risultati. L’ampiezza della
finestra temporale considerata non ha rilevanza se gli intervalli tra gli eventi sono gli stessi. Nel
confronto tra la prima e la terza riga la finestra è stata ampliata di cinque volte mantenendo
lo stesso numero di eventi per minuto: il numero di burst è molto simile. A conferma di ciò
è stato fatto un altro esperimento. Abbiamo considerato una finestra di 400 minuti e una
di 4000 minuti. Ogni minuto si verificano due eventi, tranne nell’ultimo minuto in cui se ne
verificano 50. I risultati dell’algoritmo sono esattamente identici: un burst di livello 5 durante
l’ultimo minuto. Confrontando la riga 2 e la 4, si deduce che aumentare la frequenza del
numero di eventi che si verificano su una finestra temporale fissata non basta per raggiungere
burst di livello elevato, è invece necessario che tali eventi siano particolarmente ravvicinati nel
tempo. Chiaramente il "quanto" ravvicinati dipende dalla stima probabilistica dell’algortimo
sul tempo che intercorre tra il verificarsi di due eventi consecutivi. Abbiamo riportato su un
grafico i risultati sui tempi di risposta dell’algortimo e in prima analisi si può evidenziare un

comportamento di tipo quadratico in relazione alla dimensione dell’input. In figura 3.4 viene
mostrato il grafico. Il coefficiente del termine di secondo grado risultante è dell’ordine di 10−6.
Figura 3.4: Grafico dei tempi di risposta dell’algoritmo di Kleinberg in relazione alla dimensione
dell’input.
3.3 Visualizzazione dei dati
La visualizzazione contemporanea di tante time series riferite ciascuna a una pagina Facebook
distinta mediante grafici forniti da R non è efficace. Per prima cosa le informazioni contenute
in essi sono statiche, i grafici ottenuti riescono a mostrare un range molto limitato di valori
su entrambi gli assi e risultano ingombranti in termini di dimensione effettive occupate sullo
schermo. Una semplice valutazione del valore corrispondente a uno stesso istante temporale
su tre grafici distinti risulterebbe per lo meno scomoda. Abbiamo bisogno di uno strumento
dotato di due proprietà:
1. Deve essere interattivo
2. Deve essere scalabile
La visualizzazione non è un sostituto di lunghe analisi o alert automatici. Utilizza la perce-
zione umana per processare una gran quantità di dati velocemente e in maniera approssimati-
va. Le proprietà sopra citate sono fondamentali per poter svolgere tali attività massimizzando
l’efficienza e riducendo lo sforzo visivo ai livelli minimi.

3.3.1 Horizon Charts
Le Horizon Charts combinano posizione e colori per ridurre lo spazio verticale occupato. Sono
un tool molto potente per comparare dati nel tempo e rilevare pattern o correlazioni tra time-
series allineate verticalmente. In figura 3.5 viene mostrata la tecnica utilizzata per realizzarle.
Una compressione di un grafico di time-series da 120px a 30 px perde il 75% della risoluzione
e diventa molto difficile notare piccoli cambiamenti. Le Horizon Charts riducono lo spazio
verticale senza perdere risoluzione. Valori troppo grandi per la scala vengono rappresentati
sopra quelli esistenti utilizzando colori più scuri. Maggiore è il range di colori a disposizione,
minore è lo spazio verticale richiesto.
Figura 3.5: Tecnica per realizzare una horizon chart: sfruttando tonalità di colori diverse e posizione
si riduce lo spazio verticale occupato.
All’interno dell’interfaccia Web sviluppata sono presenti horizon chart interattive create
tramite le API offerte dalla libreria esterna open source cubism.js1. Essa a sua volta si
basa su D32 (Data Driven Documents), una libreria JavaScript per la manipolazione dei
documenti e trasformazioni degli stessi guidate dai dati. Per favorire la densità dei dati,
Cubism introduce delle metriche per pixel: ciascuno codifica un istante diverso nel tempo.
Risoluzioni di schermi tipiche attuali permettono dunque di rappresentare su una sola pagina
intervalli superiori alle 10 ore con frequenze di misurazione per minuto. Cubism è dunque
scalabile in termini di percezione visiva: piccoli cambiamenti sono ben discriminati mediante
la posizione, mentre i colori differenziano grandi cambiamenti. Un altro punto di forza è la
flessibilità, i componenti sono modulari e progettati per poter essere estesi facilmente. Cubism
è costituita da diversi elementi. Il contesto è l’elemento di controllo che coordina tutti gli altri
componenti: carte, metriche, assi e così via. Il contesto va definito specificando lo step da
adottare per la suddivisone della finestra temporale in intervalli e il numero totale di valori
1
https://square.github.io/cubism/
2
https://d3js.org/

da plottare: ogni valore viene rappresentato su un unico pixel. Tramite la funzione horizon()
si aggiungono nuove horizon charts al contesto e per ognuna va specificata una metrica per
creare la time-series. La metrica è costituita dall’insieme dei valori da mostrare sul grafico. Le
metriche sono componibili tra di loro: possiamo generare una time-series uguale al prodotto
o alla somma di altre due direttamente dal browser.
3.4 Interfaccia Grafica Web
L’interfaccia grafica è stata realizzata utilizzando degli iframe che incorporano una pagina html
in cui è presente il contenuto ottenuto con la libreria Cubism. In primo luogo abbiamo gestito
il formato dei dati di input e l’interazione con il database da cui questi vengono prelevati.
Il formato scelto è il JSON in quanto il suo utilizzo tramite JavaScript è particolarmente
semplice: la libreria d3 fornisce un metodo che implementa chiamate AJAX asincrone a cui
basta passare un url per eseguire la richiesta. Inoltre tramite il package rjson è possibile
convertire una struttura dati dell’ambiente R in formato JSON: le computazioni svolte dagli
script R vengono memorizzate direttamente su database nel formato corretto. Cubism richiede
un set di valori in ingresso che rappresentano la metrica per creare un’horizon chart: ciascun
valore viene fatto corrispondere ad un pixel e plottato. Il div entro cui è inserito l’iframe è largo
900 pixel, 900 è dunque il massimo numero di valori visualizzabile all’interno di una horizon
chart. Sul database memorizziamo semplicemente un array contente i 900 valori che vogliamo
mostrare sul grafico. Per quanto riguarda la gestione dei burst, al termine dell’esecuzione
dell’algoritmo di Kleinberg viene restituito un oggetto che sulla console R appare come in
figura 3.6.
Figura 3.6: Struttura di un oggetto burst per come appare sulla console R.
Sul database salviamo la sua versione in formato JSON. La struttura, in cui mostriamo solo
le prime tre righe, è la seguente:

{
"level": [1,2,3],
"start": [1479078001.29287 ,1479078020.14654 ,1479078020.14654]
"end": [1479081994.64426 ,1479078029.94035 ,1479078029.94035]
}
Poichè il primo livello di burst va semplicemente dall’istante in cui avviene il primo even-
to a quello in cui avviene l’ultimo, non lo includiamo nella struttura salvata sul database e
selezioniamo solo i burst con livello maggiore o uguale a 2. I timestamp vengono automatica-
mente convertiti nel formato Unix, rappresentante il numero di secondi trascorsi dall’origine
impostata al 01/01/1970. Questo non è un problema in quanto come spiegato più avanti è
comodo per svolgere facilmente operazioni algebriche tra timestamp, inoltre è sempre possibile
invertire la conversione direttamente col JavaScript.
In figura 3.7 viene mostrata l’interterfaccia Web realizzata. Per prima cosa è necessario
scegliere tra un insieme di dataset da visualizzare: abbiamo testato il funzionamento salvan-
do sul database i risultati ottenuti da una delle simulazioni. La visualizzazione è interattiva:
spostandosi col cursore lungo l’asse delle x vengono visualizzati contemporaneamente i valori
di tutte le horizon bar. Dopo aver cliccato sul grafico, è possibile utilizzare le frecce della
tastiera per muoversi con maggior precisione.
Figura 3.7: Interfaccia Web dopo aver aver selezionato un dataset.
Il problema principale è stato quello di trovare un modo per mostrare graficamente i burst

risultanti dall’algoritmo di Kleinberg. Abbiamo deciso di andare a disegnare sopra le horizon
bar, evidenziando gli intervalli di inizio/fine burst presenti negli oggetti burst memorizzati in
formato JSON sul database. La finestra temporale della simulazione parte da un timestamp
predefinito, detto T. Il margine sinistro MS del div di cubism, considerato come origine degli
assi, corrisponde dunque all’istante T. Dato un timestamp di inizio burst IB, in quale punto
del div va disegnato? La differenza IB-T è pari al numero di secondi tra l’evento T e l’evento
IB. Dobbiamo sapere a quanti pixel equivale tale distanza temporale. Cubism plotta un valore
per pixel. È opportuno riscrivere cose rappresenta per noi ogni valore. Come descritto nella
sezione 3.2.1, fissato uno step s, il valore corrispondente sull’asse delle y a ogni istante
temporale i è da interpretare come #N = [Numero di commenti odiosi tra l’istante
(i-s) e l’istante (i)]. Lo step s lo scegliamo noi preventivamente: per come funziona Cubism,
sappiamo che spostandoci di un pixel lungo l’asse passiamo da un valore all’altro. Ciò vuoldire
che tra un pixel e l’altro la differenza temporale corrispondente è esattamente pari allo step s
che abbiamo deciso a priori.
Per fare un esempio, se lo step è di 1 minuto, due pixel consecutivi si trovano a un minuto di
distanza sull’asse dei tempi. Dunque per sapere dove disegnare il timestamp IB, prendiamo
IB-T e la dividiamo per 60 ottenendo il numero di minuti tra T e IB che è esattamente pari
al numero di pixel tra la posizione di T e la posizione di IB. Ripetendo lo stesso ragionamento
per ogni timestamp, siamo in grado di tracciare una striscia rossa per ciascun burst, che va
dall’orario di inizio a quello di fine. Poichè un burst di livello L è contenuto temporalmente
nel burst di livello L-1, l’effetto grafico che si ottiene è quello di vedere intervalli temporali
con tonalità di rosso proporzionali al livello del burst che contengono. Questo è dovuto alla
sovrapposizione delle striscie man mano che vengono disegnate. In figura 3.8 viene mostrata
l’interfaccia Web e i burst relativi alla simulazione.

Figura 3.8: Interfaccia Web dopo aver premuto sul pulsante "mostra risultati Kleinberg".
È possibile mostrare e nascondere i risultati cliccando sui corrispettivi pulsanti. Il sito web
è disponbile all’indirizzo http://waﬁ.iit.cnr.it/fdv/hate/#. Sono state inserite un’introduzione
generale al problema dell’hatespeech e una breve descrizione del sistema realizzato. Il carico
applicativo lato browser è molto ridotto in quanto il client non esegue alcuna computazione
sui dati di ingresso e i risultati da mostrare a video sono già pronti sul database. Il layout del
sito è strutturato per garantire una corretta visualizzazione anche su dispositivi mobile: la
resa estetica risulta piacevole grazie alla possibilità di zoomare facilmente sullo schermo per
osservare i graﬁci "da vicino".

4. Caso di studio
4.1 Dati di input
L’interfaccia Web è stata progettata per poter visualizzare più dataset: uno di questi è co-
stituito dai risultati ottenuti applicando l’algoritmo di Kleinberg ai commenti annotati di cui
si parla nel capitolo 2. I commenti sono tratti da otto pagine Facebook diverse. Riportiamo
quanto scritto in [11] per una loro descrizione. Alcune tra quelle scelte (Tabella 4.1) sono,
ad esempio, le pagine ufficiali di Matteo Renzi e Matteo Salvini dove si è riscontrato più che
altro odio di tipo politico, razziale e sessuale. Troviamo la pagina ufficiale de La Zanzara,
programma radiofonico trasmesso da Radio 24 e condotto da Giuseppe Cruciani che propone
i titoli dei principali telegiornali, interviste con numerosi ospiti e commenta i fatti del giorno
con i protagonisti della vita politica italiana e con l’intervento telefonico dei radioascoltatori,
nella quale è stato possibile riscontrare odio appartenente a varie categorie. Un’altra pagina
scelta è stata Jenus, un fumetto di forte satira religiosa, con protagonista una reinterpretazio-
ne del Messia, nato come Fumetto Online scritto da Alessandro Mereu, sotto lo pseudonimo
di Don Alemanno, nella quale è stato riscontrato odio di tipo religioso.
PAGINA URL
Matteo Renzi https://www.facebook.com/matteorenziuciale/
Il Fatto Quotidiano https://www.facebook.com/ilFattoQuotidiano/
Emosocazzi -
La Zanzara https://www.facebook.com/lazanzarar24/
Matteo Salvini https://www.facebook.com/salviniocial/
Jenus https://www.facebook.com/JenusDiNazareth/
Noi Con Salvini https://www.facebook.com/NoiconSalviniUfficiale/
Sinistra Cazzate Libertà https://www.facebook.com/sinistracazzateliberta/
Tabella 4.1: Pagine Facebook scelte per l’estrazione dei commenti.
32

CAPITOLO 4. CASO DI STUDIO 33
Il dataset è composto da 5739 commenti annotati di cui 5200 commenti non presentano hate,
338 presentano Weak hate e 201 Strong hate. Una tabella riassuntiva con la suddivisione per
classi dei commenti viene mostrata di seguito.
TIPO ODIO WEAK HATE STRONG HATE TOTALE OCCORRENZE
Religioso 15 1 16
Handicap 4 1 5
Socio-economico 20 8 28
Politco 150 59 209
Razziale 99 62 161
Sessuale 32 58 90
Altro 64 44 108
Tabella 4.2: Tipi di odio rilevato.
Nelle analisi a seguire consideriamo le classi Weak Hate e Strong Hate accorpate. Preleviamo
dal database la sola colonna relativa ai timestamp ﬁltrando semplicemente i commenti e
selezionando solo quelli che presentano odio. Poichè i commenti annotati sono tutti compresi
tra il 15/05/2016 e il 18/05/2016, prenderemo in considerazione questa ﬁnestra temporale
per le fasi seguenti. Una volta raccolti i timestamp e suddivisi per pagina abbiamo applicato
l’algoritmo di Kleinberg per rilevare i burst di odio presenti su ciascuna di queste. I risultati
sono mostrati in tabella 4.3.
PAGINA LIVELLO 2 LIVELLO 3 LIVELLO 4 LIVELLO 5 LIVELLO 6
Matteo Renzi 2 2 - - -
Il Fatto Quotidiano - - - - -
Emosocazzi - - - - -
La Zanzara 1 1 1 1 -
Matteo Salvini 3 3 3 4 1
Jenus 1 1 1 1 1
Noi Con Salvini 1 - - - -
Sinistra Cazzate Libertà 1 1 1 1 -
Tabella 4.3: Numero di burst raccolti per livello rilevati dall’algoritmo di Kleinbeg applicato a cia-
scuna pagina. Notare che la pagina Emosocazzi è stata rimossa da Facebook a seguito di contenuti
inappropriati.
Nelle pagine "Il Fatto Quotidiano" e "Emosocazzi" non sono stati rilevati burst, mentre per

la pagina "Matteo Salvini" è avvenuto un fenomeno particolare, in quanto sono presenti più
burst di livello 5 rispetto a quelli inferiori. Questo succede quando da uno stato i passiamo
allo stato i+1, per poi scendere e risalire nuovamente in seguito a un altro aumento di attività.
In figura viene mostrato il grafico dei burst relativo alla pagina "Matteo Salvini" ottenuto con
l’algoritmo di Kleinberg per evidenziare quanto detto.
Figura 4.1: Grafico dei burst relativi alla pagina Facebook "Matteo Salvini".
4.2 Workflow e Architettura di riferimento
Vogliamo descrivere il processo implementativo più nel dettaglio scomponendolo per fasi suc-
cessive. Faremo riferimento anche ad una visione di alto livello dell’architettura di base
realizzata. Distinguiamo tra computazioni lato server e computazioni lato client: il server si
prende carico dei compiti elaborativi più pesanti e fornisce al client i risultati nella versione
finale, pronti per essere visualizzati. Come spiegato nel paragrafo 4.1, i dati giungono al si-
stema tramite un database all’interno del quale sono contenute le annotazioni dei commenti
prelevati da Facebook. Un record contiene più campi: quelli significativi sono l’ID del com-
mento, l’ID della pagina a cui appartiene, il suo timestamp, e le etichette Weak Hate/Strong
Hate. L’inserimento di nuovi record all’interno del database non riguarda il lavoro svolto in
questo contesto, possiamo pertanto supporre un caso tipico in cui sul server sia presente un
programma che preleva continuamente commenti da più pagine, li annota e li memorizza sul
database.
Uno script PHP si occupa dell’interazione tra database e ambiente R e può essere modificato
in base alle esigenze del sistema. Esso infatti accede al DB tramite query SQL: per ciascun

ID pagina, filtra i soli commenti con odio compresi in un intervallo temporale specificato e
memorizza i timestamp relativi a tali commenti in un array. Il sistema genera tanti array
quante sono le pagine da monitorare: ciascun array contiene tutti i timestamp dei commenti
con odio compresi tra i due istanti scelti. Cambiando gli istanti inseriti all’interno della query
si può variare la finestra temporale di riferimento. Noi abbiamo selezionato una finestra che
va dal 15/05/2016 al 18/05/2016 perchè il dataset in ingresso è compreso tra queste due
date. Un altro scenario potrebbe essere quello di mandare in esecuzione lo script sul server
a intervalli di tempo fissati, per esempio 5 minuti, e scegliere come finestra le ultime 24h.
In questo modo si ottiene una analisi near real-time: il contesto del problema non richiede
assoluta tempestività e una soluzione del genere può essere soddisfacente.
Le operazioni descritte in seguito vengono eseguite dallo script PHP per ciscuna pagina
Facebook. Esso formatta l’array in JSON e invoca l’esecuzione degli script R per le elabora-
zioni, passandogli come argomento l’array. Il primo script R si preoccupa di generare i valori
utilizzati da Cubism per creare le horizon charts, deve quindi funzionare con uno step noto a
priori. Lo step dipende dalla dimensione delle charts e dall’ampiezza della finestra temporale
stabilita. Noi abbiamo scelto una lunghezza di 900px per i grafici di Cubism e dunque in tutto
possiamo plottare 900 valori. Nel caso dell’esempio near real-time, la finestra è ampia 24h.
Ogni ora sono 60 minuti, quindi in una finestra di 24 ore abbiamo 1440 minuti. Vogliamo
suddividerla in 900 intervalli temporali equidistanti l’uno dall’altro. Lo step da adottare sarà
dunque pari a 1440/900 = 1,6 minuti. Determinato lo step, si procede come descritto nella
sezione 3.2 per la generazione dei valori che caratterizzano la time-series. Il secondo script R
invece gestisce la burst-detection: si deve preoccupare di separare temporalmente i timestamp
identici e di eseguire l’algoritmo di Kleinberg. I risultati dei due script R vengono restituiti
allo script PHP in formato JSON e sono memorizzati su un database SQL. Nel database, per
ciascun ID pagina è presente un array contenente tutti i valori necessari per rappresentare la
serie temporale e una struttura dati in formato JSON che rappresenta i burst. In figura 4.2
viene mostrato lo schema del Workflow appena descritto.

Figura 4.2: Workflow suddiviso per fasi successive e distinzione Client-Server.
Lato client viene invocato dal browser uno script PHP che semplicemente trasferisce al Ja-
vaScript e in particolare alla libreria Cubism i risultati presenti sul database contenente le
informazioni per la rappresentazione, dopo averli organizzati in un file JSON. Per una visua-
lizzazione statica è sufficiente chiamare lo script una sola volta, facendolo invece a intervalli
fissati viene aggiornata la pagina con le nuove informazioni presenti sul database.

Figura 4.3: Visione ad alto livello dell’architettura del sistema realizzato.
4.3 Visualizzazione
In ﬁgura 4.4 viene mostrata l’interfaccia Web dopo aver selezionato il dataset "Commenti
Facebook". Sulla sinistra vengono mostrati i nomi delle pagine Facebook e per ciascuna di
queste la time series risultante e i burst relativi. Avendo a disposizione 900 pixel e avendo scelto
una ﬁnestra temporale di quattro giorni, abbiamo ricavato lo step di conseguenza. Quattro
giorni corrispondono a 5760 minuti, dividendoli per 900 otteniamo uno step di 6,4 minuti.
Cubism implementa solo step interi quindi spostandosi di un pixel lungo l’asse dei tempi si
ottengono intervalli di 6 o 7 minuti a seconda dell’approssimazione sulla parte decimale. Per
tracciare i burst con maggior precisione è stata determinata manualmente la distanza in pixel
tra il bordo sinistro e il primo valore presente sulla pagina "Jenus", pari a 152px. Chiamiamo
T il timestamp del commento corrispondente. Risulta facile sapere quanto vale nella realtà
T perchè è semplicemente il primo timestamp in ordine temporale presente sul database.
T, come del resto tutti gli altri timestamp, può essere utilizzato come origine dell’asse dei
tempi. Scegliendo T come origine riduciamo le distanze che vanno calcolate per disegnare i
burst e dunque anche l’errore assoluto dovuto all’approssimazione di queste distanze. Il T
scelto da noi non è quello ottimo ma risulta un buon compromesso tra risultati e facilità di
individuazione. L’hate-speech rilevato tipicamente presenta dei burst spuri e lunghi periodi di
inattività. Questo è dovuto al fatto che il numero di commenti generale cresce sensibilmente

subito dopo la pubblicazione di un contenuto sulla pagina e si mantiene su valori bassi durante
il resto del tempo.
Figura 4.4: Interfaccia Web con dataset "Commenti Facebook".

5. Conclusioni
In questo elaborato abbiamo mostrato come sia possibile realizzare uno strumento che riesca
ad analizzare l’hate-speech presente sui social-network. Abbiamo creato un sistema in grado
di visualizzare su mappe interattive l’andamento dell’hate-speech e di riconoscere quando
si manifesta in maniera anomala producendo dei burst di attività. Siamo inoltre riusciti a
integrare queste due funzioni rappresentando i burst in forma grafica distinguendo il loro
livello tramite diverse tonalità di colore.
Abbiamo mostrato i vantaggi di poter disporre di informazioni dinamiche e a tal proposito
supposto un possibile caso d’uso del sistema realizzato. Lo scenario di utilizzo è quello in
cui viene studiata una finestra temporale che comprende le ultime 24h e aggiorna i risultati
sul sistema a intervalli fissi scelti opportunamente. Questo approccio può rivelarsi utile per
monitorare costantemente il livello dei burst dell’hate speech e fornire segnali di allerta. In
questo modo può essere d’aiuto nel prevenire serie conseguenze a cose o persone.
5.1 Sviluppi futuri
I risultati ottenuti rappresentano un punto di partenza per sviluppi futuri. Il sistema è
potenziabile sotto vari punti di vista.
• Possono essere introdotte funzionalità aggiuntive estendendo i componenti già presenti.
Per riportare alcune idee, potrebbe essere efficace in alcune applicazioni voler rappre-
sentare ogni burst con un colore diverso in base al livello. Un altro sviluppo interessante
è quello di lasciare più liberta all’utente e permettergli di scegliere la finestra tempo-
rale autonomamente. Si potrebbe dunque prevedere un campo per inserire due istanti
e aggiornare i grafici con una rappresentazione che va dal primo istante al secondo. Il
comportamento ottenuto mimerebbe quello dello zoom di una porzione di horizon chart.
Ancora, si potrebbe inserire un campo in cui l’utente può scegliere tra diversi algoritmi
di burst detection e comparare i risultati.
39

CAPITOLO 5. CONCLUSIONI 40
• Ampliare l’implementazione sottostante e creare un sistema real-time. La libreria Cu-
bism.js è stata progettata in primo luogo per applicazioni di tipo real-time. Supporta
l’interazione con strumenti quali Graphite1 e Cube2 che gestiscono la raccolta di eventi
e la memorizzazione automatica su database. Chiaramente anche le fasi di sviluppo
precedenti devono essere riviste. I commenti Facebook dovrebbero essere raccolti e
annotati in real-time, mentre la real-time burst detection è un argomento delicato e
richiede algoritmi diversi da Kleinberg. Avremmo dunque bisogno di hardware dedicato
per minimizzare i tempi di computazione e il ritardo evento/risposta all’evento. Il client
non può più semplicemente accedere ad un database ma deve essere notiﬁcato dal server
ogni volta che l’algoritmo di burst-detection produce un nuovo risultato.
1
http://graphiteapp.org/
2
https://square.github.io/cube/

Bibliograﬁa
[1] M. Lebedko, in Globalization, Networking and Intercultural Communication".
Intercultural Communication Studies., 2014.
[2] J. van Dijck, in The culture of connectivity: a critical history of social media, 2013.
[3] S. Obar, Jonathan A.; Wildman, in Social media deﬁnition and the governance challenge:
An introduction to the special issue, 2015.
[4] N. D. Gitari, Z. Zuping, H. Damien, and J. Long, “A lexicon-based approach for ha-
te speech detection,” International Journal of Multimedia and Ubiquitous Engineering,
vol. 10, no. 4, pp. 215–230, 2015.
[5] C. E. Ring, “Hate speech in social media: An exploration of the problem and its proposed
solutions,” in The culture of connectivity: a critical history of social media, 2013.
[6] C. C. Aggarwal, “An introduction to social network data analytics,” in Social network
data analytics. Springer, 2011, pp. 1–15.
[7] C. Xia, R. Schwartz, K. Xie, A. Krebs, A. Langdon, J. Ting, and M. Naaman, “Citybeat:
real-time social media visualization of hyper-local city data,” in Proceedings of the 23rd
International Conference on World Wide Web. ACM, 2014, pp. 167–170.
[8] N. Diakopoulos, M. Naaman, and F. Kivran-Swaine, “Diamonds in the rough: Social me-
dia visual analytics for journalistic inquiry,” in Visual Analytics Science and Technology
(VAST), 2010 IEEE Symposium on. IEEE, 2010, pp. 115–122.
[9] F. Sebastiani, in Machine learning in automated text categorization. surveys (CSUR),
2002, pp. vol. 34, no. 1, pp. 147.
[10] E. S. A. G. G. Sidorov, F. Velasquez and L. Chanona-Hernández, in Syntactic n-grams
as machine learning features for natural language processing, 2014, pp. vol. 41, no. 3,.
41

BIBLIOGRAFIA 42
[11] E. Cozzani, in Individuazione del linguaggio violento nei social network: il caso di studio
delle pagine Facebook, 2016.
[12] M. Friendly, in Milestones in the history of thematic cartography, statistical graphics, and
data visualization, 2008.
[13] C. K. Thomas, J., in Illuminating the Path: Research and Development Agenda for Visual
Analytics. IEEE-Press, 2005.
[14] P. H. Saldiva, C. A. Pope III, J. Schwartz, D. W. Dockery, A. J. Lichtenfels, J. M. Salge,
I. Barone, and G. M. Bohm, “Air pollution and mortality in elderly people: a time-series
study in sao paulo, brazil,” Archives of Environmental Health: An International Journal,
vol. 50, no. 2, pp. 159–163, 1995.
[15] N. R. Bates, A. F. Michaels, and A. H. Knap, “Seasonal and interannual variability of
oceanic carbon dioxide species at the us jgofs bermuda atlantic time-series study (bats)
site,” Deep Sea Research Part II: Topical Studies in Oceanography, vol. 43, no. 2, pp.
347–383, 1996.
[16] A. Ishigami, S. Hajat, R. S. Kovats, L. Bisanti, M. Rognoni, A. Russo, and A. Pal-
dy, “An ecological time-series study of heat-related mortality in three european cities,”
Environmental Health, vol. 7, no. 1, p. 1, 2008.
[17] J. D. Hamilton, Time series analysis. Princeton university press Princeton, 1994, vol. 2.
[18] X. Zhang and D. Shasha, “Better burst detection,” in 22nd International Conference on
Data Engineering (ICDE’06). IEEE, 2006, pp. 146–146.
[19] S. R. Mounce, A. J. Day, A. S. Wood, A. Khan, P. D. Widdop, and J. Machell, “A neural
network approach to burst detection,” Water science and technology, vol. 45, no. 4-5, pp.
237–246, 2002.
[20] S. Mounce, J. Boxall, and J. Machell, “Online application of ann and fuzzy logic system
for burst detection,” in Proceedings of the 10th International Water Distribution System
Analysis Conference, Kruger National Park, South Africa, vol. 1720, 2008.
[21] M. Vlachos, C. Meek, Z. Vagena, and D. Gunopulos, “Identifying similarities, periodi-
cities and bursts for online search queries,” in Proceedings of the 2004 ACM SIGMOD
international conference on Management of data. ACM, 2004, pp. 131–142.

BIBLIOGRAFIA 43
[22] G. Palshikar et al., “Simple algorithms for peak detection in time-series,” in Proc. 1st Int.
Conf. Advanced Data Analysis, Business Analytics and Intelligence, 2009, pp. 1–13.
[23] D. Misiunas, J. Vítkovsk`y, G. Olsson, A. Simpson, and M. Lambert, “Burst detection and
location in pipe networks using a continuous monitoring technique,” in 9th International
Conference on Pressure Surges, vol. 1, 2004, pp. 24–26.
[24] X. Zhang, “Fast algorithms for burst detection,” Ph.D. dissertation, Courant Institute of
Mathematical Sciences New York, 2006.
[25] J. Kleinberg, “Bursty and hierarchical structure in streams,” Data Mining and Knowledge
Discovery, vol. 7, no. 4, pp. 373–397, 2003.

Ringraziamenti
Ringrazio la mia famiglia per non avermi mai fatto mancare nulla. Ringrazio Fabio Del Vigna
per la disponibilità e l’aiuto nel realizzare questo lavoro. Ringrazio chi ha sempre creduto in
me e in particolare ringrazio Rambod Rahmani. In realtà volerlo ringraziare è l’unico motivo
per cui ho aggiunto la pagina "Ringraziamenti".
44

Bachelor thesis Calmanovici

Recommended

Recommended

More Related Content

Similar to Bachelor thesis Calmanovici

Similar to Bachelor thesis Calmanovici (20)

Recently uploaded

Recently uploaded (7)

Bachelor thesis Calmanovici