This is a 1:1 clone of TRANSLATE-1375. Please ensure together with tlauria here, that this still works with the new TermPortal.

       

       

      For context please read TRANSLATE-1274 before implementing this issue.

      Current situation

      If a term contains an attribute of type normativeAuthorization, the values are stored in translate5 editor as shown in the following list. The visualization of the different terms is summarized to the parenthesized labels

      • preferredTerm: (preferred designation / Vorzugsbenennung, shown with a green check)
      • admittedTerm: (permitted designation / erlaubte Benennung, shown with a blue dot)
      • legalTerm: (permitted designation / erlaubte Benennung, shown with a blue dot)
      • regulatedTerm: (permitted designation / erlaubte Benennung, shown with a blue dot)
      • standardizedTerm: (permitted designation / erlaubte Benennung, shown with a blue dot)
      • deprecatedTerm: (forbidden designation / verbotene Benennung, shown as red stop)
      • supersededTerm: (forbidden designation / verbotene Benennung, shown as red stop)

      In addition, for the termPortal the following is implemented

      • If a term bears the attribute <termNote type="across_ISO_picklist_Usage">do not use</termNote>, it will be shown as forbidden term in the termPortal

      Additional info in the meta panel

      Currently only the information in the above parenthesises are displayed to the user. In the future also the real status value should be shown in the meta panel term tooltip.

      Include administrativeStatus notes

      In the future, the values of termNotes type administrativeStatus are also considered as translate5 term status.

      • <termNote type="administrativeStatus">preferredTerm-admn-sts</termNote>
      • <termNote type="administrativeStatus">standardizedTerm-admn-sts</termNote>
      • <termNote type="administrativeStatus">regulatedTerm-admn-sts</termNote>
      • <termNote type="administrativeStatus">legalTerm-admn-sts</termNote>
      • <termNote type="normativeAuthorization">preferredTerm</termNote>
      • <termNote type="normativeAuthorization">standardizedTerm</termNote>
      • <termNote type="normativeAuthorization">legalTerm</termNote>
      • <termNote type="normativeAuthorization">regulatedTerm</termNote>
      • <termNote type="administrativeStatus">deprecatedTerm-admn-sts</termNote>
      • <termNote type="administrativeStatus">supersededTerm-admn-sts</termNote>
      • <termNote type="normativeAuthorization">deprecatedTerm</termNote>
      • <termNote type="normativeAuthorization">supersededTerm</termNote>
      • <termNote type="administrativeStatus">admittedTerm-admn-sts</termNote>
      • <termNote type="normativeAuthorization">admittedTerm</termNote>

      That means a 1to1 Mapping between administrativeStatus and normativeAuthorization is possible.

      Handling of unknown terms

      All other terms not listed above will be added with the default status, which is configurable (runtimeOptions.tbx.defaultTermStatus).

      If the term has no status at all, the default status will be used too. If the term as a state unknown to translate5 additionally a log entry is generated.

      In TermPortal the terms are shown accordingly.

      Needed mapping in system configuration

      Import Map

      A new system configuration allows to map any kind of termNote type value, so that the term will be treated as a "Preferred term" or a "Forbidden term" in translate5.

      By default this configuration will be set to an empty value for "Preferred term". For a "Forbidden term" by default the mapping will be set so, that it maps <termNote type="across_ISO_picklist_Usage">do not use</termNote> to "Forbidden term".

      This config values are flexible addable by the admins, only the above one is predefined as example:

      runtimeOptions.tbx.termImportMap.across_ISO_picklist_Usage.do not use = forbiddenTerm

      So as another example other, non standard normativeAuthorization can be added:

      runtimeOptions.tbx.termImportMap.normativeAuthorization.myCustomOne = standardizedTerm

      Label Map

      A second mapping defines how the translate5 term status should be displayed, in other words the mapping between term name and label, listed at the top of the issue, must also be configurable.

      This config values will be:

      runtimeOptions.tbx.termLabelMap.preferredTerm = preferred
      runtimeOptions.tbx.termLabelMap.admittedTerm = permitted
      runtimeOptions.tbx.termLabelMap.legalTerm = permitted
      runtimeOptions.tbx.termLabelMap.regulatedTerm = permitted
      runtimeOptions.tbx.termLabelMap.standardizedTerm = permitted
      runtimeOptions.tbx.termLabelMap.deprecatedTerm = forbidden
      runtimeOptions.tbx.termLabelMap.supersededTerm = forbidden

       

          [TRANSLATE-2508] Map arbitrary term attributes to administrativeStatus

          Apart from the above content the issue was implemented:

          • define all valid term status mappings in a separate table (since to complex / JSON to big for current config table)
          • this includes the custom status values and the known normativeAuth and administrativeStatus values. So the latter values there are also mappable.
          • update datatype picklist values from mapping list on each import
          • precedence is custom, administrativeStatus, normativeAuth where custom is the weakest, and normativeAuth the strongest in order to use normativeAuth if for example a proposal was taken over

          Thomas Lauria added a comment - Apart from the above content the issue was implemented: define all valid term status mappings in a separate table (since to complex / JSON to big for current config table) this includes the custom status values and the known normativeAuth and administrativeStatus values. So the latter values there are also mappable. update datatype picklist values from mapping list on each import precedence is custom, administrativeStatus, normativeAuth where custom is the weakest, and normativeAuth the strongest in order to use normativeAuth if for example a proposal was taken over

          Marc confirmed this should be assigned to you as things described here are related to tbx import

          Pavel Perminov added a comment - Marc confirmed this should be assigned to you as things described here are related to tbx import

            tlauria Thomas Lauria
            marcmittag Marc Mittag [Administrator]
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: