| 288 | 288 | Oddrun: I partly agree, Oliver here touch on the key characteristics of CMDI: While it's flexibility allows us to configure our metadata according to any specific needs, it is equally the case that one and the same phenomenon may be expressed in many different ways. Which is sometimes confusing...Relationships between resources is such a case. Any metadata modeller may define components or elements with the specific purpose of handling relationships. OLAC DCMI-terms is one example, - another is the ResourceRelationInfo component included in all 4 resourceInfo profiles from METASHARE. Then, in addition, CMDI offer the integrated relationship elements in the Resources section, some "hard coded"/defined (isPartOf), others to be defined by the modeller or metadata creator. For the hard coded ones, the advantage of storing them outside components is the possibility of imposing a shared semantics, making exploitation easier. However, this does not apply to the ResourceRelation element, which increasingly - after its generalisation - looks like a regular component. Maybe it would be better to define ResourceRelation as a recommended component in CR, and exclude it from the Resources element? |
