Differences between revisions 6 and 7

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. See FedoraTypeChecking
- [: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

[: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 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 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 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

-  ⇤ ← Revision 6 as of 2008-10-17 17:02:10 → 
  Size: 4649
  Editor: abr
  Comment:
+   ← Revision 7 as of 2008-10-17 17:02:25 → ⇥
  Size: 3488
  Editor: abr
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 41:
-=== 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. 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.