This page is a subpage of CMDI 1.2

Resource proxy references on elements

The issue

There have been use cases where the metadata creator expressed a desire to reference resource proxies from elements rather than components. However, the schemata generated in CMDI 1.1 do not allow for this. The main argument is as follows:

Components describe resources and parts thereof; elements represent individual properties of those (sub)resources. Therefore the reference to an individual resource should always happen from the component. An individual element can never refer to entire resource.

Use cases in which such a reference seems desirable are likely to violate this assumption that a component describes a (sub)resource and elements its properties. Or have resource proxies that do not actually point to resources described by the metadata (or metadata instances part of the described collections).

On the other hand, technically it is trivial to allow references from elements and there may be (exceptional) valid use cases. If so, they should be gathered in this document so that we can decide whether this feature is actually desirable.

Proposal

As no strong use cases for the originally proposed change has emerged, it is felt that an element in a CMDI component should represent a property of the resource referred to by its containing component. Hence, no change is proposed concerning this issue.

---

Original proposal and discussion below:

Proposed solutions (Old version)

Pros

• More flexibility for the metadata creator
• Easier modelling of existing formats (e.g. IMDI InfoLinks which are referenced from description elements)

Cons

• Conceptually incorrect
• May lead to undesirable design choices
• Additional burden on tools that support visualisation of resource proxy reference

Centre impact

Tools that visualise resource proxy references (e.g. Arbil shows the referred document as a child of the referencing component) will need to deal with this new possibility.

Implementation examples

Only a change in the comp2schema XSLT is required, adding a 'ref' attribute to xs:elements derived from CMD_Elements:

<!-- Simple case: no attributes and no value scheme, 1-to-1 transform to an xs:element, just rename element and attributes -->
<xsl:template match="CMD_Element" priority="1">
    <xsl:element name="xs:element">
        <xs:attribute name="cmd:ref" type="xs:IDREF"/>
        <xsl:apply-templates
            select="@*[name() != 'Documentation' and name() != 'DisplayPriority'] | node()"/>
        <!-- process all Documentation and DisplayPriority attributes -->
        <xsl:call-template name="annotations"/>
    </xsl:element>
</xsl:template>

Notes:

• Assuming that only a single reference will be allowed and CMDI-namespace on the 'ref' attribute here (see pages for more information and discussion)
• Will also need to be implemented for complex cases of CMD_Element transformation (with attributes and/or value scheme)

Tickets

Tickets in the CMDI 1.2 milestone with the keyword elementresourceref:

Ticket	Summary	Owner	Component	Priority	Status
No tickets found

Discussion

Oddrun: I find this sentence from above misleading: "Components [did you mean profiles?] describe resources and parts thereof; elements represent individual properties of those (sub)resources. Therefore the reference to an individual resource should always happen from the component. An individual element can never refer to entire resource."

Firstly, IMHO individual elements may well refer to the entire resource. In fact, most often they do, - however, they describe an aspect of the resource as a whole. Examples: resourceName, size, licence, and countless others.

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.

The above example illustrates two different criteria for defining components, both equally legitimate, in my opinion.

So in the metadata instances that reflect this hierarchy, we need to distinguish between, on the one hand, a reference to resource as a whole, which creates a context for describing its properties, and, on the other hand, the fields (i.e. element instantiations) nested within this context that describe the resource one property at a time.

This relation between component (instantiations) and element (instantiations) is reflected by the fact that a ref can occur on the component level but not on the element level.

Secondly, given the recursive nature of components, whether modelling a piece of metadata as components or elements is often a matter of taste. Example: Information about the size of a resource may be modelled as an element (possibly with an attribute unit) or as a component with 2 elements size and sizeUnit.

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.

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.