Diferencia entre revisiones de «Analyzing and Normalizing Type Metadata for a Large Aggregated Digital Library»

De TallerDocumental on Wiki
Saltar a: navegación, buscar
(Introducción a IDHH y metadatos de tipos)
(Resumen detallado con cada una de sus partes)
Línea 28: Línea 28:
 
=== Descripción general de los problemas de metadatos de tipo IDHH ===
 
=== 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.
 
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.
  
 
== Comentario documentado ==
 
== Comentario documentado ==
  
 
== Bibliografía ==
 
== Bibliografía ==

Revisión del 01:15 18 dic 2020

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).

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.

Comentario documentado

Bibliografía