|
Size: 3590
Comment:
|
Size: 4649
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| == Content Models in general == | == DOMS Base Collection == |
| Line 7: | Line 7: |
| 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 == |
[[ImageLink(http://merkur/viewvc/trunk/docs/datamodel/fig/DOMSBaseCollection.png?root=doms&view=co,alt=DOMS base collection,width=256)]] |
| Line 28: | Line 11: |
| === 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 |
|
| Line 29: | Line 23: |
| * [:DataModel/ContentModel_DOMS: doms:ContentModel_DOMS] * [:DataModel/ContentModel_File: doms:ContentModel_File] * [:DataModel/ContentModel_AudioPreservationFile: doms:ContentModel_AudioPreservationFile] * [:DataModel/ContentModel_ImagePreservationFile: doms:ContentModel_ImagePreservationFile] * [:DataModel/ContentModel_VideoPreservationFile: doms:ContentModel_VideoPreservationFile] * [:DataModel/ContentModel_TextPreservationFile: doms:ContentModel_TextPreservationFile] * [:DataModel/ContentModel_Audio: doms:ContentModel_Audio] * [:DataModel/ContentModel_Image: doms:ContentModel_Image] * [:DataModel/ContentModel_Video: doms:ContentModel_Video] * [:DataModel/ContentModel_Text: doms:ContentModel_Text] * [:DataModel/ContentModel_License: doms:ContentModel_License] * [:DataModel/ContentModel_Schema: doms:ContentModel_Schema] * [:DataModel/ContentModel_Collection: doms:ContentModel_Collection] |
|
| Line 43: | Line 24: |
| * [:DataModel/Root_Collection: doms:Root_Collection] * [:DataModel/DOMS_Base_Collection: doms:DOMS_Base_Collection] * [:DataModel/Open_License: doms:Open_License] * [:DataModel/View_Schema: doms:Schema_View] * [:DataModel/Schema_OAIDublinCore: doms:Schema_OAIDublinCore] |
=== 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 === 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. |
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
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
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.