Differences between revisions 2 and 19 (spanning 17 versions)

High Level Design Documentation

work in progress

Introduction

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 [http://sourceforge.net/projects/doms SourceForge].

The DOMS aims at fulfilling the following objectives.

Stores and handles digital material and metadata, with a view to long-term preservation
Supports re-use of components in new collections of material
Supports a common index with possibility for relations between objects
Is modular with possibility for additions to the system
Can be monitored and maintained by non-developers
Handles metadata for access rights, and integrates with certain authentication systems

What is not part of the objectives:

Establishing work flow systems and data-specific ingest systems

Overview of a DOMS system

Our DOMS keeps its data in two different kinds of storage:

A Fedora repository
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 an object (or a cluster of 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.

Fedora ECM (Extended Content Models)
Interface to bitstorage
Interface to search engine
OAI-PMH handling
The DOMS GUI

In addition, the following separate projects are needed:

Fedora repository (available at: <TODO: INSERT URL>)

Finally, you may need:

A bitstorage that the system will use
A search engine that the system will interface to

The figure below illustrates how the different modules make use of each other. <TODO: ENSURE THAT EVERYTHING IN THE FIGURE IS COVERED BY THE PACKAGES MENTIONED ABOVE>

attachment:DOMSOverview.png

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:

A PID (persistent identifier of the object)
Metadata as XML
Relations to other objects (optional)

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 which a DOMS always contains. The kinds of predefined objects in this base collection are:

Content model objects, each acting as a type or class for other objects
Basic collection objects, all objects belong to a collection
License objects, every content model relates to a license

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

attachment:DOMSBaseCollection.png

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.

Datamodels

<TODO: ADD MORE INFO>

Usage of a Fedora repository

<TODO: ADD MORE INFO>

Usage of the Fedora ECM

<TODO: ADD MORE INFO>

Validation

<TODO: ADD MORE INFO>

Interfacing with a bitstorage

<TODO: ADD MORE INFO>

Handling OAI-PMH requests

<TODO: ADD MORE INFO>

Interfacing to search engines

<TODO: ADD MORE INFO>

Usage of the DOMS GUI

<TODO: ADD MORE INFO>

The included testbed

<TODO: ADD MORE INFO>

-  ⇤ ← Revision 2 as of 2009-06-23 09:41:59 → 
  Size: 570
  Editor: jrg
  Comment:
+   ← Revision 19 as of 2009-08-18 15:20:53 → ⇥
  Size: 4837
  Editor: kfc
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 5:
+== Introduction ==

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 [http://sourceforge.net/projects/doms SourceForge].

The DOMS aims at fulfilling the following objectives.

 * Stores and handles digital material and metadata, with a view to long-term preservation
 * Supports re-use of components in new collections of material
 * Supports a common index with possibility for relations between objects
 * Is modular with possibility for additions to the system
 * Can be monitored and maintained by non-developers
 * Handles metadata for access rights, and integrates with certain authentication systems

What is ''not'' part of the objectives:
 * Establishing work flow systems and data-specific ingest systems
-Line 6:
+Line 24:
+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 an object (or a cluster of 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.
-Line 9:
+Line 35:
+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.
 * Fedora ECM (Extended Content Models)
 * Interface to bitstorage
 * Interface to search engine
 * OAI-PMH handling
 * The DOMS GUI

In addition, the following separate projects are needed:
 * Fedora repository (available at: {{{<TODO: INSERT URL>}}})

Finally, you may need:
 * A bitstorage that the system will use
 * A search engine that the system will interface to

The figure below illustrates how the different modules make use of each other.
{{{<TODO: ENSURE THAT EVERYTHING IN THE FIGURE IS COVERED BY THE PACKAGES MENTIONED ABOVE>}}}

attachment:DOMSOverview.png
-Line 10:
+Line 58:
+The metadata stored by the DOMS is represented as objects inside a Fedora repository. 
Each metadata object in the repository contains the following:
 * A PID (persistent identifier of the object)
 * Metadata as XML
 * Relations to other objects (optional)

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 which a DOMS always contains. The kinds of predefined objects in this ''base collection'' are:
 * ''Content model'' objects, each acting as a type or class for other objects
 * Basic ''collection'' objects, all objects belong to a collection
 * ''License'' objects, every content model relates to a license

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

attachment:DOMSBaseCollection.png

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.
-Line 13:
+Line 82:
+{{{<TODO: ADD MORE INFO>}}}
-Line 15:
+Line 85:
-== Usage of a Fedora repository (separate project) ==
+== Usage of a Fedora repository ==

{{{<TODO: ADD MORE INFO>}}}
-Line 18:
+Line 90:
-== Usage of the Fedora ECM (seperate package) ==
+== Usage of the Fedora ECM ==

{{{<TODO: ADD MORE INFO>}}}
-Line 23:
+Line 97:
-== Interfacing with a bitstorage (separate package) ==
+{{{<TODO: ADD MORE INFO>}}}
-Line 27:
+Line 100:
-== Handling OAI-PMH requests (separate package) ==
+== Interfacing with a bitstorage ==

{{{<TODO: ADD MORE INFO>}}}
-Line 30:
+Line 105:
-== Interfacing to search engines (seperate packages) ==
+== Handling OAI-PMH requests ==

{{{<TODO: ADD MORE INFO>}}}
-Line 33:
+Line 110:
-== Usage of the DOMS GUI (separate package) ==
+== Interfacing to search engines ==

{{{<TODO: ADD MORE INFO>}}}


== Usage of the DOMS GUI ==

{{{<TODO: ADD MORE INFO>}}}
-Line 37:
+Line 121:
+{{{<TODO: ADD MORE INFO>}}}