Informace o kvalite metadat

[bodnarIQ]

K+ má obsahovať informácie o kvalite poskytovaných metadát. Jedná sa konkrétne o metadáta typu použitá služba, verzia použitej služby(či už pôjde o obohacujúce služby, ako NameTag a UdPipe, alebo o nástroj, ktorým OCR vzniklo). Medzi týmito dátami sa má taktiež dať vyhľadávať. Môžme to riešiť dvomi spôsobmi:

1. Predom zadefinujeme všetky metadáta, ktoré sa pre každú použitú službu majú evidovať. Tým pádom budeme schopný vystaviť každú hodnotu do samostatného fieldu, nad ktorým sa bude dať vyhľadávať, filtrovať, zgrupovať a pod. Ak by sme mali predom jasne definované možné fieldy, možme dať užívateľom väčšiu flexibilitu pri vyhľadávaní(môžme im zobraziť, aké možnosti filtrovania nad nástrojom existuje, keďže vieme, aké fieldy sme si zadefinovali). Keďže ale môže nastať situácia, kedy buď nevieme dopredu, aké metadáta o použitej službe budú dostupné alebo budú rôzne metadáta pre rôzne verzie danej služby(napr. nástroj Adobe Acrobat bude poskytovať informáciu o tom, ako dlho generovanie OCR trvalo, ale iný nástroj na OCR túto informáciu neposkytuje), nebudeme takýmto spôsobom schopný konzistentne ukladať a vyhľadávať medzi metadátami(niektoré verzie toho istého nástroja môžu so sebou priniesť nové metadáta, čo by spôsobilo založenie nového fieldu, v ktorom dokumenty používajúce iné nástroje nebudú mať žiadnu hodnotu).
2. Druhý spôsob by bol ukladať všetky metadáta do jedného fieldu pre daný nástroj ako stringový reťazec. Toto by bolo z hľadiska komplexity solr schémy výrazne jednoduchšie a nemusíme pre každý nový "typ" metadát, ktorý nejaká verzia nástroja ponúka zakladať samostatný field. Tento spôsob ešte stále do určitej miery dovoľuje vyhľadávať a filtrovať tieto metadáta(hľadať iba v dokumentoch, ktorých OCR vzniklo nástrojom Adobre Acrobat => field OCR_metadata obsahuje reťazec Adobe Acrobat), no nebolo by možné efektívne zgrupovať dáta podľa tohto fieldu. Tento spôsob ukladania by bol flexibilnejší, keďže nemusíme prispôsobovať fieldy pre každý nový nástroj, a tým pádom za mňa aj preferovanejší.

Metadáta o použitom nástroji OCR sa z môjho hľadiska dosť líšia v porovnaní s metadátami o použitej službe pre obohatenie textu. Preto by som navrhoval použiť odlišný spôsob ukladania. Pre nástroj OCR by sme potrebovali definovať očakávané metadáta(úloha pre KNAV => určiť, čo chceme evidovať pri nástrojoch OCR(názov, verziu, ...?)). To by nám dovoľovalo použiť ENUM fieldy:

• mohli by sme užívateľom dať vedieť, o akých nástrojoch OCR zatiaľ vieme a podľa toho im dať na výber,
• nemuseli by vyhľadávať v textových reťazcoch(Zobrazíme na FE, že evidujeme dokumenty, ktoré boli prevedené do textovej podoby nástrojmi Adobe Acrobat a DocParser, užívateľ si vyberie a nemusí nikde vpisovať textový reťazec, tým predídeme chybám ako napr. "žiadna zhoda pre vybraný nástroj AdobeAcrobat" - užívateľ zadal názov nástroja bez medzery)
• dokumentácia API by poskytovala informácie užívateľovi o tom, aké nástroje pre OCR evidujeme

Keďže pre každú novú službu, ktorá by nejakým spôsobom obohacovala text o metadáta, musíme robiť programátorský zásah kvôli zmene solr schémy(minimálne pridanie nových fieldov, do ktorých by sa metadáta ukladali), nebude problém prispôsobiť fieldy pre metadáta. Pri pridaní novej služby môžu nastať dve situácie:

1. v prípade ak by sme chceli pridať novú službu, ktorá prináša nový "typ" metadát -> môžeme definovať nové fieldy (napr. v systéme, kde na začiatku nebude existovať žiadna služba, pridáme službu pre obohatenie textu o lematizované tvary)
2. v prípade ak by sme chceli pridať novú službu, ktorá ponúka existujúci "typ" metadát -> ak sme predtým už definovali fieldy pre metadata, nová služba bude musieť spĺňať tieto podmienky, t.j. ponúkať rovnaké metadata o službe (napr. v systéme, kde už existuje služba pre obohatenie textu o lematizované tvary, pridáme nový nástroj, ktorý tiež lematizuje dokument, ale s lepšou presnosťou => nový nástroj musí ponúkať rovnaké metadáta (chceme v takomto prípade prepísať metadáta ktoré vznikli starším nástrojom?))

TLDR:

1. Metadáta o použitom nástroji OCR by bolo dobré dopredu definovať, aby sme užívateľovi mohli dať na výber pri filtrovaní(evidujeme nástroje AdobeAcrobat a DocParser => "chcem iba dokumenty ktoré vznikli nástrojom Adobe Acrobat")
2. Metadáta o použitom nástroji pre obohatenie budú iba vypisované, nebude sa podľa nich dať filtrovať(maximálne cez textový reťazec, ktorý ale nebude veľmi spoľahlivý, keďže užívateľ nebude mať k dispozícií existujúce možnosti), keďže nemáme dopredu definované aké nástroje budeme používať, a chceme mať voľnosť v budúcnosti pridať nové nástroje bez väčšieho zásahu do celého systému.
3. V prípade, ak by sa v budúcnosti mala pridať nová služba, ktorá ponúka lepšie obohatenie o už existujúce metadáta(napr. služba AlfaOmega3, ktorá s vyššou presnosťou určuje lemmatizovaný tvar slov), chceme staré metadáta zahodiť a nahradiť novou službou? Môže vôbec takáto situácia nastať?

[bodnarIQ]

body k diskusii:

• bude sa vyzadovat moznost vyhladavat/filtrovat nad metadatami pre pouzite nastroje obohacovania? ak ano, do akej miery?
• konkretne atributy ? kazdy nastroj moze mat nieco ine, bude specifikovane pre kazdy nastroj individualne?

poznamky:

• metadata o obohateni budu ulozene na urovni stranky - pole vnorenych dokumentov/objektov. Nie je nutne previazat s jednotlivymi uzlami stromu - metadata sa viazu na vsetky uzly rovnakeho typu, nemoze nastat situacia, kedy niektore uzly typu lemma vznikli inym nastrojom, ako ine (na rovnakej stranke)

[bukovskyIQ]

Zdravíme, potřebovali bychom vaši součinnost při tomto issues, zejména odpověď z posledního komentáře a body k diskuzi @MLhotak @zabak

[motyc]

K vlastnímu obsahu nic nemám, ale možná by obecně komunikaci zjednodušilo, kdybychom tento typ dat označovali jako "paradata", což odpovídá definici daného pojmu (https://en.wikipedia.org/wiki/Paradata).

[zabak]

Asi úplně neodpovím na položené otázky.

Pokud si představím, co chceme dosáhnout, tak v případě OCR budu hledat například stránky dělané Recognition serverem verze nižší než 4.0 a budu hledat takové stránky, které mají horší (nebo lepší) kvalitu než 90%.

Případně můžu hledat dokumenty (tj. ne jen stránky), kde je malé množství stránek (nebo tam nejsou žádné) s OCR nízké kvality.

Naopak ale můžu mít stejnou stránku zpracovanou více nástroji. Například více OCR nástrojů, více lemmatizátorů apod.

Co se týče otázek, tak nedokážu říct, jestli je lepší pro tyto účely enum nebo string nebo něco dalšího. Stejně to povede k programátorskému zásahu. Enum udrží data v indexu čistší, ale pak musí být při indexaci vyřešeno jak naložit s výjimkami a ty enum výčty by měly být definované vždy jen na jednom místě (aby se nedefinovaly pro účely kontroly dat zvlášť a nehrozilo, že to někdo zapomene aktualizovat).

[bodnarIQ]

Ďakujem za príklady užití, pomôže nám to v našej predstave.

Rád by som si ujasnil pojem recognition server - ide vo vseobecnosti o server, ktory ponuka spracovanie skenu do textoveho formatu, alebo ide o konkretnu implementaciu takehoto nastroja ABBY Recognition server?

[zabak]

Jde o ABBYY Recognition Server. Teď se to přejmenovalo na https://www.abbyy.com/finereader-server/ jestli se nemýlím