Cloud Computing+Web Semántica+Datos Abiertos (II): Linked Data Cloud

Siguiendo el post anterior (Cloud Computing+Web Semántica+Datos Abiertos (I): Linked Data Cloud), vamos a hablar en este segundo post de otros conceptos, pero todos ellos enlazados con lo dicho en el primero: como archivos vinculados, el concepto de representación de los sistemas de archivo de datos como enlace, los URIs, el modelo de datos RDF, los UUIDs, los vocabularios, la semántica de extracción de los metadatos, etc.

3. REPRESENTACIÓN DE LOS SISTEMAS DE ARCHIVO DE DATOS COMO ENLACE

Dado que las características de los sistemas de archivos y datos vinculados difieren significativamente, una serie de medidas tienen que ser realizadas con el fin de levantar los datos del sistema de archivos en una red de datos:

1. las gestiones oportunas para archivos y directorios que se encuentran, que se ajusten a los principios de datos enlazados.

2. Los vocabularios que transmiten las características de los datos encontrados en los sistemas de archivos se han de precisar y estar alineados a los ya existentes con vocabulario pertinente.

3. Los metadatos descriptivos acerca de los archivos tienen que ser extraídos del sistema de archivos y se transforma en el modelo de datos RDF.

4. Los vínculos significativos con otras fuentes de datos externas tienen que ser detectado y establecido.

5. La coherencia entre el sistema de archivos y su correspondiente representación de Datos Vinculados tiene que estar garantizada.

6. Los datos han de ser servidos de acuerdo con los principios de datos vinculados, es decir, en una forma que sea útil tanto para los seres humanos y a las máquinas.

A continuación se describe cómo cada uno de estos pasos se puede realizar.


3.1 ¿Los URIs del archivo en la Web de datos?

En el contexto de un sistema de archivos, los archivos y directorios pueden ser relevados utilizando únicamente sus rutas absolutas, cada una de las cuales consta de una secuencia de nombres de directorio y un nombre de archivo. El archivo: el esquema URI [5] es un medio para reutilizar directamente estas rutas de acceso para formar los URIs, que a su vez pueden ser utilizados para acceder a los recursos de archivos locales en un sistema informático.

Sin embargo, no son los URIs archivos únicos, ya que describen una ruta de acceso local a un recurso en un host en particular, ni estables, ya que los archivos de referencia y directorios se pueden quitar, mover o cambiar de nombre. Por lo tanto, no son adecuados para ser utilizados en una web global de datos.

Para resolver este problema de identificación, se optó por utilizar "opacos", los UUIDs generados aleatoriamente, y asignarlos a los archivos y directorios. El uso de los UUIDs al azar en un contexto global distribuido se supone que es seguro ya que la probabilidad de colisión es suficientemente baja. Además, puesto que los UUIDs son totalmente opacos, que no transmiten información sobre la ubicación física de los archivos y directorios, y por lo tanto estables, incluso cuando los objetos del sistema de archivos subyacente se cambian. Sin embargo, esto requiere de mantener una correspondencia entre los URIs estables, basados en los UUIDs, por una parte, y los identificadores inestables, basados en la trayectoria por el contrario, para garantizar que las modificaciones en el sistema de archivos estén bien reflejados en la representación de datos enlazados. En la sección 3.6 se describe la estrategia para lograr esto.

Figura 1: representación de datos enlazados de un archivo PDF

Figura 2: La interoperabilidad a través del uso de múltiples vocabularios de superposición

3.2 Los Archivos y Directorios Como Recursos de la Web

Las relaciones entre padres e hijos entre los archivos y directorios se pueden representar como triples RDF con predicados apropiados. Varios triples se añaden a cada recurso de archivo o directorio que transmiten datos que son recuperados directamente del sistema de archivos: el nombre del local (es decir, el archivo real o el nombre de directorio sin la información de la ruta completa), el tamaño del archivo, y las fechas de creación y la última modificación. Un ejemplo de la representación de un archivo RDF es representado en la figura 1. Los recursos que representan los archivos o directorios son internos identificados por URNs basados en UUIDs, para servir como datos vinculados son dinámicamente reescritos para HTTP URI (véase la sección 3.7).

3.3 Vocabularios

Con el fin de describir los archivos, directorios, sus metadatos y sus relaciones como RDF, hemos desarrollado un vocabulario de OWL sencillo publicado en http://purl.org/tripfs/2010/02 #. Hemos derivado nuestro vocabulario de los actuales vocabularios semánticos tanto como sea posible. Sin embargo, como es actualmente poco común el exponer los recursos de archivo como datos vinculados, se observó una falta de vocabularios aceptados en la comunidad para este fin. En mejor de nuestro conocimiento, sólo la NEPOMUK del Archivo Ontológico  (NFO) ha definido con precisión el modelo de los contenidos de los sistemas de archivos. Proporciona los términos para describir los archivos, directorios y sus propiedades. Nuestro vocabulario está alineado con NFO y proporciona condiciones más especializadas, de acuerdo a las necesidades de nuestro sistema.

Un número de otros vocabularios, sin embargo, tienen una noción general del concepto de documentos, y por lo general de adaptar este concepto a la foaf: clase de documento. Por otra parte, varios vocabularios tienen una noción de las colecciones, que se pueden comparar a los directorios en un sistema de archivos, por ejemplo, OAI-ORE [17] o Dublin Core. El Dublin Core-Tipo de Vocabulario, como otro ejemplo, que define los términos de los tipos de recursos diferentes así como las colecciones. Además, existe una gran cantidad de vocabulario que se puede utilizar para identificar los tipos de medios de comunicación y sus especificidades, por ejemplo, el estándar de ontología MPEG-7, la ontología musical , o el conjunto de ontologías NEPOMUK.

Para alcanzar un nivel máximo de interoperabilidad, un origen de datos debe tener como objetivo que se adhieran al vocabulario comúnmente aceptado tanto como sea posible. La semántica de RDF permite mezclar arbitrariamente vocabularios diferentes, sin relación, por lo que proponemos | además de utilizar un vocabulario personalizado | al modelo de datos del sistema de archivos utilizando el vocabulario NFO, y para añadir información de tipo de vocabularios populares como Dublin Core y FOAF y cuando se ajusten . Al servir a los datos mediante múltiples, incluso vocabularios ya alineados, que alivien a los consumidores de datos de la necesidad de realizar inferencia adicional. Un ejemplo de tal representación mixta se presenta en la Figura 2.

3.4 La Semántica de Extracción de Metadatos

Los actuales sistemas de archivo sólo proporcionan un conjunto limitado de metadatos de bajo nivel con los atributos asociados a los archivos como el nombre, propietario, tamaño, fecha de creación y modificación, o los atributos de permiso. Los modernos sistemas de archivo proporcionan medios adicionales para almacenar metadatos de nivel superior, al igual que los atributos extendidos o varias secuencias de datos, pero estos sólo son útiles si en realidad están poblados por las aplicaciones, que es raramente el caso.

Figura 3: Los metadatos extraídos de un PDF y un archivo MP3

Figura 4: Los enlaces externos a DBLP y MusicBrainz

Ya que es uno de los principios de los datos vinculados a / proporcionar información útil sobre un recurso cuando un cliente des-referencia su URI, es conveniente para extraer metadatos adicionales, descriptivo de los archivos y directorios y los exponen también a los datos vinculados. Reconsiderar, por ejemplo , en el escenario A se describe, en la sección 2, donde el valor de los metadatos de nivel de archivo del sistema (como el tamaño del archivo, tipo de archivo o los permisos de archivos) es limitada; los metadatos descriptivos de alto nivel se pueden utilizar para la recuperación selectiva de los archivos, respectivamente, sus descripciones, por ejemplo, a través de SPARQL, si es necesario. Sin embargo, la combinación de estos metadatos permite la detección sofisticada de recuperación de datos y los métodos de acceso basados en (i) el padre / hijo de las relaciones de los objetos del sistema de archivos, (ii) los metadatos del sistema de bajo nivel de archivo, y ( iii) los metadatos de alto nivel basados en el contenido.

El problema de la extracción de metadatos de los sistemas de archivos se ha estudiado durante mucho tiempo. El mayor desafío en este ámbito es la diversidad de datos que se encuentran en los sistemas de archivo, que se impone por la multitud de tipos de archivos diferentes. Para ilustrar esto, en la actualidad más de 51.000 tipos de archivos se registran en el popular FILExt service. Los diferentes tipos de archivos presentan diferentes estructuras internas y, en consecuencia los metadatos distintos pueden ser extraídos. Por tanto, es poco práctico para proporcionar extractores de metadatos para esta gran cantidad de diferentes tipos de archivos dentro de un componente de software. El lugar más viable para definir un marco de extracción de metadatos genérico que permita a los componentes específicos de extracción para diferentes tipos de archivos ser enchufados en. Por ello, el sistema puede ser adaptado al contexto de aplicación respectiva.

En nuestro enfoque, los extractores de leer los archivos y extraer un grafo RDF que contiene triples representan los metadatos extraídos. Los extractores múltiples se pueden conectar en cascada en una "tubería de aspiración" y se aplican secuencialmente a cada objeto. El resultado de los gráficos RDF se almacenan en el almacén de triples y luego se desempeñan como parte de los archivos y la descripción de la guía es a través de la interfaz de datos vinculados. Los extractores pueden extraer no sólo archivos de metadatos (es decir, datos acerca de los documentos representados por los archivos), sino también a entidades que están relacionadas con los archivos (por ejemplo, el artista que ha realizado la música almacenada en un archivo MP3) y a su vez pueden estar vinculados a fuentes de datos externas.

A modo de ejemplo, en la Figura 3 se muestra la representación de metadatos RDF que se han extraído a partir de dos archivos, el primer recurso representa un documento PDF que contiene una publicación científica, la segunda representa un archivo de audio MP3 (En este ejemplo hemos utilizado los términos de la OSCAF / ontologías NEPOMUK http://www.semanticdesktop.org /ontologies). El nodo blanco de los utilizados para identificar al artista en este ejemplo (línea 9), debe ser reescrito de forma dinámica a un "recinto cerrado", des-referenciables URI por el servidor web (ver sección 3.7).

3.5 Archivos con vínculos a fuentes externas

Una vez que los archivos y directorios se representan como recursos RDF es posible vincularlos con otros recursos relacionados en la Web. Si lo hace, permite a los clientes obtener más información potencialmente interesante sobre el recurso. Por ejemplo, los archivos se pueden clasificar de acuerdo a un esquema de clasificación que utiliza URI des-referenciables como identificadores, en este caso, los clientes están habilitados para consultar los archivos utilizando estos términos.

La tarea de vincular los archivos y directorios a los recursos externos se puede lograr por las herramientas que proporciona esta funcionalidad de los recursos genéricos Web, que normalmente se aplican diversas heurísticas para detectar los recursos relacionados semánticamente (por ejemplo, los identificadores de objeto común o similar [22]). Estas heurísticas dependerán de la información que está disponible para una entidad en particular, por lo que en el contexto de un sistema de archivos dependen de los datos proporcionados por los componentes de extracción de metadatos, como se describe en la sección anterior.

Tabla 1: Reacciones de los eventos del sistema de archivos detectados por el componente de observador

Como consecuencia de ello, seguimos la misma estrategia que para los extractores de metadatos y no proporcionan un todo-en-una solución para el problema de vincular los archivos a los recursos externos, sino que proporcionan un marco que permita vincular componentes especializados para ser enchufados. Estos componentes de vinculación pueden tener acceso no sólo al archivo de datos en bruto, sino que también extraen los metadatos, y utilizar esta información como base para la interconexión. Al igual que los extractores, que unen los componentes de retorno triples RDF se añaden al modelo de metadatos y sirven a través de la interfaz de datos vinculados.

A modo de ejemplo, en la Figura 4 se muestra las fuentes externas de una publicación científica y a un archivo de música se puede vincular, con base en la similitud de secuencia entre el título de la publicación y la combinación de título de la pista y el nombre del artista, respectivamente. En este ejemplo el documento PDF a partir de la figura 3 se ha relacionado con la variante de datos vinculados de la base de datos DBLP de la popular publicación, y el archivo MP3 se ha vinculado a los recursos del servicio MusicBrainz.

3.6 El mantenimiento de la coherencia

Como se describe en la Sección 3.1, se requiere a la mención de un UUID basado en URI para cada archivo y directorio, que puede ser considerado único en el mundo desde un punto de vista práctico. Sin embargo, sin más precauciones el URI  puede ser bastante inestable como la asignación entre un UUID basado en URI externo y un archivo basado en URI interno se invalida cada vez que un archivo de referencia se mueve, se elimina o cambia de nombre. Además, la actualización de dichos archivos puede dar lugar a incoherencias entre un archivo y los metadatos que han sido extraídos y almacenados. Tenga en cuenta que esto podría dar lugar también a los enlaces no válidos entre los recursos si estos se crean automáticamente sobre la base de metadatos del archivo, tal como se describe en la Sección 3.5.

Con el fin de preservar una asignación estable entre estos URIs y los archivos locales y directorios que representan, tenemos que emplear un componente vigilante que se encarga de la detección de eventos del sistema de archivos que pueden resultar en URIs de archivo diferente o modificando el contenido del archivo de archivos de referencia. Cada vez que un evento es detectado, las acciones apropiadas deben adoptarse, y el modelo RDF se tiene que actualizar. Tenga en cuenta que en este sentido, la asignación entre estables URIs basados en UUID y el archivo inestable y los caminos de la guía, actúan como una especie de servicio de traducción entre las URIs externas, con base en UUID válida a nivel mundial y las correspondientes URIs de archivos local, comparable a los servicios de PURL o DOI [2 ]. La Tabla 1 resume las reacciones que tienen que ser tomadas después de que los eventos del sistema de archivos se han detectado.

3.7 Servicio de sistemas de archivos como Recursos de la Web

Una vez que la representación RDF basada en los archivos y directorios, y los enlaces a fuentes de datos externas, el resultado gráfico del RDF puede servir de acuerdo a los principios de datos vinculados. Con este fin, en los URNs basados en UUID son dinámicamente reescritos para URIs basados en HTTP con la parte de host configurable, por ejemplo, http://example.com:8080/resource/ . Se considera una buena práctica [7] para servir al menos a dos variantes de los datos, una representación RDF para las máquinas y una representación HTML para el consumo humano, y que permitirá a los clientes elegir la representación que prefieran usar en la negociación de contenido HTTP que se ha generado y enriquecido con metadatos extraídos. Además de servir a los recursos de acuerdo a los principios de los datos vinculados, se recomienda proporcionar un punto final SPARQL [10] para permitir a los clientes que busquen los recursos basados en sus descripciones RDF. 

Figura 5: Acceso a archivos locales a través de una representación de datos vinculados

Además, los datos de archivo real por sí mismo pueden ser descargados en el cliente. En el caso concreto de los recursos de los datos vinculados que se obtienen a nivel local (es decir, el servidor y el cliente se ejecutan en la misma máquina), el servidor Web puede agregar vínculos a la interfaz HTML que permiten al usuario abrir directamente los archivos o directorios en marcha desde el navegador , proporcionando así una experiencia de interacción sin fisuras. En la Figura 5 se muestra una captura de pantalla de este tipo de interfaz basada en HTML, que proporciona estas opciones para el usuario.

En el tercer post (Cloud Computing+Web Semántica+Datos Abiertos (III): Linked Data Cloud)

sobre este tema hablaremos de la aplicación TripFS, de los relacionados con el trabajo, así como de las conclusiones y del trabajo de futuro. Expondremos una relación referencial de todas las fuentes consultadas (referidas a [número]).

Aquí tienen una presentación de Davide Palmisano explicando el estado actual de los Datos Vinculados: "Desde la Web Semántica en la Web de los datos: diez años de vinculación "

 

From the Semantic Web to the Web of Data: ten years of linking up

View more presentations from Davide Palmisano.

Artículos relacionados: 

• Cloud Computing+Web Semántica+Datos Abiertos (I): Linked Data Cloud
• What do HTTP URIs Identify? - Design Issues (w3.org)
• Pezholio " Blog Archive " A beginner's guide to SPARQLing linked data (Part 1) (pezholio.co.uk)
• Use Case: Semantic Web Technologies in Automotive Repair and Diagnostic (w3.org)