Pro krameriusndktest.mzk.cz jsou všechna čísla "Volume unknown"

[leiblix]

Pro krameriusndktest.mzk.cz mám v seznamu čísel u všech periodik "Volume unknown" (angličtina je ale v pořádku, můj telefon nemá českou lokalizaci).

[honza-rychtar]

Seznam rocniku periodika se generuje z: search/api/v5.0/item/UUID/children Vezme se rok a rocnik z "details":{"year":"YYYY","volumeNumber":"X"} Pokud volumeNumber chybi, pak se zobrazi "Rocnik neuveden" ("Volume unknown" pro en)

Napr. pro krameriusndktest.mzk.cz http://krameriusndktest.mzk.cz/search/api/v5.0/item/uuid:184be250-240c-11e2-85be-005056827e51/children volumeNumber chybi

Napr. pro kramerius.mzk.cz http://kramerius.mzk.cz/search/api/v5.0/item/uuid:5a2dd690-54b9-11de-8bcd-000d606f5dc6/children volumeNumber je uvedeny

Zkusel jsem nekolik periodik pro krameriusndktest.mzk.cz a nenarazil jsem na zadne, ktere by melo uvedeny rocnik. Napadlo me, ze by to mohlo byt tim, ze kramerius.mzk.cz ma neoficialni verzi API a do oficialni 5.0.2 verze volumeNumber nedoputoval. Ale tim to nebude. Napr FSV Karlovy univerzity, KNAV, Hradec Kralova, ... maji 5.0.2 a rocniky uvedene maji. Ale zase VK Olomouc taky nema nikde rocniky.

Cim to muze byt? Odkud se bere ten udaj v search/api/v5.0/item/UUID/children?

[leiblix]

Na kramerius.mzk.cz je už taky 5.0.2 (od dneška) a je to všechno ok. Odkud se ten údaj bere nevím, ale zítra se podívám. Dík.

[pavluska]

Ahoj,

to je tim, ze NDK ma cislo rocniku v jinem poli nez se davalo driv (vetsina veci z Krameria MZK), proto chci provest to cisteni dat, at to sjednotime.

P.

Wed Feb 11 2015 at 23:01:38 odesílatel Martin Rumanek < notifications@github.com> napsal:

Na kramerius.mzk.cz je už taky 5.0.2 (od dneška) a je to všechno ok. Odkud se ten údaj bere nevím, ale zítra se podívám. Dík.

— Reply to this email directly or view it on GitHub https://github.com/moravianlibrary/kramerius-for-android/issues/203#issuecomment-73974239 .

[honza-rychtar]

Sjednotime s kym? S dalsimi 30 knihovnami? Tohle by se melo resit na urovni API. Klientovi by melo byt jedno v jakem poli a v jakem formatu bylo cislo rocniku puvodne ulozeno, melo by ho zajimat jen to, kde ho najde v tom JSONu. Tohle neni uplne pravda, protoze klient bere data taky z MODSu a ze SOLR, takze budu muset resit vyskyt cisla rocniku v ruznych polich taky (coz uz delam).

U periodik v krameriusndktest.mzk.cz to nevypada, ze by se to davalo do jineho pole, ale spis ze se to nedava nikam. Nenasel jsem rocnik, jehoz MODS by obsahoval cislo rocniku! Je mozne, aby se cislo rocniku nekam ukladalo, ale v MODSu by nebylo? Ti padem neni v JSONu vracenem pres API, neni ani v aplikaci v podrobnostech o rocniku (bere se z MODS) a neni ani ve webovem klientovi - ten jeste nefici pres API a k cislu rocniku pristupuje nevm jak, ale kazdopadne ho nenajde. Ve webovem Krameriovi u periodik se rocnik periodika uvadi jako "YYYY Rocnik X" (vlevo ve strome, nahore v navigaci, v popisu), ale kdyz se podivate na libovolne periodikum v krameriusndktest.mzk.cz, tak je vsude poze YYYY.

Takze at uz NDK dava cislo rocniku kamkoli, tak ho zadna ze sluzeb nedokaze najit.

[pavluska]

Tak v Krameriu NDK je to takhle:

ročník - v MODS ve FOXML pro úroveň ročníku: číslo ročníku: mods:titleInfo - mods:partNumber

datum ročníku: mods:originInfo - mods:dateIssued

číslo - v MODS ve FOXML pro úroveň čísla a jsou to stejné elementy jako u ročníku

[pavluska]

Jestli uz si, Honzo, resis cisla, tak ty rocniky to maji uplne stejne, ve stejnych polich...

Ve starsich periodikach nejsou rocniky cislovane, takze se misto cisla rocniku pouziva rok, cili je tam rok vyplneny dvakrat. To ze si ho Kramerius z toho pole nebere do popisku, to je jiny problem :)

Thu Feb 12 2015 at 13:50:46 odesílatel Jan Rychtář notifications@github.com napsal:

Sjednotime s kym? S dalsimi 30 knihovnami? Tohle by se melo resit na urovni API. Klientovi by melo byt jedno v jakem poli a v jakem formatu bylo cislo rocniku puvodne ulozeno, melo by ho zajimat jen to, kde ho najde v tom JSONu. Tohle neni uplne pravda, protoze klient bere data taky z MODSu a ze SOLR, takze budu muset resit vyskyt cisla rocniku v ruznych polich taky (coz uz delam).

U periodik v krameriusndktest.mzk.cz to nevypada, ze by se to davalo do jineho pole, ale spis ze se to nedava nikam. Nenasel jsem rocnik, jehoz MODS by obsahoval cislo rocniku! Je mozne, aby se cislo rocniku nekam ukladalo, ale v MODSu by nebylo? Ti padem neni v JSONu vracenem pres API, neni ani v aplikaci v podrobnostech o rocniku (bere se z MODS) a neni ani ve webovem klientovi - ten jeste nefici pres API a k cislu rocniku pristupuje nevm jak, ale kazdopadne ho nenajde. Ve webovem Krameriovi u periodik se rocnik periodika uvadi jako "YYYY Rocnik X" (vlevo ve strome, nahore v navigaci, v popisu), ale kdyz se podivate na libovolne periodikum v krameriusndktest.mzk.cz, tak je vsude poze YYYY.

Takze at uz NDK dava cislo rocniku kamkoli, tak ho zadna ze sluzeb nedokaze najit.

— Reply to this email directly or view it on GitHub https://github.com/moravianlibrary/kramerius-for-android/issues/203#issuecomment-74065440 .

[pavluska]

Viz tady totok treba: http://krameriusndktest.mzk.cz/search/api/v5.0/item/uuid:f6f27d20-80e1-11e2-80e3-005056825209/streams/BIBLIO_MODS

• u tohoto periodika existuje cislovani rocniku

Thu Feb 12 2015 at 14:00:54 odesílatel Pavla Rychtářová < pavla.svastova@gmail.com> napsal:

Jestli uz si, Honzo, resis cisla, tak ty rocniky to maji uplne stejne, ve stejnych polich...

Ve starsich periodikach nejsou rocniky cislovane, takze se misto cisla rocniku pouziva rok, cili je tam rok vyplneny dvakrat. To ze si ho Kramerius z toho pole nebere do popisku, to je jiny problem :)

Thu Feb 12 2015 at 13:50:46 odesílatel Jan Rychtář < notifications@github.com> napsal:

Sjednotime s kym? S dalsimi 30 knihovnami?

Tohle by se melo resit na urovni API. Klientovi by melo byt jedno v jakem poli a v jakem formatu bylo cislo rocniku puvodne ulozeno, melo by ho zajimat jen to, kde ho najde v tom JSONu. Tohle neni uplne pravda, protoze klient bere data taky z MODSu a ze SOLR, takze budu muset resit vyskyt cisla rocniku v ruznych polich taky (coz uz delam).

U periodik v krameriusndktest.mzk.cz to nevypada, ze by se to davalo do jineho pole, ale spis ze se to nedava nikam. Nenasel jsem rocnik, jehoz MODS by obsahoval cislo rocniku! Je mozne, aby se cislo rocniku nekam ukladalo, ale v MODSu by nebylo? Ti padem neni v JSONu vracenem pres API, neni ani v aplikaci v podrobnostech o rocniku (bere se z MODS) a neni ani ve webovem klientovi - ten jeste nefici pres API a k cislu rocniku pristupuje nevm jak, ale kazdopadne ho nenajde. Ve webovem Krameriovi u periodik se rocnik periodika uvadi jako "YYYY Rocnik X" (vlevo ve strome, nahore v navigaci, v popisu), ale kdyz se podivate na libovolne periodikum v krameriusndktest.mzk.cz, tak je vsude poze YYYY.

Takze at uz NDK dava cislo rocniku kamkoli, tak ho zadna ze sluzeb nedokaze najit.

— Reply to this email directly or view it on GitHub https://github.com/moravianlibrary/kramerius-for-android/issues/203#issuecomment-74065440 .

[honza-rychtar]

Ok. Nicmene porad plati, ze to Kramerius (web i Android) neumi zpracovat.

Tady narazime na neuplnost API. Pri kazde takove zmene se bude muset upravit API (to by melo za idealnich podminek stacit). Zaroven KAZDY klient bude muset upravit parser SOLR (v tuhle chvili se hledani a obsah sbirek jinak udelat nedaji) a parser MODSu (podrobne informace jinak nedostanu).

Btw. jak dlouho se ta zmena pouziva? Jaktoze doted nebyl dan feedback prezentacni vrstve (webovy Kramerisu)?

Ono by bylo nejlepsi do budoucna rozsirit API tak, aby vubec nebylo zavisle na SOLR a MODS. MODS je sice moc pekny a krasne jde na nem videt jak vyuzivate expresivitu a volnost XML formatu, ale v konecnem dusledku dostane klient objemny soubor plny balastu, z ktereho si vycuca 1 % informaci podle x ruznych metodik z y ruznych knihoven. Vybec bych nebyl proti tomu, aby se vraceny item json rozsiril o dalsi data, ktera jsou ted dostupna pouze pres MODS a vsechny tyhle zmatky by se poresily na serveru a klienti by pres API dostavali uz sjednocena data v uspornem formatu.

[pavluska]

Zmena se pouziva cca od doby, kdy bezi NDK, takze asi 2 roky. Ja o tom vim od zacatku a taky se divim, ze si zatim nikdo nestezoval :)

S tim, ze to pujde jen pres API jsem pro, protoze cistit data jsme schopni tak asi my a zbytek knihoven na to nema kapacity.

Thu Feb 12 2015 at 14:27:00 odesílatel Jan Rychtář notifications@github.com napsal:

Ok. Nicmene porad plati, ze to Kramerius (web i Android) neumi zpracovat.

Tady narazime na neuplnost API. Pri kazde takove zmene se bude muset upravit API (to by melo za idealnich podminek stacit). Zaroven KAZDY klient bude muset upravit parser SOLR (v tuhle chvili se hledani a obsah sbirek jinak udelat nedaji) a parser MODSu (podrobne informace jinak nedostanu).

Btw. jak dlouho se ta zmena pouziva? Jaktoze doted nebyl dan feedback prezentacni vrstve (webovy Kramerisu)?

Ono by bylo nejlepsi do budoucna rozsirit API tak, aby vubec nebylo zavisle na SOLR a MODS. MODS je sice moc pekny a krasne jde na nem videt jak vyuzivate expresivitu a volnost XML formatu, ale v konecnem dusledku dostane klient objemny soubor plny balastu, z ktereho si vycuca 1 % informaci podle x ruznych metodik z y ruznych knihoven. Vybec bych nebyl proti tomu, aby se vraceny item json rozsiril o dalsi data, ktera jsou ted dostupna pouze pres MODS a vsechny tyhle zmatky by se poresily na serveru a klienti by pres API dostavali uz sjednocena data v uspornem formatu.

— Reply to this email directly or view it on GitHub https://github.com/moravianlibrary/kramerius-for-android/issues/203#issuecomment-74069730 .

[honza-rychtar]

Takze si toho vsimnul az Martin po 2 letech v Androidi aplikaci a na webu to nikomu nechybelo :) Je fakt, ze tam explicitne pisu "Rocnik neuveden", takze to bije vic do oci.

[leiblix]

Koukám na to, co by taková změna obnášela a je to nepěkné, není to možné udělat bez změny indexační šablony do SOLru. MODS v Solru není a tahání dat z Fedory by dotaz na potomky šíleně zpomalil (ostatně tak to v počátcích API implementované bylo a víme jak to bylo pomalé).

Číslo se tahá z tagu z hodnoty, která je za #.

SOLR dotaz do kramerius.mzk.cz vypadá takto: http://kramerius.mzk.cz/search/api/v5.0/search?q=PID:uuid%5C:2e238460-099a-11e3-9439-005056825209

a SOLR dotaz do krameriusndktest.mzk.cz takto (za křížkem nic není): http://krameriusndktest.mzk.cz/search/api/v5.0/search?q=PID:uuid%5C:2e238460-099a-11e3-9439-005056825209

Po úpravě indexační šablony by se samozřejmě musela všechna periodika reindexovat. To hromadně udělat umíme, ale samotná reindexace může trvat měsíc (ale nové reindexace by to neovlivnilo, zvedli bychom systémové prostředky a počet procesů).

[honza-rychtar]

Takze to znamena, ze kazda knihovna, ktera pouzila aktualni metadatovy standard, se k cislu nedostane pres SOLR? A kazda kihovna bude muset vse reindexovat?

Jinak pres SOLR vlastne cislo rocniku nepouzivam - jako parametr pro hledani se nepouziva a ve vysledcich hledani rocniky periodika nejsou. Ale treba typ dokumentu jsem bral z document_type, kde to v pripade MZK bylo ok, ale tohle pole muze obsahovat cokoli a u jinych knihoven taky obsahuje, takze se spatne zobrazoval typ dokumentu. Tohle jsem predelal na fedora.model a uz to funguje spravne vsude (je to ve verzi, ktera jeste neni na Play). Tech veci, ktere neberu uplne spravne muze byt vic - prasovani SOLRu jsem si tak nejak vymyslel podle struktury ruznych dokumentu, ktere jsem pres SOLR dostal.

Chtelo by to taky nejaky feedback z INCADu - delaji na dalsim klientovi postavenem nad stejnym API, takze musi narazet na stejne problemy. Spolecne se pak daji vymyslet dalsi pozadavky na API.

[leiblix]

Ano, bez reindexace s novou šablonou to prostě v tom stromu není (v K4 a nebude ani v K5). Vlastně se mě už jednou na tu šablonu do fronty ptal Aleš Drahotušský, nevěděl jsem proč to řeší a bylo to zrovna možná tady toto.

Asi bude fakt nejjednodušší napsat pro Incad issue, že se to má do SOLRu nově indexovat. Chystají nový SOLR a možná se budou chtít dělat i další změny v modelu.

Ono pro ostatní knihovny to problém není, mají toho celkem málo a půl milionu stran se dá reindexovat cca za den (a málokterá knihovna má víc).

My každopádně můžeme počkat, až budeme replikovat periodika z krameriusndktest.mzk.cz do kramerius.mzk.cz - to budeme muset reindexovat tak či tak.

[leiblix]

Napsal jsem issue do Incadu https://github.com/ceskaexpedice/kramerius/issues/217

[pavluska]

Ahoj,

tak se to prostě reindexuje. Stejně chceme dělat v K4MZK ty hromadné opravy, to se bez reindexace neobejde a importovat K4NDK, což taky ne. Prostě pěkně postupně to zvládnem :)

P.

Fri Feb 13 2015 at 12:53:42 odesílatel Martin Rumanek < notifications@github.com> napsal:

Napsal jsem issue do Incadu ceskaexpedice/kramerius#217 https://github.com/ceskaexpedice/kramerius/issues/217

— Reply to this email directly or view it on GitHub https://github.com/moravianlibrary/kramerius-for-android/issues/203#issuecomment-74242956 .

[luckajirku]

Omlouvám se, že se vám do toho vkládám, proklikla jsem se sem z issue 217 - Pavlo k tomu, co píšeš, že si nikdo nestěžoval, tak úplně tak to není:-), loni v květnu jsem na ty rozdíly v zobrazování staré vs NDK produkce založila issue https://github.com/ceskaexpedice/kramerius/issues/92

[leiblix]

@pavluska Šablonu jsem zatím aspoň na krameriusndktest.mzk.cz spravil, u nových periodik už se to číslo zobrazovat bude.

Ale narazil jsem na toto (je to uuid co posílal Honza) http://krameriusndktest.mzk.cz/fedora/objects/uuid:d4278100-6fa2-11e2-b2c2-5ef3fc9bb22f/datastreams/BIBLIO_MODS/content Má to stejné dataIssued a originInfo. Asi je to nějaký fail zezačátku digitalizace, bylo to ingestováno 2013-02-11.

[honza-rychtar]

@MartinRumanek Pavla rika, ze je to ok, ze pole je povinne a pokud je cislo nezname, tak zopakujou ten rok. Konkretne u tohoto rocniku cislo (i kdyz s vyplnenym rokem) pres API dostanu.

Porovnej tyto dva rocniky ruznych periodik, oba NDK: MODS 1) http://krameriusndktest.mzk.cz/fedora/objects/uuid:d4278100-6fa2-11e2-b2c2-5ef3fc9bb22f/datastreams/BIBLIO_MODS/content MODS 2) http://krameriusndktest.mzk.cz/fedora/objects/uuid:78203ee0-2746-11e3-b62e-005056825209/datastreams/BIBLIO_MODS/content

API 1) http://krameriusndktest.mzk.cz/search/api/v5.0/item/uuid:d4278100-6fa2-11e2-b2c2-5ef3fc9bb22f API 2) http://krameriusndktest.mzk.cz/search/api/v5.0/item/uuid:78203ee0-2746-11e3-b62e-005056825209

U obou ma MODS vyplnena stejna pole, ale u 1) je v API details.volumeNumber a u 2) tam neni.

[honza-rychtar]

Neni problem klienta