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

Timestamp:

02/04/14 09:52:19 (10 years ago)

Author:

oddrun.ohren@nb.no

Comment:

--

CMDI 1.2/Resource proxies/ResourceRelation

@@ -255 +255 @@
 '''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.
@@ -261 +262 @@
  
 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