Linking pages to the following structural element not possible if the elements are not on the same hierarchical level

[illipsum]

Describe the bug Not entirely sure whether this is a matter of configuration or an issue of Kitdo itself. Here's the scenario: If you create more than one level of structural data, linking a page at the end of a structure element to the following one does not work if the following element is not on the same hierarchical level.

To Reproduce To illustrate: On the last page of the last section (Abschnitt) both the chapter and section end and the following chapter (Kapitel) begins. The page looks like this: While it worked for all the sections on the same structural level, creating a link to add this page to the following chapter is not a given option in the context menu:

Expected behavior It should be possible to create a link that adds the current page to the following structural element

Release 3.4.4

Desktop (please complete the following information):

• OS: Windows 10
• Browser Firefox
• Version 102.5.0

[solth]

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

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

[illipsum]

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.

[BartChris]

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.

https://user-images.githubusercontent.com/7516499/204038382-570d5329-5e19-43a9-a256-1bf0398a90c1.mp4

[BartChris]

I also opened a general discussion here: https://github.com/kitodo/kitodo-production/discussions/5469

[oliver-stoehr]

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

[BartChris]

@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.

[illipsum]

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.

https://user-images.githubusercontent.com/51130057/204591768-cd62b066-cd94-43a6-ac09-133b21c3c5ba.mp4

[BartChris]

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 https://github.com/kitodo/kitodo-production/issues/5457#issuecomment-1330894953 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 2not 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.

[anspallek]

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?

[BartChris]

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.

[thomaslow]

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!

[BartChris]

@thomaslow I played with your solution and it works nice. I can add (multiple) links, also over different hierarchical levels. Great! I have not inspected the code and the XMLs yet, but i also tried to drag linked pages around. I will have to think more about the problem, what should happen if somebody moves linked pages around in the tree. It seems like this allows for really wild linking of pages, but sometimes - when dragging a page around - the link just disappears.

Edit:

• One option would be to always dissolve the link when the node "carrying" that link is dragged around. I noticed that you implemented it in a way that when "assigning" to the next element, you always choose the element on the lowest level, which is correct. To illustrate: Page 8:4 is linked from Abschnitt to Illustration (and not the parents) of illustration.

So usually there is no need to drag to a lower level, since your code wil do that automatically. There might be situations where you want to add an even lower level (after the link has been introduced) and then drag the link there.

But enabling to drag around the links poses the questions, wether we should introduce consistency checks, which feels like a real overkill.

• The other option would be to allow people to drag around in whatever way they please, but not to guarantee that everything then stays bug free.

Maybe @kitodo/kitodo-community-board or @solth and @oliver-stoehr can also weigh in here.

[BartChris]

I played around a little bit further and it seems like that the link can be dragged around, but specific things are not possible and lead to the dissolving of the link

• Drag a linked node to the same structure element which holds the connected node
• Drag a linked node B which is after linked node A before node A

On the other hand a linked node B can be dragged down in the tree and that does not dissolve the link.

This behaviour of dragging around links might therefor be - if at all - the topic of another pull request. For now it is probably wise to stick with the possibility to drag around linked nodes, which gives more flexibility and better usability. In my opinion Kitodo implements a quite restricted model of linking structures with pages. The possibility to drag around linked nodes could give the impression, that the users can freely attach pages to physically not-connected structures (e.g. link a page to the first chapter and the last chapter of the book). This is however not the core functionality of the editor in its current form.

(PS: There was a long discussion during a community meeting (https://docs.google.com/document/d/1_PZPObWGteCetP3rGugno7v6xM3Y-xqCfD0tlshAMDA/edit?tab=t.0 -> not documented in this protocol) on how freely pages should be linked to structures. The "combined" structure tree (which is used by the majority of users) does implicitely implement a strict hierarchical view of a document. One cannot e.g. associate page 250 with the first structural element, without changing the physical order of pages. So Kitodo 3 has implemented restrictions on how freely structures can be associated to pages.)

I would say that the actual implemented new behaviour of this Pull Request (which mostly is about the insertion of new links) looks good. Thanks a lot. I will do some more testing, but i think the PR is good to go.

[thomaslow]

@BartChris Thank you for your detailed experiments and feedback. I'm glad that adding new links works for you.

Soonish (hopefully this year), I will revise the drag & drop code base of the metadata editor as part of another issue #5926. I will keep in mind, that there is a problem with disappearing links and hopefully find the problem then.