Capture old spelling variants of metadata options

[matthias-ronge]

Is your feature request related to a problem? Please describe. In legacy data, there are occasionally metadata values that have changed, for example because they have been standardized. This leads to a problem for selection fields if the metadata editor, when opened, finds a value for the field that no longer exists in the ruleset. An error message appears, but when you click Save, the data is gone. Data loss in particular is a problem. If someone inexperienced comes across such a process and saves it, the recorded data is gone. Inserting the value into the ruleset is not an option because now only the new value is and should be there.

Describe the solution you'd like You should also be able to specify the old values in the ruleset, which will then be mapped to the new values when opened. Example (the <map> tag):

<key id="contributor">
    <label>Contributor ‹person›</label>
    <key id="role">
        <label>Role</label>
        <option value="aut">
            <map>Author</map>
            <map>author</map>
            <map>Autor</map>
            <label>Author</label>
        </option>
        <option value="edt">
            <map>Editor</map>
            <map>editor</map>
            <map>Bearbeiter</map>
            <map>BearbeiterIn</map>
            <label>Editor</label>
        </option>
    </key>
    <key id="givenName">
        <label>Given name</label>
    </key>
    <key id="surname">
        <label>Surname</label>
    </key>
</key>

At the moment, a metadata entry role = Author would cause an error message, no value is selected in the display, and after saving the value would be gone. With the additional option, Author would be displayed in the display and saved as role = aut when you click Save.

Describe alternatives you've considered

• One could correct the metadata files on the file system, for example with sed. However, this requires access to the file system, and an instruction that is too generic in sed could also cause changes elsewhere.
• You could also correct the values with an XSLT file. This would then have to run both before opening the metadata editor and before the export XSLT.

[henning-gerhardt]

For simple meta data field you can replace existing old values with new values with the help of the KitodoScript overwriteData (see https://github.com/kitodo/kitodo-production/wiki/Metadaten-Skripte) but this works not for meta data fields in meta data groups (@andre-hohmann please correct me if I'm wrong). So maybe improving this KitodoScripts for meta data groups support is maybe an option too without blowing up the ruleset files? Even maybe both approaches should be available.

[matthias-ronge]

I will check how far this can help me.

[andre-hohmann]

@henning-gerhardt : As far as i know, you are right. Values in metadata groups cannot be adjusted by the Metadata-Scripts. But even if it is possible, they are only helpful, if the processes with the incorrect values are known. With the current search, it is not possible to find all processes.

@matthias-ronge : One option is to select the correct value before saving the process - if the user can decide the correct one. The opportunity to define alternative values seems to be on the first glance very helpful, because not every user might know the correct value.

We have corrected the incorrect values in the selection lists manually (choosing the value in the list) and with Metadata-Scripts. But this might not always possible. Maybe it would also helpful, if the incorrect value is not deleted after saving. The correction could then also be carried out later and the value is not deleted accidentally.

To all who are migrating the metadata from Kitodo.Production 2 to Kitodo.Production 3: You could try to correct the values via the XSLT-transformation of the metadata. At least, if the variants of incorrect values are known, this could save time for the corrections after the migration.