Universidade Federal de Ouro Preto - UFOP Instituto de Ciéncias Exatas ¢ Biolégicas - ICEB Departamento de Computagio - DECOM UMA FERRAMENTA PARA PROCESSAMENTO DE CONSULTAS MULTIDIMENSIONAIS PARA DADOS DE: REDES SOCIAIS Aluno: Milton Stiilpen Jtinior Matricula: 07.1.4171 Orientador: Alvaro Rodrigues Pereira Jinior Ouro Preto 19 de dezembro de 2011Universidade Federal de Ouro Preto - UFOP Instituto de Ciéncias Exatas ¢ Biolégicas - ICEB Departamento de Computagio - DECOM UMA FERRAMENTA PARA PROCESSAMENTO DE CONSULTAS MULTIDIMENSIONAIS PARA DADOS DE REDES SOCIAIS Relatorio de atividades desenvolvidas apre- sentado ao curso de Bacharelado em Ci- éncia da Computagio, Universidade Fede- ral de Ouro Preto, como requisito parcial para a conclusao da disciplina Monografia T (BCC390). Aluno: Milton Stiilpen Junior Matricula: 07.1.4171 Orientador: Alvaro Rodrigues Pereira Jinior Ouro Preto 19 de dezembro de 2011Resumo As redes sociais sempre foram alvo de pesquisa, principalmente por parte dos socidlogos. Hoje, com a eminéncia do poder computacional, a Web tornou-se capaz de conectar as diversas partes do globo, possibilitando assim a coleta ¢ andilise de um rico universo de dados da massas de u is tem, dia aps dia, se mostrado factivel ¢ valoroso para os pesquisadores da Ciducia da Computagao. Dessa forma, 0 que sera proposto nesse trabalho de conchisio de curso 6 uma ferramenta para processamento de cousultas multidimensionais para dados de redes sociais. Palavras-chave: Recuperagio de Informagio na Web, Redes Sociais. Engenharia de Software. Sistemas Distribuidos. rios que nela navegam. Assim, o estudo de redes sociSumario 1 Introdugio 2 Justificativa 3. Objetivos 3.1 Objetivo geral 3.2 Objetivos espectlicos 4 Metodologia 5 Cronograma de atividades 6 Desenvolvimento 6.1 Base de dados 62 Tmplementagio Versio 1 63. Implementacdo Versio 2 6A Implementacao Versio 3. . 7 Trabalhos Futuros ee oLista de Figuras 1 Diagrama de Componentes atnal da Ferramenta 2 Interface Grafica da Ferramentas Lista de Tabelas Reqnisitos ... . Cronograma de Atividades. 3 Exemplo de Dupla de Atributos-Indice Textual 4 Exemplo de Tupla de Atributos-Indice Estruturado1 Introdugao Encontra c, na atnalidade, uma explosao de informagoes gragas a existéncia de diversas redes em escala mundial e de “xigantes” que trabalham os dados oriundos destas, como, a titnlo de exemplo, a Google © 0 Facebook. Pode-se dizer que as pessoas acrescentam diariamente contefido na Internet, seja alguma noticia, seja um comentério on opiniao sobre politica, religiio, seus gostos ¢ interesses, humor ete|5]. Sem contar a interagio que existe entre as pessoas, principalmente em redes sociais. Eo melhor de tudo: quase todos esses dads silo piblicos ¢ relativamente faceis de se coletar! [12] Nem sempre, no entanto, foi assim. Outrora, a dificuldade de se obter dados era assustadora se comparada com 0 agora, Obstéculos geogrificos, pessoais, culturais, entre outros, atrapalhavam uma andlise mais abrangente de uma rede social. A coleta de informag6es normalmente era Feita por questiondrios e demandava tempo. Seu fim principal, contudo, nao deixou de ser o mesmo: possibilitar o estudo aprofundado do comportamento humano, No easo das redes sociais online, 0 estudo dos dados de uso de io podem trazer diversas oportunidades. Kerramentas de tomada de decisio, melliorias no design de interagio de um sistema, otimizagio em sistemas distribuidos @ redes, ricos estudos de interagao social [4] etc. Logo, nés, cientistas da computagio, através de algoritinos ¢ estruturas de dados, temos a capacidade de desenvolver uma ferramenta capaz de coletar informacoes do provedor web e, a partir dessa, estruturar ¢ analisar tais dados . E 0 que propomos nesse projeto. Desenvolver uma ferramenta extensivel para a coleta ¢ analise de redes soviais. uuu usual2 Justificativa Por que os dados de redes sociais sio importantes? Consoante Nielsen Online|10), a cada cinco usuarios ativos da Internet, quatro visitam redes so Os norte- americanos gastam mais tempo no Facebook do que em qualquer ontro site dos Es- tados Unidos. LA, aplicativos de redes sociais estao entre os trés mais utilizados em smartphones. E podem-se ver esses dados repetirem no dia a dia. O mundo encontra-se interligado através de varias redes sociais online[2]. Dois tercos da populagao online global visita ou participa de tais redes. O crescimento dessa Area trouxe consigo 0 interesse dos cientistas, que comecaram a pesquisar sobre o tema. Nao obstante, 0 estudo em si ainda esta ua sua “infincia” [3] Por que criar uma ferramenta? O foco do estudo ainda nao é espeeifico. Todavia uma ferramenta desse porte abre portas para uma série de estudos mais aprofunda dos, como, por exemplo: andlise de sentimentos [6]; propagagio de mensagens [11]; “previsiio” de noticias [9] ete. Sem contar com a prépria engenharia por tras da ferra. menta, que envolve Areas como Reeuperagio de Informacao ua. Web(coletores, indices ertidos, similaridade de doenmentos), Sistemas Distribuidos e Engenharia de Soft- ware(padroes de projeto). A ideia de desenvolver uma ferramenta que tenha funcionalidades como consulta textuais, consultas estruturadas, agregador de valores, graficos ¢ mapas sobre dados de redes sociais se mostra, portanto, siginificativamente interessante.3 > Objetivos 3.1 Objetivo geral objetivo, em linhas gerais, ¢ chegar ao final da Monografia UI (BCC 391) com um sistema web sdlido de anslise dos dados de redes sociais, que soja capaz de armazenar c consultar algumas milhdes de mensagens, em tempo real. A ferramenta 6, de forma genérica, um sistema no padrao de arquitetura Model-View-Presenter|| (MVP), mais especificamente uma variante acrescida de dois médulos auxiliares. Os componentes que conterd yao da coleta até a visualizagdo de gréficos e mapas, conforme ilustra © Diagrama de Componentes ua Figura 1. A solugio pode ¢ deve receber alteragies, sempre com a intengio de melhorias. Na proxima seco, sera explicada cada parte da arquitetura proposta. Renee | > Conaita be] fe5| posleados Fignra 1: Diagrama de Componentes atual da Ferramenta3.2 Objetivos espectficos '* Model: O médulo de base de dados, nomeado Model, ¢ 0 responsivel por definir os dados a serem apresentados. Possui dois tipos de bancos de dados: Estruturados © Nio Estruturados. Para a parte Estruturada, utilizamos 0 JCubing. Pela segunda, por sua vez, utilizamos 0 Apacke Lucene. Ambos serao explanados a frent © QueryPresenter: Médulo uomeado QueryPresenter atua como mediador de requi- Bes /respostas. Ele recebe requic&o da camada View, 6 responsavel por recuperar os dados da camada Model e formati-los para serem visualizados. Fle possui pa- cotes de pesquisa de dados, searcher (pela parte nfo estruturada) ¢ cube (pela parte estruturada) ¢ um pacote, dataCombiner, que faz a combinacao dos resul- tados das pesquisas e formatacao dos dados para a View. E tudo é eucapsulado em um Servlet (componente servidor do sistema). © QueryView: Médulo nomeado QueryView @ a interface que gera a visualizagio dos dados ¢ monitora comando de usuérios (eventos) para a camada Presenter atuar buscando os dados a serem apresentados. Desenvolvido no ambiente Web, baseado em bibliotecas JavaScript: jQuery, JS Charts e Google Maps. * Cache: Levando em consideracao que o processamento das pequisas pode ser cus- toso, devido a sna natureza, o modulo denomidado Cache 6 um componente para evitar que consultas comumente realizadas sejam sempre computadas. Assim, resultado da pesquisa feita por um usario ¢ instantaneamente mostrado, Esse componente é baseado na biblioteca «Java Caching System. * Crawler: O modulo de coleta de dados, nomeado Crawler, sera responsavel por prover dados ao Model sempre que for requisitado. A existencia desse médulo € possivel gragas as Aplicagdes de Programagao de Aplicativos (API), providas pelas Redes Sociais, como FacebookAPT e TwitterA PT. Mlém desse pacote de coleta via API, existe um pacote de intepretador dos dados coletados e um pacote qne ir analisa-los ¢ classifics-los, para que possam ser adicionados ao nosso modelo de dados.4 Metodologia A motodologia utilizada nesse projeto para o desenvolvimento da ferramenta vem cres- cendo constantemente na Engenharia de Software: o Serum. Consiste em uma meto- dologia de gerenciamento ¢ desenvolvimento de software interativa ¢ incremental. Nos © adaptamos para melhor nos atender nesse projeto. Primeiramente foi desenvolvido um Backlog ¢, a partir deste, ocorreram alguus Sprints ao longo do perfodo. Cada um destes tinha suas tarefas predefinidas e vinha com um entregavel ao fim do mesmo, como podemos ver uo cronograma de atividadades (‘Labela 2). Requisitos 1 Usnirio pode fazer busca por termos; busca com operadores booleanos; busca por proximidade & busea por frase 2 Resultados estariam agregados inicialmente por estado, polaridade anos. Cabe o usuario decidir como agregar 3 Busca avancada; Usuirio especilica como cle quer agregar os dados: », Cidade, Data, Ano, Semestre, Mes, Semana, Dia e até Hora do Resultados serio apresentados em forma de gréficos ¢ mapas Resultados serio salvos para outros ustirios navegarem of a ‘Tabela 1: Requisitos 5 Cronograma de atividades Na Tabcla 2, 0 planejamento feito para o desenvolvimento da ferramenta, Atividades Ago || Set | Out | Nov | Dez Definigao do tema x Sprint 0: Estudo sobre redes sociais xix Sprint 1 Desenvolvimento da arquitetura x Sprint 2: Implementagao Versao 1 Sprint 3: Implementagio Versio 2 x Sprint &: Tmplementagio Versio 3 x Sprint 5: Escrita do relatério final e Apresentacao x ‘Tabela 2: Cronograma de Atividades.6 Desenvolvimento Nesta segao iremos relatar todo o pracesso de desenvolvimento da ferramenta de con- sultas multidimensionais sobre dados de redes sociais. A ideia de se desenvolver essa ferramenta proveio das andlises de contetido realizadas em [5]. Estas, feitas no artigo, foram executadas em uma base de dados através de um programa estatico e sem in- terface gréfica. Ao perceber 0 valor daquelas, surgi a possibilidade de gerar outras anilises e, logo, desenvolver uma ferramenta que as fizesse de maneira dinamica. 6.1 Base de dados Para desenvolver a mencionada ferramenta, a Base de Dados utilizada 6 a mesma em pregada em [5]. Essa base de dados ¢ uma base da Rede Social Twitter com 29,013,854 de tweets de 198,714 usuarios Brasileiros, desde a criagio do Twitter em 2006 até Julho 2009. Cada tweet possi atributos como: Tweet Td, Userld, Mensagem, Estado, Data e Hora. A partir desses atributos, cada tweet passou por um algoritmo de indexac que formaton os dados em dois indices, um estruturado ¢ um nao estruturade. Como indice nao estruturado, foi utilizada a Apache Lucene|8], que 6 uma biblioteca de ma- quina de pesquisa textual bem completa, open source ¢ de alto performance. Com essa biblioteca, foi gerado um {indice textual com duplas (Tabela 3) em que ¢ posstvel fazer pesquisas, a partir de um aplicative de pesquisa provido pela propria biblioteca 0 Tweet Id Mensagem 18019829 Quem NUNCA sonhou com — um —_desses??? htp://bit.ly/sOpsWh * * Tabela 3: Exemplo de Dupla de Atributos-indice Textual JA como indice estruturado, foi utilizada o JCubing, que é uma biblioteca que prove 6 desenvolvimento de modelos ¢ analise multidimensionais de dados, com um eatélogo cheio de técnicas ¢ métodos para computar, atualizar, representar e minerar cubos de dados multidimensionais [7]. Com o JCubing, foi gerado um fudice com tuplas (Labela 4) Tweet | Pol..[ Estadd Regio | Ano | Semestre' Semana | Dia] Horal Data Id 18019829] Pos [SP | Sudeste| 2007) Seml | 03 | Semanal/ 10 [22 | 2007. ‘Tabela 4: Exemplo de Tupla de Atributos-Indice Estruturado E como os atributos de um éu s colunas? otiginaram ¢ © Quando se verificou que um tweet nao possuia um valor para o atributo Estado, foi utilizada uma API do Google Geocoding para determinar a geolocalizagio a partir do campo texto de localizagio no cadastro do usuario que posto o tweet b * A Polaridade de uma mensagem ¢ a ideia de classificd-la como boa ou ruim, como pode ser visto com mais detalhes em [5]. Nesse easo, foram utilizados Emo- ticons para classificar as meusagens. Mensagens que continham Emoticons comoJ om “:-)? foram classifieados como “positivos”. JA mensagens que continham Emoticons como “=(" ou *-(° foram clasificados como “negativos", Mensagens sem Emoticons, a seu turno, foram clasificados na categoria “neutros”. Essa, pois, 6 uma heuristica simples para classificagao de sentimentos, e mesmo assim a classificagdo de positivos/negativos chegou a 2,713,531 de tweets.10% do total * Atributos de Data e Hora em geral foram derivados para que combinagées dife- rentes pudessem ser feitas e assim fosse possivel aumentar o nivel de especifidade de uma consulta no enbo multidimensional 6.2 Implementacao Versio 1 \ partir da Base de dados e da suposta arqui sistema foi feita, modulo a modulo, no sentido bottom-up. Primeiramente, foi desenvolvida a camada Model que encapsnla os indices gerados pela indexacao da Base de Dados. Fim segundo lugar, foi desenvolvido 0 componente QueryPresenter, responsavel por acessar os dados do modelo, formaté-los ¢ envié-los para a camada View do sistema. Nela foram implementados trés pacotes. O primeiro pacote, & 0 de consulta textual. Denominado searcher, esse pacote encapsula classes de Pesquisa de Indice, Analisadores Textuais, Queries de Pesquisa, Documento ¢ Diretério da bibliotecals], eutre outros, com o intuito de facilitar a utiliza ao da busea de Documentos em nosso indice textual. Assim, a pesquisa é executada de maneira simples. A classe principal ¢ a JdealizeSearch, que deve ser instanciada e possui uum método de peqnisa, search, com parametros de entrada do texto consulta ¢ campo a serem pesquisados (em nosso caso 86 existe o campo mensagem). Essa classe, ao ser instanciada, Ie wm arquivo de propriedades, definido, para iniciar as configuragdes de pesquisa desejada de maneira trivial, que sao: ura, a implementagao do ‘© Caminho do fndice que sera pesquisado: O caminho de pesquisa pode ser pasado tanto pelo arquivo de propriedades como também na propria instanciagao do Objeto; © Similaridade Textual: Ao executar uma consulta com dist coeficiente de similaridade deve ser levado em consideragio uicia de edigao, qual © * Top N Documentos: Qual ¢ a quantidade desejada de Documentos encontrados; * Resultado Minimo: Minimo necessario para deseartar 0 resultado com distancia de digo, caso 0 processo ainda ufo tenha terminado: © Verbose: Ativa on desativa 0 log de inicializagio do Objeto. O algoritmo de pesquisa da IdealizeSearch funciona da seguinte maneira: Ao receber os parinetros de pesquisa, sio inicializadas duas Threads. Uma para p de termos ¢ outra para pesquisa aproximada. Cada uma dessas threads passam por um interpretador que gera uma consulta entendida pelo IndexSearch, ¢ @ feito uma consulta em cada uma das Threads. A Thread principal fica aguardando o resultado das Threads de consulta, Quando a Thread de pesquisa exata retorna, ¢ conferido se 0 Minimo de resultado estabelecido @ cumprido. Caso afirmativo, dealizeSearch juisa exataretorna o resultado. Caso contrario, é aguardado o resultado da pesquisa por distancia por edig&o, para que possam ser sugeridas possiveis consultas corretas ao usuario. Assim, apés 0 resultado da Thread com pesquisa aproximada, ha um algoritmo para identificar os termos resultantes de um documento que equivalem a consulta feita pelo usuario. Desse modo retornando esses termos dentro dos top 5 documentos da Thread de pesquisa aproximada, como uma possivel sugestio para o usuario. O segundo pacote, cube, foi desenvolvido ¢ adaptado com a Base de Dados pelo proprio coordenador do projeto JCubing. Foi disponibilizada uma interface: simples de cousulta, chamada Querier, que recebe uma String de consulta e retorna um vetor de mapas~Classe,OpenLongHashSet > onde a Classe sio os nome dos atributos ¢ a OpenLongHashSet contém os ‘Tweet. Ids. O terceiro ¢ ultimo pacote do componente QueryPresenter & responsavel por fazer a combinacdo do resultado dos dois indices ¢ formaté-los, para enviar ao componente QueryView. A classe principal por fazer essa intersegao ¢ a IdealizeIntersection, que recehe como parametros o resultado da pesquisa textual, mais o vetor de mapas que o Querier retornou, ¢ qual o tipo de detalhie o usuario requisiton. A partir desses parametros, acontece uma intersegao ¢, por fim, hé a geragio de uma String, que possui um padrao, com separadores de campos, que sera enviada para que a camada View possa interpreté-la ¢ mostré-la da maneira como bem entender Por motivos de entendimento, eis um exemplo de uma String para a camada supe- rior: “1000%tweets:900;100", em que o “1000” significa quantidade de resultados encon- trados na pesquisa textual e “tweets” como a classe de detalhamento requisitada pelo usuario, “900” sendo a quantidade de tweets positivos, a partir da pesquisa textual e “100” como a quantidade negativa de tweets, a partir da mesma. Logo, tinhamos 0 ferramental completo para exceutar uma consulta. Entretanto ainda faltava um servidor que recebesse consultas ¢ enviasse respostas. Assim, encapsu- lando as classes principais citadas, foi implementada uma Classe que estende a Classe HttpSerelet, da biblioteca Apache Tomcat, para que fosse possivel receber/euviar as requisigdes/respostas Para o componente Query View, nessa primeira versio, apenas uma HTML simples foi implementada, com algumas funcionalidades simples de script. O. usuério pode- ria consultar escrevendo somente um texto ¢ era retornado para cle a quantidade de mensagens positivas ¢ negativas, a partir de sua consulta. A ferramenta tinha sua primeira versio, ¢ logo apareceram problemas. Pela gran- diosidade de dados trabalhados, consultas textuais demoravam cerca de 3 segundos, consnltas multidimmensionais, mais 10 segundos ¢ a fase final de intersegio, em torno de 2 minutos. 6.3 Implementagao Versao 2 A versio dois viria a ser a verso um com uma interface gréfica mais amigével do que a primeira. O componente Query View precisava ser mais que simplesmente uma pagina branca web. Assim, utilizando a biblioteca JavaScript jQuery, foram adicionadas varias funcionalidades a pagina, até entio “estatica”. Baseado na Programagio Orientada a Eventos, a implementacao da camada View tem funcionalidades como exibigio de gnificos ¢ geracio de uma pagina com os dados especificos de wma consulta, para, caso Seja requerido, exporiar as estatisticas para outro ambiente. Além do mais, foitambém implementado uma “Consulta Avancada” para o Usuario, que agora é eapaz de cspecificar ¢ combinar como “quiscr” 0 resultado de sua pesquisa. Assim, de mancira mais intuitiva, 0 usuario pode fazer requisigdes de pesquisa dinamica e seu resultado ja vem disponibilizado em dois tipos de visdes, grificos e textos, Houve uma tentativa de se utilizar a biblioteca Google Maps porém, com alguns problemas e tempo, foi deixada para segundo plano. pied wep (esa) ov reo ena aces starr Queene pede mess t eons ado Ess = Ol ate ome] onete[=] Figura 2: Interface Grafiea da Ferra nentaa 6.4 Implementagio Versio 3 Por iiltimo, apés a implementagio da camada View do sistema, era hora de otimizar todo 0 processo. O primeiro passo a ser dado era descobrir 0 que mais atrasava 0 processamento de uma consulta. Ao perceber que a fase de intersecao dos resultados estava fazendo acesso ao disco rigido para resgatar os Tweet IDs, foi tomada a decisio de que a classe IdealizeSearch seria provedora de uma cache com todos os Tweet ID: com Memdria Prineipal, ja que 0 indice textual atualiza constantemente seus ids pr rigs, por motivos de desempenho,[8]. O segundo passo foi paralelizar todo 0 processo de consultas. O Servlet, ao reeeber uma cor ia uma Thread para a consulta tex- tual, outra para a cousulta do cubo multidimensional ¢ aguarda o resultado das duns. Assim que o resultado chega, ¢ inieiado 0 proceso final de intersegio e formatagio das estatisticas. ‘Lodo esse processo foi paralelizado. Ass cada mapa do vetor resultante da consulta do cubo. Dessa forma, cada thread faz sua lta, ¢1intersecio, classifica e retorna seu resultado. Ao fim de todas as threads, simplesmente siio agregados todos os resultados de cada Thread intersessora. Foram obtidos, portanto, resultados satisfatorios com os tempos de boa parte das: consultas, Estas, que antes demoravam em torno de 2 minutos (¢ até mais), agora giram em cerca de 10 segundos. Dessa maneira foi finalizada a terceira versio do sistema. 7 Trabalhos Futuros Como Trabalhos Agendados, podemos citar o modulo ainda nto implementado, Ca- che, e 0 médulo ainda no finalizado, Crawler. A Cache sera um médulo de acesso rapido que tera algumas politicas de armazenamento de resultados as quais poderao ser configuréveis, Ser desenvolvida a partir da biblioteca Java JCS, Java Caching Sys- tem disponibilizada via Licenga Apache. Ja para o médulo Crawler, seré desenvolvido um analisador de mensagens, com o fin de tornar possivel classificé-las como posit vas/negativas com uma heuristica mais trabalhada, para poder classificar um maior niimero de mensagens ¢ com mais precisiio do que a que foi empregada em [5]. Apos isso, a integracao dos dados coletados e analisados & um importante passo a ser dado. Podemos contar com a visualizagio de mapas, num futuro proximo, pois estudo de APIs Web para mapas se encontra em andamento Ademais, 0 Gltimo requisito da Tabela 1 ¢ um trabalho futuro. Desenvolver um sistema de cadastro de usuérios, que podem salvar pesquisas ¢ manté-las armazenadas, que funcionaria, analogamente, como o médulo de Cache. ‘Também podemos citar, como trabalhos futuros mais distantes, pesquisas na Area de Andlise de sentimentos para criagao de melhores Analisadores de Polaridade das. mensagens ¢ “Predigio” de Eventos. 10Referéncias [1 Micah Alles, David Crosby, Brian Harleton Carl Erickson from Atomic Object, Greg Pattison Michael Marsiglia from X-Rite, and Curt Stienstra from Burke Porter Machinery. Presenter first: Organizing complex gui applications for test- driven development. Proceedings of Agile Conference, 2006, [2] Lars Backstrom, Paolo Boldi, Marco Rosa, Johan Ugander, and Sebastiano Vigna. Four degrees of separation. Article of New York Times November 22, 2011 [3] Fabricio Benevenuto, Jussara M. Almeida, and Altigran S. Silva. Explorando redes sovciais online: Da coleta ¢ aniilise de grandes bases de dados as aplicagies, 2011. [4] Fabricio Benevenuto, Tiago Rodrigues, Meeyoung Cha, and Virgilio Almeida. Cha- racterizing user behavior in online social networks. IMC 09 Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference, 09, 2009, [5] Fabricio Benevenuto, Diego Silveira, Thalisson Oliveire Reinaldo Fortes, aud Alvaro Pereira Jr. Entendendo a twittesfera brasil 2011 Leonardo Bombonato, a. SBSC, [6] Johan Bollen, Alberto Pepe, and Huina Mao, Modeling public mood and emo- tion: Twitter sentiment and socio-economic phenomena. Proceedings of the Fifth International AAAI Conference on Weblogs und Social Media, 2011 [7] Joubert de Castro Lima. Jeubing at www joubertlima.com.br, November 2011 [8] Erik Hatcher and Otis Gospodnetie. Lucene in Action. Manuing, 2 edition, 2011. [9] Jure Leskovee, Lars Backstrom, and Jon Kleinberg. Meme-tracking and the dy- namics of the news cycle. Proceedings of the 15th ACM SIGKDD international conference on Knowledge discovery and data mining, 2009. [10] Nielsen Online. State of the media: The social media report q3 2011. Technical report, Nielsen/ McKinsey Company, 2011 [11] Tiago Rodrigues, Fabricio Benevento, Meeyoung Cha, Krishna P. Gummadi, and Virgilio Almeida, On word-of-mouth based discovery of the web. In ACM SIGCOMM Internet Measurement Conference (IMC), 2009. [12] Matthew A. Russel. Mining the Social Web. O'Reilly, 1 edition, 2011 ul