ceskaexpedice / kramerius

System Kramerius
GNU General Public License v3.0
45 stars 26 forks source link

Indexace a konce řádků #656

Open zabak opened 5 years ago

zabak commented 5 years ago

Problém je popsaný v https://github.com/ceskaexpedice/kramerius-web-client/issues/95 kde se řeší prezentační strana věci. Při indexaci fulltextu se využívá txt a nikoli ALTO. To je výrazně rychlejší, ale má to dva identifikované problémy:

V MZK jsme udělali fix indexu, při kterém jsme přímo v indexu tento problém opravili, ale to neřeší problém nových indexací a reindexací.

pavel-stastny commented 5 years ago

Solr považuje slovo na konci řádku a na začátku dalšího za jedno slovo, takže pak ta dvě slova nejdou najít protože solr zná jen jedno slovo: "slovo1/nslovo2", takže správně by se před indexací měly všechny konce řádků nahradit mezerou.

To neni pravda. V solru je nekolik tokenizeru, ktere oddeluji jednotlive termy od sebe. Ten standardni, ktery je vyuzivan, se ridi normou definovanou v unicode. Viz https://lucene.apache.org/solr/guide/6_6/tokenizers.html#Tokenizers-StandardTokenizer

Jak se rozbije retezec pri query nebo pri indexaci jde overit administratorske strance solru. (Vyberte jadro a polozka analysis)

Pokud je slovo na konci řádku rozdělené, v indexu jsou buď dvě půlky daného slova indexované samostatně, nebo je tam něco jako "slo-/nvo" nebo "slo-/n vo" což se taky nenajde.

Mozna by stalo za uvahu do analyzy zaradit WordDelimiterGraphFilter https://lucene.apache.org/solr/guide/6_6/filter-descriptions.html#FilterDescriptions-WordDelimiterGraphFilter.

kazooo commented 5 years ago

Dobrý den, takto to ted' vypadá v Solru MZK: analyza1 Předpokladám, že takto indexované rozdělení ovlivnuje vyhledavání a zabíra navíc místo pro kousky "nký", "r" a tak dál.

pavel-stastny commented 5 years ago

To je normalni webovy formular. Kdyz chcete zalomit na novy radek, dejte to entrem.

kazooo commented 5 years ago

Když Kramerius indexuje text, tak posílá Solru jako jeden string se všemi znaky? Nebo se mýlím? Pokud mám pravdu tak by Solr to měl indexovat tak jak jsem ten text zadal do analysis.

pavel-stastny commented 5 years ago

Ja nevim, mozna si nerozumime. Kdyz mluvime o situaci, kdy je jedno slovo na konci radku a druhe na zacatku noveho, tak mluvime o nasledujici situaci? :

konec radku
zacatek noveho

A nebo mate na mysli, ze primo v textu pouzita escape sekvence pro novy radek? Jako treba v jave v jsonu atd.. ?

 String lines = "radek1\nradek2" ;

Z puvodniho komentare od Petra Zabicky jsem nabyl dojmu, ze se jedna o prvni pripad ?

vlahoda commented 5 years ago

Podival jsem se na zrejme stejny dokument uuid:ceb90a00-3c0f-11e9-bae4-005056827e51 v NDK. V datastreamu TEXT_OCR ve fedore mezi slovy kostce a Asumpce je jeden znak CR (hexa 0x0a), zatimco v odpovidajicim zaznamu v indexu SOLR je v poli text_ocr zobrazovana escapovana sekvence \n, tedy "kostce\nAsumpce". Jenze to je jen zobrazeni ulozeneho pole z indexu, ve skutecnosti byl ten text spravne tokenizovan pri indexaci toho puvodniho textu z fedory a index tedy obsahuje dva tokeny: kostce asumpce. Urcite tam neni spojeny token kostce\nAsumpce, jak tvrdi Petr Zabicka. Muzete si to snadno overit tak, ze v solru zadate query s fq=PID:uuid\:ceb90a00-3c0f-11e9-bae4-005056827e51 a q=text_ocr:asumpce - najde to prave jeden zaznam. Kdyz misto asumpce zadate nasumpce, kostceasumpce nebo dokonce kostce\nAsumpce, nenajde se nic.

@xermak00 Do tech poli ve formulari Analysis musite text zadavat jako original, tedy na vic radku a ne tak, jak je zobrazen v indexu jako jeden radek s escapovanymi \n

Tak snad si uz budete rozumet ;-)

Jinak ale samozrejme zustava ten problem se slovy rozdelenymi pomlckou na konci radku, bude treba prekonfigurovat indexer tak, aby je pri indexaci spojoval.

zabak commented 5 years ago

Ano, je to tak. Normální konce řádků jsou už u nás OK, ale indexaci rozdělených slov na konci řádku by bylo dobré dořešit.

zabak commented 5 years ago

viz též https://github.com/ceskaexpedice/kramerius-web-client/issues/96

pavelkocourek commented 5 years ago

Bude součástí samostatné Optimalizace SOLR