search

dataquest-dev / DSpace

(Official) The DSpace digital asset management system that powers your Institutional Repository
https://wiki.lyrasis.org/display/DSDOC7x/
BSD 3-Clause "New" or "Revised" License
1 stars 2 forks source link

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

Open milanmajchrak opened 10 months ago

milanmajchrak commented 10 months ago

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:

2024/Apr/18:

kosarko commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

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