Basic concepts
...
Every object should have at least one relation with the name "http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection" to a collection object with the content model "doms:ContentModel_Collection". This relation defines what collections the object is part of.
Every object should have exactly one relation with the name name "http://doms.statsbiblioteket.dk/relations/default/0/1/#hasLicense" to a license object with the content model "doms:ContentModel_License". This relation should be duplicated by each object having a POLICY datastream that refers to the LICENSE datastream of the same object by URL.
If an object has a relation "http://doms.statsbiblioteket.dk/relations/default/0/1/#isTemplateFor" to a content model, this defines that it is a template object for that content model. Template objects are prototypes, used to clone to generate new objects.
If a content model has a relation "http://ecm.sourceforge.net/relations/0/2/#extendsModel" is it means that objects subscribing to this content model also subscribe to the content model referred to. Due to limitations in Fedora, it is still necessary, however, to mention both content models in subscribing objects, and this relation must therefore be considered unsupported.
...
Collection objects are objects of content model "doms:ContentModel_Collection". They contain any data about a collection.
License objects are objects of type "doms:ContentModel_License". They must contain a datastream "LICENSE" with an XACML-description of access rights to objects referring to this license. They may also contain any other metadata about the license.
File objects are objects of type "doms:ContentModel_File". They must contain a datastream CONTENTS that refers to a binary file by URL. They must also contain a datastream CHARATERISATION that contains characterisation information for the file (the specification for this is still under development). Specialisations of this datamodel should contain specialisations of the allowed mime types for the CONTENT datastream. File objects should describe technical aspects of files, but not bibliographic metadata. This will allow migration of a file without having to update the bibliographic metadata objects.
...
- Identify files in the collection.
- Identify bibliographic objects. It may be relevant to think of elements of FRBR and object oriented modelling at this stage.
- Draw the diagram as interconnected boxes for each element.
Example:
| Gliffy | ||
|---|---|---|
|
...
|
...
|
- For each line in the diagram, define a name and a direction for the relation. Note that standards may exist for common relations.
- For each box in the diagram, define what datastreams should exist, with what XML schema
Example:
| Gliffy | ||
|---|---|---|
|
...
|
...
|
- For each object, identify the license for accessing the object
- Identify whether, and how, some blocks in the diagram should be grouped when disseminating objects.
| Gliffy | ||
|---|---|---|
|
...
|
...
|
Implementing a datamodel
Once the datamodel has been designed, the model can be implemented in DOMS. The following workflow is suggested:
...
- Set the right license in that template object in the RELS-EXT datastream and the POLICY datastream
- Set the "http://doms.statsbiblioteket.dk/relations/default/0/1/#isTemplateFor" relation in the RELS-EXT datastream.
- Set the "http://doms.statsbiblioteket.dk/relations/default/0/1/#isPartOfCollection" relation in the RELS-EXT datastream.
...