Come trasformare i dataset di DiscoverText in formato YourTwapperKepper

Come trasformare in modo rapido un dataset dal formato di DiscoverText a quello di YourTwapperKeeper

Esistono ormai svariati strumenti che supportano il lavoro del ricercatore nel reperire ed analizzare i contenuti prodotti dagli utenti nei social media.
Personalmente uso DiscoverText per le funzionalità di analisi del contenuto multi-utente che offre. Questo strumento manca tuttavia, almeno nella sua versione Professional, di un tool di analisi quantitativo in grado di rispondere a semplici domande come l’andamento della conversazione nel tempo o il rapporto fra Tweet e RT in un dataset Twitter.
A questo scopo faccio di solito uso degli script realizzati nell’ambito del progetto Mapping Online Publics e resi disponibili gratuitamente da Axel Bruns.
Il problema è che questi script sono pensati per funzionare su dataset in formato YourTwapperKeeper.
Recentemente ho trovato un modo relativamente semplice per passare da un formato all’altro usando un software gratuito chiamato Google Refine (o Open Refine come si chiama ora) e vorrei condividerlo con la comunità in caso qualcuno si trovasse ad affrontare una esigenza analoga.
1. Scaricare il dataset in formato CSV da DiscoverText;
2. Importare il file in Google Refine;
3. Scegliere la codifica UTF8 e come separatore la virgola;
4. Scegliere li nome e procedere con la creazione del progetto;
5. Scegliere Undo/Redo e poi “Apply”;
6. Nella finestra che si apre incollare il contenuto di questo script e scegliere “Perform Operation”;
A questo punto il formato del dataset è quello di TYK. Potete procedere ad esportare il file in formato CSV ed utilizzarlo come input negli script di Axel.
 

Alcuni dati sui Twitter trending topic in Italia

Gli argomenti della settimana su Twitter in Italia analizzati con il GnipPowerTrack importer di DiscoverText

Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 Come accennato nel precedente post, ho avuto la possibilità di testare per alcuni giorni una nuova funzionalità di DiscoverText che consente di reperire gli status di Twitter (Tweet) in tempo (quasi) reale.  Grazie all’accordo con Gnip, DiscoverText consente dunque di accedere alla così detta Firehose (il flusso di tutti gli status di Twitter) e di raccogliere questi contenuti per una successiva analisi.
La partecipazione a questo programma di beta test è durata dal 19 al 24 Ottobre (anche se il servizio è ancora al momento attivo).
DiscoverText, già nella versione in produzione, consente di importare contenuti da diverse fonti:

Per quanto riguarda Twitter era già disponibile il Live Feed Import basato sulle REST API di Twitter che richiede l’autenticazione con il proprio nome utente e password ed ha il vantaggio di poter reperire i Tweet da un archivio degli ultimi 5/6 giorni e lo svantaggio di non garantire la completezza dei risultati (si veda il precedente post per i dettagli su questo).
La novità è il GNIP PowerTrack importer.
Questa modalità di importazione dei Tweet ha il vantaggio di restituire il flusso completo di tutti gli status pubblici e lo svantaggio di non consentire l’accesso ad alcun archivio (il flusso che si riesce a reperire parte dal momento in cui si inizia a raccogliere i dati).
Una combinazione delle due metodologie di importazione descritte dovrebbe consentire dunque una ragionevole fedeltà nella raccolta dati (ovviamente bisognerà rimuovere i duplicati, cosa che DiscoverText consente di fare in automatico).
La metodologia di importazione GNIP PowerTrack si basa sulla costruzione di una regola di importazione che può essere costruita da un massimo di 10 termini o operatori fino a una lunghezza complessiva di 255 caratteri per l’intera regola. In pratica si tratta di filtrare il flusso dei contenuti secondo certi criteri.
Si possono cercare frasi esatte, usare gli operatori – per escludere un termine, usare un hashtag – vengono identificati alla fonte da Twitter – come chiave di ricerca, una mention di un utente specifico (@nomeutente compresi i RT), status prodotti o destinati ad un utente specifico (from: e to:), contenenti smile, status prodotti da un client specifico, status che siano retweet di uno specifico utente, status contenenti luoghi, stringhe specifiche, che contengono un certo indirizzo internet, status prodotti da utenti che abbiano un klout score compreso fra due valori minimo e massimo, status che contengono link, che siano geo-referenziati, che contengono almeno una mentions (compresi dunque i retweet) o almeno un hashtag e infine status classificati da Gnip come appartenenti ad una certa lingua (compreso l’italiano).
Per testare la funzionalità ho raccolto i dati per molti dei trending topics (per capire meglio come vengono calcolati consiglio la lettura di questo articolo) italiani emersi nel corso degli ultimi giorni da #erpelliccia a #gheddafi, da #nubifragio a #notav (+ “val di susa”) senza dimenticare #XF5 e #gf12.  Ho anche provato per breve tempo a monitorare un trending topic globale e sponsorizzato come “Paranormal Activity 3”. Per completare i test ho anche provato a raccogliere i dati dell’interno stream di contenuti in lingua italiana allo scopo di comprendere meglio la consistenza del flusso di tweet prodotti nella nostra lingua.
Iniziamo l’analisi da questi ultimi.
Usando il filtro lang:it avrei dovuto reperire il flusso di Tweet in italiano. Purtroppo questo filtro si è dimostrato del tutto inefficace. Per motivi che non mi sono chiari oltre ai Tweet in italiano sono stati anche reperiti i Tweet in altre lingue fra cui indonesiano, malese, vietnamita, turco e chissà quante altre (ho usato Google Translate per identificarle). Questa errata identificazione della lingua ha reso impossibile raggiungere l’obiettivo che mi ero posto ed i sotto-obiettivi che sarebbero stati identificare quanti di questi Tweet prodotti nella nostra lingua fossero geo-referenziati, contenessero link, mentions ed hashtag.
Passiamo dunque all’analisi del flusso di un trending topic globale e sponsorizzato come “Paranormal Activity 3”.
In questo caso, usando la semplice ricerca per frase esatta, sono stati reperiti 21333 status updates in circa due ore e mezza (nello specifico fra  il 10/21/2011 2:36:13 AM ed il 10/21/2011 5:05:37 AM EST: Eastern Standard Time).  Si tratta di 142 Tweet circa al minuto. DiscoverText supporta l’analisi di grandi quantità di dati attraverso uno strumento chiamato CloudExplorer. Si tratta in pratica di una semplice tagcloud che consente però di cliccare su ogni voce per accedere alla lista dei contenuti filtrati per quella parola chiave.

 
Cliccando ad esempio su See si accede ad una lista filtrata dei 7260 Tweet in archivio che contengono questo termine.  L’archivio può inoltre essere ricercato liberamente per parola chiave e filtrato usando uno o più criteri basati sugli stessi metadati disponibili per la costruzione di un filtro. Posso ad esempio sapere con facilità quanti status in archivio contengono un hashtag (in questo caso 2433) o quanti contengono menzioni di altri utenti (8004).
Dal pannello filtri avanzati della ricerca è inoltre possibile ottenere alcuni altri dati sull’archivio. Si può ad esempio conoscere il numero degli utenti che hanno usato l’hashtag (19360) e quale di questi lo abbia fatto più volte (15). Conoscere l’hashtag più utilizzato è Paranormal con 281 occorrenze seguito curiosamente da iDontSupport con 66 occorrenze. In totale sono stati utilizzati 1342 hastag diversi. Ci sono invece 5930 utenti diversi menzionati con in testa l’account ufficiale del film chiamato in causa da 531 status.
Il risultato di una ricerca può essere salvato in un bucket (un contenitore di passaggio con il quale miscelare i dati unendo ad esempio più di un bucket) dal quale costruire poi un dataset. Al dataset possono essere applicate le classiche tecniche di analisi del contenuto basate su griglie di analisi date o costruite a partire dai dati. Il dataset toolbox comprende strumenti piuttosto avanzati per il supporto della collaborazione fra più ricercatori nella codifica dello stesso dataset.
Veniamo adesso ai dati che riguardano i trending topics italiani.
Mi soffermerò sui casi di #gheddafi lang:it, #nubifragio, #notav, #XF5 e #gf12.
L’importer avviato alle il 20/10/2011 alle 13:50 (l’ANSA con la notizia della morte di Gheddafi è delle 13:11) ha raccolto 6601 Tweet. Il primo contenuto reperito è datato 20/10/2011 alle 13:49, l’ultimo 24/10/2011 alle 11:17.
Nel GNIP Feed Management è possibile visualizzare un grafico dell’andamento dei Tweet per ogni importer attivo.
Questo è il grafico per #gheddafi (gli orari sono in EST – Eastern Standard Time e gli slot temporali da circa 15 minuti).

 
Il picco è di oltre 300 Tweet in 15 minuti circa e corrisponde con il momento di attivazione dell’importer. Sarebbe stato bello poter raccogliere i dati di quella mezz’ora intercorsa fra l’annuncio della morte ed il momento di attivazione dell’importer. Raccogliere dataset completi relativi a breaking news è veramente difficile con questo metodo.
Per questo motivo ho provato nel caso di #nubifragio ad utilizzare sia l’importer basato sulle REST API sia il GNIP Power Track.
Con questo metodo ho reperito 4005 (1886 con GNIP e 2119 con le REST API) Tweet. La rimozione dei duplicati esatti ha ridotto l’archivio a 1783 status. Non mi è chiarissimo con questo elenco dei duplicati esatti venga creato e dopo averlo applicato anche ad altri archivi che non avrebbero dovuto contenere duplicati temo posso rimuovere anche i retweet identici. Purtroppo è difficile estrarre da questo archivio elementi utili sulle date perché, apparentemente, i Tweet importati da GNIP e quelli importati dalle REST API sono riferiti a fusi orari diversi.  Questo status duplicato ha come ora di pubblicazione rispettivamente le 9:33 AM EST e le 5:33 AM di un fuso orario sconosciuto.
Più semplice è invece lavorare su eventi programmati per i quali è possibile attivare l’importer per tempo.
Per la manifestazione di Val di Susa ho seguito l’hashtag #notav e la stringa di ricerca “val di susa”. Ho attivato l’importer alle 8:34 23/10 e reperito nel complesso 5501 Tweet.
Di seguito il grafico per l’hashtag #notav.

 
In questo caso sono riuscito a fotografare l’andamento del fenomeno prima che raggiungesse il picco (avvenuto intorno all’ora di pranzo con oltre 300 Tweet prodotti durante lo slot di 15 minuti circa).
Gli hashtag più utilizzati sono stati #diamociuntaglio (1014) e #report (117). Dei 429 utenti menzionati, notav_info è il più citato (645). In totale hanno contribuito a questo hashtag 1300 utenti diversi. Il più attivo è stato ViceVersa_1917 con 146 Tweet.
Durante il periodo di betatest sono inoltre andati in onda le prime puntate della quinta stagione di X Factor e della dodicesima edizione de Il Grande Fratello.
Per X Factor ho monitorato l’hashtag #xf5 con colpevole ritardo a partire dalla mattina successiva alla messa in onda.

 
Anche la mattina dopo c’è stato un discreto volume di conversazioni che ha superato il picco di 200 Tweet in 15 minuti. Se dovessi avere ancora accesso al servizio proverò a raccogliere i dati relativi alla messa in onda della seconda puntata in onda domani.
Infine per quanto riguarda la prima puntata della dodicesima stagione de Il Grande Fratello ho monitorato sia l’hashtag #gf12 che la stringa “grande fratello” a partire da pochi minuti prima della messa in onda (20:56 del 24/10).
Ecco il volume di Tweet durante la messa in onda (il primo grafico è riferito a “grande fratello” e il secondo a #gf12) [le 3 PM del grafico equivalgono alle nostre 21:00].

 

 
In entrambi i casi l’andamento è simile con le discussioni che si protraggono fino a oltre mezza notte (le 6 PM nel grafico). Il buco delle 5 PM del grafico credo sia dovuto a qualche problema nel flusso di importazione dei dati.
Nel secondo caso si sono toccati e superati gli 800 Tweet in 15 minuti. Inoltre questo volume è stato mantenuto per tutta la durata del programma.
Nel complesso ho reperito 13308 generati da 5169 utenti il più attivo dei quali è stato w4rr10r_0 con i suoi 160 status. Oltre a #gf12 sono stati utilizzati altri 883 diversi hashtag. Il più utilizzato dopo #gf12 è stato #GrandeFratello.
Fra i xxx menzionati nei Tweet etichettati #gf12 spicca @Microsatira il cui tweet ironico è stato retweettato oltre 100 volte (in totale ha ricevuto 189 mentions).
La seguente tagcloud dovrebbe dare un’idea dei temi più citati:

Come spesso accade nei discorsi sui programmi televisivi di grande richiamo i commenti veri e propri al programma si sommano ai giudizi di chi non riesce a capacitarsi di come quel programma possa avere successo o si lamenta della qualità della televisione italiana.
In conclusione credo che DiscoverText sia uno strumento con delle caratteristiche uniche. Non si tratta di un prodotto perfetto e non sono mancate le volte nelle quali, specie su grandi quantità di dati, mi sono stati restituiti dei messaggi di errore. L’accordo che stanno perfezionando con Gnip potrebbe rendere questo strumento essenziale per chi voglia fare ricerca su Twitter. Le modalità di implementazione di questa funzionalità rendono bene le potenzialità di estensibilità della piattaforma. La gestione delle timezones appare migliorabile (forse renderanno in futuro possibile scegliere all’utente il fuso orario per il grafico). Nel complesso il sistema si comporta bene anche su grandi quantità di dati mostrando eccellenti performance nella creazione delle tagclouds (che necessiterebbero però della possibilità di escludere liste di parole comuni) e nelle ricerche che richiedono sempre tempi ragionevolmente brevi per essere portate a termine.
Credo ci siano più di uno spunto
Come ho avuto modo di scrivere altrove, l’utilizzo di una piattaforma web collaborativa per l’analisi del contenuto rappresenta un percorso obbligato per chi desideri fare ricerca qualitativa su grandi quantità di dati (come quelli provenienti dai media sociali).
DiscoverText è un prodotto della Texifter LLC. Si tratta di una società nata come spin-off a partire dall’attività di ricerca di Stuart W. Shulman presso la University of Massachusetts Amherst.
Non mi resta dunque che augurare buon lavoro a Stuart e al suo team di sviluppatori.
P.S. Durante il periodo di beta-test i dati non sono esportabili quindi non chiedetemeli 😉
 
 
 
 
 

Limiti e possibilità della ricerca su Twitter

Il crescere del numero di ricercatori che scelgono i social media come luogo di osservazione per studiare le dinamiche sociali rende indispensabile fare il punto su limiti e possibilità offerti da queste piattaforme

Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche nella comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, al pari dei media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche presso la comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, come i media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.Facendo seguito al diffondersi dei social media presso la popolazione del nostro Paese, si va progressivamente affermando, anche presso la comunità accademica italiana, l’idea che questi spazi possano essere considerati un luogo di osservazione per le dinamiche sociali interne ed esterne alla rete.
Come all’estero anche in Italia, i ricercatori, come i media, dedicano a Twitter un’attenzione talvolta non giustificata dai dati sulla diffusione della piattaforma stessa.
Sul blog ufficiale di Twitter si legge che la piattaforma ha recentemente tagliato il traguardo dei 100 milioni di account attivi nel mondo, che la metà di questi accede quotidianamente e che il 40% di essi legge i Tweet creati da altri utenti senza produrne di propri. Dopo questo annuncio, Vincenzo Cosenza ha messo a confronto questi dati con quelli rilasciati da Facebook.
Twitter non rilascia dati ufficiali sul numero di utenti registrati o attivi in ogni nazione, ma fonti attendibili stimavano circa 1,3 milioni di utenti italiani registrati di cui circa 350.000 attivi (che avevano cioè fatto login durante i precedenti trenta giorni attraverso Twitter o le sue API) a ottobre 2010. Per darvi un termine di paragone, nello stesso periodo Facebook aveva oltre 16 milioni di utenti italiani registrati e Linkedin 1,1.
Capire la situazione a oggi non è affatto semplice.
Stimare il traffico verso il sito non è infatti, in questo caso, un buon indicatore perché una significativa fetta di utenti accede a Twitter usando client che consentono di fruire della piattaforma senza passare dal sito twitter.com. Le statistiche di ricerca di Google evidenziano un interesse crescente, in Italia, per questa piattaforma con un volume che, tuttavia, non si discosta molto da quello di siti come Badoo, Netlog o Flickr. Provate voi stessi ad aggiungere la parola chiave Facebook per farvi un’idea dei rapporti fra i volumi di ricerca (che rappresentano un indicatore dell’interesse degli utenti verso una certa piattaforma).
Chiarite le proporzioni ci sarebbe da attendersi una analoga sproporzione nell’interesse dei ricercatori italiani.
Di fatto così non è. Anche se non ho dati specifici a riguardo ho la sensazione che gli studi basati sull’analisi dei contenuti generati dagli utenti su Facebook e su Twitter si equivalgano o propendano piuttosto per quest’ultima piattaforma. Basta scorrere il resoconto del recente convegno dell’associazione internazionale dei ricercatori che studiano internet, per capire che non si tratta di un fenomeno italiano e che l’interesse della comunità accademica è centrato, a dispetto dei dati sull’utilizzo, più su Twitter che su Facebook. Questa tendenza è particolarmente curiosa in Paesi come il nostro dove i dati sulla diffusione delle piattaforme restituiscono una mappa che indica piuttosto chiaramente dove si trova la maggior parte di utenti e dunque le dinamiche sociali che riguardano settori significativi della popolazione.
Credo ci siano diversi motivi che contribuiscono in vario modo a rendere Twitter una piattaforma attraente dal punto di vista dei ricercatori:
1. Il sistema di privacy e le pratiche d’uso di Facebook rendono inaccessibile gran parte dei contenuti. Su Twitter la maggior parte dei contenuti sono pubblici ed accessibili tramite semplici (o apparentemente semplici) ricerche;
2. L’interesse dei media verso Twitter rende notiziabili le ricerche che riguardano questa piattaforma;
3. La natura orientata all’informazione (la domanda di Twitter è “Cosa sta succedendo” e non “A cosa stai pensando”) lo rendono particolarmente indicato per studi orientati a comprendere i percorsi di diffusione delle notizie;
4. L’emergere di pratiche come l’uso degli hashtag, il retweet, il replay e trending topics (ormai parte delle funzionalità interne della piattaforma) rendono più semplice comprendere la struttura delle conversazioni.
Dunque ci sono diversi buoni motivi per usare Twitter come luogo di osservazione.
L’apparente semplicità di accesso cela tuttavia dei rischi di cui il ricercatore dovrebbe essere, quanto meno, al correte.
Intanto i Tweet reperibili sono, ovviamente, solo quelli pubblici. Per la maggior parte dei progetti non si tratta di un grosso problema che va semplicemente rendicontato specificando, quando ci si riferisce al corpus di dati, di Tweet pubblici.
Ma c’è dell’altro. Come forse saprete Twitter impone dei limiti di accesso per l’utilizzo delle sue API pubbliche.
Purtroppo questi limiti non sono affatto chiari.
Si sa che le Twitter REST API sono soggette ai seguenti limiti:
– 150 richieste non autenticate ogni ora (basate sul numero ip dal quale proviene la richiesta);
– 350 richieste autenticate all’ora (basate sull’identificativo dell’utente che fa la richiesta).
Si sa inoltre che ogni richiesta può restituire un massimo di 1500 tweet.
La documentazione che riguarda le Twitter Search API specifica che la ricerca non dà accesso all’indice completo di tutti i Tweet ma solo di quelli recenti (fino a 6-9 giorni prima) e che non si possono usare le Search API per trovare Tweet più vecchi di una settimana.
Inoltre aggiunge:

The Rate Limits for the Search API are not the same as for the REST API. When using the Search API you are not restricted by a certain number of API requests per hour, but instead by the complexity and frequency.
As requests to the Search API are anonymous, the rate limit is measured against the requesting client IP.
To prevent abuse the rate limit for Search is not published. If you are rate limited, the Search API will respond with an HTTP 420 Error. {"error":"You have been rate limited. Enhance your calm."}.

Dunque i Tweet reperiti attraverso questa API non garantiscono la completezza (la documentazione parla invece di focus sulla rilevanza) e alcuni Tweet potrebbero mancare all’appello per raggiunti limiti di richieste, perché l’utente che ha generato il tweet ha un basso ranking o, infine, semplicemente perché, a causa della limitatezza delle risorse, non tutti i Tweet possono essere indicizzati in Twitter Search (si veda qui).
Se si desidera la completezza (un requisito di solito indispensabile per chi fa ricerca), dice sempre la documentazione di Twitter, conviene usare le Streaming API.
Le Straming API restituiscono i Tweet in tempo reale. Questo significa che non è possibile tornare indietro nel tempo.
Ma anche le Streaming API hanno dei limiti.

Both the Streaming API and the Search API filter, and on some end-points, discard, statuses created by a small proportion of accounts based upon status quality metrics.

In compenso

 The Streaming API results are a superset of the Search API result. The Search API filters and ranks statuses for relevance. On certain queries, the Search relevance filtering can be quite selective. The Streaming API does not perform any relevance filtering or ranking. All statuses that pass the Result Quality filter are available on Streaming API.

L’uso delle Streaming API richiede l’autenticazione.
Di seguito, nel paragrafo su accesso e limiti di utilizzo, si dice che tutti gli utenti di Twitter sono abilitati a usare due metodi chiamati statuses/sample e statuses/filter e che per tutti gli altri metodi bisogna contattare Twitter.
Ora cosa sono questi statuses/sample e statuses/filter?
Il primo restituisce un campione di Tweet basato sull’universo costituito dal flusso di tutti gli status pubblici (il cui flusso è chiamato da Twitter Firehose).
Le proporzioni di questo campione possono cambiare senza preavviso ma al momento sono le seguenti:
– Circa l’1% degli status pubblici per il flusso che Twitter chiama Spritzer (disponibile a tutti);
– Circa il 10% per il flusso denominato Gardenhose (disponibile su richiesta).
Il metodo statuses/filter è quello che dovrebbe maggiormente interessare un ricercatore. Consente in pratica di filtrare il flusso per specifiche parole chiave (ad esempio un certo hashtag), per posizione geografica, che contengono il nome di un utente (@nomeutente) come un replay o un retweet o una semplice menzione.
Il livello di accesso di default consente l’accesso ad un massimo di 400 parole chiave, di 5000 nomi utente e 25 luoghi geografici (non è chiaro se si tratta di limiti legati alla storia del singolo utente o contemporanei).
In aggiunta a questi limiti la documentazione di Twitter contiene un paragrafo intitolato Filter Limiting nel quale si specifica che le ricerche per parole (track) chiave e quelle per luogo sono soggette ad un limite di utilizzo e aggiunge…

Reasonably focused track and location predicates will return all occurrences in the full Firehose stream of public statuses. Overly broad predicates will cause the output to be periodically limited. After the limitation period expires, all matching statuses will once again be delivered, along with a limit message that enumerates the total number of statuses that have been eliminated from the stream since the start of the connection. Limit messages are described in Parsing Responses.

Non è dato sapere cosa costituisca una ricerca ragionevolmente focalizzata. Rimane dunque la sensazione di una certa confusione.  Nell’articolo Six Provocations for Big Data le autrici affermano che

Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access. Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts.Is the data representative of all public tweets? Perhaps, but not necessarily.

Di recente DiscoverText ha siglato un accordo con Gnip per offrire ai ricercatori che usano questa piattaforma l’accesso alla Firehose di Twitter. Al momento il servizio è in beta limitata ad un ristretto numero di utenti.
Da ieri ho accesso a questo servizio e lo avrò per i prossimi 4 giorni. Ho già iniziato a raccogliere dati per i principali trending topic italiani. In questi giorni cercherò di capire meglio i vantaggi e gli eventuali limiti di questa soluzione e ne parlerò in un prossimo post.

Note sulla raccolta tweet in realtime con DiscoverText

Ho provato a fare un piccolo esperimento per capire meglio i limiti del reperimento tweet su temi d’attualità.
Nel corso delle ultime 24 ore ho raccolto 9429 tweet contenenti l’hashtag #tunnelgelmini.
Per la raccolta ho usato DiscoverText che, come quasi tutti i tool attualmente disponibili (vedi la terza delle sei provocazione sui Big Data di danah boyd a Kate Crawford), non garantisce comunque che tutti i tweet della timeline pubblica siano stati effettivamente reperiti. Il limite imposto dalle API di Twitter è di 1500 tweet restituiti e DiscoverText consente di reperire i dati ogni 15 minuti. Quindi tutte le volte che sono generati più di 1500 tweet in un quarto d’ora si perdono quelli eccedenti questa soglia.
Ho iniziato a raccogliere i dati alle 17:52 di ieri 24/09 ed il primo tweet reperito è delle 16:36 del 24/09 (http://twitter.com/#!/paoloduina/status/117608339399127040).
Bisogna dunque essere molto rapidi se si desidera ottenere una collezione completa di tweet su fenomeni come questo. Annoto incidentalmente che tutte le date in DiscoverText sono relative al fuso GMT-7 e non ho trovato il modo di settare il fuso orario dell’utente.
Della collezione di tweet reperiti 4734 (50,2%) sono retweet (RT @) e 365 (3,87) sono risposte ad un utente (@ replay). I 9429 tweet sono stati generati da 4377 account diversi. Sarebbero poco più di due ad account se non fosse che la distribuzione è, come sempre avviene in questi casi, non normale. L’utente più prolifico ha pubblicato 50 tweet. I 10 utenti più prolifici hanno generato 358 tweet pari al 3,79% del totale.