nextmedia & society .org

Ho scoperto solo oggi che netvizz consente di scaricare, oltre che il proprio grafo personale di Facebook, anche quello dei gruppi di cui si è membri.

Per testare questa funzionalità ho provato a scaricare il grafo relativo al gruppo Università di Urbino “Carlo Bo” composto, al momento in cui scrivo, da 2281 membri.

Nella documentazione è riportato che, a cause delle limitazioni imposte da Facebook sull’uso delle sue API, per gruppi superiori a 500 membri viene estratto un campione casuale di membri. Nella mia prova sono invece riuscito a scaricare, dopo alcuni minuti di attesa durante i quali sembra che non succeda nulla, un grafo praticamente completo composto da 2213 nodi e 13408 archi che rappresentano i legami di amicizia fra i membri del gruppo. Sul perché manchino all’appello 68 membri non saprei dirvi anche se sospetto possa dipendere dalle impostazioni di privacy degli utenti.

Netvizz crea un grafo indiretto in formato gdf. Da lì ad importare il grafo in Gephi il passo è stato breve.

Fra le misure di centralità ho deciso di utilizzare l’Eigenvector centrality per rappresentare le dimensioni dei nodi. Ho inoltre calcolato la modularity per individuare le comunità.

Ho infine applicato l’algoritmo ForceAtlas 2 per posizionare i nodi.

Ed ecco il risultato.

Scarica la visualizzazione in formato SVG

Credo si tratti di una fotografia piuttosto fedele delle relazioni a Urbino (almeno per quello che le conosco io). Si nota l’emergere di alcuni cluster interessanti come quello degli studenti greci in blu (sulla destra e piuttosto isolati), l’area di scienze della comunicazione (in rosso), quella dell’impegno politico in bianco e piuttosto centrali a segnalare una tendenza a fare amicizia con molte persone diverse, caratteristica questa che condividono con il cluster verde che fa invece riferimento alla vita notturna e all’intrattenimento. Lascio a voi il piacere di identificare gli altri cluster.

Vi lascio inoltre con una piccola curiosità.

Questo è il grafo dei 100 membri del gruppo meglio connessi (sempre in base all’Eigenvector centrality) rispetto agli altri.

Scarica la visualizzazione in formato SVG
Ci siete? E in che cluster?

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

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.

Visto che non sono a Seattle per partecipare all’annuale conferenza dell’Associazione dei Ricercatori che Studiano Internet ho deciso di sperimentare storify per provare a raccontare, a partire da contenuti trovati in rete, la conferenza.

Proseguendo nella serie di articoli sull’utilizzo dei social media per predire il presente ho deciso questa volta di mettere a confronto il volume di ricerca su Google ed il numero di immatricolati negli atenei italiani.

L’andamento delle ricerche su Google mostra infatti una periodicità piuttosto marcata che vede nel mese di settembre il picco più alto di interesse. Questo vale sia per la generica chiave “università” che per chiavi specifiche ai diversi atenei.

Di qui la domanda: esiste una correlazione fra volume di ricerche su Google e numero degli immatricolati in un certo anno accademico?

Ho provato a verificare questa ipotesi a partire dai dati sugli immatricolati disponibili sull’anagrafe nazionale degli studenti del sito del MIUR e al servizio Google Insight for Search.

Per quanto riguarda gli immatricolati mi sono limitato a scaricare i dati disponibili (partono dall’anno accademico 2003/2004) e accorpare i fogli excel divisi per anno accademico in un’unica tabella. Al momento risultano attivi 88 atenei e l’andamento complessivo degli immatricolati è il seguente

Per misurare il volume di ricerca su Google ho effettuato delle query su Google Insight for Search. Questo servizio restitutrice “il numero di ricerche web eseguite con un termine specifico rispetto al numero totale di ricerche effettuate su Google in un arco di tempo. Non rappresentano i valori del volume di ricerca assoluto, in quanto i dati vengono normalizzati e presentati in scala da 0 a 100; ciascun punto sul grafico viene diviso per il punto massimo o per 100″ (si veda Che cosa indicano i numeri nel grafico? dalla guida del prodotto). I valori restituiti sono dunque compresi fra 0 e 100.

Nel nostro caso si tratta di ricerche effettuate su un singolo termine di ricerca con i seguenti parametri: Google Ricerca Web, Italia, Gennaio 2004-Settembre 2011, Tutte le categorie.

Ho deciso di raccogliere per ciascuno degli 88 atenei e per la chiave generica “università” i valori restituiti per il mese di agosto e quello di settembre (mesi durante i quali sono aperte le iscrizioni)*. Per quanto riguarda i singoli atenei ho dovuto concatenare termini di ricerca costruiti ad hoc per ciascun ateneo**.

Al termine della fase di data entry avevo dunque a disposizione le seguenti serie aggregate di dati per il complesso degli 88 atenei: ricerche per la chiave università (media agosto/settembre e settembre), media dei volumi di ricerca per ogni singolo ateneo (media agosto/settembre e settembre), media delle ricerche per ogni singolo ateneo escludendo i casi in cui il volume di ricerca era 0 (media agosto/settembre e settembre).

A questo punto, allo scopo di rendere confrontabili i dati, ho normalizzato il numero di immatricolati per anno accademico e per ateneo seguendo la stessa strategia utilizzata da Google Insight for Search. Ho dunque individuato il valore massimo attribuendo ad esso il punteggio 100 e normalizzato di conseguenza gli altri valori. In questo modo avevo disponibili serie di valori confrontabili su una scala compresa fra 0 e 100.

Avendo deciso di prendere come riferimento i mesi di agosto e settembre avevo tuttavia due valori per anno per quanto riguarda il volume di ricerca ed uno solo per gli immatricolati. Ho dunque deciso fare la media fra il valore di agosto e quello di settembre ottenendo un indice sintetico del volume per un singolo anno (in un secondo momento ho anche utilizzato il solo dato di settembre come confronto).

Poiché i dati degli immatricolati partono dal 2003/2004 e quelli di Google Insight for Search dal 2004 ho deciso di prendere in considerazione i dati degli immatricolati a partire dall’anno accademico 2004/2005. A partire da quell’anno, se ci fosse correlazione, ad un certo andamento del volume di ricerche su Google, dovrebbe corrispondere un analogo pattern nelle immatricolazioni. Inoltre i dati già disponibili di Google Insight per il 2011 dovrebbero prevedere l’andamento degli immatricolati per l’anno accademico 2011/2012.

Vediamo dunque i risultati:

Confortato da questi risultati ho proceduto a calcolare l’indice di correlazione per ciascun ateneo confrontando le serie di immatricolati normalizzati per ateneo 2004/2005, 2005/2006, 2006/2007, 2007/2008, 2008/2009, 2009/2010, 2010/2011 con il volume di ricerca media agosto/settembre per le stringhe di ricerca specifiche di ciascun ateneo.

Ecco il risultato:

In questo caso i risultati sono contrastanti. Nella maggior parte dei casi (47) non si riscontrano correlazioni significative ed in 3 addirittura la correlazione è negativa. Nei restanti 38 casi  la correlazione è positiva e significativa (ovvero maggiore o uguale a 0,7).

Provando a calcolare lo stesso indice di correlazione con i soli dati di settembre la situazione non cambia di molto con 50 casi di non correlazione, uno solo di correlazione negativa e 37 di correlazione positiva.

Come al solito tutti i dati che ho raccolto sono disponibili pubblicamente in un foglio di calcolo di Google Documenti.

Dunque come spesso accade quando si lavoro con le correlazioni non emerge un risultato chiaro e incontrovertibile.

Le correlazioni totali appaiono significative, ma quelle per singolo ateneo lo sono solo per un ristretto gruppo di atenei.

Lascio al lettore il piacere di scoprire l’andamento del volume di ricerca dell’agosto e settembre appena conclusi e che cosa questo potrebbe pre-configurare rispetto al numero degli immatricolati 2011/2012.

E voi cosa ne pensate? La correlazione c’è o no?

*Si tratta di un indicatore piuttosto rozzo considerando che, anche nei mesi di agosto e settembre, utenti con intenti molto diversi potrebbero usare i termini di ricerca presi in esame. Esiste tuttavia la possibilità che l’effetto di questi utenti venga essere assorbito dal trend di chi invece cerca su Google il nome dell’università alla quale pensa di iscriversi.

** I termini di ricerca considerati sono disponibili nel foglio di calcolo insieme a tutti gli altri dati nella colonna “termini di ricerca” del foglio sui volumi di ricerca. Nel corso dei vari tentativi mi sono accorto che i termini di ricerca contenenti il solo nome di dominio dell’ateneo (uniurb, unibo, unicatt, etc) sono in ascesa e vengono spesso usati al posto del nome per esteso dell’Università. Mi sono dunque chiesto se inserire anche il nome di dominio come parte della stringa di ricerca. Alla fine ho deciso di non inserire questo termine di ricerca (tranne in specifici casi come “Luiss”) perchè credo che uno studente che usa Internet per cercare l’ateneo a cui iscriversi difficilmente utilizzi queste chiavi di ricerca (ma posso anche sbagliarmi).

Parlando con studenti, dottorandi e colleghi mi pare di capire che ci sia ancora qualcuno – per non dire la maggioranza – che crea a mano citazioni e bibliografie per le sue pubblicazioni. A loro è dedicato questo post

Una volta costruire la bibliografia per un articolo era un lavoro che richiedeva tempo e dedizione. Oggi ci sono software che rendono questo lavoro estremamente semplice producendo al tempo stesso citazioni e bibliografie più corrette.

Questi software fanno sotto il nome di Reference Manager. I più popolari sono EndNote, Zotero e l’ultimo arrivato, Mendeley.

Mendeley ha un approccio leggermente diverso rispetto ai predecessori. Oltre ad essere un Reference Manager è infatti anche un social network per ricercatori. Per il momento vorrei tuttavia soffermarmi sulle caratteristiche di Mendeley come Reference Manager.

Tutte queste applicazioni si basano su una semplice idea. Ogni volta che leggiamo una pubblicazione che ci interessa ne facciamo una sorta di scheda bibliografica da archiviare in un database. Questo database in Mendeley è costituito dall’applicazione Mendeley Desktop (disponibile per Windows, Mac OS X e Linux).

Ma come popolare questo database? Inserire a mano centinaia di schede non è certo un’attività semplice o divertente. Per questo motivo è possibile lasciar fare a Mendeley il lavoro sporco. Ci sono due modi per farlo. Il primo consiste nel trascinare l’articolo pdf direttamente dalla cartella del proprio computer a Mendeley Desktop e lui farà il possibile per reperire le informazioni essenziali per costruire la scheda (autore, titolo, anno di pubblicazione, editore, rivista, etc). Per esperienza vi posso dire che non sempre funziona come dovrebbe, ma che per gli articoli in digitale scaricati dai siti delle riviste fa adeguatamente il suo dovere. Alternativamente c’è un altro metodo che è forse anche più semplice ed efficace. Si può installare sul proprio browser, non importa quale, un bottone chiamato Import to Mendeley. Una volta trovato l’articolo o il libro che ci interessa (per i libri io utilizzo WorldCat ma va bene anche Amazon) basta premere quel bottone per ottenere, a patto di essere su uno dei moltissimi siti supportati, un’analisi della pagina e la creazione automatica di una scheda con tutti i dati nel nostro database.

Una volta creato il vostro database, potete farlo anche poco per volta a partire dai riferimenti che vi servono per le cose che state scrivendo ora, si tratta di capire come creare citazioni e bibliografie.

Dipende dal programma che usate per scrivere i vostri articoli/saggi/tesi. La maggior parte di voi userà una qualche versione di Microsoft Word e altri Open Office e qualcuno BibText. Il plug-in di Mendeley supporta Windows Word 2003, 2007, 2010, Mac Word 2008, 2011, OpenOffice 3.2, BibTeX. Il plug-in giusto viene installato automaticamente con Mendeley Desktop.

Fra tutte le soluzioni che ho provato Mendeley è quella che io ed alcuni miei colleghi del LaRiCA abbiamo scelto di usare (ebbene si… anche fra di noi c’è chi scrive le bibliografie a mano ).

Una cosa è certa, almeno che non sia costretto con la forza, non perderò più ore ad inserire a mano citazioni e costruire bibliografie. Non posso che consigliarvi di fare, appena possibile, altrettanto

Disclosure: Da alcuni mesi sono advisor di Mendeley. In pratica significa che ho accettato di diffondere gratuitamente informazioni su questo prodotto come forma riconoscimento al lavoro svolto dagli sviluppatori, per mantenere il prodotto gratuito e per contribuire per le mia capacità ad un progetto che ammiro.