-
Notifications
You must be signed in to change notification settings - Fork 26
#Ověření možnosti přechod na nový repozitář systému Kramerius - Proof of concept [[TOC]]
#Úvod Účelem realizace PoC pro systém Kramerius je potřeba přechodu na novější repositář pro ukládání digitálních objektů. Ta je dána technologickým vývojem používaných komponent. Nové verze: Java, Fedora commons, SOLR sebou nesou končicí podporou verzí starších, které systém využívá. Tento text popisuje ověřované varianty repozitáře:
- Fedora Commons 4 (JCR)
- Java content repository (v implementaci Jackrabbit)
#Fedora 3 Současné verze Krameria (5.*) využívají Fedoru 3, konkrétně verze 3.4-3.8.
Fedora 3 využívá pro modelování dat formát FOXML. Každý objekt v repozitáři je formálně popsán pomocí jednoho FOXML souboru. Může obsahovat datové streamy jako jsou například obrázky a metadatové streamy, které objekt popisují případně drží relace mezi jednotlivými objekty. (To je případ streamu RELS-EXT).
Bližší popis modelu a stremů zde.
Data importovaná v do repozitáře jsou pak zobrazitelné buď v samotné aplikaci nebo případně pomocí API. Systém kramerius pro zobrazení využívá následující komponenty:
- Samotný Fedora repozitář - slouží k samotnému získávání dat.
- Resource index - je součástí Fedory a slouží k získávání dat, která nejsou z objektu dostupná.
- SOLR index - slouží pro vyhledávání a rychlému získání informací.
Deployment scháma je vidět na následujícím obrázku:
#Fedora 4 Nová verze repozitáře nevyužívá pro popis objektu FOXML, naopak chápe objekt jako uzel grafu a využívá k tomu Linkded data platform. Základními prvkem je uzel - LDP Resource. Může obsahovat dětské uzly, pak se jedná Container.
V rámci konceptu bylo nutno data přemapovat. Tedy zvolit novou reprezentaci dat v novém repozitáři tak, aby převod dat byl co nejméně bolestivý. Zvolili jsme následující:
<Container Digital object>
- <Non-RDF resource DC>
- <Non-RDF resouce BIBLIO_MODS>
- <Non-RDF resource BIBLIO_MODS>
- <Non-RDF resource RELS-EXT>
Samotný objekt obsahuje jednotlivé streamy jako dětské uzly. Důležitým aspektem zde je fakt, že samotný RELS-EXT, který drží vazby mezi objekty, je zde uložen jako standardní datastream. (Tak tomu ostatně bylo u i fedory 3). Tím je zaručeno "stejné" nakládání s objektem jako bylo u dřívější verze.
#Java content repository Podobným způsobem lze modelovat data i v repozitáři JCR pouze je nutno oddělit tyto dva typy uzlů, tedy uzly reprezentující objekt a uzly reprezentující stream. To je možné nastavením repozitáře. Viz: (https://github.com/ceskaexpedice/kramerius/wiki/POC_install#jackrabbit).
Poznámka: Nastavení repozitáře se může ve výsledné implementaci lišit.
##Uložení digitálních objektů v repozitáři Objekty mohou být uloženy v repozitáři několika způsoby. V implementaci PoC bylo využito nejjednodužší varianty a to uložení všech objektů v jedné úrovni. Viz následující struktura:
- <PID_1>
- <PID_1>
Poznámka: Ve výsledné implementaci se uložení objektů může (a nejspíše bude) lišit.
Komunikaci s repozitářem zajišťuje objekt FedoraAccess . Stará o všechny typy volání (datové nebo získání metadat). Podpora je zajištěna implementací tříd, které realizují komunikaci s repozitářem. Situace jde vidět na následujícím obrázku:
V rámci konfigurace je možno měnit a zvolený repozitář. Viz konfigurační soubor (https://github.com/ceskaexpedice/kramerius/blob/POC/common/src/main/java/res/configuration.properties#L6) a (https://github.com/ceskaexpedice/kramerius/blob/POC/common/src/main/java/res/configuration.properties#L12). Základní komunikační jednotkou, která zůstává FOXML a to z důvodů snažšího přechodu mezi jednotlivými instancemi repozitářů.
#Externí závislosti
Předmětem POC nebyly změny ve vyhledávání s pohledu UI Krameria. Rozdíl je v implmentaci novější verzi SOLRu, která je nyní dodávána pouze jako samostatná aplikace. Bylo zde využito práce, které byly provedeny v rámci Issue 458
Od verze 5.3.4 je využíván OAI provider postaven na indexu SOLRu. Tato změna je jedním z kroků k postupnému nahrazení Resource indexu.
V POC jsme se resource indexu záměrně vyhnuli a to zejména z důvodu výkonostních problémů na větších instancích (NKP, ČDK, MZK). Potřebné vazby jsou během importu ukládány v pomocném indexu. Tento pomocný index je v případě Fedory 4 plněn externí aplikací, která poslouchá JMS zprávy (stejně tomu bylo i u plnění standardního resource indexu), u Jackrabbitu je využit princip listeneru.
Finální řešení pro produkční nasazení bude řešeno společně s migračními nástroji. Předpokládá se jeho vynechání a nahrazení funkčnosti vyhledávačem.
V rámci Poc byla vytvořena distribuce, která umožňuje naimportovat, zaindexovat a prohlížet jednoduchou monografii. Instalace distribuce s popisem jak importovat data je popsána zde.
- Realizace referencovaných streamů
- Virtuální sbírky
- Import dat z jiných formátů než z FOXML
- Replikace dat
- Procesy nakládající s FOMXL
- Rozhraní pro ČDK
Oba dva repozitáře Fedora4 a JackRabbit jsou z pohledu reprezentace dat zcela srovnatelné. Oba umožňují škálování, což je důležité především u větších instancí jako jsou například instance v Národní knihovně, Moravsko zemské knihovně či v Knihovně akademie věd. Z pohledu snaží možnosti migrace na jiný repozitář v případě nutnosti se naopak jeví líp repozitář Jackrabbit. Díky standardu JCR je umožněn snadný přechod mezi různými implementacemi repozitářů jako jsou například Jackrabbit, Modeshape, atd..
Důležité vlastnosti shrnuje následující tabulka:
Vlastnosti | JCR(Jackrabbit) | Fedora 4 |
---|---|---|
Škálovatelnost | ANO | ANO |
Reprezentace dat | Podobně jako u FC4 | Podobně jako u Jackrabbitu |
Nutnost další aplikace | Není | Nutná pro poslouchání JMS zpráv při importu |
Migrace na jiný repoziář | Snadná (v rámci JCR) | Těžká |
Z výše uvedeného se přikláníme k názoru použít pro přechod repozitář JCR (Jackrabbit) .