A proposal for a presentation given at the Open Repositories conference in 2015 held in Indianapolis described thus, One of the many successes of the Hydra community is the fundamental notion from which its name is derived—the concept of many interfaces (“heads”) over top of a single repository (the “body”). The recent release of Fedora 4, with its internal RDF-centric model, has spurred efforts for a community-wide model of collections and works, such that the heads can be sure that the body will behave as they expect it to. That model has been designed and vetted by the Hydra community, and its architecture and initial implementations will be presented in this paper. [Note, and the subject of this proposal has since become known as the 'Portland Common Data Model'.]
A panel presentation given at the Open Repositories conference in 2015 held in Indianapolis described thus and Partnerships for shared repositories offer the promise of repository services at a decreased cost due to shared infrastructure and staff. In practice, reduced costs for shared repositories often require tradeoffs in security or access for the shared system. Staff working in a shared system may be geographically distributed or may work for different institutions with different priorities and reporting lines. Effective use of shared services requires thoughtful communication and tools that help maintain consistency and prevent conflicts when multiple people work in the same system. In this panel, shared repository service managers for multisite Islandora installations and a Hydra partnership will discuss methods for distributing system access and communicating with staff who work at our parent organizations, partner institutions, and third-party vendors. Each panelist will discuss the methods used so that distributed staff can have the level of access necessary to use the repository’s unique functions, while also ensuring that widely distributed system access doesn’t result in data loss or system failures.
Open source software isn’t really free. This might seem obvious to some, but there are many members of open source communities that consume rather than contribute, Slides from a panel session given at the Open Repositories conference in 2015 held in Indianapolis described thus, and they use the software but are either unwilling or unable to engage with the community to write code, submit use cases, create documentation, or do any of the other things that make an open source project a success. Fortunately, things don't have to be this way. Over the past two years, the Fedora project has undertaken a great effort to revitalize not only the software but the community itself. By maintaining open, transparent communication, soliciting use cases, development, and testing from community members, and establishing a clear project governance structure, we have laid the groundwork for a successful community source project. At the same time, the Islandora and Hydra communities have pursued similar strategies to build and sustain their own communities and the broader Fedora community. This panel will feature a discussion on the recent successes of the Fedora community and future plans to continue raising the level of community engagement and project ownership.
A poster given at the 2014 Open Repositories held in Helsinki. This poster will demonstrate the breadth of usage of the Hydra open repository solution within Europe, and highlight how the institutions using it have engaged with the Hydra community to establish their own repositories and fed into ongoing development. Readers will become aware of the use of Hydra within Europe, and how this relates to the Hydra project overall.