The Hydra philosophy

Underpinning Hydra are two fundamental assumptions:

1. no single application can meet the full range of digital asset management needs, and
2. no single institution or provider can resource the development or maintenance of a full set of solutions for the same needs.

As implied by its very name, Hydra takes a "one body, many heads" approach to both needs. From a functional perspective, one body, many heads means that Hydra is designed to support tailored applications and workflows for different content types, contexts and user interactions (e.g., an ETD application, digitization workflow application, etc.), by building them from

• a common repository infrastructure,
• flexible, atomic data models, and
• modular services and configurable components

From a participants' perspective, many heads, one body also means...

• an open architecture built on a common core, with many contributors,
• collaborative ,working solutions that can be adapted and modified to suit local needs,
• a community of developers and adopters through which additional solutions and components will be shared, and the
• ability to integrate with institution-specific infrastructure and systems.

Altogether, this leads to rich applications, customized workflows, made up of modular components, and producing reusable objects.

As a case study in this philosophy, consider content models. The Hydra team has spent considerable effort designing a common approach to leverage Fedora content models. After a number of false starts that attempted to define a uniform, standard data model, Hydra has settled on an approach which fits the 'high reuse' philosophy. The project does not offer a single comprehensive content model for each category of object that a repository might store; rather it offers a content model for core metadata which can (and arguably should) form part of almost any object's structure and then supplements this with one or more further content models which provide for the object's particular content and/or local institutional variations in structure. Thus the overall content model is actually an aggregation of reusable components.

A number of institutions worldwide have already seen that there would be positive benefits in adopting this approach of reusable components and contributing to some of the Hydra developments taking place; in particular:

• shared content models,
• shared datastream structures, and
• shared code.

In fact, much of the approach and some of the components that Hydra is developing are relevant and useful in non-Hydra environments.