A presentation given at the Open Repositories conference in 2015 held in Indianapolis, described thus, Fedora, Hydra, Solr, and Blacklight. Called “Ichabod,” this tool has allowed us to ingest, normalize, and enrich metadata from diverse systems of record and make it consumable by our main discovery tool, which is powered by the Ex-Libris product Primo. We developed Ichabod using the Agile methodology and involving developers from three distinct NYU Libraries groups. The software will lay the groundwork for future innovation in the areas of metadata management and discovery for repository content. The relationships we established have already made it possible for a similar collaboration arrangement on two other projects, with more to come in the future., and From DSpace to Drupal, NYU has a variety of systems to ingest and display curated digital content. To make this content discoverable centrally, we developed a tool for metadata ingest, transformation, and discovery based on a popular open-source software stack
Using Hydra to manage and present cultural heritage resources raises a set of interesting challenges that are beyond the scope of the traditional institutional repository. These include more complex data models, elaborate and varied workflows, richer descriptive metadata, support for more and varied controlled vocabularies, the requirement to manage larger objects comprised of larger files and multiple derivatives, support for IIIF, and a desire for richer viewing environments in general. In this presentation we will discuss these challenges and highlight examples and implementations that have gone ‘beyond the repository’. An audio recording of the session is available for download below. and A presentation at Hydra Connect 2016 described thus
A presentation given at the Open Repositories conference in 2015 held in Indianapolis described thus and Avalon Media System requires support for complex structure and modular descriptive metadata management. Use cases and examples will examine options for Avalon in Fedora such as the RDF data model in Fedora 4, static XML datastreams, and external data stores to determine which path best fits structural and descriptive metadata needs for time-based media.
Indiana University Bloomington Libraries is involved in two new projects to digitize and store content and related metadata. Each of these projects presents unique challenges. We want to use the same technology stack for both, however, so we are choosing Fedora as a storage mechanism, with Hydra-based Sufia as a repository front end. We will discuss our decision, show advantages of this Hydra/Fedora framework, and discuss advantages of moving to Fedora 4. We will also contrast this framework with the way we might have approached these projects in the past with previous versions of Fedora and before Sufia or Hydra were options. and A presentation given at the Open Repositories conference in 2015 held in Indianapolis described thus
A presentation given at the Open Repositories conference in 2015 held in Indianapolis described thus, provide an update on progress to date, At the University of Alberta Libraries we are currently developing a Digital Asset Management System (‘Hydra North’, built on Hydra and Fedora 4) to bring all of our digital assets into one platform for discovery, access and preservation. The metadata underlying these repositories has been created according to many standards (DC, MODS, EAD, etc.) and varies in level of fullness and overall quality. We find ourselves at a ‘metadata crossroads’ as we attempt to bring this disparate metadata together. We see a solution in a move to RDF and the application of the principles of linked data. In this presentation we will discuss some of the initial questions we asked ourselves as we tried to fully grasp what the move to RDF and linked data would mean for our existing metadata, provide concrete examples of the thought processes and workflows involved in moving from existing non-RDF metadata to RDF, based on the principles of linked data, outline some of the decisions we made along the way, and why, and what the impact has been, and reflect on lessons learned and outline next steps.
At the Digital Collections and Archives (DCA) at Tufts University we have designed, built, and integrated our archival collection management system and repository’s administrative interface to facilitate ingesting archival objects into our Fedora based repository. This 24x7 session briefly explores the assumptions and functional requirements we have used to guide this development work. The DCA’s unique position as an archives that is one of the key stakeholders and users of the Tufts institutional repository has enabled us to meet this integration challenge. The session describes how the integration of our archival collection management system and our repository relies on the ability to flexibly move metadata from one system to another. and A lightning talk given at the Open Repositories conference in 2015 held in Indianapolis described thus
In the past year, the major groundwork has been laid for repository systems to support ORCID identifiers. DSpace, Hydra, and EPrints all have support for storing and managing ORCIDs. However, we are still in the early stages of ORCID adoption. Only a small fraction of repository content is annotated with ORCIDs, and most end-users have not yet realized any benefit from the features based on ORCID. This panel will bring together representatives of major repository systems to relate the current status of ORCID implementations, discuss plans for future work, and identify shared goals and challenges. The panelists will discuss how ORCID support provides practical benefits both to repository staff and end-users, with a focus on features that exist now or will exist in the next year. and Slides from a panel session given at the Open Repositories conference in 2015 held in Indianapolis described thus