|
Size: 6536
Comment:
|
Size: 2095
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| Line 7: | Line 4: |
[[ImageLink(http://merkur/viewvc/trunk/docs/datamodel/fig/DOMSBaseCollection.png?root=doms&view=co,alt=DOMS base collection,width=256)]] |
|
| Line 27: | Line 20: |
| == Predefined objects == * DomsPredefinedObjects - The predefined content models and other objects in the doms system |
|
| Line 32: | Line 27: |
| * DomsPredefinedObjects - The predefined content models and other objects in the doms system == Content Models in general == |
|
| Line 36: | Line 28: |
| 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. * [:DataModel/ContentModel_DOMS: doms:ContentModel_DOMS] DONE * [:DataModel/ContentModel_File: doms:ContentModel_File] Almost DONE * [:DataModel/ContentModel_AudioPreservationFile: doms:ContentModel_AudioPreservationFile] DONE * [:DataModel/ContentModel_ImagePreservationFile: doms:ContentModel_ImagePreservationFile] DONE * [:DataModel/ContentModel_VideoPreservationFile: doms:ContentModel_VideoPreservationFile] DONE * [:DataModel/ContentModel_TextPreservationFile: doms:ContentModel_TextPreservationFile] DONE * [:DataModel/ContentModel_Audio: doms:ContentModel_Audio] DONE * [:DataModel/ContentModel_Image: doms:ContentModel_Image] DONE * [:DataModel/ContentModel_Video: doms:ContentModel_Video] DONE * [:DataModel/ContentModel_Text: doms:ContentModel_Text] DONE * [:DataModel/ContentModel_License: doms:ContentModel_License] DONE * [:DataModel/ContentModel_Schema: doms:ContentModel_Schema] DONE * [:DataModel/ContentModel_Collection: doms:ContentModel_Collection] DONE * [:DataModel/Root_Collection: doms:Root_Collection] DONE * [:DataModel/DOMS_Base_Collection: doms:DOMS_Base_Collection] DONE * [:DataModel/Open_License: doms:Open_License] DONE * [:DataModel/View_Schema: doms:Schema_View] DONE * [:DataModel/Schema_OAIDublinCore: doms:Schema_OAIDublinCore] DONE == Working with the Data model == Working with the data model might seem rather rigid. It is not, however. DOMS, to be precise, is just a Fedora system, with some extensions and enhanced Content Models. === The DOMS Type system === TODO 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 useful guidelines. There are special meaning attached to the ones from the Base Collection, though, so |
== API documentation == * Refer to the overall [Documentation] page |
DO NOT PANIC
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.
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.
The entire DOMS datamodel is, in its entirety, a complex system. For proper understanding, the various components have been detailed in seperate documents. Firstly, it consist of a number of extension to the Fedora system. Secondly, it consist of a number of predefined objects. These objects make use of the extensions to Fedora. Thirdly, it consist of a number of policies for how certain tasks are achived. And fourthly, it consist of a number of API interfaces.
Fedora and DOMS are big on namespaces. To ease writing the documentation, a namespace document, DomsNameSpaces, have been written. All namespaces should be defined there, and all shorthand refer to the namespaces defined therein.
Fedora extensions
FedoraOntology - Detailing the Ontology lanquage
FedoraTypeChecking - Detailing the extensions to the DS-COMPOSITE stream
FedoraViewBlobs - Detailing the View system, which allows you to view many objects as one
FedoraObjectTemplates - Detailing the prototype system for content models
FedoraLicensePolicies - Detailing the License system, and how it interacts with the Search system
FedoraTransactionsReplacement - Detailing the use of the STATE datastream to allow for some transaction-like processes
Predefined objects
DomsPredefinedObjects - The predefined content models and other objects in the doms system
Doms policies
DomsFileHandling - Detailing how we expect to handle file objects in Fedora.
DomsCollections - Detailing the use of collection objects in DOMS
DomsAuditTrail - Detailing how DOMS logs changes and new versions
API documentation
- Refer to the overall [Documentation] page