Proces plnenia pomocnej databázy K+

[bodnarIQ]

Akým spôsobom bude prebiehať plnenie databázy K+ ?

V K+ vystavíme API, cez ktoré budú administrátori systému schopný vybrať publikáciu/sadu publikácií do K+. V tomto kroku dôjde nahratiu základných dát z K do K+ (hlavne textový obsah OCR). Obohatenie publikácií metadátami z externých služieb(UdPipe, NameTag, ...) bude prebiehať buď už pri napĺňaní(API može príjmať parametre pre určenie, akými službami chceme dáta obohatiť už pri prvotnom napĺňaní) a taktiež bude vystavené samostatné API pre obohatenie/znovu obohatenie v neskorších fázach pre publikácie už obsiahnuté v K+.

Akým spôsobom ale administrátor systému vyberie, ktoré publikácie chce takto dostať do K+?

1. Pošle v API dotaze parameter ID publikácie, a K+ si cez API Krameriusu stiahne vybranú publikáciu.
2. Pošle v API dotaze parameter zoznam ID publikácií, K+ si cez API Krameriusu stiahne sadu publikácií.
   • pre obe tieto možnosti budeme potrebovať vystaviť API v Krameriuse pre stiahnutie publikácie
3. Pošle v API dotaze celý objekt publikácie - neefektívne, vysoká chybovosť
4. Bude vystavené v K+ aj API pre automatické hromadné sťahovanie (niečo ako "stiahnutie celého obsahu z K" s možnosťami nejakých filtrov, ako napríklad "publikácie typy monografie s počtom stránok < 100" pre nejaké systematické, postupné napĺňanie v neskorších fázach). Pre fungovanie takéhoto API bude musieť K+ volať API K, ktoré na to bude musieť byť pripravené.

Prvé dva body sú vhodné pre manuálne napĺňanie, pravdepodobne využité iba vo fázach testovania, prípadne pre dodatočné doplnenie nejakého obsahu, ale pri množstve publikácií v K potrebujeme aj nejaký automatický spôsob napĺňania.

Prosím o doplnenie prípadne opravu, ak sú niektoré body zle, alebo ak si plnenie DB K+ predstavujete inak.

[bodnarIQ]

Z dokumentacie Krameriusu vidim vystavene API pre ziskanie FOXML suboru podla UUID(bod č. 1 vyššie), wiki ale popisuje API krameriusu v4.6, bude API pre K7 zhodné?

[bukovskyIQ]

@MLhotak

[bukovskyIQ]

Zdravíme, potřebovali bychom vaši součinnost při tomto issue. @MLhotak @zabak @JanMeritus

[JanMeritus]

@bodnarIQ podobny ukol sme riesili v inej suvislosti a mame to osetreno nasledovne: C. 2, je na uvod idealne, bohuzel pro produkci je to znacne nevhodne. C4 nasledne. Urcite neresit primym preposilanim dat.

Je otazne kdo s tim bude moci operovat, pokud by to meli byt jenom admini staci fakt neco minimalistickeho, napr API. Treba rovnez pocitat s tim, ze primarne se budou spracovavat a doplnovat sbirky, tj sbirka - rootUUID- podrizene UUID, slo by si situaci zjednodusit tim "Aktualizuj sbirku", "Natahni vyjmenovanu sbirku", "Odstran sbirku" (v K+). To je asi prvni nejjednoduchsi a nejrychlejsi cesta. Sbirky spravovane kuratormi jinde ( v K).

Mirne vylepseni by umoznovala pokrocila sprava sbirek, zde je dulezity definovat nakoli se virtualni sbirky v Kram a Kram + kryji a kdo je spravuje, pripadne jestli jde o toteze (obecne muze klidne byt ze sbirka v K je pro prohlizeni, a jeji counterpart v K+ je pro strojove spracovani). Nicmene v takovem pripade bude treba objekt virtualni sbirky mit rozsiren o dalsi informace, minimalne v K+. Rozhranie by malo byt minimalisticky, ktere natiahne obsah Kram (primarne sbirka UUID, root UUID a ich podrazene UUID (bez page), a pro krasu kontextu napr Nazev, Rocnik, Autory, Prava ), bola by moznost ich vyklikat / vyfiltroval / dat all, a poslat na spracovanie, stav spracovania by sa zde zobrazoval taky, vcetne chyb. Vsechny veci ohledem spravy sbirek v standardnim K, zde jenom rizeni co se z ni aktualne spracuje. Urcite bude nutne ale osetrit pravami, pripadne batchovanim objem spracovavaneho, protoze ukliknuti muze vyvolat neprijemne dusledky. Akce by taky mohla byt casovana / schedulovana.

[zabak]

@JanMeritus @MLhotak nebylo by lepší držet obsah K+ synchronní s K a neřešit manuální synchronizaci? Co se týče sbírek, měli bychom rozlišit oficiální sbírky (už ale ty nové ve stylu K7) a pak sbírky které si vyrobí uživatel lokálně v K+ pro účely svého výzkumu. Bude i tyto "privátní" sbírky vytvářet už v Krameriu?

[JanMeritus]

@zabak za mne je synchronizace optimalni automaticky. Nicmene realne spousteni obohacovani v K+ by melo byt moci regulovano i jinak, nebot je mozne ze dojde k zahlceni. Privatni sbirky (rsp skor jejich spracovani) bude urcite nutne povolovat z K+ a taky tam aj nejak regulovat, inak si umim predstavit jak to rychle zacne rust

[bodnarIQ]

... Urcite neresit primym preposilanim dat.

Súhlas, toto samozrejme nepripadá v úvahu.

Mohol by som poprosiť o podrobnejšie informácie(alebo odkaz k nim) k užívateľským zbierkam/kolekciam v K(kto ich moze vytvarat, kedy, ako, ake atributy obsahuje, co sa s nimi da v K robit, a pod.)? V požiadavkach je to spomenuté iba veľmi stručne, a na wiki K som o tom nič nenašiel.

[JanMeritus]

obsahovy spravci, metodika zatim neexistuje, tvorena v MZK @zabak , prosim o vyjadreni s predstavou Janku Hrzinovu (odkaz preposlan)

[JanaHrzinova]

Dobrý den, obecně a na uživatelské úrovni v NK sbírky vytváří kurátor Krameria. Prozatím byla startegie taková, že dával dohromady celky volně dostupných dokumentů. Sbírka se dá vytvořit, zrušit. Dílo do sbírky zařadit/vyřadit. Potom se ke sbírkám (jednotlivým celkům) dá přidat anotace a obrázkový náhled. Ve vlastnostech sbírky se dá nastavit český název a anglický název. Potom se dají nastavit snad i práva, kdo může sbírku číst, administrovat, provádět replikace, tisknout dokumenty a přistupovat k pdf. S těmito nastaveními nemám ale žádné zkušenosti a k technickému fungování toho nedokážu mnoho říct.

[zabak]

@JanMeritus Metodiku budeme dělat, ale počítali jsme s tím, že nejprve bude software (aspoň v prvním prototypu) a na to naváže metodika