Closed bodnarIQ closed 2 years ago
body k diskusii:
poznamky:
lemma
vznikli inym nastrojom, ako ine (na rovnakej stranke)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
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).
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).
Ď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
?
Jde o ABBYY Recognition Server. Teď se to přejmenovalo na https://www.abbyy.com/finereader-server/ jestli se nemýlím
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:
OCR_metadata
obsahuje reťazecAdobe 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:
Adobe Acrobat
aDocParser
, užívateľ si vyberie a nemusí nikde vpisovať textový reťazec, tým predídeme chybám ako napr. "žiadna zhoda pre vybraný nástrojAdobeAcrobat
" - užívateľ zadal názov nástroja bez medzery)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:
TLDR:
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ť?