BC Digitized Collections: Towards a Microservices-based Solution to an Intractable Repository Problem

Referencia del artículo

Mayo, C., Adam, J., Walker, P., & Gaudreau, L. (2019). BC Digitized Collections: Towards a Microservices-based Solution to an Intractable Repository Problem. The Code4Lib Journal, (44). Retrieved from https://journal.code4lib.org/articles/14445

Resumen original

Our Digital Repository Services department faced a crisis point in late 2017. Our vendor discontinued support for our digital repository software, and an intensive, multi-department, six-month field survey had not turned up any potential replacements that fully met our needs. We began to experiment with a model that, rather than migrating to a new monolithic system, would more closely integrate multiple systems that we had already implemented—ArchivesSpace, Alma, Primo, and MetaArchive—and introduce only one new component, namely Mirador. We determined that this was the quickest way to meet our needs, and began a full migration in spring of 2018. The primary benefit of a microservices-based solution for our collections was the potential for customization; we therefore present our experiences in building and migrating to this system not as a blueprint but as a case study with lessons learned. Our hope is that in sharing our experience, we can help institutions in similar situations determine 1) whether a microservices-based solution is a feasible approach to their problem, 2) which services could and should be integrated and how, and 3) whether the trade-offs inherent in this architectural approach are worth the flexibility it offers.

Resumen original traducido

Nuestro departamento de Servicios de repositorio digital se enfrentó a un punto de crisis a fines de 2017. Nuestro proveedor suspendió el soporte para nuestro software de repositorio digital, y una encuesta de campo intensiva, de varios departamentos y seis meses no había encontrado ningún reemplazo potencial que satisfaga completamente nuestras necesidades. Comenzamos a experimentar con un modelo que, en lugar de migrar a un nuevo sistema monolítico, integraría más estrechamente múltiples sistemas que ya habíamos implementado (ArchivesSpace, Alma, Primo y MetaArchive) e introduciría un solo componente nuevo, a saber, Mirador. Determinamos que esta era la forma más rápida de satisfacer nuestras necesidades, y comenzamos una migración completa en la primavera de 2018. El beneficio principal de una solución basada en microservicios para nuestras colecciones fue el potencial de personalización; Por lo tanto, presentamos nuestras experiencias en la construcción y migración a este sistema, no como un plan sino como un estudio de caso con lecciones aprendidas. Esperamos que, al compartir nuestra experiencia, podamos ayudar a las instituciones en situaciones similares a determinar 1) si una solución basada en microservicios es un enfoque factible para su problema, 2) qué servicios podrían y deberían integrarse y cómo, y 3) si Las compensaciones inherentes a este enfoque arquitectónico valen la flexibilidad que ofrece.

Resumen detallado

Introducción

En el verano de 2017, el departamento de servicios de repositorio digital de las bibliotecas de Boston College inició un proyecto para reemplazar nuestra plataforma de repositorio de colecciones especiales digitales. Habíamos configurado una plataforma de descubrimiento provisional basada en Blacklight en 2015, pero esta interfaz se basó en el visor de imágenes y el backend DigiTool, y sabíamos que todos estos componentes eventualmente necesitarían ser reemplazados. Una de las fortalezas de DigiTool fue su capacidad para interpretar y renderizar sofisticadas estructuras de METS. Nuestra implementación hizo un amplio uso de la estructura de datos de structMap para ordenar y mostrar la relación entre múltiples archivos constituyentes en un solo objeto digital.

Usamos METS para representar el orden dentro de los artículos y archivos, y en algunos casos las diferencias entre el orden físico e intelectual de los materiales. Nos comprometimos a mantener este robusto nivel de descripción estructural, Con nuestras implementaciones METS personalizadas en mente, iniciamos un análisis ambiental para determinar si había candidatos de repositorio viables que pudieran satisfacer nuestras necesidades. Después de identificar nuestros requisitos funcionales, comenzamos una odisea de seis meses para investigar y probar ocho opciones en consulta con un grupo diverso de partes interesadas de Archives, Systems y Digital Scholarship. Algunas eran nuevas soluciones de código abierto que aún no incluían la funcionalidad que requeríamos, mientras que otras eran sistemas patentados que carecían de suficiente transparencia y personalización. Otros fueron soluciones de código abierto más maduras que plantearon preocupaciones sobre el soporte a largo plazo. Nuestro proceso de evaluación finalmente no pudo identificar una solución monolítica.

Concepción

En un intento final de satisfacer nuestras necesidades con el software existente, enviamos un correo electrónico al servidor de listas de la comunidad de Samvera, solicitando respuestas de las instituciones que utilizan METS en un contexto de Samvera. Recibimos una respuesta de un desarrollador que nos informó que METS era parte del flujo de trabajo de su institución, que se usaba principalmente para generar manifiestos IIIF, y que estos manifiestos, se usaban para representar objetos digitales estructurados. De hecho, DigiTool se creó con Struts, esta estaba en una versión desactualizada.

Con el informe de ITS, comenzó a parecer una solución más viable, así descubrimos que los sistemas que ya teníamos instalados podían cubrir una cantidad sorprendente de terreno. Con esta característica, podríamos crear colecciones en Alma y publicarlas en Primo junto con otros registros. Alma también incluye un proveedor de OAI-PMH, que podríamos aprovechar para servir contenido a entidades externas como Digital Commonwealth. Se transfirieron copias de estas colecciones desde este servidor a nuestra solución de preservación digital distribuida basada en LOCKSS, MetaArchive. Incluso si nuestra nueva solución careciera de la funcionalidad de preservación, podríamos compensar eso con los sistemas ya existentes. Vimos la migración de DigiTool como una oportunidad para adoptar el Marco Internacional de Interoperabilidad de Imagen Reconocimos que también necesitaríamos idear una forma de almacenar metadatos técnicos en un sistema de gestión de archivos.

Factibilidad

Utilizamos osullivan , una implementación de Ruby de la API de presentación IIIF, para escribir una gema Ruby que convertiría nuestros archivos METS en manifiestos IIIF. Afortunadamente, nuestro grupo de Becas Digitales ya había desarrollado algo similar para un proyecto IIIF separado, que utilizamos como punto de partida. Esto demoró mucho tiempo, pero valió la pena el esfuerzo, ya que proporcionó la base para otra gema, de espacio a segundo, que genera un manifiesto IIIF a partir de un registro de objeto digital ArchivesSpace. Seleccionar el visor de imágenes correcto también requirió prueba y error.

Nuestro equipo agradeció la interfaz limpia y moderna, así como la capacidad de mostrar información estructural en el panel lateral. Para nuestro servidor de imágenes IIIF, queríamos algo que fuera relativamente fácil de instalar y mantener. Primero, necesitábamos diseñar un flujo de trabajo para importar nuestros registros DAO a Alma. Con un poco de prueba y error pudimos generar exportaciones de registros de objetos en formato MARC que capturaron metadatos descriptivos críticos y distinguieron el material de otros registros de Alma.

Trabajamos para organizar los registros de Alma en colecciones construyendo conjuntos de registros que coincidan por nombre de colección. Si bien Primo incluye un mecanismo de enlace permanente fuera de la caja, no es personalizable y los enlaces no se pueden controlar de manera predecible. También agregamos este PID como un campo PNX de búsqueda y lo agregamos a nuestro middleware de búsqueda Primo existente, primo-servicios. Nuestro servidor de manejo se configuró para apuntar a servicios primarios para realizar una búsqueda del PID dado.

Comenzamos a experimentar con EXIF, pero finalmente nos decidimos por FITS por su capacidad para caracterizar una gama más amplia de tipos de archivos. Algunos, pero no todos los datos que estábamos interesados en almacenar ya tienen campos controlados en el modelo de datos ArchivesSpace, por lo que en muchos casos nos hemos visto obligados a almacenar datos en campos de notas generales etiquetados.

Próximos pasos

Se planea probar esto con el próximo Mirador 3. También extender el servidor de imágenes IIIF a otros usos, como una aplicación web que permite al personal cambiar el tamaño y recortar imágenes. Un ejemplo particularmente destacado de esto es el nombre 'Colecciones digitalizadas BC'. Próximamente se realizará una reevaluación de cómo nombramos y describimos el sistema, con una mayor sensibilidad al nivel de familiaridad de nuestros usuarios finales con la jerga de la biblioteca y las convenciones de la arquitectura de la información.

Hay que trabajar para optimizar cómo se integran algunos de los sistemas. Esto incluye el desarrollo de la funcionalidad adicional de exportación ArchivesSpace, y quizás el uso del proveedor ArchivesSpace OAI para canalizar registros a Alma de una manera más automatizada. Aunque no se conoce exactamente seguro la capacidad de Archivematica para lograr este objetivo.

Conclusión

Decidimos compartir nuestras experiencias con la implementación de una solución basada en microservicios porque es un enfoque arquitectónico que más bibliotecas se están interesando en explorar. Al mismo tiempo, implementamos un nuevo sistema que ha obtenido comentarios positivos de las partes interesadas internas de una manera en gran medida neutral en cuanto al presupuesto. Por otro lado, esto fue posible porque una gran cantidad de los servicios que pretendíamos combinar ya estaban implementados en nuestra biblioteca, y nuestro personal tenía el interés, la capacidad y el ancho de banda para asumir nuevos desafíos técnicos. No estamos seguros Dado que la falta de madurez fue un obstáculo importante en algunas de las soluciones de repositorio que consideramos, eventualmente podemos encontrarlas madurando para satisfacer nuestras necesidades sin requerir una personalización local extensa.

Lo concebimos para que fuera lo más flexible y amigable con la migración posible, esperando eventualmente migrar uno o más componentes hacia adelante. Será interesante mirar hacia atrás en cinco años y ver si seguimos empleando la misma arquitectura, si seguimos utilizando microservicios con un conjunto diferente de servicios interconectados o si hemos migrado a un sistema de depósito más monolítico. Esperamos haber proporcionado alguna idea de los beneficios y compensaciones inherentes a este modelo basado en microservicios. Creemos firmemente que este enfoque puede ser beneficioso para las bibliotecas que ya implementan una amplia variedad de sistemas, siempre que tengan los recursos y las habilidades técnicas para respaldar una integración más estrecha entre esos sistemas.

Esperamos ver más instituciones medianas como la nuestra implementando soluciones similares y contribuyendo al ecosistema de código abierto en el futuro cercano.