This is the home of the technical descriptions of the modules making up the DOMS

The descriptions currently covers.

For which there is a full and complete description on those sites not marked.

Sites marked "~" are incomplete and those marked "*" are complete but not yet approved by the module owner.


A DOMS is a Digital Object Management System. This document describes the open source DOMS developed at the State and University Library in Aarhus, Denmark.
Program sources for our DOMS are accessible at

The DOMS aims at fulfilling the following objectives.

What is ''not'' part of the objectives:

A brief technical overview of the individual parts of can be found as children to this document.

Overview of a DOMS system

Our DOMS keeps its data in two different kinds of storage:
1. A Fedora repository
1. A bitstorage

The Fedora repository keeps metadata, and the bitstorage keeps the actual digital material files.

If, for example, we were to store audio CDs in a DOMS, the actual digitized tracks, along with scanned cover art, could be stored as files in the bitstorage. The Fedora then would keep a metadata object (or a cluster of metadata objects) representing the CD, and containing information about for example artist(s), production year and record label, as well as information relating this CD to the digitized material in the bitstorage.

System structure

Our system is available as several different packages, each containing part of the DOMS, and each part interacting with the others.

The packages that form the DOMS are the following:

1. The DOMS server interface
1. DOMS Front end Services:

In addition, the following separate projects are needed:

Finally, you may need:

Insert the completed DOMS_diagram when it is finished.

DOMS objects

The metadata stored by the DOMS is represented as objects inside a Fedora repository.
Each metadata object in the repository contains the following:

In addition to objects containing ''descriptive metadata'' (metadata like artist in the CD example above), there are objects that we call ''file objects''. All relations to data in a bitstorage come from file objects, and these objects instead of descriptive metadata contain ''technical metadata'' about the files they point to (things like sample rate, for sound files).

In addition to the objects that contain metadata, i.e. which represent the content of the DOMS, there are a number of special objects in a DOMS. These special objects are:

A DOMS comes preloaded with some special objects, defined in the ''base collection''. These base objects are meant as a base for defining your own data models (see below) for specific collections.

The figure below shows the objects in the base collection, and their relations.


Content models are related in a hierarchy with ContentModel_DOMS at the top. Similarly, collections are related by the ''isPartOfCollection'' relation, and at the top of this hierarchy is Root_Collection.

The file objects mentioned earlier have the content models (via relation ''hasModel'') that extend ContentModel_File. That is, each has a content model for either image, text, audio, or video. Finally, ContentModel_License is the content model of all licenses, and we include Open_License, which is the license of all content models in the base collection.

Data Models

For each collection that is to be stored in DOMS, a ''data model'' must be defined.

A datamodel is a description of the formats of data and metadata, and how this data is organised in Fedora objects. In practice, this is done by formal descriptions of content models, defined by Enhanced Content Models. Having a formally described model allows us to validate our data, and to use data model aware software that integrates with our repository.

The DOMS data model, as described above, defines some structure that '''must''' be true for each collection. This includes relations to one or more collections, a license for each object, and the requirements for separate file objects containing technical metadata for each file we store in Fedora.

We also assume Dublin Core as one minimal metadata format for each object.

However, the model is flexible, and a data model for a specific collection ''may'' define additional metadataformats and relations that describe the formats and structure for that particular collection.

Summa Integration

The JSON-api is used. Documentation can be found here:


Format names in broadcast metadata