Missing LABEL and ORDERLABEL attributes for year- and issue- processes of newspaper

[andre-hohmann]

Problem

For newspaper processes, the attributes LABEL and ORDERLABEL of <mets:div TYPE="newspaper"> are not included in the exported XML files of the year- and issue-process. The attributes LABEL and ORDERLABEL of <mets:div TYPE="year"> are included in all exported XML files. See the examples below.

In the METS- Anwendungsprofil (page 12), at least the LABEL attribute is included in the year- and issue-process.
In Kitodo.Production 2.x, the LABEL and ORDERLABEL of <mets:div TYPE="newspaper"> are included in all XML files. See the examples below.

Question

Is the lack of the LABEL and ORDERLABEL attributes a desired result of the modified hierarchy in Kitodo.Production? Or did it just not attract anybody's attention, yet?
I could imagine, that especially the LABEL-attribute is needed for a correct depiction of the processes in the presentation.

Solution

It seems that the attributes are needed and they should be created internally. Either by the XSLT export or by internal functions, as for example for the <mets:div> of the year-level.
The application of additional external or post-processing scripts should be avoided.

Examples

Newspaper 3.x

<mets:structMap TYPE="LOGICAL">
    <mets:div ID="LOG_0000" LABEL="Weißeritz-Zeitung" ORDERLABEL="Weißeritz-Zeitung" DMDID="uuid-017a6d80-fde9-3445-a239-bc86ba0c9f14" ADMID="AMD" TYPE="newspaper">
        <mets:div ID="uuid-158743f5-b60e-4056-b84c-d8afc3af8be0" TYPE="year" ORDER="1" ORDERLABEL="1950" LABEL="Spielzeit 1950">
            <mets:mptr LOCTYPE="URL" xlink:href="https://digital.slub-dresden.de/data/kitodo/Wei_1761426109-1950/Wei_1761426109-1950.xml"/>
        </mets:div>
    </mets:div>
</mets:structMap>

Year 3.x

<mets:structMap TYPE="LOGICAL">
    <mets:div ID="uuid-46d49446-98a3-4ed6-97c0-df6e702f4067" TYPE="newspaper">
        <mets:mptr LOCTYPE="URL" xlink:href="https://digital.slub-dresden.de/data/kitodo/Wei_1761426109/Wei_1761426109.xml"/>
        <mets:div ID="uuid-54da021b-20e7-4d24-9863-b0928e959902" DMDID="uuid-23b05f42-3c31-397a-93fc-e869212648fa" ADMID="AMD" TYPE="year" ORDERLABEL="1950" LABEL="Spielzeit 1950">
            <mets:div ID="uuid-98db6739-a748-44b1-ac2a-77b1c5560ae3" TYPE="month" ORDER="1" ORDERLABEL="1950-01">
                <mets:div ID="uuid-33877e9c-543b-4122-920a-abb708b6218b" TYPE="day" ORDER="1" ORDERLABEL="1950-01-02"/>
                <mets:div ID="uuid-80718bed-46ab-424a-8052-9b7925d55257" TYPE="day" ORDER="2" ORDERLABEL="1950-01-09"/>
                <mets:div ID="uuid-7f1e77a1-a3bf-4d03-bade-22af75caeaac" TYPE="day" ORDER="3" ORDERLABEL="1950-01-16"/>
                <mets:div ID="uuid-c8cb0a29-9d43-4eb3-a202-3c642d8c1302" TYPE="day" ORDER="4" ORDERLABEL="1950-01-23"/>
                <mets:div ID="uuid-76ab2e14-3c76-4173-9bf9-12a41627e600" TYPE="day" ORDER="5" ORDERLABEL="1950-01-30">
                    <mets:div ID="uuid-af220305-adf9-490b-8806-cfb5264cdc0a" TYPE="issue" ORDER="1">
                        <mets:mptr LOCTYPE="URL" xlink:href="https://digital.slub-dresden.de/data/kitodo/Wei_1761426109-19500130_vorlage/Wei_1761426109-19500130_vorlage.xml"/>
                    </mets:div>
                </mets:div>
            </mets:div>
        </mets:div>
    </mets:div>
</mets:structMap>

Issue 3.x

<mets:structMap TYPE="LOGICAL">
    <mets:div ID="uuid-27cea334-24f9-4a2d-b583-a336d2848877" TYPE="newspaper">
        <mets:mptr LOCTYPE="URL" xlink:href="https://digital.slub-dresden.de/data/kitodo/Wei_1761426109/Wei_1761426109.xml"/>
        <mets:div ID="uuid-43c2ca4a-c8e0-4884-8ad7-0d4295bc36c9" TYPE="year" ORDERLABEL="1950" LABEL="Spielzeit 1950">
            <mets:mptr LOCTYPE="URL" xlink:href="https://digital.slub-dresden.de/data/kitodo/Wei_1761426109-1950/Wei_1761426109-1950.xml"/>
            <mets:div TYPE="month" ORDERLABEL="1950-01" ID="uuid-95ba613b-df20-4fe9-a88e-1ee47b714049" ADMID="AMD">
                <mets:div TYPE="day" ID="uuid-30f8c09a-264f-4550-a4fc-867e53160cad" ORDERLABEL="1950-01-30">
                    <mets:div ID="uuid-233ff383-b96d-4738-8f62-cc0b1a2122ae" LABEL="Test-Ausgabe" ORDERLABEL="Test-Ausgabe" DMDID="uuid-f55e026d-9d81-3b9d-a2d7-a72f31f68ea2" TYPE="issue" ORDER="1"/>
                </mets:div>
            </mets:div>
        </mets:div>
    </mets:div>
</mets:structMap>

Newspaper 2.x

https://digital.slub-dresden.de/oai?verb=GetRecord&metadataPrefix=mets&identifier=oai:de:slub-dresden:db:id-1761426109

Year 2.x

https://digital.slub-dresden.de/oai?verb=GetRecord&metadataPrefix=mets&identifier=oai:de:slub-dresden:db:id-1761426109-1911

Issue 2.x

https://digital.slub-dresden.de/oai?verb=GetRecord&metadataPrefix=mets&identifier=oai:de:slub-dresden:db:id-1761426109-19111212

[stefanCCS]

Hi @andre-hohmann ,
I can absolutely understand your issue. I have encountered the same.
I have build a solution which processes a post export scripts, which navigates through the Kitodo-Database, finds out this way, what to do, creates dynamically an xsl file, which is processed afterwards to add the missing things.
Unfortunately, very complicated and I fear not very fail-safe to future versions of Kitodo.
Sorry, I do not have a better answer.

[andre-hohmann]

@stefanCCS , thanks a lot for the reply. You are right, the solution sounds very complicated and for it is not applicable. In my opinion, there must be an internal solution - at least with the XSLT export. Thus, i will change the label of the issue.

For the year <mets:div> it works already and with the XSLT export , it cannot be solved.
In each METS-file, the attributes are generated for each <mets:div>. The METS-files for issues with merged information from the superordinate processes in the <mets:div> cannot be modified by the XSLT export.

[matthias-ronge]

There are some limitations in the XSLT, for example neither data from other meta.xml files can be accessed, nor HTTP querys can be made. Therefore, I would have liked to have used a different data editing language ever since, such as BeanShell, which could access anything in the running Java program. But to my regret, the choice has always been made for XSLT. Well, maybe for the future this is still a possibility, at least to make it possible as an alternative.

Another application solution would be to reimplement the powerful CopyData expressions again. This is a kind of metadata programming language that was existing in version 2. For this, there is a syntax definition already developed in #3368 (comment) which i.e. adds syntax for accessing parent meta.xml documents (see circumflex (^) operator). But this has not yet been implemented in Production 3.

Also related: #4679

[andre-hohmann]

The XSLT has from my point of view the advantage, that it can be easily applied by non-IT administrators and that there are easily accessible validators and discussions/documentation.
The option to implement the copyOnExport should be considered, but it must be taken into account, that there are metadata-scripts, which could be used.

[andre-hohmann]

There is another option during the import, respectively during the data-migration.

For superordinate processes (newspaper, periodical, ...), the attributes LABEL and ORDERLABEL could be filled with the values of the elements "title" or the "title (sort)". Then, they do not have to be added during the export.
A disadvantage is that in case of mistakes, the values in both elements (LABEL + title ; ORDERLABEL + title (sort)) have to be corrected. For newspaper and periodicals, the probability of changes, ... seems to be low.

Thus it is not a perfect option, but one that could be relatively easily implemented (hopefully).

[Kathrin-Huber]

@andre-hohmann Is this fixed?

[andre-hohmann]

@Kathrin-Huber :
No, it is not fixed. we only have a workaround:

1. During XSLT-import: the attributes LABEL and ORDERLABEL are filled in the superordinate processes
2. During data migration from 2.x to 3.x; the attributes LABEL and ORDERLABEL are filled with the values of "title" or the "title (sort)"
   Then, the attributes LABEL and ORDERLABEL for the superordinate processes are added correctly in the <mets:structMap TYPE="LOGICAL"> of the subordinate processes.

It would be sustainable, if the export XSLT of the attributes LABEL and ORDERLABEL are applied to all levels in <mets:structMap TYPE="LOGICAL">. The aim for 3.x was to remove the dependence from METS-attributes and MODS-elements.
That could be possible, when the complete XSLT is applied to the superordinate process, before the <mets:div> is implemented in the <mets:structMap TYPE="LOGICAL"> of the subordinate process. The attribute TYPE is always implemented correctly.

Edit 2023-04-03: It is necessary to add the attributes LABEL and ORDERLABEL both in the superordinate and the subordinate processes.

[andre-hohmann]

This seems to have effects on Kitodo.Presentation:

• [BUGFIX] Get issue title from the day if the issue itself doesn't contain correct date kitodo-presentation#1315

[andre-hohmann]

Similar issue:

• Automatically set outline headings  #5016

See also:

• Anwendung der METS-Attribute LABEL und ORDERLABEL in Kitodo #6277
• TYP, LABEL und ORDERLABEL in Überordnung speichern #6184