Ver el código de «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.

===Resultados===
El propósito de este artículo es describir nuestras experiencias con la implementación de una solución de repositorio basada en microservicios. Tendríamos que idear una forma de publicarlo en Primo, pero con la descripción ya presente en ArchivesSpace, no se requería migración. 
 
Usar Alma y Primo para hacer que nuestras colecciones digitalizadas sean reconocibles presentaba desafíos. Se dedicaron importantes recursos a la configuración de prueba y error de las reglas de normalización de Primo para visualización y búsqueda. La gran cantidad de reglas y su dependencia de combinaciones precisas de valores de metadatos se ha traducido en costes elevados de mantenimiento.

Primo Collection Discovery se basa en llamadas API adicionales para construir la jerarquía de colección explorable. Esa dependencia ha demostrado ser problemática, con abundantes problemas de rendimiento, almacenamiento en caché y seguridad. Con el tiempo, muchos de estos problemas se han solucionado, pero mientras tanto ha requerido una gran cantidad de soluciones manuales, comunicación con el personal de servicios públicos y solución de problemas persistente con Ex Libris. Este flujo de trabajo es efectivo, pero requiere una buena cantidad de trabajo manual que podría automatizarse.

Hay interés en la comunidad de ArchivesSpace para buscar la integración de Alma , por lo que esta podría ser una oportunidad para colaborar con otras instituciones. Audit Control Environment, no se integra con ArchivesSpace, por lo que los eventos PREMIS relacionados no se documentan junto con otros metadatos.

Había 8 posibles soluciones, cinco eran de código abierto y tres eran soluciones vendidas. DigiTool se predisponia hacia el software de código abierto. Debido a los formatos propietarios utilizados en la base de datos, aunque pudimos sacar nuestros datos de DigiTool, no los reutilizamos ampliamente en el proceso de migración, excepto como un verificador de auditoría. Una de las razones por las que un repositorio de código abierto era inviable para nosotros era la cantidad de tiempo que nuestro personal actual de sistemas y bibliotecarios de soporte tenía disponible.

se pudo implementar BC Digitized Collections sin comprar software adicional o contratar personal nuevo, lo que claramente lo convirtió en nuestra opción más responsable financieramente.

se han incorporado a los mecanismos de soporte Primo existentes, debido al tiempo usado en el proyecto.  Nuestra bibliotecaria digital de colecciones y preservación exploró e implementó FITS en sus flujos de trabajo de caracterización de archivos para permitirnos generar y almacenar metadatos técnicos.

Nuestro bibliotecario de producción digital amplió su trabajo con la API ArchivesSpace para admitir la importación y la vinculación de nuevos campos de metadatos, tanto técnicos como descriptivos. El modelo de microservicios nos permitió seleccionar e implementar servicios que combinaran y mejoraran las capacidades técnicas actuales de nuestro personal, Dedicamos una cantidad significativa de tiempo del personal para desarrollar herramientas de migración para este proyecto. Normalmente, dichos scripts y transformaciones tendrían poco valor una vez que finalizara la migración, pero estábamos encantados de encontrar lo contrario con BC Digitized Collections. Otros fueron muy revisados y refactorizados, como el script que usamos para generar objetos digitales por lotes .

El enfoque de microservicios a nuestra arquitectura de repositorio nos ha permitido desarrollar una mayor flexibilidad y transparencia en nuestros flujos de trabajo. Estos servicios son interoperables, podemos aplicarlos más allá de nuestro repositorio para mejorar nuestro programa de biblioteca digital en su conjunto. 
 
Debido a la naturaleza de código abierto de muchos de estos programas, también podemos analizar su código para comprender mejor sus fundamentos técnicos. Esto nos permite evaluar cómo los programas pueden afectar la integridad de nuestras colecciones y la privacidad de nuestros clientes. Creemos que estas integraciones flexibles conducirán a menos silos, flujos de trabajo más eficientes y una biblioteca digital más sólida en general. Finalmente, uno de nuestros objetivos perdurables como departamento es conectarnos y contribuir a la comunidad de práctica más amplia.

Al asumir un papel activo en múltiples comunidades de código abierto, este proyecto nos ha posicionado para hacerlo. Nuestras interacciones con las personas e instituciones involucradas en ArchivesSpace y IIIF han sido profundamente gratificantes, y esperamos trabajar más con estas comunidades.

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

==Comentario documentado==
Teniendo en cuenta que el servidor que tenían anteriormente (Digitool), es demasiado completo, es muy difícil, volver a encontrar uno con las mismas características que este, debido a que este es la solución ideal para la gestión y exploración de documentos digitales. Para cubrir sus necesidades, no se si al 100% encontramos otras alternativas, y algunas ya probadas por ellos.

Alma, es un complemento el cual proporciona integraciones entre el sistema y la gestión de la colección, pero basado en Ex Libris el cual es el que suspendió el soporte, por lo que esta no nos sirve de mucho. 
Analizando softwares para bibliotecas digitales y sin poder probarlos, hay varios los cuales pueden sustituir a este, AtoM, permite crear cuadros de clasificación, realizar descripciones en diferentes niveles, así como crear registros de autoridad, gestionar ingresos y crear paginas estadísticas entre otras cosas. Permite crear taxonomías, y lo que hace a este software realmente interesante es que es mutirespositorio y multi-idioma. 

CollectionSpace, sería otra solución, permite la gestión de todo tipo de colecciones, esta genera a partir de código abierto. Además, permite la gestión de procesos propios como la gestión de préstamo de las piezas. 

Otro programa apropiado para lo que buscan en este proyecto es VuFind, el software funciona con una capacidad adicional para el sistema integrado de gestión de bibliotecas que sustituye al OPAC, teniendo más y mejores funcionalidades. 

Para el desarrollo de repositorios de documentos digitales encontramos otras alternativas a las anteriores como pueden ser: 

* '''CDSware:''' Actúa como plataforma para colecciones de documentos, bibliotecas digitales, pre-prints, etc. Como estándar de descripción de contenidos utiliza MARC21. Sigue el modelo LAMP, y necesita Python. La documentación de referencia incluye todos los módulos necesarios para disponer una instalación de CDSware completa. La integración de documentos ofimáticos se lleva a cabo usando parsers de terceros. Además puede exportar la información a formatos HTML, XML, MARC, e incorpora OAI.Como estándar de metadatos usa Dublin Core, y puede aplicar RDF para determinar las relaciones entre los diferentes contenidos. También cumple el estándar OAI.

* '''Fedora:'''aplicación para desarrollo de repositorios de documentos, creada por Cornell University y la biblioteca de la University of Virginia. ha sido desarrollado en Java, por lo que se necesita el JSDK de Sun. Trabaja con objetos digitales, los cuales tienen un ciclo de vida y unas relaciones entre ellos durante un periodo de tiempo. Estándar de metadatos usa Dublin Core, y puede aplicar RDF para determinar las relaciones entre los diferentes contenidos. También cumple el estándar OAI. 

* '''DSpace:''' repositorio de información digital, pensado para almacenar, indizar el contenido y difundir los trabajos de investigación de una organización. DSpace incorpora Dublin Core y el protocolo OAI. Está escrito en Java, y necesita el JSDK de Sun, Apache Ant, Postgres u Oracle y Jakarta Tomcat. Permite crear grupos de usuarios, definir niveles de seguridad, crear flujos de trabajo etc. DSpace incorpora también la posibilidad de empaquetar sus contenidos en formato METS.

* '''E-prints:''' crear un repositorio de documentos de libe acceso, y sirve para dar soporte a repositorios, archivos de e-prints y a revistas digitales. Ha sido desarrollado en el marco del projecto Open Access, por la School of Electronics and Computer Science, University of Southampton. Necesita un servidor LAMP, e incorpora un motor de búsqueda propio. 

Greenstone es la herramienta de software libre que es una herramienta para bibliotecas digitales. Greenstone es un conjunto de programas que sirve para crear y distribuir colecciones de bibliotecas digiitales en Internet o en CD-ROM. Esta es creada, desarrollada y mantenida por New Zealand Digital Library Project en la universidad de Waikato en cooperación con Unesco y la ONG Human info de Bélgica. 

Como bien hemos nombrado anteriormente su software es libre, multilingüe, y con publicación en términos de licencia de GNU GPL. Esta aplicación esta formada por diferentes macros, programados en Perl, encargados del tratamiento y recuperación de la información textual y por un conjunto de plugins que actúan como filtros de importación para diferentes formatos de documentos digitales.
Greenstone es capaz de procesar e incorporar a las colecciones documentos en numerosos formatos, también incluimos en esto los formatos ofimáticos mas comunes. Greenstone ofrece la posibilidad de exportar colecciones a soporte CD. Greenstone también lleva incorporado un servidor OAI. 

Toda esta información extraída de un texto de Jesús Tramullas (2006), por lo que en la actualidad estas herramientas estarán disponibles y con versiones mejoradas. 

Si en este proyecto hubieran incluido herramientas como Fedora, DSpace, E-prints o CDSware, seguramente podrían haber seleccionado una mejor solución a sus problemas que ahora se le plantean, quizás solo les interesaba analizar las oras herramientas y sacar esas conclusiones, creo que este proyecto se podría haber investigado más y esperar a sacar los resultados introduciendo estas otras herramientas, quizás eso no les interesaba, pero eso nunca lo podremos llegar a saber.

==Referencias bibliográficas==

Alcazar, R. (2015). ''Software libre para bibliotecas, archivos y museos 2015''. Retrieved November 30, 2019, from http://www.rubenalcaraz.es/pinakes/software-libre/software-libre-para-bibliotecas-archivos-y-museos-2015/

Caplan, P. (2009). ''UNDERSTANDING PREMIS''. Library of Congress Network Development and MARC Standards Office. 

GitHub. (n.d.). ''Alma_integrations: API calls to push metadata from ArchivesSpace to the Alma API''. Retrieved November 30, 2019, from https://github.com/duspeccoll/alma_integrations

RedHat. (n.d.). ''¿Qué es una API?'' Retrieved November 30, 2019, from https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces

Softwareseleccion. (n.d.). ''DigiTool'' - Software selección. Retrieved November 30, 2019, from https://www.softwareseleccion.com/digitool-p-1068

Tramullas, J. (2006). ''Software libre para gestión de recursos de información digital''. Zaragoza. Retrieved December, 28, 2019, from http://eprints.rclis.org/7560/1/tramu2006.pdf