Changes between Version 14 and Version 15 of CMDI 1.2/Resource proxies/ResourceRelation

Timestamp:

02/04/14 09:50:58 (10 years ago)

Author:

oddrun.ohren@nb.no

Comment:

--

CMDI 1.2/Resource proxies/ResourceRelation

@@ -249 +249 @@
 
  Resources that are defined in bundles are listed under !ResourceProxy. The individual parts can be seen as independent resources as well, such as a subcorpus that can also be distributed on its own. ''To point out that a resource is part of a larger unit or created as part of a larger unit'', the !IsPartOfList is introduced referring to one or more larger units by giving the PID of the larger units with the !IsPartOf element.
+
+----
+Oddrun:
+
+'''Ad relations between metadata documents:''' I will not claim there is never need of expressing relations between metadata documents. E.g. the metadata of a resource may be subdivided into several documents in a way that do not correspond to the resource composition (is such a situation compliant with CMDI at all?). In such cases, the metadata files will need to be related to each other . And it is certainly necessary to have a clear semantics as to which  object types (resource or metadata) are connected by a relation statement. 
+However, I do not think the need is great enough to  warrant muddling the waters in the non-component part of CMDI by giving the opportunity to talk about metadata files.  That is, whenever a file with ResourceType “Metadata” is listed in ResourceProxyList, it should represent the resource it describes, not the metadata as a resource in its own right. (it is of course thinkable to allow giving  metadata files the  ResourceType “Resource” to indicate that the file in question is to be regarded as a resource in itself, but this would violate the principle of ResourceProxyList only containing the parts of the described resource).
+Likewise, when a metadata file CMDI-x appears in the IsPartOLst, it must be taken to mean that the currently described resource is part of the resource described by CMDI-x. 
+Any information about (including relations between ) metadata as such (apart from the adm info in the header) can and should be handled by dedicated components, IMHO at least.
+
+'''Ad relations in the non-component part of a CMDI file:''' It sounds so incredibly plausible and simple in Thortsen’s words from the cited paper above. But the examples from Clarin-D shows that each and every center has their own way of dealing with resource relations. Apparently, quite a representational diversity can be created within the CMDI framework, totally without the help of ResourceRelation... Hence, do we really need ResourceRelation? On the other hand, one might argue that since it is rarely used, removing it doesn’t really simplify thing... It would be nice to see some real world examples of its use, though.
+ 
+However, even though Clarin-D centres express relationships in manifold ways, there is a pattern when it comes to representing the ''compositional structure of resources'', namely that the ''resource part-of hierarchy is represented by ResourceProxyList and IsPartOfList''. If practiced  universally, aggregators like VLO and others could use this to good effect in their portals. True, hasParts/IsPartOf is just one relation, but a very important one, defining the compositional structure of a resource. 
+To sum up, I think my position would be: 
+* Promote  ResourceProxyList and IsPartOfList as best practice for expressing the compositional structure of a resource
+* All other relations are to be expressed in the components
+  * Remove ResourceRelationList/ResourceRelation 
+  * Publish a new component ResourceBinaryRelation for expressing resource relations in general, along the lines of the latest suggestions for ResourceRelation above 
+
+