Guidelines for designing a new datamodel

When designing the datamodel for a new collection to be put in the DOMS, we have to choose how many different types of objects the model should consist of. This is a tradeoff between few objects containing lots of metadata each, and in the other extreme many objects with fewer metadata on each and potentially more relations between the objects. The guidelines below were written to convey the proper balance when designing a new datamodel.

• As a rule of thumb, there should be as few objects as possible. What actually does justify the inclusion of an object is explained by the principles below.
• Introducing an object is justified if
  • the object would model a concept which would be interesting to look at for the sake of the concept itself, or
  • the object would model a concept for which we would need to record non-trivial metadata, or

  • the object would model a concept which it would be useful to be able to refer to via a relation.

Cost effiency

"Avoid as mouch as possible filling in elements or structuring datain a particular way only because it appears in a standart or other implementers do it that way. Instead find out what the reason for the inclusion of that element is, or review the other implementer's procedures, and determin if those goals apply to your project." source:[http://www.citeulike.org/group/12552/article/6480816 Metadata for Digital Resources]

Patterns for datamodels

[:GuidelinesForNewDatamodel/PatternLanguage:PatternLanguage]

Workflow

When describing the collection templates, be sure to include the workflow in the description, e.g. which data is needed in order to allow the collection elements to be represented on their own.