El RDFa (“Marco para la Descripción de Recursos en Atributos” por sus siglas en inglés) está teniendo sus cinco minutos de fama: Google está comenzando a procesar RDFa y Microformatos al indexar sitios web, utilizando la información analizada para mejorar la visualización de los resultados de búsqueda con “fragmentos enriquecidos”. Yahoo!, mientras tanto, ha estado procesando RDFa por casi un año. Con estos dos buscadores gigantes en la misma trayectoria, un nuevo tipo de web está más cerca que antes.
La web está diseñada para ser consumida por humanos, y mucha de la rica y útil información que nuestros sitios web contienen, es inaccesible para las máquinas. Puedes presentarle a los humanos muchas variaciones en el diseño, deletreo, capitalización, color, posición, y mucho más, y aún así lograrán captar el significado intrínseco de la página. La máquinas, por el otro lado, necesitan algo de ayuda.
Un nuevo tipo de web─una web semántica─estaría compuesta por información marcada de tal manera que el software pudiera entenderla de manera sencilla. Antes de considerar cómo podríamos alcanzar tal tipo de web, echemos un vistazo a lo que podríamos lograr con ella.
Búsquedas mejoradas#section1
Al añadir información amigable con la máquina mejora nuestra habilidad de realizar búsquedas. Imagina una noticia que dice “hoy el primer ministro voló a Australia”, haciendo referencia al primer ministro, Gordon Brown. El artículo pordría no llamar al primer ministro por su nombre, pero aún así continúa siendo bastante sencillo asegurar que la noticia aparece cuando alguien busca “Gordon Brown”.
Sin embargo, si la noticia en cuestión data de 1940, no queremos que este documento aparezca cuando los usuarios buscan “Gordon Brown” ─ sino que preferiríamos que aparezca cuando buscamos “Winston Churchill”.
Para lograr esto utilizando la misma técnica que en el ejemplo de Gordon Brown─por ejemplo, mapeando un conjunto de letras a otro─nuestro motor de búsqueda debe saber las fechas de inicio y desenlace de los cargos de todos los primer ministros de Gran Bretaña, y después realizar una referencia cruzada de ellos con la fecha de publicación del artículo. Esto no sería completamente imposible, sin embargo, ¿qué pasa si el artículo es ficticio, o si en realidad está hablando del primer ministro de Australia? En estos casos, una simple lista de fechas no será de utilidad.
Los algoritmos de indexado que intentan deducir el contexto necesario a partir del texto, definitivamente irán mejorando con el paso de los años, sin embargo, lo único que puede asegurar que una búsqueda sea precisa es markup extra que quite ambigüedad a la información.
Interfaces de usuario mejoradas#section2
Yahoo! y Google han comenzado a utilizar RDFa para mejorar la experiencia de usuario, al mejorar la apariencia de resultados de búsqueda individuales. Aquí un ejemplo del enfoque de Google:
y aquí el de Yahoo!:
Hay una ventaja comercial al tener mejor “entendimiento” de las páginas indexadas: podemos añadir junto a los resultados de búsqueda, anuncios más relevantes y enfocados.
Ahora que sabemos por qué podríamos querer poner información más amigable con las máquinas, podemos preguntarnos cómo implementarlo.
Elementos metadata de HTML#section3
Sin duda alguna, ya debes estar familiarizado con los elementos básicos de metadata que HTML soporta. Los más comúnmente utilizados son los elementos meta y link, y algunas personas también sabrán que el atributo @rel utilizado en link también puede ser usado con a. (Nota: Estaré usando el término “HTML” para referirme a “la familia de lenguajes HTML”, puesto que lo que estoy diciendo aplica de igual manera para HTML y XHTML.)
Primero, echaremos un vistazo a estas características ya existentes, puesto que ellas poveen la fundación conceptual sobre la que RDFa ha sido construido.
El uso de <meta> y <link> en HTML#section4
Los elementos meta y link viven en el elementohead del documento, y nos permiten brindar información que se refiere al mismo. Por ejemplo, yo podría querer decir que he creado mi documento el 9 de marzo del 2009, que yo soy el autor, y que permito que otras personas utilizen de manera legal mi artículo según lo deseen:
<html>
<head>
<title>RDFa: Now everyone can have an API</title>
<meta name="author" content="Mark Birbeck" />
<meta name="created" content="2009-05-09" />
<link rel="license" href="http://creativecommons.org/licenses/ »
by-sa/3.0/" />
</head>
.
.
.
</html>Este ejemplo muestra como HTML empaqueta limpiamente la metadata del documento en un espacio distinto del texto del artículo. HTML utiliza el elemento head para la metadata y el elemento body para cualquier contenido que la página tenga.
HTML también nos permite combinar estas dos áreas: podemos poner el atributo @rel en un enlace, y aún así mantener el significado que contiene en link.
Utilizando @rel#section5
Imaginemos que quiero permitir a los visitantes de mi sitio que vean la licencia Creative Commons. Como las cosas están hasta el momento, la información sobre la licencia a la que me refiero, se encuentra oculta de los lectores, pues está en el elemento head. Pero eso se resuelve simplemente, añadiendo un anchor en el body:
<a href="http://creativecommons.org/licenses/by-sa/3.0/">CC Attribution-ShareAlike</a>Esto es correcto, y nos permite lograr lo que queríamos: primero, tenemos metadata entendible para máquinas en el elemento head que describe la relación entre el documento y la licencia:
<link rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/" />…y segundo, tenemos un enlace en el body, que nos permite a los humanos dar clic para leer la licencia:
<a href="http://creativecommons.org/licenses/by-sa/3.0/">CC Attribution-ShareAlike</a>Pero HTML también nos permite utilizar el atributo @rel de link en un anchor. En otras palabras, permite que la metadata que normalmente iría en el elemento head del documento, aparezca en el body.
Con esta poderosa técnica, podemos expresar tanto la metadata para las máquinas, como el enlace para dar clic que usan los humanos, en un cómodo paquete:
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CC Attribution-ShareAlike</a>Este simple método de aumentar el markup en la línea con metadata no es comúnmente usado en sitios web, sin embargo, se encuentra en el núcleo de RDFa. Esto nos guía al primero principio de RDFa:
Regla #1:#section6
Los elementos link y a implican que hay una relación entre el documento actual y algún otro documento; el atributo @rel nos permite proveer el valor que describirá explícitamente esa relación.
Sin embargo, no hay que olvidar que: utilizar @rel con a es meramente tomar ventaja de una característica de HTML que ya existe, a la cuál RDFa presta atención.
Aplicar distintas licencias a imágenes#section7
El ejemplo anterior provee información sobre la licencia de la página web que la contiene. Pero, ¿qué pasa si la página contiene múltiples elementos, cada uno con licencias distinta? No te tomará más de un momento pensar los distintos escenarios donde esto aplicaría, como una página con resultados de búsqueda en Flickr, YouTube o SlideShare.
RDFa toma la simple idea tras @rel─expresar relaciones entre dos cosas─y construye sobre eso, al permitir que el atributo sea aplicado junto al atributo @src en el elemento img.
Entonces, por ejemplo, imaginemos una página de resultados de búsqueda en Flickr:
<img src="image1.png" />
<img src="image2.png" />Digamos que la primera imagen tiene una licencia Creative Commons Attribution-ShareAlike, pero la segunda utiliza una licencia CC Attribution-Noncommercial-No Derivative works.
¿Cómo deberíamos representarlo?
Si piensas que simplemente pongamos el atributo @rel en el elemento img, estás en lo correcto. Para expresar dos licencias distintas, una para cada imagen, simplemente hacemos lo siguiente:
<img src="image1.png" rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/" /><img src="image2.png" rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" />Aquí puedes ver el principio central en acción─construir sobre las características de metadata que HTML ya tiene. Construir sobre conceptos HTML de esta manera, hace sencillo para la gente guiarse al utilizar RDFa.
Regla #2:#section8
Los atributos @rel y @href ya no son exclusivos para los elementos a y link, sino que también pueden ser usados con img para indicar relaciones entre una imagen y algún otro objeto.
Añadiendo propiedades a <body>#section9
En nuestra ilustración HTML, vimos que también podemos añadir propiedades textuales sobre el documento:
<meta name="author" content="Mark Birbeck" />
<meta name="created" content="2009-05-01" />
Esto nos dice quién creó el documento, y cuándo, pero solo puede ser utilizado en la cabecera del documento. RDFa toma esta técnica y la mejora para que pueda ser utilizada en body; @content por lo tanto, ha dejado de estar confinado a la etiqueta meta, sino que puede aparecer en cualquier elemento.
Regla #3:#section10
En HTML ordinario, las propiedades se definen en la cabecera del documento utilizando @content con meta. En los documentos HTML con RDFa, @content puede ser utilizado en cualquier elemento.
Sin embargo, hay un cambio menor en la forma en la que @content es usado en head. Debido a que el atributo @name es actualmente utilizado con propósitos diferentes en otras partes de HTML, sería un poco confuso usarlo para representar la propiedad name en el body. Por ello, RDFa brinda un nuevo atributo llamado @property, para cumplir ese rol.
Regla #4:#section11
Ya que HTML utiliza la propiedad @name para especificar el nombre de una propiedad en meta, no puede ser usado en otros elementos, por lo que RDFa brinda el nuevo atributo @property.
Supongamos que la fecha de publicación y el nombre del autor de nuestro documento están en la cabecera del documento, y la misma información está en forma entendible para los humanos en el cuerpo del documento:
<html>
<head>
<title>RDFa: Now everyone can have an API</title>
<meta name="author" content="Mark Birbeck" />
<meta name="created" content="2009-05-09" />
</head>
<body>
<h1>RDFa: Now everyone can have an API</h1>
Author: <em>Mark Birbeck</em>
Created: <em>May 9th, 2009</em>
</body>
</html>Con RDFa podemos fusionar estos dos conjuntos de información, para que la metadata sea localizada en el mismo punto que el texto legible:
<html>
<head>
<title>RDFa: Now everyone can have an API</title>
</head>
<body>
<h1>RDFa: Now everyone can have an API</h1>
Author: <em property="author" content="Mark Birbeck">Mark Birbeck</em>
Published: <em property="created" content="2009-05-09">May 14th, 2009</em>
</body>
</html>En un momento veremos cómo podemos mejorar este ejemplo. Por ahora, solo necesitamos reconocer que no importa si la metadata aparece en el cuerpo del documento, o en la cabecera, significa lo mismo─y que esto es meramente el equivalente para texto de la técnica @rel que HTML ya tiene para expresar relaciones en body.
Utilizando vocabularios#section12
Estamos por tomar una pequeña desviación aquí. Podemos usar @name="author" sin problemas en la cabecera del documento porque, a pesar de que la propiedad “author” no está definida en ninguna especificación, la gente lo ha usado a través de los años. No obstante, RDFa permite─y requiere─una mayor precisión. Cuando usamos un término como “author” o “created” necesitamos indicar de dónde proviene ese término. Si no lo hacemos, no hay manera de saber si lo que quieres decir al utilizar “author” es lo mismo que yo creo.
Esto podría parecer innecesario. Después de todo, ¿cómo podría confundirse alguien con un término tan obvio como “author”? Ahora imagina que el término es “country” (“país”) en un sitio web sobre días festivos; ¿el término se refiere al país en que se celebra esa fiesta? ¿o indica que la fiesta se lleva a cabo en todo el país, en vez de una ciudad en específico? Muchas otras palabras también podrían tener diferentes significados en distintos contextos, y si añadimos la posibilidad de lenguajes distintos, pronto te darás cuenta de que si queremos lograr algún progreso con nuestra información, debemos ser precisos. Y eso implica indicar de dónde vienen los términos que usamos.
En RDFa, logramos esto al indicar que queremos usar una cierta colección de términos, o vocabulario. Esto se logra de forma sencilla─solo especifica la dirección del vocabulario, junto con un mapa en su forma compacta, como este:
xmlns:dc="http://purl.org/dc/terms/"(Si entiendes XML, reconocerás que esto es muy similar a la sintaxis para la declaración del namespace en XML.)
Este ejemplo nos brinda acceso a la lista de términos del vocabulario Dublin Core, por medio del prefijo “dc”. Dublin Core tiene muchos términos disponibles para nosotros, y los dos que usaremos en nuestro ejemplo son “creator” y “created”. Para lograr que funcionen, necesitamos poner el prefijo frente a ellos, de la siguiente manera:
dc:creator
dc:createdAhora está completamente claro: “dc:creator” no es lo mismo que “xyz:creator”.
Nótese que el prefijo de mapeo, debe estar localizado en un punto “arriba” del lugar donde será usado en el documento. En nuestro ejemplo, podría ser puesto en el elemento body o en el elemento html. El ejemplo completo podría lucir así:
<html xmlns:dc="http://purl.org/dc/terms/">
<head>
<title>RDFa: Now everyone can have an API</title>
</head>
<body>
<h1>RDFa: Now everyone can have an API</h1> Author: <em property="dc:creator" content="Mark Birbeck">Mark Birbeck</em> Published: <em property="dc:created" content="2009-05-09">May 9th, 2009</em>
</body>
</html>Hay una gran cantidad de vocabularios de dónde escoger, y listaré alguno más en el próximo artículo de esta serie. Por supuesto, nada te detiene de inventar el tuyo propio y utilizarlo en tu compañía, organización, o grupo de interés. Pero debes saber una cosa que comúnmente sorprende a la gente: no hay una organización centralizada que verifique tu trabajo. Sí existen buenas prácticas a seguir. Sin embargo, con el poder viene la responsabilidad, por lo que deberás procurar realizar una investigación previa sobre este proceso, para posteriormente trabajar en tu nuevo vocabulario.
Antes de regresar a nuestro ejemplo, debería añadir un último punto sobre los vocabularios; sin duda alguna debes estar preguntándote por qué a @rel="license" no se le trata igual, y no requiere un prefijo como @property="author". La respuesta es que HTML ya tiene algunos valores por defecto que se utilizan con @rel (como “next” y “prev”), y RDFa añade unos pocos más. Uno de los que añade es “license”.
Pero dejando de lado esa lista de valores─por ejemplo, al usar un término del vocabulario Dublin Core como “replaces” o un término de FOAF como “knows”─entonces debes utilizar la técnica de mapeo con prefijos de la misma manera cómo lo hacemos con @property.
Por ejemplo, digamos que nuestro artículo no solo tiene una licencia CC como vimos anteriormente, sino que también está reemplazando a algún otro documento─una relación que podemos expresar utilizando el término “replaces” de Dublin Core. Expresamos esas dos relaciones de esta manera:
<html xmlns:dc="http://purl.org/dc/terms/">
<head>
<title>RDFa: Now everyone can have an API</title>
</head>
<body>
<h1>RDFa: Now everyone can have an API</h1>
Author: <em property="dc:creator" content="Mark Birbeck">Mark Birbeck</em>
Created: <em property="dc:created" content="2009-05-09">May 9th, 2009</em>
License: <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">CC Attribution-ShareAlike</a>
Previous version: <a rel="dc:replaces" href="rdfa.0.8.html">version 0.8</a>
</body>
</html>Ahora que entendemos los vocabularios, regresemos a nuestro ejemplo principal.
Utilizando texto incrustado para definir el valor de una propiedad#section13
Con el ejemplo anterior, seguro muchos están molestos por haber duplicado el texto “Mark Birbeck” tanto en el atributo @content y el texto en la línea. Si así fue, definitivamente estás entrando en la onda de RDFa. En efecto podemos remover el valor @content si el texto contenido indica el valor que queremos usar como metadata:
Author: <em property="dc:creator">Mark Birbeck</em>
Regla #5:#section14
Si no está presente el atributo @content, entonces el valor de la propiedad será definido utilizando el texto contenido en el elemento.
Aunque la técnica @content deriva del elemento de HTML meta, piensa en el ejemplo anterior como la manera “por defecto” para indicar una propiedad. También le da a los autores mayor libertad con el texto que el usuario lee, ya que pueden ser más precisos con la información embedada. La fecha de publicación ilustra esto; toda la información en los siguientes ejemplos tiene el mismo significado, permitiendo usar formas distintas de representar la información para el lector:
<span property="dc:created" content="2009-05-14">May 14th, 2009</span>
<span property="dc:created" content="2009-05-14">May 14th</span>
<span property="dc:created" content="2009-05-14">14th May</span>
<span property="dc:created" content="2009-05-14">14/05/09</span>
<span property="dc:created" content="2009-05-14">tomorrow</span>
<span property="dc:created" content="2009-05-14">yesterday</span>
<span property="dc:created" content="2009-05-14">14 Mai, 2009</span>
<span property="dc:created" content="2009-05-14">14 maggio, 2009</span>Regla #6:#section15
Si el atributo @content está presente, este sobreescribe el valor en el texto contenido en el elemento, para definir el valor de la propiedad.
En la próxima entrega de ALA, aprenderemos cómo añadir propiedades a una imagen─y cómo añadir metadata a cualquier elemento.
No Comments
More from ALA
En Defensa de los Lectores
Introducción a RDFa (Parte 2)
Trabajando Desde Casa: Los Lectores Responden
Entendiendo la Mejora Progresiva
Creando Proporciones Intrínsecas para Videos