| | 25 | |
| | 26 | > - reusable elements: for elements that can be re-used in various |
| | 27 | > components, is there a way of storing them somewhere, so that you don’t |
| | 28 | > have to repeat, for instance, the controlled vocabulary or the pattern |
| | 29 | > for its values? |
| | 30 | |
| | 31 | CMDI itself has not been designed with re-use of elements in mind, but |
| | 32 | it's an interesting suggestion to provide some kind of 'snippets' |
| | 33 | functionality to the Component Editor. I suppose we could consider this. |
| | 34 | As far as Controlled Vocabularies are concerned, the common practice now |
| | 35 | is to wrap these into Components for ease or re-use and maintainability |
| | 36 | (i.e. if you want to add or change a value (prior to publication) it |
| | 37 | gets applied to all instances). |
| | 38 | |
| | 39 | > - elements + isoCat: I have noticed that when you enter an isoCat |
| | 40 | > concept link for an element, it does not inherit any of the properties |
| | 41 | > of this data category from the isoCat, correct? For instance, if it’s a |
| | 42 | > closed element (e.g. “smoker”), the set of values from the isoCat are |
| | 43 | > not transferred to the element in the Component Registry. Is there a way |
| | 44 | > of doing this automatically? |
| | 45 | |
| | 46 | This as a feature would make a lot of sense, and in fact already is on |
| | 47 | our roadmap, so you can expect it in a future version of the Component |
| | 48 | Registry (but too be honest probably not within the next couple of months). |
| | 49 | |
| | 50 | > - choice of components: is there a way of encoding choice of a |
| | 51 | > component? For instance, in this profile you can choose between an X |
| | 52 | > and a Y component but only one of them can and should be present in the |
| | 53 | > profile? |
| | 54 | |
| | 55 | No, there is no support for choice in CMDI. However I don't see any |
| | 56 | reason for CMDI not too support this in a future version, except maybe |
| | 57 | for the added complexity (which would not be too bad I guess), so this |
| | 58 | would be something for the community to discuss - the scope is a bit |
| | 59 | broader than just the Component Registry though, since the whole |
| | 60 | metadata generating part of the infrastructure would need to support it. |
| | 61 | |
| | 62 | > - inclusion of components inside components: I have seen that you can |
| | 63 | > include components in two ways: |
| | 64 | > |
| | 65 | > (a) by adding a component and specifying all the elements that should be |
| | 66 | > included in this, in which case you add a name for the component; |
| | 67 | > |
| | 68 | > (b) by dragging an existing component from the table to the edit canvas; |
| | 69 | > in this case, the componentId is used instead of the name and you don’t |
| | 70 | > have to add the elements. |
| | 71 | > |
| | 72 | > Is there a way of adding an existing component and “altering” its name? |
| | 73 | > For instance, we have the same component (personInfo) for adding data |
| | 74 | > for all persons, regardless of their role (e.g. contact persons, |
| | 75 | > copyright holders etc.). In each component that a person can be added, |
| | 76 | > we give in the XSD the name of the element and the type of the |
| | 77 | > personInfo component, e.g. |
| | 78 | > |
| | 79 | > |
| | 80 | > <xs:elementname="contactPerson"type="ms:personInfoType"maxOccurs="unbounded"> |
| | 81 | > |
| | 82 | > Is there a way of doing something similar in the component registry? |
| | 83 | |
| | 84 | So this would make components a bit more like 'types', and not chunks |
| | 85 | that get re-used as a whole. Unfortunately the way components are |
| | 86 | referenced in profiles and other components in the specification |
| | 87 | language (from which profile schemas gets generated) makes this a bit |
| | 88 | hard to do at the moment. Again this is something we may want to |
| | 89 | consider for a future version of CMDI and therefore something that needs |
| | 90 | to be discussed. |
| | 91 | |
| | 92 | > - ordering of elements and components: I’ve seen that you can move up |
| | 93 | > and down elements between them but I couldn’t move a component in |
| | 94 | > between elements. Is there a way of doing this? |
| | 95 | |
| | 96 | The CMDI specification (by means of the general component schema[1]) |
| | 97 | requires all elements within a component to appear *before* any |
| | 98 | contained components, so again in the current version of CMDI there is |
| | 99 | no way to do this. I'm not aware of the exact rationale behind this, but |
| | 100 | maybe someone can comment on this. If there is no good reason to keep |
| | 101 | the components and elements separated, again that is something that may |
| | 102 | be changed in a future version. |
| | 103 | |
| | 104 | So unfortunately there are no real solutions (yet) for any of these |
| | 105 | points, but we are working on some of them and others can be discussed. |
| | 106 | I hope this answers your questions though; if not feel free to post any |
| | 107 | additional questions to the cmdi@clarin.eu e-mail address or to the CMDI |
| | 108 | forum[2] mentioned by Dieter. |
| | 109 | |
| | 110 | Kind regards, |
| | 111 | Twan |
| | 112 | |
| | 113 | [1] http://www.clarin.eu/cmd/general-component-schema.xsd |
| | 114 | [2] http://tla.mpi.nl/forums/data-archiving/cmdi |
