Correlación entre el nº de clicks y los RTs entre los tweets que se han retransmitido cinco o más veces.

Para acceder a la visualización interactiva, pulsar en la imagen

Una de las preguntas que me hacía en el análisis del hashtag #manifiesto era si existía alguna correlación entre la retransmisión de una url y el número de clicks que recibía. He podido comprobarlo analizando los clicks de la urls acordadas por el servicio bit.ly usando el API de bit.ly

En los datos recogidos hay valores muy extremos, siendo 0,007 el índice de correlación lineal de la muestra total. Aparecen urls con miles de clicks que no se han retransmitido, mientras que otras muy retransmitidas no han llegado a cien clicks. Sin embargo, si se calcula la  correlación segregando la muestra en función del número de RTs el índice aumenta hasta el 0,41 para las urls que han tenido 5 o más RTs (caso que ilustra la cabecera del post). La siguiente imagen muestra el índice de correlación entre los clicks y los RTs en función de la muestra segregada por nº de RTs.

No se puede concluir  nada concreto de estos datos y es preciso medir otros valores como el número de seguidores para intentar aproximarse  a una medida de la influencia del emisor del tweet. Para calcularla aún debo esperar un poco.

Antecedentes

Cuando analicé las urls del los tweets del hashtag #manifiesto, descubrí  que las urls acortadas son una barrera para estudiar los enlaces que aparecen en los tweets. De una muestra de 20.236 tweets que contenían links,  el 82% estaban acortados. El coste en tiempo que supone expandir la url y la tasa de error dificultan obtener el enlace real. Para alargar una url se precisa un acceso http por lo que se dispara el tiempo de tratamiento, pasando a hablar de unidades de segundo por enlace.

Comentando con mi grupo de investigación esta limitación estuvimos buscando alternativas para solventar el problema, como paralelizar los accesos http o intentar interactuar con los servicios acortadores. Siendo bit.ly con un 55,76%. el servicio más extendido parecía el candidato ideal para estudiar qué posibilidades ofrecía. @nordez, rápidamente vio el API de bit.ly y me pasó el enlace.

Aunque mi intención era intentar mejorar el tiempo de expansión de los enlaces utilizando el API por su posibilidad de enviar peticiones de un grupo de urls, me llamó la atención una opción que permite obtener el número de clicks de un link dado y me distrajo del objetivo. La información que proporciona el API de los clicks está muy simplificada, tan solo se obtienen los clicks por usuario y los globales, mucho menos de los que suministra la interfaz web cuando a la url corta de bit.ly se le añade un + al final, pero supongo que se estarán reservando para opciones premium.

Metodología

He probado el API de bit.ly con la librería Python-bitly de  yoav.aviram para analizar los clicks de las urls acortadas con bit.ly. Procesar 4.331 urls ha llevado 78m 50.546s. aproximadamente 1,09 segundos por url y se han producido 37 errores (0,85%).  De los datos obtenidos se han eliminado las urls que se han comprimido anónimamente porque no aparece su número de clicks, quedando en 3.636 urls. Todos lo datos obtenidos están disponibles en este dataset.

Enlaces relacionados:

• Blogs vs. Prensa en el hashtag #manifiesto
• Analizando el hashtag #manifiesto
• Resultados del estudio del hashtag #manifiesto (versión wiki)

Los errores sintácticos han sido uno de los problemas que me he encontrado al analizar el código HTML de los blogs con el programa  Lestat, como ya  escribí  hace tiempo en el post titulado  El diablo cojuelo.  Hace unas semanas  Norberto Fernández,  profesor de mi Departamento  me sugirió  que convirtiese el HTML de los blogs a XHTML y me indicó dos herramientas para hacerlo: tidy y html2xhtml.

Estas herramientas son capaces de convertir HTML en XHTML, ordenando, limpiando y corrigiendo los errores de markup.  Las ventajas de trabajar con XHTML son múltiples:  es un lenguaje de marcas bien estructurado, permite de recorrer el documento  con XPATH o con XSLT.

La herramienta tidy, disponible en lenguaje c y java, fue desarrollada por Dave Raggett y como dice su autor:

Is an open source utility for tidying up HTML. Tidy is composed from an HTML parser and an HTML pretty printer. The parser goes to considerable lengths to correct common markup errors. It also provides advice on how to make your pages more accessible to people with disabilities, and can be used to convert HTML content into XML as XHTML. Tidy is W3C open source and available free. It has been successfully compiled on a large number of platforms, and is being integrated into many HTML authoring tools. Recently the maintenance of Tidy has been taken over by a group of dedicated volunteers on SourceForge

La herramienta   html2xhtml se ofrece como servicio web y su código fuente está  disponible en lenguaje c que funciona tanto en plataformas GNU/Linux como Windows, aunque en su versión compilada sólo se ofrece para Windows, siendo necesario en otras plataformas compilarlo a partir de su código fuente.  Ha sido desarrollada por Jesús Arias Fisteus, profesor de la Universidad Carlos III y como dice su autor:

Is an open-source converter from HTML to XHTML. it converts HTML files into XHTML. It can fix many common errors in HTML files (e.g. missing end tags, elements with incorrect content model, non-standard elements or attributes, etc.) The output document type can be selected among several XHTML DTDs (1.0, 1.1, Basic, etc.).

He realizado una prueba  de estas dos herramientas sobre 100 blogs de la tesis de Tíscar Lara

Después de esta prueba  se me abren nuevos caminos para continuar el desarrollo de lestat. Pero como decía Scarlett O’Hara, “eso lo pensaré mañana”.

——–

He despertado a  Lestat para ampliar y mejorar sus funciones. Es una dura tarea retomar un programa que se ha dejado reposar demasiado tiempo. Con paciencia y perseverancia estoy intentando  volver a entenderlo como el día que lo  dejé aunque esto tiene su precio.

Una de las facturas que me ha pasado Lestat por este abandono ha sido un bug que me ha costado un poco encontrarlo. Estoy falta de reflejos pero en mi favor tengo que decir que el bug tenía  un sentido del humor muy sutil. Aquí lo cuento para que juzgue el lector:

Una de las funciones que le he añadido a Lestat es un fichero de configuración para darle más flexibilidad en la ejecución. Para ello he definido una gramática que permita describir la configuración y la he analizado con lex/bison.  Además de la  definición del léxico de la gramática puse una expresión regular para descartar caracteres en blanco, tabulaciones y saltos de línea de esta manera  [\ \t\n]* y un default para gestionar errores léxicos  que ejecutaba lo siguiente:

fprintf(stderr,  "Error lexico en linea %d. Mira a ver si \'%s\' es el culpable.\n",  yylineno, yytext);
fprintf(stderr,"Lestat le desea mejor suerte la proxima vez \n");

Al ejecutar el analizador del fichero de configuración obtenía un resultado incomprensible:

' es el culpable.inea 1. Mira a ver si '
Lestat le desea mejor suerte la próxima vez

Primero sospeché que la función fprintf tenía un error en los parámetros y que el stack estaba corrupto. Lo miré con tanta fijeza como incredulidad.  Tras muchas trazas y muchas vueltas encontré la explicación:

El fichero de configuración lo había escrito en Windows por lo que el  salto de línea era <CR><LF> (\r\n) en vez de carácter  de salto  de línea <LF> (\n) que utiliza unix. El análisis léxico detectaba el carácter  <CR>  como error léxico y se ejecutaba la sentencia:

fprintf(stderr,  "Error lexico en linea %d. Mira a ver si \'%s\' es el culpable.\n",  yylineno, yytext);

yytext contenía un <CR> que hacía que cuando se había escrito

Error lexico en linea 1. Mira a ver si '

Se volviera al inicio de la línea para escribir lo restante:

es el culpable.inea 1. Mira a ver si’

La solución al problema era tan sencilla como poner la expresión regular [\ \t\r\n]* para filtrar blancos, tabulaciones y salto de línea.

Estas son las cosas que pasan en la programación y que nos hacen perder mucho tiempo

El pasado miércoles asistí a una conferencia de Richard Stallman en el Medialab Prado. En un estupendo español, sin ppt que le amparase nos mostró sus ideas  en un discurso estructurado y coherente.

Habló de las cuatro libertades, de  cómo surgió GNU,  el impacto de linux en GNU, el conflicto de ideas entre en proyecto GNU y Linus Torvalds,  la importancia de difundir en termino GNU/linux y la conveniencia de que en la Administración Pública y en  la educación solo se utilice software libre.

Como una pequeña contribución me hago eco de la  difusión del término GNU-linux desde este blog. Al hablar de distribuciones de Software libre se menciona mayoritariamente el nombre de linux sin ninguna referencia a GNU. Linux es el núcleo, una parte muy importante, pero no es el todo. Las distribuciones incluyen linux con los componentes GNU. Al no mencionarlo no se reconoce la autoría, el esfuerzo ni los ideales de este proyecto. De ahí la importancia de llamarlo GNU/linux.

Se puede constatar el uso del término buscando en Google por “linux” o por  “GNU/linux“. En el primer caso  proporciona 456.000.000 resultados mientras que en el segundo ofrece 21.300.000  resultados, cantidad sensiblemente inferior.

Para ver el uso reciente del término “GNU/linux” frente a “linux“  nada mejor que buscar en las conversaciones de Twitter. Las visualizaciones que aparecen a continuación están realizadas con la herramienta  TwitterStreamGraphs que visualiza en una línea temporal los últimos doscientos posts del topic elegido. Si se pulsa en las imágenes se verán  en su tamaño real.

Topic  GNU/linux, velocidad 100 tweets/día. Unos de los topics asociados que sobresale es linux

Topic GNU: se parece como dos gotas de agua al topic  GNU/linux

Topic linux: velocidad 100 tweets/hora. Tiene asociado testimonialmente el topic GNU

Finalmente, desde aquí mi agradecimiento a Richard Stallman que entre sus muchas contribuciones al software libre se encuentra el hacer que Bison, programa que utilizo para BarriBlog, sea compatible con yacc.

Como comentaba en el post anterior llevo varias semanas lidiando con TouchGraph Navigator, la versión de pago de Google. Me ha recordado a los programas de Microsoft que son de pago, pero funcionan mal. Esta herramienta se ajusta al estilo minimalista de Google, por ese motivo los mensajes de error son tan transparentes que no se ven. Esta estética no favorece nada a la depuración y hace perder mucho tiempo.

Para poder mostrar que la visualización no es algo complejo se utilizará el mismo método de explicación que en las herramientas GraphViz y Pajek. mediante un procedimiento en tres pasos:

Preparar datos de origen: Los datos del meme recogidos en una hoja de cálculo se salvan en formato texto separados por tabulaciones.

Transformar datos a formato .xml: Se aplica un filtro awk al fichero de texto separado por tabulaciones y se genera un fichero en formato xml.

Generar el gráfico: Se procesa el fichero .xml con el programa TouchGraph Navigator

El resultado obtenido con TouchGraph se puede observar en estas tres imágenes estáticas. Corresponde a la agrupación de los blogs que han participado en el meme de Enjut@ Mojamut@ según: género, fecha de la participación y grado de influencia en la propagación. No ha sido posible publicar los resultados de una forma interactiva por razones que se explican más adelante.

Al pulsar en las imágenes aparecerán en su tamaño real.

	Agrupación por género: En el halo rosa se encuentran los blogs femeninos y en azul los masculinos Filtro awk fichero xml generado Comando para generar el fichero xml
	Agrupación en torno a la fecha de propagación: Los blogs aparecen agrupados por su coincidencia temporal en la propagación del meme. Filtro awk fichero xml generado Comando para generar el fichero xml
	Agrupación en relación en la influencia en la propagación del meme: Se han clasificado los blogs en cinco TIERs según el número total de memes de los que son origen, directa o indirectamente: TIER-5 50 o más de 50, TIER-4 entre 49 y 25, TIER-3 entre 24 y 10, TIER-2 entre 9 y 5, TIER-1 entre 4 y 1  y TIER 0 los que no ha propagado el meme. Filtro awk fichero xml generado Comando para generar el fichero xml

Entorno de ejecución:

TouchGraph Navigator aporta las siguientes mejoras sobre la versión liberada:

• Permite capturar los datos desde una hoja de cálculo Excel además de la opción del fichero XML. Esto facilita la captura de datos desde herramientas ofimáticas y no precisa una transformación de los datos a un formato XML.
• Amplía las posibilidades de visualización y mejora la estética.

Cuando empecé a utilizar la herramienta me pareció sencilla hasta que intenté visualizar “El meme de enjut@ Mojamut@”. Me llevó una semana descubrir que el tamaño si importa. Para que me funcionara tuve que acortar el número de nodos a 135 (elegí los blogs con una fecha más temprana de publicación del meme). Además, la interfaz Excel producía resultados erróneos aunque afortunadamente la entrada de datos por xml mostró mejor comportamiento.

El segundo tropiezo fue cuando intenté publicar en la web los resultados. Me devolvía el error de que no tenía licencia y me invitaba a pasar por caja. Por este motivo los resultados mostrados de la evaluación de la herramienta son estáticos en vez de dinámicos, como a mi me habría gustado. Por supuesto en la página de descarga de la versión de evaluación no se indicaba las limitaciones de la herramienta en cuanto al tamaño del grafo ni las condiciones para la publicación de los resultados en la Web. Solo me queda pedir una licencia como betatester a los de TouchGraph Navigator para poner a prueba su sensibilidad con los tesistas.