Diferencia entre revisiones de «BC Digitized Collections: Towards a Microservices-based Solution to an Intractable Repository Problem»

De TallerDocumental on Wiki
Saltar a: navegación, buscar
(Próximos pasos)
(Factibilidad)
Línea 15: Línea 15:
  
 
===Factibilidad===
 
===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.
  
 
===Resultados===
 
===Resultados===

Revisión del 11:09 26 nov 2019

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

Concepción

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.

Resultados

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

Comentario documentado

Referencias bibliográficas