Progettazione di un sistema di simulazione per reti sociali

DIPARTIMENTO DI

FILOLOGIA, LETTERATURA E LINGUISTICA

CORSO DI LAUREA IN

INFORMATICA UMANISTICA

TESI DI LAUREA

Progettazione di un sistema di simulazione per reti sociali

CANDIDATO

Stefano Costanzo

RELATORE

Dott. Paolo Milazzo

CORRELATORE

Dott.ssa Giovanna Broccia

Ai miei genitori,

che più di chiunque altro

mi hanno sostenuto in questo percorso.

- 1 -

Indice

1. Introduzione ... 4

1.1. Abstract ... 5

1.2. Mission e obiettivi generali ... 7

1.3. Difficoltà e problematiche di approccio ... 9

1.4. Riferimenti online ... 11

2. Background ... 12

2.1. Reti, grafi e social ... 12

2.2. Un social network di rifermento: Twitter ... 16

2.2.1. TAGS e le Twitter API ... 19

2.3. Il sistema di simulazione agent based ... 21

2.4. La progettazione top-down e bottom-up ... 23

2.4.1. Dagli event log alle specifiche ... 24

3. Raccolta dati ... 26

3.1. Criteri e raccolta dati ... 26

3.2. Organizzazione ed elaborazione dati ... 31

3.2.1. Analisi statistica dei dataset ... 31

3.2.2. Liste di utenti e relazioni tra essi ... 33

3.2.3. Generazione del grafo ... 36

3.2.4. La rete interna ... 38

3.3. Dati raccolti ... 41

3.3.1. La composizione del dataset... 41

- 2 -

3.4. Osservazioni iniziali ... 45

3.4.1. Classificazione euristica delle tipologie di utenti ... 46

3.5. Script sviluppati ... 50

4. Modellazione utente ... 54

4.1. Calcolo delle probabilità ... 55

4.2. Esempio di calcolo senza categorie ... 59

4.3. Le categorie di utente ... 62

4.3.1. Indici di selezione categoria degli utenti ... 63

4.3.2. Il calcolo delle probabilità sulle categorie ... 68

4.4. Script sviluppati ... 70

5. Simulatore ... 72

5.1. Approccio ABS e la OOP ... 72

5.2. Costruzione del simulatore ... 75

5.2.1. Il costruttore di reti teoriche... 75

5.2.2. Il costruttore di reti reali ... 78

5.2.3. Le generazioni... 79

5.2.4. Il sistema di simulazione... 81

5.3. Simulazione senza categorie... 87

5.4. Simulazione con categorie ... 89

5.5. Processo di evoluzione attraverso i test ... 91

5.5.1. Alcune considerazioni sui risultati ... 99

5.6. Test di simulazione su casi notevoli ... 100

5.6.1. Test 1... 101

5.6.2. Test 2... 105

- 3 -

6. Test sulle reti ... 110

6.1. Test rete: #10agosto ... 111

6.2. Test rete: #11settembre ... 113

6.3. Test rete: #barcellona ... 115

6.4. Test rete: #buondimotta ... 117

6.5. Test rete: #GalaxyNote8 ... 119

6.6. Test rete: #tvdla5 ... 121

6.7. Test rete: #twittamibeautiful... 123

6.8. Test rete: #WhyImPoorIn4Words ... 125

6.9. Test rete: #Venezia74 ... 127

6.10 Considerazioni sui risultati ... 129

7. Conclusioni ... 132

8. Bibliografia e Sitografia ... 134

9. Indice delle figure ... 137

- 4 -

1. Introduzione

La moderna società ha visto nell’arco di pochi anni evolvere sensibilmente il proprio modo di comunicare: dai primi anni 2000 ad oggi vi è stata una radicale evoluzione nella diffusione delle informazioni. Basti pensare che all’inizio del millennio una connessione ad internet era alla stregua di un privilegio, mentre oggi possediamo tutta una serie di device che, privi di connessione al web, sono poco più utili di un fermacarte. Ne deriva una percezione assai diversa del mondo attorno a noi: le informazioni diventano “a portata di tap” e condividerle con il nostro gruppo di conoscenti (e non soltanto) è diventato quanto mai immediato e strutturato su scala sempre più vasta.

Nascono quelli che definiamo oggi social network: ambienti in cui è possibile ricreare una propria rete di conoscenze e condividere con esse pensieri personali, informazioni e qualsivoglia contenuto. Si è visto come tali reti abbiano avuto eco globale, connettendo persone e permettendo di condividere quantità di informazioni prima impensabili. Ne abbiamo esempi in quasi tutti i campi: partendo da quello pubblicitario che nei social ha trovato terreno fertile in cui evolversi, fino ad arrivare addirittura alla politica con propagande nate ed evolute attraverso la rete e i social.

Diventa quindi imprescindibile cominciare a osservare il mondo da questa prospettiva, evolvere gli studi in tale campo e prevedere i comportamenti presenti e futuri per organizzarsi e tentare di sfruttare al massimo questo enorme potenziale che la rete ci offre. Possiamo in qualche modo prevedere come un utente si comporta all’interno della sua rete di conoscenti? Osservare come i messaggi e le informazioni si diffondono in presenza di determinate caratteristiche?

Osservare il reale per cercare di ricrearlo in maniera artificiale in modo da analizzarne i comportamenti, al fine di comprendere come questo sistema d’interazione si comporta nel presente e quali sviluppi futuri potrà offrirci.

- 5 -

1.1. Abstract

L’elaborato si articola in maniera estremamente lineare, partendo dalle basi del lavoro e della raccolta dei dati ed evolvendo gradualmente nella spiegazione verso il modo in cui tali dati sono stati elaborati, sviluppati e infine utilizzati nella creazione del sistema di simulazione che rappresenta l’obiettivo ultimo di tutto il lavoro.

Il capitolo di background ci offre un breve presentazione degli argomenti teorici di cui è necessario possedere una minima conoscenza per capire al meglio come si articolano i processi che avverranno successivamente. Viene dedicata attenzione particolare al tipo di social scelto come fonte di informazione, le ragioni di tale scelta e quali sono le caratteristiche peculiari che verranno analizzate. Sono inoltre presenti riferimenti ai possibili approcci teorici e alla bibliografia essenziale utilizzata per gettare le fondamenta dei successivi ragionamenti.

Nella parte di raccolta dei dati osserviamo come è stato possibile ottenere le informazioni di partenza e come sono state elaborate inizialmente in dati utili alla costruzione del simulatore. Quindi non si tratta del semplice reperimento di alcuni messaggi ma dei processi teorici e informatici che hanno portato tali dati ad essere interpretati e “depurati” dalle informazioni accessorie. La fonte grezza dei messaggi trattati, di fatto, porta in se contenuti che eccedono le intenzioni di questo progetto e in qualche caso possono anche diventare fuorvianti per gli scopi finali.

La modellazione dell’utente è il cuore vero e proprio della ricerca svolta nel corso della creazione del simulatore. Prima di procedere a codificare algoritmi e processi che permettessero di ottenere dei risultati utili è assolutamente necessario comporre tutti i pezzi e capire come i nostri utenti debbano agire. Cerchiamo quindi di comprendere delle regole di comportamento, di apprendere dall’evoluzione della rete stessa e di bilanciare la territorialità delle singole entità: comportamenti derivanti dalla loro situazione sociale all’interno dell’intera struttura. Modellare significa in questo caso dare un volto a quelli che sono semplici oggetti di una rete, offrire un carattere e lasciare che sfoghino le proprie caratteristiche liberamente.

Nel capitolo dedicato al simulatore vero e proprio cercheremo di capire come i dati ottenuti e raffinati in precedenza possono aiutarci nella costruzione di un sistema di

- 6 -

simulazione che imiti quanto più possibile le caratteristiche strutturali e comportamentali di un set di reti reali. Osserviamo come tale processo non sia affatto scontato e come caratterizzare utenti in maniera verosimile rappresenti un importante punto di svolta in questo tipo di approccio. Sono inoltre presenti anche quelle tipologie di lavoro che hanno portato spesso a delle importanti revisioni del workflow per riuscire ad ottenere un risultato finale soddisfacente.

Nei test ci si occupa di riassumere come il simulatore abbia funzionato o meno relativamente alle reti prese in analisi. Il comportamento subisce determinate variazioni a seconda della tipologia di rete ed è importante che i test vengano ripetuti sempre ed espansi su un corpora di dati sempre più ampio. Naturalmente, tali risultati sono relativi ai soli dati presentati e vedono particolare interesse nei confronti di uno specifico esempio che viene utilizzato come linea guida per quanto concerne l’intero elaborato, al fine di tentare di descrivere al meglio e senza incongruenze l’intero processo che porta dai messaggi iniziali alle simulazioni alla fine.

Le conclusioni si pongono l’obiettivo di trarre le somme circa il lavoro svolto, di quali possono essere stati i limiti e quali invece siano le prospettive di sviluppo successivo di quanto trattato in queste pagine. Rappresentano quello che è a tutti gli effetti il nodo di congiunzione tra quanto realizzato effettivamente e quanto è possibile realizzare successivamente a quanto trattato.

- 7 -

1.2. Mission e obiettivi generali

Lo sviluppo di un progetto del genere ci pone di fronte a obiettivi ambiziosi ma al tempo stesso di non facile soluzione. Partendo dalla base di teoria delle reti, si toccano principi di simulazione, machine learning, data mining e così via. Tutta questa serie di competenze ci offre una vasta scelta di punti da trattare, tuttavia il tema trattato in questo elaborato deve avere un inizio e una conclusione.

L’inizio, se così possiamo definirlo, non ha un vero e proprio principio nel nulla: sono state formulate più ipotesi di lavoro e dalle conclusioni derivanti dalle simulazioni, dai sempre nuovi dati alla mano e dagli errori derivanti da alcuni generi di tentativi, si è giunti a quello che poteva essere il vero e proprio punto di partenza: un set di messaggi che costruisce la nostra base di informazione, dal quale ricavare le relazioni strutturali di una rete, da essa si partirà per ottenere un comportamento quanto più simile a quello ricavato dall’osservazione del reale.

A fianco del processo conclusivo, anche una serie di ipotesi di lavoro scartate dopo un’iniziale fase di selezione: inizialmente il lavoro si sarebbe dovuto concentrare anche con delle reti teoriche, create ad hoc attraverso dei noti algoritmi di costruzione. Si è deciso di mettere da parte tale idea per concentrarsi maggiormente nel trasporre una rete reale nel simulato, questo non vieta però di considerarlo come un futuro approccio e una possibile estensione di quanto tratta il presente elaborato. La maggiore difficoltà presentata nel passare dall’approccio “realistico” a quello puramente “teorico” si presenta nel caratterizzare la singola utenza, frutto di ragionamenti e processi di calcolo applicati a caratteristiche reali, non presenti in un mondo teorico che – appunto – parte da zero e non trova caratteristiche da imitare ma stimate in base a una più ampia visione di sistemi realistici. Lo studio presentato ha un approccio molto più basilare e non presenta un numero di casi sufficiente alla stesura di modelli teorici rigorosi; pur presentando un punto di partenza, è importante che l’intero processo di modellazione venga applicato su una quantità di dati molto più vasta e articolata per poi passare a teorizzare un sistema totalmente teorico.

Un lavoro quindi che nella sua semplicità di approccio risulta completo e si conclude su se stesso, in maniera rigorosa e con risultati più che incoraggianti ma che presenta assolutamente degli ampi margini di miglioramento sulla sua struttura stessa e di

- 8 -

estensione verso nuovi orizzonti che possono integrare il lavoro, oltre che – per certi versi – migliorarlo e renderlo maggiormente versatile.

Obiettivo finale di quanto viene trattato in seguito è quindi quello di analizzare, al meglio delle possibilità, le reti reperite da un noto sistema di social network, trarre alcune stime su quanto raccolto e costruire un sistema di simulazione che possa riprodurre il più fedelmente possibile i comportamenti osservati dalla fotografia della porzione di rete osservata. Bisogna fare attenzione a questo ultimo concetto: per fotografia si intende una finestra temporale ben precisa all’interno della quale vengono raccolte le informazioni, mentre con porzione consideriamo unicamente quella serie di utenti coinvolti nei processi che coinvolgono unicamente i dati raccolti.

Precisato come la rete sia limitata nello spazio e nel tempo, è possibile ricreare comportamenti interni e valutare come muoversi all’interno di piccoli mondi assestanti che si vengono a creare. Le reti reali – naturalmente – non sono universi isolati e scambiano informazioni con entità esterne ad esse, anche questo aspetto verrà preso in considerazione e poterà ad alcuni tipi di approccio che vogliono appunto contenere e quanto più isolare tali comportamenti. In sostanza l’obiettivo è quello di sintetizzare queste reti ai soli utenti che svolgono delle azioni al loro interno, filtrando in qualche modo tutti i comportamenti orientati verso porzioni spaziali esterni alla struttura della rete ottenuta attraverso il singolo dataset. La conseguenza è una netta riduzione della rete, imposta dallo scarto di quelle informazioni che possono in qualche modo inquinare il risultato finale non avendo diretta interazione con la nostra finestra di osservazione delle informazioni raccolte.

Non semplicemente un lavoro fine a se stesso ma un vero e proprio punto di partenza verso futuri sviluppi e implementazione che ne possano integrare la validità. Vi sono inoltre alcuni studi di partenza sull’argomento, che hanno costituito base fondamentale dell’approccio al lavoro; molti di essi concludono esattamente allo stesso modo, ipotizzando futuri sviluppi e approcci diversi, offrendo quanto sviluppato in prospettiva di successive analisi.

- 9 -

1.3. Difficoltà e problematiche di approccio

Condurre questo tipo di analisi su reti reali e da esse trarre dei dati che possano permettere la ricostruzione di un sistema di simulazione non è un’esperienza di lavoro banale. L’utente medio non è affatto “medio” come la sua definizione suggerisce: ogni fruitore dei social rappresenta un caso assestante e non è semplice assimilarlo a dei casi generici per poter costruire un sistema che sfrutti un approccio versatile.

Sorge quindi spontaneo pensare a quali siano state le difficoltà oggettive di approccio per questo tipo di lavoro. Il primis bisogna collocare certamente la raccolta dei dati e la successiva loro elaborazione: le quantità vanno scelte con cura, un sistema troppo piccolo rischia di non offrire una visione soddisfacente di quanto quella rete sia efficace nell’essere presa come esempio, dall’altra parte se vi è presente un numero eccessivo di informazioni si rischia che il lavoro diventi dispersivo e – dal punto di vista computazionale – di difficile gestione.

Pur esistendo varie tipologie di script già compilate e pronte per l’uso, si è deciso di svolgere questo lavoro utilizzando, fatta eccezione per TAGS, unicamente degli script originali, creati ad hoc per l’occasione. Tale approccio ha fatto certamente aumentare le tempistiche di lavoro, creando non poche problematiche a livello di gestione dei risultati emersi, sottoposti a varie revisioni per via di eventuali errori o incoerenze individuate in fasi successive all’interno un determinato processo.

Gli stessi strumenti utilizzati hanno posto dei limiti che purtroppo non potevano essere aggirato, come quello relativo alle API di Twitter limitanti le operazioni che è possibile svolgere nel corso di determinati archi temporali; in tal caso, l’unica via è rispettare tali limiti e cercare di gestire al meglio le tempistiche.

Ogni singolo aspetto ha in qualche moto presentato delle problematiche che sono state risolte attraverso i test e la revisione di alcuni aspetti del progetto; le stesse direzioni di sviluppo sono più volte variate alla luce di nuovi aspetti emersi nel corso dell’opera di definizione. Si è partiti con l’obiettivo di poter creare un simulatore che potesse in qualche modo porre anche l’attenzione in ambienti teorici e non solo nell’emulare prospettive reali; tuttavia tali ambizioni sono state ridimensionate dalla particolarità della caratterizzazione del singolo utente, relativa alla singola rete e non facilmente

- 10 -

generalizzabile con l’insieme limitato di informazioni alle quali abbiamo avuto accesso durante le fasi di progettazione. Ciò non esclude che tale progetto non possa essere continuato ed arricchito anche di questi aspetti.

Le fasi di testing del simulatore si sono rivelate spesso inconcludenti, specialmente nelle prime fasi del lavoro, portando di volta in volta a modifiche che ne hanno sempre più affinato le caratteristiche fino ad arrivare a un punto ritenuto soddisfacente per gli obiettivi posti. Le modifiche hanno comunque portato ad alterazioni sempre più sensibili, passando da risultati estremamente distanti da quelli posti come obiettivo fino a condizioni sempre più accettabili ma soggetti comunque a continue revisioni. Ultima, ma non meno importante precisazione è che il metodo di simulazione che andremo ad illustrare è progettato e applicato su dei dati reali raccolti in periodi relativamente brevi. In tali periodi si assume che il comportamento degli utenti – salvo dovute e sporadiche eccezioni – si mantenga costante. Di conseguenza, i risultati finali saranno valutati anche da questo punto di vista ed eventuali sviluppi futuri del metodo dovranno tener conto di questa premessa.

Nel complesso, seppur il lavoro possa sembrare nel suo complesso molto semplice e poco articolato attraverso le sue fasi, procedere nella simulazione di ambienti reali assume risvolti spesso inaspettati e incontrollati che possono essere risolti ma soltanto attraverso varie fasi di sperimentazione e confronto.

- 11 -

1.4. Riferimenti online

Tutti gli script e i codici utilizzati all’interno del progetto e sviluppati autonomamente, sia per quanto riguarda la parte di raccolta dei dati che la simulazione, sono reperibili presso il sito: Modelling, Simulation and Verification of Biological Systems (University of Pisa, 2018), gruppo di ricerca del dipartimento di Informatica dell’università di Pisa.

http://www.di.unipi.it/msvbio/software/SNS.html

Presso tale pagina – in lingua inglese – è possibile reperire, in formato compresso: - Collegamento alla tesi in formato digitale sul portale ETD dell’Università di Pisa; - Documentazione per l’utilizzo degli script presenti;

- I dataset utilizzati nella tesi e un esempio svolto di una rete;

- Gli script di modellazione utente e costruzione delle reti in linguaggio Python; - Il simulatore di reti sociali in linguaggio Java;

- 12 -

2. Background

Quanto segue si pone il semplice scopo di introdurre i concetti basilari della teoria applicata nella stesura del presente elaborato. Non si tratta di una visione esaustiva degli argomenti trattati ma di una sintesi del bagaglio necessario per affrontare quanto verrà trattato nei capitoli successivi. Prenderemo in considerazione i rudimenti di teoria delle reti e dell’approccio scelto per costruire il sistema di simulazione, frutto di documentazione riguardante gli articoli citati in bibliografia. Infine, alcuni cenni sul perché di determinate scelte sia concettuali che progettuali.

2.1. Reti, grafi e social

Molto spesso si crea confusione su cosa si intenda per reti sociali o, nella terminologia inglese più comune: social network. Visto il grande successo avvenuto nella prima decade del 21° secolo di servizi come Facebook, Twitter e così via, troppo spesso si cade nell’errore di assimilare la definizione di rete sociale a questi siti di enorme successo. Nella teoria delle reti, una rete sociale è appunto una società dove sono presenti degli individui che interagiscono tra di loro in maniera più o meno strutturata. Tale interazione può portare alla modifica del comportamento o della struttura stessa presente tra due o più individui; tale processo deriva dalla teoria dei grafi che, appunto, si pone l’obiettivo di analizzare il funzionamento dei sistemi complessi studiando come i componenti di tali sistemi interagiscono tra di loro. La teoria delle reti o dei grafi si occupa quindi di effettuare una “mappatura” delle reti e di misurare termini notevoli della sua natura; l’importanza di questo studio può essere percepita osservando come tali teorie siano applicate ai campi più disparati: dalla medicina all’economia, passando dall’informatica, l’antropologia e ovviamente la sociologia. Una rete può quindi essere assimilata a un elenco di componenti (nodi) che interagiscono in qualche modo tra di loro (tali interazioni sono definite come archi). Un esempio molto semplice di come una rete sociale può essere strutturata è il seguente: due nodi (che potremmo assimilare a due persone) interagiscono tra di loro (uno scambio di lettere, ad esempio); lo schema riassuntivo è quello che vediamo in Figura 1: il Nodo 1 è rappresentato appunto da un cerchio e ha la possibilità di

- 13 -

interagire con il Nodo 2, anch’esso un cerchio, tale possibilità di interazione è rappresentata da una semplice freccia che punta nella direzione dell’azione (per esempio: il Nodo 1 manda una lettera al Nodo 2). Allo stesso modo, il Nodo 2 ha la possibilità di interagire con il suo compagno, il tutto è rappresentato semplicemente con delle frecce.

FIGURA 1- ESEMPIO SEMPLIFICATO DI RETE

Il caso appena visto, rappresenta quanto di più semplice possa essere osservato tra le interazioni sociali; abbiamo però detto che si tratta di analisi che mirano allo studio di sistemi estremamente complessi. Se per definire una rete ci basiamo sul numero degli nodi e delle interazioni tra di essi (archi), allora possiamo dire che la rete in Figura 1 è costituita nella sua totalità da 2 Nodi e 2 archi. Il web, naturalmente, ha portato all’esasperazione il concetto di “rete sociale” negli ultimi anni, fornendo non soltanto delle interessanti piattaforme di comunicazione, ma veri e propri casi di studio a livello globale, disponibili in pochi clic (Barabasi, 2015).

Proviamo ad esempio di immaginare, seppur semplificando l’approccio, la rete costituita da tutti gli utenti presenti sul social Facebook e dalle interazioni tra di essi. Gli utenti attuali del social network sono circa 2,2 miliardi1, mentre ognuno di essi ha potenzialmente un massimo di 5000 amicizie possibili. Facendo un rapido conto, questa rete avrebbe qualcosa come 2,2 miliardi di nodi e (potenzialmente) qualcosa come 11.000 miliardi di archi.

Questi numeri ci fanno capire come le reti, specie con la diffusione capillare di internet, siano complesse e quanto mai importanti; 2,2 miliardi di persone sono un terzo della popolazione globale, riuscire a comprendere i meccanismi di interazione e

1 _{Dato comunicato il 25 Aprile 2018 dallo stesso Mark Zuckerberg sul suo profilo Facebook:}

- 14 -

comunicazione tra di essi rappresenta una ricchezza in termini di informazione senza pari. Come detto in precedenza, le reti sociali non devono essere assimilate ai soli siti web, tali teorie possono essere applicate a vari casi e situazioni: la diffusione di una malattia nell’Europa Medievale, la radicalizzazione religiosa all’interno di particolari comunità, le interazioni di un habitat animale all’interno di un ecosistema e così via. Non bisogna cadere quindi nella trappola dell’ambiguità creata dai social network negli ultimi anni: la rete sociale nasce come rete fisica e soltanto con gli sviluppi degli ultimi anni le metodologie si sono applicate all’ambito virtuale.

FIGURA 2-LA RETE DEGLI UTENTI FACEBOOK NEL 2010,PAUL BUTLER

Normalmente distinguiamo due tipi di grafo: quello diretto e quello indiretto. I nomi stessi suggeriscono la proprietà distintiva che ognuno di essi possiede, infatti in quelli diretti le interazioni vanno unicamente da un nodo all’altro (come una singola freccia del nostro esempio in Figura 1), mentre in quelli indiretti l’interazione e reciproca (nell’esempio avremmo potuto inserire un unico arco, senza verso). Esempio di rete diretta è lo stesso web, ogni collegamento ipertestuale rimanda con esattezza a una determinata pagina, ma dalla pagina non possiamo utilizzare lo stesso collegamento per tornare indietro; i colleghi di lavoro, invece, formano una rete indiretta: se Tizio lavora con Caio, di conseguenza anche Caio lavora con Tizio.

Infine occorre un’ulteriore misura molto importante per la valutazione delle reti. Si tratta del grado di un nodo. In maniera molto semplice, possiamo dire che il grado altro non è il numero di interazioni che un singolo nodo ha con altri nodi. Questo ci

- 15 -

offre un’indicazione di quanto l’entità presa in considerazione sia in contatto con la rete; in una rete indiretta conteremo semplicemente gli archi che arrivano ad esso, mentre per le reti dirette il grado sarà la somma di tutti gli archi entranti e di quelli uscenti. Utile strumento di valutazione della rete è appunto la media del grado dell’intera rete, che ci offre indicazione di quanto in media un singolo nodo sia connesso all’interno del nostro grafo (Barabasi, 2015).

Osservare la distribuzione del grado all’interno della rete ci permette di osservare e magari prevedere come l’informazione si diffonderà all’interno di determinate strutture di rete. Potremmo, ad esempio, individuare all’interno della popolazione quali sono le entità più influenti (con un grado più alto) e quali invece subiscono passivamente e si ritrovano maggiormente ai margini della rete. Tuttavia, bisogna ricordare che un singolo individuo possiede un limite intrinseco di interazioni con cui costituisce una rete sociale; nei primi anni ’90 l’antropologo britannico Dunbar studiò l’associazione tra la grandezza della corteccia celebrale e il numero di relazioni sociali stabili. Scoprì che tali relazioni sono comprese tra le 100 e le 200 unità; studi successivi misurarono che tale numero poteva essere stimato con 150, cifra che prese quindi il nome di Dunbar’s Number (Gonçalves, Perra, & Vespignani, 2013). Questo ci porta quindi ad avere, quantomeno, un’idea di che differenza vi possa essere tra una rete in cui compaiono migliaia di archi su un singolo nodo e quelle che effettivamente sono le interazioni reali dell’utente.

Esistono in oltre altre valutazioni e metodi molto più specifici di quanto descritto in questa essenziale introduzione, utile per esprimere al meglio concetti che verranno trattati in seguito nell’elaborato. In sintesi: definiremo una rete come un elenco di interazioni (L = numero di archi) tra una popolazione di entità (N = numero di nodi); le interazioni potranno essere dirette o indirette e contribuiranno a far crescere o meno il grado di un singolo nodo (con ki indichiamo il grado di un nodo i); la natura della rete e la sua struttura potranno essere studiate al meglio osservando come questo grado si distribuisce al suo interno (Barabasi, 2015).

- 16 -

2.2. Un social network di rifermento: Twitter

L’enciclopedia Treccani definisce un social network come segue: “Con l’espressione social network si identifica un servizio informatico on line che permette la realizzazione di reti sociali virtuali. Si tratta di siti internet o tecnologie che consentono agli utenti di condividere contenuti testuali, immagini, video e audio e di interagire tra loro. […] Il social networking costituisce oggi una delle forme più evolute di comunicazione on line e, anche se è pressoché impossibile fornire un numero complessivo, gli utenti sono in costante crescita.” (Istituto Treccani, 2018) L’esigenza di un confronto tra le situazione realistiche con i dati ricavati dagli event logs che possono essere simulati, mette di fronte all’esigenza di reperire grosse quantità di dati reali che possano costituire il cuore pulsante della ricerca e le fondamenta delle osservazione da cui partire per la costruzione di sistemi che tentino, quantomeno, di rispecchiare il più possibile il comportamento dell’utente. I social network risolvono a pieno questa esigenza, in quanto forniscono tutta una serie di vantaggi: un feedback in tempo reale delle informazioni, basso costo di reperimento e una quantità enorme di dati (Ikeda, Hattori, Ono, Asoh, & Higashino, 2013).

Per raccogliere una significativa quantità di dati si è scelto di porre l’attenzione sul popolare web service

Twitter, attivo dal 2006. La particolarità di questo social

è l’essere appunto essenziale nella sua struttura principale, si tratta infatti di un servizio di micro blog: ogni utente ha la possibilità di inserire un messaggio con del contenuto originale (tweet) con un limite di 140 caratteri (almeno nella sua versione originale). Alcuni utenti scrivono semplicemente quello che pensano, ma molte compagnie lo utilizzano per pubblicizzare il proprio brand e renderlo virale all’interno di gruppi di utenza mirati in maniera specifica (Java, Finin, Xiaodan, & Tseng, 2007) (Serrano, Iglesias, & Garijo, 2015).

All’interno di Twitter, un utente ha alcune azioni basilari di condivisione dei contenuti, che sono andate arricchendosi nel tempo. Tuttavia, la struttura principale è rimasta sostanzialmente la stessa, all’interno dell’elaborato ci occuperemo di osservare lo FIGURA 3-LOGO DI TWITTER

- 17 -

scambio basilare di informazioni tra gli utenti, mettendo da parte le funzioni multimediali aggiuntive inserite nel corso degli anni nella piattaforma.

L’utente ha la possibilità di creare un nuovo contenuto, un tweet. Questo tweet è composto principalmente da un messaggio testuale di 140 caratteri. Un tweet originale possiede il formato:

[additional text]

A sua volta un utente può interagire con altri utenti presenti nella sua rete di conoscenze principalmente in due modi: il retweet permette di replicare un tweet originale sulla propria bacheca, con riferimento all’autore, in tal caso il contenuto sarà esattamente lo stesso, ma nuovamente condiviso. Questo permette un’alta diffusione dell’informazione all’interno della rete. Un retweet appare normalmente con il seguente formato:

[additional text] RT @[account]: [original tweet]

Occorre precisare che, da una semplice osservazione dei dati elaborati, gli utenti si limitano a condividere semplicemente in contenuto e soltanto in casi molto rari arricchiscono il retweet con del testo addizionale (Yamaguchi, Takahashi, Amagasa, & Kitagawa, 2010). Il secondo modo di interagire con i tweet è la reply, con la quale un utente ha la possibilità di replicare direttamente a uno stato, per rispondere in qualche modo a un tweet di un determinato interesse (Kawamoto, 2013). La reply non possiede particolarità nel formato, se non un riferimento all’utente del tweet a cui si risponde:

@[account] [additional text]

Dall’osservazione del comportamento su alcuni campioni di dati, messa da parte la produzione originale dei tweet da parte degli utenti che risulta necessaria all’inserimento dell’informazione all’interno della rete, vi è una produzione di retweet assai maggiore rispetto alle reply (Bongwon, Lichan, Pirolli, & Chi, 2010). L’utente medio tende quindi a impacchettare l’informazione e a diffonderla come fosse propria, senza però aggiungere alcun tipo di messaggio se non quello intrinseco del tweet originale (Herbrich, Stern, Van Gael, & Zaman, 2010) (Bongwon, Lichan, Pirolli, & Chi, 2010) (Yamaguchi, Takahashi, Amagasa, & Kitagawa, 2010).

- 18 -

A tal proposito, uno studio molto interessante è quello di (Yamaguchi, Takahashi, Amagasa, & Kitagawa, 2010), i cui concretizza il comportamento medio degli utenti suddividendoli in due grandi macro-categorie: da una parte abbiamo gli Information Source, gli utenti che producono materiale utile e originale, che tendono ad avere un alto numero di follower; dall’altra parte troviamo gli Information Seeker, una categoria che raramente inserisce del contenuto originale ma segue un altissimo numero di altri utenti per reperire materiale interessante. Abbiamo quindi una prima grande distinzione tra chi produce del materiale originale e chi invece lo “utilizza” in qualche modo, non soltanto consultandolo, ma diffondendolo attraverso gli strumenti che il social offre.

A livello strutturale invece le relazioni tra utenti sono molto semplici: esse formano un grafo diretto. Supponiamo di avere un utente A che segue gli aggiornamenti di un utente B. Diremo in questo caso che l’utente A è un follower di B (ma non necessariamente il contrario). L’utente B è invece un following di A, ovvero un utente che A segue. Quindi un utente con molti follower è un utente con un grosso seguito di persone che ne seguono gli aggiornamenti, mentre un alto numero di following implica il fatto che l’utente segua a sua volta un grosso numero di aggiornamenti di stato. Nulla vieta inoltre di essere reciprocamente follower, seguendo a vicenda i propri aggiornamenti (Huberman, Romero, & Wu, 2008). Nei casi analizzati, vi erano alcuni profili con milioni di follower corrispondenti a importanti testate giornalistiche, fonte di informazione per un buon numero di sotto-reti prese in analisi.

Molto importante nella diffusione dell’informazione, soprattutto riguardo la raccolta dati che prenderemo in considerazione più avanti, è la presenza – ormai massiccia e di grande rilievo commerciale – dei cosiddetti hashtag. Gli hashtag sono delle vere e proprie etichette con cui i messaggi, i tweet, possono essere etichettati; si tratta di parole o combinazioni di parole concatenate, precedute dal simbolo cancelletto (#). Quando un hashtag viene inserito all’interno di un messaggio, si crea un collegamento ipertestuale che rimanda a tutti i messaggi più recenti che contengono la medesima sequenza di caratteri con in testa il cancelletto. Questo permette quindi di effettuare ricerche tematiche e di individuare facilmente quali siano le tendenze di una rete o di una porzione di essa, identificando specifici argomenti ad essi correlati (Counts & Yang, 2010).

- 19 -

La scelta di utilizzare proprio Twitter per la raccolta dei dati è dovuta, in prima battuta alla semplicità della struttura di rete, essa ci permette infatti di ricostruire in maniera efficace le reti minime di cui abbiamo bisogno per le successive analisi. Infatti, i suoi oltre 330 milioni di utenti2, producono una grossa quantità di informazioni che possono essere classificate e sfruttate nella ricerca; tali informazioni sono inoltre pubbliche (salvo specifici casi) e possono essere facilmente reperite attraverso API che la stessa azienda distribuisce attraverso i propri canali ufficiali. Abbiamo inoltre visto la semplicità dei messaggi che il micro blogging genera, questo ci permette di approcciarci a questa rete sociale senza però considerare un tipo di interazione complessa ed eccessivamente articolata (Serrano, Iglesias, & Garijo, 2015) (Yamaguchi, Takahashi, Amagasa, & Kitagawa, 2010).

2.2.1. TAGS e le Twitter API

Una delle ragioni fondanti per cui viene utilizzato Twitter per reperire i dati è la semplicità di ottenerli attraverso delle librerie software che la stessa azienda fornisce per l’esplorazione dei suo database, pubblici salvo che per alcune eccezioni. In particolare, è importante ricordare come è stato possibile ottenere i dati necessari attraverso l’utilizzo di software online basati proprio sull’utilizzo di queste API. In prima battuta, il software di raccolta dei dati che abbiamo utilizzato è stato TAGS (Hawksey, 2018); tale software risulta molto semplice, ma al tempo stesso efficace: si basa sulle API Twitter e i Google Spreadsheet. Inserendo delle chiavi di ricerca o degli hashtag è possibile reperire attraverso di esso i tweet relativi in un certo arco di tempo specificato. Il tutto viene ordinato in tabelle ed esportato in formato csv (comma-separated values), ovvero in valori separati da virgola che possono essere approcciati attraverso un semplice foglio elettronico o degli specifici script che vedremo successivamente. I dati presenti nelle tabelle esportate sono molteplici e scendono quanto più possibile nel dettaglio del singolo tweet, sviscerandolo delle informazioni

2 _{Dato comunicato il 26 Ottobre 2017 dalla stessa azienda in un comunicato ufficiale:}

http://files.shareholder.com/downloads/AMDA-2F526X/5470665732x0x961127/658476E7-9D8B-4B17-BE5D-B77034D21FCE/TWTR_Q3_17_Earnings_Press_Release.pdf

- 20 -

pubbliche che esso trasporta; vedremo in seguito anche degli esempi del tipo di dati raccolti attraverso questa applicazione. Bisogna comunque precisare che, seppur presenti, molte informazioni risultano poco utili ai fini del lavoro che andremo a considerare, se non addirittura frammentarie, come ad esempio la presenza di coordinate geografiche di un tweet, vanificate dalla geo localizzazione non attiva dell’utente che lo ha generato; quindi un serie di caselle nulle.

Le Twitter API (Twitter, 2018) sono righe di codice, librerie e servizi online messi a disposizione degli utenti di Twitter registrati al social come sviluppatori. Esse permettono di accedere – previo login – ai database della piattaforma e reperirne le informazioni necessarie. Tuttavia, per non eccedere con il traffico di dati, sono presenti anche importanti limitazioni che, pur non interrompendo, rallentano sensibilmente l’utilizzo degli script basati su questa tecnologia. Esistono vari tipi di applicazioni, messe a disposizione dall’azienda, che lavorano attraverso l’utilizzo di queste API, il che rende Twitter attiva nella promozione e realizzazione di un gran numero di progetti Open Source.

- 21 -

2.3. Il sistema di simulazione agent based

Un Agent Based Model (ABS), tradotto letteralmente come modello basato su agenti, è un modello computazionale di simulazione e interazione tra entità autonome (gli agenti, appunto). Le entità che costituiscono gli agenti del modello possono essere individuali o collettive, secondo quanto prevede l’organizzazione del sistema che andiamo a simulare attraverso questo approccio.

Il risultato di una simulazione del genere su un sistema (reale o teorico che sia) è una valutazione di come tali agenti si comportino nella complessità della loro struttura e come possono evolvere le proprie azioni sulla base di eventi singoli che condizionano però il sistema nella sua interezza.

Si tratta di una disciplina le cui competenze sono molto varie e articolate, il che permette di utilizzarla anche nell’ambito di interesse che investe questo elaborato: le reti sociali. Introducendo infatti un sistema di casualità all’interno dei nostri agenti, è possibile assimilare quest’ultimi al comportamento individuale dell’utente all’interno di una rete della quale fa parte. L’approccio ABS si pone quindi lo scopo di individuare un comportamento quanto più realistico dell’agente, cercando appunto di comprenderne le evoluzioni e non di progettare automi che si comportino alla perfezione all’interno dell’ambito ricercato (Barnes & Chu, 2015).

Ci troviamo quindi di fronte alla simulazione di interazioni semplici, tra piccoli gruppi di agenti che, analizzati in micro-scala, vengono simulati su azioni semplici ed essenziali. Il tutto avviene però simultaneamente all’interno della rete, questo ci porta a ricreare, o addirittura a prevedere, il comportamento dell’intera rete complessa. Il modello risponde quindi ad alcune caratteristiche fondamentali nella sua progettazione, comuni alla maggioranza dei modelli:

1. Gli agenti – sono appunto gli attori della nostra simulazione, ogni agente o gruppo di agenti presenta delle determinate caratteristiche che ne distinguono il comportamento;

2. Euristiche decisionali – il sistema di strategie, tecniche e procedimenti che vengono attuate per far svolgere il comportamento agli agenti, le regole secondo le quali un agente prende una determinata decisione;

- 22 -

3. Regole di apprendimento o processi adattivi – i processi secondo i quali un agente può evolvere e modificare i propri comportamenti, adattandoli a determinate caratteristiche che il sistema assume;

4. Topologia di interazione – si tratta della struttura stessa della rete che definisce come gli agenti interagiscono tra di loro;

5. Ambiente – l’ambiente dentro il quale gli agenti interagiscono tra di loro, un ambiente semplice impone dinamiche semplici, mentre ambienti più complessi portano ad azioni sempre più complesse. La stessa posizione spaziale degli agenti e l’organizzazione con i vicini può influenzare questo comportamento; Queste caratteristiche permettono di formare l’interazione dinamica tra i nostri agenti creando determinate complessità che possono anche rispecchiare quella del mondo reale. Questi modelli, in qualche modo, seppur non esprimano direttamente come generare gli equilibri di un sistema, sembrano generare e obbedire a tali equilibri, assumendo comportamenti ben definiti. La simulazione può far emergere modelli interni e spiegarne l’insorgere, identificandone la leva e il funzionamento distinguendo tra i percorsi che possono o potrebbero seguire. Bisogna inoltre considerare l’alta robustezza di questi sistemi che, anche se soggetti a forti pressioni di cambiamento dall’interno e dall’esterno, mantengono le funzionalità degli agenti senza alterarne in maniera incontrollata il comportamento.

Comprendere come i fenomeni sociali si diffondano in una rete, predire eventuali comportamenti e formulare delle ipotesi circa la diffusione dell’informazione all’interno di una certa popolazione, sono soltanto alcune delle caratteristiche che l’ABS offrono per l’approccio di studio alle reti sociali. Per quanto riguarda l’elaborato e le sperimentazioni di cui parleremo nei capitoli successivi, il sistema verrà utilizzato come base per l’implementazione di un simulatore che permetterà di far agire una rete secondo comportamenti ben definiti di agenti (in questo caso, veri e propri utenti) osservati e analizzati in reti reali.

- 23 -

2.4. La progettazione top-down e bottom-up

La progettazione top-down e bottom-up sono due metodologie di approccio utilizzate per l’elaborazione e la gestione dell’informazione all’interno di sistemi complessi. Permettono di analizzare situazioni complesse formulando le ipotesi più adatte alla risoluzione del caso specifico (Demetrescu, Finocchi, & Italiano, 2008).

Nel modello top-down si procede partendo, appunto, dall’alto. Ci si basa su una visione generale del sistema, senza scendere però nei dettagli delle parti specifiche. Le singole parti del sistema sono poi prese in analisi e definite nel dettaglio, scendendo via via nella complessità delle sue parti. Ognuna di queste parti può essere a sua volta approcciata come all’inizio, ripetendo il processo, fin quando non si raggiunge il livello di dettaglio desiderato. Per la progettazione si ricorre spesso ad un modello “a scatole” che permette di riassumere le varie parti in sistemi chiusi senza scendere nel dettaglio della progettazione dei singoli elementi. Il nome significa letteralmente “dall’alto verso il basso” e si pone l’obiettivo di partire dall’obiettivo generico, scendendo di complessità per costruirne le fondamenta che lo costruiscono (Sabatier, 1986).

In contrasto al primo approccio, troviamo il modello bottom-up nel quale si pensa a definire le parti più elementari nel dettaglio, per poi connetterle successivamente tra di loro per realizzare il sistema nella sua complessità. Tale strategia risulta efficace anche a partire dai risultati finali delle operazioni che il sistema gestisce: da essi è possibile ricostruire le parti ultime che li hanno generati, per poi risalire all’organizzazione generica in testa. Inoltre, conoscendo le variabili di comportamento specifico delle parti, è possibile definire al meglio il sistema completo, in quanto ne conosciamo al meglio i dettagli che possono influenzarne il comportamento (Sabatier, 1986).

Nella funzione specifica che questo testo si pone di sviluppare, il dato di partenza sono appunto le raccolte di informazioni del comportamento di una rete reale; da essi ci si pone l’obiettivo di ricostruire “a ritroso” un sistema di simulazione che possa definire i meccanismi che li hanno generati. Ecco perché è quanto mai indispensabile procedere con l’approccio bottom-up a partire dalla raccolta delle informazioni per ricostruire il sistema che intessa queste pagine.

- 24 -

2.4.1. Dagli event log alle specifiche

I moderni sistemi informatici, così diffusi ormai nel globo, dietro ai numerosi servizi offerti nei campi più disparati, producono una vera e propria miniera di informazioni. L’utente nel corso dell’utilizzo di tali sistemi producono delle informazioni che prendono il nome di event logs. Esistono processi che si pongono lo scopo di offrire una serie di tecniche orientate all’analisi delle informazioni contenute in queste raccolte per risalire alle meccaniche, ai dati, all’organizzazione e alle strutture che tali azioni possono aver costruito nel corso del loro ciclo di vita. Vi è una branchia specifica, quella del process mining, che si occupa di definire tali processi per rendere automatico risalire alle specifiche che ne costituiscono le fondamenta. Per quanto riguarda il lavoro di cui parleremo, il process mining rappresenta semplicemente una fase di ispirazione che non verrà resa nella sua integrità (Aalsta, Reijersa, Weijtersa, & Dongena, 2007).

Un event log, nello specifico, contiene tipicamente delle informazioni circa delle specifiche activity e dei case. Un activity, anche chiamato task, è l’operazione vera e propria che viene svolta sullo specifico case, l’oggetto preso in considerazione. Tali eventi hanno impressa, al loro interno, la data e l’ora esatta della loro occorrenza. Inoltre, se presente, gli eventi possono contenere informazioni circa la persona che esegue o inizializza l’evento, in questo caso chiamiamo questo utilizzatore performer. Bisogna quindi considerare tre fattori: 1) La prospettiva del processo (How?), 2) La prospettiva organizzativa (Who?), 3) La prospettiva del caso (What?). Un esempio estremamene semplificato di come un event log generico può presentarsi all’analista è dato dalla seguente tabella che rappresenta alcune attività ipotetiche degli operatori (Aalsta, Reijersa, Weijtersa, & Dongena, 2007).

Case id Activity id Originator Timestamp

Case 1 Activity A John 9-3-2004: 15.01

Case 2 Activity B John 9-3-2004: 15.12

Case 3 Activity B Sue 9-3-2004: 16.03

Case 4 Activity C Carol 9-3-2004: 16.07

- 25 -

L’esigenza di un’analisi sempre più accurata e specifica di questi event log dipende dalla necessità quanto mai di primaria importanza del monitorare le attività commerciali in maniera più viscerale possibile. Attraverso essi è possibile non solo monitorare tali attività, ma gestirle e soprattutto svolgere un lavoro di “intelligence” per migliorare l’efficienza dei processi coinvolti.

Ci si pone quindi lo scopo di implementare la costruzione di modelli, per quanto più possibile automatici, che spieghino le dinamiche osservate dall’analisi dei dati; una prospettiva promettente che, tuttavia, al momento vive una fase di sviluppo e non considera – ad esempio – situazioni pratiche come la difficoltà di esecuzione di una activity e le eccezioni; tali situazioni devono essere gestite in maniera manuale, essendo appunto imprevedibili. Diventa quindi molto importante, al fine di un corretto approccio, mettere a confronto situazioni realistiche delle applicazioni con i dati ricavati dall’analisi degli event logs; un confronto tra questi due approcci rappresenta un buon punto iniziale per concepire modelli quanto più efficaci.

- 26 -

3. Raccolta dati

In questo capitolo introdurremo i criteri e metodi con cui è avvenuta la raccolta dati, utile al fine di racimolare le informazioni minime da cui partire per la costruzione del simulatore. Come affermato precedentemente, approcciandoci al problema in modo bottom-up e ispirando tale percorso ad una forma meno rigorosa di process mining, abbiamo bisogno di una cospicua libreria di dati di partenza, che sarà successivamente lavorata e adattata secondo le esigenze richieste. Questa fase non si articola quindi in una mera raccolta di testi ordinati, ma in un’analisi critica di informazioni catalogate e ordinate secondo ben specifici criteri.

3.1. Criteri e raccolta dati

Attraverso la versione 6.1.2 di TAGS è stato possibile reperire i dati necessari per cominciare a lavorare sull’argomento. L’idea è quella di raccogliere gruppi di tweet inerenti allo stesso argomento; per raggruppare queste informazioni si è scelto di utilizzare come criterio di ricerca un certo hashtag, scelto tra quelli che Twitter suggerisce e sono – di conseguenza – maggiormente in voga in un certo periodo.

- 27 -

TAGS è un Google Sheet Template free, che ci permette di reperire in automatico le collezioni dei risultati di ricerca impostati sulla sua interfaccia. Il funzionamento è molto semplice: è sufficiente copiare il documento disponibile sul sito web indicato all’interno del proprio Google Drive; si esegue il Setup per inserire le API Key richieste e si è pronti per immettere una nuova chiave di ricerca, il risultato è un foglio Excel con tutti i tweet che ci interessano, in Figura 4 vediamo come appare l’interfaccia. L’archivio generato, secondo le impostazioni di default dello script, è aggiornato ogni ora. I parametri impostabili sono i seguenti:

 Enter term (termine di ricerca) – la parola chiave attraverso la quale è possibile cominciare la ricerca vera a propria, accetta operatori come AND, OR, well e from. Nel nostro caso è stata utilizzata per la ricerca di hashtag semplici;

 Period (periodo) – è la fascia di tempo all’interno della quale eseguire la ricerca, può essere impostata a ritroso fino a 7 giorni;

 Follower count filter (filtro di conteggio dei follower) – è il numero minimo di follower che un utente deve possedere per soddisfare i criteri di ricerca, utile per filtrare a monte utenti falsi che provocano unicamente spam;

 Number of tweets (numero dei tweet) – il massimo numero di tweet ricercabili per ogni singolo utente, relativi alla chiave di ricerca, utile anche in questo caso per limitare i risultati, soprattutto se inquinati dallo spam;  Type (tipo di ricerca) – si divide in tre possibili opzioni:

o Search/tweets – utilizza una parola chiave (il termine di ricerca) per ottenere risultati fino agli ultimi 7 giorni di attività;

o Favorites/list – utilizza un nome utente (come termine di ricerca) per ottenere la lista dei tweet che sono stati segnati come “preferiti” da quesst’ultimo;

o Statuses/user_timeline – utilizza un nome utente (come termine di ricerca) per estrarre gli aggiornamenti di stato;

Diventa quindi possibile destreggiarsi tra i vari parametri per ottenere archivi di dati quanto più adatti al tipo di ricerca che si intende effettuare. Il prodotto di tale processo è un foglio “Archive” che si aggiunge allo spazio di lavoro del Google Sheet,

- 28 -

all’interno del quale i dati sono organizzati con un record per ogni riga, i valori degli attributi sono invece distribuiti sule colonne. L’aspetto dei risultati è riassunto in Figura 5, possono esservi naturalmente applicati tutti i filtri messi a disposizione dallo stesso Google Sheet, per osservare al meglio il primo impatto sulle informazioni e concentrarsi sugli aspetti più interessanti.

FIGURA 5-ESEMPIO DI COME APPAIONO I DATI RACCOLTI

Le caratteristiche presenti sono molteplici, ma non necessariamente del tutto utili; alcuni degli attributi, in effetti, sono nulli per via delle impostazioni fisiche degli utenti che creano il contenuto (ad esempio la geo localizzazione), altre sono importanti a fine puramente statistico. Sono stati inizialmente reperiti alcuni gruppi di questi dati e successivamente si è proceduto alle analisi vere e proprie; i criteri di ricerca sono stati essenzialmente quelli di default, ma si è scelto di reperire insiemi di grandezza diversa per quanto riguarda il numero dei tweet presenti all’interno, rimanendo comunque tra le poche centinaia e non oltre i 15.000 record.

Osserviamo quindi come un esempio di record appare una volta reperite tutte le informazioni e quali sono i significati che possiedono le singole colonne. Per questo esempio, e per altri che seguiranno, attingeremo al database riguardante l’hashtag #10agosto, reperito appunto nell’Agosto 2017. Il tutto è riassunto nella seguente tabella. Questo al fine di offrire una maggiore continuità di comprensione del processo di lavoro che porta alla raffinazione e al conseguente utilizzo dei dati.

- 29 -

Attributo Esempio Significato

id_str 895623418711728130 ID univoco del tweet preso in

considerazione

from_user gcedeo

Nome utente o screen-name, scelto dallo stesso, si indentifica con la @ text @GolpeAGolpe3 con @faustomaso y @ftovar432 del #10Agosto https://t.co/Y7CW5ZRXnp vía @YouTube

La stringa di testo del tweet generato dall’utente, contiene l’hashtag utilizzato come chiave di ricerca

created_at Thu Aug 10 12:30:37 +0000 ₂₀₁₇ Data e ora della creazione tweet

time 10/08/2017 13:30:37 Data e ora della pubblicazione del

tweet

geo_coordinates null Le coordinate geografiche del

Tweet

user_lang Es La lingua dell’utente

in_reply_to_user_id_str 793902144 ID dell’utente al quale il

generatore del tweet risponde

in_reply_to_screen_name Golpeagolpe3 Screen-name al quale il

generatore del tweet risponde

from_user_id_str 148341196 ID dell’utente che ha generato il

tweet

in_reply_to_status_id_str Null ID del tweet al quale l’utente ha

risposto source <a href="http://twitter.com" rel="nofollow">Twitter Web Client</a> Stringa HTML contenente informazioni sul supporto attraverso il quale l’utente ha generato il tweet

- 30 -

profile_image_url

http://pbs.twimg.com/profile_i mages/438123047602507776/ rKpn1jmn_normal.jpeg

URL dell’immagine del profilo dell’utente che ha generato il tweet

user_followers_count 899 Numero di follower dell’utente

user_friends_count 1990 Numero di following dell’utente

status_url http://twitter.com/gcedeo/statu_{ses/895623418711728130} URL diretto al tweet preso in _{considerazione}

entities_str {"hashtags":[{"text":"10Agosto","indi ces":[47,56]}],"symbols":[],"user_me ntions":[{"screen_name":"Golpeagol pe3","name":"Golpeagolpe","id":793 902144,"id_str":"793902144","indice s":[0,13]},{"screen_name":"faustoma so","name":"Fausto Maso","id":284115156,"id_str":"284 115156","indices":[18,29]},{"screen_ name":"ftovar432","name":"Fran Tovar","id":321466934,"id_str":"321 466934","indices":[32,42]},{"screen_ name":"YouTube","name":"YouTube" ,"id":10228272,"id_str":"10228272"," indices":[85,93]}],"urls":[{"url":"http s://t.co/Y7CW5ZRXnp","expanded_url ":"https://youtu.be/o1mXPhZAFNA"," display_url":"youtu.be/o1mXPhZAFN A","indices":[57,80]}]}

Entità che aggiunge al tweet dei metadata di vario genere

- 31 -

3.2. Organizzazione ed elaborazione dati

Come primo passo è necessario effettuare le prime operazioni di pulizia, analisi e creazione dei grafi a partire dalle reti. Per scelta progettuale, si procede per molti passi, in modo da frammentare maggiormente i passaggi e – di conseguenza – avere un maggior controllo delle fasi intermedie di elaborazione.

3.2.1. Analisi statistica dei dataset

Una volta reperita una certa quantità di dati, ritenuta sufficiente per effettuare le prime verifiche e analisi, si procede a organizzarli e a fare le prime analisi – principalmente statistiche – su di essi. Attraverso lo script AnalisiDataset.py è stato possibile ottenere un primo dato informativo sui database reperiti. Il modo migliore di osservarne il funzionamento è quello di fare un esempio di risultati; per fare ciò prenderemo in considerazione tre dataset scaricati attraverso TAGS di dimensioni diverse: data#Bankitalia (Piccolo – 928 Tweet), data#12luglio (Medio – 2.297 Tweet) e data#HarryUsesHappinessNotGender (Grande – 16.696 Tweet). Nel dare in elaborazione allo script questi archivi, abbiamo ottenuto i seguenti risultati:

data#Bankitalia data#12luglio data#HarryUsesHap pinessNotGender # tweet TOT 928 2.297 16.696 # RTweet 694 (74.78%) 1.381 (60.12 %) 12.906 (77,3%) # tweet originali 234 (25.22%) 916 (39.88 %) 3.790 (22,7%) # reply 12 (1.29%) 31 (1.35 %) 169 (1,01%) @ Utenti TOT 512 1.729 3.531

@ max tweet UfficioStampaBI (53 -

- 32 -

@ max retweet FabQuintiliani (9 - 0.97%) CasaLettori (15 - 0.65%) styljnsovl (208 - 1,25%)

@ reply fatte silvionicolini (5 - 0.54%) scrivolandia ( 8 - 0.35%) KingHStylespics (22 - 0.13%)

@ reply subite silvionicolini ( 4 - 0.43%) BeaLorenzin (2 - 0.09%) Harry_Styles (42 - 0.25%)

@ most

follower repubblica (2.711.082) SkyTG24 (2.870.836) melano_comestai (66.647)

@ most

following SpazioEconomia (43.326) S_Galimberti (90.929) melano_comestai (66.532)

Tot Follower 8.967.452 32.012.153 25.576.791

Avg Follower 17.514,55 18.514,84 7.243,5

Tot Following 1.498.432 4.317.984 21.293.783

Avg Following 2.926,63 2.497.39 6.030,52

Come si può osservare già a primo impatto, quello che risalta subito agli occhi è il come gli utenti si comportino in modo pressoché simile, pur trattandosi di argomenti molto diversi tra loro (e con dimensioni diverse dei dati di raccolta).

Vediamo quindi che la tendenza è di effettuare molti retweet a scapito dei contenuti originali: i primi rappresentano in buona parte dei casi i 2/3 dell’insieme raccolto, mentre i contenuti prodotti da zero, sono il rimanente terzo; le reply sono invece uno strumento utilizzato in scala molto minore. Si vede pure come i contenuti originali siano una prerogativa di un ristretto numero di utenti, che produce buona parte di essi, mentre i retweet e le reply sono maggiormente distribuite all’interno dell’insieme di utenti appartenenti alla rete in analisi. Le ulteriori statistiche ci suggeriscono come vi siano utenti con un altissimo numero di follower (tendenzialmente testate giornalistiche o personaggi pubblici) che rappresentano dei veri e propri hub di informazione, mentre l’utente più “medio” tende a seguire molto piuttosto che ad

- 33 -

essere seguito. Altro dato importante è il confronto tra i follower totali e i following totali: in sostanza vi è più gente seguita che gente che segue.

Pur sembrando osservazioni assai banali, questi dati risultano di vitale importanza per l’implementazione di una simulazione efficace. Ad esempio, osserviamo come l’utenza tenda più a condividere che a creare informazioni, come vi sia una maggiore efficacia di determinati personaggi nel trasmettere dei messaggi e – soprattutto – come la rete si possa costruire in maniera più semplice a partire dai rapporti di following, piuttosto che dai seguaci di un determinato utente; vedremo in seguito come questa piccola differenza possa diventare fondamentale nel corso delle analisi.

3.2.2. Liste di utenti e relazioni tra essi

Completata la prima fase di analisi statistica dei dataset presi in considerazione è il momento di ottenere quelli che sono i dati sensibili, utili per la costruzione simulatore, non soltanto nella sua struttura, quanto nei parametri di impostazione che ne influenzano decisioni e scelte.

Come prima fase utilizziamo lo script gen_uteList.py per generare la lista degli utenti, il compito è molto semplice ed essenziale: generare una lista alfabetica di tutti gli utenti presenti all’interno della nostra raccolta di tweet che andranno a costituire il cuore pulsante della nostra rete, i nodi. A fianco di tale lista, vengono anche visualizzati alcuni valori statistici, il tutto viene riassunto successivamente in tabella; in fase di costruzione della nostra rete, il punto cardine è appunto possedere una lista di utenti. A fianco della lista di utenti, così com’è, utilizziamo lo script gen_ute_id.py per generare una lista di utenti dove però essi risultano accoppiati con il proprio ID univoco presente su Twitter. Questo ci permette di possedere in qualunque momento una lista di tutti gli utenti sia con il proprio screen-name, sia con il proprio id secondo delle coppie [screen-name; id]. Sempre citando il dataset #10agosto otterremo, ad esempio, campioni di utenti del tipo:

ASR_Goalmania;1706594336 AeroportoPa;2411624330 BramucciMatteo;2753421268

- 34 -

Mentre le prime fasi di lavoro la computazione dei dati è avvenuta localmente, semplicemente operando sui dati reperiti attraverso TAGS, per proseguire nella raccolta di dettagli è necessario fare un ulteriore passo in avanti e cercare ulteriori informazioni su ogni singolo utente. Di fatto, la computazione in locale, una volta compilati gli script è risultata assai veloce, ma basata su una raccolta di informazioni essenziale e limitativa.

3.2.2.1. Le problematiche di reperibilità dei follower

Nasce quindi quella che risulta la fase più delicata del lavoro di raccolta ed elaborazione dei dati, la raccolta dei follower o dei following di ogni singolo utente. Attraverso lo script download_follower.py è possibile, partendo dalla lista di utenti generata, scaricare la rispettiva lista di follower di un singolo utente ed esprimerla nella forma che segue:

screenname[id1, id2, id3, … idn]

Dove lo screen-name rappresenta l’utente presente nella nostra lista generata in partenza, mentre gli ID sono tutte le identità dei suoi follower, reperite direttamente sui server di Twitter. Pur trattandosi di un risultato molto semplice e immediato, riassumibile in qualche migliaio di righe di testo, si tratta di un punto assai critico della procedura di costruzione della nostra rete; infatti è l’unica informazione che possediamo per la ricostruzione delle interazioni tra i singoli utenti.

Costruire questa lista ha creato non pochi problemi nell’economia di tempistiche e gestione degli script. Questo deriva dalle limitazioni3 che le API di Twitter impongono agli sviluppatori per evitare di intasare i server con richieste eccessive. In sostanza, è possibile effettuare un massimo di 15 call per ogni finestra di connessione, raggiunto tale limite il sistema deve rimanere 15 minuti in pausa prima di poter interrogare

- 35 -

nuovamente il database. Ulteriore limitazione è la possibilità di reperire un massimo di 5000 id follower per ogni call; essendo presenti utenti con decine di migliaia, se non milioni, di seguaci, si può facilmente intuire come tale limite possa risultare assai deleterio per i tempi di esecuzione dello script, oltre al costante rischio di finire nella blacklist del server e di non poter continuare a lavorare.

Per ovviare, almeno in parte a tali tempistiche e vista la grande difficoltà di gestire l’alto numero di follower presenti in un singolo insieme di tweet, si è deciso di aggirare in parte il problema creando uno script parallelo: download_following.py che ha le medesime funzioni del suo gemello già citato, ma si occupa di reperire dai server soltanto i following, di numero – mediamente – assai minore rispetto ai follower. Tale scelta si è rivelata vincente, permettendo di snellire sensibilmente i tempi di esecuzione e di lavorare su un insieme ridotto di dati. I risultati sono conservati ed esportati in maniera del tutto analoga a quella vista precedentemente.

I risultati sono stati ottenuti con tempistiche che vanno da 1,2 a 129 ore di esecuzione continua. A tal proposito è importante precisare come, per ovviare ai lunghi tempi di esecuzione su macchine private, è stato possibile utilizzare le macchine presenti all’interno del dipartimento di informatica, in remoto, messe a disposizione del docente. Questo per via della maggiore stabilità di esecuzione e di connessione. Ulteriore accorgimento è stato quello di creare un semplice file di log che tenesse conto dei progressi fatti finora e permettesse di riprendere dalla posizione in cui si è lasciato laddove si fosse presentato un problema o un errore del sistema.

Ultima precisazione in tal merito, una piccola modifica del codice sorgente delle relative API. Tale accorgimento si è reso necessario per via di un piccolo bug generato dall’assenza di utenti presenti nei tweet, ma successivamente eliminati dalla rete. La nostra ricerca costituisce una foto statica del modello, mentre realisticamente tali relazioni sono in continua modifica. Nel momento in cui si presentava tale situazione, lo script entrava in un loop infinito, che non bloccava l’esecuzione ma faceva perdere tempo e call preziose ai nostri fini. Semplicemente, una piccola modifica alla gestione delle eccezioni di una libreria ha permesso di ignorare tali assenze e proseguire la ricerca. Si è scelto di ignorare l’assenza di tali utenti in quanto costituiscono un insieme ridotto e poco significativo del complesso.

- 36 -

3.2.3. Generazione del grafo

Ottenuti tutti i dati di cui si è trattato nei paragrafi precedenti è possibile ottenere la costruzione del grafo, relativo alle interazioni tra gli utenti presenti nella rete. Naturalmente il grafo sarà di tipo diretto, in quanto le relazioni di Twitter non sono obbligatoriamente bi-univoche: se un utente A segue un utente B, non è assolutamente scontato che si verifichi il contrario.

La fase di ricostruzione del grafico è complessivamente molto semplice, basta mettere insieme quanto ricavato nei punti precedenti ed effettuare dei piccolo accorgimenti. Si comincia rendendo tutte le informazioni omogenee: come abbiamo visto, nella lista dei follower abbiamo lo screen name dell’utente seguito da tutti gli id degli utenti da cui è seguito o che segue. Per ottenere tutto in formato id è sufficiente utilizzare lo script from_screentoid.py che attraverso la lista di coppie [screen-name; id] precedentemente ottenuta, sostituisce in assoluta semplicità gli screen-name presenti con il rispettivo id, restituendo un file testuale del tutto identico a quello precedente ma con soli id univoci.

[screenname; id(u)]

screenname[id1, id2, … idn]  id(u)[id1, id2, … idn] Abbiamo quindi tutti gli ingredienti necessari per generare il nostro grafico, in formato testuale. Si parla quindi di generare una edge-list, in altre parole: una lista di coppie (id1, id2), dove la singola coppia è presente soltanto se id1 è un follower di id2 ed è presente nella lista di utenti della rete, generata nei primi passaggi. Il risultato è la lista degli archi presenti nella rete, che viene esportata in due formati diversi: il csv e il dot. Il primo formato è quello più comune e utilizzato per l’esportazione di tabulati di dati in generale, permette a buona parte dei software di riconoscere le informazioni. Il formato dot, invece, è linguaggio creato appositamente per la gestione dei grafi, che può essere interpretato da una moltitudine di librerie open source. Per i fini di questo elaborato occorre precisare che, pur essendo stato generato, non vi è stato poi un effettivo utilizzo, avendo lavorato principalmente e senza che vi fossero gravi criticità con il formato csv.