Bien, en el blog tagschema.com de Nitin Borwankar explica bastante bien como hacerlo, y aquí voy a incluir un resumen traducido al castellano de lo que considero más importante de dicho blog.

He tenido la experiencia de hacer aplicaciones web 2.0 utilizando esquema de etiquetas, y es bastante sencillo de implementar si uno tiene los conceptos adecuados para hacerlo.

La Web 2.0 necesita Datos 2.0

Una de las principales características de muchas aplicaciones web 2.0 es que son folcsonomías, clasificando los contenidos por medio de palabras clave o “etiquetas” (tags) mnemotécnicas.

Normalmente estas aplicaciones a diferencia de las aplicaciones “1.0″, por llamarlas de alguna manera, relacionan a los usuarios con lo que denominaremos sus ítems (podrían ser bookmars, fotos, videos, música, o cualquier objeto de una aplicación). En las aplicaciones “2.0″ no solo se relacionan los usuarios con sus ítems, sino que también se relacionan con las etiquetas que les ponen a sus ítems.

Los nuevos modelos de datos, ahora, deberán tener en cuenta una nueva dimensión a la hora de actuar, y esa nueva dimensión son las etiquetas. Para lograr eso de una forma eficiente se debe hacer una especie de datawarehousing. Ese datawarehousing en tiempo real son nuestros Datos 2.0, los datos que utilizaremos por medio de nuestro esquema de etiquetas.

Entonces, el esquema de etiquetas (o tags) representa un datawarehouse de datos etiquetados (o tabeados), y esos serán nuestros Datos 2.0.

Datos 2.0 a fondo

Ahora que sabemos que un esquema de etiquetas (o esquema de tags) no es nada mas ni nada menos que un datawarehouse, para analizar estos esquemas de etiquetas vamos a tener que hacer un análisis de modelos multidimensionales.

Antes de interiorizarnos con profundidad en este tema vamos a darnos cuenta que para cualquier simple aplicación que utilice etiquetas vamos a necesitar tres dimensiones básicas: “Usuario”, “Etiqueta” y “Ítem”. A partir de esas tres dimensiones comenzaremos a hacer el análisis de un esquema de etiquetas.

Con esas tres principales dimensiones se genera lo que en datawarehousing se conoce como “fact table”, y eso es una tabla donde se asocian y convergen las 3 dimensiones. En esa tabla tendremos la información de cada ocurrencia de un evento, como por ejemplo “el usuario X ha puesto la etiqueta Y al ítem Z”. Esta situación se da para todas las etiquetas Y que le incluye el usuario X a todos los objetos Z que posea.

Entonces, si el usuario “pepe” utiliza las etiquetas “cine”, “música”, “literatura” y “ocio” de manera en la que a el le parece con algunos artículos de un sitio web que habla sobre hobbies, en un esquema de etiquetas podríamos llegar a encontrar las siguientes columnas en una “fact table”:

Usuario     Etiqueta        Ítem
----------------------------------------------------------------
'pepe'      'cine'          'http://algohobbies.com/articulo-1'
'pepe'      'cine'          'http://algohobbies.com/articulo-2'
'pepe'      'música'        'http://algohobbies.com/articulo-2'
'pepe'      'cine'          'http://algohobbies.com/articulo-3'
'pepe'      'literatura'    'http://algohobbies.com/articulo-3'
'pepe'      'ocio'          'http://algohobbies.com/articulo-4'

El usuario “juan” tendrá una cantidad similar de campos para todos sus objetos etiquetados, lo mismo para el usuario “laura”.

Las “fact tables” son tablas de asociaciones de múltiple entrada, donde se asocian todas las dimensiones posibles en un solo lugar. Estas tablas permiten una gran cantidad de consultas interesantes para correr, con probablemente, una de las mejores escalabilidades.

Creando un modelo de datos para navegar una folcsonomía

Además de la unión de los Usuarios, Etiquetas e Ítems hay una cantidad de relaciones que, junto con la relación base, forman el modelo de datos 2.0. Exploremos estas relaciones y sus consecuencias para la arquitectura de los datos.

Los Usuarios tienen Ítems (URL’s, fotos, música, etc.), pero un Usuario puede existir en la base de datos sin poseer ningún Ítem, como por ejemplo luego de haberse registrado. Por el lado del Ítem, este terminara siendo incluido en la base de datos solamente si esta relacionado al menos a un usuario (el que lo haya cargado). Entonces, un Usuario tiene quizás-ninguno-pero-posiblemente-muchos Ítems, y un Ítem tiene al-menos-uno-y-posiblemente-muchos Usuarios.

Similarmente, un Ítem puede existir sin ninguna Etiqueta, pero una Etiqueta existe solamente para asignar un valor a un Ítem. Adicionalmente, un Usuario puede no haber etiquetado nada por lo cual no tener ninguna Etiqueta, pero una Etiqueta siempre va a ser asignada por un Usuario.

Teniendo en cuenta esas tres relaciones cíclicas obtenemos lo siguiente:

Usuario  (1-muchos)  <---------> (0-muchos)  Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Usuario

Transcribiendo eso para una mejor comprensión podemos obtener este hermoso diagrama:

Aquí podemos ver que hay relaciones muchos-a-muchos entre cada par de entidades. Este modelo que vemos aquí arriba es la representación de un modelo lógico de datos, que al pasarlo a un modelo físico de datos va a requerir algunas modificaciones debido a las relaciones de muchos-a-muchos.

La idea no es dar una clase sobre bases de datos, pero como una breve explicación, la forma estándar de representar las relaciones muchos-a-muchos es crear una tabla de relación en la base de datos, que asocie ambos campos por medio de sus identificadotes.

Por ejemplo si queremos almacenar los Ítems que ha guardado un Usuario, al mismo tiempo que queremos saber los Usuarios que poseen cierto Ítem de una forma eficiente, crearemos una tabla que se podría llamar UsuarioÍtem para resolver la relación de muchos-a-muchos entre esas dos entidades donde cada columna tendrá el identificador del Usuario y el identificador del Ítem. Con la misma lógica tendremos una tabla UsuarioEtiqueta y una tabla ÍtemEtiqueta.

Habiendo creado las tablas de relaciones, el modelo nos quedara similar al siguiente:

Para completar nuestro modelo de datos, como vimos anteriormente, tenemos la famosa “fact table” donde se relacionan los Usuarios, Ítems y Etiquetas en una sola tabla, que puede ser representada de dicha manera:

Ahora bien, seguramente están pensando ¿todo esto para hacer una simple nube de etiquetas?

Bien, si estas pensando en hacer una arquitectura de una folcsonomía a gran escala va a ser necesario algo así, ya que en una primera instancia este modelo resuelve de forma muy simple las preguntas: “¿Cuáles son todos los Ítems de un Usuario?” O “¿Cuáles son todas las Etiquetas de este Ítem?”; pero yendo a un grado mayor de profundidad, nos podemos encontrar con preguntas como: “¿Cuáles son todos los Usuarios que tienen mas Ítems similares entre sí con otro Usuario?”. Usando este modelo, podemos responder muchas consultas sin hacer múltiples JOIN en una base de datos, y cuando hablamos de mas de 250.000.000 de columnas, es algo importante para la performance.

Entonces, como nuestro modelo no puede evitar nunca tener nuestra “fact table” ya que mantiene la coherencia entre los Usuarios, Ítems y Etiquetas, combinando estos dos modelos de datos obtendremos lo que se podría denominar la base de nuestro modelo de datos 2.0, nuestro famoso esquema de etiquetas:

Relacionando datos en una folcsonomía

Si bien SQL es un lenguaje perfectamente adecuado para hacer consultas de datos “tabulares”, no es particularmente elegante para representar las abstracciones que tenemos en mente a la hora de relacionar datos en una folcsonomía, como por ejemplo, relacionar Usuarios, Ítems o Etiquetas entre sí.

Vamos a usar una simple notación para hablar sobre las relaciones entre Usuario-Ítem-Etiqueta, para transformar momentáneamente SQL en un lenguaje un poco más descriptivo. Olvidémonos de SQL por un momento y vamos a seguir esta notación:

Las letras en minúscula “í”, “e” y “u” representaran a un “Ítem”, “Etiqueta” y “Usuario” respectivamente.

Las letras en mayúscula “Í”, “E” y “U” representaran una lista de “Ítems”, “Etiquetas” y “Usuarios”, como una búsqueda.

Veamos algunos ejemplos:

Al pedir U(í), estaremos pidiendo todos los Usuarios de un Ítem í.
(En SQL sería: select u.* from usuarios u, usuarios_ítems ui where u.id = ui.usuario_id and ui.item_id = algun_item_id; )

Al pedir U(e), estaremos pidiendo todos los Usuarios que tengan la Etiqueta e.
(En SQL sería: select u.* from usuarios u, usuarios_etiquetas ue where u.id = ue.usuario_id and ue.etiqueta_id = alguna_etiqueta_id; )

Similarmente obtendremos:

Í(u) serán todos los Ítems de un Usuario u.
Í(e) serán todos los Ítems que tengan una Etiqueta e.
E(í) serán todas las Etiquetas que estén asignadas a un Ítem í.
E(u) serán todas las Etiquetas que haya usado un Usuario u.

Ahora, si buscamos en un segundo grado de profundidad, podremos encontrar consultas un poco mas interesantes que las anteriores.

Por ejemplo, E(U(e)) es una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e.
(Su SQL sería: select e.* from etiquetas e, usuario_etiquetas ue, where ue.usuario_id in (select usuario_id from usuario_etiquetas where etiqueta_id = alguna_etiqueta_id))

Aquí podemos observar que es mucho mas sencillo decir lo que queremos, “Una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e”, que su representación en SQL que puede llegar a ser mas compleja de entender sin la explicación previa.

De esta manera, con la notación que hemos utilizado podemos encontrar varias consultas de segundo grado.

Estas consultas las veremos mas adelante en alguna otra publicación, creo que ya es demasiada información por una única entrada.

Como hacemos siempre que vamos a dar una definición “de abuela” sobre algún tema, vamos a tratar de repasar que dicen en diferentes lugares sobre el termino que vamos a explicar. Así que empecemos por Wikipedia:

“Folksonomía es una indexación profesional, es decir, la clasificación colaborativa por medio de etiquetas simples en un espacio de nombres llano, sin jerarquías ni relaciones de parentesco predeterminadas. Se trata de una práctica que se produce en entornos de software social cuyos mejores exponentes son los sitios compartidos como del.icio.us (enlaces favoritos), Flickr (fotos), Tagzania (lugares), flof (lugares) o 43 Things (deseos).”

Si bien esta definición no me termina de gustar, y creo que no deja del todo claro el termino, podemos sacar cosas bastante claras: Es una clasificación colaborativa por medio de etiquetas.

En el hormiguero podemos encontrar una nota sobre folcsonomía, que es muy interesante, de la cual podemos sacar esto:

“Es decir, clasificar cosas mediante una serie de palabras clave. Por ejemplo, si quiero clasificar una receta de paella usaría las tags (o etiquetas, o palabras-clave): paella, cocina, receta, marisco, arroz. Todas a un mismo nivel, y todas independientes.”

Bueno, aquí podemos encontrar que las folcsonomías usan los benditos tags. O sea, ¡llamamos a una folcsonomía a catalogar con tags! Lo cual no creo que sea tan así, pero estamos mas cerca de lo que queremos llegar.

En la taberna del turco, que hizo una buena nota sobre este tema, obteniendo muchos datos sobre la Wikipedia en ingles, podemos rescatar un poco de etimología de esta palabra, ya que creo que en este caso si es importante:

“Etimológicamente hablando, folcsonomía es una palabra derivada de taxonomía, la cuál significa clasificación (taxis) y orden (nomia). Teniendo en cuenta que folc significa en alemán pueblo, tenemos que folcsonomía vendría a significar “clasificación por el pueblo”.”

Bueno, al ver la etimología de la palabra creo que ya no deberían quedar muchas dudas sobre que es una folcsonomía; pero para no ser menos vamos a hacer una definición “de la abuela”.

Definición de la abuela: ¿Qué es una Folcsonomía?

Una folcsonomía es una forma de catalogar o clasificar las cosas de manera colaborativa, o sea, es una forma de clasificación masiva en la cual las cosas son clasificadas por un conjunto de personas a la vez. La manera actual y mas popular de realizar las folcsonomías es por medio de los tags (o etiquetas).

Bueno, en este articulo, vamos a ver que son estas etiquetas, para que sirven, y por que tantos sitios las utilizan.

¿Qué es un tag (una etiqueta)?

Según del.icio.us, uno de los mas emblemáticos sitios web 2.0 (al menos a mi parecer), al traducirlo al castellano dice que: “Una etiqueta es simplemente una palabra que se utiliza para describir un bookmark*. Al contrario que las carpetas, vos podes asignar etiquetas cuando lo necesites y podes utilizar todas las etiquetas que quieras. El resultado es una mejor manera de organizar tus bookmarks y una gran manera de descubrir cosas interesantes en la web.”

* Podemos ver que aquí aclara que las etiquetas son para describir bookmars, ya que del.icio.us es un sistema que se encarga de administrar bookmarks (o favoritos).

De esta definición, creo que podemos obtener esta conclusión: “Una etiqueta es simplemente una palabra que se utiliza para describir un algo. Al contrario que las carpetas, se pueden asignar tantas etiquetas como se deseen.”

¿Seguís sin tener claro que es una etiqueta?

Bueno, vamos a ver que nos dice Wikipedia al respecto; y luego de analizar todo lo que nos dice Wikipedia sobre etiquetas, podemos llegar a decir que: “Una etiqueta es un elemento que se adhiere a otro elemento para identificarlo o describirlo”.

Si bien en la enciclopedia podemos notar que la definición no se refiere a una “etiqueta computacional”, sino más bien a una etiqueta física, las etiquetas dentro del mundo de la informática cumplen el mismo objetivo.

A un tema de música, un bookmark o una foto digital, entre otros, no les podemos asignar etiquetas que cuelguen de ellas o estén adheridas a ellas, ya que no existen físicamente; estas solo existen digitalmente. Para solucionar este problema, al no poder adherirle una etiqueta física, si les adherimos una etiqueta esta tiene que ser digital.

De eso se tratan las famosas etiquetas (o tags): Etiquetar en el mundo digital las cosas, tal cual lo haríamos en el mundo físico.

¿Qué ventaja tiene utilizar tags (etiquetas)?

En el mundo digital, a mi parecer, etiquetar las cosas posee mas ventajas que en el mundo fisico; y vamos a tratar de explicar los motivos.

La primer ventaja, como en el mundo fisico, es que tenemos todas nuestras cosas catalogadas de una manera mas eficiente sin la necesidad de que pertenezcan a una carpeta especifica. Como por ejemplo un tema de los Rolling Stones puede pertenecer a las etiquetas 70s, rock, oscuro, jagger; y no solo a la carpeta “Rolling Stones” donde tenemos todos los discos de esta banda.

Una segunda ventaja importante, es la busqueda de información. Como en internet no estamos nosotros solos y la compartimos con millones de usuarios, estos usuarios tambien pondran etiquetas a sus cosas, lo cual nos facilitara buscar información basándose en etiquetas. Por ejemplo, si yo entro a Flickr, puedo buscar todas las fotos que posean la etiqueta “guevara“, para encontrar fotos la gente etiqueto con ese nombre.

Otra ventaja que veo que es importante es la navegabilidad, teniendo mas posibilidades de acceder a la misma información.

Como conclusión de este punto, me gustaría dejar claro que las etiquetas son algo muy sencillo e intuitivo una vez que uno se acostumbra a utilizarlas; lo cual nos deja un gran valor con poco esfuerzo.

¿Qué es una nube de tags (etiquetas)?

Llegando al final de este articulo, de forma simple, podemos analizar lo que nos dice Wikipedia sobre lo que es una nube de tags: “Una nube de etiquetas (tag cloud en inglés) es una representación visual de las «etiquetas» o palabras clave usadas en un sitio web. Generalmente este listado de palabras se ordena alfabéticamente; las etiquetas más utilizadas se representan con un tipo de letra de tamaño mayor que el resto.”.

Así de sencillo: Una nube de tags (etiquetas) es una lista, de estas mismas, las cuales tienen diferente tamaño según su popularidad dentro del sitio. Normalmente, cuando presionamos estas etiquetas, podemos ver todos las cosas que están etiquetadas con ellas.

En algún otro articulo mostrare diferentes ejemplos de nubes de etiquetas, como también se charlara sobre como generar nubes de etiquetas a la hora de programar nuestro sitio.