A presentation given at Connect 2017 described thus, it’s not fun to have an ingest fail overnight and spend the morning tracking down why. Programmatically testing and validating digital object metadata prior to ingest helps us avoid these failures. The metadata itself is managed by Git and stored in GitHub, Several years ago UCSB incorporated Git/GitHub and JIRA into our metadata management and batch ingest workflows. Since then we’ve looked at repurposing other development tools to provide lightweight and automated solutions to problems we often face. One is that we rely primarily on batch ingests when adding content to our Samvera repository. As a result it’s especially important for the metadata to be error-free, and this allows us to run automated checks against any changes using Jenkins and some custom libraries we’ve written for validating CSV and MODS metadata. In this session, we will provide an overall of our current ingest preparation workflow and the tools we are using, and will discuss some of the benefits that have come out of this collaborative effort.
Keyword:
Metadata, Connect 2017, Samvera, and Import/export
The Royal Library was very fast to adapt the emerging web technologies in the mid 1990’s. The web was used as an integrated part of digitization projects, resulting in a number of specially tailored web sites for various types of content, manuscripts, images, literary texts, journal articles, etc. Each project and type of material would typically result in its own data model, metadata format, workflow, and a database/repository that was tightly coupled with the web application. In later years, as the throughput on the digitization production lines has increased, more automated ways of dissemination have been developed. However this has not been able to fundamentally replace the tendency to building silos around different types of content. Being both national and university library, we can expect that in the future accessioned material will largely be born digital. In order to handle this situation, we have decided to start implementing an integrated digital library infrastructure, covering all aspects of digital collection building and management. The assumptions are that some metadata will be shared between all types of digital materials, and that the main steps in a digital object life-cycle will be common for all object types. In my presentation I am going to show how we are building a technical infrastructure in support of this, using building blocks such as Hydra, Fedora Commons, Solr, and Blacklight. I will also be touching on the organizational side of the project, focusing on the challenges to both IT people and collections staff in this process of change., and A presentation to the EOD Conference held at the National Library of Technology, Prague, Czech Republic, 17-18 October 2013. Abstract
Keyword:
Blacklight, Fedora, Architecture, Hydra, Metadata, and Solr
Contributors to the Samvera codebase require the consent of their institution or organization and to give this, the employer must sign a Corporate Contributor License Agreement. This is the downloadable form.
Keyword:
Contributor License Agreement, Governance, and Samvera
Samvera Partners must sign a formal one page Letter of Agreement (LoA) in support of the formal and legal Memorandum of Understanding (MoU) signed by the Steering Group in April 2012. A composite document comprising the 2012 MoU, amendments made to it in 2018 to reflect the name change from Hydra to Samvera, changes made in 2019 to reflect governance changes in the Community, a version of the MoU showing the effect of these amendments, and a blank Letter of Agreement are in this downloadable document.
Keyword:
Memorandum of Understanding, Governance, Samvera, and Letter of Agreement
A presentation given at Connect 2017 described thus and With so many Samvera metadataists managing similar objects and collections, can we get a handle on the metadata we have and what we share with the community? This session will introduce the idea behind the Documentation Project from the Samvera Metadata Interest Group and will consider what we're saying about our objects, how we're expressing it, and how best to move this work forward to provide suitable context for what we do or don't want our MAPS to look like as we document our work within Samvera.
Keyword:
Interest and Working Groups, Metadata, and Connect 2017
Fedora is the flexible, extensible, open source repository platform that commonly underlies Samvera implementations. Fedora provides a number of core services that Samvera already uses, such as CRUD operations, versioning, and fixity, and several new, potentially useful extended services have been introduced within the last year. The API Extension Framework provides a means of binding services to repository objects in order to extend the functionality of Fedora, while the Import/Export Utility makes it easier to get content into and out of Fedora in standardized formats and packages. This workshop will introduce both of these new services and discuss how they might be used in the context of Samvera. Participants will also have an opportunity to try them out via hands-on exercises in combination with a virtual machine. and A workshop given at Samvera Connect 2017 described thus
Keyword:
Fedora, Samvera, Workshop, Import/export, and Connect 2017
Subject:
Samvera Community
Creator:
Woods, Andrew
Contributor:
Birkland, Aaron, DuraSpace, and Johns Hopkins University
A lightning talk at Samvera Virtual Connect 2018 described thus and At Samvera Connect 2017, we presented a draft roadmap for the Hyrax 2.x-3.x release series. Since then, much work has been done to fulfill the promise of that roadmap, and work continues. In this talk we'll quickly review the roadmap, discuss the current status of work on Hyrax, and call for participation in future development efforts to bring Hyrax to 3.0 as soon as feasible.
Keyword:
Samvera, Roadmap, Virtual Connect 2018, Lightning talk, and Hyrax
A presentation given at the Open Repositories conference in 2010. In part, the proposal reads and While repositories provide obvious benefits in hosting and managing content, it is equally clear that there is no “one size fits all” solution to the range of digital asset management needs at a typical institution, much less across institutions. A system that supports the submission, approval and dissemination of electronic theses and dissertations, for example, has demonstrably different requirements than a digitization workflow solution, an e-science data repository, or media preservation and access system. There is a clear need in the repository community to readily develop and deploy content-, domain-, and institution-specific solutions that integrate the flexibility and richness of customized applications and workflows with the underlying power of repositories for content management, access and preservation. This paper will provide an overview of Hydra’s philosophy, architecture, and components, as well as demonstrations of various Hydra installations. The paper will also provide a progress report on Hydra development to date and its overall roadmap, as well as provide observations on the successes and challenges of community-based development of shared repository solutions.
Keyword:
Community, Open Repositories 2010, Architecture, Repository, and Hydra
Subject:
Hydra Project
Creator:
Sadler, Bess, Sigmon, Tim, Mene, Willy, Green, Richard A, Staples, Thornton, McRae, Lynn, Cramer, Tom, and Awre, Christopher L
Contributor:
University of Hull, DuraSpace, University of Virginia, and Stanford University