Question

• reusable elements: for elements that can be re-used in various components, is there a way of storing them somewhere, so that you don’t have to repeat, for instance, the controlled vocabulary or the pattern for its values?

• elements + isoCat: I have noticed that when you enter an isoCat concept link for an element, it does not inherit any of the properties of this data category from the isoCat, correct? For instance, if it’s a closed element (e.g. “smoker”), the set of values from the isoCat are not transferred to the element in the Component Registry. Is there a way of doing this automatically?

• choice of components: is there a way of encoding choice of a component? For instance, in this profile you can choose between an X and a Y component but only one of them can and should be present in the profile?

• inclusion of components inside components: I have seen that you can include components in two ways:

(a) by adding a component and specifying all the elements that should be included in this, in which case you add a name for the component;

(b) by dragging an existing component from the table to the edit canvas; in this case, the componentId is used instead of the name and you don’t have to add the elements.

Is there a way of adding an existing component and “altering” its name? For instance, we have the same component (personInfo) for adding data for all persons, regardless of their role (e.g. contact persons, copyright holders etc.). In each component that a person can be added, we give in the XSD the name of the element and the type of the personInfo component, e.g.

<xs:element name="contactPerson" type="ms:personInfoType" maxOccurs="unbounded">

Is there a way of doing something similar in the component registry?

• ordering of elements and components: I’ve seen that you can move up and down elements between them but I couldn’t move a component in between elements. Is there a way of doing this?

Answer

• reusable elements: for elements that can be re-used in various

components, is there a way of storing them somewhere, so that you don’t have to repeat, for instance, the controlled vocabulary or the pattern for its values?

CMDI itself has not been designed with re-use of elements in mind, but it's an interesting suggestion to provide some kind of 'snippets' functionality to the Component Editor. I suppose we could consider this. As far as Controlled Vocabularies are concerned, the common practice now is to wrap these into Components for ease or re-use and maintainability (i.e. if you want to add or change a value (prior to publication) it gets applied to all instances).

• elements + isoCat: I have noticed that when you enter an isoCat

concept link for an element, it does not inherit any of the properties of this data category from the isoCat, correct? For instance, if it’s a closed element (e.g. “smoker”), the set of values from the isoCat are not transferred to the element in the Component Registry. Is there a way of doing this automatically?

This as a feature would make a lot of sense, and in fact already is on our roadmap, so you can expect it in a future version of the Component Registry (but too be honest probably not within the next couple of months).

• choice of components: is there a way of encoding choice of a

component? For instance, in this profile you can choose between an X and a Y component but only one of them can and should be present in the profile?

No, there is no support for choice in CMDI. However I don't see any reason for CMDI not too support this in a future version, except maybe for the added complexity (which would not be too bad I guess), so this would be something for the community to discuss - the scope is a bit broader than just the Component Registry though, since the whole metadata generating part of the infrastructure would need to support it.

• inclusion of components inside components: I have seen that you can

include components in two ways:

(a) by adding a component and specifying all the elements that should be included in this, in which case you add a name for the component;

(b) by dragging an existing component from the table to the edit canvas; in this case, the componentId is used instead of the name and you don’t have to add the elements.

Is there a way of adding an existing component and “altering” its name? For instance, we have the same component (personInfo) for adding data for all persons, regardless of their role (e.g. contact persons, copyright holders etc.). In each component that a person can be added, we give in the XSD the name of the element and the type of the personInfo component, e.g.

<xs:elementname="contactPerson"type="ms:personInfoType"maxOccurs="unbounded">

Is there a way of doing something similar in the component registry?

So this would make components a bit more like 'types', and not chunks that get re-used as a whole. Unfortunately the way components are referenced in profiles and other components in the specification language (from which profile schemas gets generated) makes this a bit hard to do at the moment. Again this is something we may want to consider for a future version of CMDI and therefore something that needs to be discussed.

• ordering of elements and components: I’ve seen that you can move up

and down elements between them but I couldn’t move a component in between elements. Is there a way of doing this?

The CMDI specification (by means of the general component schema[1]) requires all elements within a component to appear *before* any contained components, so again in the current version of CMDI there is no way to do this. I'm not aware of the exact rationale behind this, but maybe someone can comment on this. If there is no good reason to keep the components and elements separated, again that is something that may be changed in a future version.

So unfortunately there are no real solutions (yet) for any of these points, but we are working on some of them and others can be discussed. I hope this answers your questions though; if not feel free to post any additional questions to the ​cmdi@clarin.eu e-mail address or to the CMDI forum[2] mentioned by Dieter.

Kind regards, Twan

[1] ​http://www.clarin.eu/cmd/general-component-schema.xsd [2] ​http://tla.mpi.nl/forums/data-archiving/cmdi