Engranando Información: Un ejemplo del mundo real

team_turning_gears

Tutorial¿Qué es RDF y para que es bueno?

La mayoría del tiempo en el mundo de hoy obtenemos información de un solo lugar. Por ejemplo, una sola base de datos podría contener la información de una línea de productos completa. No existe mucha información distribuida en la web debido a la dificultad de juntar información proveniente de diferentes fuentes, de las cuales cada una podría tener su propio formato de datos y sus propias convenciones.

Acá vemos un escenario en el cual la información distribuida tiene mucho sentido: una base de datos de productos de diferentes proveedores y reseñas de esos productos de múltiples consumidores. Ningún proveedor querrá ser el responsable de mantener una base de datos para este proyecto, dado que este contendrá información de productos de la competencia sin contar con las reseñas negativas. De la misma manera, ningún usuario tendrá los recursos para mantener una base de datos de semejante tamaño. ¿Cómo podemos hacer esto realidad?

RDF es particularmente ideal para este proyecto. Cada proveedor y usuario publicará un archivo RDF en sus sitios web. El proveedor escogerá las URIs para sus productos y los usuarios usarán esas URIs al momento de realizar sus reseñas. Los proveedores no necesitan acordar un esquema para nombrar sus productos y los usuarios no están ligados a un formato definido por el proveedor. RDF permite a los proveedores y a los usuarios coincidir en lo que necesitan coincidir, sin forzar a nadie a usar un vocabulario en particular.

Proveedor 1
proveedor1:productoX	dc:title	        "Cool-O-Matic"
proveedor1:productoX	retail:price	        "$50.75"
proveedor1:productoX	proveedor1:partno	"TTK583"
proveedor1:productoY	dc:title	        "Fluffertron"
proveedor1:productoY	retail:price	        "$26.50"
proveedor1:productoY	proveedor1:partno	"AAL132"
Proveedor 2
proveedor2:producto1	dc:title	          "Cierra Canecas"
proveedor2:producto1	retail:price	          "$28.11"
proveedor2:producto1	proveedor1:warranty_code  "None."
proveedor2:producto2	dc:title	          "Levanta Tierra"
proveedor2:producto2	retail:price	          "$33.21"
proveedor2:producto2	proveedor2:warranty_code	  "X12"
Usuario 1
proveedor1:productoX	dc:description	"Este producto es genial!" .
Usuario 2
proveedor2:producto2  dc:description    "¡Que producto tan innecesario!"
proveedor2:producto2  review:rating     review:Excellent

Es una pregunta abierta el como la aplicación recuperará esos archivos, pero eso se dejará a consideración. Una vez la aplicación tenga esos archivos, tiene la información suficiente como para relacionar los productos con sus reseñas y precios, y también para mostrar información específica como la garantía o el número de la parte (warranty_code y partno). Lo que se debe aprender de este ejemplo es la poca restricción que RDF ofrece, mientras que a su vez permite a las aplicaciones juntar  y relacionar información. Además, las aplicaciones RDF no necesitan saber sobre la naturaleza de los datos en esos archivos para poder usarlos. Si una aplicación ya sabe de antemano que significan dc:title y dc:description, es capaz de presentar los títulos y las reseñas de los cuatro productos. Nótese que la presencia de los predicados que la aplicación no conoce no ocasionan ningún inconveniente. La aplicación simplemente los ignora.

Otro aspecto positivo es que los proveedores y los usuarios no tuvieron que ponerse de acuerdo en mucho para que todo esto pasara. Tuvieron que ponerse de acuerdo en usar EDF, pero no concordaron en ningún formato específico, nisiquiera en la URIs. Ayuda que tengan las mismas URIs para los títulos y los precios, a pesar que no era necesariamente necesario. Lo crucial aquí es que no tuvieron que enumerar todo lo que los proveedores incluyen para sus productos. Cuando un proveedor necesite agregar algo que no estaba entre los acuerdos iniciales (Número del producto o códigos de garantía), ellos podrán agregan un nuevo predicado sin afectar el funcionamiento de ningún sistema existente. Igualmente ningún usuario está atado al vocabulario del proveedor. Los usuarios tienen la libertad de agregar sus propias relaciones, tal como calificaciones, a sus RDFs.

Otro punto de vista válido es la interoperabilidad. El formato del proveedor 1 es totalmente interoperable con el formato de los demás a pesar de que el proveedor 1 no acordó un formato común con los demás. Cuando alguien aparezca y quiera interoperar con la información del proveedor 1, no necesitan un nuevo formato, solo necesitan escoger los sujetos, predicados y objetos correctos.

¿Es esto es mejor que XML? Más adelante se hablará de este tema.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s