As far as I know this is not a bug but by design.

@oliver-stoehr can you elaborate on this a little more?

Hi Arved,

thanks for your reply. Maybe to clarify my point: if this behaviour is not due to configurations made in the ruleset or elsewhere, it has to be considered a bug imho. Take a look at the contents of the aforementioned book:

On page 100 both chapter "II. Halbtageswanderungen" and sub-chapter "e) Ins Bergische" end (and actually "2. Größere Wanderungen..." as well, but I ignored that level), and the following chapter "III. Weitere Tagesausflüge..." begins.
Now, if it were impossible by design to link structural elements of different levels, one would either be coerced to produce flawed structural data (having assigned the page in question to only one of the structure elements) or limit the structuration depth to the top level.
Neither could be considered a desirable modus operandi.

I would also think that a page should always be assignable to the next structural element, independent of the hierarchical level. This is necessary to enable exporting complete structures (e.g. as PDF) without having to decide if a page is only belonging to the previous chapter or the new main chapter.
This might get quite complicated if the Page should be linked to a Structure element which is in itself a child of another hierarchy. So it is has to be investigated if we can cover more complicated scenarios.

While investigating this issue i also encountered, that the gallery is duplicating images, when, "assign to next element" is selected multiple times. This does not seem to affect data, so it is only a minor annoyance.

I also opened a general discussion here:
#5469

This restriction is by design. I don't fully remember the reasons we had three years ago. As far as I can tell there are no technical limitations left, that prevent a change of the current implementation.
But the main reason was, that the "assign to next element" action would be ambiguous and confusing if possible over multiple levels.

• Monograph
  • Chapter 1
    • Page 1
    • Chapter 1.1
      • Page 2
  • Chapter 2

When linking page 2 in this example, it is not clear whether the "next element" is Chapter 1 or Chapter 2. So it might result in:

• Monograph
  • Chapter 1
    • Page 1
    • Chapter 1.1
      • Page 2
    • Page 2
  • Chapter 2

or:

• Monograph
  • Chapter 1
    • Page 1
    • Chapter 1.1
      • Page 2
    • Page 2
  • Chapter 2
    • Page 2

@oliver-stoehr thanks a lot for your response. In my opinion the next element is chapter 2, because i do not really see the ambiguity here. Everything which is included in chapter 1.1 is automatically part of chapter 1 since the structure-page-link is repeated in the higher hierarchical levels when exporting.
There might therotically be constellations where there is a section after 1.1. which belongs to chapter 1 only, but i would say that this is very rare and 99% percent of the cases would be the beginning of chapter 2 on the same page as the end of chapter 1.1 - so that you would want the link to chapter 2. But maybe i am overlooking some cases. The possibility to link to chapter 2 is also way more important to enable correct PDF exports of all the pages of chapter 2 for example.

I found a way to solve this, but it's quite the hassle. So instead of classifying this a bug, making linking between structural elements easier would be my feature request. Here is how I did it:

1. Pull the last page out of the sub-level section to the chapter one level above
2. Create the link to the following chapter
3. Pull the last page back to sub-level section
   This yields correct structural data.

@oliver-stoehr Thanks for the reply. I can see how there is in theory room for ambiguity here, but I agree with @BartChris that this would very rarely be the case. And only by allowing links across structural levels correct structural data are possible for all the common cases. where structural elements end and begin on the same page and where there is more than one level of structuration depth.

We still see this as a desirable feature. I will try to outline what a solution might look like.

1. I propose to keep the dialog as simple as possible and keep "Assign to next element" as the only linking option
2. This option should be enabled even if the next element is not on the same hierarchical level, under certain conditions
   • the element has to be a non-root top-level logical node without children or the last structural element inside a non-root logical node
   • the next element in the tree has to be a structural element -independent of it's hierarchical level-, not a page
3. Using the "assign to next element" button always puts a link inside the next logical node (independent of level).
4. It should be possible to drag the link to lower level nodes of this logical nodes after that.

The problems addressed here #5457 (comment) are not a real problem in this context. The example indicates that it might be unclear whether the user wants to link Page 2 in chapter 1.1 to chapter 1 or chapter 2. But a page on chapter 1.1 is always already linked to chapter 1 in the exported METS. So there is no need to explicitly link Page 2 to chapter 1, this always happens automatically. (We might even duplicate the link in the exported METS if we link Page 2 explicitly to chapter 1)

I will try to visualize the proposed idea.

Consider the following structure from above

Monograph

    * Chapter 1
        * Page 1
        * Chapter 1.1
            * Page 2 (-> Page to be linked <-)
    * Chapter 2

Selecting "Assign to next element" for Page 2 results in the following tree:

Monograph

    * Chapter 1
        * Page 1
        * Chapter 1.1
            * Page 2 (-> Page to be linked <-)
    * Chapter 2
            * _Page 2_  (linked)
            * Chapter 2.1
                * Page 3  

If the user wants to link Page 2 not only to Chapter 2, but to Chapter 2.1 especially, he can do so be dragging the link there:

Monograph

    * Chapter 1
        * Page 1
        * Chapter 1.1
            * Page 2 (-> Page to be linked <-)
    * Chapter 2
            * Chapter 2.1
                * _Page 2_  (linked)
                * Page 3     

This is necessary to enable explicit linking to sub chapters (sub-structures) as well. The main questions would be
a) What to allow when linked pages are dragged around?
b) how to proceed when elements like Page 3 are dragged around which normally cannot appear before a linked page.

My intuition would be: After the initial link element is placed nothing should be explicitly disallowed if it does not bring serious harm from a technical side. This is especially true for b) All page can be dragged around by this user even if this leads to strangely arranged page links. Otherwise we would have to always check whether a specific re-arrangement of pages leads to an illogical linking structure.

On the other hand: It is already possible to drag around linked elements but the behavior is sometimes not really predictable. If freely dragging around leads to complicated behavior one can also think of a command like "move link down" or "move link up" to attach the link to sub chapters. This would enable more controlled behavior and would satisfy our requirements.

I am not sure if the current design choices meet the DFG requirements for 2.3 Linking of logical and physical structure (mets:structLink) of the DFG profile METS application profile for digitised media Version 2.3.1. "A logical structure can be made up from several physical structural elements (e.g. pages) and a physical structure can belong to several logical structural elements." (p. 16) https://dfg-viewer.de/fileadmin/groups/dfgviewer/METS_application_profile_2.3.1.pdf
Do I understand correctly, that it is currently not possible to assign several (logical structural) elements or sub-elements to one image (physical structural element) in Kitodo 3?

I would also like to add some examples for which there were problems with the input of elements in the structure tree. Pages are missing in the structure tree which could lead to incomplete mets:structLink and incomplete PDF chapter/element download.

• Example sub-element Figure: Chapter looses a page in the structure tree if a sub-element (ex. Figure) is added. At the same time the image with the figure is removed from the chapter in the Gallery.
  

• Example Image points to several (sub-)elements: Only the last added (sub-)element keeps the image and the pagination in the structure tree. The other (sub-)elements loose the same image/pagination. For example two obituaries with two figures are on one page (Screenshot uses element Chapter)
  

So far I have only tested monographs. Is it possible to create a nested structure tree of a journal: Level 1 Journal, Level 2 Volume, Level 3 Issue, Level 4 Journal Article, Level 5 Image?

Is it possible to create a nested structure tree of a journal: Level 1 Journal, Level 2 Volume, Level 3 Issue, Level 4 Journal Article, Level 5 Image?

@anspallek This should already be possible, because Kitodo automatically adds the links to the higher levels during export. If a page belongs to structure 1.1.1, it also belongs to 1.1 and 1 in the exported METS. It might appear in the editor as if the image is only is attached to the lowest hierarchy level. And this is also the case for the internal METS saved by Kitodo. The exported METS however contains links between the pyhsiycal structure and all the logical level it belongs to (direct or indirect). The DFG guideline

A logical structure can be made up from several physical structural elements (e.g. pages) and a physical structure can belong to several logical structural elements.

should therefor be satisfied. You can try the "Export DMS" (which generates the exported METS) functionality to check this.

Hi everyone, could you check the demo video of my pull request (see #6255), and verify that this is the behavior that you expected? Thank you!