OAI Provider pro Solr 7 (Kramerius 6)

[rzeh4n]

oai4solr nepodporuje Solr 7, který je potřeba pro Kramerius 6, ale používá ho už teď třeba MZK: moravianlibrary#294. Tak jenom, aby se o tom vědělo a bylo to někde zaznamenané, minimálně až se bude schylovat k finální verzi Kramerius 6,

[rzeh4n]

Možná by stálo za to uvažovat nad přechodem na ResourceSync namísto letitého OAI-MPH, u kterého se ukazuje, že má spoustu nedostatků, jako třeba:

• informace o odstraněných položkách
• systém resumptionTokenů při sklízení velkých setů

Fakticky je sklízení větší instalace Krameria, jako je MZK, téměř nepoužitelné. A problém nemusí být nutně v implementaci OAI-PMH Repozitáře.

[svetlym]

Dobrý den,

v Městské knihovně v Praze používáme protokol OAI-PHM pro komunikaci s knihovním systémem. Pokud by se zrušilo, museli bychom implementovat jiný protokol v našem knihovním systému.

[zabak]

ResourceSync by mohl být krok správným směrem. Opravdu funkčních a hlavně škálovatelných, rychlých a spolehlivých implementací OAI-PMH je u nás pomálu. V té souvislosti upozorňuji na draft IIIF Change Discovery API 0.1 a na prezentaci IIIF & ResourceSync:
Supporting discovery která tomu draftu předcházela. Je to samozřejmě ještě ve vývoji.

[zabak]

Dalo by se využít https://github.com/resourcesync/py-resourcesync - je to v pythonu, ale má to i solr generator, takže teoreticky by to šlo přímo použít.

[svetlym]

Zkonzultoval jsem to ještě s naším IT oddělením. Na implementaci nového protokolu do našeho knihovního systému nemáme momentálně zdroje - plně nás vytěžuje nasazování RFID.

OAI-PHM v Kramériovi ovšem používáme pouze na to, abychom do našeho knihovního systému automaticky doplňovali nově zveřejněná uuid. Možná by tedy tuhle funkcionalitu bylo možné implementovat nějak jednodušeji než komplet novým protokolem.

[filak]

Kramerius by měl mít dobře implementované OAI-PMH jakožto etablovaný standardní protokol.

ResourceSync by byl fajn - třeba by se jím dala lépe vyřešit aktualizace nadstavbových systémů ČDK atp.

Zmíněný projekt již není moc aktivní
https://github.com/resourcesync/py-resourcesync/graphs/code-frequency

Někdo by musel implementovat příslušný generátor pro v Krameriovi aktuálně používanou verzi SOLRu - viz https://github.com/resourcesync/py-resourcesync#resource-metadata

[zabak]

Problém vidím v tom, že ResourceSync vznikl jako odpověď na nedostatky OAI-PMH a praktická zkušenost ukazuje, že není tak snadné udělat implementaci OAI-PMH, která je rychlá, spolehlivá, bez chyb, bez dezinterpretací apod.
ResourceSync má blíž dávkovým exportům a je příočařejší.

[filak]

OK, souhlas. Ale jak už zmínil @svetlym - stávající knihovní systémy umí většinově spíš OAI. Takže bych OAI v Krameriovi rozhodně v současnosti nezahazoval.

[zabak]

Problém je, jestli to není kanón na vrabce. Možná že by pro daný účel stejně dobře posloužil export textového souboru obsahujícího na každém řádku několik údajů.

[JanMeritus]

@filak @svetlym taky souhlas, zmena by mala dopad taky na nase systemy. OAI zatim stale treba podporovat, obecne by som v tomto trende nasledoval Europeanu a ArXIv.

[pavel-stastny]

@rzeh4n @zabak OAI řešeno v rámci issue #1034.