Differences between revisions 62 and 63
Revision 62 as of 2008-10-02 14:20:42
Size: 6236
Editor: abr
Comment:
Revision 63 as of 2008-10-02 14:25:58
Size: 4874
Editor: abr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
 * [:DataModel/ContentModel_Image: doms:ContentModel_Image]
 * [:DataModel/ContentModel_Video: doms:ContentModel_Video]
 * [:DataModel/ContentModel_Text: doms:ContentModel_Text]
 * [:DataModel/ContentModel_Image: doms:ContentModel_Image] DONE
 * [:DataModel/ContentModel_Video: doms:ContentModel_Video] DONE
 * [:DataModel/ContentModel_Text: doms:ContentModel_Text] DONE
Line 93: Line 93:



=== ContentModel_Image ===
Extends ContentModel_DOMS

The following variables are used:
 * $ImageFile: An object with the Content Model !ContentModel_!ImagePreservationFile

Requirements for objects described by !ContentModel_Image
 * Datastreams
  * RELS-EXT
   * doms:hasPreservationFile -> $ImageFile


=== ContentModel_Video ===
Extends ContentModel_DOMS

The following variables are used:
 * $VideoFile: An object with the Content Model !ContentModel_VideoPreservationFile;


Requirements for objects described by !ContentModel_Video
 * Datastreams
  * RELS-EXT:
   * doms:hasPreservationFile -> $VideoFile


=== ContentModel_Text ===
Extends ContentModel_DOMS

The following variables are used:
 * $TextFile: An object with the Content Model !ContentModel_TextPreservationFile;

Requirements for objects described by !ContentModel_Text
 * Datastreams
  * RELS-EXT:
   * doms:hasPreservationFile -> $TextFile



== Technical Metadata ==
A file object should contain technical metadata. In this context it refers
 * A datastream with the output of the characterisation tools used on this file upon ingest, called CHARACTERISATION
 * A datastream with the metadata about the origins of the file, called Origin

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

Doms Data Model

In the following these shorthands will refer to the following namespaces

A definition: A datamodel describes the content of a collection. A content model describes the content of a data object. So, a data model is a set of content models, that together describe the collection.

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

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.

DOMS Content Models in general

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

  • Data objects
  • Content Model objects

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. For more detail on this, see FedoraOntology and FedoraTypeChecking

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.

The special Content Model object "doms:ContentModel_DOMS" is the root object. All Content Models must have an "doms-relations: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 "fedora-model:hasModel" and all Content Models that can be reached from this, by following "doms-relations: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.

Content Models have two datastreams in particular that are interesting. These are the ONTOLOGY and DS-COMPOSITE. The Ontology defines the the allowed relations in subscribing objects, and the DS-COMPOSITE defines the required datastreams and any restrictions they must adhere to.

DOMS Base Collection

Doms come shipped with a base collection of objects, representing the base types. The objects in the base collection will be detailed in the following.

ContentModel_ImagePreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_ImagePreservationFile

  • Datastreams
    • PRONOMID: must be "fmt/10" (tiff version 6)

ContentModel_TextPreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_TextPreservationFile

  • Datastreams
    • PRONOMID: must be "x-fmt/16" (Utf8) or "fmt/95" (pdf-a)

ContentModel_VideoPreservationFile

Extends ContentModel_File

Requirements for objects described by ContentModel_VideoPreservationFile

  • Datastreams
    • PRONOMID: must be "x-fmt/385" (mpeg1) or "x-fmt/386" (mpeg2)

DataModel (last edited 2010-03-17 13:13:00 by localhost)