Open JanMeritus opened 5 years ago
JanMeritus
commented
4 years ago @honza-rychtar @zabak vzhledem k diskusii a ubirani se k tomu aby filtry byly dale expandovany, nestoji za uvahu pripravit radsi rozhrani advanced search kde si uzivatel uz jasne nastavi pokrocilou formulaci dotazy?, viz napr #339
zabak
commented
4 years ago Nějaký prototyp už Honza má na dk.kramerius.org akorát by bylo potřeba tam přidat podporu více polí.
honza-rychtar
commented
2 years ago Část už je hotova a co zbývá a má smysl udělat přepišme přehledněji tady #536
1. Agregovana issue o pridavani dalsich poli a funkcionalit
Pre istotu opakujem z povodnych isssues, a rozdelujem do moznych buducich kategorii, aby v tom bol lepsi prehlad / zaroven pridavam navrh clenenia GUI. Tymto by som #193 zavrel a preniesol diskusiu sem o jednotlivych kategoriach/funkcionalitach riesenia pak mozu vznikat samostatne issues (idealne sme odkazujuce). Tu by bolo fajn riesit skor celkovu implementaciu a jej postup.
1.1 Kat. Basic (Issue #193 )
Dokaze fungovat samostatne, malo by sa zaviest ako prve po dohode z VT
autor, názov, rok vydania [casovy slider], ISBN, ISSN. veřejné / neveřejné [checkbox], text v metadatach [vsetky metadatove polia], text v OCR
step II. (dep. on SOLR): doplnit o Klucove slova, #232 : Miesto vydania, Vydavatel/Nakladatel
zanikne ako kategoria prenesenim poli do kategorii pri dalsej implementacii
2.1. Kategorie rozsiritelne o funkcie (na tie sa neskor rozpadne Kat. Basic)
Kategorie funguju ako na knihovny.cz vyhladavajuce riadky, ktore sa mozu agregovat do skupiny ktora obsahuje jednu alebo viac reduktivnych funkcii / filtrov s upresnujucim cielenim - vid nizsie v issue - 3.1-3.4 Funkcie
2.1.1. Zakl. Bibliograficke udaje
2.1.2. Text
2.1.3. Rozsir Bib, Administrativa a Responsibility statements
2.1.4. Media
2.1.5. Prava
Po diskusii k #210 k Rozsirenym pravam, by obecne Advanced search mal zvladat vyhladavat rovnako s upresnujucim kriteriom podla prav nad jednotlivymi dokumentami (Verejne, Neverejne, Rozsirene prava (1. obecne (default vsetky), 2. rozpad - podla jednotlivych druhov: DNNT, CC, specialne zmluvy s vydavatelmi, ine ala Europeana))
2.2 Vyhladove kategorie
2.2.1. Geografia a GIS
Kategoria do buducna rozsiritelna pre potreby mapovania. TODO vyriesit duplicity s BIB kat (moznost aplikovat len na obsah)
[API rozhranie]: Export zoznamu vysledkov dotaz + result (Name:GIS) (JSON)
2.2.2. NER
[API rozhranie]: Export vysledkov dotaz + result (JSON)
3.0 Funkcie
Daju sa kombinovat s jednotlivymi kategoriami, obmedzuju ich by default vseobecnu posobnost. Tj uzivatel si vybere napr dve kategorie (napr. dve geograficke, ci jednu admin a jednu obsahovu) a kazdej priradi specificke funkcie. Moze sa pouzit viacero filtrov na jednu kategoriu.
3.1 Fc: Filter Zacielenie okruhu vysledkov / Redukcia dotazu
Funguje ako efektivny sposob pozitvneho/negativneho obmedzenia okruhu vysledkov. Ma iba dve subfunkcionality - obmedzenie na urcitu sadu dokumentov a testovanie pritomnosti vyrazov. V kombinacii s konkretnou vyssie uvedenou kategoriou umozni velmi presne zacielenie hladania.
Obsah:
-- Hladanie nad vybranymi dokumentami / ich sadou / Virt. Zbierkou. Aplikacia hladania nad vybranymi dokumentami, ci sadou. Redukcia SOLR dotazu v ramci vsetkych vyssie zadanych poli na vyber UUID a ich podriadenych zloziek.
-- Vyskyt vyrazu (checkbox: lemmatizovane (ano/nie))
Vyhoda: 1. presnejsie cielenie dotazov pre uzivatelov 2. Znacne setrenie prostriedkov na backende (aka win-win pre user i sysadmin).
User case: Som uzivatel so sadou dokumentou / korpusom - zaujima ma len vyhladavanie v oznacenych dokumentoch, ci v oznacenych dokumentoch so specialnym filtrom.
Implementacia:
3.2. Fc. Parameter
3.3. Fc. Chyby
Bolo by dobre aby v pripade, ze uzivatela zaujimaju aj chybove stavy vyhladavania si vedel take zobrazit / prip. len vyziadat cez API. Momentalne sa podla vsetkeho z vyhladavania vysledky postradajuce predpisanum formu (casto chyba v datach), ci zastaralost indexu nad datami vyhadzuju / ignoruju. Tieto vysledky mozu sluzit navodne ako obsahovym spravcom k opravam, tak i pri priprave zmenoviek, ale hlavne i badateslky ladenym uzivatelom - vedia, co vlastne z ich dotazu realne vypadlo pre zobrazenie
3.4. Fc. Providing Institution
4.0. Samostatne funkcionality (nedaju sa kombinovat s vyssie uvedenym)
4.1. Fc. Kramerius "CCL" (samostatna funkcionalita - zavislost na implementacii vyrazov)
Okno pre zlozeny dotaz s implementaciou . Mal by fungovat ako v hlavnom vyhladavani tak i v pokrocilom. Zavisle na implementacii vyraziva navrhnuteho p. @BrozekAles
Uzivatel cez neho vie odpalit jednoduchy dotaz z kombinacie poli, ktory sa vie prelozit do dotazu na SOLR.
Dotaz ktory si postupne uzivatel formuluje cez jednotlive vyssie uvedene okna vidi ako sa mu formuluje dotaz. Moze donho zasiahnut a preformulovat si niektore veci
4.2. Fc. API (zavedenie procesu v core):
Advanced search s jeho funkcionalitami zaviest tiez pre uzivatelov pouzivajucich API, bud metodou GET alebo POST, dotaz prostrednictvom "Kramerius CCL". Rozsirennie moznosti / limitov, co su pre Advanced Search v GUI. Navrat v JSON.
5. Postup implementacie
Objednavat postupne v jednotlivych vlnach a postupne implementovat tiez logiku Kram "CCL"