Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2008-10-17 16:47:12 →
Size: 6951
Editor: abr
Comment:
← Revision 5 as of 2008-10-17 16:52:43 → ⇥
Size: 4645
Editor: abr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== 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.
Line 25: Line 6:

Line 30: Line 9:
Line 33: Line 11:
=== Objects nessesary for DOMS === === Objects relevant to the internal working of DOMS ===
Line 45: Line 23:
=== Objects adding extra meaning to data objects ===
Line 47: Line 24:
 Objects describing a single audio file should use these content models
  * [:DataModel/ContentModel_Audio: doms:ContentModel_Audio] - For the object containing the descriptive metadata about the audio
  * [:DataModel/ContentModel_AudioPreservationFile: doms:ContentModel_AudioPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file		 === Objects for adding extra meaning to data objects ===
Line 51: Line 26:
 Objects describing a single image file should use these content models
  * [:DataModel/ContentModel_Image: doms:ContentModel_Image] - For the object containing the descriptive metadata about the image
  * [:DataModel/ContentModel_ImagePreservationFile: doms:ContentModel_ImagePreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file		 Objects describing a single audio file should use these content models
 * [:DataModel/ContentModel_Audio: doms:ContentModel_Audio] - For the object containing the descriptive metadata about the audio
 * [:DataModel/ContentModel_AudioPreservationFile: doms:ContentModel_AudioPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file
Line 55: Line 30:
 Objects describing a single video file should use these content models
  * [:DataModel/ContentModel_Video: doms:ContentModel_Video] - For the object containing the descriptive metadata about the video
  * [:DataModel/ContentModel_VideoPreservationFile: doms:ContentModel_VideoPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file		 Objects describing a single image file should use these content models
 * [:DataModel/ContentModel_Image: doms:ContentModel_Image] - For the object containing the descriptive metadata about the image
 * [:DataModel/ContentModel_ImagePreservationFile: doms:ContentModel_ImagePreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file
Line 59: Line 34:
 Objects describing a single text file should use these content models
  * [:DataModel/ContentModel_Text: doms:ContentModel_Text] - For the object containing the descriptive metadata about the text
  * [:DataModel/ContentModel_TextPreservationFile: doms:ContentModel_TextPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file		 Objects describing a single video file should use these content models
 * [:DataModel/ContentModel_Video: doms:ContentModel_Video] - For the object containing the descriptive metadata about the video
 * [:DataModel/ContentModel_VideoPreservationFile: doms:ContentModel_VideoPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file
Line 63: Line 38:
Objects describing a single text file should use these content models
 * [:DataModel/ContentModel_Text: doms:ContentModel_Text] - For the object containing the descriptive metadata about the text
 * [:DataModel/ContentModel_TextPreservationFile: doms:ContentModel_TextPreservationFile] - For the object linking the Bitstorage file, and containing the technical metadata about the file
Line 68: Line 45:
Doms contains a number of content models. These are meant to serve as the basic buildingblocks for data models for new collections. A datamodel is, of course, not restricted to use only these content models, it can, and should, define it's own. All new content models, should extend doms:!ContentModel_DOMS, and all objects that need to reference files outside Fedora should have a content model that derive from doms:!ContentModel_File, but aside from that, the system just consist of best practices. Doms contains a number of content models. These are meant to serve as the basic buildingblocks for data models for new collections. A datamodel is, of course, not restricted to use only these content models, it can, and should, define it's own. All new content models, should extend doms:!ContentModel_DOMS, and all objects that need to reference files outside Fedora should have a content model that derive from doms:!ContentModel_File and so on, as described above. The content models that provide extra meaning are optional to use, and should at least be extended for the relevant collection.
Line 70: Line 47:
Most data models are structured around some realworld concept, like a CD, modelled as a digital object. This object will be described by a content model that is totally collection specific, only extending doms:!ContentModel_DOMS. It will probably have relations to digital objects, like tracks. These will be described by a content model that extends one of the four major content types (Image, Audio, Video or Text) from the base collection. Each of these will tracks must then reference a audio preservation file object, or some subtype of this. This is the best practice for constructing data models.

For other collections, other data models might be more pratical. The content models for the four types add no special meaning to objects, other than what is agreed by convention. !ContentModel_DOMS specify the r


 There are special meaning attached to the ones from the Base Collection, though, so 		Most data models are structured around some realworld concept, like a CD, modelled as a digital object. This object will be described by a content model that is totally collection specific, only extending doms:!ContentModel_DOMS. It will probably have relations to digital objects, like tracks. These will be described by a content model that extends doms:!ContentModel_Audio. Each of these will tracks must then reference a audio preservation file object, or some subtype of this. This is the best practice for constructing data models.

Doms Predefined Objects

Doms come with some predefined objects. Most of these carry heavy semantic meaning in regards to the overall DataModel.

DOMS Base Collection

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

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.

Objects relevant to the internal working of DOMS

  • [:DataModel/ContentModel_DOMS: doms:ContentModel_DOMS] - The requirements for all objects in Doms

  • [:DataModel/ContentModel_File: doms:ContentModel_File] - The requirements for all objects that should reference files in Bitstorage. See DomsFileHandling

  • [:DataModel/ContentModel_License: doms:ContentModel_License] - The content model for objects containing the technical requirements of rights and licenses are described here. See FedoraLicensePolicies

    • [:DataModel/Open_License: doms:Open_License] - The license imposing no access restrictions

  • [:DataModel/ContentModel_Schema: doms:ContentModel_Schema] - The content model for objects objects describing the contents of datastreams in data objects

    • [:DataModel/View_Schema: doms:Schema_View] - The schema for the VIEW datastream
    • [:DataModel/Schema_OAIDublinCore: doms:Schema_OAIDublinCore] - The schema for the DC datastream

  • [:DataModel/ContentModel_Collection: doms:ContentModel_Collection] - The content model for objects representing the overall structure of the repository.

    • [:DataModel/Root_Collection: doms:Root_Collection] - The overall collection, representing the entire repository
    • [:DataModel/DOMS_Base_Collection: doms:DOMS_Base_Collection] - The collection of the base objects

Objects for adding extra meaning to data objects

Objects describing a single audio file should use these content models

Objects describing a single image file should use these content models

Objects describing a single video file should use these content models

Objects describing a single text file should use these content models

Working with the Data model

Doms contains a number of content models. These are meant to serve as the basic buildingblocks for data models for new collections. A datamodel is, of course, not restricted to use only these content models, it can, and should, define it's own. All new content models, should extend doms:ContentModel_DOMS, and all objects that need to reference files outside Fedora should have a content model that derive from doms:ContentModel_File and so on, as described above. The content models that provide extra meaning are optional to use, and should at least be extended for the relevant collection.

Most data models are structured around some realworld concept, like a CD, modelled as a digital object. This object will be described by a content model that is totally collection specific, only extending doms:ContentModel_DOMS. It will probably have relations to digital objects, like tracks. These will be described by a content model that extends doms:ContentModel_Audio. Each of these will tracks must then reference a audio preservation file object, or some subtype of this. This is the best practice for constructing data models.

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