TableOfContents

1. Extensions for Fedora

The DOMS data model have been make use of the Fedora extension:

ImageLink(http://merkur/viewvc/trunk/docs/datamodel/fig/DOMSBaseCollection.png?root=doms&view=co,alt=DOMS base collection,width=1024)

The DOMS datamodel describes how the Type system underlying DOMS is realised in Fedora 3. The figure above will serve as a guide through the following sections.

1.1. DOMS Content Models

Fedora provides a repository for digital objects. All objects in the repository can, in principle, be unique, but Fedora provides a way of specifying that an object has 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 its contents, via a fedora-model:hasModel relation, and in DOMS we require it to be present. A data object will be said to "subcribe" to a Content Model. Content Model inheritance, as specified in FedoraOntology, will be used.

1.1.1. Inheritance

The special Content Model object "ContentModel_DOMS" is the root object. All Content Models must have an "doms:extendsModel" relation to this object, possibly through a number of other Content Models. The complete description of a data object is defined as the set of the descriptions in the Content Model specified with "hasModel" and all Content Models that can be reached from this, by following "extendsModel" relations.

A Content Model can "extend" more than one other Content Model. There is no overriding of Content Models, a subscribing object must be valid in regards to all the Content Models in the inheritance tree.

1.1.2. Schema Objects

Many of the schemas used in DOMS need to be referenced many times. To avoid duplication, we have made objects containing only schemas, suscribing to the Content Model "doms:ContentModel_Schema". The describing datastream in a schemabinding might contain the schema directly, or it might contain the URL to the datastream that does. Either way, it should be invisible to programs accessing the datastream through the API.

1.1.2.1. Inheritance rules

Views are inherited when Content Models extends each other. Keep three seperate lists, one for datastreams, one for relations and one for inverse relations. Just concatenate the entries from all parent content models to these lists, and remove duplicates. Then use these three lists to generate the list of objects in the view.

1.2. Predefined Content Models

Shorthand:

1.2.1. ContentModel_DOMS

ContentModel_DOMS is the root of the content model inheritance tree. All content models derive from this model. As all objects in DOMS must have a content model, all objects must adhere to the restrictions defined in this content model.

The following variables are used:

Requirements for objects described by ContentModel_DOMS

1.2.2. ContentModel_File

Extends ContentModel_DOMS

In DOMS, we have found it beneficial to separate 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.

The following variables are used:

Requirements for objects described by ContentModel_File

The characterisation datastream could look like this. 

<?xml version="1.0" encoding="UTF-8"?>
<char:characterisation xsi:schemaLocation="http://doms.statsbiblioteket.dk/types/characterisation/0/1/# http://developer.statsbiblioteket.dk/DOMS/types/characterisation/0/1/characterisation/characterisation-0-1.xsd"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:char="http://developer.statsbiblioteket.dk/DOMS/types/characterisation/0/1/#"
  xmlns:jhove="">
  <char:characterisationRun>
    <char:tool>JHove</char:tool>
    <char:output>
      <jhove:...>
      </jhove:...>
    </char:output>
  </char:characterisationRun>
</char:characterisation>

1.2.3. ContentModel_ImagePreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_ImagePreservationFile

1.2.4. ContentModel_TextPreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_TextPreservationFile

1.2.5. ContentModel_VideoPreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_VideoPreservationFile

1.2.6. ContentModel_AudioPreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_AudioPreservationFile

1.2.7. ContentModel_Image

Extends ContentModel_DOMS

The following variables are used:

Requirements for objects described by ContentModel_Image

1.2.8. ContentModel_Audio

Extends ContentModel_DOMS

The following variables are used:

Requirements for objects described by ContentModel_Audio

1.2.9. ContentModel_Video

Extends ContentModel_DOMS

The following variables are used:

Requirements for objects described by ContentModel_Video

1.2.10. ContentModel_Text

Extends ContentModel_DOMS

The following variables are used:

Requirements for objects described by ContentModel_Text

1.2.11. ContentModel_License

Extends ContentModel_DOMS

Requirements for objects described by ContentModel_License

1.2.12. ContentModel_Schema

Extends ContentModel_DOMS

Requirements for objects described by ContentModel_Schema

1.2.13. ContentModel_Collection

Extends ContentModel_DOMS

Requirements for objects described by ContentModel_Collection: None

1.3. Technical Metadata

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

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