Koncept projektu Obálky knih.cz podpora obálek a obsahů vícesvazkových děl a periodik

Transkript

1

2 Koncept projektu Obálky knih.cz podpora obálek a obsahů vícesvazkových děl a periodik V současnosti je používáno popisování svazků periodik a monografií buďto shora (nadřízený záznam nese informaci o podřízeném), nebo zdola (podřízený záznam nese informaci o nadřízeném). Existuje národní doporučení pro SK ČR z r doporučující popisovat díla s nevýznamnými názvy shora. Popisování svazků periodik a monografií se napříč nejrůznějšími informačními systémy děje oběma způsoby. Cílem tohoto konceptu není závislost navrhovaných změn API na konkrétním způsobu popisování, ale je snaha o doplnění stávajícího API projektu Obálky knih.cz o univerzální podporu obálek a obsahů vícesvazkových děl a periodik. Identifikace svazků monografií K identifikaci monografií v současnosti slouží identifikátory ISBN (případně EAN), OCLC a ČNB. Knihovním informačním systémům je umožněno dotazovat se na libovolnou kombinaci těchto identifikátorů. Knihovní informační systémy tohoto v praxi využívají v případě, že v bibliografickém záznamu knihovny má knihovní informační systém k dispozici např. dva identifikátory (typicky ISBN a ČNB). Není jistota, že pokud se knihovní systém zeptá pomocí jednoho z identifikátorů a meta datový záznam nebude nalezen, tak meta datový záznam nebude nalezen pod druhým identifikátorem. Proto je výhodné ptát se na všechny v katalogu knihovny dostupné identifikátory najednou. Výše popisovanými identifikátory je v současnosti možné dotazovat se na souborné záznamy vícesvazkových děl. Předmětem tohoto konceptu je dotazování se na díla o úroveň níže části svazků. V MARC21 jsou pro účely identifikace částí vyhrazena pole: 245n číslo části (200h v UNIMARC), 245p název části (200i v UNIMARC). Návrhem je využít právě tyto podpole a pro účely identifikace částí svazků monografií je připojit ke stávajícím identifikátorům. Prioritním bude podpole čísla části 245n, resp. 200h. Pokud bibliografický záznam číslo části neobsahuje, bude možné připojit název části. Nebude se jednat o ten samý princip jako u výše popisovaných identifikátorů (isbn, ean, nbn, oclc), tj. pokud bibliografický záznam bude obsahovat oba identifikátory, informační systém připojí k dotazu pouze číslo části. Pojmenujme si tento nový parametrem jako část = part_no. Pravidla pro dotazování se knihovního systému na veřejné API projektu Obálky knih.cz, tzv. dotazovací API (jedná se o API frontend serveru, neboli API v3.0): V případě, že bibliografický záznam podpole 245n resp. 200h obsahuje, připojí se jeho obsah tak jak je, jako parametr part_no.

3 V případě, že bibliografický záznam podpole 245n resp. 200h neobsahuje, ale obsahuje podpole 245p resp. 200I, připojí se jeho obsah tak jak je, jako parametr part_no. V případě, že bibliografický záznam neobsahuje ani jedno z těchto podpolí, parametr part_no se nepřipojí vůbec. V tomto případě dostaneme jako odpověď API souborný záznam identifikovaný vyjmenovanými identifikátory (isbn,ean,nbn,oclc) v dotazu. Tento případ je běžný v současnosti, kdy se parametr part_no ještě nepoužívá. Pomocí parametru part_no se budou vkládat informace tak, jak je má knihovní informační systém uložené. Normalizace bude probíhat až uvnitř architektury Obálky knih.cz. Pravidla pro dotazování se na části díla uvnitř projektu Obálky knih.cz (API mezi frontend servery a backend serverem, neboli API v2.0) budou odlišná. Budou odlišná z důvodu normalizace dotazu. Doporučením pro knihovní systémy bude dotazování se pomocí polí pro číslo, nebo část díla bibliografického záznamu tak jak je beze změny. Nastává ale problém, že různé knihovny budou mít stejná díla popsána odlišně. Typickým příkladem z praxe je uvádění zkratek, kdy např. č.1, číslo 1 a část 1 znamenají to samé, ale pro informační systémy jsou to 3 různé věci. Proto se v našem příkladu normalizací provede zkrácení na 1. Pravidla pro normalizaci budou popsána v dalším textu a řeší i případ, že se v popisu části nevyskytuje žádný směrodatný číselný identifikátor. Příklady dotazů na svazky monografií: Pokud podpole 245n existuje, připojí se k identifikátoru ISBN/OCLC/ČNB např. takto: kde bibliografický záznam obsahoval podpole 245n s hodnotou č.1 a tento řetězec bude normalizací uvnitř architektury projektu Obálky knih.cz převeden na 1. Pokud podpole 245n nexistuje, ale existuje podpole 245p, připojí se k identifikátoru ISBN/OCLC/ČNB např. takto: první"]} kde bibliografický záznam obsahoval podpole 245p s hodnotou Část první a tento řetězec bude normalizací uvnitř architektury Obálky knih.cz převeden na cast_prvni. Pokud podpole 245n a 245p neexistují, zašle se požadavek na veřejné dotazovací API projektu Obálky knih.cz na základě identifikátorů ISBN/OCLC/ČNB, tak jako doposud.

4

5 záznamů bude v případě periodik komplikovanější. Pravidla pro dotazování se knihovního systému na veřejné API, tzv. dotazovací API: Je nutné použít minimálně kombinaci rok+číslo, nebo ročník+číslo, nebo všechny tři rok+ročník+číslo. Použití nových parametrů: part_year rok vydání/svázání periodika, part_volume ročník vydání periodika, part_no číslo vydání/rozsah čísel vydání, part_note poznámka, případně popis, pokud záznam neobsahuje výše uvedené. Do parametrů part_year, part_volume, part_no a part_note se budou vkládat informace tak, jak je má knihovní informační systém uložené. Normalizace bude probíhat až uvnitř architektury projektu Obálky knih.cz. Toto je případ, že knihovní informační systém tyto informace obsahuje. Pokud knihovní informační systém informace o roku, ročníku a číslu nemá oddělené, zeptá se veřejného dotazovacího API projektu Obálky knih.cz pomocí řetězce, který má k dispozici. Příklady: řetězec 2010, roč. 47, č bude API OKCZ přeložen na: rok 2010 / ročník: 47 / číslo: 1-11 řetězec r.50:č.1-20(2013) bude API OKCZ přeložen na: rok 2013 / ročník: 50 / číslo: 1-20 řetězec Roč. 29 (1992) č. 25,26 + příl.(magazín) bude API OKCZ přeložen na: rok 1992 / ročník: 29 / číslo: 25,26 / poznámka: priloha(magazin) řetězec Speciál Nejhorší zločinci švěta, 2011 bude API OKCZ přeložen na: rok 2011 / číslo: nejhorsi_zlocinci_sveta Pravidla pro dotazování se na části díla uvnitř projektu Obálky knih.cz (API mezi frontend servery a backend serverem, neboli API v2.0): part_year Rok vydání/svázání periodika. Parametr bude obsahovat pouze číslice, pomlčky pro označení nepřetržité řady let (bez mezer) a čárku pro označení přerušené řady (také bez mezer). Řetězce "roč.", "jahr." a jiné budou odstraněny z důvodu normalizace. part_volume Ročník vydání periodika. Parametr bude obsahovat pouze číslice, pomlčky a čárky, podobně jako parametr year. Nebude obsahovat řetězec jako např. "Vol.", "Sv." a jiné z důvodu normalizace. part_no Číslo vydání/rozsah čísel vydání.

6 Bude obsahovat pouze číslice, pomlčky a čárky, podobně jako předchozí parametry. Čistě slovní zápis, např. "zvláštní vydání" apod. budou normalizovány jiným způsobem než čísla. Bílá místa budou nahrazena za jiný znak. Nebude obsahovat řetězec "č.", "nr.", "měs." apod. Označení měsíců (tím je myšleno např. leden, březen, listopad, ne led, bre, list) bude normalizováno na čísla. part_note Poznámka. Může obsahovat informace o prezenčním půjčování, spolehlivosti docházení seriálu (dochází opožděně, nespolehlivá výměna), neúplných ročnících a chybějících číslech, mutacích a řadách. Častější využití parametru bude ale systémy, které nemají předchozí parametry rok/ročník/číslo oddělené. Příklad dotazu na číslo periodika: multi={["nbn":"cnb ","part_year":"2014","part_no":"č. 1 + CD příloha"]} Normalizace parametrů Aby nedocházelo k omezování knihovních systémů, bude dotazovací API umožňovat posílání parametrů tak, jak se v bibliografických záznamech vyskytují. Toto ale vyžaduje normalizaci na straně API projektu Obálkyknih.cz. Cílem je zamezení duplikaci záznamů v co nejvyšší míře. Normalizace bude probíhat na všech instancích frontend serveru a bude se snažit o takovou úpravu parametrů dotazů, aby různé popisy toho samého záznamu vedly na jeden záznam. Pravidla normalizace: Pokud parametr neobsahuje žádné číslo, budeme se snažit o substituci bílých míst za jiný znak, např. podtržítko. Bude vyřešeno vícenásobné odsazení znaků. Pokud parametr číslo obsahuje, budeme se snažit o odstranění všech dalších nepotřebných znaků, které informační hodnotu nezvyšují. Budou využity regulární výrazy. API se bude snažit o odstranění teček, středníků, závorek apod. Budou se zachovávat čárky a pomlčky, protože ty např. oddělují čísla periodik ve svazcích periodik. Speciálním typem parametru bude parametr part_note. Pokud bude tento parametr uveden bez parametru part_no (který je potřebný pro identifikaci rok+číslo, nebo ročník+číslo), bude se jednat o dotaz systému, který nemá oddělenou informaci o roku, ročníku a čísle v bibliografickém záznamu. Systém se bude v takovémto případě snažit o rozlišení informace, kterou nese. Bude se

7 snažit o oddělení informací o roku vydání/svázání periodika a o čísle/číslech. Tato funkčnost usnadní (nebo spíš neznemožní) používání napojení obálek a obsahů čísel periodik a svazků periodik pro knihovnické informační systémy neumožňující zavedení normalizace. Algoritmus zajišťující oddělení informací o roku, ročníku a čísle bude fungovat na principu hledání hrany informace v textu. Tímto se text rozdělí na fragmenty a ty se budou dále klasifikovat. Součástí klasifikace bude odstranění řetězců nenesoucích žádnou informaci, např. roč., ročník, rok. Tyto řetězce nesou pouze informaci potřebnou pro klasifikaci fragmentu, ale ne dále pro dotazování se na API projektu Obálky knih.cz. Takto rozdělené a klasifikované informace se ještě normalizují. Odstraní se přebytečné mezery, závorky apod. Příklady předloh a výsledků tohoto algoritmu jsou na stránce č.5 tohoto dokumentu. Cílem tohoto algoritmu není 100% klasifikace informací v textovém řetězci poskytnutém knihovním informačním systémem, to není možné. Cílem je co nejlepší rozlišovací schopnost, zasažení co nejvyššího počtu běžně se vyskytujících způsobů popisování čísel periodik pro systémy, které informace o roku, ročníku a číslu nemají separované.

8

9

10 V případě periodik je situace jednodušší. Skenované číslo periodika má vždy stejný identifikátor jako souborný záznam. Liší se v: rok (budou povolena čísla, čárky a pomlčky). Položka Rok vydání, která teď existuje, zůstane. Bude obsahovat hodnotu nacházející se v katalogu knihovny, tj. např. Hodnotu indikující, že periodikum vychází od roku 2010 doteď. Jednotlivá periodika se budou lišit rokem skenovaného periodika, kde hodnota může být např ročník (povolené znaky: čísla, čárky a pomlčky) číslo (povolený jakýkoliv znak; nemusí dokonce ani obsahovat číslo) poznámka (cokoliv; pokud se v předchozí položce objeví znak +, bude text za tímto znakem přesunut automaticky do pole poznámka) Shrnutí změn: Úprava formuláře při zakládání nové jednotky tak, aby bylo možné zakládat monografie, nebo periodika. Možnost vyhledávání ve formuláři pro zakládání nové jednotky pomocí ISBN, EAN, ČNB, OCLC a vlastního identifikátoru. Současnou záložku Metadata skenovacího klienta rozšířit o možnost zadání čísla svazku a názvu svazku v případě monografií a roku + ročníku + čísla v případě periodika. Rozšíření logiky formuláře Metadata o obohacení o metadata souborného záznamu. Je více cest, jak toto obohacení získat, a to: zadáním uživatele, detekce více identifikátorů současně, kdy záznam obsahuje 2 opakování podpole bibliografického záznamu, např. ISBN, kde druhé opakování znamená, že se jedná o identifikátor souborného záznamu díla (bude případně potřebné dodatečné dohledání pomocí Z39.50), dodatečné dohledání souborného záznamu pomocí tlačítka Propojit s jiným souborným záznamem. Dohledání bude probíhat pomocí Z39.50 souborného katalogu ČR. Zasílání nových identifikátorů ze skenovacího klienta na vkládací API projektu Obálky knih.

11 Vkládací API Je API backend serveru a využívá jej v současnosti skenovací klient a v budoucnu bude používat i webový formulář na stránce obalkyknih.cz a crawlovací a harvestovací procesy. Slouží k předávání naskenovaných obrázků a meta dat. Backend server, který slouží jako centrální úložiště a obsahuje logiku. Vkládací API nové informace poskytnuté skenovacím klientem zpracuje a podle nich vytvoří nový záznam + souborný záznam (tabulka book), nebo vytvoří nový záznam a napojí na existující souborný záznam. Naskenovanou obálku, případně obsah následně zpracuje (obálku a náhled první stránky obsahu resampluje a stránky TOC spojí) a pokud je požadované, poskytne k OCR zpracování. Změny API v případě podpory obálek a obsahů vícesvazkových děl a periodik budou znamenat úpravu logiky. API bude rozšířeno o nové parametry part_year, part_volume, part_no a part_note, jako i o parametr id_parent (sloupec tabulky book datového modelu) identifikující nadřízený souborný záznam. Dotazovací API Dotazovací API, podobně jak je tomu v případě vkládacího API, bude rozšíření o nové parametry part_year, part_volume, part_no a part_note. Dotazovacím API je chápáno veřejně dostupné API frontend serveru, tj. API verze 3. Frontend server bude tyto parametry normalizovat a s nově upravenou hodnotou se bude ptát dotazovacího API backend serveru (API v.2). Podobně jak je tomu v současnosti bude API zobrazovat obálku souborného záznamu i u dokumentů na nižších úrovních v případě, že tyto dokumenty neobsahují vlastní obálku, nebo obsah. V případě, že obsahují, bude přes API poskytnuta obálka a obsah naskenovaná právě k danému záznamu.