| | 72 | Oddrun: Good idea, but I think this is very different from the ''extended display information'' discussed on another page. While the latter has to do with information targeted ''visualisation'' of metadata, we are here concerned with alternative methods by which values of metadata fields may be decided. In particular, methods involving operations on other metadata fields and on the resources themselves. In other words, we are here talking about standard metadata. In my mind, derivation rules (calculation expressions) come in the same class as specifications of data type, restrictions (e.g. closed vocab) and syntax patterns (e.g. patterns for earth coordinates, points in time, etc), which are all specified in the components. Hence the derivation rules should also be specified in the components. |
| | 73 | For this we will need a simple rule/expression language, involving operands (metadata fields (not including other derived fields?), external resources and som fixed expressions (e.g. DateOfToday)) and operators (at least arithmetic operators for numbers, concatenation and substring for texts, conversion between text and numbers, access method for external files, - possibly also a way of expressing conditions) to be performed on the operands. |
| | 74 | For this to function well, the metadata editor must be able to discover when any updated field is involved in some derivation rules, and either perform automatic syncronization of the derived fields, or alert the user accordingly. |
| | 75 | One last word: This sounds like a very nice feature which makes it possible to create richer metadata without burdening the metadata creator. However, it has the potential of making the metadata handling quite complex, so ''showing restraint'' in using it should be part of the metadata modeller's best practice. |
| | 76 | |
