Getting started (managers)

So, as a manager overseeing repository development and/or the curation of digital collections, why use Hydra?  And what do you need to do to get started with it?

Firstly, the best evidence for why to use Hydra comes from those who are using it.  Read what other managers have said and then have a look at these case studies which reveal some of the scenarios that Hydra can be applied to: the multiple implementations of the common Hydra technical framework have highlighted both the flexibility of how the platform can be used, and how the different use cases can feed back to enrich the framework further.

Now you’ve looked at Hydra and how others use it.  What do you need to do to bridge the gap between “I’m interested” and getting the software development under way?  Below are listed those areas you will need to give attention to as you engage in its implementation.  Many have pointers to further information; other such pointers will be added to in due course.  But feel free to use this as a checklist as you proceed.

  • Be aware that working with Hydra is a development, not just an implementation.  Close links with the technical staff involved are essential.  Hydra provides a framework through which answers to the steps below can be put into practice relatively quickly for testing, allowing for iterative improvements as understanding and planning develops.
  • Be aware that you are not alone.  Hydra is a community, and has routes (mailing lists, wiki) through which questions can be asked and information provided to guide you along the way.  No question is unwelcome.  The Hydra founders have always worked on the principle of asking each other questions, and that process greatly informed what Hydra has become.
  • What will you be using Hydra for?  Generating a clear scope and understanding of this will help greatly in planning.  Hydra is informed by keeping the basis of repository solution design simple.  Start from here and build out to meet your detailed requirements.
    • What content types will you be managing in your collection(s)?
    • How will you describe the content using metadata?  What different types of metadata will be associated with content (e.g., descriptive, technical, preservation, etc.). NB All content in Hydra requires rights metadata – what permissions are required for your collection(s)?
    • What links between objects in your collections will be required?  In other words, how is the collection(s) organised?  Is it hierarchical?  Does it contain complex objects that combine multiple individual files?  Addressing such questions will provide structure to the repository and inform how it can be managed.
    • Will you deal with differing content types in the same way or in separate ways (in terms of create, read, update and delete workflows/options/screens)?  An example: will you manage journal articles differently from theses?  What are the implications and requirements for having different approaches?
    • How long is the intended repository solution being planned to last?  Bearing in mind the longevity of the solution will inform what preservation/access processes you may wish to put in place to enable a long lifespan.
    • The user interface will need designing.  Note that this is last on the list, and deliberately so as it will be layering over the structure of the repository designed through the stages mentioned above.  Hydra offers great flexibility in the UI design, meaning a careful consideration of this to aid user engagement will be of value.

Undertaking the steps above may not be straightforward all the time, but the repository solutions generated to date have all benefitted from it and show their worth.  We look forward to hearing how you get on; the more Hydra heads are developed the richer the community becomes.