libcas / dl4dh

DL4DH – development of tools for effective utilization and mining of data from digital libraries to reinforce digital humanities research

DL4DH

DL4DH – development of tools for effective utilization and mining of data from digital libraries to reinforce digital humanities research

Almost every single central or large library stores a big amount of data in a digital form. The data are usually described by the high-quality metadata, which enables to browse these collections, to create various virtual exhibitions etc. They are stored in digital libraries or different repositories, whose design and basic functionalities are primarily intended just for the content viewing. To increase the level of their usability for the special research group of the data scientists is needed to enrich the metadata content and to develop the appropriate interfaces to extract the data to make the heuristic part of the research more effective than today.

The aim of the project is to design a set of the new functionalities and independent tools that enables the extensive data mining procedures in digital libraries to cover the digital humanities researchers needs.

DL4DH project is solved by the Library of the Czech Academy of Sciences, the National Library of the Czech Republic and Moravian Library in Brno and IT company InQool.

DL4DH project is supported by the Ministry of Culture of the Czech Rebublic under ID number DG20P02OVV002.

Project main coordinator: Martin Lhoták [email protected]

Main components of DL4DH solution:

DL4DH Feeder https://github.com/LIBCAS/DL4DH-Feeder

Kramerius+ https://github.com/LIBCAS/DL4DH-Kramerius-plus

TEI Converter https://github.com/LIBCAS/DL4DH-TEI-Converter

dl4dh's Issues

Metodika

Metodika DL4DH

Návrh osnovy metodiky. (Body dodané 9. 2. jsou zobrazeny tučně.)

Podklady

RIV

Definice druhů výsledků ve formátu .docx

Výsledek „Metodika“ je souhrnem doporučených praktik a postupů schválených, certifikovaných nebo akreditovaných kompetenčně příslušným orgánem veřejné správy … a s jednoznačně vymezenými uživateli tak, aby tito uživatelé měli jistotu, že při jejím dodržení budou získané výsledky průkazné, opakovatelné a že se jich lze dovolat.

Výsledek „Metodika“ realizoval původní výsledky výzkumu a vývoje, které byly uskutečněny autorem nebo týmem, jehož byl autor členem.

… musí být takové schválení/certifikace/akreditace uděleno na základě vypracování dvou nezávislých oponentních posudků …

Příklady metodik

Metodiky od roku 2016, oblast humanitních věd, poskytovatel MK, vyhledáno v RIVu

• Metodika logické ochrany digitálních dat
• Metodika uchování a prezentace multimediálních dat
• Metodika evidence dokladů hmotné kultury v narativních pramenech se zaměřením na zpřístupnění kulturně historických informací v cizojazyčných pramenech
• Certifikovaná metodika s názvem Století informace: svět informatiky a elektrotechniky – počítačový svět v nás, NÚŠL
• Certifikovaná metodika digitalizace všech typů obrazových zdrojů filmových materiálů
• Interpretace fotografie z hlediska obsažených obrazových informací. Metodika maximalizace reálného využití informací poskytovaných historickým fotografickým materiálem jako solitérní památkou a v kontextu používaných databázových systémů evidence pro prohloubení určení a poznání zobrazeného v každodenní praxi při identifikaci osob, míst, ateliérů apod.

Úvahy o metodice DL4DH

Ideální čtenář/uživatel metodiky

• (A) provozovatel digitální knihovny Kramerius
• (B) badatel v oblasti digitálních humanitních věd
  • (B1) programátor
  • (B2) „neprogramátor“

Co by se čtenáři/uživatelé měli dozvědět

• (A) provozovatel digitální knihovny Kramerius
  • co je součástí dat v Krameriu
    • jenom základ, detaily formou odkazu na dokumentaci
  • co je součástí dat v Krameriu+
    • víc než základ, detaily ale formou odkazu na dokumentaci
  • Kramerius+
    • nasazení (požadavky na HW a SW),
    • konfigurace (interní a externí služby)
    • provoz (aktualizace SW, synchronizace dat)
• (B) badatel v oblasti digitálních humanitních věd
  • jaká data jsou k dispozici (v Krameriu)
    • obsah (pokud možno vyčíslené v procentech; čísla za KNAV, MZK, NK)
      • z jakého období jsou publikace
      • z jaké produkce publikace pocházejí
      • jaké jazyky díla obsahují
      • jaká jsou témata (beletrie, noviny, odborné)
    • objem digitalizátů
    • struktura (monografie, periodika, virtuální sbírky…)
    • ne/dostupnost dat chráněných autorským zákonem
  • jaké údaje o datech jsou k dispozici (v Krameriu, Krameriu+, NDK balíčcích)
    • metadata (k dokumentu, k obrázkům)
    • obrazová data
    • textová data
  • v jakém formátu jsou údaje o datech k dispozici
    • CSV/TSV
    • JSON
    • TEI
    • ALTO
  • schémata poskytovaných dat
    • XSD, RNG pro ALTO a TEI
    • JSON Schema (bude k definované?)
  • jak jsou údaje o datech zachyceny v jednotlivých formátech
    • (jakým způsobem zpracovat? komparačně jako tabulku, každý formát samostatně?)
  • práce s Krameriem (přepnutí na Kramerius+)
  • jak pracovat s DL4DH Feederem správně, aby uživatel dospěl ke správným výsledkům
    • (výsledkům čeho? vyhledávání, nebo bádání?)
  • práce s uživatelských rozhraním Krameria+/DL4DH Feederu
  • API pro práci s Krameriem+ a DL4DH Feederem
  • příklady výzkumných témat
    • podrobná studie i s výsledky
    • náměty na další studie s předpokládaným scénářem prací

Další užitečné informace

• cíle projektu
• předpokládaní uživatelé
• digitalizace v knihovnách
  • historie
  • aktuální stav
  • instituce využívající Krameria
• nové metody v humanitních vědách
  • DH
  • velké objemy dat
• formáty poskytovaných dat
  • syntaktická pravidla jednotlivých formátů
  • výhody a nevýhody formátů
  • standardizační autority (ALTO, TEI)
• právní rámec
  • autorský zákon
  • směrnice EU (data pro výzkum)
• obohacování textových dat
  • jaké nástroje jsou k dispozici
  • které nástroje se dostaly do DL4DH a proč
• architektura zvoleného řešení
  • technologie
  • komponenty systému
    • komunikace mezi nimi
  • zdůvodnění zvolených řešení
• slabá místa DL4DH
  • k čemu se nedá použít
• informace o jiných podobných projektech

Dotazy na INOVATIKU

Dotazy na INOVATIKU

Význam a využitie niektorých fieldov v SOLR indexe

• field geographic_names - čo reprezentuje, na čo sa využíva?
• field publication_places - čo reprezentuje, na čo sa využíva?
  priklad - Ide o miesto publikácie získané z MODS - mods:publisher(v príklade vyššie “Jihomoravský kraj”) alebo mods:subject -> mods:geographic(“Česko”, “Czechia” , oboje indexované 8 krát?)
• Je nejaký dôvod pre ukladanie hodnôt(stored=true) pre fieldy x.facet a x.sort a nevyužívanie copyField-ov pri týchto fieldoch?
• Na čo sa využívajú fieldy own_pid_path a own_model_path?
• Na čo sa využíva field rels_ext_index? Kedy sa sortuje podľa tohto fieldu?
• Kedy má objekt definovaného foster_parent-a ?
• Rozdiel medzi in_collections a in_collections.direct? Field definuje, v akých kolekciách sa objekt nachádza, ide o id zbierky, používa sa to pri novinách/časopisoch? (model - periodical)
• Využitie fieldu level?
• Date.min a date.max? “Začátek intervalu který obsahuje objekt” - co znamená ? Kedy je objekt definovaný intervalom? Čo interval vyjadruje? (datum vydání?)
• Čo sa ukladá do fieldov coords._ ? Koordináty čoho?

Dotazy vseobecne

• Kde môžem nájsť triedy pre content modely, ktore Kramerius používa, z balika com.qbizm.kramerius.imp.jaxb, napr. com.qbizm.kramerius.imp.jaxb.monograph.Monograph?
• Sú to generované triedy z nejakých XSD?
• Build krameria hádže nasledovný error(súbor build.properties nemám nikde ovorený)

D:\git\kramerius\kramerius>java -version
java version "1.8.0_271"
Java(TM) SE Runtime Environment (build 1.8.0_271-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode)

D:\git\kramerius\kramerius>gradle :search:clean :search:build --stacktrace

> Configure project :
Building K4-K5; please read BUILD-README.txt

> Task :search:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :search:infofile
Created build file D:\git\kramerius\kramerius\search\build\resources\main\build.properties

> Task :search:processResources FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':search:processResources'.
> java.io.IOException: Unable to delete file: D:\git\kramerius\kramerius\search\build\resources\main\build.properties

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':search:processResources'.
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:102)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:43)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:355)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:343)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:336)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:322)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker$1.execute(DefaultPlanExecutor.java:134)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker$1.execute(DefaultPlanExecutor.java:129)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:202)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:193)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:129)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.UncheckedIOException: java.io.IOException: Unable to delete file: D:\git\kramerius\kramerius\search\build\resources\main\build.properties
        at org.gradle.util.GFileUtils.forceDelete(GFileUtils.java:268)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter$1.run(CleanupStaleOutputsExecuter.java:81)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:402)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:394)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:92)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:75)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:95)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        ... 24 more
Caused by: java.io.IOException: Unable to delete file: D:\git\kramerius\kramerius\search\build\resources\main\build.properties
        at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2400)
        at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1721)
        at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1617)
        at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2391)
        at org.gradle.util.GFileUtils.forceDelete(GFileUtils.java:266)
        ... 38 more


* Get more help at https://help.gradle.org

BUILD FAILED in 7s
72 actionable tasks: 5 executed, 67 up-to-date

Labels a testovani

muzu pozadat o prava k pridavani labels - pro zlepseni RFC a issues cyklu

Filtrácia paratextu

Požiadavka: "Ve výzkumu mě zajímá samotný text odborných článků, měl bych mít tedy možnost z textu odfiltrovat paratext (čísla stránek a záhlaví s nadpisy apod.)"

Na toto sa mi nepodarilo nájsť žiaden nástroj, ktorý by to dokázal vyriešiť z textového reťazca. Bolo by to ale možné vyriešiť použitím lepších nástrojov pre OCR, ktoré by rozpoznaný text vrátili otagovaný, pomocou čoho by sme sa mohli rozhodovať, že či ide o paratext alebo nie. Verzovanie stránok podľa použitého OCR máme vyriešené, odfiltrovanie paratextu by ale tým pádom fungovalo iba na novších OCR. Máte nejaké dostupné nástroje na OCR, ktoré by tohoto boli schopné, alebo budeme musieť nejaký nástroj nájsť? Zatiaľ som narazil na Abby FineReader, ktorý sa najčastejšie považuje za najlepší.

Ďaľším potencionálnym riešením by bolo použitie REGEXu, čo ale nebude veľmi spoľahlivé, keďže obsah, na ktorom by sme to chceli použiť, je veľmi rozmanitý(niekedy je číslovanie stránok na začiatku, niekedy na konci, mohlo by dochádzať k odstráneniu časti textu ktorý nie je paratextom)

Metadata z NDK balicku

Potrebovali by sme nadefinovať, ake konkrétne metadáta sa majú preberať z NDK balíčkov, a podľa čoho sa má dať filtrovať a vyhľadávať, aby sme podľa toho mohli nadefinovať fieldy pre indexovanie a mohli začať spresňovať model objektu, v ktorom sa budú ukladať metadáta vzťahujúce sa k stránke, prípadne k celej publikácií.

Príklad NDK balíčku máme (pre publikáciu Bohemia).

Solr

Analyza moznych reseni aktualniho stavu

1. Spolocny solr index - spolecna data

   • problem s udrzitelnostou
   • problem pri reindexe
   • zasah do indexu krameria (nepřístupná varianta za inQool a Inovatiku)

2. Oddelene indexy - oddelene data

   1. Kramerius+ vlastny solr core

      • pre vyhladavanie sa vyuzije Solr JoinQuery parser
      • pri vyhladavani v specifickem shardu (vybranem)
        • dokumenty vo vysledku nie su spajane z jednotlivych shardov, takze vyhladavanie hlavneho obsahu v jednom core a obohatenych metadat v druhom core nefunguje
        • zvoleny dotaz sa vykona v oboch core - nie cast dotazu v jednom a cast dotazu v druhom core
      • pre joinQuery musi byt replica shardu krameria+ na kazdom node solru krameria
        • moznost iba filtrovat na zaklade vysledkov, v odpovedi sa nezobrazia vysledky z oboch shardov
        • tym, ze sa z prveho dotazu vrati iba mnozina ID pouzitych pre filtrovanie v druhom dotazu, nebude mozne facetovanie, vypocet relevancie a sorting na fieldoch z povodneho krameria
      • joinQuery vysveletene nizsie

   2. Kramerius+ vlastna solr kolekcia (pri vyuziti SolrCloud)

      • pre vyhladavanie sa vyuzije Solr JoinQuery parser
      • moznost iba filtrovat, v odpovedi sa nezobrazia vysledky z oboch kolekcii
      • Performance Join operace v Solr je linearne zavisla na pocte unikatnych termov vo fielde na ktorom sa spaja. Kedze my by sme joinovali na PID, → pocet unikatnych hodnot je pocet dokumentov
      • rovnaky princip ako pri Join Query vyssie

3. Oddelene indexy - spojene data

   • duplikovane data
   • problem s udrzanim dat synchronizovanych (zmeny v povodnom indexu mozu prebiehat radovo v minutach), hlavne pri vacsich indexoch

Solr Join Query

Vyber z dokumentacie Solr Join Query prisposobeny pre kontext Krameria

Joining across Single Shard Collections

Let’s consider an example where you want to use a Solr join query to filter publications by nameTag_persons that contain Karol. Specifically, imagine we have two collections with the following fields:

  kramerius: pid, title, text, ...
  kramerius_plus: pid, nameTag_persons, lemma, ...

To filter documents by nameTag_persons that have Karel using a Solr join on the kramerius_plus collection, you can send the following filter query to the kramerius collection:

   /solr/search/select?fq={!join from=pid fromIndex=kramerius_plus to=pid}nameTag_persons:Karel

Notice that the query criteria of the filter (name_tag_persons:Karel) is based on a field in the collection specified using fromIndex. Keep in mind that you cannot return fields from the fromIndex collection using join queries, you can only use the fields for filtering results in the "to" collection (kramerius).

Replica node of metadata index must exist on every node with original collection

Next, let’s understand how these collections need to be deployed in your cluster. Imagine the kramerius collection is deployed to a four node SolrCloud cluster and has two shards with a replication factor of two. Specifically, the kramerius collection has replicas on the following four nodes:

node 1: kramerius_shard1_replica1

node 2: kramerius_shard1_replica2

node 3: kramerius_shard2_replica1

node 4: kramerius_shard2_replica2

To use the kramerius+ collection in Solr join queries with the kramerius collection, it needs to have a replica on each of the four nodes. In other words, kramerius+ must have one shard and replication factor of four:

node 1: kramerius+_shard1_replica1

node 2: kramerius+_shard1_replica2

node 3: kramerius+_shard1_replica3

node 4: kramerius+_shard1_replica4

Joining across multiple collections

• The Cross Collection Join Filter is a method for the join parser that will execute a query against a remote Solr collection to get back a set of join keys that will be used to as a filter query against the local Solr collection.
  • remote Solr collection results only used as filter query - cant use for relevancy sorting
• Joins in Solr can't return results from both sides.

Zaver a navrhy reseni

Z vyse uvedeneho plyne, ze ani jedna z moznosti neni idealna

Cestu nejmensiho odporu vnimame v 3. moznosti

• bylo by potreba se snazit drzet SOLR aktualni, i presto, ze se index obnovuje radove v minutach, je to opravdu klicove mit solr aktualni v kazdy jeden okamzik ??
• Nebo si muzeme dovolit zpozdeni mezi indexy - napr 1 denni zpozdeni vuci puvodnimu systemu Kramerius, synchronizovat kazdy den o polnoci

Zde vnimame moznou potrebu budouci soucinnosti ze strany Inovatiky

• bylo by potreba probrat moznosti, jaky by to melo dopad na kooperujici firmu Inovatika

Prosime o potvrzeni nasich pohledu na vyse zmineny obsah.

KRAMERIUS + : Volba vhodne technologie baze, indexu a endpointu

Princip navrhu

Obecne bude treba stanovit vhodne technologie reseni a pohybovat se idealne v jejich hranicich. Proto si myslim ze v tyto fazy je dulezite si ujasnit technologie, ktere by ale po dosazeni pouzitych reseni a jejich vztahu (Baze, Index, Scheduler, Endpointy) mali vytvorit provozuschopny system, nepohybujici se vo vyjimkach a solidni prostor a skalovatelne zazemi pro uzivatelske dotazy, exporty a prip. dalsi integrace.

• cim min core technologii tim lepsi
• core technologie by meli mit sirokou akceptaci
• nicmene pro specificke ucely, muze byt pripadne vic zdrojovych bazi (eg. ciselniky, entity, relace apod.)

1. Baze
myslim ze tento bod si vyzaduje (protoze jde obecne o volbu nosne technologie na pristi leta) hlubsi analyzu ze strany dodavatele a idealne nejake easy POC, protoze jedna vec je

1. teoreticke rozhodnuti o vhodnosti objektovejsiho vs semantickejsiho modelu (oba vsak dokazu byt nastavitelny jednou nebo druhou technologii: NoSQL / TripleStore - a v obou pripadech jde v podstate o grafove baze)
2. komplikovanost instalace technologii a jejich sprava na konkretnich ruzne velkych instancich DK vcetne prubeznych migraci v nich uskladnenych (vyhledove nemalych) dat a jejich remodelaci dle prubezne rozvijenych datovych modelu
3. komplexita a vhodnost zvoleneho reseni, vyvoj do budoucna, podpora a adopce zvolene technologie

• pred roky se rozhodlo o smerovani na triplestore, ale doted se s tim knihovny borili
  • sprava teto technologie na denni bazi pro male DK neni vubec jednoducha
  • ne vzdy je k dostani dostatocna dokumentace k potrebnym issues vyplyvajicim z pouzite technologie
  • zmeny ve vyvoji konkretni TS implementace ze strany vydavatele technologie vedli k jeji opusteni a zahozeni nove verze Krameria a obecne ted uz min. 2 rocnimu setbacku na hlavni vetvy vyvoje
• bez POC, prip. kapacitniho testu nebo vyjadreni skuseneho databazoveho architekta nevidim schopnost kvalifikovane rozhodnout o vhodnom reseni, ktere je ale zasadni pro uspech projektu

Navrh:

• V pripade ze by melo jit o naozaj skalovatelny reseni s vizi do budoucna, premyslel by som nad shardovatelnymi bazemi schopnymi mohutnych operaci, ktere muzu, ale nemusi nutne vzdy byt semanticke, to uz zalezi jak by sme si nastavili pro konkretni data nebo casti dat. To je zasadni vyhoda oproti jinym technologiim, ktere jsou se svym modelem dat ovela silnejsie provazany.
• Trochu sem premyslel a zde mi vylozene nejlepe vychazi napr. Apache HBase, prip. jeho interpretace Jena-HBase nebo jeji rychlejsi braska Hive-HBase (obidva vic out-of-box RDF oriented). Obecny HBase se da pouzit k mnoha ucelum a je kompatibilni napr. se SPARQL a celym polem dalsich technologii, navyse je to solidni SW schopni pracovat s PB dat, metadat a cehokoliv co vyvstane. Druhym dalsim podobnym kandidatem je Apache Cassandra. Cassandra i nativni HBase jsou shardovatelny, rozumi si s distribuovanymi a cloudovymi systemami. Nevyhodou teto technologie, pokud by se nedodavala napr. pro male instance v ready made dockru s virtualizacnim overheadem, je relativne zlozite nasazeni a sprava, vyhodou ze jde o siroke nasazeni a industrialni a dlouhodobe skalovatelny standard.

2. Indexy

• muzu slouzit jako rychla prekladova vrstva mezi bazi a endpointy
• maji predindexovane veci
• cache dotazu
• v pripade slozitejsich dotazu by mela byt moznost konzultovat pripadne uzivatelskou reprezentaci baze mimo indexu
• nejde nutne o rychlost, skor schopnost poskytovat komplexni odpovedi napr. nad agregovanymi polemi, prip. upravy pro ktere neni nutne menit zdrojove data a budou stale ze zdrojovych dat vyplyvat
• Navrh: SOLR a Lucene, nebo neco jinyho
  • v pripade vyuzit baze operujici s Map Reduce (ala HBase) doplnkove reseni
  • hlavne pokud by slo o nejake zobrazovatko

3. Scheduler
Zde je nutno se zamyslet nad dotazmi z interfacu a rizenim odpovedi na ne - a schedulovanim a pridelovanim priorit jednotlivych dotazu a pridelovanim systemovych prostredku. Rata se ze ne vsechny dotazy muzu byt zodpovedeny on the fly, bude je treba stackovat a ridit

• zamereni na transportni vrstvu a. rizeni komunikace z rozhrani endpointu na index a baze
• administratorskych preferenci.
• dostupnych kapacit jednotlivych zdroju a jejich napr shardu
• vypocetniho vykonu
• repetice a dostupnosti napr v cache a indexech
• dale napr. volitelne notifikovat uzivatele po jejich dobehnuti
• Navrh: Vyuzit pri implementaci schedulera taky moznosti RDF pozitivniho Apache Thrift frameworku

4. Endpointy

• operacemi dle autentizace a autorizace (a role)
• bez ohledu na vybrani underlying baze a indexu by podla mna zhoda mela panovat na jejim endpointu,
• pro oba pripady , nebo ruzne dalsi agregace zdrojovych bazi na pozadi muze perfektne poslouzit SPARQL. SPARQL umoznuje kombinovat a zastitovat ruzne zdroje a provadet komplexni dotazy nad nima, muze se taky zvazit vyuziti SPARQL GW. Mozna implementace: vyuzit tez analyticke sily dotazovani via Apache Spark
• obecnejsi REST API s nadefinovanymi CRUD operacemi
• Viz napr. LOD #11; Dotazy: LIBCAS/DL4DH-Kramerius-plus#63

postup OCR → TEI: kdy pouštět jazykovou analýzu?

Jazykovou analýzu lze pustit buď na plaintextu a nebo na text převedený už do TEI: vyextrahuje se z něj plaintext, pustí analýza a vloží se zpět do TEI.

Viz také #1: toto rozhodnutí silně ovlivní, jak bude výsledné TEI vypadat.

Takto, až v TEI, pouštíme analýzu, když děláme parlamentní TEI dokumenty:

1. Převod do tei
2. metadata pro neanotovaná data(vyplnění hlavičky)
3. anotace
4. metadata pro anotovaná data
5. konverze do teitoku

volání udpipe:

https://github.com/ufal/ParCzech/blob/master/src/run_parczech.sh#L402
volá tento skript:
https://github.com/ufal/ParCzech/blob/master/src/udpipe2/udpipe2.pl

volání nametag:

https://github.com/ufal/ParCzech/blob/master/src/run_parczech.sh#L421
volá skript:
https://github.com/ufal/ParCzech/blob/master/src/nametag2/nametag2.pl

Má to smysl řešit, pokud na začátku jako výsledek OCR máme ALTO, které obsahuje dost informací vč. pozic na stránce. Pokud chceme tyto informace zachovat i na výstupu do TEI, tak je asi nejsnazší TEI generovat přímo z ALTO. Zde je ukázka TEI z ALTO: https://cunicz-my.sharepoint.com/:f:/g/personal/51291532_cuni_cz/EjADq5FS0URHkvlkWlGpVmkBNLGfIisuJ6S55wfB10xMaw?e=LG8pgL

• problém použitého konvertoru: ignoruje informaci o spojení slova rozděleného přes 2 řádky (v ALTO to je).

Druhá možnost je v současném schématu: ALTO >> plain text >> NLP analýza (+ přidat k tokenům koordináty z ALTO) >> TEI

Neaktuální dokumentace k metodě api/info/kramerius

V dokumentaci této metody (v rámci OpenAPI) je uveden povinný parametr krameriusInstance.

Podle aktuálního chování tento parametr není potřeba.

TEI formát

Zdroje, z ktorých vychádzam:
DL4DH_pomocna_databaze_200323
Ukážkový súbor z Drive - TEI/Ukazka/P14/TEI
Dokumentácia TEI

Formát jednotlivých ukážok sa nezhoduje, tak by som sa rád dotázal na objasnenie k niekoľkým veciam.

1. Naším cieľom pre formát TEI je hlavne pridanie atribútov pre jednotlivé tokeny. Predstavujem si to tak, ze každé slovo bude otagované v štýle <token persName="Karol IV." posX="124.5" posY="31">Karla IV.</token>. Vo Vami dodanej ukážke formátu TEI to takto ale nie je. Tam je každé slovo v body označené nejakým xml:ID, na ktoré sa potom predpokladám viažu atribúty pozície v tagoch <facsimile></facsimile>.
   
   
2. V súbore Pomocná databáza každý tag začína s predponou tei, napriklad <tei:persName>Karol IV.</tei:persName>, no v dokumentácii TEI to takto nie je.
   
   
3. V súbore Pomocná databáza je ukážka použitia tagov pre identifikáciu geografických lokácií nasledovným spôsobom:
   
   Zatiaľčo v dokumentácií je to takto:
   
   Bolo by ale dobré to zjednotiť v zmysle, že otagované slovo bude stále iba to, ktoré sa vyskytuje v texte(teda v tomto prípade by koordináty neboli medzi tagmi) a všetky metadáta, ktoré sa k danému tokenu viažu, by boli ako atribúty tokenu. T.j., napríklad:
   <token placeName="Brno" geoLat="42.1415" geoLon="16.1014">Brne</token>
   Bolo by toto použiteľné?
   
   
4. Ako správne otagovať prípad, kedy viacero tokenov zdieľa metadáta? Príklad:
   <token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso</token> - Po správnosti by sa rozoznaná menná entita mala otagovať tak, že každé slovo bude samostatný token, a každý token by mal obsahovať metadáta o tom, že ide o názov osoby, čiže by to vyzeralo tak, že každé jedno slovo z mena osoby by malo duplikované metadáta o celom mene osoby.
   <token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Pablo</token><token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Diego</token><token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">José</token>...
   Spojiť pod jeden token to nemôžeme, pretože na jednotlivé slová sa môžu vzťahovať ďaľšie metadáta, ktoré už nezdieľajú, napríklad lemma.

Ak by jednotlivé body potrebovali dôkladnejšie vysvetlenie/diskusiu, preferoval by som založenie samostatného issue pre jednotlivé body.

Testování Krameria+ 1.4

Obohatil jsem publikaci s uuid:0c94cf70-188a-11e4-8f64-005056827e52, tj. externími nástroji a TEI (obohacení NDK) jsem neprováděl.

Publikaci není možné exportovat.

Při pokusu o export do všech formátů se objevila chyba Při pokusu o export publikace došlo k chybě.

Žádné další podrobnosti jsem se v UI nedozvěděl.

Na záložce ÚLOHY EXPORTOVÁNÍ nejsou v seznamu žádné úlohy.

Linked Open Data a Entity Linking

Pre sprístupnenie dát z K+ ako Linked Open Data je potrebné implementovať Entity Linking - proces prepojenia rozpoznaných entít z textu na nejakú externú databázu(napr. wikidata). Toto má niekoľko výziev:

• variabilné pomenovania rovnakých entít - jedna a tá istá logická entita môže byť reprezentovaná rôznymi textovými pomenovaniami, napr. New York, NY, Big Apple, prípadne preklepy v textoch (New Yokr)
• nejednoznačnosť - rovnaký textový reťazec môže reprezentovať rôzne entity v závislosti od kontextu, napr. Paris = Paris Hilton alebo Pariz vo Fr?
• entita sa nemusí v konkrétnej externej db nachádzať, môže však neskôr pribudnúť, čo môže byť problém detekovať bez nutnosti opätovného spustenia algoritmu
• algoritmus musí byť dostatočne rýchly a škálovateľný, čo pri veľkých databázach ako je wikidata môže byť problém
  Podarilo sa mi nájsť zopár existujúcich riešení, žiadne však nepodporujú český model.
  DBPedia Spotlight - vlastny NER, nepodporuje cz
  MAG - vlastný NER, možnosť určiť klientom rozpoznané entity v inpute, nepodporuje cz

Entity Linking je nevyhnutný pre previazanie rozpoznaných entít s externými databázami a vystavenia dát ako Linked Open Data. Vyvinúť takýto nástroj v rámci projektu DL4DH nebude podľa mňa zrealizovateľné, a existujúci nástroj, ktorý by podporoval český jazyk som nenašiel. Viete o nejakom? Bez takéhoto nástroja nebude možné sprístupniť dáta ako LOD a prepojiť s externými DB

Obohatenie textu o narodní autority

Obohatenie prebehne pomocou služby NameTag. Služba nameTag nám vráti text otagovaný o rozpoznané entity. Z nich sa vyextrahujú entity otagované ako PX - Personal Names. Do DB sa uložia metadáta potrebné pre vytvorenie TEI formátu - Názov entity, pozícia zažiatku, pozícia konca, typ entity, ... Tieto dáta nebudú indexované - nebude možné v nich vyhľadávať, bolo by to zbytočné - vyhľadávanie by nemalo žiadnu pridanú hodnotu, rovnako by sa našli publikácie pri vyhľadávaní v plainTexte/lemmatizovanom texte. Bude možné vyexportovať všetky rozoznané menné entity z daného dokumentu - táto funkcionalita bude použitá hlavne pre zaslanie potrebných informácii do TEI Convertoru pre vytvorenie a uloženie TEI formátu.

Problém nastáva pri prelinkovaní mennej autority s externou databázou. Nemáme efektívny spôsob, akým by sme mohli určiť konkrétnu autoritu, na ktorú autor publikácie myslel pri písaní. Toto by sme mohli vyriešiť tak, že pri rozoznaní mennej entity by sa vytvoril iba URL link do databáze autorít, ale nie na stránku konkrétnej autority, ale na stránku ktorá sa zobrazí pri vyhľadávaní daného reťazca. Vyzeralo by to nejak takto:

Karel IV. byl syn dědičky Přemyslovců Elišky a českého krále Jana Lucemburského.

Jediný spôsob, akým by sme mohli odkazovať na presné záznamy v menných autoritách je manuálna správa rozpoznaných entít a ich prelinku ku konkrétnej mennej autorite knihovníkmi/administrátormi, no pri takomto množsvte dát mi to príde veľmi neefektívne.

Bolo by toto dostatočné riešenie čo sa týka prelinkovania menných autorít do externej databázy?

EDIT: Budeme potrebovať odkazovať na viaceré externé DB? Na čom to bude závisieť? Budeme to mať dopredu definované? Môžme sa spoliehať na to, že pre jeden "typ" metadat(napr. metadata o rozpoznanych mennych autoritach) budeme odkazovať stále na rovnakú externú DB?

Transformácia rozpoznaných entít typu lokácia na súradnice

Požiadavka: "Badatel si z mapy vybere zájmovou oblast. Na základě rozpoznaných entit se vyhledají texty obsahující uvedené informace."

Pre implementovanie takejto funkcionality budeme musieť rozpoznané entity typu lokalita indexovať pod ich súradnicami. Toto zahŕňa hneď niekoľko problémov.

1. Konvertovanie textu na súradnice

• potrebujeme previesť textové reťazce rozpoznané nástrojom NameTag na ich súradnice. Pre toto existuje niekoľko nástrojov, väčšina z nich sú platené. Tu by mohol nastať problém ešte s českým/slovenským názvom, ktoré nemusí nástroj byť schopný rozpoznať.
• nástroj od Googlu, Geocoding API dokáže prevádzať aj české/slovenské názvy(napr. ako Solúň) a vrátiť ich geografickú šírku a dĺžku, prípadne Border(obdĺžnik s 4 súradnicami). Stojí 5$/1000 requests

2. Vyjadrovanie lokalit s väčšou rozlohou

• ak by sme všetky lokality konvertovali na body, nedalo by sa spätne z bodu určiť, aká lokalita sa tým zamýšľala. To by spôsobilo, že ak by sme narazili na rozoznanu lokalitu "Česká republika", zaindexovalo by sa to pod zemepisnými súradnicami 49.8175° N, 15.4730° E. Ak by badateľ chcel nájsť publikácie, v ktorých sa spomína lokalita v 30km okruhu dediny "Golčův Jeníkov", bol by zahltený výsledkami o zmienkach "Českej republiky", ktoré sú preňho irrelevantné, a tých pár výsledkov pre "Golčův Jeníkov" by sa medzi toľkými nerelevantnými výsledkami stratilo. Toto by sa dalo vyriešiť tak, že by sme evidovali pri každej rozoznanej entite jej podtyp(typy rozpoznanych geolokalit tu) a buď indexovali iba niektoré typy, alebo dávali užívateľovi ešte na výber, aký typ geolokality chce vyhľadávať.

3. Použitý súradnicový systém

• pre správne fungovanie potrebujeme ukladať súradnice v Solre ako zemepisnú šírku a výšku. V ukážke z dokumentu Pomocná databáza sa používa súradnicový systém EPSG:5514, ktorý dokáže vyjadrovať iba územie CR/SK. Budeme potrebovať detekovať, či ide o lokalitu v rámci tohto územia, a ak áno, prevádzať do iného súradnicového systému do výsledného TEI formátu? A čo s ostatnými lokalitami, ktoré nespadajú do tohto územia? Alebo budeme túto informáciu evidovať iba o lokalitách v rámci tohto územia?

Spracovanie textu nástrojom UDPipe

Dobrý deň,

začal som implementovať spracovanie textov nástrojom UDPipe a narazil som na chovanie, ktorému trochu nerozumiem. Zakladám preto toto issue pre vyjasnovanie potrebných vecí počas implementácie spracovávania textov publikácií nástrojom UDPipe.

Ide konkrétne o spôsob tokenizácie. Z výstupu totižto ukladám pozíciu tokenu a narazil som na situáciu, že UDPipe pridal neexistujúci token do textu. Ide konkrétne o spracovanie vety Je potřeba jisté zralosti, řekl bych, jistého věku paternity, aby se člověk mohl stát zahradníkem amatérem., a podľa ďalších pokusov celkovo o vety obsahujúce slovo aby.

UDPipe slovo aby označil, že sa nachádza na pozícií 13-14 a neposkytol ziadne metadata okrem offsetov tokenu, na nasledujúcom riadku poskytol metadata o tokene aby (tu uz bez offsetov) a na dalsi riadok pridal slovo by spolu s metadatami (takisto bez offsetov).

Vedel by mi prosim niekto vysvetlit, preco sa toto deje, pripadne ci su aj ine slova, pri ktorych podobne spravanie mozme ocakavat a ako spracovat toto slovo? Predpokladam ze vkladat token by medzi obohatene metadata nie je ziaduce, udaje o offsetoch musim zobrat z prveho vyskytu slova a ostatne metadata z nasledujuceho riadku?

Zavedenie systemu labelov

• prosim o zavedenie systemu labelov pre tematicke okruhy, stav plnenia issue / vazene, prioritizaciu
• prosim o zavedenie millestones zviazanych s verziami projektu
• mozem dodat sam / vyuzit tie co su a priebezne sa o to starat, ale nemam na to prava (ani assignovat)

Diagram komponent + procesy

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í obohacovania

2. 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 BE

Postup:

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+
   2. Užívateľ môže manuálne vyfiltrovať nechcené publikácie a zvyšok pošle naspäť do Feederu
   3. Komponenta QueryProcessor zaistí získanie obsahu na vyžiadanej úrovni (nie stále plný obsah) z Krameria+
   4. 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
   5. 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 Filler

Synchronizer

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áciu

Filler

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+.

Proces plnenia pomocnej databázy K+

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.

Licenčné podmienky

Kde nájdeme licenčné podmienky k danej publikácií, aké môžu byť, ako na základe nich budeme musieť obmedzovať prístup k publikácií?

Súčasťou FOXML je datastream POLICY , ktorý vyzerý napríklad takto:

<foxml:datastream ID="POLICY" STATE="A" CONTROL_GROUP="E" VERSIONABLE="false">
    <foxml:datastreamVersion ID="POLICY.0" LABEL="" CREATED="2020-10-30T16:00:30.008Z" MIMETYPE="application/rdf+xml">
      <foxml:contentLocation TYPE="URL" REF="http://local.fedora.server/fedora/get/policy:public/POLICYDEF"/>
    </foxml:datastreamVersion>
</foxml:datastream>

K obsahu odkazu v foxml:contentLocation sa nedostanem, predpokladám že je k nemu prístup iba interne, vieme z toho ale nejakým spôsobom vyčítať typ licencie?

Informace o kvalite metadat

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ť?

Prosim o zapojeni testovaci instance vuci NK

@bodnarIQ @MLhotak prosim o zapojeni testovaci instance vuci NK

• potrebujeme v ramci vystupu religionisticke mapy vyznamu overi automatizovanou praci na datech - a kvalitu vystupu projektu

Obohatenie o MARC záznam

Ukážka MARC záznamu: https://vufind.mzk.cz/Record/MZK01-000000119/Details#tabnav

Publikácie majú byť obohatené o MARC záznamy - čo všetko z MARC záznamu máme preberať, a ako s tým ďaľej pracovať? Má byť niečo určené pre filtrovanie?

Prístup k MARC záznamom
MARC záznam môžeme získať cez api aleph.mzk.cz/OAI, kde ale potrebujeme ID záznamu.
Ukážka: https://aleph.mzk.cz/OAI/?verb=GetRecord&identifier=oai:aleph.mzk.cz:MZK01-000000119&metadataPrefix=marc21 - MARC záznam pre ID oai:aleph.mzk.cz:MZK01-000000119. Odkiaľ tento identifikátor vieme získať?