Realizando una búsqueda en la Web que me permita profundizar aun más sobre el tema de los Linked Data (aparecido recién en 2006) o Datos Vinculados (mantendré llamándolos Linked Data para que sea más fácil la adopción del término), he descubierto el blog de Ian Davis un libro sobre Patrones de Linked Data, está sobre licencia creative commons 2.0 por lo que me voy a permitir hablar un poco sobre él.
Qué es Linked Data
Partiendo por lo básico comenzaré por aclarar qué es Linked Data. Linked Data, idea de Tim Berners-Lee, es una forma de publicar datos utilizando HTTP, RDF y una URI (No una URL, la diferencia fundamental entre URI y URL es que URI permite además de identificar un recurso, identificar fragmento específico dentro de una dirección, por ejemplo http://www.ejemplo.com/index.html#fragmento, a diferencia de una URL que solo permitiría http://www.ejemplo.com/index.html). La idea central de los Linked Data se basa en cuatro principios fundamentales:
- Utilizar URIs para identificar recursos publicados en la Web
- Tener publicados estos datos en una URI basada en http con el fin de que puedan ser localizados y consultados.
- Proporcionar información útil, detallada o extra acerca del recurso cuando se acceda a esta URI basada en http.
- Incluir enlaces a otras URI’s relacionadas con los datos contenidos en el recurso de forma que se potencie el descubrimiento de la información sobre la Web.
El fin último de los Linked Data y de toda la información en formato RDF es permitir a aplicaciones y agentes de software la realización de tareas complejas como búsquedas semánticas, deducciones e inferencias sobre datos publicados en Web.
Actualmente existen muchos grupos de Linked Data publicados en la Web (empezando por la DBPedia por ejemplo), para hacerse una idea de su evolución Richard Cyganiak ha generado unos diagramas con la evolución histórica de fuentes de datos vinculados.
Catálogo de Patrones de Linked Data
El libro, el cual por los autores es llamado catálogo de patrones comienza por justificar el por qué un catálogo de patrones. Sus razones (con las cuales estoy absolutamente de acuerdo, ¡era que no!) las expongo:
Porque los patrones de diseño presentan una serie de ventajas:
- Tienen una estructura bien definida, que centra su foco en los conocimientos esenciales que se están comunicando.
- Fomentan la discusión con enfoques complementarios y relacionados a la hora de tomar una decisión de diseño.
- Proporcionan un nombre para una decisión de diseño o solución. Esto permite construir un léxico que fomenta una comunicación más clara entre profesionales.
Los patrones del catálogo están distribuidos en cuatro capítulos:
- Patrones de Identificación – Identifier Patterns (Cap2)
- Patrones de Modelado – Modelling Patterns (Cap3)
- Patrones de Publicación – Publishing Patterns (Cap4)
- Patrones de Aplicación – Application Patterns (Cap5)
Los ejemplos del libro están basados en la sintaxis Turtle de RDF (espero luego darme el trabajo de publicar un pequeño tutorial de Turtle RDF para dar más contexto a quienes recién están empezando ), la cual es mucho más simple de leer que la más conocida RDF-XML y además es compatible con consultas SPARQL
Bien, ahora comenzaré a contarles acerca de cada uno de los patrones en el libro. En esta entrada, dada la extensión del tema, solo hablaré sobre los patrones de Identificación (Capítulo 2 del libro), luego prometo armar 3 entradas más en el blog sobre los demás capítulos (debo hacerlo ya que mi tesis va por este lado). Como todo patrón, éste debe dar solución a un problema de diseño. Cada uno lo expongo a continuación.
Patrones de Identificación
Estos patrones están relacionados con la generación, asignación y creación de URI’s para Linked Data. Los patrones identificados dentro de esta temática son los siguientes:
URI’s Jerárquicas (Hierarchical URIs)
Este patrón se puede aplicar cuando existe una colección de recursos que pueden formar una jerarquía natural. Por ejemplo los capítulos de un libro o departamentos dentro de una organización. El patrón debería tener la siguiente forma en Turtle:
:tipoElemento /:elemento :/tipoSubElemento :/ :subelemento
Ejemplo:
/libros/12345/capitulo/1
En este caso la URI reflejaría de manera natural la colección de todos los capítulos de un libro en particular. Entonces finalmente utilizando el patrón de URI’s Jerárquicas, una solución final podría ser:
ejemplo.com/libros/123/capitulo/1
Claves Literales (Literal Keys)
Este patrón se puede aplicar cuando es necesario publicar un identificador para un fin propio de nuestro uso, es decir no global, para un recurso RDF. El problema que surge al respecto es qué hacer con el identificador global.
Este patrón propone crear una propiedad personalizada que sea sub-clase de la propiedad de identificación del recurso, tal que permita relacionar el valor existente de identificación con el recurso además del nuevo valor de clave.
Claves Naturales (Natural Keys)
Este patrón se puede aplicar cuando se necesita crear una URI única para un conjunto de recursos que por si solos ya tienen una URI única.
La solución propuesta para este caso la describen al nivel de algo tan simple como concatenar las claves únicas existentes con una base de URI adecuada. Para utilizar las URI existentes y poder concatenarlas puede ser útil también codificar esta última.
URI’s Diseñadas (Patterned URIs)
Este patrón se aplica (y es casi una base para los demás patrones de identificación) para generar URIs más limpias y claras. La idea es crear URIs que sigan un patrón común al nivel de poder ser construidas mediante algoritmos. La idea principal es poder crear nuevas URIs en el conjunto de datos basándose en el conocimiento de solo un ejemplo de URI.
La implementación del ejemplo me recuerda en lo personal al funcionamiento de las URIs al usar RESTful. Un ejemplo de este patrón se puede definir si una aplicación va a publicar datos sobre recursos de tipo libro (rdf:type :Libro). En este caso, las URIs a construir para identificar a cada libro tendrían la forma:
/books/1234
Donde /libros es la parte de la base de la URI que indica que se trata de una colección de libros y el 1234 identifica a un libro en particular.
URI’s Proxy (Proxy URIs)
Este patrón se utiliza cuando recursos de terceros no poseen identificadores estándar por si solos, aunque si tengan un identificador como conjunto. Por ejemplo la ISO no podrá tener asignadas URIs únicas a cada uno de los recursos en su conjunto de datos ya que muchos de estos aparecen combinados en diferentes contextos.
En este caso se propone como solución tratar los recursos de terceros de forma idéntica a los recursos propios y asignarles URI dentro del dominio propio.
Claves Compartidas (Shared Keys)
Este patrón es utilizado para simplificar la interconexión de datos. La idea es aplicar el patrón de claves naturales y de URIs Diseñadas de forma que usando diferentes bases de URI pero con iguales identificadores se acceda a información del mismo recurso desde diferentes diferentes URIs.
Un ejemplo que se expone en el libro es el siguiente. La BBC ha creado URIs para acceder a información de artista que son algorítmicamente relacionadas a URIs presentes en MusicBrainz usando una clave compartida común. Los identificadores creados por MusicBrainz son construidos a partir de un ID definido por ellos. Las URIs para el mismo artista en los diferentes sitios serían las siguientes:
BBC
www.bbc.co.uk/music/artists/a74b1b7f-71a5-4011-9441-d0b5e4122711
MusicBrainz
musicbrainz.org/artist/a74b1b7f-71a5-4011-9441-d0b5e4122711
Bien, esto es lo que les cuento por ahora, espero luego agregar los patrones de modelado, publicación y aplicación que dejo pendientes.
