Masarykova univerzita Fakulta informatiky DIPLOMOVÁ PRÁCE. Identifikátory URN:NBN v prostředí českých knihoven a systém pro jejich správu

Masarykova univerzita Fakulta informatiky DIPLOMOVÁ PRÁCE Identifikátory URN:NBN v prostředí českých knihoven a systém pro jejich správu Brno, 2012 Martin Řehánek

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně dne podpis Vedoucí práce: RNDr. Miroslav Bartošek, CSc.

Poděkování Chtěl bych na tomto místě poděkovat PhDr. Ladislavu Cubrovi za spolupráci na projektu URN:NBN Rezolveru, Ing. Petru Žabičkovi za umožnění se tomuto tématu věnovat a RNDr. Miroslavu Bartoškovi, CSc. za vedení práce. i

Shrnutí Práce popisuje praxi používání perzistentních identifikátorů digitálních dokumentů v českém prostředí i v zahraničí. Důraz je kladen zejména na identifikátor URN:NBN. V druhé části práce se autor zabývá vlastní implementací systému pro správu identifikátorů URN:NBN v národním jmenném prostoru urn:nbn:cz. Systém vychází z podobného nástroje, jehož funkce zachovává a přidává nové. Datový model je rozšířen o nové typy dokumentů. Systém umožňuje různými způsoby přiřazovat identifikátory digitálním dokumentům a udržovat sadu jejich metadat. Vytváření záznamů je možné buď manuálně přes webové rozhraní, nebo použitím zabezpečeného aplikační rozhraní. Záznamy je přes webové rozhraní možné zpětně upravovat. Systém disponuje OAI-PMH rozhraním, přes které mohou externí systémy sklízet uložené záznamy. Přes webové rozhraní je možné administrátory spravovat uživatelské účty pro zapojené instituce. ii

Klíčová slova PID, identifikátor, URN:NBN, URL, resolver, REST, GWT, OAI-PMH, NDK, digitalizace iii

Obsah 1 Úvod 1 2 Rozbor problému 2 2.1 Perzistentní identifikátory.................... 2 2.2 Analogové identifikátory..................... 2 2.3 Digitální identifikátory...................... 2 2.3.1 Syntaxe a sémantika................... 3 2.3.2 Jednoznačnost...................... 3 2.3.3 Perzistence........................ 3 2.3.4 Směrování......................... 4 2.4 Existující identifikační schémata................ 4 2.4.1 DNS............................ 4 2.4.2 URL............................ 5 2.4.3 nestabilita URL..................... 5 2.4.4 Handle........................... 6 2.4.5 DOI............................ 8 2.4.6 ččnb........................... 8 2.4.7 URN............................ 9 2.4.8 URN:NBN........................ 10 2.4.9 Syntaxe.......................... 10 2.5 URN:NBN rezolvery ve světě.................. 10 2.5.1 Německo, Rakousko, Švýcarsko............. 11 2.5.2 Itálie............................ 12 2.5.3 Švédsko.......................... 12 2.5.4 Maďarsko......................... 13 2.5.5 Finsko........................... 13 2.6 URN:NBN v České republice.................. 13 2.6.1 Syntaxe identifikátoru.................. 14 2.6.2 Softwarový systém.................... 14 2.7 URN:NBN resolver od firmy Incad............... 14 2.7.1 Datový model....................... 15 2.7.2 Administrace a přidělování URN:NBN......... 16 iv

2.7.3 Autentizace & autorizace................ 16 2.7.4 Uživatelské rozhraní................... 18 2.7.5 Technologie a kvalita kódu............... 20 2.8 Národní digitální knihovna................... 20 3 Implementované řešení 22 3.1 Úvod................................ 22 3.1.1 Zadání........................... 22 3.1.2 Realizace......................... 23 3.2 Datový model........................... 23 3.2.1 Intelektuální entita.................... 23 3.2.2 Digitální dokument.................... 29 3.2.3 URN:NBN........................ 29 3.2.4 Digitální instance..................... 30 3.2.5 Registrátoři a archivátoři................ 30 3.2.6 Digitální knihovna.................... 31 3.2.7 Katalog.......................... 31 3.2.8 Uživatelský účet..................... 31 3.3 Možnosti systému......................... 32 3.3.1 Životní cyklus URN:NBN................ 32 3.3.2 Správa digitálních instancí................ 35 3.3.3 Registrar-scope identifikátory.............. 35 3.3.4 Rezolvování........................ 36 3.3.5 Uživatelské účty, role a práva.............. 37 3.3.6 Vkladání záznamů.................... 38 3.4 Architektura systému...................... 39 3.4.1 Modul Core........................ 40 3.4.2 Modul Persistence.................... 40 3.4.3 Modul Services...................... 40 3.4.4 Modul Web-common................... 40 3.4.5 Modul Xml........................ 40 3.4.6 Modul Api........................ 41 3.4.7 Modul Web........................ 41 3.4.8 Modul OaiPmhProvider................. 41 3.5 Bezpečnost............................ 41 3.6 OAI-PMH Data provider.................... 41 3.6.1 OAI-PMH......................... 42 3.6.2 Implementace OAI-PMH Provideru pro R2...... 43 3.7 Interakce s dalšími systémy................... 44 3.7.1 Kramerius......................... 44 3.7.2 Transformační modul NDK............... 46 3.7.3 Registr Digitalizace................... 46 v

3.7.4 Sirius........................... 47 3.7.5 Katalogy......................... 47 3.8 I18n................................ 47 4 Zhodnocení výsledků 49 4.1 Další možný rozvoj........................ 49 vi

Kapitola 1 Úvod Internet se s problémem jednoznačné identifikace potýká od svého zrodu. Šlo ale hlavně o identifikaci jednotlivých uzlů v síti, ať už na úrovni adres protokolu IP, nebo doménových jmen. Svět knihoven problematiku identifikátorů také zná, avšak z jiného pohledu. Do nedávné doby se vydavatelé, knihovníci a archiváři zabývali jen identifikací fyzických dokumentů, jako jsou knihy, rukopisy, obrazové, či hudební materiály a jiné. Nyní se ale i oni setkávají s poptávkou společnosti po dostupnosti informací online přes světovou webovou síť. Vznikají tak digitální knihovny, které zprostředkovávají nejrůznější díla v digitální podobě, ať už zpětně digitalizovaná, nebo rovnou jako digitální vzniklá. Vyvstává pak potřeba díla globálně jednoznačně a dlouhodobě identifikovat tak, aby je byl uživatel schopen na základě identifikátoru vyhledat a případně zobrazit, pokud to umožňují pravidla přístupu. 1

Kapitola 2 Rozbor problému 2.1 Perzistentní identifikátory 2.2 Analogové identifikátory Tímto pojmem budeme označovat perzistentní identifikátory, které identifikují fyzická díla na různých úrovních podle [8], ale nejčastěji na úrovni manifestu. Může se jednat o díla v rozličných fyzických podobách, ať už tištěná, ručně psaná, ve formě hudebního CD, notové partitury či mikrofilmu. Analogové identifikátory bývají přítomny v katalozích knihoven a slouží čtenáři k vyhledávání a k citacím. Samotné knihovny je využívají ke komunikaci s jinými institucemi, tedy třeba k akvizici či synchronizaci katalogů. Typickými příklady jsou ISBN, ISSN, SICI anebo ISMN. Za jejich přidělování typicky zodpovídá decentralizovaná agentura, jejíž národní složky přidělují identifikátory v rámci vymezeného podprostoru. Častou vlastností těchto identifikátorů je jejich přítomnost ve fyzickém médiu, např. ISBN se tisknou do samotných knih. Nemusí to být ale pravidlem, zejména díla vzniklá dříve než samotný identifikační systém logicky identifikátory neobsahují. 2.3 Digitální identifikátory Za digitální identifikátory budeme považovat jen ty identifikátory, které identifikují díla v digitální podobě. Od digitálního identifikátoru se často očekává nová vlastnost, kterou digitální svět umožňuje, a tou je existence směrovací služby. Viz 2.3.4. Hranice mezi analogovými a digitálními identifikátory není ostrá. Např. ISBN se v malé míře přidělují i e-bornům 1, plní tedy i funkci digitálních identifikátorů. 1 Díla, která rovnou vznikla v digitální podobě 2

2.3.1 Syntaxe a sémantika Tvar identifikátoru vždy podléhá syntaxi definované konkrétním identifikačním schématem. Otázkou je, zda má identifikátor nést i sémantiku. Odpověď bývá různá. ISBN v sobě kóduje druh díla (např. 978 pro knihy), dále zemi vzniku, vydavatele. Poté následuje samotný kód díla a kontrolní součet. ISSN naopak sestává pouze z kódu díla a kontrolního součtu. Celkově převládá názor, že by identifikátor měl plnit jen jednu funkci, a to identifikovat objekt. Není proto vhodné, aby nesl jakoukoliv další sémantiku. Výjimkou jsou hierarchické identifikátory, u kterých by ale část identifikující samotný objekt (v nějakém kontextu) opět další sémantiku nést neměla. 2.3.2 Jednoznačnost Pokud by se stalo, že dva různé objekty mají přiřazen stejný identifikátor, nemohlo by z principu fungovat směrování a celé identifikační schéma by postrádalo smysl. Jediným způsobem, jak jednoznačnost zajistit, je existence autority, která identifikátory přiděluje. Ta může fungovat dvojím způsobem. Centrální služba je jednodušší na implementaci, je však méně pružná. Organizace, která službu provozuje, musí veškerou agendu spojenou s přiřazováním identifikátorů řešit sama. Služba musí být schopna vyřizovat velké množství požadavků a její výpadek ohrozí všechny účastníky. Hierarchický systém funguje tak, že centrální autorita rozděluje prostor identifikátorů na jednotlivé podprostory. Tyto podprostory pak spravují lokální autority, které buď rovnou identifikátory přiřazují, nebo opět podprostor rozdělí a svěří zodpovědnost za přiřazování autoritám na nižší úrovni. Nejjednoduššími a nejčastějšími způsoby rozdělení prostoru jsou použití prefixů (URN:NBN) nebo sufixů (DNS). Výhody spočívají ve větší škálovatelnosti celého systému, samotný provoz naopak může být náročnější, protože klade požadavky na autority na nižší úrovni hierarchie. Mluvíme-li zde o jednoznačných identifikátorech, vždy máme na mysli jednoznačnost globální, pokud nebude explicitně řečeno jinak. 2.3.3 Perzistence Perzistence identifikátoru znamená jeho dlouhodobé uchování a platnost i po zániku samotného digitálního díla. Pokud by perzistence zajištěna nebyla, 3

mohlo by se stát, že by identifikátor dříve náležící dílu již neexistujícímu byl nově přiřazen jinému dílu. Recyklace identifikátorů je velmi nežádoucí, protože by nepřinesla nic jiného než chaos při zpracování starších záznamů externích systémů, které tyto identifikátory používají. Perzistence není vlastnost identifikátoru samotného, musí být zajištěna systémem trvalé identifikace. 2.3.4 Směrování Účelem služby zajišťující směrování 2 je zobrazit uživateli samotné dílo na základě hodnoty digitálního identifikátoru. To je realizováno přesměrováním webového prohlížeče do digitální knihovny na stránku, na které je konkrétní dílo zobrazeno, anebo je umožněno stáhnout si digitální dílo do počítače k zobrazení v jiném programu či prohlížečce. Může existovat více lokací, na kterých je digitální dílo dostupné. Potom musí směrovací služba rozhodnout, do které z nich přesměrovat aktuální uživatelský požadavek. Dalším možným řešením je zobrazit seznam dostupných lokací, z kterých si klient vybere. Pokud je klientem jiný systém, může tak rozložit zátěž a přistupovat k oběma lokacím paralelně. Významnou vlastností je možnost měnit směrování při zachování hodnoty identifikátoru. Tuto vlastnost má např. systém Handle (2.4.4), u URL (2.4.2) je toto naopak velkým problémem. 2.4 Existující identifikační schémata 2.4.1 DNS DNS 3 je hierarchický distribuovaný identifikační systém určený pro počítače, služby nebo jiné zdroje připojené k Internetu nebo privátní síti[21]. Podle této definice by se mohl zdát vhodným kandidátem pro identifikační schéma digitálních děl. Je však příliš svázaný s infrastrukturou Internetu a rozšíření ve směru obecnější identifikace (stejně jako mnohá jiná zvažovaná rozšíření) odvádějí pozornost od jeho primární funkce, kterou je identifikace počítačů a služeb. DNS se na věci dívá optikou sítí a serverů, od které my ale chceme při hledání globálního identifikačního schématu abstrahovat. Problematické se může jevit také vlastnictví domén - kdo vlastní.cz, vlastní také všechny subdomény jako brno.cz a spilas.brno.cz. 2 rezolver 3 Domain Name System 4

2.4.2 URL URL[22] je typem URI 4 podobně jako URN (viz 2.4.7). Skládá se z názvu protokolu odděleného řetězcem ://, zbytek URL je specifický pro každý jednotlivý protokol. U nejčastěji používaných protokolů, jako HTTP, HTTPS, FTP, následuje DNS jméno (případně rovnou IP adresa), volitelně číslo portu, lokální adresní část, případně parametry dotazu a identifikátor fragmentu. 2.4.3 Nestabilita URL Problémem URL je jeho nestabilita, která plyne z čistě praktických důvodů. DNS část URL nemusí být zachována navěky. Jak se organizace rozvíjejí a mění svou strukturu, často se nevyhnou změnám doménových jmen. Pokud organizace zanikne, nebude dále platit poplatky za vlastnictví domény a ta bude ležet ladem, nebo změní majitele. Naopak perspektivně se rozvíjející projekt může koupit uživatelsky příjemnější doménu a stávající URL se změní. U lokální části URL je tento problém ještě markantnější. Rozličné technologie a rámce pro tvorbu webů a webových portálů pracují s lokální částí různě. Porovnejme například portály vytvořené s pomocí pouze statických webových stránek CGI skriptů PHP Pythonu Adobe Flash Java Servletů AJAX 5 rámců typu GWT 6 U každé z nich vypadá lokální část URL jinak, při změně technologie se tak aktivní URL změní. Technologie se budou dále měnit a s nimi i pohledy na to, jak by měl URL vypadat. Správci webových systémů se sice často snaží vytvářet hezká URL, ale jejich motivací je spíše lepší přijetí uživateli než snaha o perzistenci. Pokud se tedy URL zdroje zneplatní důsledkem změny domény či přechodu na jinou technologii, identifikační systém se rozbíjí. Částečně je možné 4 Uniform resource identifier 5 Asynchronous JavaScript and XML 6 Google Web Toolkit 5

tyto situace řešit algoritmy pro přesměrování 7. Je ale potřeba tyto algoritmy udržovat a stále vlastnit původní doménu. 2.4.4 Handle Systém Handle[18][19] byl vyvinut iniciativou CNRI zprvu za podpory agentury DARPA 8 za účelem perzistentní identifikace zdrojů dostupných na Internetu. Má tedy širší uplatnění než jen v doméně digitálních knihoven. I přes svou propracovanost a vysokou míru rozšíření se Handle nestal IETF standardem, existuje pouze jako RFC memo[20]. Handle je kompatibilní s URN (viz 2.4.7). Syntaxe identifikátoru Syntaxe handle je jednoduchá: <handle> ::= <handle prefix>/<handle suffix> Prefix identifikuje jmennou autoritu a je přidělován GHR. Autorita si může od přiděleného prefixu vytvářet tečkovou notací odvozené prefixy - autorita s prefixem 12345 vlastní také prefixy 12345.1 a 12345.1.1. Takto je možné definovat hierarchii autorit. Suffix může obsahovat jakékoliv znaky z Unicode 2.0, rozlišuje se velikost písmen. Tato volnost umožňuje zapojení různých, již existujících, schémat. Jedná se o dvojúrovňový hierarchický model - kořenový uzel se nazývá Global Handle Registry (GHR) a uzly druhé úrovně jsou Local Handle Service (LHS). GHR se zapojuje v první fázi rezolvování. Podle handle prefixu vybere server, který náleží správné LHS, a vrátí jeho identifikátor. Server patřící LHS potom pro handle suffix vrátí URL zdroje, seznam URL, případně metadatový záznam. Kromě těchto dvou typů uzlů existují ještě cache servery 9 a proxy servery 10. Distribuované rezolvování Systém dovoluje škálovat LHS a zajistit tak větší dostupnost, rychlejší odezvu a odolnost proti výpadkům. Služba se skládá z jednoho, nebo více míst (site). Místo obsluhuje jeden, nebo více serverů. Servery pak pro handle suffix vracejí jednu, případně více, URL. Výběr správného serveru je realizován protokolem Handle. 7 Pro Apache HTTP Server např. modulem mod_rewrite. 8 Defense Advanced Research Projects Agency - grantová agentura ministerstva obrany USA. 9 uchovávají odpovědi na časté dotazy z cizích LHS 10 pro dotaz v podobě URL vytvoří dotaz v protokolu Handle a vrátí jeho odpověď 6

Změna mapování Důležitým prvkem je možnost změnit mapování handle na URL (seznam URL). Takto je možné zachovat funkční handle i při přesunu zdroje, nutná je ale kooperace ze strany poskytovatele zdroje. Použití Handle je opravdu masově používaný systém. Podle http://handle.net/factsheet.html k dnešnímu dni existuje pět paralelních instancí GHR, které dohromady obsluhují 70 100 miliónů požadavků na rezolvování měsíčně. Existuje mnoho aplikací, které využívají Handle ke správě svých digitálních objektů. Pro ilustraci uvádíme některé příklady: DOI je identifikační schéma postavené nad Handle. Viz 2.4.5. PILIN[17][26] je australský projekt budovaný mezi léty 2006 2007, jehož ambicí bylo vytvoření národní infrastruktury perzistentních identifikátorů pro dokumenty akademické povahy. Kramerius 3 (viz 3.7.1) je stále rozšířený předchůdce digitální knihovny Kramerius 4, která je důležitým prvkem projektu NDK2.8. Dspace[28] je digitální repozitář a knihovna. V Česku se používá v několika významných českých vysokých školách 11. Jde o otevřený software vyvíjený pod licencí BSD. DigiTool je komerční digitální knihovna od izraelské firmy Exlibris, která stojí také za rozšířeným knihovním katalogem Aleph. Systém je hojně používán hlavně v Severní Americe, u nás např. v Ústavu výpočetní techniky UK nebo v Ústřední khihovně VUT. NDLP 12 je program Kongresové Knihovny 13 zaměřený na digitalizaci a zpřístupnění kulturního a historického dědictví USA. NCSTRL 14 je federativní knihovna, která zprostředkovává jednotný přístup k technickým dokumentům z oboru výpočetní techniky. Ty jsou umístěny v digitálních knihovnách jednotlivých členů. 11 http://www.dspace.cz/instalacecr.html 12 National Digital Library Program 13 Library of Congress je národní knihovnou USA. 14 Networked Computer Science Technical Reference Library 7

2.4.5 DOI DOI 15 je komerční systém, který vychází z Handle. Jeho použití se platí ročními příspěvky, které vycházejí z počti identifikovaných objektů. Definuje složitý datový model. Chce-li účastník obdržet identifikátor, musí do systému vložit metadata, která musí být v souladu s tímto modelem. Podporuje takové služby, jako DRM 16 2.4.6 ččnb Česká národní bibliografie Česká národní bibliografie[23][24] je služba, která registruje tiskovou produkci vydanou v České republice. Tuto službu, společně s archivací produkce na základě práva povinného výtisku, plní Národní knihovna ČR. Od roku 1996 je v Česká národní bibliografie online dostupná v elektronické podobě. Technicky je to realizováno bází ČNB v katalogu Aleph Národní knihovny. Číslo ČNB Číslo České národní bibliografie[25] (ččnb) bylo zavedeno v roce 2010 jako jednoznačný identifikátor záznamů v ČNB. Tento identifikátor byl zpětně přiřazen všem záznamům z ČNB, které vznikly po roce 1800. ččnb ale není možné přidělit dokumentům spadajícím do kategorie šedé literatury. Jde například o: vysokoškolské a habilitační práce katalogy výstav, aukcí, veletrhů, divadel nepublikované výzkumné zprávy, interní dokumenty propagační materiály (turistické, politické, obchodní) ččnb má tvar <ččnb> ::= ccnb: <ID>, přičemž ID je devítimístné číslo. Přidělování ččnb zajišťuje NK na základě povinného výtisku. Ostatní knihovny pak při katalogizaci zjišťují ččnb z katalogu NK. Předpokladem ale je, že je dané dílo přítomno v ččnb. Pokud tomu tak není, může být požádáno o dodatečné přidělení ččnb. 15 Digital Object Identifier 16 digital rights management 8

Nevýhody Největším problémem ččnb je skutečnost, že bylo zavedeno až v roce 2010, poté co již proběhla část digitalizace. Tento identifikátor tak není přítomen v metadatech digitálních dokumentů, což stěžuje jejich propojení s fyzickými dokumenty. Z tohoto pohledu je největší objem digitalizace naštěstí teprve před námi. Z pohledu digitalizace je problematická také nemožnost použít identifikátor pro šedou literaturu. Ta povětšinou nedisponuje ani identifikátory ISBN či ISSN a nebude tak možné jednoznačně propojit fyzický a digitální dokument. 2.4.7 URN URN 17 [2] je typem URI a slouží jako perzistentní identifikátor nezávislý na lokaci zdroje (na rozdíl od URL, který je popsán v kapitole 2.4.2). Je to obecný koncept, který se pokouší sjednotit různé typy identifikátorů pod jedním jmenným prostorem. Syntaxe URN[1] je definovaná takto: <URN> ::= urn: <NID> : <NSS> V části urn nezáleží na velikosti písmen. NID definuje jmenný prostor identifikátorů[3] čili konkrétní identifikační schéma. Mezi definované jmenné prostory patří UUID[30], ISBN 18, IETF 19 a další[5][7], zejména NBN[4]. Název jmenného prostoru může obsahovat velká a malá písmena latinské abecedy, číslice a znak -, tímto znakem ale nemůže začínat. Délka NID je omezena maximálně na 32 znaků. Záleží zde na velikosti písmen. NSS je identifikátor v konkrétním identifikačním schématu. Identifikátor se skládá z velkých a malých písmen latinky, číslic a speciálních znaků ), (, +,,, -,., :, =, @, ;, $, _,!, *,. Délka je obecně neomezená. Některé další znaky je možné zapsat escape sekvencí %AB, přičemž AB jsou cifry hexadecimální číslice, která kóduje oktet znaku v znakové sadě Unicode. Syntaxi dále upřesňuje konkrétní identifikační schéma - může být omezena povolená množina znaků, délka identifikátoru, či definována ekvivalence malých a velkých písmen. 17 Uniform Resource Name 18 http://tools.ietf.org/html/draft-hakala-rfc3187bis-isbn-urn-00 19 http://tools.ietf.org/html/rfc2648 9

2.4.8 URN:NBN Termínem URN:NBN budeme označovat URN identifikátor za použití schématu NBN[4]. Za NBN stojí Juha Hakala z finské národní knihovny. URN:NBN může identifikovat různé typy objektů, nemusí jít nutně o digitální objekty. Je možné jej použít například pro fyzické dokumenty a v rámci rezolvování vracet jejich metadata. 2.4.9 Syntaxe Identifikátor URN:NBN existuje v jedné z těchto tří podob: 1. URN:NBN:<kód země>-<nbn string> 2. URN:NBN:<kód země>:<kód podprostoru>-<nbn string> 3. URN:NBN:<jiný prefix>-<nbn string> Kód země je dvojmístný kód podle ISO 3166. Za všechny URN:NBN pod tímto prefixem zodpovídá národní knihovna dané země. První možnost odpovídá situaci jedné národní knihovny, která sama přiděluje identifikátory pro celý národní prostor. Pokud existuje pro určitý kód země více národních knihoven nebo je jiný důvod, proč pravomoci rozdělit, je vhodné používat URN:NBN druhého typu a rozdělit národní prostor na podprostory. Třetí možnost je jen teoretická a v praxi nepoužívaná. Pro situace, kdy není možné použít národní kód podle ISO 3166, bude přidělen jiný prefix. Autoritou pro přidělování těchto prefixů je americká Kongresová Knihovna. Jejím úkolem je také zveřejňovat registr prefixů, jak je popsáno v [4]. Tento registr ale neexistuje. NBN string Syntaxe NBN string není nijak dále omezena, platí pravidla pro URN. Očekává se, že ji správci jednotlivých národních prostorů upřesní, bude-li to potřeba. Omezení syntaxe závisí zejména na konkrétním způsobu generování/přidělování URN:NBN v národním kontextu. 2.5 URN:NBN rezolvery ve světě Už době vzniku specifikace URN:NBN[4] v roce 2001 používali tento identifikátor národní knihovny ve Finsku, Švédsku, Norsku. Později se připojilo Německo, Rakousko, Švýcarsko, Itálie, Nizozemí, Maďarsko a Česká republika. Implementováno bylo několik různých systémů pro správu URN:NBN, které zde krátce popíšeme. 10

2.5.1 Německo, Rakousko, Švýcarsko V rámci projektu EPICUR 20 byl v letech 2002 2005 německou národní knihovnou vyvinut systém pro správu a resolvování URN:NBN[6], který byl určen primárně pro e-born díla, zejména závěrečné vysokoškolské práce. Na výstup projektu EPICUR později navázal projekt MetaResolver 21. Později se do tohoto systému připojilo také Rakousko a Švýcarsko. Jako součást výstupu projektu EPICUR byly uvolněny dvě verze pluginu pro webové prohlížeče. 1. Verze určená pro prohlížeče postavené na renderovacím jádru Gecko, která údajně funguje pro tyto verze webových prohlížečů: Mozilla 1.5 Netscape 7.1 Firefox 0.8 Jedná se o velmi zastaralé prohlížeče, Netscape dokonce již neexistuje. Proto se nedá očekávat, že bude plugin fungovat i v jejich novějších verzích. Podle http://en.wikipedia.org/wiki/timeline_of_web_browsers je evidentní, že plugin vznikal na přelomu let 2003 a 2004. Přesto jsem instalaci vyzkoušel v aktuální verzi Firefoxu (12.0) pro operační systém Ubuntu 11.04. Prohlížeč nebyl schopen plugin nainstalovat a považoval jeho instalační soubor za poškozený. 2. Verze pro Internet Explorer ve verzi 5.0 a výše. Jeho funkčnost jsem netestoval. Plugin funguje jako protocol handler 22 pro protokol urn. Pokud obsah adresního řádku začíná prefixem urn:nbn:, je tento prefix nahrazen řetězcem http://nbn-resolving.de/urn/resolver.pl?urn=urn:nbn:. Na základě takto vytvořeného dotazu vrátí resolvovací služba požadovaný dokument. Jak se plugin zachová pro jiný jmenný prostor než nbn, mi není známo. URN:NBN Cluster Na konci roku 2011 vzešla ze strany Deutsche Nationalbibliothek iniciativa URN:NBN Cluster, která si bere za cíl zjednodušit nasazení URN:NBN i mimo německé prostředí. Mělo by vzniknout konsorcium institucí, které by se společně podílely na vývoji systému vycházejícího z Metaresolveru. 20 http://www.dnb.de/en/wir/projekte/abgeschlossen/epicur.html 21 http://sourceforge.net/projects/metaresolver/ 22 Aplikace nebo kód zajišťující reakci na protokol, který je prohlížeči neznámý. Typicky je protokol mailto zpracováván externím emailovým klientem a https zase obsluhuje modul prohlížeče pro podporu SSL. 11

2.5.2 Itálie Od roku 2007 pracuje sdružení italských institucí na vývoji vlastního systému, který přiděluje a rezolvuje URN:NBN[10]. Projektu se účastní množství významných institucí, jako je Fondazione Rinascimento Digitale, Univerzita v Miláně, Národní knihovna ve Florencii, Národní Ústřední knihovna v Římě, Consorzio Interuniversitario Lombardo per l elaborazione automatica a jiné. Rezolvování zde funguje hierarchicky a distribuovaně (viz oddíl 2.3.2) a podobá se systému Handle (2.4.4). Uzly systému tvoří strom, přičemž registrace NBN provádějí listové uzly, které zodpovídají za daný podprostor. Po registraci NBN se vytvořený záznam replikuje nadřazenému uzlu. Nelistové uzly pak obsahují záznamy všech svých potomků a kořen celého stromu má k dispozici záznamy všechny. Každý uzel tak může rezolvovat jakékoliv URN:NBN. Buď jeho záznam sám vlastní, nebo se na něj zeptá rodičovského uzlu. Kvůli optimalizaci odezvy navíc uzly disponují cache pro uložení často dotazovaných záznamů. Hierarchické je také definování pravidel. Pravidla uzlu vždy musí splňovat pravidla rodičovského uzlu, která mohou být dále upřesněna. Pravidla definují[10]: syntaxi NBN kterým zdrojům je povoleno NBN přiřazovat granularitu zdrojů, kterým jsou NBN přiřazovány (kniha, článek, kapitola,... ) způsob auditů přidružených repozitářů Systém je postaven na Java EE technologiích a svobodném software jako Apache Tomcat a PosgtreSQL. I přes předchozí spolupráci s tímto sdružením se v roce 2009 NKP rozhodla pro realizaci vlastního systému. Mezi hlavní důvody tehdy patřily rozdílné požadavky na URN:NBN rezolver v českém prostředí, obava z narůstajícího zpoždění italského projektu a nedostatečná komunikace obou stran. 2.5.3 Švédsko Švédská národní knihovna 23 byla jednou z prvních organizací, které začaly používat URN:NBN. Stalo se tak navázáním spolupráce s rozvíjejícím se systémem DiVA[15]. Samotný URN:NBN resolver je k dispozici na http://urn.kb.se/start 23 http://www.kb.se/isbn-centralen/urnnbn/ 12

Projekt DiVA začal vznikat na půdě švédské Uppsala University v roce 2000 a v roce 2003 byl hotový funkční software. Později se přidaly další čtyři švédské a jedna dánská univerzita. Původním záměrem bylo zjednodušit procesy související s publikací absolventských prací, publikací a dalších dokumentů, které vysokoškolské prostředí produkuje. DiVA je tedy systém pro elektronickou publikaci a archivaci dokumentů. Obsahuje zejména: nástroje pro samotnou publikaci konfigurovatelnou transformaci mezi rozličnými metadatovými formáty rozhraní pro publikaci do dalších systémů (mj. OAI-PMH provider) LTP 24 modul PID manager, který pro všechny objekty používá URN:NBN DiVA Portal 25 - webové rozhraní, ve kterém je možné prohledávat či procházet záznamy ze všech zapojených instalací systému DiVA 2.5.4 Maďarsko V Maďarsku se existuje URN:NBN rezolver na http://nbn.urn.hu/. Bohužel se mi ale nepodařilo dohledat k němu nějaké materiály v angličtině a na emaily mi dlouhodobě nikdo neodpovídá. 2.5.5 Finsko Finové stáli za zrodem URN:NBN, konkrétně Juha Hakala z finské národní knihovny[4]. Finský národní resolver 26 umí rezolvovat nejen URN:NBN, ale i další URN schémata, například URN:ISBN a URN:ISSN. Jejich systém je hierarchický. Těm institucím, které jsou schopné automaticky dodávat metadata do centrálního resolveru, je přidělen jmenný podprostor v rámci národního prostoru URN:NBN. Pro část NBN string se používá UUID[30]. 2.6 URN:NBN v České republice V Národní knihovně ČR bylo v roce 2007 rozhodnuto o tom, že se začne používat identifikátor URN:NBN pro identifikaci digitálních dokumentů (2.7.1 nebo 3.2.2), a to hlavně těch, jejichž fyzické předlohy nemají přiřazený jiný identifikátor (ISBN, ISSN, ččnb). 24 long time preservation - dlouhodobá archivace dat 25 http://www.diva-portal.se/ 26 http://urn.fi/ 13

2.6.1 Syntaxe identifikátoru Obecná syntaxe URN:NBN je popsána v 2.4.8. Existují tři možnosti konkrétní syntaxe, z kterých bylo nutné vybrat a vybranou syntaxi dále upřesnit. Pro českou republiku (kód země cz) byla zvolena 2. varianta: urn:nbn:<kód země>:<kód podprostoru>-<nbn string> V celém identifikátoru není důležitá velikost písmen. Základní tvar URN:NBN je v lower-case notaci. Kód podprostoru Kód podprostoru identifikuje instituci, většinou knihovnu. Může jím být: Sigla pro instituce, kterým byl tento kód Národní knihovou ČŘ přidělen. Sigla[16] je tvořena třemi písmeny 27 a třemi číslicemi. Jiný kód pro ostatní instituce. Ten je tvořen sekvencí písmen a číslic o délce 1 5 znaků. NBN string NBN string se skládá z právě 6 alfanumerických znaků. 2.6.2 Softwarový systém Nejprve se uvažovalo o použití italského řešení[10] (viz 2.5.2), z čehož nakonec z různých důvodů sešlo. V letech 2009 2001 byl pak firmou INCAD pro NKP vyvinut vlastní rezolver[11] 28. Viz 2.7. Tímto rezolverem bylo přiřazeno necelých 11000 URN:NBN. V polovině roku 2011 bylo zřejmé, že bude URN:NBN nutné zapojit do projektu NDK. Stávající rezolver nedisponoval prostředky pro napojení na další systémy. Proto byl autorem práce na podzim téhož roku na základě požadavků z NKP navržen konkrétní způsob rozšíření rezolveru. Autor práce následně toto rozšíření implementoval, výsledkem čehož je rezolver popisovaný v této práci (viz 3). 2.7 URN:NBN resolver od firmy Incad Rezolver vyvinutý firmou INCAD budeme pro odlišní od nového rezolveru dále nazývat Rezolver-INCAD nebo zkráceně R1. Ten byl pevně navázaný na Registr Digitalizace (viz 3.7.3). Rezolver-INCAD získával data přímým 27 Standardně se používají velká písmena, základní tvar URN:NBN (a tedy i sigla) je ale v lower-case notaci. 28 V době zveřejnění práce stále dostupný na http://resolver-old.nkp.cz. 14

přístupem do databáze RD, navíc poté upravoval záznamy v databázi RD 29. Toto řešení má zřejmé nevýhody: Rezolver-INCAD musí reflektovat databázové schéma Registru Digitalizace. Vývoj R1 byl ale ukončen na jaře roku 2011 (poslední změna v kódu nastala 21. 4.), zatímco RD je vyvíjen dál a nelze tak vyloučit změnu databázového schématu. R1 používá RAD 30 framework aplikator 31 z dílny INCADu. Ten zde slouží zejména k přístupu do databáze. Aplikator je použit v dalších produktech INCADu, jako je právě RD nebo Kramerius 4 (viz 3.7.1), a jak pokračuje vývoj těchto systémů, mění se i samotný aplikator. Již v říjnu 2011 nebylo možné zkompilovat Rezolver-INCAD ze zdrojových kódů na Google code právě kvůli nekompatibilním změnám v modulu aplikator. 2.7.1 Datový model Koncepční model Koncepční model Rezolveru je popsán na obrázku 2.1. Intelektuální entita reprezentuje předlohu díla, které bylo digitalizováno. Neodpovídá ale jednotce, nýbrž manifestu podle [8]. K intelektuální entitě se váží identifikátory ISBN, ISSN, ččnb. Digitální reprezentace odpovídá množině výsledků digitalizace tedy balíku obrázků a metadat. Právě tomuto objektu je přiřazeno URN:NBN. Digitální instance reprezentuje instanci digitální reprezentace v některé digitální knihovně. Hlavním atributem je tedy URL. Ač se jedná o strom, na základě způsobu získávání dat bylo zjištěno, že prakticky má každý uzel právě jednoho potomka. Větvící faktor je tedy 1. Fyzický model Z koncepčního modelu vychází model fyzický (viz 2.2), který již definuje jednotlivé databázové tabulky a vztahy mezi nimi. Tabulka IntelektualniEntita odpovídá intelektuální entitě, DigitalniReprezentace digitální reprezentaci a Zverejneno digitální instanci. DigitalniKnihovna pak odpovídá digitální knihovně. Nemůžu nezmínit významné chyby v takto modelované databázi: 29 Změna hodnoty atributu Mainflag tabulky Predloha. 30 rapid application development 31 http://code.google.com/p/aplikator/ 15

Obrázek 2.1: Koncepční model systému Rezolver-INCAD[46]. Není vhodné pojmenovávat tabulky a atributy česky. Hlavně pokud jde o otevřený software, u kterého se dá očekávat použití či rozšíření někým jiným. Téměř všechny atributy jsou typu string, ačkoliv jsou do některých z nich ukládány hodnoty jiných typů. Také omezení na délku řetězce někdy postrádá smysl. Proč má mít atribut SIGLA 20 znaků, když je sigla identifikátorem instituce o pevné délce 6 znaků? Hodnota žádného atributu kterékoliv tabulky nemusí být definována (kromě primárních a cizích klíčů). To platí i pro URN:NBN (viz 2.7.3). Bylo by to v pořádku, pokud by se hodnoty atributů kontrolovaly na aplikační úrovni, ale to se evidentně neděje. URN:NBN jsou atributem digitální reprezentace. Pokud je digitální reprezentace odstraněna, zanikne i URN:NBN, čímž přijdeme o jeho perzistenci a potenciálně unikátnost (viz 2.7.3). 2.7.2 Administrace a přidělování URN:NBN Systém obsahuje administrativní rozhraní, které je určené pouze pro správce celého systému. V tomto rozhraní je možné záznamy vyhledávat (podle hodnoty vybraného atributu) a poté upravovat. Druhou funkcí je načítání záznamů z Registru Digitalizace a následné přiřazení URN:NBN. 2.7.3 Autentizace & autorizace Definice uživatelů je ponechána na aplikačním serveru 32. Autorizace přístupu k administrativnímu rozhraní je realizována přiřazením role urnnbn. Autentizace je řešena metodou basic access authentication[50]. Tato metoda 32 typicky Apache Tomcat 16

Obrázek 2.2: Fyzický model systému Rezolver-INCAD[47]. není sama o sobě bezpečná, protože se protokolem HTTP přenáší v otevřené podobě uživatelské jméno a transformované heslo 33, které lze jednoduše dekódovat. Bez použití SSL/TLS 34 je tak v některých případech 35 možné odposlechnout přihlašovací údaje. V tomto rizikovém režimu byl Rezolver-INCAD po celou dobu ostrého provozu na adrese resolver.nkp.cz, dokud nebyl nahrazen novou verzí. Načtení dat Nové záznamy jsou do databáze Rezolveru získávány tímto postupem: 1. Administrátor klikne na Načíst data. 2. Z databáze RD se stáhnou všechny záznamy z tabulky Predloha, které zatím staženy nebyly. Tedy záznamy mající hodnotu příznaku Mainflag rovnu 1. 3. Z každého takového záznamu jsou vytvořeny tři záznamy v databázi resolveru v tabulkách: IntelektualniEntita 33 Řetězec jméno:heslo zakódovaný algoritmem Base64. 34 Secure Socket Layer/Transport Layer Security protokoly pro šifrování transportní vrstvy. Kombinací HTTP a SSL/TLS je protokol HTTPS. 35 Např. při připojení přes nešifrovanou WIFI bez použítí VPN. 17

DigitalniReprezentace Zverejneno Všimněte si, že zmiňovaný postup vytváří faktickou kardinalitu vztahů 1:1:1 mezi těmito třemi tabulkami. 4. V databázi RD je v příslušném záznamu tabulky Predloha nastavena hodnota příznaku Mainflag na 2. Není třeba rozlišovat intelektuální entity, digitální reprezentace a digitální instance (tabulka Zverejneno), protože jsme zjistili, že vzhledem ke kardinalitě 1:1:1 jde prakticky o jeden logický záznam rozprostřený mezi tři tabulky. Můžeme tedy od teď mluvit o záznamech. V tomto okamžiku existují v Rezolveru záznamy, které nemají přiřazeno žádné URN:NBN! Přidělení URN:NBN Nyní je proto potřeba provést operaci přiřazení URN:NBN, a to buď pro jednu konkrétní digitální reprezentaci, nebo pro všechny ty digitální reprezentace, které URN:NBN přiděleno nemají. Toto řešení je podivné. Dalo by se očekávat, že bude existovat jedna operace, která bude implementovat získání dat a vytvořeným záznamům bude automaticky přidělovat URN:NBN. Pro rozdělení na dvě nezávislé operace neexistuje žádný důvod. Naopak nastává nežádoucí existence záznamů v Rezolveru, které nemají přiřazeno URN:NBN. Nelze tak kontrolovat integritu dat na úrovni databáze zavedením omezení NOT NULL 36. Mazání záznamů Další operací nad záznamy je jejich mazání. Ta provede odstranění záznamu ze všech tří tabulek. Tím je ale porušena perzistence identifikátoru ztrácíme informaci, že konkrétní URN:NBN již přiřazeno bylo. Při použití jiné implementace generování NBN stringu 37 může být toto URN:NBN znovu přiřazeno a dojít tak dokonce k narušení jednoznačnosti identifikátoru. 2.7.4 Uživatelské rozhraní Vyhledávání záznamů Oproti tomu, co tvrdí dokumentace[12], je možné vyhledávat pouze podle hodnot identifikátorů 38 URN:NBN, ččnb, ISBN a ISSN. Například zá- 36 Integritní omezení NOT NULL atributu databázové tabulky znamená, že není možné vložit do tabulky záznam, jehož hodnota pro tento atribut není definovaná. 37 To v rámci nové implementaci celého rezolveru opravdu nastalo. 38 Musí být nalezena přesná shoda ve vyhledávaném řetězci a hodnotě identifikátoru. 18

znam pro urn:nbn:cz:aba001-000343 39 má přiřazené ččnb cnb001781646. Podle ččnb lze záznam opět vyhledat, nikoliv ale pro hodnoty Číslo RDCZ ( Pr000011443 ), Číslo zakázky ( 44790 ) nebo Financováno ( norské fondy ). Výsledky vyhledávání zobrazují jen ty atributy jednotlivých záznamů z databáze, které mají definovanou hodnotu. Rezolvování Předpokládejme, že je Rezolver-INCAD dostupný na doméně resolver-old.nkp.cz a naše URN:NBN je urn:nbn:cz:aba001-0001qc. Zobrazení metadat je dostupné na URL http://resolver-old.nkp.cz/urnnbn/urn:nbn:cz:aba Odpovědí na tento dotaz je HTTP kód 302 a přesměrování na http://resolver-old.nkp.cz/ur Tato stránka je vstupním bodem uživatelského rozhraní GWT aplikace. Stránka realizuje jedinou funkci a tou je zobrazení záznamů na základě vyhledávání. Proto je parametrem vyhledávaný řetězec, v tomto případě URN:NBN. Vyhledávaný řetězec je v URL přítomen jako URL fragment. Ty se neposílají na server. Vyhledávání a zobrazování funguje tak, že JavaScript v prohlížeči pošle na server AJAXový dotaz s parametrem, jehož hodnotou je vyhledávaný řetězec. Jakmile obdrží odpověď, dynamicky transformuje aktuální stránku a zobrazí výsledky vyhledávání. Je tedy zřejmé, že získávání metadat funguje pouze pro webový prohlížeč podporující JavaScript a není vhodné pro automatizované přístupy jiných systémů 40. Stejným způsobem funguje i http://resolver-old.nkp.cz/urn:nbn:cz:aba001-0001qc. Podle dokumentace by měla být stejná funkčnost dostupná na URL http://resolver-old.nkp.cz/redirect/urn:nbn:cz:aba001-0001qc. Dotaz je ale přesměrován na http://resolver.nkp.cz/urnnbn//urn:nbn:cz:aba001-0001qc. Tento URL není korektní kromě zdvojeného lomítka je vygenerovaná špatná doména. Přesměrování do digitální knihovny funguje na http://resolver-old.nkp.cz/urnnbn/urn:nb Pokud není parametr library definován, zobrazí se pouze metadata. Čili být přesměrováni na některou digitální instanci můžeme být pouze v případě, že víme, v které digitální knihovně se instance nachází. To je prakticky nepoužitelné, navíc v rozporu ze základní myšlenkou rezolvování, která by mohla znít: Známe jméno, nikoliv lokaci. 39 http://resolver-old.nkp.cz/urnnbn/#urn:nbn:cz:aba001-000343 40 Jedinou možností, jak tohle obejít, je s pomocí nástroje, který umí, stejně jako webový prohlížeč, interpretovat JavaScipt a ví, jakou stránku očekávat. 19

2.7.5 Technologie a kvalita kódu Resolver-INCAD je aplikace vyvinutá ve webovém frameworku GWT[53]. Jako taková je použitelná pouze ve webovém prohlížeči nebo jiném programu, který je schopen interpretovat JavaScipt. Není proto možné systém integrovat s dalšími systémy způsobem podle filozofie SOA 41. Aplikace používá pro perzistenci a editaci záznamů modul aplikator. Ten je minimálně od listopadu 2011 s Rezolverem nekompatibilní na úrovni zdrojového kódu. Rezolver tak dnes není možné jednoduše zkompilovat. Aplikace je budována jako otevřený software pod licencí GNU GPL v3 42, používá však komerční databázi Oracle. Kvalita samotného aplikačního kódu je občas otřesná. Je možné najít takové perly, jako třídu nazvanou SomeFunction. Veškeré dotazy do databáze jsou uloženy jako soukromé atributy typu String, jejichž obsahem je celý SQL dotaz. Např. třída NacistData obsahuje tento úsek kódu: p r i v a t e String RDCZPredlohaSelect = " s e l e c t id, urnnbnflag, urnnbn, i d c i s l o, s i g l a 1, digknihovna, skendjvu, skenjpeg, s k e n g i f, s k e n t i f f, skenpdf, skentxt, " +" rozsah, r o z l i s e n i, barevnahloubka, dostupnost, isbn, i s s n, ccnb, druhdokumentu, nazev, autor, vydavatel, rokvyd, mistovyd, u r l, publprac, publdate, financovano, c i s l o z a k a z k y " +" from Predloha where urnnbnflag = 1 " ; @SuppressWarnings ( " unused " ) p r i v a t e String RDCZDigObjSelect = " s e l e c t id, handler from d i g o b j do l e f t o u t e r j o i n x p r e d d i g o b j xdo on do. i d = xdo. rdigobjekt where xdo. rpredloha=? " ; //TODO p o u z i t pro d a l s i Lokace @SuppressWarnings ( " unused " ) p r i v a t e String RDCZInitUpdate = " update Predloha s e t urnnbnflag = 1 where urnnbnflag i s n u l l and financovano i n ( norskefondy, iop, VISK7, povodne ) " ; p r i v a t e String RDCZInstSelect = " s e l e c t value, cz from d l i s t s where classname = cz. incad. nkp. d i g i t a l. I n s V l a s t n i k " ; p r i v a t e String RDCZKnihSelect = " s e l e c t value, cz from d l i s t s where classname = cz. incad. nkp. d i g i t a l. I n s D i g i t a l n i K n i h o v n a " ; 2.8 Národní digitální knihovna Projekt Národní digitální knihovna[31] (NDK) si bere za cíl digitalizaci významné části knižního fondu vydaného na území České republiky v 19. 20. století. Digitalizováno by celkem mělo být okolo 50 000 000 stran. Sekundárním cílem je dlouhodobá a spolehlivá archivace digitalizovaných dokumentů a samozřejmě jejich zpřístupnění veřejnosti v digitálních knihovnách. 41 Service-Oriented Architecture 42 GNU General Public License ve verzi 3 20

Projektu se účastní Národní knihovna České republiky (NKP) a Moravská zemská knihovna v Brně (MZK). Projekt byl schválen v červnu 2010 a od té doby se událo dost práce. Všechny zapojené subsystémy by měly být již téměř hotové a to do takové míry, aby bylo možné v polovině letošního roku nastartovat testovací provoz. Jedním z těchto systémů je právě URN:NBN Rezolver. Dalším systémem je tzv. Transformační modul, který komunikuje s několika systémy a předává mezi nimi transformovaná data. 21

Kapitola 3 Implementované řešení 3.1 Úvod Tato kapitola se popisuje nový URN:NBN Rezolver, který nahradil Rezolver- INCAD. Systém byl implementován autorem práce ve spolupráci s Ladislavem Cubrem z NKP v roli zadavatele a odborného garanta projektu. Tento nový rezolver budeme pro jednoznačnost nazývat Rezolver-v2 nebo R2. 3.1.1 Zadání Rezolver-INCAD popsaný v 2.7 trpí některými neduhy, které byly ve zmíněné kapitole dostatečně popsány. Zejména nedisponuje funkcionalitou nutnou pro zapojení do masové digitalizace v rámci projektu NKD. Nejvýznamnějším nedostatkem je navázanost na Registr Digitalizace a z neexistence aplikačního rozhraní pro importy dat a jejich pozdější získávání ze strany dalších systémů. Mým úkolem bylo navrhnout a implementovat takový systém, který bude mít stejné funkce jako Rezolver-INCAD, a navíc některé další. Hlavní požadavky na rozšíření byly tyto: umožnit jednotlivým institucím samostatnou správu přidělených podprostorů URN:NBN rozšířit datový model a aplikaci o podporu nových typů dokumentů, kromě stávajících monografií a periodik zajistit zapojení do projektu NDK, zejména integraci s Transformačním modulem a Krameriem upravit způsob rezolvování přesměrování na základě zdroje přístupu analyzovat způsoby generování a přidělování URN:NBN, navrhnout řešení a to implementovat 22

implementovat rozhraní pro sklízení záznamů z R2 externími systémy zachovat URN:NBN přiřazená v R1 včetně metadat a digitálních instancí Součástí požadavků byla také definice vyžadovaných typů dokumentů a jejich atributů[51]. V průběhu vývoje se však některé požadavky měnily. Např. bylo ustoupeno od funkce mazání digitálních dokumentů (viz 3.2.2), která je dostupná v R1. Měla být naopak zachována jejich perzistence, stejně jako perzistence URN:NBN. 3.1.2 Realizace Původně jsem zamýšlel převzít kód R1 a upravit jej. Na základě studia kódu a vzhledem k rozsahu zamýšlených změn jsem dospěl k názoru, že bude jednodušší začít celý systém budovat znovu. Nechtěl jsem nadále používat modul aplikátor z důvodu jeho nezávislého vývoje. Databázi Oracle jsem chtěl vyměnit za PostgreSQL. Samotného kódu v projektu Rezolver-INCAD není hodně a jeho kvalita mi připadá nízká. Proto jsem se rozhodl celý začít celý systém budovat znovu. Vycházel jsem ale z původního datového modelu. Také jsem použil kostru aplikace při vývoji modulu web (viz 3.4.7) a zejména základní strukturu a design stránky. Vývoj výsledného systém probíhá pod licencí GNU GPL v2. Zdrojové kódy jsou k dispozici na portálu Google code[48]. Všechny používané knihovny, aplikační server i databáze jsou také otevřenými softwary. 3.2 Datový model Koncepční model základních entit je zakreslen na obrázku 3.1, který ale vykresluje jen základní, nejdůležitější entity. Všechny databázové tabulky a vztahy mezi nimi zobrazuje fyzický model na obrázku 3.2. 3.2.1 Intelektuální entita Intelektuální entita (IE) má stejný význam jako v R1 (viz 2.7.1). Vyjadřuje manifest jednotky předlohy[8], která byla digitalizována. Intelektuální entitu digitálně reprezentuje (viz 3.2.2) jeden nebo více digitálních dokumentů. Více existujících digitálních dokumentů jedné IE znamená, že bylo digitalizováno několik jednotek manifestu téhož díla. Není důležité, zda šlo o různé jednotky, zásadní je, že proběhlo více digitalizací. Záznam IE je uložen v tabulce IntelectualEntity a podle typu IE dále v tabulkách IeIdentifier, Originator,Publication,SourceDocument. 23

Obrázek 3.1: základní entity koncepční model. 24

Obrázek 3.2: fyzický datový model celého systému. 25

Typy intelektuálních entit Systém pracuje s několika typy intelektuálních entit. Vztahy mezi nimi, zejména dědičnost, ilustruje obrázek 3.3. Obrázek 3.3: vztahy mezi různými typy intelektuálních entit. Typ dokumentu je určen atributem entitytype, který obsahuje některou z hodnot MONOGRAPH, MONOGRAPH_VOLUME, PERIODI- CAL, PERIODICAL_VOLUME, PERIODICAL_ISSUE, THESIS, ANALYTICAL nebo OTHER. Aplikaci je možné rozšířit o nové typy dokumentů bez nutnosti změny databázového schématu 1. K upřesnění typu dokumentu v lidsky čitelné podobě slouží atribut documenttype. Jeho využití je vhodné, například pokud chceme u typu MONO- GRAPH rozlišit, zda se jedná o knihu, rukopis nebo starý tisk. Nutné je upřesnění druhu používat u typu OTHER 2, zde se můžou objevit hodnoty jako mapa, grafika,... Jednotlivé typy IE se dále liší tím, zda mohou obsahovat záznam v tabulkách Publication, Originator a SourceDocument. Navíc některé atributy samotné tabulky IntelectualEntity jsou použitelné jen pro vybrané typy IE. Konkrétně se jedná o atributy digitalborn a de- 1 Byla by ale potřeba aktualizovat aplikační kód. 2 Systém samotný to ale nevynucuje, ani u OTHER nemusí být hodnota documenttype definována. 26

greeawardinginstitution. DigitalBorn je použit pro všechny publikovatelné (viz 3.2.1) typy IE. Je to binární příznak, který označuje, jestli dílo původně vzniklo v digitální podobě. DegreeAwardingInstitution používá pouze typ vysokoškolská práce. Atribut slouží k identifikaci vysoké školy. Bylo by neefektivní jen kvůli nim vytvářet složitější hierarchii dědičnosti mezi typy IE. Pro ty typy IE, kterých se vybraný atribut netýká, je na úrovni aplikace zajištěno, aby jeho hodnota nemohla být vyplněna. Při patřičném vložení do databáze je pak tomuto atributu přiřazena hodnota NULL. Obecně platí princip, že nedefinovanou hodnotu reprezentuje v databázi NULL 3. Identifikátory V R1 byly identifikátory dány napevno databázovým schématem. Jednalo se o atributy ccnb, ISBN, ISSN a jinyid tabulky IntelektualniEntita. Bylo tedy možné, aby existovala IE s definovanou hodnotou ISBN i ISSN, což je nesmysl 4. V R2 existuje pro každý identifikátor záznam v tabulce IeIdentifier, přičemž na aplikační úrovni je pro každý typ IE definovaná sada identifikátorů, které mohou být pro tento typ definovány. Sadu identifikátorů pro jednotlivé typy dokumentů je možné rozšířit bez změny databáze 5. Identifikátor se skládá z typu identifikátoru a hodnoty identifikátoru. Typ identifikátoru nabývá některé z hodnot TITLE, SUB_TITLE, VO- LUME_TITLE, ISSUE_TITLE, ISBN, ISSN, CCNB nebo OTHER. Hodnota identifikátoru pak může obsahovat jakýkoliv text, alespoň z pohledu databáze. Na aplikační úrovni je ale při importu nebo ručním vložení kontrolováno, zda hodnota splňuje definovaná omezení. Vždy je ohraničena maximální délka, u ISBN, ISSN a CCNB se navíc prověřuje korektnost syntaxe. Všimněte si, že za identifikátor se považují i názvové údaje. Tento přístup byl zvolen z toho důvodu, že i typy názvových údajů se liší mezi různými typy IE. Fungují tedy opravdu jako ostatní identifikátory. Navíc to umožňuje jednodušší implementaci vyhledávání podle identifikátorů a názvových údajů 6. Tabulky Originator, Publication a SourceDocument Tabulka Originator reprezentuje primárního původce díla. Záznam se skládá z typu a hodnoty. Typ může být AUTHOR (autor), CORPORATION (korporace) nebo EVENT (akce/událost). Hodnota není nijak omezena 7. Každý 3 a nikoliv třeba prázdný řetězec 4 ISBN se přiřazují monografiím, ISSN periodikům. 5 Opět je nutná změna aplikačního kódu. 6 Stačí prohledávat hodnoty všech atributů idvalue tabulky IeIdentifier. 7 pouze na aplikační úrovni maximální délkou 27