Ver el código de «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.
==== Guía de difusión de metadatos de tipo ====
La Guía de Metadatos Tipo para instituciones contribuyentes se difundió durante el primer semestre de 2019. Las Mejores Prácticas de Metadatos de IDHH se actualizaron para incluir la guía y también se han publicado en el sitio web del grupo de trabajo de metadatos de IDHH junto con una lista de valores a los que el IDHH se transforma. Tipo DCMI. Se anima a las instituciones a que se pongan en contacto con el especialista en servicios de metadatos del IDHH si desean recomendar adiciones u otros cambios al mapeo actual.
=== Medición del impacto de metadatos de tipo ===
El proyecto de metadatos IDHH Type arrojó resultados impresionantes. Antes de que comenzaran los esfuerzos de remediación, solo 176,000 de 327,000 valores (53.8%) se ajustaban al Tipo de DCMI y el campo tenía 558 valores únicos. De estos valores, solo el 20% de los más de 300.000 registros del IDHH aparecían con metadatos de tipo en el catálogo DPLA. Los nuevos exámenes de los metadatos de tipo el 2019-02-15 y el 2019-05-20 utilizando la herramienta de descarga de metadatos de Python y OpenRefine mostraron mejoras notables. El chequeo de febrero reveló que la cantidad de campos de metadatos únicos se redujo a 117. La cantidad de valores conformes con DCMI a partir del 15/02/2019 era 300,985, mientras que solo había 918 valores no conformes, lo que significa que el 99.7% de IDHH Escriba valores de metadatos conforme a DCMI.
La revisión de febrero de 2019 también mostró que todavía hay algunos valores que no se ajustan al tipo DCMI que quedan de la lista original desarrollada en 2018-11. Por lo general, se trataba de facetas con menos de 10 valores cada una y, por lo tanto, no se consideraron una prioridad en el proyecto. Además, hubo algunos valores nuevos que deben haberse deslizado debido a los cambios que las instituciones proveedoras habían realizado en sus metadatos desde que se descargaron y verificaron inicialmente en OpenRefine en 2018-11 y 2018-12 y que no habían sido contabilizados por el XSL. Solo dos de estos valores tenían más de 100 instancias.

La revisión de mayo de 2019 volvió a revelar altos porcentajes de conformidad con el tipo DCMI. De aproximadamente 308,000 valores de metadatos de tipo proporcionados originalmente, 307,000 se ajustaban al tipo de DCMI, manteniendo la conformidad del 99.7% con el tipo de DCMI visto en la revisión de febrero. Había 109 campos únicos que aparecían en el análisis. Solo hubo tres valores no conformes con recuentos superiores a 100 y la gran mayoría de estos (más del 86,5%) están siendo transformados por el sistema de ingestión de DPLA.

Ambas revisiones mostraron altos porcentajes de finalización del campo de metadatos dc: type y conformidad con el tipo DCMI. Esto puede estar permitiendo que las propias medidas de control de calidad de DPLA hagan su mejor trabajo. La mayoría de los valores no transformados por el XSL del IDHH son transformados por el sistema de Ingestión del DPLA y, por lo tanto, no son motivo de preocupación. A partir del 2019-05-20, DPLA Analytics informa tasas de finalización del campo Tipo al 92%, muy lejos de las tasas del 20% observadas en diciembre de 2018 (consulte la Figura 8). Es probable que esto sea aún mayor si no fuera por el hecho de que varios contribuyentes no proporcionan ningún tipo de metadatos.
También se debe tener en cuenta que ninguno de los problemas previstos al tokenizar múltiples valores de Tipo separados por punto y coma se manifestó en la revisión de febrero o mayo. El DPLA pudo desduplicar los valores de Tipo, lo que hizo que valiera la pena normalizar los delimitadores y convertirlos en token. Sin embargo, el IDHH continuará revisando los metadatos y las transformaciones de Tipo de vez en cuando.
=== Próximos pasos: Nuevos sistemas de análisis y recolección y comunicación continua ===
Las extensas transformaciones XSL ahora implementadas en el servidor de agregación IDHH REPOX hacen que sea imposible analizar grandes muestras de metadatos de tipo proporcionados originalmente por contribuyentes utilizando datos JSON-LD de la API DPLA. Antes de que se implementara XSL, DPLA recibía valores originales proporcionados por contribuyentes de IDHH y, por lo tanto, estos mismos valores eran accesibles en la API y mediante descarga masiva en el campo originalRecord.Type . Después de que se implementó la plantilla XSL para transformar los metadatos de tipo, el IDHH transforma los valores originales proporcionados por los contribuyentes antes de que sean recopilados por DPLA y, por lo tanto, no están disponibles a través de la API de DPLA. Por lo tanto, además de las herramientas existentes que permiten el análisis de pequeñas muestras de metadatos de los contribuyentes, será necesario desarrollar un modo de analizar grandes y, si es posible, el conjunto de datos IDHH completo de Tipo y otros valores de metadatos directamente de los contribuyentes. Discutir en profundidad nuevos métodos está más allá del alcance de este documento, pero puede implicar un cambio de plataforma de recolección de REPOX a una que proporcione un análisis de datos más poderoso, como la solución de Michigan Service Hub ahora ampliamente adoptada por otros socios de DPLA: Combine.
El tipo, como todos los metadatos en una agregación continua a gran escala, será un objetivo en movimiento: los metadatos de los proveedores actuales pueden cambiar y periódicamente se agregan nuevas colecciones con valores de metadatos de tipo potencialmente nuevos. Se seguirán evaluando minuciosamente los metadatos de las nuevas colecciones. Además, el IDHH continuará comunicándose con los proveedores que planean mejorar sus metadatos de tipo y otros campos de metadatos.

El contacto regular con la DPLA será fundamental. Además de las discusiones en curso sobre el papel de DPLA en la normalización de los datos de los proveedores, será importante discutir cualquier problema restante o nuevo relacionado con el nuevo sistema de recolección recientemente implementado de DPLA, Ingestión 3.
=== Conclusiones: un esfuerzo de equipo ===
Los desafíos de este proyecto, particularmente en la recopilación y análisis de metadatos, expusieron algunas limitaciones serias en la infraestructura del IDHH y proporcionaron ímpetu e inspiración para nuevos procedimientos y plataformas. También reveló los muchos usos de las herramientas de DPLA, especialmente su API y API abiertas en general. Además, este proyecto sacó a la luz la creciente importancia de comprender múltiples aspectos del trabajo de metadatos, incluida la recolección, el análisis y el refinamiento de metadatos, junto con la capacidad de trabajar con herramientas para cada aspecto. El proyecto utilizó varias herramientas de código abierto, incluidos OpenRefine y el editor Atom para desarrollar scripts de Python. El proyecto de análisis y refinamiento de metadatos Type fue un testimonio de los desafíos y recompensas de trabajar con metadatos agregados y requirió la cooperación de todas las partes involucradas: proveedores, el hub y el DPLA.

== Comentario documentado ==

Una gran cantidad de estructuras de metadatos permiten describir los recursos de información creados porlos humanos para ser usados por ellos mismos. Desde hace un par de décadas, la actividad de la Web Semántica se enfocó a la representación de los datos a través de la creación de perfiles que se transitanautomáticamente   en   los   sistemas   de   información,   permitiendo   la   filtración,   selección   y conexión de diferentes piezas de información. En la actualidad, las pautas para adquirir información, procesarla y diseminarla, propician que los bibliotecólogos profesionales ingresen a mercados diferentes que le exigenmayores conocimientos y especialización.

Con la pretensión de crear identificadores y localizadores que organicen y sistematicen la heterogénea información que alberga Internet han surgido varios intentos de normalizar esta información tan dispersa. El primero ha sido la TEI (Text Encoding Initiative) o texto codificado, se trata de un proyecto internacional con el objeto de establecer las normas para intercambio de documentación electrónica válida para fines investigadores en el marco de las instituciones académicas. Se trata de normas para codificar o marcar texto y posteriormente procesarlo automáticamente, además incluye una cabecera que comprende información sobre el documento electrónico o metadatos.

Existen múltiples iniciativas para describir recursos electrónicos mediante metadatos normalizando y estandarizando las estructuras y arquitecturas de las recursos de Internet, el ejemplo más significativo, conocido y utilizado dentro del campo de la biblioteconomía y la documentación es el Dublin Core, creado por las iniciativas de las asociaciones de bibliotecarios norteamericanos, y en concreto por la Online Computer Library Center (OCLC), pero existen otros muchos que van desde los más estructurados y con un nivel más rico de descripción, hasta metadatos menos estructurados y con un nivel mucho menos detallado.

== Bibliografía ==

El mundo de los metadatos aplicados a las bibliotecas | Documanía 2.0. [en línea]. [Consulta: 18 enero 2021]. Disponible en: https://documania20.wordpress.com/2013/06/05/el-mundo-de-los-metadatos-aplicados-a-las-bibliotecas/. 

Organización del conocimiento en Internet. [en línea]. [Consulta: 18 enero 2021]. Disponible en: https://www.uv.es/~fgines/sansegundo.htm. 

Metadatos y recuperación de información: estándares, problemas y aplicabilidad en bibliotecas digitales - Dialnet. [en línea]. [Consulta: 18 enero 2021]. Disponible en: https://dialnet-unirioja-es.cuarzo.unizar.es:9443/servlet/articulo?codigo=4594949.