Embed Size (px)
Citation preview
“output” — 2015/5/20 — 14:15 — page i — #1
UNIVERSITA DEGLI STUDI DI TRIESTEDipartimento di Ingegneria e Architettura
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi di Laurea in Reti di Calcolatori II
Metodologia per la classificazioneautomatica di commenti non desiderati
su social network
LAUREANDO RELATORE
Simone Maver Chiar.mo Prof. Alberto BartoliUniversita degli Studi di Trieste
CORRELATORE
Chiar.mo Prof. Eric MedvetUniversita degli Studi di Trieste
Anno Accademico 2014/2015
“output” — 2015/5/20 — 14:15 — page i — #2
Indice
1 Introduzione 1
2 Definizione formale delle regole di filtraggio 32.1 Contesto e notazione utilizzata . . . . . . . . . . . . . . . . . . . . . . . 32.2 Formazione di una regola e sua applicazione . . . . . . . . . . . . . . . . 52.3 Esempi di regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Estrazione dei dati 83.1 Progettazione algoritmo di estrazione . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Notazione utilizzata . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 Metodi delle API utilizzati . . . . . . . . . . . . . . . . . . . . . 103.1.3 Obbiettivo da raggiungere e definizione dell’algoritmo . . . . . . 10
3.2 Dettagli implementativi ed esecutivi . . . . . . . . . . . . . . . . . . . . 13
4 Validazione del formalismo 174.1 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Dettagli implementativi . . . . . . . . . . . . . . . . . . . . . . . 22
5 Conclusioni 23
A Interfacciamento alle Twitter API 24
Bibliografia 26
i
“output” — 2015/5/20 — 14:15 — page 1 — #3
Capitolo 1
Introduzione
La crescente diffusione dei social network negli ultimi anni ha portato ad un aumentodelle relazioni virtuali tra gli utenti presenti in essi, con il conseguente aumento dicontenuti e informazioni che vengono presentati ad ogni utente. Questa crescita ha fattoemergere la necessita di permettere agli utenti di selezionare e moderare i contenuti ele fonti da cui essi provengono in modo da poter evitare quei contenuti non desideratie poter far fronte anche a fenomeni di abusi e/o offese che questi contenuti possonoveicolare. Questa esigenza trova riscontro sia tra i gestori dei social network [1], sia incampo scientifico [2, 3, 4, 5].
Alcuni dei maggiori social network forniscono ai propri utenti alcune funzionalita perfare fronte alle problematiche citate e in ambito scientifico esistono alcune proposte similia quelle discusse in questa tesi [6, 7]. Il lavoro qui presentato aveva come obbiettivola definizione di un formalismo per descrivere insiemi di regole di filtraggio da partedi un utente e la verifica di effettiva usabilita e gradimento da parte di utenti reali.L’obbiettivo e stato parzialmente raggiunto perche e stata conclusa la definizione teoricadel formalismo ma non e stato completato lo strumento progettato per la validazionedel formalismo tramite l’utilizzo da parte degli utenti.
Il lavoro, svolto presso il Machine Learning Lab1 dell’Universita di Trieste, e statosuddiviso nelle seguenti parti: scelta del social network di riferimento per il reperimentodei dati, in base all’analisi delle Application Program Interface (API) a disposizione perinterfacciarsi al social network; definizione e progettazione della struttura dei dati daottenere al termine dell’estrazione; implementazione di un algoritmo per l’estrazionedei dati; definizione del formalismo per descrivere le regole di filtraggio; progettazionee realizzazione di un’applicazione web da sottoporre ad un gruppo di utenti per rac-cogliere dati utili alla valutazione di efficacia, usabilita e gradimento del formalismoprecedentemente definito.
1http://machinelearning.inginf.units.it/
1
“output” — 2015/5/20 — 14:15 — page 2 — #4
CAPITOLO 1. INTRODUZIONE 2
La scelta del social network e ricaduta su Twitter R© principalmente per i seguentimotivi: la natura pubblica dei suoi dati, la sufficiente documentazione delle APIe la predisposizione all’utilizzo con il linguaggio di programmazione Java. Per laparte riguardante il reperimento dei dati e stata utilizzata principalmente la JavaPlatform Standard Edition 1.7 per la quale era disponibile Twitter4j, una libreria diinterfacciamento alle API di Twitter. Infine l’applicazione web e stata realizzata soloparzialmente, utilizzando per il frontend il framework MVC AngularJS, per il backendla piattaforma NodeJS R© e per la gestione dei dati derivanti dall’applicazione e statoutilizzato il DBMS MongoDB.
Il resto del presente documento e strutturato in tre capitoli: nel primo capitolo verradescritto tutto quello che riguarda l’algoritmo per l’estrazione e la strutturazione deidati; nel secondo capitolo verra affrontata la definizione del formalismo per descrivere leregole di filtraggio; il terzo capitolo conterra le informazioni riguardanti progettazione erealizzazione dell’applicazione web.
“output” — 2015/5/20 — 14:15 — page 3 — #5
Capitolo 2
Definizione formale delle regoledi filtraggio
In questo capitolo verra esposto il contesto da cui si e partiti per la definizione di unaregola di filtraggio. Quindi verra descritta la struttura proposta per una regola e glielementi che la compongono. Infine, verranno proposti alcuni esempi di regole formatea partire da una descrizione in linguaggio naturale di cosa si desidererebbe filtrare.
2.1 Contesto e notazione utilizzata
Il problema di fornire agli utenti la possibilita di controllare i contenuti che vengonovisualizzati nel proprio spazio in un social network e oggetto di studio nella comunitascientifica come gia evidenziato nell’introduzione. Nel lavoro presentato in [8], gli autoriaffrontano questo problema proponendo un sistema per permettere agli utenti di ungenerico social network di avere il controllo su cio che viene pubblicato nello spazioa loro riservato sul social network. Prendendo come riferimento questo lavoro e illinguaggio proposto in [9] per definire regole in un altro ambito, verra illustrato qui unformalismo per la definizione di regole di filtraggio di messaggi indesiderati sul propriospazio all’interno di un social network.
Si iniziera definendo la notazione che verra utilizzata nel seguito.
Insiemi legati al problema del filtraggio
M insieme dei messaggi; un messaggio e un testo pubblicato da un utente in unaconversazione
U insieme degli utenti
C insieme delle conversazioni
3
“output” — 2015/5/20 — 14:15 — page 4 — #6
CAPITOLO 2. DEFINIZIONE FORMALE DELLE REGOLE DI FILTRAGGIO 4
T insieme dei topic; per topic si intende un argomento di discussione. Questi topic nonsono presenti nei dati disponibili sul social network ma vengono assegnati in fasedi analisi del testo di un messaggio, a partire da un insieme predefinito.
Insiemi definiti staticamente
R insieme delle relazioni; contiene due tipi di relazione {segue, eSeguito}
Ltxt insieme delle etichette per il testo; le etichette descrivono informazioni chenon sono legate direttamente all’argomento contenuto nel testo come, ad esem-pio: volgare, georeferenziato, contieneImmagini, contieneLink,nonContieneTesto. Queste etichette non sono presenti nei dati disponibi-li sul social network ma vengono assegnate in fase di analisi del testo di unmessaggio, a partire dall’insieme predefinito elencato sopra.
Luser insieme delle etichette per gli utenti; le etichette descrivono informazioni aggiun-tive sull’utente come, ad esempio:utenteVerificato, utenteAppenaRegistrato. Queste etichette vengonodefinite e assegnate in base ai dati dell’utente disponibili sul social network.
Funzioni: sono state individuate alcune funzioni per mettere in relazione gli insie-mi definiti nel paragrafo precedente. Queste funzioni verranno utilizzate in seguitoper mostrare in quale maniera viene applicata una regola ad un messaggio di unaconversazione.
AM : M → U funzione di associazione tra utente e messaggio: u = AM (m) significache u e l’autore del messaggio m
AC : C → U funzione di associazione tra utente e conversazione: u = AC(c) significache u e l’autore della conversazione c
TM : M → Set(T ) funzione di associazione tra messaggio e argomenti di discussio-ne(topic): Tm = TM (m) significa che Tm e l’insieme dei topic del messaggiom
TC : C → Set(T ) funzione di associazione tra conversazione e argomenti di discussione:Tc = TM (c) significa che Tc e l’insieme dei topic della conversazione c
TU : U → Set(T ) funzione di associazione tra utente e argomenti di discussione:Tu = TU (u) significa che Tu e l’insieme dei topic dell’utente u
LM : M → Set(Ltxt) funzione di associazione tra etichette e messaggio: Lm = LM (m)significa che Lm e l’insieme di etichette del messaggio m
“output” — 2015/5/20 — 14:15 — page 5 — #7
CAPITOLO 2. DEFINIZIONE FORMALE DELLE REGOLE DI FILTRAGGIO 5
LC : C → Set(Ltxt) funzione di associazione tra etichette e conversazione: Lc = LC(c)significa che Lc e l’insieme delle etichette della conversazione c
LU : U → Set(Luser) funzione di associazione tra etichette e utente: Lu = LU (u)significa che Lu e l’insieme delle etichette dell’utente u
R : U ×U → Set(R) funzione di definizione delle relazioni esistenti tra utenti: Ru1,u2 =R(u1, u2) significa che Ru1,u2 e l’insieme delle relazioni esistenti tra gli utenti u1 eu2
2.2 Formazione di una regola e sua applicazione
Una regola viene definita per mezzo di una tupla di elementi specificati dall’utenteautore della conversazione su cui verra applicata la regola; la tupla e cosı composta
ρ = (Tc, Tm, Lu, Lm, σc,m, σc,um , σuc,um , Ruc,um,, U0) (2.1)
Le componenti della regola hanno il seguente significato
• Tc ⊆ T e l’insieme degli argomenti di discussione riguardanti la conversazione sucui viene applicata la regola
• Tm ⊆ T e l’insieme degli argomenti di discussione riguardanti il messaggio su cuiviene applicata la regola
• Lu ⊆ Luser e l’insieme delle etichette riguardanti l’autore del messaggio su cuiviene applicata la regola
• Lm ⊆ Ltxt e l’insieme delle etichette riguardanti il messaggio su cui viene applicatala regola
• σc,m, σc,um , σuc,um ∈ {true, false} sono tre flag utilizzati per valutare:
– σc,m se la conversazione c e il messaggio m hanno topic in comune
– σc,um se la conversazione c e l’autore um del messaggio sotto esame hannotopic in comune
– σuc,um se l’autore uc della conversazione e l’autore um del messaggio sottoesame hanno topic in comune
• Ruc,um ⊆ R e l’insieme delle relazioni che intercorrono sul social network tral’autore della conversazione uc e l’autore del messaggio um
• U0 ⊆ U e un insieme di utenti del social network
“output” — 2015/5/20 — 14:15 — page 6 — #8
CAPITOLO 2. DEFINIZIONE FORMALE DELLE REGOLE DI FILTRAGGIO 6
Preso in considerazione un messaggio m, esso viene rifiutato (filtrato) in unaconversazione c da una regola ρ se e solo se tutte le condizioni seguenti sono verificate:
1. TC(c) ∩ Tc 6= ∅
2. TM (m) ∩ Tm 6= ∅
3. LU (AM (m)) ∩ Lu 6= ∅
4. LM (m) ∩ Lm 6= ∅
5. ¬σc,m ∨ TC(c) ∩ TM (m) = ∅
6. ¬σc,um ∨ TC(c) ∩ TU (AM (m)) = ∅
7. ¬σuc,um ∨ TU (AC(c)) ∩ TU (AM (m)) = ∅
8. Ruc,um = ∅ ∨ R(AC(c),AM (m)) ∩Ruc,um = ∅
9. AM (m) ∈ U0
2.3 Esempi di regole
In questa sezione verranno forniti alcuni esempi di regole formate partendo da unadescrizione testuale del filtraggio che si vorrebbe eseguire. La descrizione testuale vienefatta dal punto di vista dell’autore della regola che desidera filtrare dei messaggi in unaconversazione di cui e autore.
Rifiuta tutti i messaggi volgari:
(T, T, Luser, {volgare}, false, false, false, ∅, ∅) (2.2)
Rifiuta tutti i messaggi volgari eccetto quelli provenienti dall’utente di none Ghandi:
(T, T, Luser, {volgare}, false, false, false, ∅, U \ {Ghandi}) (2.3)
Rifiuta i messaggi volgari quando io sto parlando di religione e politica:
({religione, politica}, T, Luser, {volgare}, false, false, false, ∅, ∅) (2.4)
Rifiuta tutti i messaggi quando parlo di religione e politica e l’utente che pubblica unmessaggio si e appena registrato:
({religione, politica}, T, {utenteAppenaRegistrato}, Ltxt, false, false, false, ∅, ∅) (2.5)
“output” — 2015/5/20 — 14:15 — page 7 — #9
CAPITOLO 2. DEFINIZIONE FORMALE DELLE REGOLE DI FILTRAGGIO 7
Rifiuta i messaggi volgari quando parlo di sport tranne quei messaggi provenienti dagliutenti che io seguo:
({sport}, T, Luser, {volgare}, false, false, false, {eSeguito}, ∅) (2.6)
Rifiuta tutti i messaggi pubblicati dall’utente Prandelli quando io parlo di sport:
({sport}, T, Luser, Ltxt, false, false, false, ∅, {Prandelli}) (2.7)
Rifiuta tutti i messaggi che parlano di sesso pubblicati da utenti a cui sono associatitopic diversi dai miei:
(T, {sesso}, Luser, Ltxt, false, false, true, ∅, ∅) (2.8)
Rifiuta tutti i messaggi con topic diversi da quelli della conversazione, tranne se sonopubblicati da utenti che mi seguono sul social network:
(T, T, Luser, Ltxt, true, false, false, {segue}, ∅) (2.9)
Rifiuta tutti i messaggi tranne quelli che sono pubblicati da autori che hanno dei topicin comune con me e che sto seguendo:
(T, T, Luser, Ltxt, false, true, false, {eSeguito}, ∅) (2.10)
Rifiuta tutti i messaggi che parlano di basket, tranne quelli pubblicati da utenti checondividono alcuni topic con me:
(T, {basket}, Luser, Ltxt, false, false, true, ∅, ∅) (2.11)
Rifiuta tutti messaggi quando parlo di medicina e i messaggi pubblicati parlano diargomenti diversi da quelli della conversazione, tranne se io seguo l’autore del messaggioo lui segue me:
({medicina}, T, Luser, Ltxt, false, false, true, {segue, eSeguito}, ∅) (2.12)
“output” — 2015/5/20 — 14:15 — page 8 — #10
Capitolo 3
Estrazione dei dati
L’obbiettivo di questa fase era ottenere un dataset da utilizzare nelle fasi successive. Isocial network candidati dai quali estrarre i dati necessari erano Facebook R© e Twitter R©.La scelta e ricaduta sul secondo perche i suoi dati sono a disposizione generalmentein forma pubblica e non soggetti a particolari privacy policy, a meno che l’utente nondisponga diversamente riguardo ai dati legati al suo profilo. Al contrario, Facebookpermette di accedere via API ai dati di altri utenti solo se si e stretta “amicizia” conessi e in ogni caso la disponibilita di informazioni dipende dalle specifiche impostazioniscelte da ogni utente.
3.1 Progettazione algoritmo di estrazione
Una volta individuata la sorgente da cui estrarre i dati, ci si e concentrati sulla definizionedi quali dati si intendeva estrarre. Il social network Twitter permette agli utenti dirispondere a tweet di altri utenti: una o piu risposte ad un tweet compongono, assieme altweet iniziale, una conversazione. Sono state scelte le conversazioni come dato d’interesseperche sembravano il tipo di dato adatto ad essere sottoposto ad operazioni di filtraggio.
A partire da questa considerazione e iniziata la fase di studio delle API esposteda Twitter per individuare l’eventuale esistenza di qualche metodo adatto alla nostraesigenza. Purtroppo non e stato individuato alcun metodo che restituisse conversazionigia formate e si e proseguito definendo un algoritmo che permettesse di raggiungere l’ob-biettivo prefissato, mediante l’utilizzo combinato di piu metodi delle API a disposizione.Nel seguito di questo capitolo verra illustrato l’algoritmo prodotto.
3.1.1 Notazione utilizzata
E necessario dare alcuni definizioni preliminari per delineare lo scenario da cui si epartiti per la definizione dell’algoritmo. Siano:
8
“output” — 2015/5/20 — 14:15 — page 9 — #11
CAPITOLO 3. ESTRAZIONE DEI DATI 9
T l’insieme di tutti i tweet.
U l’insieme di tutti gli utenti.
C l’insieme di tutte le conversazioni: una conversazione e un albero in cui i nodi sonotweet e i rami corrispondono alla relazione di parentela tra i due tweet collegati.Questa relazione viene specificata mediante il campo inReplyToStatusId presentein ogni tweet e descritto nel prossimo punto della lista. Si noti che e solamente iltweet figlio ad avere nozione della parentela verso il tweet padre.
t ∈ T un tweet; nella documentazione delle API viene definito come un oggetto conte-nente dei campi; nel seguito verranno presi in considerazione solo alcuni di questicampi, qui elencati:
id e la rappresentazione in forma di numero intero dell’identificatore univoco deltweet.
inReplyToStatusId se il tweet e una risposta ad un altro tweet, allora questocampo contiene l’identificatore del tweet a cui risponde, altrimenti assumevalore -1.
inReplyToUserId se il tweet e una risposta ad un altro tweet, questo campocontiene l’identificatore univoco dell’autore del tweet a cui risponde, altrimentiassume valore -1.
u ∈ U un utente; nella documentazione delle API viene definito come un oggettocontenente dei campi; nel seguito verranno presi in considerazione solo alcuni diquesti campi, qui elencati:
id e la rappresentazione in forma di numero intero dell’identificatore univocodell’utente.
screen name e l’alias che l’utente utilizza per identificarsi sul social network.
c ∈ C una conversazione.
ρ : C → T ; ρ(c) identifica il tweet radice della conversazione c.
Gli identificatori univoci di tweet e utenti (indicati con id nella lista appena descritta)vengono generati da Twitter e sono composti da un timestamp, un worker number eun sequence number1. Twitter non fornisce garanzia sull’ordinamento totale degli IDgenerati ma solamente sull’ordinamento parziale. Piu precisamente la garanzia fornita eche se due tweet A e B sono pubblicati nello stesso periodo, allora devono avere due IDin stretta vicinanza tra loro. Citando testualmente il blog del team ingegneristico di
1https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake
“output” — 2015/5/20 — 14:15 — page 10 — #12
CAPITOLO 3. ESTRAZIONE DEI DATI 10
Twitter2: “In mathematical terms, although the tweets will no longer be sorted, theywill be k-sorted [10]. We’re aiming to keep our k below 1 second, meaning that tweetsposted within a second of one another will be within a second of one another in the idspace too.”.
3.1.2 Metodi delle API utilizzati
Tra i metodi esposti dalle API, sono stati utilizzati:
getTweet(t.id) che restituisce un singolo tweet, identificato dal suo id, fornito comeparametro.
getContaining(q, count, result type) restituisce count tweet da T per i quali t.text Aq. La scelta del tipo di tweet da restituire dipende dal parametro opzionaleresult type che puo assumere i seguenti valori:
• mixed(valore di default): il dato restituito contiene sia tweet piu popolari siatweet piu recenti
• recent: il dato restituito contiene i tweet piu recenti
• popular: il dato restitutito contiene i tweet piu popolari
Durante l’utilizzo, per il campo result type non e stato necessario fare una sceltaspecifica quindi e stato mantenuto il valore di default(mixed).
I nomi dei metodi sopra riportati sono stati scelti diversi rispetto alla documentazioneufficiale per facilitare la lettura di questo documento; la descrizione precisa e riportatain appendice A.
3.1.3 Obbiettivo da raggiungere e definizione dell’algoritmo
Una volta definito lo scenario, e stato individuato l’obbiettivo specifico che si volevaraggiungere con questo algoritmo di estrazione. Considerando un insieme di partenzaU0 ⊂ U di utenti, si voleva ottenere un insieme C ⊂ C di conversazioni tale da rispettarei seguenti vincoli:
• ∀c ∈ C : |c| ≥ nminNodes, dove |c| e il numero di nodi nell’albero di conversazione c
• |U ′| ≥ nusers, dove U ′ = {u ∈ U : ∃c ∈ C, ρ(c).authorId = u.id}
• ∀u ∈ U ′ : |Cu| ≥ nconversations, dove Cu = {c ∈ C : ρ(c).authorId = u.id}2https://blog.twitter.com/2010/announcing-snowflake
“output” — 2015/5/20 — 14:15 — page 11 — #13
CAPITOLO 3. ESTRAZIONE DEI DATI 11
L’algoritmo e stato suddiviso in piu parti, separate secondo un approccio top-down.Il modulo principale e collectConversations che riceve in ingresso un utentedi partenza u e l’estensione di ricerca nradius
3. Restituisce un insieme di conversazioni.Per ogni utente coinvolto nella ricerca, viene utilizzato il modulo extract-
Conversations il quale riceve in ingresso un utente u e restituisce un insieme diconversazioni in cui u e coinvolto. Al fine di ricostruire singole conversazioni a partireda un tweet viene utilizzato il modulo buildConversation. Questo modulo ricevein ingresso un tweet t e restituisce l’eventuale conversazione di cui t fa parte. Infine,la struttura della conversazione viene creata mediante il modulo Tree che ricevein ingresso una conversazione c e un insieme di tweet T candidati a far parte di c erestituisce la conversazione aggiornata con i tweet in T che ne fanno parte.
Verra ora data una descrizione piu dettagliata dei moduli, ognuno accompagnato daun listato di pseudo-codice. Nel listato 1 viene esposto il punto d’inizio dell’algoritmocomplessivo. Per ognuno degli utenti facenti parte dell’insieme di partenza U0 vieneeseguita la procedura indicata con collectConversations, la quale riceve iningresso l’utente u e l’estensione di ricerca desiderata nradius. Restituisce un insiemecomposto da conversazioni che coinvolgono u e da conversazioni che coinvolgono gli utentifacenti parte delle conversazioni dell’utente iniziale u. Il parametro nradius stabilisce illimite della ricerca di conversazioni.
Listato 1
1: function collectConversations(u, nradius)2: C ←extractConversations(u)3: U ← {u ∈ C}4: Unext ← U5: for i← 1, nradius do6: Cnext ← ∅7: for all u ∈ Unext do8: Cnext ← Cnext ∪ {extractConversations(u)}9: end for
10: Unext ← {u ∈ Cnext} \ U11: U ← U ∪ Unext
12: C ← C ∪ Cnext
13: end for14: return C15: end function
3Per estensione di ricerca si intende il numero di insiemi sui quali viene iterata la ricerca diconversazioni. Ad ogni iterazione vengono memorizzati tutti gli utenti appartenenti alle conversazionicollezionate. Al termine dell’iterazione corrente viene costruito l’insieme degli utenti non ancoraincontrati nelle ricerche precedenti. Su questo insieme viene effettuata una nuova ricerca.
“output” — 2015/5/20 — 14:15 — page 12 — #14
CAPITOLO 3. ESTRAZIONE DEI DATI 12
Nel listato 2 viene esposta la procedura extractConversations utilizzatanel listato precedente. Essa restituisce un insieme di conversazioni in cui e coinvoltol’utente u, fornito come parametro d’ingresso.
Listato 2
1: function extractConversations(u)2: C ← ∅3: T ←getContaining(@u.name, nciting)4: for all t ∈ T do5: C ← C ∪ {buildConversation(t)}6: end for7: return C8: end function
In extractConversations viene usata la funzione denominata buildCon-versation (listato 3) il cui scopo e ricostruire una conversazione. Infatti, a partiredal tweet fornito in ingresso questa funzione verifica se esso e un tweet in risposta ad unaltro tweet. In caso negativo, viene restituita una conversazione degenere formata daun solo tweet. In caso affermativo, viene tentato il recupero del tweet padre nell’alberodi conversazione considerato e viene continuata la ricostruzione dell’albero.
Si era intenzionati a ricostruire la conversazione piu completa possibile cioe a cercaredi recuperare la maggior parte dei tweet in essa inclusi assieme al tweet radice cheha dato origine alla conversazione stessa. Questo risultato non e sempre ottenibileprincipalmente a causa del fatto che Twitter non garantisce la disponibilita, tramite imetodi di ricerca, di tutti i tweet potenzialmente disponibili. Inoltre esiste la possibilitache alcuni tweet non siano piu disponibili oppure protetti dall’utente che li ha pubblicati,cioe resi disponibili solo agli utenti che sono in relazione con lui.
Quindi, al fine di ottenere la conversazione piu completa possibile, per ognuno deitweet ti gia inseriti nella conversazione, viene eseguita un’estrazione di tweet che citanol’autore del tweet ti e tra questi vengono cercati quelli appartenenti alla conversazione einseriti in essa. In questo caso la procedura termina quando e stata raggiunta la radicedella conversazione, cioe il tweet che l’ha originata.
Infine viene presentata nel listato 4 la funzione Tree, che e il cuore della ricostru-zione dell’albero di conversazione. Riceve in ingresso una conversazione e un’insiemedi tweet dei quali bisogna verificare l’eventuale appartenenza alla conversazione e laloro collocazione al suo interno. Se questo insieme contiene piu di un tweet allora vieneinnanzitutto selezionato il sottoinsieme dei tweet che sono delle risposte. In questoinsieme e necessario scegliere un tweet da cui iniziare la ricostruzione.
Quest’ultima scelta e stata fatta nel modo seguente. Considerata la garanzia diordinamento parziale dei tweet in base agli ID fornita da Twitter (descritta nellasezione 3.1.1) invece di scegliere senza criterio un tweet da cui iniziare la ricostruzione,
“output” — 2015/5/20 — 14:15 — page 13 — #15
CAPITOLO 3. ESTRAZIONE DEI DATI 13
Listato 3
1: function buildConversation(t)2: c←tree(c, {t})3: if t.inReplyToStatusId 6= ∅ then4: while t.inReplyToStatusId 6= ∅ do5: t←getTweet(t.inReplyToStatusId)6: c←tree(c, {t})7: end while8: Tnext ← {t ∈ c}9: while Tnext 6= ∅ do
10: for all ti ∈ Tnext do11: T ′ ←getContaining(@ti.authorName, nciting)12: cnew ←tree(c, T ′)13: end for14: Tnext ← {t ∈ {cnew \ c}}15: c← cnew16: end while17: end if18: return c19: end function
e sembrato ragionevole supporre che la scelta di un tweet con identificatore di valorealto aumentasse la probabilita di trovarsi lontano dalla radice e portasse a ricostruire lamaggior parte della conversazione possibile.
Una volta inizializzata la conversazione, vengono esaminati tutti i tweet del sottoin-sieme contenente i tweet che sono risposte, confrontandoli con quelli appartenenti allaconversazione in esame. Nel confronto si verifica se il tweet candidato e in relazione conuno di quelli gia presenti e, in caso affermativo, lo si inserisce nella posizione correttaall’interno della conversazione.
3.2 Dettagli implementativi ed esecutivi
L’implementazione dell’algoritmo di estrazione e stata fatta in linguaggio Java versione1.7 perche il laureando aveva maggiore dimestichezza con questo linguaggio ed inoltreera disponibile una libreria non ufficiale (Twitter4j) per l’interfacciamento alle API diTwitter.
E stata scelta questa libreria perche fornisce alcune funzionalita ritenute utili per losviluppo e che altrimenti sarebbe stato necessario sviluppare autonomamente: aperturadella connessione verso le API, gestione dell’autenticazione, formazione degli URLcorretti a seconda dell’endpoint da contattare.
“output” — 2015/5/20 — 14:15 — page 14 — #16
CAPITOLO 3. ESTRAZIONE DEI DATI 14
Listato 4
1: function tree(c, T )2: if c = ∅ then3: if |T | = 1 then4: c← {t ∈ T}5: return c6: else if |T | > 1 then7: T ′ ← ∅8: for all t ∈ T do9: if t.inReplyToStatusId 6= ∅ then
10: T ′ ← T ′ ∪ t11: end if12: end for13: c←maxId(T ′)14: end if15: end if16: for all t ∈ T do17: for all tc ∈ c do18: if t.id = tc.id then19: T ← T \ {t}20: end if21: if t.inReplyToStausId = tc.id then22: tc.isFatherOf(t)23: t.isChildOf(tc)24: c← {tc, t}25: end if26: if tc.inReplyToStausId = t.id then27: t.isFatherOf(tc)28: tc.isChildOf(t)29: c← {tc, t}30: end if31: end for32: end for33: return c34: end function
“output” — 2015/5/20 — 14:15 — page 15 — #17
CAPITOLO 3. ESTRAZIONE DEI DATI 15
Non si include all’interno di questo documento una descrizione puntuale del codiceJava sviluppato perche esso corrisponde a quanto descritto nella sezione precedente.L’unica osservazione da aggiungere e che e stato necessario gestire i limiti temporalie quantitativi che Twitter impone per accedere alle API senza incorrere in sanzionicoercitive (blocco dell’indirizzo IP e dell’account Twitter tramite i quali si stannocontattando gli endpoint delle API).
Per gestire questi limiti il social network fornisce le informazioni sulla situazione incorso mediante l’utilizzo di alcuni header HTTP delle risposte che invia. Nel dettaglio,vengono forniti:
1. il limite massimo di richieste raggiungibile per il tipo di richiesta effettuato
2. la quantita di richieste ancora disponibili per quel tipo di richiesta, nella finestratemporale in cui ci si trova
3. il tempo rimanente prima dell’esaurimento della finestra temporale corrente
Per evitare di incorrere in un blocco della ricerca, queste informazioni sono statecostantemente monitorate in modo da sospendere temporaneamente la ricerca in casodi raggiungimento del limite imposto. Una volta terminata una finestra temporale, ilconteggio delle richieste effettuate viene azzerato dal social network, permettendo cosıdi riprendere la ricerca.
Un’ulteriore conseguenza di queste limitazioni e stata la necessita di eseguire ilcodice sviluppato su un calcolatore costantemente collegato a internet. Infatti, siccomela formazione del dataset ha richiesto di accedere in maniera intensiva alle API e statonecessario che il sistema sviluppato potesse stare in esecuzione a lungo per raccogliere idati rispettando i limiti sopra descritti.
Dopo aver testato alcune combinazioni di parametri, l’esecuzione finale e stataeseguita con i seguenti parametri:
• l’account da cui e iniziata la ricerca e stato quello di Oprah Winfrey, conduttricetelevisiva statunitense, perche possedeva un elevato numero di follower su Twitter(circa 27 milioni)
• numero di tweet che citano un certo utente: nciting = 100
• numeri di utenti autori di conversazioni da collezionare (cioe autori della radicedella conversazione): 100
• numero di conversazioni da collezionare per ogni utente autore di conversazioni: 5
• raggio di estensione della ricerca: nradius = 3
“output” — 2015/5/20 — 14:15 — page 16 — #18
CAPITOLO 3. ESTRAZIONE DEI DATI 16
I parametri sopra elencati sono stati scelti senza poter valutare l’effettiva disponibilitadi queste quantita di dati sul social network. Infatti dopo circa 72 ore di esecuzione laformazione del dataset non era ancora stata completata e si e deciso di interromperel’esecuzione mantenendo anche i dati che non rispettavano i parametri specificati.Al termine di disponeva di soli 6 utenti autori di conversazioni per cui erano statecollezionate almeno 100 conversazioni da almeno 5 tweet. Complessivamente sono statecollezionate 23627 conversazioni la cui dimensione varia tra 1 tweet (conversazione“degenere”) e 107 tweet.
Il dataset e stato salvato su disco creando una cartella per ogni utente autore diconversazioni, contenente le conversazioni da lui originate in formato JSON (JavaScriptObject Notation) perche e il formato in cui Twitter restituisce i dati richiesti ed era difacile gestione in Java tramite la libreria Google Gson.
“output” — 2015/5/20 — 14:15 — page 17 — #19
Capitolo 4
Validazione del formalismo
4.1 Progettazione
Una volta definito il formalismo si e voluta individuare una maniera per valutarel’usabilita e l’efficacia della descrizione teorica presentata nel capitolo 3. Inoltre si volevatentare di valutare il gradimento di un utente reale a cui venga proposto di utilizzareun’implementazione del sistema di filtraggio.
Per svolgere questo parte del lavoro di tesi si e scelto di procedere nel modo seguente.A partire dal risultato dell’estrazione presentato nel capitolo 3, e stato selezionato unsottoinsieme di conversazioni. Questa selezione e stata fatta manualmente, scegliendoconversazioni composte da almeno cinque messaggi in modo che il filtraggio non divenissebanale. Oltre che in base alla loro lunghezza, le conversazioni sono state selezionate inmaniera che il contenuto fosse abbastanza comprensibile e contenesse del testo. Infattispesso i messaggi visualizzati nel corso della selezione contenevano abbreviazioni, parolecontratte o altri tipi di contenuti che rendevano il messaggio povero, se non addiritturaprivo, di significato.
Effettuata la selezione, sono state aggiunte alcune informazioni di contesto chepotrebbero essere coinvolte in una regola ma non erano comprese nei dati estratti:ad ogni utente e ad ogni messaggio sono stati assegnati i topic e le etichette che siritenevano piu opportuni. Questa scelta e stata fatta in maniera parzialmente arbitraria,in particolare per gli utenti, perche non si disponeva di abbastanza informazioni chepermettessero di definire una sorta di profilo dell’utente e quindi assegnare dei topic edelle etichette piu appropriati. Il fatto che queste informazioni non siano veritiere noninfluisce negativamente sulla validazione perche l’obbiettivo non era creare un ambientecompletamente aderente alla realta.
Completata la selezione delle conversazioni, ad ognuna di esse e stata associata unadescrizione testuale del filtraggio da effettuare. E stata fatta questa scelta in modo dapoter assegnare a diversi utenti reali lo stesso compito e raccogliere informazioni su
17
“output” — 2015/5/20 — 14:15 — page 18 — #20
CAPITOLO 4. VALIDAZIONE DEL FORMALISMO 18
come esso viene portato a termine. Per brevita, nel seguito la coppia conversazione efiltraggio da effettuare verra indicata con il termine task.
Ad ogni utente reale che partecipera al test verra proposto piu di un task e verrannoraccolti alcuni dati sull’utilizzo. Durante il test l’utente impersonera l’autore dellaconversazione. I dati ritenuti rilevanti da raccogliere per una successiva valutazionesono i seguenti:
1. task assegnato all’utente
2. numero di operazioni che l’utente effettua sulle regole: creazioni, eliminazioni emodifiche
3. tempo di esecuzione del task assegnato
4.2 Implementazione
Per far svolgere i task agli utenti reali si e scelto di realizzare un’applicazione web la cuiinterfaccia grafica permettesse all’utente di visualizzare la conversazione, le informazionidi contesto e il lavoro da svolgere. Oltre alla visualizzazione e stato implementato unpannello di creazione e gestione delle regole in modo che l’utente possa visualizzare intempo reale il risultato che producono le regole create sulla conversazione oggetto difiltraggio. L’interfaccia complessiva riportata in figura 4.1
Figura 4.1: Interfaccia utente complessiva
“output” — 2015/5/20 — 14:15 — page 19 — #21
CAPITOLO 4. VALIDAZIONE DEL FORMALISMO 19
Nella sezione in alto a sinistra, presentata in figura 4.2, viene indicato all’utentequale filtraggio deve svolgere, qual e il suo ruolo nella conversazione e le informazioniche riguardano l’utente che deve impersonare.
Figura 4.2: Sezione dell’interfaccia in alto a sinistra
Nella sezione in alto a destra, presentata in figura 4.3, vengono mostrati all’utentegli altri partecipanti alla conversazione con le informazioni che li riguardano e chepotrebbero essere oggetto del filtraggio da eseguire. Inoltre e presente il tasto Nextconversation che permette all’utente di proseguire con il task successivo.
Figura 4.3: Sezione dell’interfaccia in alto a destra
Nella parte bassa dell’interfaccia viene presentato a sinistra il pannello contenentela conversazione su cui l’utente deve operare (figura 4.4). Ogni messaggio e la conversa-zione stessa contengono, a lato del testo, i topic contrassegnati in rosso e le etichettecontrassegnate in grigio. A destra e posizionato il pannello delle regole, con il qualel’utente puo interagire (figura 4.5).
I singoli messaggi che devono essere filtrati secondo le istruzioni fornite all’utentesono contraddistinti da un bordo tratteggiato e una croce, entrambe di colore rossocome si puo vedere nell’esempio di figura 4.6.
“output” — 2015/5/20 — 14:15 — page 20 — #22
CAPITOLO 4. VALIDAZIONE DEL FORMALISMO 20
Figura 4.4: Pannello della conversazione
Figura 4.5: Pannello delle regole vuoto
Figura 4.6: Esempio di tweet contrassegnato come da filtrare
“output” — 2015/5/20 — 14:15 — page 21 — #23
CAPITOLO 4. VALIDAZIONE DEL FORMALISMO 21
Una volta creata una regola, all’utente viene presentata la regola appena creatavuota (figura 4.7) con la possibilita di aggiungere delle elementi alla regola mediante iltasto Add rule element (figura 4.8).
Figura 4.7: Nuova regola senza elementi
Figura 4.8: Selezione dell’elemento da aggiungere alla regola
Nell’esempio mostrato in figura 4.9, l’utente ha aggiunto un elemento alla regola edeve selezionare un valore da assegnargli. Una volta eseguita la selezione e resa attivala regola premendo sul taso OFF a lato del nome della regola, l’utente potra vederenel pannello della conversazione il risultato del filtraggio che ha impostato (figura 4.10).All’utente che sta operando viene fornita anche la possibilita di eliminare elementi dauna regola mediante il tasto arancione a destra in figura 4.9 oppure di eliminare laregola stessa mediante il tasto Delete Rule presente a destra del tasto Add rule element.
“output” — 2015/5/20 — 14:15 — page 22 — #24
CAPITOLO 4. VALIDAZIONE DEL FORMALISMO 22
Figura 4.9: Elemento selezionato in fase di arricchimento
Figura 4.10: Visualizzazione di un messaggio filtrato
4.2.1 Dettagli implementativi
La parte lato client dell’applicazione e stata realizzata utilizzando il front-end frameworkTwitter Bootstrap assieme al web application framework MVC AngularJS. La partelato server e stata realizzata con il framework NodeJS e il DBMS NoSQL MongoDB.
La componente lato server e composta da un applicazione che espone due URLendpoint: /api/conversation e /api/save. Il primo endpoint viene contattato all’inizio diuna sessione di lavoro di un utente e ogni volta che l’utente conclude un task. Questoendpoint restituisce un nuovo task da svolgere.
Per scegliere quale task restituire tra quelli disponibili, e stata realizzata una strutturadati circolare: ad ogni richiesta ricevuta, viene aggiornato il puntatore al prossimotask e restituito il task corrispondente. E stato realizzato questo sistema per far fronteall’utilizzo in rapida successione da parte di piu utenti e per fare in modo che i diversitask venissero serviti nella maniera piu uniforme possibile.
Il secondo endpoint viene contattato quanto l’utente sceglie di concludere il task insvolgimento. La pressione del tasto Next conversation provoca una richiesta HTTP ditipo POST verso l’URL dell’endpoint. Dal payload della richiesta vengono estratti i daticorrispondenti al task svolto e salvati su un’istanza di database. Conclusa l’interazioneHTTP necessaria per il salvataggio dei dati viene contattato il primo endpoint perricevere il prossimo task da presentare all’utente.
“output” — 2015/5/20 — 14:15 — page 23 — #25
Capitolo 5
Conclusioni
L’obiettivo presentato nell’introduzione e stato parzialmente raggiunto. Infatti si egiunti alla definizione del formalismo per formare le regole di filtraggio ma non e statacompletata l’implementazione da utilizzare per la validazione del formalismo con utentireali. Rimane da implementare la logica applicativa necessaria per utilizzare alcunielementi delle regole durante la loro creazione.
La mancanza di questa parte di logica non ha permesso di iniziare la validazione conutenti reali, in modo da poter raccogliere i dati che sono stati descritti nel capitolo 4.Senza questi dati, non e stato possibile effettuare la valutazione che era stata preventivata,riguardante la bonta del formalismo proposto.
Il mancato raggiungimento dell’obbiettivo e dovuto principalmente al fatto che lafase di estrazione dei dati (capitolo 3) ha assorbito una quantita di tempo piu lunga diquella prevista. In particolare l’interfacciamento alle API di Twitter ha richiesto maggiorattenzione nello sviluppo e alcune correzioni dell’approccio inizialmente pianificato, adiscapito delle fasi successive.
23
“output” — 2015/5/20 — 14:15 — page 24 — #26
Appendice A
Interfacciamento alle TwitterAPI
In questa appendice verranno descritti in maniera piu approfondita ma non esaustiva imetodi delle API utilizzati nella fase d’estrazione e citati nel capitolo 3.
Il metodo che e stato denominato per brevita getTweet(t.id) nel paragrafo 3.1.2corrisponde all’endpoint https://api.twitter.com/1.1/statuses/show.json. Questo endpointha le seguenti specifiche e limitazioni:
Formato della risposta JSON
Richiesta autenticazione? Sı
Tasso richieste limitato? Sı
Richieste/15 minuti (autenticazione utente) 180
Richieste/15 minuti (autenticazione app) 180
La query che si vuole effettuare va accodata all’URL dell’endpoint come, ad esem-pio: https://api.twitter.com/1.1/statuses/show.json?id=210462857140252672. La queryd’esempio corrisponde a cercare un tweet il cui ID corrisponde a 210462857140252672.Il risultato di questa ricerca comprende anche le informazioni riguardanti l’utenteautore del tweet. Sono disponibili altri parametri opzionali che non vengono appro-fonditi in questo documento. Per ulteriori informazioni e possibile fare riferimento ahttps://dev.twitter.com/rest/reference/get/statuses/show/%3Aid.
Il metodo che e stato denominato per brevita getContaining(q, count, result type)nel paragrafo 3.1.2 corrisponde all’endpoint https://api.twitter.com/1.1/search/tweets.json. I parametri utilizzati corrispondono a:
• q corrisponde alla query che si vuole effettuare
24
“output” — 2015/5/20 — 14:15 — page 25 — #27
APPENDICE A. INTERFACCIAMENTO ALLE TWITTER API 25
• count e il numero di tweet secondo cui la risposta verra suddivisa in “pagine”;Twitter utilizza una tecnica chiamata “cursoring”1 per suddividere grandi quantitadi risultati, permettendo lo scorrimento tra le varie parti.
• result type specifica il tipo di tweet che si vuole ottenere; puo assumere i seguentivalori:
– mixed(valore di default): il dato restituito contiene sia tweet piu popolari siatweet piu recenti
– recent: il dato restituito contiene i tweet piu recenti
– popular: il dato restituito contiene i tweet piu popolari
Questo endpoint ha le seguenti specifiche e limitazioni:
Formato della risposta JSON
Richiesta autenticazione? Sı
Tasso richieste limitato? Sı
Richieste/15 minuti (autenticazione utente) 180
Richieste/15 minuti (autenticazione app) 450
La query che si vuole effettuare verso questo endpoint va accodata all’URL dell’end-point come, ad esempio:https://api.twitter.com/1.1/search/tweets.json?q=%23freebandnames.
La query d’esempio corrisponde a cercare dei tweet che contengano il testo “#free-bandnames”. Il formato della query deve sottostare ai seguenti vincoli: deve esserecodificata in UTF-8, convertita in un formato adeguato ad essere incluso in un URL (URL-encoded) e contenere al massimo 500 caratteri. La risposta restituita contiene un’insiemedi tweet che rispettano i parametri della richiesta. Sono disponibili altri parametriopzionali che non vengono approfonditi in questo documento. Per ulteriori informazionie possibile fare riferimento a https://dev.twitter.com/rest/reference/get/search/tweets.
1https://dev.twitter.com/overview/api/cursoring
“output” — 2015/5/20 — 14:15 — page 26 — #28
Bibliografia
[1] Alex Hern. Twitter CEO: We suck at dealing with trolls andabuse, 2105. URL: http://www.theguardian.com/technology/2015/feb/05/twitter-ceo-we-suck-dealing-with-trolls-abuse. [1]
[2] Ryadh Dahimene, Cedric Du Mouza, and Michel Scholl. Efficient filtering inmicro-blogging systems: We won’t get flooded again. In Scientific and StatisticalDatabase Management, pages 168–176. Springer, 2012. [1]
[3] Ibrahim Uysal and W Bruce Croft. User oriented tweet ranking: a filteringapproach to microblogs. In Proceedings of the 20th ACM international conferenceon Information and knowledge management, pages 2261–2264. ACM, 2011. [1]
[4] Jonghyuk Song, Sangho Lee, and Jong Kim. Spam filtering in twitter using sender-receiver relationship. In Recent Advances in Intrusion Detection, pages 301–317.Springer Berlin Heidelberg, 2011. [1]
[5] Bharath Sriram, Dave Fuhry, Engin Demir, Hakan Ferhatosmanoglu, and MuratDemirbas. Short text classification in twitter to improve information filtering. InProceedings of the 33rd international ACM SIGIR conference on Research anddevelopment in information retrieval, pages 841–842. ACM, 2010. [1]
[6] Gorrell P Cheek and Mohamed Shehab. Human effects of enhanced privacymanagement models. Dependable and Secure Computing, IEEE Transactions on,11(2):142–154, 2014. [1]
[7] Anna C Squicciarini, Mohamed Shehab, and Joshua Wede. Privacy policies forshared content in social network sites. The VLDB Journal—The InternationalJournal on Very Large Data Bases, 19(6):777–796, 2010. [1]
[8] Marco Vanetti, Elisabetta Binaghi, Elena Ferrari, Barbara Carminati, and MorenoCarullo. A system to filter unwanted messages from osn user walls. Knowledge andData Engineering, IEEE Transactions on, 25(2):285–297, 2013. [3]
26
“output” — 2015/5/20 — 14:15 — page 27 — #29
BIBLIOGRAFIA 27
[9] Eric Medvet, Alberto Bartoli, Barbara Carminati, and Elena Ferrari. Evolutionaryinference of attribute-based access control policies. In Evolutionary Multi-CriterionOptimization, pages 351–365. Springer, 2015. [3]
[10] Tom Altman and Yoshihide Igarashi. Roughly sorting: Sequential and parallelapproach. Journal of information processing, 12(2):154–158, aug 1989. [10]
