Automatická aktualizace bibliografických záznamů při jejich změně v knihovním systému

[zabak]

Měla by existovat možnost automaticky aktualizovat bibliografické záznamy v Krameriu když se změní v knihovním systému. Podobně funguje např. Polona. Z hlediska uložení záznámů v LTP by to nemělo vadit, protože LTP není autoritativním zdrojem bibliografických záznamů. Umožnilo by to mj. udržet aktuální informace z Národních autorit apod.

[luckajirku]

Ve kterém knihovním systému? V tom, odkud pochází původní záznam?

[zabak]

Ano - mohlo by to fungovat podobně jako Aleph Cluster - Kramerius nastaví proti jednomu knihovnímu systému a v/u záznamu bude uložen identifikátor báze a id (sysno v případě Alephu) a je na správci, jestli "propojí" se svým katalogem i replikované záznamy tím, že nahradí nebo doplní ten identifikátor. Zároveň by to vyřešilo problém přes co linkovat, diskutovaný v #15.

[luckajirku]

Nedovedu si to prakticky představit. Jednalo by se o jakoukoli změnu v záznamu, nebo by to sledovalo jen předem definovaný výběr konkrétních polí? U možnosti dát správci možnost přepsat metadata u replikovaných dokumentů bych byla opatrná. Jestliže digitalizující knihovna dělá v rámci přípravy na dig poctivou rekatalogizaci s knihou v ruce (jasně, neděje se to všude, ale mělo by), má metadata v cajku a jistým způsobem za jejich správnost ručí. Někdo si titul zreplikuje a jeho systém mu to přepíše ne tak dokonalými daty z vlastního katalogu nebo SKC, přitom stále pod tím bude "podepsaná" původní knihovna, to moc smysl nedává, ne? Další věc - živá periodika, kde se začalo s digitalizací, když byl záznam v aacr. Tak je to v Krameriovi, později se záznam předělal podle rda - tam najednou budou trochu jiná pole, takže nepůjde jen čistě přepsat obsah.

[JanMeritus]

Toto je podla mna zasadna vec. Kazdopadne je procesna otazka ako k tomu pristupit. Ako @luckajirku pise zaznamy u starsej digi boli casto v podstate rekatalogizovane. U toho mame skusenosti i u nas. V pripade ze vnimame Kramerius rovnako ako katalog, bude treba vyriesit synchronizaciu medzi:

1. nim a hlavnym katalogom jeho knihovne, ale nie jednosmerne, ale obojsmerne.

2. medzi nimi a SKC.

3. Poliakom to umoznuje architektura Polony a aj struktura ich dlhodobeho ulozista, kde, ako som to navnimal, je extremne jednoduche editovat len metadata a zaroven to synchronizovat s LTP

[zabak]

V případě replikací by to bylo na knihovně samotné - buď si to propojí nebo ne. Ve vazbě na diskusi v #15 by asi mělo smysl mít tam samostatný indikátor toho, jestli má být záznam aktualizován nebo ne. Co se periodik týče, nebo obecně - měnil by se celý záznam (a přeindexoval), takže tam problém nevidím. Pro kontrolu by se mohlo zjišťovat, jestli nedošlo ke změně názvu, což by mohlo indikovat nějaký radikálnější zásah do záznamu, který by zasloužil určitou kontrolu.

[luckajirku]

Další věc, co mě napadá, jak by si to poradilo s vícedílkami, které jak víme, jsou v NDK standardu zatím definované blbě a proti katalogizačním pravidlům. V Alephu je popis na úrovni titulu, kdežto u digi objektů je popis na úrovni titulu těžce osekaný a plný je až na úrovni svazků, jenomže tam jsou zase v každém jen údaje toho konkrétního svazku.

[zabak]

@JanMeritus obousměrná aktualizace si myslím že není moc reálná. Dokážu si ji ale velmi dobře představit na úrovni procesů - tj. pokud mám potřebu záznam upravit, provedu úpravu v Alephu a ona se mi přenese do Krameria. U složitějších případů bude muset nastoupit třeba i strukturální změna v datech v jednom nebo obou systémech (vícesvazky apod.) ale to už je na ruční práci.

[luckajirku]

Jinak z obousměrné by v nejedné knihovně nebyli nadšeni ani katalogizátoři, a vcelku i právem.

[luckajirku]

V případě replikací by to bylo na knihovně samotné - buď si to propojí nebo ne. Ve vazbě na diskusi v #15 by asi mělo smysl mít tam samostatný indikátor toho, jestli má být záznam aktualizován nebo ne.

Ale tady myslím, že by knihovna, která objekt vytvořila, měla mít možnost nepovolit replikujícím knihovnám aktualizaci podle jiného katalogu.

[luckajirku]

Pak můžou být další případy... Třeba jsme digitalizovali pro menší knihovny, od kterých nešlo stahovat přímo z jejich katalogu. Záznamy měli čerstvě po RK, do SKC se jim ne vždy povedlo protlačit všechny informace, resp. přepsat ten původní záznam, tenhle záznam z SKC jsme stáhli do ProArcu a pak podle jejich katalogu upravovali, aby tam bylo vše a správně. Neříkám, že je to celé špatně, jen že je třeba si uvědomit, že ne vždy budou AUTOMATICKÉ opravy žádoucí a prospěšné. A co si už vůbec nedovedu představit, je pak třeba sklízení x verzí toho samého zreplikovaného titulu do ČDK...

[godnat]

Dobrý den, Za Oddělení standardů NK chápeme potřebu provádění oprav u dat a o, že se to aktuálně děje příliš pomalu. Ale LTP úložiště by měl být hlavní a autoritní zdroj dat, jinak dle našeho názoru existuje riziko narušení systému, kdy budou kolovat různé kopie jednoho dokumentu a kdo bude ručit za jejich autenticitu. V případě havárie Krameria musí být možné z LTP obnovit jeho obsah. To při jakýchkoliv úpravách jen v Krameriovi nebude možné. Záleží také o jaká bibliografická metadata by se jednalo- v případě údajů např. věcného popisu by se o aktualizaci v Krameriovi asi i dalo uvažovat- aktuální údaje tedy LTP mít nebude a z hlediska dlouhodobé správy tedy související operace s těmito daty nebudou možné. Ale údaje jako např. rok vydání, číslo periodika, autor, název díla je zásadní změna-jsou to údaje, které slouží k identifikaci díla a potřebuje je i správce LTP. Jak píše @luckajirku mělo by se důsledně dbát na katalogizaci a zevrubnou kontrolu záznamu před samotnou digitalizací.
Je třeba také připomenout resolver a Metodiku přidělování URN:NBN, kde se uvádí, že změny v signifikantních údajích je třeba řešit novým přidělením URN:NBN. Nemělo by dojít k rozpadu jednoty. Záznam v resolveru nesmí odkazovat na něco, co se tváří jako něco jiného. Tedy v případě zásadnější změny je dle našeho názoru vždy třeba jít přes LTP.

[JanMeritus]

Osobne si myslim ze autorita by mala byt SKC a nemal by sa obchadzat. @zabak mas pravdu, uprava asi jednosmerna, tj z loc. Kat do SKC a z neho jednotlivych zaznamov. V NK vieme podla pripadnych poziadavkov doplnit API na mieru. URN:NBN a Resolver som spominal v ceskaexpedice/kramerius-web-client#217

Neviem ale ci by sa o tom malo hlasovat takto narychlo, vyzera ze tema je zlozite na jednu issue, siaha do standardov, registrov, identifikacnych cisiel a systemovych otazok. Idealne by bolo dobre k nemu mat samostatnu poradu a riesit jeho vyvoj az bude konsenzus v dalsom Q.

@godnat mate aj stanovisko k previazaniu katalogovych zmien cisto v Alephu (nezavislo na vyvoji Krameria) a LTP?

PPS V pripade havarie u velkej instancie, je samozrejme LTP posledna moznost z ktorej to obnovovat, ktora by v praxi ale pri sucasnych podmienkach trvala roky.

[zabak]

Ale tady myslím, že by knihovna, která objekt vytvořila, měla mít možnost nepovolit replikujícím knihovnám aktualizaci podle jiného katalogu. @luckajirku Tohle bych nechal na knihovně, která si dokument zreplikovala, jinak si stejně nejakou cestu najdou a ten blok obejdou, když budou tu potřebu cítit. Stejně je možné že význam replikací výrazně poklesne po zprovoznění DNNT.

[zabak]

@luckajirku V případě menších knihoven (taky ty případy máme) kdy záznam vznikl jinak než kopií z katalogu by bylo možné kdykoli takové propojení zřídit a aktivovat. Ale reálně se to dít asi často nebude. Ta aktualizace nebude moci být povinná, to asi nebude nikdy možné, vždy budou výjimky.

[zabak]

@luckajirku Co se importu do ČDK týče, měli bychom dosáhnout toho, že se zpětně sjednotí uuid na úrovni titulu. U nových replikací si myslím, že by problémy nemusely nastávat, problém bude hlavně migrace z Krameria 3 NK u periodik, které jsou už i v jiných Krameriích - jinými slovy, tento problém už máme.

[filak]

Tak tohle je rozhodně netriviální problematika. Osobně se domnívám, že aktualizace biblio metadat by měla být odpovědností producenta dat - knihovny - na úrovni lokální instance Krameria.

Jde hlavně o to, aby byla pro toto podpora na straně Krameria-Admin modulu a to zejména:

• stažení Marc21 přes OAI-PMH na základě lokálního identifikátoru - local identifier z MODS nebo zádání identifikátoru ručně, pokud v MODS není

• konverze staženého Marc21 na MODS s použitím aktuálního XSLT (lokální soubor v instanci Krameria), případně další streamy jako DC atd...

• update příslušného objektu v Krameriovi-Fedoře

• reindexace příslušného objektu bez nutnosti reindexovat celý titul znovu

Každopádně by bylo také třeba zapojit ProArc - tedy umožnit provést obdobnou operaci v ProArcu a pak propagovat změny v biblio metadatech do Krameria.

Aktualizace nadstavbových Krameriů by pak už mohla být automatická.

[zabak]

@godnat Měli bychom oddělit informace pocházející z knihovního systému a informace vzniklé během digitalizace. @JanMeritus na to upozorňuje - v Alephu ty změny vznikají stejně. A pro bibliografické záznamy je Aleph zdrojem a v případě katastrofického selhání se Aleph musí obnovit z vlastních záloh jako celek - a bylo by tedy posléze možné metadata z Alephu znovu aktualizovat i v Krameriu.
Jiná věc jsou strukturální změny (např. vícesvazky) nebo změny metadat specifických pro stránku, číslo, ročník apod. Tam je nezbytné provedené změny mít i v LTP.

Bibliografická metadata jsou používána uživateli pro vyhledávání, je proto vhodné je mít aktuální. Týká se to i změn na úrovni autorit a Z hlediska LTP ale je možná i z důvodů uváděných @godnat lepší ponechat v LTP záznam v podobě, v jaké byl v době digitalizace. Na druhou stranu nic asi nebrání tomu, aby se do LTP v nějaké podobě pravidelně archivovala celá bibliografická báze, kdyby na to přišlo.

Z obecného hlediska vidím v současnosti největší problém v autoritách (úplná absence unikátních identifikátorů autority v záznamech a tím i jejich neaktuálnost a neaktualizovatelnost).

[zabak]

@JanMeritus to že to teď odhlasujeme neznamená, že se to musí okamžitě začít dělat, nejprve bude nutné udělat detailní analýzu atd. Ale pokud víme, že se to bude dělat, tak je silná motivace to rychle domluvit a dotáhnout.

[pavluska]

Zdravím, tohle téma je teoreticky velice zajímavé, ale v praxi to přinese víc problémů než užitku. Obávám se, že tady ani velmi silná motivace nepomůže :) Stačí mi, když teď procházím periodika, která jsou v Krameriu MZK - čili spojená z MZK a NK. Bez problému je tak jedno z pěti.

Jenom nástřel problémů: a) periodikum vůbec nemáme v katalogu, protože ho má jen NK b) v NK je to periodikum a v MZK monografie (a naopak) c) netýká se jen bibl. metadat, ale i strukturálních - často je periodikum jinak rozdělené v MZK a v NK (myslím tím, že v jedné knihovně vyhodnotili jinak změnu názvu než v jiné, takže někde jsou všechny ročníky pod jedním záznamem, jinde jsou na dvou i více záznamech), někdy dokonce víc záznamů v jedné knihovně k jednomu periodiku d) reálně se prostě z konvertovaného záznamu před importem do Krameria některé informace mažou a některé přidávají e) to jako že ty věci, které jsme několik let opravovali, aby třeba fazety vypadaly hezky, mi najednou někdo dávkově změní zpátky na ten bordel, co tam byl předtím???!!! to je na facana :)

A to je opravdu jen nástřel, co mě tady mezi řevem dvou dětí napadl. Bude toho mnohem mnohem víc... nedejbože brát jako bernou minci souborný katalog... ale nevím, možná se za těch 5 let zázračně opravila data ve všech katalozích a já jsem zbytečně skeptická :)

[zabak]

@pavluska proto by tam musel být příznak který tu aktualizaci zapíná nebo vypíná. A zrovna u periodik přebíraných z jiné knihovny se dá logicky čekat nejvíc problémů. Na druhou stranu je tam ještě větší množství věcí, které problematické nejsou, jsou jen ne zcela aktuální. A jeden z důvodů, proč se úpravy v záznamech dělají před importem je to, že víme, že pak už není možné je změnit jen opravou v Alephu. Což by jinak zrovna u faset obvykle šlo, navíc fasety máme i v katalogu. Čím víc se ty databáze začnou rozcházet, tím horší to bude, proto musíme dostat procesy do takové podoby, aby se záznamy opravovaly pokud možno jen na jednom místě.

[pavelkocourek]

celkem zaujate tuhle diskuzi sleduju :) Problém jde napříč aplikacemi.

Vychází mi z toho zatím, že by Kramerius (pravděpodobně v kombinaci s novým ProArcem) měl dokázat aktualizovat (možná i porovnat) záznam/y podané v jednotném formátu a na druhé straně umět podat svůj záznam/y třeba prostřednictvím webové služby.

[luckajirku]

@zabak Tohle bych nechal na knihovně, která si dokument zreplikovala, jinak si stejně nejakou cestu najdou a ten blok obejdou, když budou tu potřebu cítit. Stejně je možné že význam replikací výrazně poklesne po zprovoznění DNNT.

Tak já bych to zas úplně na té knihovně nenechávala. Ale ok, to se dá vyřešit podmínkou v replikační smlouvě.

[luckajirku]

d) reálně se prostě z konvertovaného záznamu před importem do Krameria některé informace mažou a některé přidávají

A tohle není problém jen periodik, ale i monografií - ať už to jsou informace o přívazcích, přebytečné sedmistovky (když je ve svazku víc děl od stejného autora), u záznamů stahovaných z SKC přebytečné 910 atp. Mně tak trochu přijde, že je tu na jednu stranu nadšení z dnešních technických možností a nápady, co všechno by se dalo, když to teda jde, ale nebere se dost v potaz, jak skutečně ty procesy od přípravy, rekatalogizace přes metadatový popis v praxi probíhají a s čím vším každá relativní drobnost souvisí...

[zabak]

@luckajirku

Tak já bych to zas úplně na té knihovně nenechávala. Ale ok, to se dá vyřešit podmínkou v replikační smlouvě.

To je myslím ještě podstatně horší cesta. Znamenalo by to mj. mít u každého zreplikovaného bibliografického záznamu poměrně detailní metadata o tom, která pole a atributy je a není na základě replikační smlouvy možné měnit (protože co smlouva to jiná omezení, dodatky apod.)

[luckajirku]

@zabak takhle komplikovaně na úroveň polí atp. jsem to nemyslela. Prostě chceš si zreplikovat náš dokument?, OK, ale bez jakýchkoli modifikací - ber nebo nech být.

[zabak]

@luckajirku Což o to, ale právě jsem dostal zákaz dělat tam opravy, doskenování chybějících věcí... pak uplyne třeba 20 let. Takových periodik mám najednou desítky, možná stovky. Pracují tu už úplně jiní lidé. Bude si ještě někdo pamatovat, že někde hluboko v archivu instituce je založená replikační smlouva která má takové speciální klauzule?

[luckajirku]

@zabak pokud budeš chtít opravovat, doskenovávat, tak bych se nejdřív obrátila na tu instituci, odkud to pochází. Prostě automatický přepis v jakékoli instalaci krameria a následný vznik x verzí téhož je nesmysl.

[zabak]

@luckajirku Jenže v případě digitalizací třeba z VISK7 se obrátíš na koho? Bohužel už teď existují minimálně dvě verze - jedna v NK a druhá v dané instituci, každá má pravděpodobně jiné uuid. Pokud se to replikovalo ještě v K3, tak jich bude i víc. Ale myslím, že už jsme příliš utekli od původního issue :-)

[luckajirku]

@zabak Nemyslím, že jsme až tak utekli. Ale pokud se vrátíme k původní myšlence - tak prostě je velký rozdíl mezi požadavkem "AUTOMATICKY aktualizovat bibliografické záznamy v Krameriu, KDYŽ SE ZMĚNÍ v knihovním systému" a "dát adminům možnost v NUTNÝCH případech přepsat metadata přímo v Krameriovi stažením aktuálního záznamu z katalogu".

[svetlym]

V Městské knihovně v Praze aktualizovat záznamy v Proarcu nebo Kramériovi z knihovního katalogu v dohledné době určitě nebudeme, protože v Proarcu máme úplnější záznamy než v knihovním systému, takže bychom tím degradovali kvalitu metadat.

Pokud tedy bude tato funkcionalita implementována, rozhodně by se měla zapínat v konfiguraci.