Edit Item / Embargo - metadata local.embargo.termslift

[milanmajchrak]

Original issue: ufal#1054
Excel Notes: Embargo value will be loaded from the metadata _local.embargo.termslift_ exposed by the datacite_openaire.xsl crosswalk

2024/Apr/18:

• When the embargo is set up the dc.date.available is not removed
• v5 - termslift is assigned only for two Items: http://hdl.handle.net/11234/1-3498 and http://hdl.handle.net/11372/LRT-2729
• termslift metadata could be used like this:

#### Embargo Settings ####
# DC metadata field to hold the user-supplied embargo terms
embargo.field.terms = local.embargo.termslift

# DC metadata field to hold computed "lift date" of embargo
embargo.field.lift = local.embargo.termslift 

[kosarko]

menim dtq-label z jm-triage na ufal-showstopper.

z dnesni diskuse: potrebujeme embarga, implementace je druhotna (tj. klidne pomoci policies a ne local.embargo.termslift)

1. embarga by se nemela ztratit pri migraci
2. informace o embargu musi byt nejak dostupna oai crosswalkum. Napr. v datacite_openaire https://github.com/ufal/clarin-dspace/blob/d20cbdb420e7c7ac01bfea8e3285b4ffaff1c1ed/dspace/config/crosswalks/oai/metadataFormats/datacite_openaire.xsl#L151 se vyuziva

[milanmajchrak]

1. Hladal som aktivne embarga vo v5 a nenasiel som ziadne, hladal som to podla DB, kde je v resourcepolicy start_date != null
2. Termslift problem, nekonzistencia:

• ked nastavis embargo, tak sa ti zmeni READ policy s nejakym start_date (v7), predpokladam, ze takto to funguje aj vo v5 a taketo fungovanie je spravne.
• aktualne: termslift je nastavene len pre tieto Itemy: http://hdl.handle.net/11234/1-3498 and http://hdl.handle.net/11372/LRT-2729 , oba su withdrawn, lenze embargo nemaju nastavene na READ so start_date, ale maju WITHDRAWN_READ so start date. Dokonca som našiel Withdrawn Item, ktory ma embargo s WITHDRAWN_READ, ale nema termslift - http://hdl.handle.net/11234/1-4914

Chcem upravit OAI PMH crosswalk, tak aby embargo bralo z metadata, len teraz neviem, z ktorych a kedy. Ma zobrat embargo namiesto termslift, ak bitstream obsahuje policy READ so start_date a WITHDRAWN_READ so start_date? Alebo len jedno z toho? Ako sa mam zachovat pri tom Bitstreame, ktory ma WITHDRAWN_READ a nema termslift?

[milanmajchrak]

iba bitstreamy

[milanmajchrak]

@kosarko
Narazili sme na pár nejasností, tak by som ťa chcel poprosiť o viac info. Pýtame sa hlavne, lebo sme si neni istý, či to teraz vo v5 funguje správne a ako mate vyriešené tieto scenáre.

Embargo informácia sa získava z local.embargo.termslift a exposuje cez crosswalk datacite_openaire.xsl, kedy ak dc.date.available neobsahuje hodnotu, zoberie sa hodnota z metadat local.embargo.termslift (cas embarga).
Avsak pre ani jeden z tychto itemov vo v5 nie je po nastaveni embarga dc.date.available prazdne -> podmienka v datecite_openaire.xsl nebude nikdy hodnota z metadat local.embargo.termslift.

<xsl:when test="doc:metadata/doc:element[@name='dc']/doc:element[@name='date']/doc:element[@name='available']/doc:element/doc:field[@name='value']">
<date dateType="Available">
<xsl:value-of select="doc:metadata/doc:element[@name='dc']/doc:element[@name='date']/doc:element[@name='available']/doc:element/doc:field[@name='value']"/>
</date>
</xsl:when>
<xsl:otherwise>
<!-- empty available means embargo. item will be available on the embargo date -->
<date dateType="Available">
<xsl:value-of select="doc:metadata/doc:element[@name='local']/doc:element[@name='embargo']/doc:element[@name='termslift']/doc:element/doc:field[@name='value']"/>
</date>
</xsl:otherwise>

Vo v7 je mozne zvolit embargo na metadata (item) a bitstreamy itemu. Nepouziva sa local.embargo.termslift ale v resourcepolicy sa nadstavi start_date pre READ action.
Po predchodzej diskusi chceme, aby bolo embargo dostupné v datacite_openaire.xsl a vztahovalo sa len na bitstreamy.
Otázky:

1. Vo v7 sa po nastaveni embarga na metadata alebo bitstream dc.date.available nestrati, podmienka z datecite_openaire.xsl je neplatna (tak ako vo v5). Je v poriadku, ze hodnota v dc.date.available ostava zachovana?
   Ak sa skutočne nikdy nezoberie embargo hodnota z local.embargo.termslift. Navrhujeme úpravu, aby sa najskôr skontrolovalo embargo a až potom dc.date.available? (teda opacna kontrola)
2. Bolo povedane, ze mame brat do uvahy embarga nastavené na bitstream (READ policy so start date). Čo v prípade, ak ma item viac bitstreamov a embargo je nastavené len na jeden z nich?
   Ako mame potom v crosswalk vyhodnotit, že na cely item je nastavene embargo?
3. Embarga nastavené na metadata itemu (teda item) nemame v crosswalku brat do uvahy vobec?

[kosarko]

@milanmajchrak ono ve v5 to s tim embargem bylo/je o neco slozitejsi nez pises. Nevim, jestli je uplne ucelny to hledat do detailu...lehkej odhad o neco niz

K tomu jak to fungovalo, mimo jine i cast breaking changes ve v7 (z https://wiki.lyrasis.org/plugins/viewsource/viewpagesrc.action?pageId=315720591)

The "dc.date.available" field is no longer set by DSpace during submission. DSpace has had two fields which represented when an object was added/available in DSpace: "dc.date.accessioned" and "dc.date.available". The Accessioned Date (dc.date.accessioned) has always represented the date the object was deposited into DSpace, while the Available Date (dc.date.available) represented the date the object was first available (which may be later than the accessioned date if the item had an embargo).

Ja si myslim, ze se pri install itemu, nebo potom nejakym cli nebo cronjobem aktualizovalo dc.date.available na zaklade toho local.embargo.termslift fieldu. On ten termslift taky mohl byt neco relativniho jako 60 days a do date.available se pak ulozilo now() + 60days. Takze kdyz se na to divas zpetne, tak bych asi porovnaval dc.date.available a dc.date.accessioned, kdybych zjistoval, jestli na itemu embargo bylo nebo ne....potom by v tom xsl bylo to local.embargo.termslift spis fallback (nebo to fungovalo jeste malinko jinak, pripadne jak pises ty nefungovalo to - chces-li zacit hledat https://github.com/ufal/clarin-dspace/blob/d20cbdb420e7c7ac01bfea8e3285b4ffaff1c1ed/dspace-api/src/main/java/org/dspace/embargo/EmbargoManager.java#L35 )

K otazkam, vezmu to od konce:

Embarga nastavené na metadata itemu (teda item) nemame v crosswalku brat do uvahy vobec?

Pokud je embargo na metadata, tak to znamena, ze anonym nema prava cist metadata, ne? OAI by se melo indexovat v kontextu anonyma, takze by tenhle item proste nemelo oai dostat k indexovani, ne?

Čo v prípade, ak ma item viac bitstreamov a embargo je nastavené len na jeden z nich?

To bych doufal, ze nebude moc caste. Kazdopadne si myslim, ze by to v metadatech melo byt hlasene jako "embargoed". Cekal bych, ze jestli k tomu bude dochazet, tak to embargo bude na "hlavnim bitstreamu" (datech) a nebude treba na manualu. Takze bych asi nastavil Available podle start_date pro READ action, ktery je nejdal v budoucnosti?

Vo v7 sa po nastaveni embarga na metadata alebo bitstream dc.date.available nestrati

pouziva se ve vanilla dspace vubec jeste na neco? viz ten quote vys ohledne breaking changes. Vy to nekde v implementaci pouzivate? Co se tam nastavi pro novej item, pokud teda nema dc.date.available vubec?

Jak se chovaji policies, ktere maji start_date (uz) v minulosti, zustavaji v historii nadale? Jsme schopni za 10 let rict, tenhle item jsme prijali v tenhle den, ale bylo na nem embargo, takze realne byl k dispozici az od ... ?

[Paurikova2]

@kosarko
Zhrnutie:

• embargo je brane z resource policy - READ start_date
• ak je na item dane embargo, oai nema prava citat metadata (otestovane)
• ak je embargo na bitstreame itemu -> Teraz nadstavenie embarga podla start_date bitstreamu, ktory je najdalej v buducnosti.
• ukoncenie embarga - ukoncenie embarga bud nadstavenim end_date alebo vymazanim resource policy alebo prepisanim. Vznik embarga bude zaznamenavat metadata provenance (musime mergnut) -> sposob, akym bude mozne zistit, ci bolo na iteme/bitstreame v minulosti embargo

[Paurikova2]

@kosarko
Po vyriešení problému s embargo sme vykonali testy crosswalk pre openaire_data (formát, ktorý využíva informácie o embargu).
Existuje jedna položka (handle: 11234/1-3062), ktorej bitstream už bol zaregistrovaný s embargom (dátum začiatku: 2020-02-10).
Na základe toho je výsledok prechodu pre openaire_data pre "date available" tejto položky 2020-02-10T00:00:00Z.
Avšak požiadavka z lindat.mff.cz vrátila 2019-10-21T13:30:24Z, čo predstavuje metadáta dc.date.available.
(https://lindat.mff.cuni.cz/repository/oai/openaire_data?verb=GetRecord&metadataPrefix=oai_datacite&identifier=oai:lindat.mff.cuni.cz:11234/1-3062)
V našom testovacom prostredí má táto položka tiež metadáta dc.date.available, ale kvôli predchádzajúcej diskusii o embargu
je v súčasnosti táto sekcia vypočítaná na základe resource policy.
Skontrolovala som to v databáze v5 a skutočne existujú dve položky s resource policy pre "READ" na bitstreame s dátumom začiatku.
Prva je handle 11234/1-1659, kde sa dátum začiatku zhoduje s dc.date.available, takže tu nie je žiadna chyba pri testivaní.
Druhá je položka s handle 11234/1-3062, ktorú tu spomínam.
Na základe všetkého tohto môžeme považovať novú implementáciu embarga za správnu a problematický handle ignorovať?
Nová implementácia: Ak je na bitstreame itemu embargo, skontrolujte tiež či bolo ukončené; ak nie je embargo, použite dc.date.available. (dc.date.available sa po ukončení embarga neupdatuje, použije sa pre Available end_date resource policy)
Ak existuje viacero bitstreamov s embargom pripojeným k itemu, použite ten "najmladší v budúcnosti".

[kosarko]

@Paurikova2

Mně to chování (změna u 1-3062) přijde takhle v pořádku.

najmladší v budúcnosti

tzn. že pokud mám jeden bitstream s koncem embarga 2025-01-01 a druhej s 2026-01-01 použije se 2026?

Co bude u nových itemů, které nemají embargo? Stále tam bude dc.date.available? Viz můj předchozí dotaz na upstream změny...

[milanmajchrak]

@kosarko

1. Áno, použije sa ten 2026
2. V tejto verzii 7.6.1. bude stále dc.date.available, až od v8 nie je.
   Ak Item nema embargo (ma READ policy so start date) a ma dc.date.available, použije sa dc.date.available
   Ak item ma embargo a ma dc.date.available, použije sa embargo
   Ak item nema embargo a nema ani dc.date.available, vrati null

[milanmajchrak]

Merged and released