dc.date.issued is removed and it is missing in crosswalks

[milanmajchrak]

Problem description

If the Item has local.approximateDate the dc.date.issued value is removed, because we do not want to store duplicate values in the metadata, but because of that the OAI cannot retrieve that value from dc.date.issued.

TODO:
Add first value from local.approximateDate.issued into dc.date.issued instead of removing it.

2024/Apr/17 call:

• maybe having unvalid characters like ???? in the data.issued causes some problem which OK is going to discover
• instead of removing dc.date.issued copy the value from the local.approximateDate.issued into it
• TODO: Update view in the Item View Page - do not show date if there is some value in the local.approximateDate.issued

2024/Apr/18:

• check conversation: dc.date.issued is removed and it is missing in crosswalks #461 (comment)

[kosarko]

nekolik poznamek obecne:

1. lindat repozitar ma dc.date.issued jako required field, takze pokud to smazes, budou ozyvat ruzny metadata QA checky, ze jim chybi required field
2. Duvod pro local.approximateDate.issued byl, ze ty hodnoty, ktery jsme dostaly, nesly nacpat do dc.date.issued. Ve verzi 5 nemohlo byt dc.date.issued repeatable plus v nejakej moment prochazi tridou DCDate, ktera vynucuje nejakej konkretni format. Tahle trida je stale i ve v7 (https://github.com/dataquest-dev/DSpace/blob/dtq-dev/dspace-api/src/main/java/org/dspace/content/DCDate.java), takze bych si myslel, ze tenhle problem tam bude i nadale.
3. Najdes itemy, ktery maj jak local.approximateDate.issued tak dc.date.issued (ktery neni 0000) (viz text niz)

---

Jestli teda neni jednodussi dc.date.issued nemazat a v simple item view udelat jednom nejaky if-elif-else po vzoru https://github.com/ufal/clarin-dspace/pull/1002/files#diff-f753de4ed7a4c41cdfddc7bc8b2c13ebec6c67498893fb406dbf0bfa7708f3d8R1297. Ono to neni nic peknyho, tak jestli vidis nejakou lepsi cestu...

Metadata v repozitari u tech dotcenych kolekci jsou merge xml exportu a rucne vytvoreneho spreadsheetu. Nasleduje nejaka historicka komunikace, jak se k tomu stavu doslo ( a na konci pak prave odkazy na nekolik ruznejch stavu).

u cca 60 zaznamu se lisi datum ktere je v tabulce a to ktere dostanu z xml metadat (bud z pole ROK-VYROBY-SOTU nebo DAT-VYROBY-SOTU).
Napr. pro 3901492-06 je v xml ROK-VYROBY-SOTU 1938 a v tabulce je "1923, 1926, 1938".

Tam mam ponechat to "presnejsi" z xml? Nebo mam u vseho pouzit ty hodnoty z tabulky.

prosím ponechat všechna data z tabulky Lindat (některé šoty jsou sestaveny
z více záznamů, pořízených v různých letech to je uvedeno právě tím "1923,
1926, 1938" - systém AIS bohužel neumožňuje všechny zapsat).
Roky, které jsou odděleny čárkou, znamenají, že se točilo v ty konkrétní
roky. Roky, které mají uprostřed pomlčku, znamenají, že nevíme, kdy přesně
se natáčení uskutečnilo, ale mohlo být realizováno v uvedeném časovém
rozmezí.

metadata v repozitari jsou aktualizovana.
V podstate je to resene tak, ze se pridalo nove pole, ve kterem se drzi onen rozsah rozsah (nebo seznam) roku.
Hodnota toho noveho pole se zobrazi uzivatelum namisto hodnoty z dc.date.issued. Zaroven je to momentalne jenom na te urovni zobrazeni. To znamena, ze napr. do exportu v oai_dc se ty rozsahy nedostanou a bude tam dc.date.issued odvozene z xml (tj. bud jeden rok, nebo 0000).
Pole dc.date.issued je v systemu lehce specialni a nejde to lehce rozsirit na rozsahy nebo seznamy. Zaroven mi ale prislo uzitecne tu informaci aspon nejak zobrazit.
Jeste nekolik poznamek:
V pripade, ze v tabulce bylo datum ve formatu rrrr nove pole se nepridavalo, ale zmenila se hodnota v dc.date.issued.
U nekolika zaznamu se tak zmenil i "rozumny rok" (neco jineho nez 0000). V nasledujicim je leva strana "!=" z xml, prava z tabulky. V repozitari je hodnota prave strany
WARN: 3901485-01 1934 != 1942
WARN: 3901489-04 1939 != 1938
WARN: 3901491-14 1956 != 1949
WARN: 3901499-08 1928 != 1930
WARN: 3901505-17 1928 != 1930

Nove pole nepribylo take u nasledujicich zaznamu, opet se jenom aktualizovalo dc.date.issued:
INFO: 3901472-15 updating 0000 to 1926
INFO: 3901473-04 updating 0000 to 1931
INFO: 3901473-09 updating 0000 to 1947
INFO: 3901474-24 updating 0000 to 1930
INFO: 3901480-06 updating 0000 to 1929
INFO: 3901484-20 updating 0000 to 1926
INFO: 3901485-09 updating 0000 to 1945
INFO: 3901486-15 updating 0000 to 1928
INFO: 3901487-21 updating 0000 to 1957
INFO: 3901494-02 updating 0000 to 1955
INFO: 3901495-02 updating 0000 to 1935
INFO: 3901496-11 updating 0000 to 1922
INFO: 3901735-05 updating 0000 to 1918
INFO: 3901735-06 updating 0000 to 1935
INFO: 3901498-11 updating 0000 to 1931
INFO: 3901501-11 updating 0000 to 1930
INFO: 3901501-16 updating 0000 to 1937
INFO: 3901503-22 updating 0000 to 1930
INFO: 3901505-16 updating 0000 to 1938
INFO: 3901507-10 updating 0000 to 1928
INFO: 3901035-03 updating 0000 to 1929
INFO: 3901036-30 updating 0000 to 1912

U vsech ostatnich zaznamu pribylo nove pole.
Konkretne nekolik prikladu:
http://hdl.handle.net/20.500.12801/3901492-06
ma dc.date.issued (1938), ale zobrazuje se seznam 3 roku.

http://hdl.handle.net/20.500.12801/3901735-22
ma dc.date.issued (0000), ale zobrazuje se rozsah.

http://hdl.handle.net/20.500.12801/3901735-06
ma jenom dc.date.issued (1935 misto puvodni 0000)

[milanmajchrak]

@kosarko Ďakujem za info.

1. Suhlasim, neskôr by to mohlo spôsobiť ďalší problem
2. Neviem prečo tento error nevyskakoval vo v7
3. Takže, ak su v local.approximateDate.issued normalne hodnoty napr: 1938, 1932, 1945, tak do dc.date.issued da najvyssi datum 1945.

Upravim to tak, že sa dc.date.issued nebude mazať a na FE bude nejake IF, ktore spravne zobrazi datum.

[kosarko]

@milanmajchrak

Takže, ak su v local.approximateDate.issued normalne hodnoty napr: 1938, 1932, 1945, tak do dc.date.issued da najvyssi datum 1945.
To ale jenom pokud je dc.date.issued 0000?

[milanmajchrak]

@milanmajchrak

Takže, ak su v local.approximateDate.issued normalne hodnoty napr: 1938, 1932, 1945, tak do dc.date.issued da najvyssi datum 1945.
To ale jenom pokud je dc.date.issued 0000?

Áno, dobrá poznámka.