Design principles

The original Hydra group spent many hours discussing how digital content might best be modelled for a repository.  What came out of these discussions was an answer that mapped easily onto Fedora, our chosen repository software, but which was intended to be more broadly applicable.  Whilst there are already institutions investigating what might happen if Fedora were replaced by a different repository solution, for the time being this section of the website will concentrate on implementing our principles with Fedora.  This whole area is covered in more detail on our “content modelling” page and in much more detail on the Hydra wiki – these are just the simplified headlines!

Hydra supports two forms of object in a repository

    • a compound object, where an object may contain one or more ‘items’ of content (in the special case of a single item of content we often refer to it as a ‘simple’ object rather than compound), and
    • atomistic (complex) objects where there is a parent object linked to content held in one or more child objects

Our wiki offers notional guidelines as to which approach might be used in particular situations.

So what does Hydra expect of an object in its underlying repository?

First, a so-called ‘Hydra-compliant’ object must assert what modelling pattern it follows.   Hydra provides a number of these and many Hydra partners have written variations on these and/or supplemented them with new ones.

Hydra-compliant objects must have associated rights.  Most people use the schema that Hydra developed because it integrates straightforwardly with Hydra’s rights enforcement but, again, there is no reason why it might not be done in other ways.  These rights determine who can discover and use the content.

‘Hydra-compliant’ digital objects should have accompanying metadata.  The default amongst the current implementations is to use MODS for descriptive metadata but other schemas are being implemented too.

And finally, some Hydra-compliant objects will have actual digital content for delivery.  Fedora, and therefore Hydra, can deal with any form of content from documents, images and multimedia files down to highly specialized binary formats.

There may be much more to an object, but those are the essentials.

So why care about compliance?  Well firstly, by sticking to the ‘rules’, more importantly maybe sticking to our approach, you can be assured of community support to assist your development process. We will all know in general terms what it is you are trying to achieve and may be able to offer advice based on the way we dealt with similar problems. Secondly, we hope that by conforming to standard patterns it will be possible for you to maybe adopt further developments with a minimum of pain – these may be additional Hydra heads or applications outside our framework but which assume ‘Hydra-compliant’ objects.  It goes without saying, that Hydra’s gems largely assume Hydra compliance.