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

Timestamp:

01/23/14 08:21:39 (10 years ago)

Author:

oddrun.ohren@nb.no

Comment:

--

CMDI 1.2/Resource proxies/Element

@@ -66 +66 @@
 
   [[twagoo|Twan]]: Here's how I understand the intended relation between profiles, (non-profile) components and elements: profiles define the description of a resource or a set of related resources; in the latter case, different components can be used to define the description of individual resources within that set by collecting a set of properties/aspects that make up this description; elements finally define these properties/aspects in terms of value scheme, cardinality etc. 
-    Oddrun: What you describe here is one way of using components to compartmentalise the description of a resource, but not necessarily the most typical one. Example: Consider a resource (corpus)  R with 2 parts Ra and Rb, where Ra is audio and Rb text (transcription of Ra). Now select the profile resourceInfo for corpora to describe this resource. resourceInfo contains several components pertaining to the decsribed resource (R) as a whole, e.g.   contactPerson and distributionInfo. These components decsribe specific aspects of R as a whole, they do not concern any one of Ra and Rb in particular.  On the other hand, resourceInfo also contains components pertaining to specific mediatypes (deeper down, in component corpusInfo). In our case we would need to instantiate  corpusTextInfo and corpusAudioInfo. Here,  each of the components does pertain to one specific part of R, in that corpusAudioInfo obviously describe Ra and corpusTextInfo describe Rb.
+    Oddrun: What you describe here is ''one'' way of using components to compartmentalise the description of a resource, but not necessarily the most typical one. '''Example''': Consider a resource (corpus)  R with 2 parts Ra and Rb, where Ra is audio and Rb text (transcription of Ra). Now select the profile ''resourceInfo'' for corpora to describe this resource. resourceInfo contains several components pertaining to the decsribed resource (R) as a whole, e.g.   ''contactPerson'' and ''distributionInfo''. These components decsribe specific aspects of R as a whole, they do not concern any one of Ra and Rb in particular.  On the other hand, resourceInfo also contains components pertaining to specific mediatypes (deeper down, in component corpusInfo). In our case we would need to instantiate  ''corpusTextInfo'' and ''corpusAudioInfo''. Here,  each of the components does pertain to one specific part of R, in that corpusAudioInfo obviously describe Ra and corpusTextInfo describe Rb.
+
 The above example illustrates two different criteria for defining components,  both equally legitimate, in my opinion.
 
@@ -76 +77 @@
 
   [[twagoo|Twan]]: That's true, a component does not define the specification of a full resource ''per se''. My point is that, I think, elements never do/can/should. If an element describes a property of a resource, there will always be component higher up in the tree that selects the resource. Even with bad modeling, I think that would be hard to avoid but maybe someone can provide a counterexample.
+    Oddrun: I think I finally see what you mean :-), namely that it doesn't make sense to allow an element to be a property of some other resource than that described by its containing component (ultimately profile). If so, I agree.  
 
 Components that are ''profiles'' on the other hand, do represent a holistic description of the resource as a whole, and I think it is preferable to  reserve the ResourceProxyList in a CMDI file for resources/files that actually constitute the ''described resource''. Other relevant resources (documentation, reviews, publications, a.o.) should be referenced from appropriate parts of the metadata instance. If such resources only can be referenced from components, one would have decide this at model time, which perhaps is no big deal? Especially if there is a risk of increased malpractice attached to allowing it for elements, too.    
@@ -81 +83 @@
   [[twagoo|Twan]]: I completely agree with your point that only described resources should be referenced from the resource proxy list! Other kinds of references would be profile specific and obviously can only be achieved by means of elements and/or attributes. Yes this has to be decided at model time, and I am not sure if that could be an issue - I guess not really. 
   In any case, the crucial point is that this is both conceptually and technically a different kind of referencing. Maybe you do a agree that ''described resources'' should be referable from the component level only while other kinds of referencing (typically through an element of type ''anyURI'') should be allowed occur in arbitrary places in component and profile specifications?
+    Oddrun: I agree. 
 
   It's good to be aware that this topic often leads to confusion; we have seen several cases where !ResourceProxies were interpreted as the preferred location to store ''any'' external reference, described resource or otherwise. We should probably think about ways to make the semantics of the resource proxy list clearer to prevent this.
+    Oddrun: Yes, I think there's an acute need of guidance/documentation of best practice.