Changes between Version 10 and Version 11 of CMDI 1.2/Resource proxies/ResourceRelation


Ignore:
Timestamp:
01/22/14 13:08:54 (10 years ago)
Author:
oddrun.ohren@nb.no
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CMDI 1.2/Resource proxies/ResourceRelation

    v10 v11  
    233233
    234234Another observation: [putting on my center agnostic hat] at least one centers defines relations between Resources by using !ResourceProxies and the ''@href'' attribute within the component section of the CMDI instance, e.g. by putting an ''@href'' on ''isPart'' or ''source'' elements (OLAC DCMI-terms profile). Relation suddenly appear within the Components section. What do you think about this approach (especially considering the metadata exploitation point-of-view)?
     235
     236Oddrun: 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?