Analyzing and Normalizing Type Metadata for a Large Aggregated Digital Library

Referencia del articulo

Lynch, Joshua D.; Gibson, Jessica; Han, M.-J. (2020). Analyzing and Normalizing Type Metadata for a Large Aggregated Digital Library. The Code4Lib Journal, (47). Recuperado de: https://journal.code4lib.org/articles/14995

Resumen original

The Illinois Digital Heritage Hub (IDHH) gathers and enhances metadata from contributing institutions around the state of Illinois and provides this metadata to the Digital Public Library of America (DPLA) for greater access. The IDHH helps contributors shape their metadata to the standards recommended and required by the DPLA in part by analyzing and enhancing aggregated metadata. In late 2018, the IDHH undertook a project to address a particularly problematic field, Type metadata. This paper walks through the project, detailing the process of gathering and analyzing metadata using the DPLA API and OpenRefine, data remediation through XSL transformations in conjunction with local improvements by contributing institutions, and the DPLA ingestion system’s quality controls.

Resumen traducido

El Illinois Digital Heritage Hub (IDHH) recopila y mejora los metadatos de las instituciones que contribuyen en todo el estado de Illinois y proporciona estos metadatos a la Biblioteca Pública Digital de América (DPLA) para un mayor acceso. El IDHH ayuda a los contribuyentes a dar forma a sus metadatos según los estándares recomendados y requeridos por el DPLA, en parte mediante el análisis y la mejora de los metadatos agregados. A finales de 2018, el IDHH emprendió un proyecto para abordar un campo particularmente problemático, los metadatos de tipo. Este documento describe el proyecto, detallando el proceso de recopilación y análisis de metadatos utilizando la API de DPLA y OpenRefine, la corrección de datos a través de transformaciones XSL junto con las mejoras locales de las instituciones contribuyentes y los controles de calidad del sistema de ingestión de DPLA.

Resumen detallado con cada una de sus partes

Antecedentes: problemas con los metadatos de tipo y los controles de calidad existentes

Introducción a IDHH y metadatos de tipos

El Illinois Digital Heritage Hub (IDHH) recopila y mejora los metadatos de las instituciones colaboradoras de Illinois y proporciona estos metadatos a la Biblioteca Pública Digital de América (DPLA) para un mayor acceso. El IDHH ayuda a los contribuyentes a dar forma a sus metadatos según los estándares recomendados y requeridos por el DPLA. Este documento describe el proceso para recopilar y analizar los metadatos de tipo de los contribuyentes, los problemas observados en el análisis de los metadatos y las formas en que los contribuyentes, el IDHH y el DPLA solucionaron los problemas encontrados en el análisis.

El IDHH es el Centro de servicios de Illinois para la Biblioteca Pública Digital de América (DPLA), y una colaboración entre la Biblioteca Estatal de Illinois (ISL), el Consorcio de Bibliotecas Académicas y de Investigación en Illinois (CARLI), la Biblioteca Pública de Chicago (CPL) y la Universidad de Biblioteca Illinois Urbana-Champaign (UIUC). En julio de 2019, el IDHH agregó metadatos de aproximadamente 150 instituciones contribuyentes individuales en todo el estado. Los metadatos se recopilan como Qualified Dublin Core (QDC), también conocidos como Términos de metadatos DCMI (dcterms), y se proporcionan como registros QDC a la DPLA.

En julio de 2019, el IDHH recopiló y expuso más de 310,000 registros de 448 colecciones digitales. Mediante evaluación de metadatos, un documento de mejores prácticas y formación; El IDHH ha realizado importantes esfuerzos para que los metadatos de los contribuyentes se ajusten a los estándares y recomendaciones de DPLA que, en última instancia, mejoran la capacidad de descubrimiento de los ricos y únicos recursos digitales del IDHH.

Como en cualquier entorno agregado, algunos campos, incluido el Tipo, han sido difíciles de estandarizar en las instituciones contribuyentes del IDHH. El DPLA tiene controles de calidad sólidos para todos sus metadatos y refinamientos específicos para el campo Tipo. Sin embargo, sus sistemas de ingestión requieren una línea de base de calidad que no estaba presente en los metadatos de tipo del IDHH. Los metadatos del tipo IDHH son muy diversos y los requisitos de DPLA son estrictos; mientras que todos los metadatos de los registros originales se conservan y están disponibles en la API de DPLA, solo el tipo DCMI valores, como 'Imagen', 'Imagen en movimiento', 'Objeto físico', 'Sonido' y 'Texto' facetable en la API y el catálogo de DPLA. El tipo es uno de varios campos de datos que DPLA utiliza para crear facetas mediante las cuales restringir los resultados de la búsqueda y vincular desde un registro individual a una lista de elementos de un Tipo determinado. Los sistemas de ingestión de DPLA proporcionan asignaciones entre una lista establecida de elementos no conformes. valores y tipos de DCMI, pero las asignaciones y las características de catálogo posteriores que se basan en los valores de tipo de DCMI parecen funcionar mejor cuando hay valores de tipo de DCMI válidos en un registro original. Debido a su importancia para el acceso, el descubrimiento y la interactividad, y las bajas tasas de finalización como se ve en la interfaz de búsqueda de DPLA, se determinó que era necesario mejorar los metadatos Tipo aportados por las instituciones del IDHH. El análisis inicial reveló que había 558 valores de Tipo únicos en todos los registros de IDHH. Después del análisis de metadatos, se llevó a cabo un enfoque triple para mejorar los metadatos de tipo. Los metadatos de tipo aportados por las instituciones del IDHH podrían mejorarse mediante:

1. instituciones que presenten metadatos de mejor calidad

2. Transformaciones XSL más robustas de los metadatos agregados por el IDHH

3. trabajar con la DPLA para mejorar sus controles de calidad en los metadatos de Tipo IDHH, lo que a su vez puede conducir a controles de calidad mejorados en Tipo y otros campos para otros centros que aportan metadatos a la DPLA.

Descripción general de los problemas de metadatos de tipo IDHH

El análisis en profundidad que se analiza en detalle a continuación mostró que, a partir del 13 de diciembre de 2018, había al menos 558 valores de metadatos de tipo únicos entre aproximadamente 327,000 valores en total. Sólo alrededor de 176.000 de los 327.000 valores totales se ajustaban perfectamente al tipo DCMI. Debido al gran volumen de valores únicos que ingresan y las limitaciones en la Ingestión 1 de DPLA controles de calidad, solo aproximadamente 61.000 valores de metadatos se muestran y funcionan como facetas de trabajo en las interfaces de búsqueda de DPLA. Esto representó solo un valor de Tipo de DCMI por cada cinco registros que las instituciones del IDHH habían contribuido al DPLA.

Inspección de metadatos de tipo IDHH

Análisis inicial mediante el panel de análisis de DPLA y las herramientas de agregación DPLA OAI desarrollado originalmente por el Centro de Patrimonio Digital de Carolina del Norte y modificado por el IDHH, solo arañó la superficie de lo que parecían ser problemas generalizados con los metadatos de tipo aportados por el IDHH. Si bien las herramientas de agregación revelarían metadatos de tipo dentro de una sola colección, el análisis de datos a gran escala no podría lograrse fácilmente con ellos debido a su diseño listo para usar que evalúa un conjunto de registros a la vez.

El personal de IDHH y DPLA hizo varios intentos de 2017 a 2018 para analizar los metadatos de todo el conjunto de registros de IDHH con OpenRefine. Debido al tamaño del conjunto y posiblemente a la memoria insuficiente disponible en las máquinas que facilitan este esfuerzo, OpenRefine no pudo analizar el conjunto de datos después de varios intentos. Además, aunque OpenRefine admite la recopilación y el análisis de XML a través de consultas OAI-PMH, el personal de IDHH desconocía, incluso después de una extensa investigación, si OpenRefine puede manejar los tokens de reanudación y cómo. Por lo tanto, el único método conocido por el personal de IDHH para lidiar con grandes conjuntos OAI-PMH con OpenRefine es el tedioso proceso de ingresar manualmente tokens de reanudación.

Se investigaron métodos alternativos para recopilar y analizar todos los metadatos de tipo IDHH, incluida la descarga masiva de datos JSON-LD creados por DPLA a partir del XML recopilado de IDHH y que llaman a la API de DPLA para muestras más pequeñas de datos JSON-LD. En última instancia, se seleccionó la última opción principalmente porque las herramientas de análisis de datos como OpenRefine funcionan mejor con datos JSON que con XML y porque la recopilación de datos a través de la API proporcionaría los datos más actualizados disponibles de DPLA en un paquete bastante pequeño. La descarga de un subconjunto de metadatos de todos los registros IDHH, incluidos solo los pares clave-valor de tipo de cada registro y otros cuatro campos que se analizan a continuación, fue de alrededor de 100 MB, en comparación con la descarga masiva de 1 GB de todos los metadatos IDHH.

Una secuencia de comandos de Python se creó para generar llamadas a la API DPLA y descargar todos los datos JSON-LD para cada proveedor de datos IDHH, tal como se leen desde un archivo csv UTF-8. Esta secuencia de comandos se puede ejecutar en Python 2.7 o superior y requiere la instalación de la biblioteca de solicitudes, que se utiliza para interactuar con la API DPLA. Puede parecer más obvio utilizar la API para recopilar todos los registros que contienen el nombre o ID del concentrador en los metadatos del proveedor. El problema con este enfoque es que la API limita las llamadas a 100 páginas de 500 resultados cada una, o un máximo de 50.000 registros. Como solo uno de los proveedores de IDHH actualmente aporta más de 50.000 registros y sus metadatos ya se ajustan bien al tipo DCMI, se decidió recopilar colecciones por proveedor para trabajar dentro del límite de la API. El script descargó más de 900 archivos de datos JSON-LD que contienen los datos de al menos el 94% de los más de 300.000 registros del IDHH. El 6% restante está compuesto por registros proporcionados por la institución única, discutida anteriormente, cuyos registros suman más de 50,000 y, por lo tanto, exceden los límites de llamadas de la API de DPLA . Luego, los archivos JSON-LD se importaron a OpenRefine 3.0 en la máquina local del especialista en metadatos y se analizaron en OpenRefine como archivos JSON. La tabla OpenRefine inicial reveló que muchos registros tenían dos instancias de los campos sourceResource.type u originalRecord.type con los valores correspondientes debido a la presencia de dos elementos en los registros XML proporcionados originalmente al DPLA. Se requirió un mayor refinamiento para priorizar los elementos de acción de los abrumadores resultados. Las facetas originalRecord.type y los recuentos correspondientes se descargaron del conjunto original de OpenRefine y se importaron a otra hoja de OpenRefine. Las facetas se ordenaron alfabéticamente y distinguiendo entre mayúsculas y minúsculas. Se realizó una operación en blanco para eliminar los duplicados que resultaron de las dos columnas, las celdas de varios valores se unieron para obtener los recuentos totales de las filas en blanco y las que están encima de ellas, y las celdas de varios valores se sumaron creando una nueva columna. El producto final fue una hoja de cálculo de 558 valores de tipo y sus respectivos recuentos de todas las colecciones de IDHH.

El número de valores de Tipo únicos reveló problemas que el IDHH no pudo resolver mediante la transformación XSL únicamente. Además de la normalización masiva de valores comunes por parte del IDHH, se identificaron otras dos categorías de problemas: aquellos que deberían ser corregidos por el DPLA y aquellos que simplemente necesitarían ser abordados por contribuyentes individuales para refinar los metadatos que proporcionan.

Soluciones para la limpieza de datos

Mejoras de IDHH XSL

Gran parte del trabajo de mejorar los metadatos de tipo se puede manejar automáticamente a través de transformaciones de hojas de estilo XSL aplicadas en el servidor de agregación IDHH REPOX. Se desarrolló una plantilla XSL para hacer coincidir el elemento dc: type y realizar operaciones en el nodo de texto, por ejemplo, el valor de metadatos Type que contiene el elemento dc: type.

Problemas resueltos con XSL

Muchos proveedores utilizan comas o una combinación de valores separados por comas y, el delimitador más común, punto y coma. Ocasionalmente, aparecen comas y puntos y comas en el mismo campo. En las plantillas XSL para transformar el tipo, una línea de código que utiliza la función XPath replace () convierte las comas en punto y coma para normalizar el delimitador.

La expresión tokenize () XPath2 se usa para dividir múltiples valores y luego, cada token se inspecciona por separado usando un bucle for-each que llama a una plantilla para hacer coincidir un token con el tipo DCMI correcto.

En lugar de depender de una coincidencia exacta de un determinado valor de cadena, el XSL transforma esta cadena en minúsculas si contiene una determinada palabra clave, utilizando las funciones XPath en minúscula.

Limitaciones XSLT

XSL funciona en nodos individuales. Por tanto, si hay varios elementos dc: type presentes, cada uno pasará por la función de normalización. Algunos registros tendrán valores de Tipo que se transformarán en el mismo valor.

Afortunadamente, DPLA puede eliminar la duplicación de campos específicos y se le ha pedido que lo haga para los metadatos de tipo de IDHH.

Las coincidencias de palabras clave que utilizan contiene () descritas anteriormente requerirán una atención cuidadosa y continua a los metadatos de tipo de los contribuyentes para asegurar que los valores se transformen correctamente. Las pruebas periódicas, la última de las cuales en el momento de redactar este documento fue en 2019-05, muestran que la transformación ha funcionado bien durante casi medio año. Sin embargo, eventualmente puede haber valores de Tipo recién agregados que contengan una determinada palabra clave que se convertirá en valores de Tipo incorrectos.

Limpieza por instituciones individuales

Muchos problemas se reducen a valores inusuales que aparecen en el campo Tipo de metadatos que no pueden ser manejados por transformaciones XSL y deben ser reparados por contribuyentes. Los ejemplos incluyen frases que parecen ser más adecuadas para un campo de descripción de elemento ( dc: description ) o asunto ( dc: subject ), URL que parecen ser identificadores de registros duplicados, metadatos de derechos y errores ortográficos extraños de valores de tipo común. Simplemente no es práctico transformar estos valores a menudo únicos que, sin embargo, impregnan varias colecciones y afectan gravemente a sus metadatos de tipo y su capacidad de descubrimiento. Además, trabajar con el personal de las instituciones les permite mejorar los metadatos a nivel local y la usabilidad de sus entornos de recopilación digital.

Desde las primeras comunicaciones en adelante, el IDHH comprometió respetuosamente a los contribuyentes, brindándoles aliento e instrucción sobre cómo remediar el tipo y otros campos de metadatos. Este mensaje incluía el propósito y la importancia de los metadatos de tipo en el DPLA, una descripción general del vocabulario controlado seleccionado del DPLA, el tipo de DCMI, así como los pasos que el IDHH está tomando para aliviar al menos parte de la carga de los contribuyentes en el cumplimiento de los estándares. del tipo DCMI.

El IDHH tomó medidas para ayudar a las instituciones contribuyentes a comprender el problema y las mejores prácticas para los metadatos de tipo. Una guía de metadatos de tipos en línea para contribuyentes se creó y se vinculó en varios otros sitios web, incluido el IDHH LibGuide. Se llevaron a cabo horas de oficina regulares para ofrecer a los colaboradores la oportunidad de discutir la corrección de metadatos para Tipo u otros campos.

Implementación de XSLT y guía de metadatos de tipos

Prueba e implementación de XSLT

El XSLT se desarrolló en forma de prueba y listo en pequeños conjuntos de datos XML en Oxygen Editor 18.0. El 2019-01-24, inmediatamente antes de la primera ingesta de DPLA de 2019 para Illinois, XSLT se ejecutó por primera vez en el servidor IDHH REPOX 2.3.7. El coordinador de recolección y el especialista en servicios de metadatos probaron las características clave de las transformaciones en varios conjuntos de datos grandes, que incluyen:

El mapeo básico de un valor de metadatos proporcionado a un tipo de DCMI Los efectos de la transformación en valores pluralizados, ortografías alternativas, espacios en blanco, etc. El manejo de XSLT de valores delimitados en delimitadores de coma y punto y coma

Las pruebas también confirmaron la duplicación de valores pronosticados en el desarrollo del XSLT. Sin embargo, no se produjeron transformaciones inesperadas y el XSLT se implementó para las transformaciones en todos los registros proporcionados a DPLA el 28 de enero de 2019.