DOMS Data model



The DOMS system will be a system that models several collections of digital objects. Each object belongs to one or more collections. This is represented by having one or more "isPartOfCollection" relations to the parent collections. This goes for a collection object as well - it belongs to another collection. One collection has special status though: the "doms:Root_collection" does not belong to any other collection, and is thus the bottom element for the "isPartOfCollection" relation. Every other collection has a "isPartOfCollection" relation to "doms:Root_collection".

In addition, DOMS contains a special collection - the "doms:DOMS_base_collection". This collection provides objects such as content models and licences that are utilized by (and mandatory for) the other collections in the DOMS. Content models and licences are discussed below. This collection is meant to be ingested as the first collection in the DOMS.

DOMS Content Models

Fedora provides a repository for digital objects. All objects in the repository can, in principle be unique, but Fedora provides of specifying an object as a given type. Unfortunately, the type-definitions in Fedora, called Content Models, are rather simplistic by default. We use them as the basis of our type system, with certain enhancements.

For our purposes, there are two kinds of digital objects in Fedora

The Content Model object, as used in DOMS, describes the compulsary and legal content of an object of this type. It contains the information nessesary to verify if the given object is indeed of this type.

A data object can specify the Content Model describing it's contents, via a hasContentModel relation. It can only have one such relation, and in DOMS we require it to be present.


A type system that does not allow for inheritance, will have limited use. In spite of this, the Fedora Content Models do not provide this functionality. We have build our own inheritance system for Content Models to compensate for this lack.

The special Content Model object "ContentModel_DOMS" is the root object. Content Models must have an "extends" relation to this object, possible through a number of other Content Models. When performing validation of a Data Object, the validator will validate the object against the Content Model specified with "hasContentModel" and all Content Models that can be reached from this, by following "extends" relations.

A Content Model can extend more than one other Content Model. The validator will only validate an object against a given Content Model once per invocation, so circular relations are not a problem.

Predefined Content Models



The following variables are used:

Requirements for objects described by ContentModel_DOMS


The following variables are used:

Requirements for objects described by ContentModel_Image


The following variables are used:

Requirements for objects described by ContentModel_Wav


The following variables are used:

Requirements for objects described by ContentModel_Wav


The following variables are used:

Requirements for objects described by ContentModel_Wav


The following variables are used:

Requirements for objects described by ContentModel_Wav


Requirements for objects described by ContentModel_Licence


Requirements for objects described by ContentModel_Collection: None

File Objects

In DOMS, we have found it beneficial to seperate the abstract concept of "Image" or "Audio" from the concrete implementations such as "jpeg" and "mp3". The metadata about the image will be relevant no matter the manifestation of the image, and as such should not reside along with the technical metadata about the manifestation. To support this separation, we have introduced the concept of File objects.

A File object is an object, that contain a link to the file (in Bitstorage), and the technical metadata about this file. Only File objects are allowed to reference a file in Bitstorage. File objects must all have a Content Model that extends ContentModel_File.

Preservation files

We have a special class of files in DOMS, the ones we are willing to promise to preserve. These are the eight formats

For each of these, we have defined a Content Model that extends ContentModel_File.

Presentation files

DOMS does not, by default, support the concept of presentation files. Files in Bitstorage, are per default, meant to preserved, and it should not be used for transitory formats. Instead presentation files are dynamically generated upon request.

All the preservation files Content Models have disseminators that convert the given preservation format into a presentation format.

Technical Metadata

A file object should contain technical metadata. In this context it refers

* login * LDAP

In addition, it must have a relation "hasOriginal" if it was migrated from another file that exist in DOMS.



Licences, in DOMS, have, as their only purpose, to restrict who can view what material. They are only a concern for people using the material in DOMS, not users working with the GUI, or otherwise administrating the contents.

Licences are implemented by using the Fedora XACML engine. When a user authenticates with the Fedora server (or with a server passing authentication tokens to the DOMS), he gets a number of attributes. Each of these attributes name one licence that the user can access material under.

Each data object in DOMS has a POLICY datastream. This datastream is just an URL, referring to a Licence object's LICENCE datastream. This datastream is an XACML stream, that evaluates if the user posses the attribute that specify that the user can use this Licence. If yes, the user is granted access to the original object, otherwise he is denied.

Audit Trail

Each user that will use the GUI will need to login. They will authenticate with some external server, probably the SB LDAP server. The access control is not really a concern for the DOMS system. As such, all GUI users will have equal and full access to the DOMS repository.

Audit trails, however, are a concern. Each change to a datastream in a data object will, per default Fedora behaivour, create a new version of this datastream, marked with the creation time and the username. For this reason the Fedora operations PurgeObject and PurgeDatastream are blocked, as they destroy the audit trail. Real deletion of information is not possible, but both objects and datastreams can be marked as "deleted", again per standard Fedora behaviour. Any tools working with or on DOMS should respect this flag. The GUI should only concern itself with the most recent version of a datastream.

DataModelTemp (last edited 2010-03-17 13:09:09 by localhost)