Changes between Version 2 and Version 3 of ClarinHelpdesk/q9

11/13/12 13:53:01 (12 years ago)

added answer


  • ClarinHelpdesk/q9

    v2 v3  
    2424== Answer ==
     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?
     31CMDI itself has not been designed with re-use of elements in mind, but
     32it's an interesting suggestion to provide some kind of 'snippets'
     33functionality to the Component Editor. I suppose we could consider this.
     34As far as Controlled Vocabularies are concerned, the common practice now
     35is 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
     37gets applied to all instances).
     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?
     46This as a feature would make a lot of sense, and in fact already is on
     47our roadmap, so you can expect it in a future version of the Component
     48Registry (but too be honest probably not within the next couple of months).
     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?
     55No, there is no support for choice in CMDI. However I don't see any
     56reason for CMDI not too support this in a future version, except maybe
     57for the added complexity (which would not be too bad I guess), so this
     58would be something for the community to discuss - the scope is a bit
     59broader than just the Component Registry though, since the whole
     60metadata generating part of the infrastructure would need to support it.
     62> - inclusion of components inside components: I have seen that you can
     63> include components in two ways:
     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;
     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.
     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.
     80> <xs:elementname="contactPerson"type="ms:personInfoType"maxOccurs="unbounded">
     82> Is there a way of doing something similar in the component registry?
     84So this would make components a bit more like 'types', and not chunks
     85that get re-used as a whole. Unfortunately the way components are
     86referenced in profiles and other components in the specification
     87language (from which profile schemas gets generated) makes this a bit
     88hard to do at the moment. Again this is something we may want to
     89consider for a future version of CMDI and therefore something that needs
     90to be discussed.
     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?
     96The CMDI specification (by means of the general component schema[1])
     97requires all elements within a component to appear *before* any
     98contained components, so again in the current version of CMDI there is
     99no way to do this. I'm not aware of the exact rationale behind this, but
     100maybe someone can comment on this. If there is no good reason to keep
     101the components and elements separated, again that is something that may
     102be changed in a future version.
     104So unfortunately there are no real solutions (yet) for any of these
     105points, but we are working on some of them and others can be discussed.
     106I hope this answers your questions though; if not feel free to post any
     107additional questions to the e-mail address or to the CMDI
     108forum[2] mentioned by Dieter.
     110Kind regards,