Sistema de tagging - la nube de etiquetas

Características y elementos de las nubes de tags

Por lo que respecta a la definición de una nube de tags, creo que una imagen vale más que mil palabras. Por lo tanto, puedes ver La nube de tags de del.icio.us o bien las de flickr.

La principal utilidad de las nubes de etiquetas es la de presentar información agregada, y en el mejor de los casos, sintetizada (que no resumida). Visualizar una nube de tags de un portal equivale a disponer de un cuadro resumen de conceptos que identifican los contenidos. Cuanto más grandes se presentan los términos en una nube de tags, más frecuente es el uso de ese término. Concretaré este "cuanto más" un poco más abajo.

Después de una primera fase de uso de las nubes de etiquetas, han aparecido algunas variantes en los sistemas de visualización. Algunas de las características introducidas han sido:

• Ordenación:
• Alfabética: Los términos se ordenan alfabéticamente.
• Por frecuencia: Los términos se muestran por frecuencia de uso.
• Agrupación:
• Alfabética: Los términos se separan por letra inicial.
• Semántica: Los términos se agrupan por co-ocurrencia (Hassan, Herrero-Solana; 2006).
• Sobre el uso del espacio donde se muestra la nube (Owen, Lemire; 2007):
• El espaciado e interlineado entre tags son gestionados por el navegador.
• Se aplican técnicas de CSS y HTML para aprovechar mejor el espacio.
  

Los criterios de ordenación y la agrupación son combinables, por lo que se pueden crear varios niveles de ordenación-agrupación que dieran como resultado una mejor visualización de contenidos.

Uno de los temas que son más de interés para mi ha sido encontrar un algoritmo de determinación del tamaño de las etiquetas. He encontrado información, pero no me ha parecido satisfactoria. Por ejemplo, encontré el artículo de Owen y Lemire anterior un algoritmo para la determinación de los tamaños de etiquetas.

Otro artículo en echochamber me pareció interesante por lo visual de su explicación, aunque conceptualmente creo que es erróneo. El sistema que utilizan es interesante, y en parte muy en la línea de lo que estaba pensando yo, pero no me acabó de convencer. Creo que es un error centrarse en la densidad, y no en la distribución. Es decir, calcular los tamaños de las etiquetas en base a las frecuencias simples, y no a las acumuladas.

Aunque ya es vox populi que la distribución de las etiquetas sigue una distribución con la característica cola larga, esa cola presenta diferentes pesos, el conjunto de la distribución puede tener varias formas, y por lo tanto la determinación de los tamaños puede no ser el adecuado utilizando fórmulas como las indicadas en el artículo anterior.

Abandonarse a las estadísticas

No sólo me apetece: creo que en este caso es lo mejor. Supongamos que las etiquetas siguen una distribución de frecuencias parecidas a la distribución Zipf: cola larga, pocos ítems con mucha frecuencia, muchos ítems con poca frecuencia, y los ítems del rango medio.

Si siguiéramos los criterios de sistemas de indexación full-text, los términos más utilizados se considerarían palabras vacías por ser muy frecuentes, con lo que se descartarían. La principal razón es que un término muy utilizado es un mal criterio discriminante. Por lo general, las etiquetas más utilizadas son las que aparecen en la nube, porque son cuantitativamente más importantes. Esto a nivel semántico no parece lo mejor. Esto también queda para más adelante.

Sin embargo, no descartamos los términos más habituales. La lista de tags ordenados de más a menos frecuente recuerda un gráfico de Pareto.

Echando un vistazo al gráfico de Pareto, podemos ver dos elementos: las barras, que representan la función de densidad (frecuencia en un punto), y la línea, que representa la función de distribución (frecuencia acumulada).

Podemos ver que tanto un esquema como el otro siguen una forma que se puede trazar con una línea curva: sin alteraciones. Esta forma de distribución de los datos, tiene lugar cuando existe una gran cantidad de elementos (recursos etiquetados). La variabilidad se estabiliza y es difícil crear grandes alteraciones sin introducir mucha información

Bajando del tren teórico y volviendo a la realidad: una organización está iniciando la introducción de datos etiquetados. Ese etiquetado ya empieza a presentar una larga cola, debido a que hay términos que sólo se han utilizado una vez. Sin embargo, no existe aún la cabeza de la cola. O quizá lo que está sucediendo es que los "tags medios" aún no se han formado, por lo que hay un hueco entre tags muy frecuentes y los poco frecuentes.

Esta circunstancia puede repetirse cuando se agrupa o se disgregan los tags según alguno de los criterios indicados anteriormente.

De hecho, dentro de un mismo recurso también se da el proceso que tiene lugar en el conjunto: a medida que los usuarios de un sistema de bookmarking social etiquetan un mismo contenido, la distribución se va estabilizando, formando también una distribución con cola larga.

Antes de llegar a la estabilidad, el tamaño de los tags es importante para tener una buena representación. Mostrar todos los tags muy grandes o muy pequeños puede alterar la calidad de la visualización de la nube, y por ello su objetivo. Esto tiene consecuencias a varios niveles: desde la recuperación de la información, hasta el diseño de interficie.

En esta situación, existen varias aproximaciones de base estadística al problema. Aún sabiendo que no seré exhaustivo, destaco tres:

• Análisis en base a la "forma" o ley que sigue la distribución de frecuencias. Es decir, análisis paramétrico. Por lo general la mayoría de herramientas del análisis paramétrico se centran en la distribución normal.
• Análisis no paramétrico: al no establecer a priori la distribución (ni su forma), se aplican técnicas no basadas en (los parámetros de) esa distribución.
• Estadística robusta: Estadística basada en la ordenación de los datos y la obtención de valores estadísticos menos sensibles a variaciones.
  

De las tres, yo escojo la tercera. Para empezar, es la más sencilla de abordar, ya que las técnicas son sencillas de aplicar. Al no basarse en la distribución, se adaptan mejor a los varios casos posibles de distribuciones. Además, computacionalmente son más abordables (exceptuando por la ordenación).

Aunque esto está por ver, los efectos de utilizar la estadística robusta son intuitivamente más comprensibles por un usuario (administrador de un sitio) que quisiera configurar el comportamiento de la nube de tags, por lo que también se da pie a sencillas interficies de configuración.

La única excepción está en la ya comentada velocidad de computación por el hecho de ordenar la muestra, aunque al tratar con un conjunto ya agregado (antes de ordenar ya se han escogido un grupo reducido de etiquetas), ese aspecto no debería ser preocupante.

Nubes de etiquetas con estadística robusta

Para empezar a abordar las circunstancias comentadas antes, podemos ver un gráfico de lo que sería una distribución acumulada de tags:



La distribución acumulada viene a decir: si miras el porcentaje en el punto X, el valor acumulado te indica qué porcentaje de elementos (en nuestro caso tags) de la muestra estan por debajo de esa cantidad. Es decir, si en 35 tienes un 70%, quiere decir que el 70% de los tags tienen 35 o menos usos.

En cambio, la información que proporcionan los gráficos de densidad son que en el punto X hay una proporción determinada. En resumen, no dan una visión de conjunto.

Si ordenamos los valores del gráfico de densidad de menor a mayor, tenemos una "función de densidad" siempre creciente, con una forma inversa a la que habitualmente presenta un gráfico de Pareto.

Utilizando percentiles, lo que hacemos es dividir esta lista por partes. Supongamos que seleccionamos 100 tags para la nube. Si queremos una distribución equivalente de cinco tamaños de fuente, podemos seleccionar los percentiles 20,40,60 y 80. Con esto tendremos que:

• Entre 0 y 20 tiene tamaño 1 (el más pequeño).
• Entre >20 y 40 tiene tamaño 2.
• Entre >40 y 60 tiene tamaño 3.
• Entre >60 y 80 tiene tamaño 4.
• Entre >80 y 100 tiene tamaño 5 (el más grande).
  

El cálculo de los percentiles con la muestra ordenada es muy sencilla. Para el caso (ideal) que planteo, sólo es necesario escoger los valores que hay en las posciones 20, 40, 60 y 80. Con estos valores, sólo hemos de ir comparando la frecuencia de uso en cada tag y asignar el tamaño del intervalo.

Hagámoslo sencillo: un ejemplo de 10 tags:

tag1 = 1
tag2 = 2
tag3 = 3
tag4 = 5
tag5 = 8
tag6 = 9
tag7 = 14
tag8 = 20
tag9 = 100
tag10 = 150

Con los percentiles anteriores, tenemos que los valores a seleccionar serían 2,5,9,20. A efectos prácticos esto significa que el tag1 y tag2 tienen tamaño 1, .... y el tag9 y tag10 tienen tamaño 5.

Para este cálculo hemos ordenado los tags *por frecuencia*. Lo que sucede a menudo es que al mostrarse en la web, se ordenan alfabéticamente. Por lo tanto, el cálculo de tamaños y el proceso de mostrarse en pantalla se hacen por separado.

Consecuencias del uso de percentiles

Una de las consecuencias del uso de percentiles es que no siempre se consigue un efecto deseable. Por ejemplo, alteraremos la muestra anterior:

tag1 = 1
tag2 = 1
tag3 = 1
tag4 = 5
tag5 = 5
tag6 = 9
tag7 = 22
tag8 = 150
tag9 = 180
tag10 = 2000

En este caso aparecen dos cuestiones importantes:

• El percentil 20 sigue siendo 1, pero al generar la nube de etiquetas, el tag3 también se mostrará con tamaño 1. Este efecto es habitual en pequeñas colecciones o en muestras que tienen tendencia a mostrar el comportamiento de larga cola.
• El segundo efecto importante es el de tag10: su frecuencia de uso es mayor que la suma del resto, pero a nivel de tamaño se muestra igual que el tag9, cuando en realidad tag9 está más cercano a tag8.
  

Un consuelo sirve para las dos: en el momento de agrupar y categorizar, siempre existen estas imperfecciones. De los dos, el más preocupante es el segundo, ya que el principal interés al agrupar datos es que se mantenga la representatividad de la información: si un tag utilizado 2000 veces se representa como igual de importante que otro utilizado sólo 180 veces, algo falla.

Por suerte, la estadística robusta ya considera la presencia de los datos extremos (outliers). Estos datos extremos se dan tanto por máximos como por mínimos. Por lo general, su cálculo se realiza mediante cuartiles y el rango intercuartìlico: el rango intercuartílico indica la distancia entre el cuartil 1 y el cuartil 3, lo que equivale a la distancia entre los percentiles 25 y 75. Esta distancia se utiliza como regla de medida para determinar lo máximo esperado para valores no extremos.

Así, si un dato está más allá de N rangos intercuartílicos respecto la mediana, se considera un outlier (valor extremo). En los casos como el gráfico box-plot, lo que se hace es dejar al outlier fuera del gráfico general, aunque marcando su posición. Para el caso que nos ocupa, la cuestión sería utilizar un criterio distinto para cada extremo:

• Si se trata de un extremo por mínimo, debería eliminarse: si la nube de tags se utiliza como indicador agregado de contenidos, un mínimo excesivamente bajo no es representativo, ya que probablemente es parte de la "cola".
• Para el caso de los máximos, debería existir un tamaño de fuente aplicable sólo a este tipo de datos, ya que de este modo se resaltaría esta propiedad. Es decir, una clase CSS asignada a un tag outlier.
  

En ambos casos, a medida que aumenta la muestra es muy probable que desaparezcan. Sin embargo, es probable que sigan teniendo presencia en nubes de tags más filtradas.

Una vez saciadas las exigencias de representatividad, ya tenemos un criterio bastante básico, que se puede concretar en el siguiente pseudocódigo.

• A = los tags más utilizados y sus frecuencias.
• B = Ordenar A de menor a mayor frecuencia.
• C = Matriz con los percentiles 20, 40, 60 y 80. (escoger valores en posiciones correspondientes)
• Para cada A[i] en A:
• Para cada C[j] en C:
• Si frecuencia de A[i] <= C[j]:
• Imprimir el tag A[i] con tamaño "j"
• break (pasar al siguiente tag)
• Fin Si
• Fin bucle C[j]
• Fin bucle A[i]
  

Conclusiones

Si la web tiene una gran cantidad de contenidos, la nube de tags se convierte en un equivalente nada sintáctico de un resumen. Sin embargo, los formatos de las nubes de tags quizá evolucionen hacia modelos más basados en análisis de co-ocurrencia.

El hecho que se dé una buena representatividad en esta nube reflejará mejor los contenidos, por lo que ayudará a que el usuario pueda decidir si se queda o se va. La distorsión de la nube de tags (con o sin intención) es infructuoso, ya que tarde o temprano el usuario se dará cuenta que la nube no refleja el conjunto.

A nivel técnico, el algoritmo que se deriva del pseudocódigo anterior es rápido. Este tipo de consultas agregadas son sencillas, y el único factor que pudiera jugar en su contra es la memoria que puede utilizar la consulta a la base de datos.

Por delante me quedan varios temas. Uno de ellos es crear un algoritmo de creación de nube de tags que permita varios esquemas de visualización, considerando criterios de ordenación y agrupación combinados.

El segundo, de carácter más técnico, es realizar pruebas de rendimiento sobre varios esquemas de bases de datos enfocados a almacenar sistemas de tagging. Es una pregunta habitual, que también permitirá profundizar en sistemas de optimización de bases de datos.