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

Timestamp:

01/23/14 10:16:20 (10 years ago)

Author:

fankhauser@ids-mannheim.de

Comment:

--

CMDI 1.2/Resource proxies/ResourceRelation

@@ -234 +234 @@
 Another 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)?
 
-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? 
+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?
+
+Peter: https://trac.clarin.eu/wiki/%20VLO%20Taskforce contains a summary of how some CLARIN-D centers currently represent relationships. None of the examples
+collected so far uses the element ResourceRelationships. Instead, the generic (binary) relationships expressed by ResourceProxy, are often further described
+in the component part of a CMDI record.