|
Size: 1794
Comment:
|
← Revision 19 as of 2010-03-17 13:08:49 ⇥
Size: 1243
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
| === Cost effiency === "Avoid as much as possible filling in elements or structuring data in a particular way ''only'' because it appears in a standard 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(patterns ed.), and determine if those goals apply to your project." source:[http://www.citeulike.org/group/12552/article/6480816 Metadata for Digital Resources] |
{{attachment:CD-Collections-diagram.png}} |
| Line 15: | Line 13: |
| [:GuidelinesForNewDatamodel/PatternLanguage:PatternLanguage] | [[GuidelinesForNewDatamodel/PatternLanguage|PatternLanguage]] |
| Line 17: | Line 15: |
| == 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. |
== Collections for datamodels == [[GuidelinesForNewDatamodel/Collections|Collections]] |
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.
Patterns for datamodels