hlageek
commented
3 years ago napr. ak užívateľ pozná PID z Krameria, môže zistiť, že publikácia nie je obohatená v Krameriu+ dotazom na Feeder typu "vráť mi všetky publikácie, kde ID=1234" a Feeder vráti 0 výsledkov -> užívateľ vie, že publikácia s ID=1234 sa nenachádza v Krameriu+
Jedna možnost je asi zaindexovat všechna přes OAI-PMH sklizená metadata z Krameria do Solr a držet u nich příznak, zda daná položka již byla obohacena. Uživatel by mohl odeslat žádost o obohacení Adminovi. Protože by ale záznam nebyl prohledávatelný s pomocí obohacených dat, bylo by to poněkud nesystémové a není jasné, jak by se uživatel mohl k neobohaceným položkám smysluplně dostat. Viděl bych to tedy spíš na příležitost pro úpravu Krameria, který by si mohl volat API Feederu a evidovat, které záznamy jsou také v Kramerius+. Žádost o zařazení PID k obohacení by Adminovi chodila z Krameria. Pokud by ze strany Krameria nebyla vůle takové rozšíření implementovat, muselo by se to asi řešit ad hoc. Ale i takové ad hoc řešení je systémovější, protože, jak jsem uvedl výše, nedává moc smysl, aby Feeder/Kramerius+ vedle obohacených dat ještě držel a prohledával metadata neobohacených publikací. Snad jedině kdyby byly jasně odlišeny dvě úrovně prohledávání - jedna, která by fungovala jen jako kopie Krameria, druhá s extenzí na obohacená data. Ale průnik mezi nimi nelze dost dobře udělat.
motyc
bodnarIQ
Zdravím, zakladám toto issue pre ukážku aktuálneho stavu komponent diagramu spolu s popisom jednotlivých procesov. Diagram som znovu prerobil podľa pripomienok z pondelkového meetingu. Prikladám taktiež stručný popis jednotlivých komponent.
Prikladám aj link na poznámkový blok v aplikácii Evernote, kde by malo byť to isté, čo je popísané nižšie(sekcie Diagram komponent a Popis procesov), ale o niečo lepšie čitateľné, pretože formátovanie dlhších textov v githube nie je najšťastnejšie. V poznámkovom bloku v Evernote som zvýraznil nedoriešené body/dotazy na KNAV, ku ktorým by som poprosil vaše vyjadrenie.
Evernote link
Diagram komponent
Popis procesov
1. Proces obohacovania
- spúšťa **správca** Krameria+ - proces začína volaním rozhrania K+ _publicationId_, kde sa pošle množina _root_id_(PID) publikácií pre obohatenie - pre testovacie účely bude API brať množinu ID, neskôr sa doimplementuje spôsob, ktorý zaručí obohatenie **celého** obsahu Krameria(**nutná podpora zo strany Krameria - vystaví API**) alebo obohatenie väčších celkov - rozhranie môže byť volané napriamo skrze API, alebo cez grafické rozhranie (možnosť vlastného UI pre K+)Postup:
1. **Scheduler** príjme množinu ID, ktorú pridá do fronty pre spracovanie, zároveň bude jednotlivé requesty z fronty postupne posúvať ďalej komponente **Filler** - fronta by mala slúžiť pre zabránenie zahltenia Krameria+ - _môže dôjsť k zahlteniu? neprebehne celý proces obohatenia pred sprístupnením systému verejnosti?_ 2. **Filler** riadi proces obohacovania, zaisťuje volanie jednotlivých komponent v správnom poradí (**Filler** riadi volanie komponent **Enricher**, **TEI Converter**, **MongoDB**) * V prvom rade sa dotáže na **jadro Krameria** pre plný obsah publikácie - Skontroluje sa, že ide o root_id, t.j. ID objektu s typom **monograph**, **periodical**, **periodcalVolume**, ..., NIE typ **PAGE** - Skontroluje sa, že existuje ALTO - Ak neexistuje, potreba zavolať _recognitionServer_ (stačí upozorniť správcu?) - Získa z API **Krameria** všetkých potomkov danej root publikácie (množinu objektov typu **page**) * Získanú štruktúru (titulok/výtisk + stránky) pošle na obohatenie do komponenty **Enricher** - **Enricher** sa stará o konkrétny proces obohatenia jednotlivých dát volaním externých služieb 1. Najprv sa obohatia dáta na úrovni výtisku - pripojenie metadát z MARC záznamu - pripojenie metadát z NDK balíčkov 2. Následne sa obohatia jednotlivé stránky - Ak neexistuje OCR text, extrahuje sa text z ALTO formátu - Ak existuje OCR text, použije sa ten - Text stránky sa pošle na tokenizáciu/lematizáciu do nástroja **UDPipe**, spracuje sa odpoveď, vytvorí sa pole objektov = tokenov, na ktoré sa naviažu príslušné metadáta - Text stránky sa pošle na NER do nástroja **NameTag**, spracuje sa odpoveď, získané metadáta sa namapujú na tokeny - Metadáta z formátu **ALTO** sa namapujú na pole tokenov 3. Pri prvom obohatení stránky sa zapíše verzia použitých nástrojov 4. Po každom ďalšom obohatení stránky sa skontroluje, či nedošlo k zmene verzii externého nástroja (verzie LINDAT nástrojov sa môžu zmeniť počas obohacovania, čo by mohlo spôsobiť inkonzistencie) 1. Ak áno - chyba, každá stránka výtisku musí byť obohatená rovnakou verziou nástroja 2. Vyhodí sa chyba, proces obohacovania sa musí spustiť znovu nad celou publikáciou 5. Po obohatení poslednej stránky sa uložia paradata (metadata o použitých nástrojoch) do obohateného objektu na úrovni výtisku 6. Obohatené objekty sa vrátia komponente **Filler** 3. Po získaní obohatených objektov sa táto štruktúra pošle do komponenty **TEI Convertor** - **TEI Convertor** vráti obohatené dáta v TEI formáte - Pre objekty na úrovni výtisku vráti TEI Header - Pre objekty na úrovni stránok vráti TEI Body - TEI Convertor vytvorí tei formát obsahujúci kompletní množinu metadát ktorá sa uloží ako atribút(stĺpec) objektu (TEI formát sa pri exporte vo Feederi na základe uživateľského dotazu môže orezávať o nechcené tagy) 4. Po získaní TEI formátu sú dáta plne obohatené a posielajú sa na uloženie do komponenty **MongoDB** - **MongoDB** je síce logickou súčasťou Krameria+, ale v skutočnosti je to plnohodnotná samostatná aplikácia s vlastným rozhraním - Môže byť provozovaný na rovnakom stroji ako K+, ale zároveň môže byť aj na inom servery/skupine serverov alebo v cloude (pre rozloženie zátaže - záťaž na vyťažovanie z DB neovplyvní vyťaženie stroja s K+ zodpovedného za proces obohacovania) - Z tohoto dôvodu je komponenta **MongoDB** znázornená iba polovičným presahom do modulu Kramerius+ 5. Po úspešnom uložení do DB sa upozorní komponenta **Indexer** v module **Feeder BE**, že došlo k úspešnému obohateniu publikácie - **Indexer** následne obohatenú publikáciu zaindexuje do Solru a prípadne upozorní užívateľa/správcu o úspešnom dokončení obohacovania2. Proces synchronizácie
- spúšťa sa automaticky - **Kramerius** by mal poskytovať rozhranie implementujúce protokol OAI PMH, na ktoré sa Kramerius+ bude dotazovať - Ak sa detekuje zmena v dátach nejakej publikácie, publikácia sa pošle do fronty pre znovuobohatenie (prejde celým procesom obohacovania znovu a výsledok sa nahradí v DB)3. Proces dotazovania
- spúšťa autentifikovaný vedecký pracovník buď cez grafické rozhranie Feeder FE, alebo priamym pripojením na rozhranie Feedru BEPostup:
1. **Scheduler** bude slúžiť ako most medzi užívateľskými dotazmi a komponentou pre ich spracovanie - príjme dotazy od užívateľov - pokusí sa vyhodnotiť ich zložitost - podľa zložitosti dotazu ich posunie ďalej na vyhodnotenie, alebo uloží do fronty pre vyhodnotenie neskôr - bude taktiež zodpovedný za spúšťanie odložených dotazov vo fronte 2. **QueryProcessor** bude riadiť proces dotazovania a pripravovať výsledok dotazu pre užívateľov 1. Prijatý dotaz sa pošle na vyhodnotenie do komponenty **Solr** 1. **Solr** bude hlavnou komponentou pre vyhodnocování výsledku dotazu z indexu - Solr je, podobne ako MongoDB, logickou súčasťou **Feeder BE**, ale v skutočnosti je to plnohodnotná samostatná aplikácia s vlastným rozhraním - Môže byť provozovaný na rovnakom servery ako **Feeder BE**, ale kľudne aj na inom servery/skupine serverov pre rozloženie záťaže a urýchlenie vyhodnocovania dotazov - Solr **nie je optimalizovaný pre vracanie veľkého objemu dát**, ale pre vyhľadávanie nad veľkým objemom dát. - To, čo sa do Solru uloží (atribút fieldu stored=true) a to, čo sa do Solru zaindexuje (atribút fieldu indexed=true) nemá na sebe žiadnu závislosť - nie všetko čo je zaindexované musí byť aj uložené - Fieldy(stĺpce) môžu byť: - _indexed=true, stored=true_ - nad obsahom tohto fieldu sa dá vyhľadávať a pri vyhodnocovaní sa field vrátí v odpovedi - _indexed=true, stored=false_ - nad obsahom tohto fieldu sa dá vyhľadávať ale pri vyhodnocovaní sa field nevráti v odpovedi - _indexed=false, stored=true_ - nad obsahom tohto fieldu sa nedá vyhľadávať, ale pri vyhodnocovaní sa field vráti v odpovedi - _indexed=false, stored=false_ - nad obsahom tohto fieldu sa nedá vyhľadávať a pri vyhodnocovaní sa field nevráti v odpovedi, field prakticky nie je súčasťou Solru(využitie pri pokročilom dynamickom mapovaní fieldov) - Z dokumentácie: - _indexed=true|false_ - _True if this field should be "indexed". If (and only if) a field is indexed, then it is searchable, sortable, and facetable._ - _stored=true|false_ - _True if the value of the field should be retrievable during a search, or if you're using highlighting or MoreLikeThis._ - Preto by sme sa do Solru nemali snažiť ukladať čo najviac dát a tým obmedziť prístup do **Krameria+** v snahe optimalizovať rýchlosť dotazovania. - Namiesto toho by sme mali od **Solru** požadovať pri vrátení výsledkov malú sadu dát(ID odpovedajúcich dokumentov) a na základe nich siahať do **MongoDB** pre plné objemy dát. - V snahe znížiť záťaž na systém **Kramerius** by sme mohli uvažovať o ukladaní dát(metadát - napr. autor, vydavateľstvo, rok vydania, čislo stránky, ...) do **Solru**, ktoré by sme mohli často potrebovať, a ktoré nemáme uložené v **Krameriu+**. Tieto objemy dát by neboli také veľké, ako objemy obohatených dát v **Krameria+** 2. Výsledok vyhodnoteného dotazu zo **Solru** sa vráti užívateľovi ako náhľad s minimálnym množstvom informácií - Môže užívateľ(vedecký pracovník) nejakým spôsobom zažiadať správcu **Krameria+** o obohatenie publikácie, ktorá nie je v Krameriu+? Prípadne akým? - napr. ak užívateľ pozná PID z Krameria, môže zistiť, že publikácia nie je obohatená v Krameriu+ dotazom na Feeder typu "vráť mi všetky publikácie, kde ID=1234" a Feeder vráti 0 výsledkov -> užívateľ vie, že publikácia s ID=1234 sa nenachádza v Krameriu+ 3. Užívateľ môže manuálne vyfiltrovať nechcené publikácie a zvyšok pošle naspäť do **Feederu** 4. Komponenta **QueryProcessor** zaistí získanie obsahu na vyžiadanej úrovni (nie stále plný obsah) z **Krameria+** 5. V prípade potreby získať data z **Krameria** sa využije komponenta Joiner pre spojenie dát z Krameria a dát z **Krameria+** do jednotného formátu 6. Komponenta **QueryProcessor** zaistí vrátenie dát užívateľovi v zvolenom formáte (default TEI?) a v zvolenom rozsahu (ktoré fieldy, ktoré tagy a pod.)Popis jednotlivych komponent
Kramerius+
Scheduler
Scheduler bude vstupná brána do systému Kramerius+, ktorá bude zabraňovať prehlteniu systému. Prichádzajúci request na systém Kramerius+ bude zachytený v komponente Scheduler, ktorý rozhodne, či môže byť obohatenie spustené, alebo bude odložené do fronty požiadaviek pre spustenie neskôr. Správca systému bude volať API, ktoré bude prijímať ID publikácie/množinu ID na obohatenie. Scheduler posunie nezmenený dotaz na rozhranie komponenty FillerSynchronizer
Synchronizer bude komponenta, ktorá sa bude starať o synchronizáciu systému Kramerius a Kramerius+. Kramerius vystaví API, ktoré bude implementovať OAI PMH protokol, pomocou ktorého bude komponenta Synchronizer upozornená v prípade, že dôjde k zmenám v systéme Kramerius. V takomto prípade sa vyhodnotí ID publikácie, v ktorej došlo k zmene, a spustí sa znovu proces obohacovania pre danú publikáciuFiller
Filler bude mať na starosti riadenie obohacovacieho procesu, predávanie informácií medzi jednotlivými komponentami a zaistí správne poradie volaných komponent. Filler príjme ID publikácie a dotáže sa na jadro Krameria pre plný obsah publikácie. Túto publikáciu následne pošle na obohatenie komponente Enricher. Po obohatení Enricherom sa výsledný objekt pošle do TEI Convertoru pre prevod do TEI formátu. Získaný TEI formát sa pribalí na obohatený objekt a odošle komponente MongoDB pre uloženie do databázy. Po úspešnom uložení sa upozorní Feeder BE, že pribudla nová obohatená publikácia a je potrebné ju zaindexovať.Enricher
Enricher bude jadro obohacovacieho procesu. Enricher bude komponenta, ktorá bude priamo volať interné a externé obohacovacie služby a zabezpečovať spracovávanie výsledkov, mapovanie metadát a celkové vytvorenie obohatených objektov.MongoDB
Do komponenty MongoDB sa bude ukladať obohatený obsah. MongoDB bude samostatná aplikácia, s ktorou bude jadro Krameria+ komunikovať cez vlastné rozhrania. Prístup do MongoDB bude zaručený iba priamo cez Kramerius+ (**_v diagrame momentálne možné z Feederu priamo do MongoDB, bude upravené_**). MongoDB môže byť provozované na inom servery, ako Kramerius+. Pripojenie na MongoDB z Krameria+ bude konfigurovateľné.TEI Converter
TEI Converter bude zaisťovať prevod obohatených objektov do valídného TEI formátu. Objekty na úrovni strany budú prevedené do formátu TEI reprezentujúce TEI body. Objekty na vyššej úrovni (výtisky, monografie, ročník periodika,...) budú prevedené do formátu TEI reprezentujúce TEI header.Feeder Backend
Scheduler
Scheduler sa bude snažiť určit výpočetnú zložitosť prichádzajúcich dotazov. V prípade, že bude dotaz príliš zložitý, ho scheduler odloži do fronty pre vykonanie neskôr. V prípade, že sa dotaz vyhodnotí ako nie príliš zložitý, scheduler dotaz posunie ďalej pre vyhodnotenie.QueryProcessor
QueryProcessor bude hlavná komponenta zabezpečujúca riadenie procesu dotazovania. Pri prijatí dotazu ho scheduler pošle na vyhodnotenie do Solru. Po získaní výsledku ho vrátí užívateľovi pre upresnenie výsledkov. Užívateľ následne vyfiltrované výsledky pošle naspäť komponente QueryProcessor, ktorá zaistí získanie ich plného obsahu na vyžiadanej úrovni a v zvolenom formáte. Ak dostupné údaje v Krameriu+ nebudú dostačujúce, siahne do Solr/Krameria pre ďalšie dáta, ktoré pomocou komponenty Joiner spojí a vráti užívateľovi.Joiner
Joiner bude zaisťovať spájanie dát z rôznych zdrojov pre rovnaké publikácie do jednotného formátu.Solr
Solr bude hlavnou komponentou zaisťujúcou vyhodnocovanie dotazu. Indexovať bude nutné všetky fieldy, nad ktorými bude mať uživateľ možnosť vyhľadávať. Ukladať by sa mali ale iba tie, ktoré sú nutné v odpovedi na dotaz v Solru. Väčšie objemy dát by sa mali doťahovať z Krameria+ priamo, Solr by mal slúžiť iba na zúženie množiny publikácií odpovedajúcich danému dotazu.Indexer
Indexer bude poskytovať rozhranie pre pridanie nových obohatených publikácií do Indexu. Rozhranie tejto komponenty sa bude volať po úspešnom obohatení publikácie v Krameriu+.