Creation of newspaper processes: Enabling adding individual metadata for the first issue per day

[andre-hohmann]

Problem

For the creation of processes for newspaper issues, to functions are available to add metadata to the processes.

• Add metadata to all issues: The selected metadata field and its value are assigned to all issues. This is relevant for metadata like language, digital collection ... which are usually the same for all issues.
• Add metadata: The selected metadata field and its value are assigned to only one issues. This is relevant for metadata like issue-label ... which are not the same for all issues.

It seems, that the function of Add metadata to all issues and Add metadata for the first issue are the same. In both cases, the metadata field is assigned to all issues and the values cannot be changed. In addition, it is not possible to delete metadata of the first issue. If the metadata is deleted, it is deleted for all all issues.
For other issues, the function Add metadata works correctly and the metadata field and its value is only assigned to one issue and the metadata field can be deleted.

Solution

The function Add metadata for the first issue must be corrected to enable the assignment of individual metadata for the first issue.

Example

[andre-hohmann]

After a discussion with @solth and @IkramMaalej, we found out that there are different expectations about the function Add metadata.

Expectation 1
In my opinion, the function Add metadata should enable the assignment of metadata (for example: title= Frühausgabe) to all issues of that type (Frühausgabe) in the block.
Otherwise, it is not possible to assign a title or a a label to the respective issues.
To enable the assignment of titles to issues, the processes of each issue of one day have to be created separately, which consumes more time.

Expectation 2
The current implementation enables the assignment of a metadata to the issues of one day, as for example.
There are four issues a day:

• Issue 01
• Issue 02
• Issue 03
• Issue 04

If Add metadata is applied to

• Issue 01, the metadata is assigned to the issues 01-04
• Issue 02, the metadata is assigned to the issues 02-04
• Issue 03, the metadata is assigned to the issues 03-04
• Issue 04, the metadata is assigned to the issues 04-04

I cannot imagine a use case for that function. Probably, this is a misunderstanding regarding the function "Ab dieser Ausgabe" (Enable metadata input in calendar form), which does not clearly describes which option is meant:

1. All issues of one type beginning from a the specific date.
2. All issues of one day beginning from a specific issue.

Result
Before the issue is implemented, it must be examined if both expectations are needed or if expectation 1 meets all demands.

[andre-hohmann]

@matthias-ronge : Do you know, which of the expectations in the comment above is correct?
It seems as if you are the one with the most knowledge and experience regarding the creation of newspaper processes.

In my opinion we have the following opportunities to solve the problem:

1. If expectation 1 is correct, the existing function should be modified
2. If expectation 2 is correct, an additional button and function is necessary to implement expectation 1
3. If no one can decide, which expectation is the correct one, an additional button and function is necessary to implement expectation 1

[matthias-ronge]

Expectation 2: Current implementation is, there is a Block, that has a date of firstAppearance an a date of lastAppearance, and it contains issues. Issues are generic, they can have a heading as they may differ in time of publication (morning issue, evening issue, …), geographic distribution (Edinburgh issue, London issue, …) and/or their days of appearance (weekday issue: Mon—Fri, weekend issue: Sat, sports supplement: Mon, real estate market: Wed, broadcasting programme: Thu). Furthermore there may be exclusions if an issue didn’t appear on a date where, due to the day of week, it usually does (i.e. on holidays), and additions if an issue has appeared where, due to the day of week, it should not have.

The CountableMetadata records are bound to the Block (!) and define each a pair consisting of a start date and an issue for their create moment, and for their delete moment.

From these values, the IndividualIssues are dynamically generated (and re-generated whenever a change makes it necessary). So, if you select an additional issue on a day where it normally wouldn’t appear, and you have a running issue number metadata, the additional issue will receive an issue number, and all subsequent issues will be renumbered.

Example: You have a block for week 44/2022 (31st Oct 2022 − 6th Nov 2022) with a “morning issue” (Mon − Sat), a “noon issue” (Mon − Sat) and an “evening issue” (Mon − Fri), and a metadata “issue number” starting with “morning issue” on 31st Oct 2022 with no. 1 counting “per issue”, you will get the following individual issues generated:

31st Oct 2022
  - morning issue (issue number: 1)
  - noon issue (issue number: 2)
  - evening issue (issue number: 3)
1st Nov 2022
  - morning issue (issue number: 4)
  - noon issue (issue number: 5)
  - evening issue (issue number: 6)
2nd Nov 2022
  - morning issue (issue number: 7)
  - noon issue (issue number: 8)
  - evening issue (issue number: 9)
3rd Nov 2022
  - morning issue (issue number: 10)
  - noon issue (issue number: 11)
  - evening issue (issue number: 12)
4th Nov 2022
  - morning issue (issue number: 13)
  - noon issue (issue number: 14)
  - evening issue (issue number: 15)
5th Nov 2022
  - morning issue (issue number: 16)
  - noon issue (issue number: 17)
6th Nov 2022
  (no issues)

If you now mark the issues on 1st Nov as “not appeared” (the date 1st Nov 2022 will be added to the set exclusions of the issues), the following list is generated:

31st Oct 2022
  - morning issue (issue number: 1)
  - noon issue (issue number: 2)
  - evening issue (issue number: 3)
1st Nov 2022
  (no issue)
2nd Nov 2022
  - morning issue (issue number: 4)
  - noon issue (issue number: 5)
  - evening issue (issue number: 6)
3rd Nov 2022
  - morning issue (issue number: 7)
  - noon issue (issue number: 8)
  - evening issue (issue number: 9)
4th Nov 2022
  - morning issue (issue number: 10)
  - noon issue (issue number: 11)
  - evening issue (issue number: 12)
5th Nov 2022
  - morning issue (issue number: 13)
  - noon issue (issue number: 14)
6th Nov 2022
  (no issues)

Assuming that there is no existing print of noon issue on 3rd Nov to digitize and you remove it, you would get

31st Oct 2022
  - morning issue (issue number: 1)
  - noon issue (issue number: 2)
  - evening issue (issue number: 3)
1st Nov 2022
  (no issue)
2nd Nov 2022
  - morning issue (issue number: 4)
  - noon issue (issue number: 5)
  - evening issue (issue number: 6)
3rd Nov 2022
  - morning issue (issue number: 7)
  - evening issue (issue number: 8)
4th Nov 2022
  - morning issue (issue number: 9)
  - noon issue (issue number: 10)
  - evening issue (issue number: 11)
5th Nov 2022
  - morning issue (issue number: 12)
  - noon issue (issue number: 13)
6th Nov 2022
  (no issues)

The issue numbers are now wrong, as the number counting should fictitiously continue even for the issue that is missing. So you can redefine the counter on „evening issue“ of 3rd Nov back to 9. This will internally bind two CountableMetadata records to the block, one “issue number” starting on 1st Oct, morning issue with value 1, counting per issue, and ending on morning issue of 3rd Nov; and a second “issue number” starting on 3rd Nov “evening issue” with value 9, counting per issue. This is the reason why countable metadata can start on any issue of the day.

Expectation 1: Currently, there is no feature to bind a CountableMetadata only to specific issues, though this might make sense. For example, you have Edinburg issue only appearing once a day, but London issue appearing as morning issue and evening issue:

31st Oct 2022
  - London morning issue (issue number: 1)
  - Edinburgh issue (issue number: 1)
  - London evening issue (issue number: 2)
2nd Nov 2022
  - London morning issue (issue number: 3)
  - Edinburgh issue (issue number: 2)
  - London evening issue (issue number: 4)
3rd Nov 2022
  - London morning issue (issue number: 5)
  - Edinburgh issue (issue number: 3)
  - London evening issue (issue number: 6)
...

If you implement such a feature, please keep in mind that the metadata must be savable to, and restorable from the course.xml file, so you will need to define a clear way how to express these in the XML how several metadata with the same key are bound to issues or not.

[andre-hohmann]

@matthias-ronge : Thanks a lot for the comprehensive answer. It is more complicated than i assumed and it seems, that the existing functionality should not be changed.

I was rather looking for a solution to add a static titles or edition-labels to distinct the issues of one day, as for example:

• Morning edition
• Evening edition
• Special edition

In Kitodo.Production 2.x it was assigned automatically according to the value in the field "Ausgabe" during the creation of the processes of the issues.

Thus, it is necessary to add another button which enables the assignment of a label to all issues of one kind - for example "Morning edition".
The function of the existing button "add metadata" must not be changed. Only the label might be modified to express the difference of the functionalities.