Existen diferentes modelos para el tratamiento de datos enlazados dentro de repositorios OAI-PMH. En la mayoría de los casos las plataformas empleadas, el software soportado o los proyectos de aplicación, suelen determinar cómo proceder con cada uno de ellos. Resultaría realmente complejo categorizar todas las propuestas que existen, ya que cada una de ellas se adapta a la realidad tecnológica con la que tiene que trabajar, así como a la naturaleza de los datos. Pero sí destacaremos alguno que nos ha servido a modo de guía o patrón, como por ejemplo el trabajo de Coppens, que aporta una forma muy novedosa de gestionar fondos de archivo empleando datos enlazados por medio de los estándares de descripción EAD e ISAD-G (Coppens y otros, 2009). En el mismo sentido, la forma en la que Europeana ha integrado los materiales de archivos, bibliotecas y museos (Haslhofer y otros, 2011; Doerr y otros, 2011), o Nestor, una aplicación construida a partir de la experiencia práctica de varios archiveros, y que emplea EAD para los metadatos (Ferro y Silvello, 2013), son ejemplos clave.

Existe un grupo de iniciativas que, para preservar datos digitales, ha optado por OAI-PMH por las ventajas que presenta este modelo. Nos hemos centrado en el estudio de Preso, que busca la creación de espacios para preservar materiales fílmicos y fotográficos. Por su ámbito de actuación, la Unión Europea, se orienta a ofrecer soporte para Europeana (Addis y otros, 2010).

Aunque el uso de OAI-PMH está bastante generalizado, también se han estudiado aquellos proyectos que proponen complementar este protocolo por medio de diferentes mecanismos. Así OAI2LOD es un servidor, compatible con protocolos de interoperabilidad, que permite consultar los metadatos con SPARQL (Sparql Protocol and RDF Query Language). Realmente esto supone un salto cualitativo con respecto al resto de proyectos, ya que resulta posible sacar más partido a las relaciones existentes entre los datos. En concreto el trabajo con las relaciones “same as” entre dos instancias del servidor aporta una mayor riqueza en las búsquedas (Haslhofer y Schnadl, 2008, 2010). Para lograr esto, el software servidor compara los valores de un conjunto de atributos seleccionados manualmente según su similaridad léxica usando la distancia Levensthein. Es un sistema modular, ya que para la transformación de los datos en RDF/XML se emplea otro servidor que trabaja de forma paralela, D2RQ Server (Bizer y Seaborne, 2004). Uno de los principales problemas detectados en OAI2LOD, la imposibilidad de compaginar varios proveedores de datos, se resolvió con importantes mejoras realizadas por Coppens, que permitieron la importación de datos procedentes de diversos repositorios OAI-PMH (Coppens y otros, 2013).

Una de las áreas más investigadas dentro del ámbito de la Web Semántica ha sido la recuperación de información. Entre las primeras aproximaciones destaca Sindice, que embebe datos RDF y los microformatos que los describen en un servidor que se consulta por medio de un SPARQL Endpoint, permitiendo realizar consultas semánticas sobre los recursos almacenados (Tummarello y otros, 2007). Otras aportaciones que han servido como base para el trabajo que se describe en este texto es el método de construcción de índices en tiempo real que emplea Squin (Hartig y otros, 2009), y las consultas basadas en reglas que emplea FedX, que por medio del framework Sesame permite la optimización de consultas federadas (Schwarte y otros, 2011).

En esa misma línea, pero empleando técnicas diferentes, se encuentra el motor Darq, que complementa ese tipo de búsquedas con un sistema de toma de decisiones para refinar las búsquedas federadas (Quilitz y Leser, 2008). Existen otros sistemas que se valen de información estadística para realizar procesos similares, como Splendid (Görlitz y Staab, 2011). El problema es que ambos métodos se centran demasiado en técnicas complementarias y no exploran lo suficiente las facilidades semánticas de recuperación de información a través del lenguaje OWL. Precisamente por ese motivo consideramos tan destacada la aportación de Coppens, que gestiona datos enlazados mediante un índice estructurado para optimizar las consultas OWL:same as en los Endpoints locales y remotos de SPARQL de forma simultánea (Coppens y otros, 2013).

También ha servido de base para el proyecto CoroArchivo el motor de consultas Elite, que permite mapear con gran facilitad las relaciones entre los datos por medio de estructuras R-Tree, integrando información de diversa índole (incluidas tripletas RDF) con bases de datos relacionales (Nolle y Nemirovski, 2013).

La combinación de estas tecnologías ha servido para desarrollar el sistema de búsqueda federada de nuestro proyecto, enriqueciendo las consultas del tipo OWL:same as. Se ha optado por mapear las clases que se obtienen de la búsqueda distribuida para filtrar mejor la información. La similaridad de los datos se obtiene mediante el cálculo de la distancia Manhattan. Los resultados se complementan con las etiquetas OWL:equivalentClass, OWL:equivalentProperty, OWL:differentFrom y OWL:AllDifferent, combinadas con el algoritmo de OWL2tips (Domínguez-Velasco, 2013a). Al igual que en Elite, nuestra propuesta emplea un razonador para formular las consultas y un módulo de indexación distribuida que conecta el sistema con ontologías, tanto locales como externas, a partir de mapas de referencias.

Hemos utilizado el software open source DSpace, que gestiona repositorios compatibles OAI-PMH usando un solo data center.

A pesar de las deficiencias que se le atribuyen a la filosofía OAI-PMH, porque, al solo contar con el protocolo de metadatos OAI-DC (Schöpfel y otros, 2012), gestiona con austeridad las descripciones bibliográficas, y porque a veces forma parte de la web invisible y resulta poco accesible para los servicios de búsqueda (Merlino-Santesteban, 2012), DSpace ha ganado popularidad cuando gestiona datos semánticos sobre todo gracias a:

El sistema está operativo en la Universidad Central de las Villas (UCLV), donde el convenio de universidades flamencas VLIR tiene instaladas las infraestructuras tecnológicas necesarias para su funcionamiento (tabla II).

A continuación se detalla el proceso de transformación de los datos:

Drupal, desarrollado a partir de 1999 por Dries Buytaert, y publicado bajo licencia GNU dos años más tarde, genera sitios web combinando varios “bloques” para adaptar sus funcionalidades a las necesidades específicas. Es además un “content management framework” (Byron y otros, 2012). La información se almacena en una base de datos relacional (MySQL, PostgreSQL, SQLite…) por medio del lenguaje de programación PHP. Permite la publicación de datos en formato RDF, además de soportar otros, como n-triples, JSON, XML, RSS y turtle. Gestiona las URIs de los materiales RDF publicados y un SPARQL Endpoint para la consulta. Se pueden personalizar los campos RDF y los namespaces (Alonso-Sierra y otros, 2012).

La búsqueda facetada y las consultas en SPARQL se realizan por medio de los siguientes módulos de Drupal:

Instalados los módulos necesarios, OWL2tips (Domínguez-Velasco, 2013a) facilita la visualización en formato OWL y la transformación de las descripciones archivísticas a estructura LIAM, capaz de operar con grandes conjuntos de datos.

Coroimagen UCLV es un conjunto de datos que posee 1.422 instancias, más de 68 datasets y 5 servicios de archivo descargados de VIAF, Europeana, DLBP y de los archivos de la propia institución donde se realiza la prueba. La mayor complejidad para manejar estos recursos es establecer la correspondencia entre los datasets con las fuentes de información, como sucede con DSnotify (Popitsch y Haslhofer, 2011).

Se creó, por ese motivo, un archivo que establece la relación entre los elementos utilizados en la descripción que hace posible medir el nivel de eficiencia de CoroArchivo a partir de los eventos que registra la aplicación y su influencia en f-mesure. Dicho archivo sirvió también para detectar que existía un elevado número de instancias, 98, que estaban mal escritas. Para subsanar este error se crearon indicadores de exclusión que aislaran del experimento aquellas instancias cuyo nivel de ocurrencia afectaba al proceso de evaluación. Así fue posible lograr una distribución homogénea de eventos en un tiempo determinado y minimizar los problemas de entropía.

Se decidió realizar la evaluación de acuerdo con los procedimientos de Popitsh y Haslhofer (Popitsch y Haslhofer, 2011), que verifica el funcionamiento de una plataforma con información que implica control de autoridades. En nuestro caso queríamos analizar en qué medida la precisión y la exhaustividad (F-measure) influían en el rendimiento de la herramienta. Para ello se utilizó: un vocabulario capaz de almacenar la información del proceso (Leiva-Mederos y otros, 2013); un módulo de monitorización de eventos; un simulador encargado de representar los datasets en otros entornos de la Universidad; y un analizador que mostraba y examinaba los parámetros seleccionados para emitir los resultados de la evaluación.

Con un algoritmo denominado jump (Domínguez-Velasco y Leiva-Mederos, 2013) se registraron los valores de entropía de las propiedades de los namespaces que se alojan en la plataforma con una cobertura menor del 20%. Estos valores se originaban en caso de que los recursos involucrados en el proceso tuvieran cubiertos sus datasets con al menos un 20% de instancias. Los recursos evaluados fueron Europeana, VIAF, DLBP y el archivo de la UCLV, seleccionando los elementos que caracterizan un documento que tienen buena representación en los datasets:

La evaluación de la entropía sirve para seleccionar los namespaces con mejores valores de C, H y Hnorm, de acuerdo con las características de un documento (tabla III). Los namespaces evaluados fueron:

http://xmlns.com/foaf/0.1/

http://xmlns.com/foaf/0.1/

http://www.europeana.eu/schemas/ese/

http://purl.org/dc/elements/1.1/

http://viaf.org/viaf/data/

El resultado de la tabla III muestra que los mejores resultados en el proceso de evaluación de entropía, H y Hn son superiores en los datasets de Europeana y en los de VIAF, debido a la calidad de las descripciones de los datos. Los datasets locales, etiquetados con la sigla uclvf, mantienen buenos índices de evaluación, todos por encima de 0,5. Se decidió usar en el test las características uclvf:type, skos:Concept, edm:collectionName, foaf:document, foaf:mane, uclvf:title, edm:EdmType, que tienen mayor representatividad en cada uno de los sistemas de información seleccionados, y que representan lo esencial de un documento.

A continuación se llevó a cabo una simulación, poniendo en funcionamiento el software durante 60 segundos para acceder al 30% de las instancias, como en trabajos que pretendían evaluaciones similares (Sing-Borrajo, 2013), para así monitorizar los cambios en los datasets con una tasa media de 7,03 eventos, resultado del cociente 422/60 seg. Se trataba de analizar la influencia de los eventos de la plataforma en su exhaustividad y precisión. Para ello se repitió la prueba con diferentes intervalos (4 s., 8 s., 15 s., 25 s., 45 s.), que registraron un promedio de 12, 21, 34, 43 y 379 por cada segundo de ejecución del sistema.