Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of seasons does not work porperly #3637

Closed
andre-hohmann opened this issue May 18, 2020 · 8 comments · Fixed by #3740
Closed

Implementation of seasons does not work porperly #3637

andre-hohmann opened this issue May 18, 2020 · 8 comments · Fixed by #3740

Comments

@andre-hohmann
Copy link
Collaborator

Problem

For seasons, it is necessary, that the process of issues are assigned to the year-element according to the beginning of the season. This is not January, but usually August or September.

If the beginning of the season is defined as 01.09. the ORDERLABEL is generated formally correctly, as for example:

  • ORDERLABEL="1850/1851"
    Thus, it seems as if seasons are recognized generally.

The allocation of the issues to the year is not working properly, as it works according to newspaper issues, for example:

  • issues 1850-09 ... 1850-12 are assigned to 1850/1851
  • issues 1851-01 ... 1850-08 are assigned to 1851/1852

All issues should be assigned to 1850/1851

Solution

Seasons must be depicted correctly in the METS-files.

Examples

Examples 3.x

Click to show the exported METS-File:
	<mets:structMap TYPE="LOGICAL">
		<mets:div ID="uuid-5de5945d-20f5-4922-813e-0a1d0774978c" TYPE="ephemera">
			<mets:mptr xlink:href="https://digital.slub-dresden.de/data/kitodo/DresKr_880547324/DresKr_880547324.xml" LOCTYPE="URL"/>
			<mets:div ID="uuid-dbdb91bc-b656-47ff-8efb-47eabcef2b72" ADMID="uuid-6a39df4f-0586-3dc9-9f59-8b2e9e36d241 uuid-7da4106a-c76a-3d74-a279-ea86ebd8cb4b uuid-e36c8498-19fb-37ba-8833-8ff4e58da764" TYPE="year" ORDER="1" ORDERLABEL="1850/1851">
				<mets:div ID="uuid-44e7b95a-d988-4d18-9556-d54d552d1a6b" TYPE="month" ORDER="1" ORDERLABEL="1850-09">
					<mets:div ID="uuid-adb1fc69-ea95-457b-889d-e3f8154f84e2" TYPE="day" ORDER="1" ORDERLABEL="1850-09-02"/>
				</mets:div>
				<mets:div ID="uuid-9f5442d8-5881-4711-b9ea-16c7674482ba" TYPE="month" ORDER="1" ORDERLABEL="1850-10">
					<mets:div ID="uuid-bdedbdaf-393d-44ad-abc4-86501df45ab4" TYPE="day" ORDER="1" ORDERLABEL="1850-10-04"/>
				</mets:div>
				<mets:div ID="uuid-4dbf142d-cb1e-4576-a72d-83a06bc8b5be" TYPE="month" ORDER="1" ORDERLABEL="1850-11">
					<mets:div ID="uuid-42d7b08d-87b3-426c-97cf-733900130a49" TYPE="day" ORDER="1" ORDERLABEL="1850-11-01"/>
				</mets:div>
				<mets:div ID="uuid-73762e23-d45b-4dfa-adec-620964897beb" TYPE="month" ORDER="1" ORDERLABEL="1850-12">
					<mets:div ID="uuid-a7197320-1641-45cf-8d5c-3f9c90857a65" TYPE="day" ORDER="1" ORDERLABEL="1850-12-09"/>
					<mets:div ID="uuid-389ab394-935e-4fc9-919b-c58b1231ea20" TYPE="day" ORDER="1" ORDERLABEL="1850-12-18"/>
				</mets:div>
			</mets:div>
		</mets:div>
	</mets:structMap>
Click to show the exported METS-File:
	<mets:structMap TYPE="LOGICAL">
		<mets:div ID="uuid-719d716e-8dc0-462d-a5b2-b29c250df0a1" TYPE="ephemera">
			<mets:mptr xlink:href="https://digital.slub-dresden.de/data/kitodo/DresKr_880547324/DresKr_880547324.xml" LOCTYPE="URL"/>
			<mets:div ID="uuid-58b5718d-1729-4644-80a7-86ec312abb02" ADMID="uuid-c0cbe782-0538-3f53-9729-6528dc5d65a3 uuid-8881f9f5-374e-350e-8408-e49c5e5dc8ae uuid-e0506efa-dd88-3cb3-b86e-665544e2953d" TYPE="year" ORDER="1" ORDERLABEL="1851/1852">
				<mets:div ID="uuid-14430bd5-f5a0-42ee-95a9-444a0a999f27" TYPE="month" ORDER="1" ORDERLABEL="1851-01">
					<mets:div ID="uuid-cd659ff5-d8d9-495b-9001-3fd58cb47d99" TYPE="day" ORDER="1" ORDERLABEL="1851-01-09"/>
				</mets:div>
				<mets:div ID="uuid-1270ef26-833f-4e42-8c75-fe1d1d3e36f2" TYPE="month" ORDER="1" ORDERLABEL="1851-02">
					<mets:div ID="uuid-6b00b4ba-bf0b-40b5-a0ae-db639f6c5437" TYPE="day" ORDER="1" ORDERLABEL="1851-02-05"/>
				</mets:div>
				<mets:div ID="uuid-f49bbb43-7da3-4ff4-826d-473a78e598dc" TYPE="month" ORDER="1" ORDERLABEL="1851-04">
					<mets:div ID="uuid-3fbdab23-1846-436d-8698-c79729726e2e" TYPE="day" ORDER="1" ORDERLABEL="1851-04-09"/>
				</mets:div>
				<mets:div ID="uuid-ee0f5ea0-a251-44a0-804e-0b5945c7d2e4" TYPE="month" ORDER="1" ORDERLABEL="1851-06">
					<mets:div ID="uuid-56f5ec28-7e80-49a0-a5e2-d97cd5960390" TYPE="day" ORDER="1" ORDERLABEL="1851-06-04"/>
				</mets:div>
				<mets:div ID="uuid-d93c506c-db82-491e-b90c-bdb3821f40fa" TYPE="month" ORDER="1" ORDERLABEL="1851-08">
					<mets:div ID="uuid-6f19c434-5d8d-43d3-a0b1-80954646bf40" TYPE="day" ORDER="1" ORDERLABEL="1851-08-08"/>
				</mets:div>
			</mets:div>
		</mets:div>
	</mets:structMap>

Examples 2.x

@matthias-ronge
Copy link
Collaborator

Test #3740 shows that this basically works. We can safely remove the blocking label, I think.

@andre-hohmann
Copy link
Collaborator Author

@matthias-ronge: Can you confirm that you can still create processes for seasons? If so, could you tell me the Kitodo version you apply?
You do not need to analyse this in detail - i would help me a lot, if i knew if it is "my fault" or if the functionality is currently not available.

In case you need information, here is a summary of what i do and the result of it.
I apply the following values:

  • von: 01.08.1879
  • bis: 30.06.1880
  • Erster Tag des Jahres: 01.08

Result:

  • Processes 01.08.1879 and 02.08.1879 are assigned to year 1879
  • Processes 30.06.1880 is assigned to year 1880
  • ORDERLABEL 1879: 1879/1880
  • ORDERLABEL 1880: 1880/1881

Thus, the seasons are applied in ORDERLABEL, but the processes are not assigned to the correct year-process.

@matthias-ronge
Copy link
Collaborator

I don’t use that feature, so I can’t tell right away. Needs testing, but sounds like a bug. I reopen this issue

@andre-hohmann
Copy link
Collaborator Author

@matthias-ronge : Thanks a lot!
I am sure, that it worked in 2020, otherwise i would have protested to close the issue.

@matthias-ronge
Copy link
Collaborator

May be related to #4824

@andre-hohmann
Copy link
Collaborator Author

@matthias-ronge : Thanks for the hint it leads to issue

Maybe the correction of that issue leads to the loss of functionality to create seasons correctly. Unfortunately, i cannot find out, how the problem in #4363 was solved.

Can you confirm, that the seasons cannot be created correctly? Just to make sure that the reason is our configuration.

@matthias-ronge
Copy link
Collaborator

@andre-hohmann Are you aware of #3741?

Cite:
In version 3, the beginning of the year must be defined in the ruleset.

<division id="Season">
    <label>season</label>
    <subdivisionByDate yearBegin="--07-01">
    …

In addition, a button for setting the start of the year exists in the calendar editor.

Screenshot 1

→ The beginning of the year must be entered exactly equal to the setting in the rule set, or processes with the wrong substructure are created.

@andre-hohmann
Copy link
Collaborator Author

@matthias-ronge : No, i wasn't. But that seems to be the solution - thanks a lot!

I added the "documentation" label to #3741 and close the comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants