SlideShare a Scribd company logo

Architektura a implementace digitálních knihoven v prostředí sítě Internet

•
•
David Pasek
David Pasek

Cílem práce je charakteristika stávající situace budování digitálních knihoven ve světovém měřítku se zaměřením na problematiku jejich architektury a implementace v podmínkách sítě Internet. Práce se věnuje především důležitým komponentám digitálních knihoven a jejich specifikaci. Mezi důležité komponenty patří digitální objekt, repozitář, katalog a uživatelské rozhraní. V práci jsou rovněž popsány signatury digitálních objektů, které jsou důležité zejména z hlediska bezpečnosti, neměnnosti obsahu a věrohodnosti autora digitálního objektu. Pozornost byla věnována i normám a specifikacím metadat, která jsou velmi důležitá pro budování katalogu a vyhledávání relevantních digitálních objektů. Přínosem práce je podání návrhu optimálního modelu digitální knihovny a ukázky praktických aplikací na navrhovaném modelu.

Science
1 of 84
Download to read offline
1 Univerzita Karlova v Praze Filozofická fakulta Ústav informačních studií a knihovnictví Diplomová práce 2002 Bc. David Pašek
2 Univerzita Karlova v Praze Filozofická fakulta Ústav informačních studií a knihovnictví Bc. David Pašek Architektura a implementace digitálních knihoven v prostředí sítě Internet Diplomová práce Praha 2002
3 Vedoucí diplomové práce: PhDr. Eva Bratková Oponent diplomové práce: Datum obhajoby: Hodnocení:
4 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité informační zdroje. V Praze, 18. prosince 2001 ………………………….. podpis diplomanta
5 Identifikační záznam PAŠEK, David. Architektura a implementace digitálních knihoven v prostředí sítě Internet. Praha, 2002. 77 s., 38 s. příl. Diplomová práce. Univerzita Karlova v Praze, Filozofická fakulta, Ústav informačních studií a knihovnictví 2001. Vedoucí diplomové práce PhDr. Eva Bratková. Abstrakt Cílem práce je charakteristika stávající situace budování digitálních knihoven ve světovém měřítku se zaměřením na problematiku jejich architektury a implementace v podmínkách sítě Internet. Práce se věnuje především důležitým komponentám digitálních knihoven a jejich specifikaci. Mezi důležité komponenty patří digitální objekt, repozitář, katalog a uživatelské rozhraní. V práci jsou rovněž popsány signatury digitálních objektů, které jsou důležité zejména z hlediska bezpečnosti, neměnnosti obsahu a věrohodnosti autora digitálního objektu. Pozornost byla věnována i normám a specifikacím metadat, která jsou velmi důležitá pro budování katalogu a vyhledávání relevantních digitálních objektů. Přínosem práce je podání návrhu optimálního modelu digitální knihovny a ukázky praktických aplikací na navrhovaném modelu. Klíčová slova Digitální archív, digitální knihovna, digitální objekt, digitální podpis, DOI, Dublin Core, handle systém, katalog, metadata, PICS, RAP, RDF, repozitář, signatura, transakční log, unikátní identifikátor, uživatelské rozhraní, XML
6 OBSAH 1.ÚVOD.....................................................................................................................10 1.1 CO JE DIGITÁLNÍ KNIHOVNA ................................................................................. 10 1.2. PROČ BUDOVAT DIGITÁLNÍ KNIHOVNY...................................................................... 14 1.3. TERMÍNY A DEFINICE ........................................................................................ 15 2. ARCHITEKTURY DIGITÁLNÍCH KNIHOVEN ..........................................................17 2.1. PRINCIPY BUDOVÁNÍ DIGITÁLNÍCH KNIHOVEN ............................................................. 17 2.2. DIGITÁLNÍ OBJEKT ........................................................................................... 20 2.3. REPOZITÁŘ ................................................................................................... 23 2.4. KATALOG ..................................................................................................... 26 2.5. UNIVERZÁLNÍ IDENTIFIKAČNÍ SYSTÉMY .................................................................... 29 2.5.1 URI, URN a URL ...................................................................................... 29 2.5.2 DOI - identifikátor digitálního objektu ........................................................ 30 2.5.3 Handle system........................................................................................ 36 2.6. CENTRALIZOVANÝ VERSUS DISTRIBUOVANÝ MODEL ....................................................... 39 2.6.1 Z39.50.................................................................................................. 40 2.6.2. XML..................................................................................................... 43 2.6.3. Z39.50 versus XML................................................................................. 45 3. SIGNATURY DIGITÁLNÍCH OBJEKTŮ ...................................................................47 3.1. ÚVOD DO KRYPTOGRAFIE.................................................................................... 47 3.1.1. Symetrická kryptografie .......................................................................... 48 3.1.2. Asymetrická kryptografie a digitální podpis ................................................. 48 3.2. POTŘEBA SIGNATUR U DIGITÁLNÍCH OBJEKTŮ ............................................................. 49 4. DIGITÁLNÍ KNIHOVNY A METADATA ...................................................................51 4.1 ÚVOD DO METADAT ........................................................................................... 51 4.2. NORMY A SPECIFIKACE ...................................................................................... 52 4.2.1. PICS - Platform for Internet Content Selection ............................................ 52 4.2.2. RDF - Resource Description Framework...................................................... 53 4.2.3. Dublin Core........................................................................................... 58 4.3. REKAPITULACE SOUČASNÉ SITUACE METADAT NA INTERNETU............................................ 62 4.4. PŘÍNOS METADAT PRO DIGITÁLNÍ KNIHOVNY .............................................................. 63 5. NÁVRH MODELU DIGITÁLNÍ KNIHOVNY..............................................................65 5.1. ARCHITEKTURA SYSTÉMU.................................................................................... 66
7 5.2. IMPLEMENTACE UŽIVATELSKÉHO ROZHRANÍ ............................................................... 67 5.3. IMPLEMENTACE KATALOGU .................................................................................. 70 5.4. IMPLEMENTACE REPOZITÁŘE ................................................................................ 72 5.5. OPTIMALIZACE VÝKONU ..................................................................................... 73 6. ZÁVĚR...................................................................................................................75 SEZNAM OBRÁZKŮ ...................................................................................................77 REJSTŘÍK..................................................................................................................78 REFERENCE...............................................................................................................80 PŘÍLOHA...................................................................................................................84
8 PŘEDMLUVA Již řadu let se zabývám problematikou budování informačních systémů. V minulých šesti letech jsem se intenzívně věnoval webovým internetovým systémům a on-line databázím. Poslední dva roky usilovně pracuji na hledání, návrhu a realizaci „ideálního“ dokumentově orientovaného systému, který slouží jako centrální katalog a repozitář digitálních objektů. V rámci mé vlastní softwarové firmy jsem právě na základě skloubení poznatků ze studia informatiky na Matematicko-fyzikální fakultě a informačních studií na Ústavu informačních studií a knihovnictví otevřel projekt digitální knihovny jako univerzální dokumentové báze dat pod pracovním názvem DigLib. Proto jsem přivítal možnost výběru tohoto tématu diplomové práce, které mi umožnilo podívat se na problematiku architektury digitální knihovny v širších souvislostech. Často jsem se v praxi setkal s dvěma naprosto odlišnými postoji k filozofii digitálních knihoven. Většina uživatelů, ale hlavně informačních manažerů, si dnes již uvědomuje potřebu centrální evidence dokumentů, identifikaci dokumentů pomocí metadat a jejich zařazení do relevantních kategorií. Na druhou stranu je patrná nechuť a neochota uživatelů metadata k dokumentům pořizovat. S tímto paradoxem se moderní informační specialista musí vyrovnat, a tato práce by měla ukázat směr, kudy je potřeba se ubírat. Nové technologie a implementace moderních standardů mohou pomoci vyřešit tento paradox. V závěru práce je popsána konkrétní implementace digitální knihovny, tak jak jsme ji společně s kolegy v naší firmě vytvořili. Také se zmíním o nasazení tohoto produktu v institucích, firmách a webových portálech v České republice a Německu. Práce je založena na výběru a studiu hlavně on-line dostupných zdrojů, protože dané téma je natolik nové a progresivní, že je velmi těžké najít kvalitní informace v klasické monografické literatuře. Více informací existuje v tradičních periodikách a nejvíce jich je v elektronické podobě. Jako základní dokument je použit framework1 od Roberta Kahna (CNRI) a Roberta Wilensky (UC Berkeley) [KAH95]. Tato práce je často nazývána jako "Kahn/Wilensky architektura digitální knihovny". 1 Framework je koncept (rámcový systém), nad nímž je možno tvořit další výzkum nebo vývoj
9 Na tomto místě bych chtěl poděkovat vedoucí své diplomové práce PhDr. Evě Bratkové za její pomoc, doporučení, vstřícnost a nasměrování správným směrem. Citace v textu diplomové práce jsou přizpůsobeny standardům běžně používaným v domácí i zahraniční odborné literatuře. Seznam použité literatury je zpracován podle normy ČSN ISO 690. U některých, zejména internetových, pramenů se mi nepodařilo získat všechny potřebné údaje, proto jsou uvedeny ve zkrácené podobě.
10 1.ÚVOD 1.1 Co je digitální knihovna Digitální knihovna je specifickým případem informačního systému, jehož hlavním úkolem je podpora velkého a rozšiřitelného množství digitálních informačních služeb [KAH95]. V této práci definuji a popíši základní entity a principy, které v takových systémech můžeme najít. Zaměřím se na otázku, jaké informace jsou v podobě digitálních objektů ukládány, vyhledávány a zpracovávány a jaké konvence, pravidla a normy lze použít pro identifikaci a lokaci digitálních objektů. Dále věnuji pozornost architektuře digitálních knihoven a jejich implementaci v prostředí Internetu. Termín digitální objekt zde používám v technickém slova smyslu a později bude podrobně popsán. Na tomto místě jen uvedu, že soubory, databáze, elektronické texty nemůžeme označovat jako digitální objekt, alespoň do té doby, než jsou uloženy ve správné struktuře. Je-li digitální knihovna informační systém, pak můžeme najít jednotlivé aktéry informačního systému a jejich funkce. Prvním aktérem je katalogizátor, který zajišťuje katalogizaci digitálních objektů a jejich přidávání do systému. Je-li systém katalogizace a uložení digitálního objektu do repozitáře automatizován, pak katalogizátorem může být autor primárního dokumentu, automatický systém a nebo kombinace autora a poloautomatického katalogizačního systému. Druhým aktérem je rešeršér, který vyhledává požadované informace uložené v digitálních objektech a relevantní digitální objekty ukládá z repozitáře na svůj počítač. Rešeršérem myslím kohokoliv, kdo vyhledává v digitální knihovně. Nebudu rozlišovat informační specialisty a běžné uživatele, neboť si myslím, že z hlediska systému mezi nimi není rozdíl. Rozdíl je pouze v jejich znalostech a zkušenostech. Jeden z pohledů na funkcionalitu systému je znázorněna pomocí use case diagramu2 podle normy UML3 : 2 Use Case diagram v UML je jeden z úhlů pohledu na softwarový systém, kde se vyskytují aktéři (lidé nebo stroje) provádějící určíté akce (use cases = případy užití). Jeden use case může obsahovat ještě další upřesňující případy užití
11 Obr.1 Případ užití digitální knihovny Obr.1. nám schematicky znázorňuje, že katalogizátor v systému digitální knihovny vykonává tři základní operace: 1. katalogizaci digitálního objektu 2. uložení digitálního objektu do repozitáře 3. revizi a změnu digitálního objektu a rešeršér používá dvě základní operace: 1. vyhledávání digitálního objektu 2. uložení digitálního objektu z repozitáře k lokálnímu použití Digitální knihovna je systém softwarových, hardwarových a komunikačních komponent, které zajišťují funkce digitální knihovny jako informačního systému. Ideálním komunikačním prostředím pro systémy digitálních knihoven je síť Internet umožňující přístup k digitální knihovně opravdu každému potencionálnímu zájemci. Přístup k Internetu je dnes již běžnou a relativně levnou záležitostí. Kdybychom 3 UML – Uniform Modeling Language – jazyk pro modelování informačních a softwarových systémů
12 používali nějaké jiné telekomunikační prostředí, pak pro zájemce musíme zajistit patřičnou konektivitu, která určitě bude finančně i technicky mnohem náročnější než spojení internetové. Navíc internetové technologie zažívají takový rozmach, že je možné si vybrat z mnoha platforem, operačních systémů, databázových systémů a vývojových nástrojů pro implementaci digitální knihovny. Zjednodušené schéma komponent digitální knihovny a jejich datových toků: Obr.2 Znázornění základních softwarových komponent internetové digitální knihovny a datové toky Názory na to, co to je digitální knihovna, jsou velmi různé. Například Dr. Peter Noerr4 ve své práci [NOE00] na otázku, co je digitální knihovna, uvádí že v podstatě existují dva typy digitálních knihoven
13 • knihovny obsahující materiály v digitalizované podobě • knihovny obsahující digitální materiály Podle mého názoru, je rozdíl mezi nimi velmi malý a z hlediska tématu v podstatě bezvýznamný. Důležité je, že digitální knihovna má materiály uloženy v počítačovém systému ve formě, ve které je velmi jednoduché s nimi manipulovat a dodávat je způsobem, který u klasických materiálů prostě není možný. I když má klasická knihovna velmi automatizovaný systém, není digitální knihovnou v našem pojetí, jestliže obsahuje pouze klasické materiály (jako jsou tištěné knihy). Automatizace nedělá z knihovny digitální knihovnu v našem slova smyslu, ale je pravdou, že digitální knihovna musí být automatizována v co nejvíce jejích procesech [POK01]. Mustafa Jarrar z katedry počítačových věd Bruselské univerzity v e-mailové konferenci o digitálních knihovnách (DIGLIB@INFOSERV.NLC-BNC.CA) napsal: "Termín digitální knihovna má více možných významů. Budeme-li se držet klasické definice, že digitální knihovna je digitalizovaná kolekce materiálů, tak si pod tím někdo představí tradiční knihovnu s digitalizovanými materiály a službami, které tyto informace zpřístupňují, někdo jiný se může dívat na telefonní seznam v mobilním telefonu jako na digitální knihovnu a někdo další může považovat za digitální knihovnu internetový vyhledávač. Z toho tedy vyplývá, že jakákoliv kolekce digitálních informačních objektů a služby nad ní je digitální knihovnou." Jak je vidět, tak ani mezi odborníky zabývajícími se digitálními knihovnami není jednotný názor. Já se myslím, že ne všechny kolekce digitálních materiálů a služby nad nimi můžeme považovat za digitální knihovny. Je potřeba, aby kolekce splňovala alespoň základní koncepty popsané v dalších kapitolách této práce. Myslím, že si budeme muset ještě nějaký čas počkat, než se například z dnešních velmi populárních internetových vyhledávačů stanou digitální knihovny internetového obsahu, i když je potřeba říci, že některé se k tomu svými vlastnostmi již blíží. Pokusím-li se definovat, co je digitální knihovna, pak bude má definice vypadat takto: 4 Dr. Peter Noerr - britský informační specialista, zakladatel známého knihovnického systému Tinlib
14 Def.: Digitální knihovnou rozumíme kolekci digitálních objektů, nad nimiž existují služby digitálních knihoven. Digitální objekt je informační entita obsahující metadata o obsahu, vlastní obsah, transakční log a signaturu. Podobnou definici digitální knihovny uvedl Jaroslav Pokorný [POK01] na 8. ročníku konference AKP 2001 (Automatizace knihovnických procesů). Def.[POK01]: Digitální knihovna je řízená kolekce informací spolu s jistými službami, přičemž tyto informace jsou uloženy v digitální formě a jsou přístupné po síti. 1.2. Proč budovat digitální knihovny V dnešní době elektronických textů, obrazů a zvukových děl, které se distribuují po datových telekomunikačních sítích typu Internet, je budování digitálních knihoven logickým krokem po knihovnách klasických. V klasických knihovnách dokonce existují metody na katalogizaci elektronických publikací na datových nosičích. Identifikace elektronických dokumentů, uložených kdesi v datové síti, často měnících obsah i lokaci, ale vyžaduje jiný přístup. S digitálními objekty lze mnohem kvalitněji a operativněji pracovat a manipulovat než s dokumenty klasickými a k tomu jsou zapotřebí speciální metody, normy a technologie, které by digitální knihovny měly obsahovat. Zde uvádím několik důvodů, které vysvětlují důležitost a přínosy digitálních knihoven. I. EFEKTIVITA PRÁCE Digitální knihovna by měla mimo jiné fungovat jako velmi kvalitní katalog digitálních objektů, v němž rešeršér má možnost velmi komfortně provést rešerši a získat metainformace o relevantních datových objektech. Primární dokumenty relevantních objektů, o které má zájem, má možnost okamžitě získat, a to v datovém formátu5 , který si zvolí. Práce s takovým typem knihovny je mnohem efektivnější a časově méně náročná. Využití digitální formy materiálů v digitálních knihovnách dává nové možnosti, které nejsou s klasickými materiály možné. 5 Datovým formátem rozumíme např. formáty PDF, PostSkript, MS Word dokument, HTML dokument, XML dokument a pod.
15 II. KVALITA VYHLEDÁVÁNÍ Bez digitálních knihoven se rešeršér při vyhledávání na Internetu musí spolehnout na standardní vyhledávací stroje, které nejsou nijak zaměřeny na digitální objekty. Nepoužívají k identifikaci univerzální identifikační systémy, ale pouze URL dokumentů. Neukládají kvalitní metadata. Obsahují informace všeho druhu a i dokumenty bez jakékoliv informační hodnoty. Metadata by měla zvýšit kvalitu vyhledávání a zlepšit poměr relevantních a partinentních dokumentů. III. TVORBA KOLEKCÍ DIGITÁLNÍCH OBJEKTŮ Tak jako klasické knihovny fungují jako uspořádané sbírky klasických dokumentů, tak je potřeba vytvářet i kolekce uspořádaných digitálních objektů. To je jedna z hlavních úloh digitálních knihoven. I elektronické zdroje je potřeba uchovávat pro další generace a nesmíme riskovat, že o některé kvalitní informace přijdeme. Trvalá dostupnost (PRESERVATION) je jeden z důležitých úkolů mezinárodní knihovnické federace IFLA a digitální knihovny jsou v digitálním světě ekvivalentem klasických knihoven, které tento problém řeší. 1.3. Termíny a definice Terminologie je velkou bariérou při popisování digitálních knihoven. Některá slova mají různý význam v různých oborech, a proto je potřeba vymezit, jaký význam budou mít právě v kontextu digitálních knihoven. S tímto problémem se setkáváme jak v jazyce anglickém, tak českém, kde je situace ještě komplikovanější. Mnoho běžně používaných anglických termínů nemá ustálený český ekvivalent. Osobně preferuji používání anglických termínů, než vymýšlení nových a nikomu nic neříkajících českých termínů, a jelikož naprostá většina kvalitních dokumentů z oblasti výzkumu digitálních knihoven existuje právě v jazyce anglickém, bude tak i pro čtenáře jednodušší studium dalších zahraničních materiálů. Jedním z úkolů této práce je vysvětlit a popsat termíny používané v oblasti digitálních knihoven. Na tomto místě uvedu ty nejdůležitější: • Digitální objekt • DOI (Digital Object Identifier)
16 • DOI žánry • Dublin Core • Handle system • Katalog • PICS (Platform for Internet Content Selection) • RAP (Repozitory Access Protokol) • RDF (Resource Description Framework) • Repozitář • Signatura digitálního objektu • Transakční log digitálního objektu • XML (eXtensible Markup Language) • Z39.50 a eZ39.50
17 2. ARCHITEKTURY DIGITÁLNÍCH KNIHOVEN 2.1. Principy budování digitálních knihoven Systém digitální knihovny pracuje obecně na tomto principu. Katalogizátor je uživatel, který převede primární materiály do formy digitálního objektu. Digitální objekt je datová struktura, která se skládá z primárních digitálních materiálů nesoucích obsahové informace, metadat, signatury a unikátního univerzálního identifikátoru. K získání unikátních univerzálních identifikátorů se používají autorizované generátory (viz handle system, DOI). Katalogizátor pak může digitální objekt uložit do jednoho nebo více repozitářů, ze kterých jsou pak dostupné pro rešeršéry. Rešeršérem nazývejme jakéhokoliv uživatele, jenž vyhledává v digitální knihovně. Po uložení objektu do repozitáře je identifikátor objektu a identifikace repozitáře zaregistrována do globálního systému identifikátorů. Rešeršéři pak mohou podle identifikátoru digitálního objektu zjistit, v jakých repozitářích je daný objekt uložen. Interakce s repozitářem typu ukládání nebo přístupu k objektům jsou prováděny přes protokol RAP (Repozitory Access Protocol), který by každý repozitář měl podporovat. Digitální objekt, jehož identifikátor je uložen v globálním systému identifikátorů, nazýváme registrovaným digitálním objektem. Chceme-li udržovat obsah digitální knihovny perzistentní a nezávislý na počítači, zařízení, prohlížeči nebo formátu dat, pak bychom se měli při budování a správě systému držet níže uvedených principů [CRA01]: 1. Očekávat a předvídat změny Držet systém co nejvíce obecný a flexibilní vůči dalším požadavkům, které se zaručeně objeví v budoucnosti. Měli bychom být připraveni na změnu technologií, konverzi primárních dokumentů do nových digitálních formátů či přidávání dalších metadat. 2. Znát uchovávaný obsah Je potřeba si uvědomit, že pro uživatele je nejzajímavější a nejhodnotnější obsah digitální knihovny. Tvůrci digitálních knihoven musejí rozhodovat o jejím obsahu včetně výběru objektů, které je potřeba vložit, převést z klasické formy do formy digitální a opatřit kvalitními metadaty.
18 3. Zapojit správné lidi V ideálním případě je dobré mít k dispozici specialisty jak z počítačového oboru, tak i z informačních věd a knihovnictví. Příkladem důležitosti spolupráce počítačových specialistů a knihovníků je americká norma Dublin Core metadata standard [DC_Z3985]. Počítačoví specialisté se na problém dívají z hlediska sémantické interoperability metadat ve velké informační síti - Internetu. Informační vědci a knihovníci mají velké zkušenosti s katalogizací a indexací, vědí, jak jsou důležité pro vyhledávání informací (information retrieval). Dále je dobré zapojit odborníky z oborů, pro které je digitální knihovna určena. Ti by měli ve spolupráci s knihovníky budovat (indexovat a katalogizovat) obsah digitální knihovny. 4. Navrhnout použitelný systém Uživatelská rozhraní většiny digitálních knihoven jsou budována pomocí internetových technologií. Na tomto místě je potřeba podotknout, že digitální knihovna nemusí používat pouze webové technologie, ale je pravdou, že dnes je to nejjednodušší možnost, jak poskytnout přístup k datům co nejvíce uživatelům. Uživatelské rozhraní by tedy mělo být navrženo tak, aby ho bylo možno jednoduše a bez velkých finančních a časových nároků předělat na jinou technologii. Dnešní webové technologie jsou však velmi dobře použitelné a není důvodu, proč na nich digitální knihovny nezaložit. Vždy je potřeba se držet základního pravidla, že pro uživatele je důležitý obsah, a proto navrhujme uživatelské rozhraní a navigační systém co nejjednodušší. Musíme si uvědomit, že uživatel má možnost si ve svém internetovém prohlížeči nastavit mnoho parametrů, jako jsou například velikost písma, velikost zobrazované plochy, vypnutí obrázků apod. Navíc uživatel může používat různé operační systémy, jako jsou MS-Windows, Apple Macintosh, UNIX, PALM OS apod. Pak tedy naše uživatelské rozhraní vypadá trochu jinak pro každého uživatele. Důležité je používat opravdu jednoduché rozhraní, které se všude zobrazí dobře. Vhodné je mít připraveno více uživatelských rozhraní a poskytnout uživateli možnost výběru. 5. Zajistit přístup Na tento bod se můžeme dívat ze dvou úhlů pohledu. Prvním úhlem pohledu je potřeba udržovat přístupová práva k jednotlivým objektům v digitální knihovně. Ne všichni musí mít stejná práva ke všem objektům. Někdo může daný objekt pouze číst, jiný ho může i změnit a někdo ho nemusí vidět vůbec. Druhým úhlem
19 pohledu je zajistit uživatelům čitelnost dokumentů. Jestliže uživatel získá dokument z digitální knihovny ve formátu, který si neumí zobrazit, pak je to stejné, jako by dokument nezískal. Systém by tedy měl umožnit uživateli výběr požadovaného formátu (pokud možno otevřeného6 ) a poskytnout konverzi. Druhou možností je nabídnout uživatelům software, který je schopen dokumenty zobrazit. 6. Automatizovat, kde je to možné Pracujeme s elektronickými daty, a proto bychom měli využívat co nejvíce automatizovaných procesů ve všech činnostech digitální knihovny. Jedná se o nástroje, které zrychlují a zefektivňují práci při pořizování objektů do digitální knihovny. Systém by měl nabízet katalogizátorům výběrová menu, nacházet klíčová slova podle četnosti výskytu v primárním dokumentu a další utility k usnadnění ruční práce indexátorům a katalogizátorům. Zatím není možné hovořit o plně automatické katalogizaci a indexaci, protože tyto činnosti vyžadují buď primární dokumenty ve strukturované formě (např. XML s patřičným DTD) a nebo lidskou inteligenci. Nicméně počítače nám jsou schopny mnoho práce ušetřit, nabídnout několik možností a člověk si pouze vybere tu správnou, případně ji upřesní. Vyhledávání a zobrazování informací uživatelům musí být naopak plně automatizováno, protože to už vychází ze strukturovaných dat uložených v digitální knihovně. 7. Držet se standardů Použití standardů při budování systému má mnoho výhod. Aplikace jsou více škálovatelné, robustnější, interooperabilní a přenositelné [STR94]. To samozřejmě platí i pro budování, implementaci a správu digitálních knihoven. 8. Zajištění kvality Výběr kvalitních dokumentů, kompletní a korektní metadata, to jsou základní pravidla pro udržení kvality digitální knihovny. Digitalizujeme-li klasické materiály, je potřeba sledovat i kvalitu pořízených dat. 9. Klást důraz na trvalé uchování (perzistenci) 6 Otevřeným formátem rozumíme formát, jenž je veřejně zdokumentovaný a existují nástroje pro jeho zobrazení. Tyto nástroje musí být možno získat bezplatně.
20 Je potřeba si uvědomit, že i dokumenty v digitální podobě je potřeba uchovávat pro budoucnost. Máme-li nějaký dokument v určitém formátu, který se dnes již nepoužívá, pak jej nemůžeme ani zobrazit, a tím se nám obsah tohoto dokumentu ztrácí. Dalším problémem je například poruchovost magnetických záznamů, nebo i CD nosičů. Je potřeba se tímto jevem zabývat, abychom nepřišli o cenná data. Speciálně vytvořená skupina 21 expertů zjistila, že v dnešní době není garantováno trvalé uchování digitálních informací [ROT99]. Toto zjištění je opravdu paradoxní, když si uvědomíme, kolik dokumentů a informací se nám zachovalo až do dnešního dne na relativně "primitivních" nosičích informací, jako jsou papír či kámen. 2.2. Digitální objekt Na tomto místě podrobně vysvětlím pojem digitální objekt. V některých starších českých zdrojích se občas můžeme setkat i s ekvivalentním termínem informační jednotka, avšak většina odborníků se již dohodla na termínu digitální objekt. V architektuře Kahn/Wilensky jsou jednotky či entity v digitální knihovně nazývány "digitálním objektem". Kahn a Wilensky [KAH95] zdůrazňují, že termín digitální objekt musí být používán ve smyslu datové struktury, a ne v obecném smyslu jakéhokoliv dokumentu v digitální formě. Podle nich by možná byl lepší termín digitální strukturální objekt (objekt digitální infrastruktury), ovšem jeho používání nepovažují z praktického hlediska za optimální. Kahn se na digitální objekty dívá jako na architekturu, kterou lze použít v různých síťových informačních systémech. Digitální objekt musí obsahovat jak samotná data, tak i metadata [KAH95]. Informace uložené v digitálním objektu, tedy primární dokumenty, nazýváme obsah (content). Jména a identifikátory digitálních objektů (handle) jsou jedním z nejdůležitějších částí architektury digitální knihovny, ale tím se budu podrobně zabývat v kapitole 2.5. (Univerzální identifikační systém).
21 Jak již víme, informace jsou v digitální knihovně uloženy jako digitální objekty. Nejjednodušším zobecněním digitálního objektu je, že digitální objekt je sadou bitů7 . Toto zobecnění je jistě pravdivé, ale velmi zjednodušené. Obsahy většiny digitálních objektů mají určitou strukturu a obsahují další informace (intelektuální vlastnictví, identifikace autora či vydavatele apod.), které musí být propojeny s digitálním objektem. Obrázek č.3 ukazuje strukturu digitálního objektu v Kahn/Wilensky architektuře. Obr.3 Architektura digitálního objektu - zdroj [KAH95] K tomu, aby bylo možné prezentovat obsah (content) digitálního objektu, je potřeba znát typ obsahu. Digitální objekt může obsahovat více typů obsahů. Jedna část obsahu může být například textová a druhá audio záznam. Ukazuje se, že jakkoliv komplexní data mohou být poskládána z několika základních typů obsahů, identifikátorů (handlů), signatur a dalších digitálních objektů. Objekt vždy obsahuje unikátní identifikátor (handle). K podrobnějšímu popisu objektu se používají metadata (properties), která jsou na obrázku č.3 znázorněna jako "properties". Signatura je volitelná část objektu, ale může být užitečná například pro ověření platnosti objektu nebo získání informace, že nikdo kromě autora objekt nezměnil. Používají se k tomu pokročilé techniky kryptování, kontrolních součtů (check sums) či 7 Bit - ve smyslu jednotka informace, která nabývá pouze dvou hodnot, a to 0 nebo 1
22 technologie privátních a veřejných klíčů (public/private keys). V dnešní době je možné použít technologii hodně diskutovaného digitálního podpisu. Možnostem signatur se budu více věnovat v samostatné kapitole č.3. Transakční log8 se často používá k uchování informací o všech prováděných transakcích s daným objektem. Ty mohou být užitečné například pro statistiky četnosti zobrazení metadat, četnosti stažení obsahu objektu rešeršéry. Další transakční údaje je možné použít pro profilování (nabídnutí daného objektu určitým uživatelům), či rozhodování o managementu a optimalizaci repozitáře (např. ke kterým objektům se nejčastěji přistupuje). Mezi data, jež má smysl ukládat do transakčních logů, patří datum, čas a typ provedené operace s objektem v repozitáři a identita uživatele provádějícího tuto operaci. Jeden digitální objekt má více forem. Je potřeba odlišovat mezi formami digitálních objektů. Jinou formu má objekt vytvořený autorem, v jiné formě může být uložen v repozitáři, a v další je posílán rešeršérům. Rešeršér, požadující primární dokument určitého digitálního objektu z repozitáře digitální knihovny, si může zvolit mnoho parametrů, pomocí nichž se bude daný obsah přenášet přes síť do jeho systému9 . Jako příklad mohu uvést situaci, kdy rešeršér nalezl dokument v digitální knihovně, který si chce uložit do lokálního počítače. V repozitáři je tento dokument uložen jako digitální objekt, jenž má obsah uložen ve specifickém formátu postscript a samozřejmě obsahuje další metadata. Tvůrce dokumentu jej poslal do repozitáře jako dokument v MS Word a rešeršér jej požaduje ve formátu PDF. Celá transakce může být velmi složitým softwarovým procesem, nicméně velmi důležitým k tomu, aby byl systém použitelný. Na tomto příkladě vidíme, že forma digitálního objektu se mění, přičemž obsah zůstává zachován. Digitální objekty jsou základním stavebním kamenem digitální knihovny, avšak uživatelé nechtějí pracovat s digitálními objekty, ale s objekty na nejvyšší úrovni abstrakce. Digitální objekt je svým způsobem abstraktní třída všech typů dokumentů, která musí zůstat uživatelům utajena. Uživatelé pracují s textovými dokumenty, počítačovými programy, obrázky, hudebními záznamy, které jsou většinou 8 Log – žurnálový soubor, ve kterém se uchovávají všechny provedené akce 9 Úmyslně mluvíme o systému, neboť rešeršér nemusí pracovat jen s personálním počítačem, ale například s kapesním počítačem typu PDA, mobilním telefonem, či jiným zařízením, jež je schopno zobrazit požadovaná data.
23 reprezentovány formou více digitálních objektů seskupených dohromady. Jak by měly být digitální objekty seskupeny, nemůže být specifikováno nějakými pevně danými pravidly. Je to závislé na specifikaci objektu, typu obsahu a někdy i na obsahu samotném. Příkladem smysluplného seskupení je například počítačový program a jeho dokumentace v elektronické podobě. Architektura digitální knihovny musí podporovat seskupování digitálních objektů a jejich zpřístupnění. Architektura Kahn/Wilensky podporuje nejvyšší úroveň abstrakce (uživatelskou) dvěma možnými způsoby. Prvním způsobem je, že digitální objekt může sám v sobě obsahovat další digitální objekty (Obr.4). Druhým řešením je více digitálních objektů, každý s vlastním identifikátorem (handlem), které tvoří speciální digitální objekt, jenž v metadatech obsahuje identifikátory na tyto samostatné objekty. Toto řešení funguje na principu katalogizačního záznamu. Osobně se mi více líbí právě toto druhé řešení. Je logické, aby jednotlivé digitální objekty, i když obsahově patří k sobě, měly vlastní unikátní identifikátor a byly tak přístupné i samostatně. Obr.4 Digitální objekt použitý jako katalogizační záznam Kahn zavádí dva stavy digitálního objektu. Proměnlivý a neměnný digitální objekt (mutable a immutable). Proměnlivý digitální objekt může být změněn i po uložení v repozitáři. I přesto nemohou být změněna žádná klíčová metadata, ale většina ostatních změn je povolena. Naopak neměnný digitální objekt nesmí být změněn za žádných okolností. Jediné, co je možné s neměnným digitálním objektem provést, je vymazat ho z repozitáře nebo zakázat k němu přístup. 2.3. Repozitář Repozitář je jednou z hlavních komponent infrastruktury digitální knihovny [LAG95]. Úkolem repozitáře je ukládání a přístup k digitálním objektům v elektronické síti. Jak
24 jsem již jednou zmínil, digitální objekt je v repozitáři uložen často v úplně jiné formě, než se prezentuje uživateli. Různé repozitáře mají velmi různé interní organizace, ale každý digitální objekt musí mít všechny náležitosti popsané v kapitole 2.2. Obr.5 Struktura repozitáře [ARM97] Výše uvedené schéma na obr.5 ukazuje obecnou třívrstvou architekturu repozitáře. RAP interface je komunikační vrstvou, pomocí které okolní svět komunikuje RAP protokolem s repozitářem. V Kahn/Wilensky architektuře repozitáře je nadefinován repozitářový přístupový protokol (RAP - Repozitory Access Protocol). Každý repozitář musí tento protokol podporovat. Protokol definuje základní operace s repozitářem. Repozitáře samozřejmě mohou navíc poskytovat i další rozšířené funkce a užitečné dotazovací jazyky, pomocí nichž je možné vyhledávat digitální objekty uložené v repozitáři. To, aby protokolu RAP repozitář rozuměl, zajišťuje vrstva Repozitory Shell (repozitářová nadstavba). Perzistentní datový sklad (Persistent Store) je prostor, kam se fyzicky ukládají digitální objekty. Implementace je okolnímu světu skryta a záleží jen na implementaci repozitáře, jak a kam bude digitální objekty ukládat. Ke komunikaci s perzistentním skladem slouží příkazy Store API. Řídící vrstva (Object Management Layer) je střední vrstva, která zajišťuje mapování služeb mezi repozitářovou nadstavbou a datovým skladem, a to prostřednictvím příkazů Shell API. Popis základních funkcí protokolu RAP: 1. Přístup k digitálnímu objektu (ACCESS_DO) Příkaz ACCESS_DO obecně vyvolává program, jenž provádí přístupové operace nad digitálním objektem uloženým v repozitáři. Program je závislý na předaných parametrech.
25 Výstupem mohou být metadata objektu, klíčová metadata nebo celý digitální objekt. Mohou být implementovány i další doplňkové služby typu encrypt, compress apod. Služba encrypt vrací digitální objekt v zašifrované podobě. Služba compress vrací digitální objekt ve zkomprimované podobě nějakým komprimačním algoritmem. Doplňkové služby však nejsou nijak standardizovány a není dán ani jejich výčet. 2. Uložení digitálního objektu (DEPOSIT_DO) Příkaz DEPOSIT_DO může být implementován různě. Jednou z možností je předat operaci primární dokument a metadata, z čehož systém vytvoří nový digitální objekt a uloží jej do repozitáře. Při tvorbě digitálního objektu se musí rovněž zaregistrovat univerzální identifikátor (handle) objektu. Další možností příkazu DEPOSIT_DO je replikace již existujícího digitálního objektu. DEPOSIT_DO slouží i k modifikaci existujícího proměnlivého (mutable) digitálního objektu. 3. Přístup k dalším službám (ACCESS_REF) Tento příkaz umožňuje jednoznačně identifikovat další repozitáře a jejich protokoly, které poskytují další služby nad digitálními objekty. Jsou definovány dvě možné odpovědi: a) žádné další servery b) seznam dvojic (server, protokol) Základním cílem protokolu RAP je jednoduchý model práce s repozitářem. Všechny ostatní služby, akce a transakce mohou být prováděny přes jiné standardizované protokoly (např. Z39.50, SQL3, ZQL, Dienst) pomocí příkazu ACCESS_REF. Bylo by velmi praktické, kdyby všechny repozitáře podporovaly protokol RAP, protože pak by byla velmi jednoduchá komunikace mezi jednotlivými repozitáři. William Arms rozšířil ve svých implementacích RAP protokol o další funkce [ARM97]: Funkce Popis VerifyHandle Kontroluje, jestli byl handle zaregistrován v handle systemu AccessRepoMeta Načte metadata repozitáře
26 Funkce Popis Verify_DO Kontroluje, jestli repozitář obsahuje digitální objekt s uvedeným handlem AccessMeta Načte metadata specifikovaného digitálního objektu Access_DO Načte digitální objekt z repozitáře Deposit_DO Ukládá digitální objekt do repozitáře Delete_DO Smaže digitální objekt z repozitáře MutateMeta Změní metadata digitálního objektu Mutate_DO Změní digitální objekt V infrastruktuře digitální knihovny musí existovat alespoň jeden repozitář. Repozitářů však může být více a z hlediska výkonnosti velkých systémů se rozdělení repozitářů jeví jako nutnost. Systém repozitáře s milióny digitálních objektů a tisíci přístupy za vteřinu nelze provozovat na jediném serveru. Rozdělení repozitáře se dá řešit více způsoby. Jedním z nich je distribuovaný model pomocí technologií CORBA, COM apod. Další možností je například klastrování10 serverů, jež zajišťují funkci repozitářů. Carl Lagoze v práci [LAG95] popisuje implementaci repozitáře nad Kahn/Wilensky architekturou. Systém, který nazval ISOS (Inter-operable Secure Object Stores), definuje rozhraní do zabezpečených repozitářů, které komunikují s ostatními repozitáři, klienty a dalšími službami. Rozhraní je nadefinováno jako distribuovaný objektový systém v prostředí CORBA11 . Carl Lagoze používá ve svém systému více instancí repozitáře, který definuje jako sadu digitálních objektů. Každý repozitář je jednoznačně identifikován pomocí repozitářového handlu. Pošleme-li požadavek na získání digitálního objektu s daným handlem, systém nám vrátí handly repozitářů, ve kterých se daný digitální objekt nachází. Pak je velmi jednoduché si vybrat nejbližší, nejrychlejší, nebo jinak pro nás nejvýhodnější repozitář a objekt si vyžádat. 2.4. Katalog V Kahn/Wilensky architektuře se s pojmem katalog nesetkáme, neboť základní ideou je uchovávat katalogizační údaje zapouzdřené zároveň s primárním dokumentem v digitálním objektu a digitální objekty v repozitáři. Samozřejmě, že existují metody, jak využít metadat digitálních objektů v repozitáři jako katalogu, ale robustnějším 10 Klastrování (clustering) - seskupení více počítačů. Klastr navenek funguje jako jeden mnohem výkonnější počítač. 11 CORBA - standard pro vývoj distribuovaných aplikací, navržený organizací OMG (Object Managment Group)
27 řešením je vytvoření katalogu jako další komponenty architektury digitální knihovny. Z hlediska praktické implementace a rychlosti odezvy po zadání rešeršního dotazu do systému se podle mého názoru rozhodně vyplatí vytvořit katalog metadat digitálních objektů. Další výhodou je možnost šíření pouze katalogizačních záznamů jako zdroje sekundárních informací, a možnost umístit v digitální knihovně pouze katalogizační záznam digitálního objektu, aniž by existoval v repozitáři dané digitální knihovny. V neposlední řadě lze vybudovat katalog nad více repozitáři. Máme možnost držet se Kahn/Wilensky architektury a ponechat metadata jako součást digitálních objektů. Druhou možností je vytvoření pouze katalogu metadat s univerzálním identifikátorem12 digitálního materiálu13 , který bude uložen na lokacích daných identifikátorem (např. pomocí URL http://www.cuni.cz/dl/diglib.html, ftp://ftp.cuni.cz/dl/diglib.pdf nebo DOI či handle systemu) . Repozitářem se může stát i celý Internet nebo náš Inter/intranetový server a nemusíme vytvářet žádný speciální repozitář. Naimplementujeme-li vlastní repozitář, pak není problém, aby jedním z identifikátorů u katalogového záznamu byl identifikátor do repozitáře. Např. rap://repozitory.cuni.cz/?hdl:cnri.dlib/february97-arms. Výběr architektury repozitáře a metadat ovlivňuje typ aplikace a formát primárních dokumentů. Katalog je souborem katalogizačních záznamů. Záznam vytvoříme jako podmnožinu metadat uložených v digitálním objektu, která by měla být nějakým způsobem standardizována. Noerr v materiálu [NOE00] nabízí jako vhodná schémata pro katalogizační záznam tyto knihovnické standardy: MARC14 , Dublin Core15 , BIB-116 , EAD17 . Volba vhodného standardu je klíčová pro implementaci katalogu, nicméně záznamy implementované podle určitého standardu jde většinou jednoduše konvertovat do standardu jiného. 12 Například DOI - Digital Object Identifier 13 Zde není možno hovořit o digitálním objektu, ale pouze o digitálním primárním dokumentu, neboť digitální materiál nesplňuje definici digitálního objektu 14 MARC - http://lcweb.loc.gov/marc 15 Dublin Core - http://www.dublincore.org 16 BIB1 - http://lcweb.loc.gov/z3950/agency 17 EAD - http://lcweb.loc.gov/ead
28 Záznamy musí být uloženy tak, aby se v nich dalo velmi rychle vyhledávat. Ideálním řešením by bylo použít nějakou objektově orientovanou databázi, nejlépe založenou na XML. Jelikož však technologie objektových databází i přes velká očekávání v 90. letech 20. století nedoznala velkého rozmachu a technologie XML je relativně mladá, neexistují ještě použitelné a aplikovatelné nástroje. Nejlepším řešením je použít nějaký kvalitní RDBM18 systém, ve kterém implementujeme nám nejlépe vyhovující standard pro katalogizační záznam - metadata. RDBM systémy jsou optimalizovány pro práci s velkým množstvím dat. Je jen otázkou, který z databázových systému použít. Pro jednodušší implementaci katalogu bych doporučoval Open source19 databáze, které jsou většinou zdarma a bývají velmi kvalitní. Jako příklad uveďme MiniSQL nebo dnes na Internetu hodně používaný databázový server MySQL. Pro profesionálnější řešení můžeme použít kvalitních komerčních produktů typu Oracle, Sybase, DB2 či Informix20 . Katalog je určen pro uživatele, a proto je potřeba vytvořit uživatelské rozhraní pro procházení a prohledávání katalogu. Jelikož implementujeme digitální knihovnu v prostředí Internetu, pak je vhodné vytvořit internetovou aplikaci komunikující s uživatelem prostřednictvím webového rozhraní. Pro aplikační vrstvu digitální knihovny je možno zvolit jeden z mnoha programovacích jazyků podporujících tvorbu webových aplikací. Mezi nejkvalitnější patří PHP, PERL, JAVA a další. K velmi podobným závěrům dospěli i tvůrci prototypu digitální knihovny z virginské univerzity [STA00]. Ti zvolili jako RDBMS databázový server MySQL a pro aplikační vrstvu použili Java servlety. 18 RDBM systém - Relation Database Management System - relační databázový server 19 Open source - software včetně zdrojových kódů, který je volně šiřitelný pod různými licencemi (např. GNU) 20 Informix byl v květnu 2001 koupen IBM a začleněn do RDBMS IBM DB2
29 2.5. Univerzální identifikační systémy Na tomto místě je potřeba zdůraznit, že vzhledem k architektuře digitální knihovny, nemají architektury identifikačních systémů přímou souvislost, neboť k identifikaci digitálních objektů nám postačí brát univerzální identifikační systém jako "black box", kde k identifikaci používáme identifikátor daného systému a umístění objektu jsme také schopni z identifikačního systému získat. To nám pro potřeby digitální knihovny bohatě postačí. Avšak k lepšímu pochopení souvislostí je vhodné se zaměřit na podstatu identifikačních systémů. 2.5.1 URI, URN a URL URI, URN a URL se používají hlavně na internetu. Internet je informační prostor, který obsahuje milióny dokumentů. K tomu, abychom se mohli orientovat v tak obrovském informačním prostoru, potřebujeme univerzální identifikátory, které nám slouží jako orientační body v tomto kyberprostoru [W3CNA93]. URI (Uniform Resource Identifier) jsou krátké znakové řetězce identifikující abstraktní nebo fyzické zdroje jako jsou dokumenty, soubory ke stažení, služby, elektronické poštovní schránky, apod. URI zpřístupňuje zdroje a zároveň definuje jednoduché přístupové metody (HTTP, FTP, GOPHER, MAILTO, apod.) k těmto zdrojům, což umožňuje získání zdrojů pomocí jednoho prostého kliknutí myši (čí jiného podobného výběru). Obr.6 URL a URN jsou podmnožinou URI URI může fungovat jako lokátor zdroje, jméno zdroje a nebo obojí. URL (Uniform Resource Locator) je podmnožinou URI, což je schématicky zobrazeno na obrázku č.6. URL identifikuje zdroje podle jejich umístění v elektronické síti a přístupového
30 protokolu. Příkladem URL je tedy ftp://ftp.freebsd.cz/pub/FreeBSD/release-4.6.i386.iso, což identifikuje soubor ke stažení přes protokol FTP a to ze serveru zabývajícího se operačním systémem FreeBSD v České republice. URN (Uniform Resource Name) je také podmnožinou URI. URN je však na rozdíl od URL globálně jednoznačný a trvale dostupný identifikátor, a to i v případě, že zdroj přestane existovat a nebo se stane nedostupným. Klasickými příklady URN jsou tedy DOI a Handle system. Oba tyto systémy jsou popsány v dalších kapitolách. Příklady URN [ARM97]: urn:hdl:cnri.dlib/august95 urn:lifn:some.domain:anything-goes-here urn:path:/A/B/C/doc.html 2.5.2 DOI - identifikátor digitálního objektu Nejdříve vysvětlím zkratku DOI (Digital Object Identifier). Znamená trvalý identifikátor digitálního objektu v elektronické síti. Zde jsou všechny digitální objekty jednoduchou posloupností bitů. DOI může být použit na jakoukoliv formu digitálního objektu v libovolném prostředí. Obecněji řečeno, DOI je univerzální identifikační systém, který můžeme přirovnat například k ISBN či ISSN. DOI může být použit k identifikaci různých fyzických objektů (např. tištěné knihy, články v časopisech, CD nosiče, video záznamy apod.), ale i k identifikaci digitálních souborů v síťovém prostředí, což je důležité pro digitální knihovny. DOI poskytuje schéma pro jednoznačnou a perzistentní identifikaci digitálních objektů v síťovém prostředí. Trvalá (perzistentní) dostupnost DOI je zajišťována centrálním systémem. Jedním z problémů dnešního Internetu je fakt, že kdykoliv se nějaký objekt přesune někam jinam, pak uživatel hledající daný objekt nalezne pouze starou lokaci daného objektu, a jelikož tam již objekt není, obdrží pouze informaci, že daný objekt neexistuje. V lepším případě na daném místě v Internetu nalezne odkaz na hledaný objektu. To je zapříčiněno tím, že identifikace pomocí URL určuje umístění objektu a ne objekt samotný. DOI naopak identifikuje určitý objekt a podružně pak jeho lokaci. Každý DOI je registrován v handle systemu a lokace objektu v Internetu tudíž může být určena. Když se objekt přesune někam jinam, pak je potřeba změnit jeho lokaci
31 v handle systemu a vše funguje dále. Pro koncového uživatele změna lokace nepřináší žádný problém, neboť uživatel se na digitální objekt odkazuje pomoci DOI a až na základě odpovědi handle systemu se dozví aktuální lokaci objektu. Nestane se nám pak, že objekt nemůžeme nalézt, a nebo, že musíme procházet všechny lokace, na kterých byl daný objekt umístěn. DOI pracuje jako akční identifikátor. Nejjednodušší operací, jež lze s DOI provést, je lokace objektu, který DOI identifikuje. Díky tomu se může používat jako URL. Vlastnosti DOI jsou však mnohem komplexnější a lze s ním provádět mnohem více operací. DOI je interoperačním identifikátorem. DOI systém byl vyvíjen, aby spolupracoval s minulými, současnými i budoucími technologiemi. DOI umožňuje pracovat jak s dřívějším standardem ISBN, tak se současným standardem URL. DOI systém je a vždy bude otevřený standard a bude vždy kompatibilní s budoucími Internetovými standardy, které se vyvíjejí a budou vyvíjet. DOI systém je konstruován jako integrovaný systém složený z více spolupracujících komponent (obr.7). Norman Paskin [PAS01] rozdělil DOI systém do tří komponent. Jsou to enumerace, popis, rozpoznání. Nad těmito komponentami jsou definována pravidla.
32 Obr.7 Tři komponenty DOI systému (enumeration, description, resolution) a pravidla (policies) 1. Enumerace (Enumeration): Přiřazení identifikačního čísla (DOI), které digitální objekt identifikuje. Je mnohem lepší mluvit o alfanumerickém řetězci než o čísle, neboť identifikátor objektu může obsahovat jak číslice tak i písmena. Pro jednoduchost se však používá termín číslo digitálního objektu. DOI je vytvořen tak, aby bylo možno co nejjednodušším způsobem jednoznačně identifikovat objekt v jakémkoliv formátu (fyzickém i digitálním). Existující identifikátory, jako třeba ISBN, mohou být použity jako část DOI. Struktura DOI bude podrobně popsána později. V praxi se DOI používá jako identifikační číslo bez nároku na popis obsahu. Obecně z DOI nelze odvodit obsah nebo nějaké popisné atributy materiálu, avšak některé implementace identifikátorů umožňují uchovat obsahovou i popisnou identifikaci přímo v sobě, a tak dávají uživateli k dispozici metadata o identifikovaném objektu. V takovém případě jsou metadata uložená v systému DOI při registraci tou nejbezpečnější cestou k získání informací o objektu. Nemáme-li identifikační číslo závislé na metadatech, docílíme toho, že identifikátor zůstává perzistentní i při změně matadat (např. změna autorských práv), a proto se DOI často nazývá trvalý (perzistentní) identifikátor. 2. Popis (Description): Vytváří popisné atributy objektu, který je DOI identifikována. Jak již bylo řečeno, identifikátor sám o sobě většinou neobsahuje žádná metadata, a proto je zavedena v systému DOI množina metadat, která musí být povinně vyplněna u každého registrovaného objektu. Je to tedy určité metadatové jádro, které je stejné pro všechny registrované digitální objekty. Tato metadata jsou dostupná pro všechny uživatele systému DOI a slouží jako základní popisná metadata objektů identifikovaných v systému DOI. Je zřejmé, že struktura metadat je různá pro různé typy identifikovaných děl. Například popis monografie je odlišný od popisu hudebního záznamu nebo fotografie. Proto jsou zavedeny žánry DOI (DOI Genres). Každý objekt zaregistrovaný do systému DOI je zařazen minimálně do jednoho žánru. Každý DOI žánr může obsahovat ještě další žánrově specifická metadata. V následující tabulce zrekapituluji soubor metadat, který tvoří metadatové jádro systému DOI:
33 Prvek metadat Definice Status Počet Povolené hodnoty DOI DOI Povinné pouze 1 DOI Žánr DOI žánrová klasifikace definovaná IDF21 Povinné minimálně 1 z DOI žánrové klasifikace Identifikátor unikátní identifikátor Určeno žánrem minimálně 1 alfanumerický řetězec obsahující i typ identifikátoru např. ISBN Název jméno, pod kterým je objekt znám Určeno žánrem minimálně 1 alfanumerický řetězec Typ Primární strukturální typ objektu Povinné pouze 1 Dílo Vyjádření Zhmotnění Jednotka Původ Proces, kterým bylo dílo vytvořeno povinné minimálně 1 Originál Modifikace Excerpce Kompilace Kopie Primární agent Jméno nebo identifikátor primárního agenta (většinou autor) povinné minimálně 1 Role agenta Jakou roli má primární agent povinné minimálně 1 kód role Metadatové jádro je množina povinných metadat, ke kterým je možné zadat další administrativní informace při registraci objektu, jako je např. datum registrace, identita uživatele, který provádí registraci, nebo číslo verze záznamu. 3. Rozpoznání (Resolution): Systém DOI se odlišuje od ostatních identifikačních systémů tím, že je "akční". Objekt určený identifikátorem DOI, může být na Internetu rozpoznán a poté získán, je-li na Internetu přístupný. To neznamená, že by byl každý DOI identifikátor implicitně rozpoznatelný, neboť DOI nemusí identifikovat pouze digitální objekty, ale může identifikovat i materiály klasické (monografie, časopisecké články apod.). Rozpoznáním v tomto slova smyslu, rozumíme proces uložení DOI identifikátoru do síťové služby, ze které můžeme pomocí identifikátoru získat zpět informace relevantní 21 IDF - International DOI Foundation
34 danému identifikátoru. Nejjednodušší je takový případ, kdy k jednomu registrovanému DOI identifikátoru uložíme jednu URL lokaci digitálního objektu (Obr.8). Takový případ nazýváme jednoduché rozpoznání (simple resolution). Obr.8 Schéma jednoduchého rozpoznání Digitální objekt však může a často i existuje na Internetu ve více kopiích. Pro DOI systém to není vůbec žádný problém a takový případ pak nazýváme vícenásobné rozpoznání (multiple resolution). K jednomu DOI pak existuje více URL nebo jiných lokačních identifikátorů (Obr.9). Obr.9 Schéma vícenásobného rozpoznání Technologie používaná pro rozpoznávání DOI se nazývá handle system, který bude podrobněji popsán v kapitole č. 2.5.2.
35 4. Pravidla (Policies): V každém komplexním systému je potřeba dodržovat určitá pravidla, aby nenastal chaos a systém byl konzistentní. Nejinak je tomu i v systému DOI, který spravuje IDF (International DOI Foundation). Základní pravidla IDF: • DOI se používá k identifikaci intelektuálního vlastnictví digitálních objektů. Intelektuální vlastnictví je chápáno v celé šíři, tak jak ho definují definice organizace WIPO a další mezinárodní úmluvy. • DOI je primárně určeno k řízení intelektuálního vlastnictví, ale to neznamená, že by se DOI nemohlo používat i pro volně šiřitelné objekty. • Používání systému DOI pro identifikaci je zdarma. Náklady spojené s provozováním systému jsou přímo i nepřímo hrazeny registrovanými členy systému DOI. IDF bude dotovat celý systém až do té doby, než poplatky registrovaných členů systému DOI pokryjí všechny náklady spojené s provozem. • Všechny identifikátory DOI musí být registrovány v globálním registru DOI. • Zápis identifikátoru DOI je standardizován podle americké normy ANSI/NISO Z39.84-2000 • Budou zřízeny registrační autority, aby řídili přidělování identifikátorů DOI a pořizování metadat. • Každý objekt musí mít vyplněnu minimální sadu metadat (metadatové jádro). • Reverzní vyhledávání objektů podle metadat není poskytováno systémem DOI. Takovéto vyhledávání bude nabízeno jednotlivými registračními autoritami. Struktura DOI DOI je složen ze dvou komponent, prefixu a sufixu, které jsou odděleny lomítkem (Obr.10).
36 Obr.10 Struktura identifikátoru DOI Prefix je poskládán z částí oddělených tečkou. První část DOI prefixu je "10", což je vlastně identifikace DOI systému v různých implementacích handle systemu. Další částí prefixu je číslo organizace, které je organizaci přiděleno při registraci. Do budoucna se počítá s dalšími částmi, jež budou reprezentovat podčásti organizace. Například Karlova univerzita jako organizace by mohla mít DOI prefix "10.2504", ale každá fakulta UK by měla přidělený rozšířený prefix. Například Filozofická fakulta UK by mohla mít rozšířený prefix "10.2504.09". Sufix slouží jako jednoznačný identifikátor objektu. Kombinací prefixu a sufixu dostáváme jednoznačný identifikátor objektu v rámci organizace. Sufix může být alfanumerický řetězec, který si uživatel volí při registraci. Může to být pořadové číslo a nebo také již existující identifikátor (ISBN, ISSN, apod.). Syntaxe obou dvou následujících DOI identifikátorů je tedy korektní. Obr.11 Syntaxe DOI identifikátorů 2.5.3 Handle system Technologie handle system, vyvíjená CNRI, byla vybrána k rozpoznávání ve výše popsaném systému DOI, neboť nabízí mnoho reálných výhod jako: • vícenásobné rozpoznání (multiple resolution) • přizpůsobivost (flexibility) • rychlost zpracovávání rozpoznávacích dotazů • úspěšné nasazení v několika projektech digitálních knihoven • úspěšná implementace a podpora v různých dalších reálných projektech • vyvíjeno jako otevřený standard
37 • připravenost k dalšímu vývoji Obecně se handle system využívá k tomu, aby bylo možno rozpoznat univerzální identifikátory (handly) v distribuovaném prostředí Internetu. Jednotliví klienti, jako jsou například webovské prohlížeče, používající speciální rozšíření (většinou ve formě pluginů22 nebo proxy serverů23 ), se připojují k handle systemu a prostřednictví handle system protokolu získávají metadata o digitálních objektech identifikovaných příslušným identifikátorem. Systém rozpoznávání v handle systemu je názorně vidět na dalším obrázku (Obr.12). Celý proces je velmi podobný systému DNS24 , který se v Internetu používá pro rozpoznávání adres URL. 22 Plugin - je speciální softwarová komponenta rozšiřující schopnosti původního software 23 Proxy server - zprostředkovávající server, v klient/server technologiích komunikuje klient se serverem definovaným protokolem. Potřebujeme-li mezi klienta a server vložit nějakou další funkcionalitu, která není protokolem nativně podporována, pak musíme použít právě proxy server, který to zprostředkovaně zajistí. 24 DNS - domain name systém
38 Obr.12 Schéma architektury handle systemu Vysvětlení ke schématu handle systemu: 1. Klient je webový browser a handle požadovaného dokumentu je například 10.123/456. Klient posílá handle do handle systemu k požadovanému rozpoznání. To je provedeno buď přímo pomocí klienta, který má implementovánu nativní podporu handle system protokolu, a nebo prostřednictvím proxy serveru, jestliže klient protokol handle system nepodporuje. 2. Handle systém je soustavou celé řady serverů poskytující handle služby (handle services). Každá služba se skládá z jednoho primárního handle serveru a libovolného počtu sekundárních handle serverů. Sekundární slouží jako záložní servery v případě nefunkčnosti primárního serveru, proto se všechny informace z primárního serveru automaticky replikují na servery sekundární. Každá handle služba musí být zaregistrována v globálním registru handle služeb (Global Handle Registry), který je zodpovědný za to, že zná lokace a jmenné prostory všech
39 veřejných lokálních handle služeb. Naopak i každá lokální handle služba ví, jak přistupovat ke globálnímu registru handlů. To umožňuje handle systemu lokalizovat lokální handle službu, která zná odpověď na rozpoznávací dotaz a vrátí klientovi lokační data dokumentu s požadovaným handlem. 3. & 4. Každý handle může být asociován s jedním nebo více lokačními údaji. V našem příkladě je handle 10.123/456 sdružen, a tudíž i rozpoznán jako URL adresa i jako nový protokol DLS25 . To jsou informace, které jsou vráceny klientovi. Je potřeba si uvědomit, že k jednomu DOI může existovat i více lokačních identifikátorů jednoho typu, takže například můžeme k jednomu dokumentu obdržet více URL adres. Handle systém je čistě rozpoznávací systém a je až na klientovi, co s vrácenými údaji provede. 2.6. Centralizovaný versus distribuovaný model Digitální knihovna je katalog a repozitář digitálních objektů. Ideálním stavem by bylo, kdyby existovala jedna velká digitální knihovna, kde by člověk nalezl vše, co hledá. Taková představa je však velmi utopická, a to z mnoha hledisek. Ať již z technického (komunikační infrastruktura, technické vybavení), regionálního (každý region má svá specifika), oborového (i každý obor má svá specifika) a dalších. Realita je taková, že existuje mnoho digitálních knihoven regionálních, oborových, institucionálních a dalších, které žijí svým vlastním životem. Nicméně velmi často se stává, že si mezi sebou potřebují vyměnit určité digitální objekty (nebo alespoň jejich metadata) a nebo uživatel jedné knihovny chce využít fond jiné knihovny, při zachování stejného uživatelského rozhraní. Na otázku, jaký konkrétní systém či technologie je nejlepší, je velmi těžké odpovědět, protože právě dnes se utvářejí standardy pro distribuované webové služby a je otázkou blízké budoucnosti, co se prosadí. Obecně je důležité, aby systém podporoval automatickou výměnu a sdílení informací, a aby byl založen na otevřených standardech. V dalších podkapitolách nastíním jednotlivé standardy a technologie, které měly, mají a nebo mohou mít praktický význam pro digitální knihovny. 25 DLS - digital library system
40 2.6.1 Z39.50 Jde o standardizovaný protokol pro vyhledávání a přejímání dat. Z39.50 specifikuje abstraktní informační systém s velkou množinou funkcí pro vyhledávání a přejímání záznamů, procházení uspořádaných seznamů, atd. Na straně serveru je tento abstraktní systém mapován na konkrétní systém správy bází dat. Komunikace mezi serverem a klientem je přesně definována protokolem. Implementační detaily serveru jsou zakryté síťovým rozhraním, takže klient může přistupovat k libovolnému typu databáze prostřednictvím stále stejného protokolu. Na straně klienta je abstraktní informační systém zpětně namapován na uživatelské rozhraní, které může být šité na míru konkrétním požadavkům uživatele. Výhodou Z39.50 tedy je, že umožňuje odlišným informačním zdrojům vystupovat pod jednotným uživatelským rozhraním a současně dává každému informačnímu systému možnost vytvořit několik rozhraní pro odlišné skupiny uživatelů [RUB99]. Komunikace, služby Z39.50 je aplikačním protokolem, který specifikuje komunikaci mezi klientem a serverem při vyhledávání informací v bázích dat. Spojení navazuje klient zasláním tzv. inicializačního (init) požadavku, kterým se představí serveru a ve kterém navrhuje hodnoty parametrů nezbytných pro vytvoření Z39.50 relace (verze protokolu, ověření identity, podporované operace, maximální délka zprávy, apod.). Server zareaguje zasláním inicializační (init) odpovědi, ve které oznamuje klientovi hodnoty parametrů a informuje ho, zda souhlasí s vytvořením Z39.50 relace. Následně klient zformuluje dotaz (seznam bází plus termy k vyhledání s hodnotami atributů, pospojované boolskými operátory) a odešle jej jako tzv. Search požadavek. Server prohledá databáze, vytvoří si množinu výsledných záznamů a odpovídá zasláním počtu prvků této množiny v Search odpovědi. V závislosti na počtu nalezených záznamů může tato odpověď obsahovat také některé či všechny nalezené databázové záznamy. Ostatní nalezené záznamy jsou pro klienta k dispozici prostřednictvím dodatečných dotazů, tzv. Present požadavků, po kterých následují Present odpovědi serveru obsahující požadované záznamy. Proces ukončení Z39.50 relace může zahájit jak klient, tak server, a to zasláním Close požadavku a obdržením Close odpovědi. Kromě výše uvedených služeb Init, Search a Present nabízí protokol Z39.50 mnoho dalších operací, jako např. vyhledávání v uspořádaném seznamu (služba Scan), setřídění či zrušení množiny výsledků (služba Sort, resp.
41 Delete), ověřování totožnosti klienta (služba Access-control), zasílání služebních informací (služba Resource-control), atd. Existují novější verze Z39.50 (verze 2 a 3), které mají určitá vylepšení, ale pro účel výběru komunikačního protokolu pro decentralizovaný systém digitální knihovny bude tento popis Z39.50 postačovat. Formáty Protokol rozlišuje 2 druhy záznamů, které se mohou vyskytnout v odpovědi serveru: jsou to záznamy databázové a diagnostické. Databázové záznamy musí vyhovovat některému z registrovaných formátů, přičemž Z39.50-1995 podporuje 15 formátů záznamu: Unimarc, Intermarc, CCF, USmarc, UKmarc, Normarc, Librismarc, Danmarc, Finmarc, MAB, Canmarc, SBN, Picamarc, Ausmarc a Ibermarc. Diagnostické záznamy server posílá v případě, že z nějakých důvodů není schopen obsloužit dotaz. Jsou akceptovány 2 druhy registrovaných diagnostických formátů, a to Bib-1 a Diag-1. Jako přenosová syntaxe záznamu je podporována struktura záznamu pro výměnu dat podle ISO 2709. Obr.13 Systém komunikace mezi uživatelem a knihovnickou databází [AND01] Využití Z39.50 v knihovnictví
42 V knihovnickém prostředí lze protokol Z39.50 využít zejména k: 1. lokálnímu přístupu k externím datovým zdrojům. Pomocí základních funkcí protokolu lze uživateli rozšířit množinu lokálních zdrojů dat o vzdálené databáze, přičemž přístup k lokálním a externím bázím probíhá přes stejné uživatelské rozhraní. Lokální přístup ke vzdáleným zdrojům je nejběžnější implementací protokolu Z39.50 v knihovnách. 2. vytváření virtuálních či distribuovaných souborných katalogů. Skupina knihoven může využít protokolu k poskytnutí přístupu k jejich bázím přes lokálního klienta. Uživatel v jedné z těchto knihoven pak využívá její lokální uživatelské rozhraní k vyhledávání v databázích všech knihoven ve skupině. 3. přejímání záznamů. Z39.50 klient prohledává vzdálenou databázi, přičemž specifikuje požadovanou syntaxi záznamů. Obdržené záznamy pak zkopíruje do lokálního systému za účelem zařazení do lokálního katalogu. Přejímání záznamů se stává velmi rozšířeným využitím Z39.50. Z39.50 z praktického hlediska Ačkoli je představa o využití protokolu Z39.50 jako sjednocujícího prvku při sdílení informací mezi různými knihovnickými systémy velmi revoluční, v praxi je třeba zůstat na zemi. Aplikace, využívající protokol Z39.50, mohou poskytovat jednotné rozhraní jen tehdy, budou-li tento protokol beze zbytku podporovat. Z39.50 je však protokolem velice rozsáhlým, takže ve skutečnosti každý systém založený na protokolu Z39.50 využívá spíše jen větší či menší podmnožinu jeho vlastností. Rozhraní těchto systémů jsou tedy sice založena na standardu protokolu Z39.50, avšak není zaručena jejich vzájemná kompatibilita. Při vytváření distribuovaných či virtuálních souborných katalogů je proto třeba, aby se zúčastněné strany dohodly na konkrétní množině podporovaných vlastností Z39.50, čili na tzv. Profilu, jehož součástí jsou např. typy atributů a jejich hodnoty, syntaxe záznamů, velikosti zpráv, apod. Pokud se v současnosti rozhodneme využívat služeb Z39.50 serverů, zjistíme, že různé servery mají nejenom odlišné vlastnosti, ale jejich chování je dokonce nezřídka v rozporu s protokolem Z39.50, takže je téměř nemožné vytvořit univerzálního Z39.50 klienta, který by dokázal komunikovat s libovolným Z39.50 serverem bez předchozí studie jeho chování.
43 I přes tuto skutečnost přináší protokol Z39.50 mnohá zjednodušení. Usnadňuje například přejímání autorit, protože záznam s sebou nese informaci o použitém formátu. Velký přínos Z39.50 je však zejména v tom, že výrazně zjednodušuje implementaci souborných katalogů, protože rozdíly mezi chováním jednotlivých serverů nejsou zdaleka tak veliké, jaké jsou mezi systémy, které Z39.50 nepodporují. 2.6.2. XML Pokud bych měl jednou větou vyjádřit co je XML, pak bych řekl, že "XML je sada standardů pro výměnu a publikování informací strukturovaným způsobem. Zkratka XML znamená eXtensible Markup Language. Jde o relativně nový značkovací jazyk, vyvinutý konsorciem W3C26 (World Wide Web Consortium) především jako prostředek k překonání omezujících prvků v HTML. HTML27 je velmi populární značkovací jazyk. Některé studie udávají, že celkem existuje asi 800 miliónů webových stránek, které jsou napsány v jazyce HTML. Jazyk HTML je podporován obrovským množstvím aplikací, včetně prohlížečů, editorů, emailových programů, databází, organizátorů a dalších aplikací [BEN01]. Příčina vzniku XML je zdánlivě jednoduchá a je výsledkem úsilí o vyřešení konfliktních požadavků, ke kterým W3C dospělo při stanovení budoucnosti jazyka HTML. Všem je jasné, že lidé potřebují další HTML tagy28 . Tyto nové tagy přitom budou stále specializovanější. Například matematici chtějí tagy pro vzorce. Chemici také potřebují tagy pro vzorce, ovšem pro jiné typy vzorců. Tyto, ze strany uživatelů, zcela opodstatněné požadavky dělají starosti autorům a vývojářům, protože ti chtějí naopak méně tagů. HTML je totiž už dnes natolik komplikované, že aplikace pro práci s HTML jsou velmi složité a mají velké hardwarové nároky. Je možné v rámci jednoho jazyka mít více tagů a zároveň méně tagů? Tuto zdánlivě paradoxní otázku řeší XML dvěma základními změnami oproti HTML: • XML nemá žádné předdefinované tagy • XML má mnohem přísnější syntaxi 26 W3C je organizace zabezpečující vývoj a udržování většiny webových standardů. Další informace o konsorciu W3C získáte na webové adrese www.w3c.org 27 HTML hypertext markup language – předpokládám, že čtenář ví co je HTML a k čemu se používá 28 TAG je značka značkovacího jazyka - například <p> je tag, který v HTML znamená začátek nového odstavce
44 To, že XML nemá žádné předdefinované tagy, dělá z XML rozšiřitelný (eXtensible) jazyk, protože si autoři mohou vytvořit tagy podle jejich konkrétních potřeb. Pozorného čtenáře však okamžitě napadne řada otázek. 1. Jak systém zjistí, že například tag <autor> označuje právě informace o autorovi? 2. Dají se porovnávat různé (například číselné) údaje? 3. Jak se tímto způsobem zjednoduší správa dokumentů? Pokusím se na tyto otázky odpovědět, a tím bych zároveň chtěl objasnit základní význam XML. Ad 1. Klasický prohlížeč dokumentů nepotřebuje vědět, že text uvnitř tagu <autor></autor> jsou personální údaje o autorovi. Většinou mu stačí vědět, jak dané informace zobrazit a čtenář už si podle zobrazení konkrétní obsah uvědomí. Co naopak po prohlížeči požadujeme je, aby příslušné údaje zobrazil jinak pro různé druhy výstupů. Jinak je potřeba zobrazit údaje o autorovi pro tištěný dokument, jinak pro webovou prezentaci a jinak pro wapovou prezentaci. Tím se dostáváme ke hlavní myšlence XML. XML označkuje textový dokument tak, aby informace byli strukturované a automatizovaný systém s nimi mohl pracovat. V XML dokumentech máme možnost uchovávat pouze holé informace bez formátovacích informací. Informace o formátování se k danému XML přiřazují pomocí XSL, nebo kaskádových stylů (XSL a styly definují konečnou podobu jak se XML dokumenty zobrazí). Některé speciální aplikace potřebují vědět, na rozdíl od klasického prohlížeče, že daný údaj je například příjmení autora. To je samozřejmě možné a k tomu slouží XML analyzátory (XML analyzátory jsou programy, které přetransformují XML dokument do stromové hierarchie a umožní přístup k jednotlivým strukturám v dokumentu). Ad 2. Různé údaje v XML se dají porovnávat pomocí XML analyzátorů. Ad 3. Pomocí XML se může správa dokumentů velmi zjednodušit. Máme-li všechny dokumenty v dokumentovém repozitáři ve formátu XML, pak nám stačí uchovávat pouze jednu kopii holého dokumentu a formátovací šablony nám zajišťují automatické formátování do formátů požadovaných uživatelem. Není tedy vůbec žádný problém okamžitě změnit grafický design všech dokumentů. XML v digitálních knihovnách
45 XML se v digitálních knihovnách hodí pro tři základní druhy aplikací: publikování, ukládání a výměnu dat. Všechny druhy aplikací jsou pro implementaci digitálních knihoven zajímavé a přínosné. XML lze jednak využít jako základní formát dokumentů v repozitáři, a nebo z hlediska distribuovaného modelu digitální knihovny zajímavější využití XML jako nástroje pro definici standardizovaných metadat a jejich výměny mezi jednotlivými digitálními knihovnami. Tím se nabízí možnost existence uživatelských rozhraní do digitálních knihoven, přistupujících do více katalogů a repozitářů distribuovaných po celém Internetu. Samozřejmě to předpokládá standardizaci protokolu, založeného na XML, pro přístup do digitálních knihoven. Takovýto protokol by měl podle mého názoru nahradit zastaralý a neflexibilní protokol Z39.50, o kterém jsem psal v předchozí kapitole. 2.6.3. Z39.50 versus XML Je zřejmé, že chceme-li budovat distribuované digitální knihovny, které spolu komunikují, tak k tomu potřebujeme komunikační protokol. Otázkou je zda do moderních digitálních knihoven implementovat starý, méně flexibilní, pouze knihovnicky zaměřený protokol Z39.50 a nebo protokol založený na moderních, obecných a dnes už i standardizovaných protokolech XML, SOAP29 (respektive XP). Pavel Krbec i Naděžda Andrejčíková se ve článcích [KRB01] a [AND01] přiklánějí k používání protokolu Z39.50 a jeho případné doplnění o podporu XML. Stanislav Psohlavec to ve článku [PSO01] již vidí spíše ve prospěch moderních technologií, a to jak z pohledu technologického, tak i ekonomického. Já si myslím, že pro protokol Z39.50 nalezneme využití pouze v knihovnách, ale obecnější "průmyslové" protokoly založené na XML a SOAP se dají využít i v jiných oborech, což sebou přináší i obecné nástroje a technologie, které zlevňují a zefektivňují vývoj a správu knihovnických systému. Dnešní informační technologie se velmi intenzivně zabývají komunikací v heterogenním síťovém prostředí, a tak se nabízí jejich využití i v automatizovaných knihovnických systémech. Samozřejmě, že nakonec musí vzniknout protokol, který bude funkčně velmi podobný protokolu Z39.50, ale bude "zabalený" do moderního a obecného konceptu. Určité iniciativy 29 SOAP je protokol založený na XML, pro výměnu informací v decentralizovaném distribuovaném prostředí.
46 tímto směrem je možné pozorovat již dnes. Například ELAG (European Library Automation Group) vydal na 25. mezinárodním semináři rezoluci [HAL01], která vyzívá k adaptaci stávajících knihovnický protokolů a norem do obecných ITC technologií. Prvním náznakem přechodu k novým technologiím je protokol ZXML, známý též pod názvem eZ3950, jenž počítá s použitím webových služeb a obecného přenosového protokolu SOAP.
47 3. SIGNATURY DIGITÁLNÍCH OBJEKTŮ 3.1. Úvod do kryptografie Co je kryptografie? Vezmeme-li to doslova, pak jde o "studium tajného písma". Často se také používá pojem šifrování. V podstatě jde o vědní disciplínu, která se zabývá šifrováním dat za pomoci matematických metod. Praktické aplikace kryptografie jsou v dnešní době velmi široké a dále porostou. Jde například o posílání utajených informací nezabezpečeným informačním kanálem (například elektronickou poštou) nebo o mechanismus digitálních podpisů. Prostě všude tam, kde je nutné informace utajovat nebo ověřovat jejich pravost [ŠOB00]. Potřebu utajovat některé obsahy digitálních objektů nebo zaručit jejich autenticitu můžeme od digitální knihovny vyžadovat. S kryptografií se můžeme v historii setkat již u starých národů. Dá se říci, že je stará téměř stejně jako umění písma. Už v prvopočátcích písemnictví, někdy před 4000 lety, se objevovaly tajné znaky, které byly určeny pouze pro určitou skupinu zasvěcených. První známou šifrou v pravém slova smyslu byl Skytale, který se používal již v 5. století před naším letopočtem ve Spartě. Princip je velmi jednoduchý. Na hůlku o určitém průměru se namotal proužek kůže a na něj byla napsána zpráva. Poté se proužek odmotal a takto byl odesílán kurýrem. Kdo neznal princip, nedokázal zprávu přečíst. Dalším známým příkladem z historie je první z řady substitučních šifer, která byla údajně používána ke korespondenci mezi Juliem Césarem a královnou Kleopatrou. Její princip je opět prostota sama. Celá abeceda byla odsunuta o tři místa doprava. Pro dnešní kryptografy by rozluštění těchto šifer byla práce v nejhorším případě na několik minut. Ani systémy vyvinuté až do konce minulého století nedokáží kryptografům vzdorovat podle podmínek déle než několik hodin. Ovšem již na počátku tohoto století došlo k prudkému rozvoji kryptografie, který byl spjat s vynálezem telegrafu. Až do konce padesátých let bylo vynalezeno velké množství mechanických šifrovacích strojů. Namátkou mohu uvést jedno z nejpřísněji střežených tajemství 2. světové války - schopnost spojenců luštit německé depeše šifrované Enigmou. Pro tento účel také Alan Turing sestrojil jeden z prvních počítačů Colossus.
48 Kryptografii můžeme rozdělit na dvě hlavní části - symetrickou kryptografii a asymetrickou kryptografii. 3.1.1. Symetrická kryptografie Symetrická kryptografie bývá nazývána též konvenční nebo klasická. Založená je na principu jednoho tajného klíče, který vlastní jak odesilatel tak příjemce. Klíč si předávají nějakým bezpečným kanálem. Zprávy jsou šifrovány i dešifrovány pomocí tohoto klíče. Výhodou symetrické kryptografie je její relativně velká rychlost. Běžně používané algoritmy jsou také dostatečně jednoduché na to, aby mohly být implementovány do speciálních hardwarových komponent. V praktických aplikacích, například v bankovnictví, se dnes používá právě hardwarových karet. Nejznámějšími symetrickými algoritmy jsou DES (Data Encryption Standard), 3DES (TripleDES), IDEA (International Data Encryption Algorithm), CAST, BlowFish a TwoFish. 3.1.2. Asymetrická kryptografie a digitální podpis Asymetrická kryptografie, neboli kryptografie s veřejným klíčem, využívá jiné myšlenky. Každý uživatel má dva klíče. Jeden je tajný (soukromý) a jeden veřejný. Využití asymetrické kryptografie se dělí do dvou hlavních skupin - na přenos tajných zpráv a na digitální podpis. Při přenosu tajné zprávy je zpráva odesílatelem zašifrována pomocí veřejného klíče adresáta. Kryptografický algoritmus zaručuje, že zprávu bude schopen dešifrovat (a tedy i přečíst) pouze adresát, a to pomocí svého tajného klíče. Digitální podpis používá podobný princip, ale v opačném směru. Cílem digitálního podpisu je autentifikace zprávy - ověření její pravosti a úplnosti. Zpráva se tedy zašifruje pomocí tajného klíče odesílatele a takto získaný podpis se přidá k původní (nešifrované) zprávě. Adresát si ověří pravost odesílatele tak, že pomocí odesílatelova veřejného klíče dešifruje podpis. Pokud obsah zprávy je totožný s dešifrovaným podpisem, je odesilatel autentický, neboli napsal to opravdu ten, kdo se vydává za odesilatele.
49 Ve skutečnosti je to trochu složitější. Nešifruje se totiž celá zpráva, tak jak je, ale ze zprávy se vytvoří hašovací funkcí (obvykle MD5 nebo SHA-1) tzv. Otisk zprávy, který si můžeme představit jako otisk prstu člověka. Až tento otisk se šifruje. Proč se vytváří otisk zprávy? Prvním důvodem je velmi nízká rychlost asymetrických algoritmů. Uvádí se, že asymetrické šifry jsou řádově tisíckrát pomalejší, než šifry symetrické. Druhým důvodem je velikost zprávy. Kdybychom k původní zprávě přidali ještě zprávu zašifrovanou, tak by se velikost zprávy zdvojnásobila. Zašifrováním otisku můžeme podpis omezit na konstantní velikost. Většinou se používá 128 bitový nebo 160 bitový otisk. Nejznámějšími asymetrickými algoritmy jsou RSA, Diffie-Hellman, ElGamal (varianta Diffie-Hellmana), DSA a algoritmy založené na eliptických křivkách. 3.2. Potřeba signatur u digitálních objektů Po krátkém úvodu do základů kryptografie chci v této kapitole vysvětlit potřebu signatur u digitálních objektů. V kapitole "Digitální objekt" jsem uvedl, že se digitální objekt skládá ze čtyř komponent. Identifikátoru, metadat, obsahu a signatury. Signatura je komponenta volitelná a často se ani v praxi neimplementuje, nicméně v některých aplikacích má svůj smysl. Hlavní funkce signatur digitálních objektů jsou: 1. zajištění možnosti kontroly, zda obsah dokumentu nebyl změněn 2. zajištění věrohodnosti autora obsahu Jiří Peterka30 v jedné emailové konferenci přirovnává elektronickou signaturu k obálce s pečetí, která dává příjemci záruku, že se její obsah cestou od odesilatele nezměnil, a zároveň prokazuje, že obálku zalepil někdo, kdo vládne danou pečetí . Příklad: Představte si elektronický archív nějakého ministerstva, který zpřístupňuje oficiální dokumenty pro veřejnost. Jistě výborná služba. Ministerstvo by však mělo požadovat zajištění věrohodnosti dokumentů. Co kdyby někdo úmyslně či neúmyslně vyměnil 30 Jiří Peterka
50 nebo pouze pozměnil oficiální dokumenty v archívu? I malá změna v dokumentu může naprosto změnit smysl celého dokumentu. Archív je informační systém připojený ve veřejné síti, ve které existují potenciální bezpečnostní hrozby jak z vnějšku tak i ze vnitř31 . Řešení: Každý digitální objekt v digitální knihovně má signaturu, která obsahuje digitální podpis ministerstva. Tím je zajištěno, že čtenář dokumentu má možnost ověřit platnost digitálního podpisu a tím autenticitu dokumentu. Navíc má i jistotu, že dokument nebyl pozměněn. Výsledkem spolupráce konsorcia W3C a Internet Engineering Task Force je nový standard zvaný XML-Signature Syntax and Processing [BAR02]. Ten specifikuje XML podepisování dokumentů a při dodržení pravidel standardu, zajišťuje autenticitu autora, autenticitu dokumentu i jeho integritu. 31 Většina bezpečnostních průniků do informačních systémů je provedena ze vnitř organizací (pracovníky organizace) nicméně ani průniky z vnějšku nejsou zanedbatelné. Otázka bezpečnosti informačních systému přesahuje rámec této práce.
51 4. DIGITÁLNÍ KNIHOVNY A METADATA 4.1 Úvod do metadat Kapitolu o metadatech jsem do své práce zařadil, protože metadata mají významný vliv na elektronické dokumenty, a tím i na digitální knihovny. Právě proto bychom při budování digitální knihovny měli vědět, co nám metadata mohou nabídnout a jak by digitální knihovna měla s metadaty pracovat a využívat je. V současné době existuje v celosvětovém měřítku nepředstavitelně rozsáhlé bohatství informací uchovávaných v dokumentech. Většinou není problémem, aby určité informace byly publikovány, ale problém je relevantní publikované informace vyhledat. K tomu, aby byly informace dobře vyhledatelné, slouží kvalitní popis dokumentů, který se opírá o identifikační popis, pořádací systémy a metody obsahové analýzy. Výsledkem jsou informace o dokumentech, respektive informace o obsazích dokumentů. Nejčastěji se používá termín informace o informacích - metadata. Cílem této kapitoly je ukázat aktuální trendy v používání metadat, a to zejména v elektronických dokumentech, protože právě tam je jejich nejširší a nejzajímavější uplatnění. Zaměříme-li se na elektronické dokumenty, pak v současnosti nejpoužívanějším médiem pro jejich publikaci je síť Internet, kde můžeme nalézt opravdu velké množství dokumentů. A právě tato skutečnost může způsobit tak zvaný informační problém. Na Internetu je tolik dokumentů, že se nám může stát, a velmi často se nám to i stává, že nemůžeme rychle, kvalitně a uspokojivě nalézt relevantní dokumenty. Buď nenajdeme žádný relevantní dokument a nebo naopak, a to je obvyklejší případ, najdeme velmi mnoho relevantních dokumentů a neumíme rychle rozhodnout, které z nich jsou pro nás zajímavé a které mají nulovou informační hodnotu. K řešení tohoto problému by mohla sloužit metadata. Jaké jsou aktuální trendy v identifikačním popisu a pořádání elektronických dokumentů na Internetu a jak nám tyto metody slouží k vyhledávání, jsem se pokusil popsat v následujících kapitolách.
52 4.2. Normy a specifikace Velkou nutnost metadat elektronických dokumentů si uvědomuje i organizace W3C32 . Výsledkem jejich velkého zájmu o metadata je vytvoření RDF - Resource Description Framework33 a PICS - Platform for Internet Content Selection. Nutnost demonstruje i prohlášení organizace W3C. "Možnosti využití Internetu jsou nekonečné, co nám však internetové technologie nenabízejí, jsou informace o informacích. Identifikační popis, katalogizace a popisné informace v takové formě, aby je bylo možné správně vyhledávat a zpracovávat pomocí počítačů. Jinými slovy, dnešní web potřebuje metadata." [W3CMDS00] 4.2.1. PICS - Platform for Internet Content Selection PICS je množina specifikací, umožňující distribuovat metadata o obsahu elektronických dokumentů ve formě štítků (labels34 ). Štítky obsahují informace v jednoduché, počítačem čitelné formě a jsou primárně určeny k selekci, filtraci a profilování informací danému informačnímu konzumentovi. Vše se samozřejmě odehrává v pozadí a potenciální čtenář o filtraci nemusí vědět. Jistě si dovedeme představit velké množství situací, kdy se nám takovéto automatické filtrování informací hodí a vyplatí. Původně byla tato technologie vyvíjena k tomu, aby rodiče či učitelé měli možnost odfiltrovat nežádoucí materiály pro děti. Dnes tuto technologii s velkým ohlasem přijmou i IT manažeři firem, kterým umožní automatickou cenzuru dokumentů pro jejich zaměstnance. Prohlížení nevhodných dokumentů v pracovní době je pro firmy velkým problémem a tato technologie jim dává do rukou nástroj, kterým zamezí, aby si zaměstnanci prohlíželi webové stránky cestovních kanceláří, zábavné webové stránky, apod. Tuto skutečnost dnes řada firem řeší tak, že neposkytuje svým zaměstnancům plný přístup k Internetu, to jim však na druhou stranu snižuje přístup k mnoha důležitým informačním zdrojům. Normu PICS podporují i vládní instituce, jelikož volné šíření informací všem sociálním skupinám, nemusí být například z morálních či etických důvodů vhodné. Vydavatel či 32 W3C - organizace pro standardizaci webových technologií. 33 Framework - je ucelený znovupoužitelný systém, nad kterým je možno budovat další nadstavby 34 Label - obecně štítek, návěští, záložka (je velmi složité najít ekvivalentní český název pro již zaběhlé anglické výrazy)
53 autor dokumentu má v rámci standardu PICS možnost určit kategorii nebo cílovou skupinu pro publikovaný dokument. Komise pro komunikaci EU k tomu ve 34. bodě svého prohlášení říká: "Komise podporuje vývoj mezinárodních systémů pro hodnocení obsahu dokumentů kompatibilních s protokolem PICS a dostatečně flexibilních k regionálním a kulturním rozdílům, jenž budou přínosem jak pro uživatele, tak pro vydavatele." [EPCC97] Osobně si myslím, že tato technologie bude mít pro vývoj Internetu velký význam nejenom jako úmyslná cenzura, ale i jako inteligentní filtrace nerelevantních dokumentů. Tím nám také částečně pomáhá řešit informační problém. Z pohledu implementace digitálních knihoven je dobré o PICS vědět a případně primární dokumenty o tato metadata obohatit. 4.2.2. RDF - Resource Description Framework RDF (Resource Description Framework) je koncepce zápisu metadat, možňující univerzální a strojově srozumitelnou formu popisu informačních zdrojů (digitálních objektů) v distribuovaném prostředí elektronické sítě Internet. Nejdůležitějšími vlastnostmi celého konceptu je univerzálnost metadat, strojově srozumitelná forma, lepší přesnost než fulltextové vyhledávání a budoucí rozšiřitelnost pomocí RDF schémat. RDF bylo publikováno a doporučeno k používání organizací W3C dne 22.2.1999. RDF specifikace 1.0 vyšla 27.3.2000. Dá se říci, že PICS je podmnožinou RDF. Z předchozí kapitoly je zřejmé, že PICS je primárně určen k popisu obsahu dokumentu. RDF samozřejmě také, ale navíc poskytuje informace i o dalších, z knihovnického pohledu zajímavých prvcích. Jazyk RDF je deklarativní, standardně používající jazyk XML pro zápis metadat digitálního objektu. Tento digitální objekt, často zvaný zdroj, může být jakýkoliv elektronický objekt. Např. elektronický textový dokument, webová stránka, grafický soubor, zvukový soubor, video, apod. V praxi RDF nemusí popisovat pouze digitální objekty, ale dokonce jakékoliv reálné objekty jako jsou výrobky, budovy, instituce, apod.
54 Další vlastností RDF záznamů je možnost odkazu (reference) na jiný RDF záznam, poskytující podrobnější informace. Toto je velmi silný nástroj, který nám ve své podstatě umožňuje definovat hypermetadatovou síť. RDF poskytuje koncepci (framework), ve které nezávislé komunity mohou vytvářet slovníky35 hodící se k jejich specifickým potřebám a mají možnost sdílet tyto slovníky s dalšími komunitami36 . Při sdílení takto vytvořených slovníků musí být význam jednotlivých termínů, respektive jednotlivých vlastností, předem dán a alespoň rámcově normován. Právě k tomu nám slouží RDF schémata. Schéma definuje významy, vlastnosti a vazby mezi jednotlivými atributy metadat37 . Schéma také obsahuje určitá omezení hodnot metadatových atributů a přebírání atributů z jiných schémat. Jazyk RDF umožňuje každému dokumentu, aby obsahoval metadatové údaje (URL lokací) k objasnění, které slovníky jsou v dokumentu používány. Jedním z nejznámějších slovníků je Dublin Core, jenž byl vynalezen knihovnickou komunitou k identifikačnímu popisu a klasifikaci webových dokumentů. Další slovníky mohou zahrnovat úplně jiné obory a to i komerční. Jako příklad můžeme uvést fiktivní aplikaci slovníku pro komunitu pohostinství, který by sloužil k identifikaci a popisu restauračních zařízení. Tak například aplikace slovníku RESTAURACE by mohla obsahovat metadatové atributy typu "adresa", "cenová skupina", "kvalita jídla", "další služby", apod. Zde však může nastat problém, kdy dva různé slovníky použijí stejná jména některých metadatových atributů. V těchto případech nastává potřeba použití jmenných prostorů. Již jsem se několikrát zmínil o tom, že RDF je odvozeno z idejí XML. RDF používá XML jmenné prostory k povolení více stejně nazvaných metadatových prvků pro různá schémata. Mám na mysli situaci, kdy dvě různá schémata chtějí používat stejné jméno metadatového prvku. Např. schéma PUB chce používat atribut ADDRESS jako fyzickou adresu daného objektu (ulice, město, PSČ, ) a schéma PHOTO chce používat atribut ADDRESS jakou URL lokaci na elektronickou fotografii. 35 termínem slovník máme v tomto kontextu na mysli seznam atributů metadat 36 komunitou myslíme určitou, např. oborově zaměřenou, skupinu lidí 37 metadatový atribut je jedna popisná informace z metadatového schématu
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet
Architektura a implementace digitálních knihoven v prostředí sítě Internet

Recommended

Trendy automatizovaných knihovních systémů
Trendy automatizovaných knihovních systémůTrendy automatizovaných knihovních systémů
Trendy automatizovaných knihovních systémů
kadlec
 
Internet jako zdroj informací
Internet jako zdroj informacíInternet jako zdroj informací
Internet jako zdroj informací
CEINVE
 
Elektronické informační zdroje
Elektronické informační zdrojeElektronické informační zdroje
Elektronické informační zdroje
CEINVE
 
KPI závěrečný úkol
KPI závěrečný úkolKPI závěrečný úkol
KPI závěrečný úkol
Libor Mühlpachr
 
Kde a jak hledat informace
Kde a jak hledat informaceKde a jak hledat informace
Kde a jak hledat informace
CEINVE
 
Digitisation activities and standards in Czech Archives
Digitisation activities and standards in Czech ArchivesDigitisation activities and standards in Czech Archives
Digitisation activities and standards in Czech Archives
ICARUS - International Centre for Archival Research
 
02 OAIS.pptx
02 OAIS.pptx02 OAIS.pptx
02 OAIS.pptx
MagdalnaBohuslavov
 
Online katalogy a weby knihoven
Online katalogy a weby knihovenOnline katalogy a weby knihoven
Online katalogy a weby knihoven
JanKanka
 

Recommended

Trendy automatizovaných knihovních systémů
Trendy automatizovaných knihovních systémůTrendy automatizovaných knihovních systémů
Trendy automatizovaných knihovních systémů
kadlec
 
Internet jako zdroj informací
Internet jako zdroj informacíInternet jako zdroj informací
Internet jako zdroj informací
CEINVE
 
Elektronické informační zdroje
Elektronické informační zdrojeElektronické informační zdroje
Elektronické informační zdroje
CEINVE
 
KPI závěrečný úkol
KPI závěrečný úkolKPI závěrečný úkol
KPI závěrečný úkol
Libor Mühlpachr
 
Kde a jak hledat informace
Kde a jak hledat informaceKde a jak hledat informace
Kde a jak hledat informace
CEINVE
 
Digitisation activities and standards in Czech Archives
Digitisation activities and standards in Czech ArchivesDigitisation activities and standards in Czech Archives
Digitisation activities and standards in Czech Archives
ICARUS - International Centre for Archival Research
 
02 OAIS.pptx
02 OAIS.pptx02 OAIS.pptx
02 OAIS.pptx
MagdalnaBohuslavov
 
Online katalogy a weby knihoven
Online katalogy a weby knihovenOnline katalogy a weby knihoven
Online katalogy a weby knihoven
JanKanka
 
TTT IVIG
TTT IVIGTTT IVIG
TTT IVIG
JanMat
 
Tomas neugebauer kpi_znackovani
Tomas neugebauer kpi_znackovaniTomas neugebauer kpi_znackovani
Tomas neugebauer kpi_znackovani
Tomáš Neugebauer
 
KPI Zaverecny ukol
KPI Zaverecny ukolKPI Zaverecny ukol
KPI Zaverecny ukol
magdickakahy
 
Blok expertů KISK: Ditigalizace, Metadata, Pojekty
Blok expertů KISK: Ditigalizace, Metadata, PojektyBlok expertů KISK: Ditigalizace, Metadata, Pojekty
Blok expertů KISK: Ditigalizace, Metadata, Pojekty
MoravskaZemskaKnihovna
 
Kpi závěrečný úkol
Kpi závěrečný úkolKpi závěrečný úkol
Kpi závěrečný úkol
ValesovaM
 
Sec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizecSec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizec
Milan Janíček
 
úVod do studia
úVod do studiaúVod do studia
úVod do studia
Petr
 
Digitalizace a dlouhodobá ochrana digitálních dokumentů
Digitalizace a dlouhodobá ochrana digitálních dokumentůDigitalizace a dlouhodobá ochrana digitálních dokumentů
Digitalizace a dlouhodobá ochrana digitálních dokumentů
MoravskaZemskaKnihovna
 
Experimentální OPAC
Experimentální OPACExperimentální OPAC
Experimentální OPAC
kadlec
 
COinS
COinS COinS
COinS
Milan Janíček
 
Publikování dokumentů
Publikování dokumentůPublikování dokumentů
Publikování dokumentů
CEINVE
 
Projekt Europeana Newspapers - online brána k evropským historickým novinám
Projekt Europeana Newspapers - online brána k evropským historickým novinámProjekt Europeana Newspapers - online brána k evropským historickým novinám
Projekt Europeana Newspapers - online brána k evropským historickým novinám
Europeana Newspapers
 
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v časeKlára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
ÚISK FF UK
 
Ceska digitalni knihovna
Ceska digitalni knihovnaCeska digitalni knihovna
Ceska digitalni knihovna
martinlhotak
 
Jiří Nechvátal: Projekt Obálkyknih.cz
Jiří Nechvátal: Projekt Obálkyknih.czJiří Nechvátal: Projekt Obálkyknih.cz
Jiří Nechvátal: Projekt Obálkyknih.cz
ÚISK FF UK
 
Vyhledávání informací a zpracování rešerší I.
Vyhledávání informací a zpracování rešerší I.Vyhledávání informací a zpracování rešerší I.
Vyhledávání informací a zpracování rešerší I.
Drahomíra Dvořáková
 
Role elektronického publikování
Role elektronického publikováníRole elektronického publikování
Role elektronického publikování
lindask
 
Elektronické publikování a vědecká komunikace
Elektronické publikování a vědecká komunikaceElektronické publikování a vědecká komunikace
Elektronické publikování a vědecká komunikace
lindask
 
E-kniha a její čtečka
E-kniha a její čtečkaE-kniha a její čtečka
E-kniha a její čtečka
JanKanka
 
05 Standardy a nástroje.pptx
05 Standardy a nástroje.pptx05 Standardy a nástroje.pptx
05 Standardy a nástroje.pptx
MagdalnaBohuslavov
 
FlexBook Software - Conceptual Architecture
FlexBook Software - Conceptual ArchitectureFlexBook Software - Conceptual Architecture
FlexBook Software - Conceptual Architecture
David Pasek
 
Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2
David Pasek
 

More Related Content

Similar to Architektura a implementace digitálních knihoven v prostředí sítě Internet

KPI Zaverecny ukol
KPI Zaverecny ukolKPI Zaverecny ukol
KPI Zaverecny ukol
magdickakahy
 
Kpi závěrečný úkol
Kpi závěrečný úkolKpi závěrečný úkol
Kpi závěrečný úkol
ValesovaM
 
Sec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizecSec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizec
Milan Janíček
 
úVod do studia
úVod do studiaúVod do studia
úVod do studia
Petr
 
Ceska digitalni knihovna
Ceska digitalni knihovnaCeska digitalni knihovna
Ceska digitalni knihovna
martinlhotak
 

Similar to Architektura a implementace digitálních knihoven v prostředí sítě Internet (20)

TTT IVIG
TTT IVIGTTT IVIG
TTT IVIG
 
Tomas neugebauer kpi_znackovani
Tomas neugebauer kpi_znackovaniTomas neugebauer kpi_znackovani
Tomas neugebauer kpi_znackovani
 
KPI Zaverecny ukol
KPI Zaverecny ukolKPI Zaverecny ukol
KPI Zaverecny ukol
 
Blok expertů KISK: Ditigalizace, Metadata, Pojekty
Blok expertů KISK: Ditigalizace, Metadata, PojektyBlok expertů KISK: Ditigalizace, Metadata, Pojekty
Blok expertů KISK: Ditigalizace, Metadata, Pojekty
 
Kpi závěrečný úkol
Kpi závěrečný úkolKpi závěrečný úkol
Kpi závěrečný úkol
 
Sec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizecSec 2010-do knihovny-skrze_prohlizec
Sec 2010-do knihovny-skrze_prohlizec
 
úVod do studia
úVod do studiaúVod do studia
úVod do studia
 
Digitalizace a dlouhodobá ochrana digitálních dokumentů
Digitalizace a dlouhodobá ochrana digitálních dokumentůDigitalizace a dlouhodobá ochrana digitálních dokumentů
Digitalizace a dlouhodobá ochrana digitálních dokumentů
 
Experimentální OPAC
Experimentální OPACExperimentální OPAC
Experimentální OPAC
 
COinS
COinS COinS
COinS
 
Publikování dokumentů
Publikování dokumentůPublikování dokumentů
Publikování dokumentů
 
Projekt Europeana Newspapers - online brána k evropským historickým novinám
Projekt Europeana Newspapers - online brána k evropským historickým novinámProjekt Europeana Newspapers - online brána k evropským historickým novinám
Projekt Europeana Newspapers - online brána k evropským historickým novinám
 
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v časeKlára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
Klára Rösslerová: Proměny výměnných formátů bibliografických dat v čase
 
Ceska digitalni knihovna
Ceska digitalni knihovnaCeska digitalni knihovna
Ceska digitalni knihovna
 
Jiří Nechvátal: Projekt Obálkyknih.cz
Jiří Nechvátal: Projekt Obálkyknih.czJiří Nechvátal: Projekt Obálkyknih.cz
Jiří Nechvátal: Projekt Obálkyknih.cz
 
Vyhledávání informací a zpracování rešerší I.
Vyhledávání informací a zpracování rešerší I.Vyhledávání informací a zpracování rešerší I.
Vyhledávání informací a zpracování rešerší I.
 
Role elektronického publikování
Role elektronického publikováníRole elektronického publikování
Role elektronického publikování
 
Elektronické publikování a vědecká komunikace
Elektronické publikování a vědecká komunikaceElektronické publikování a vědecká komunikace
Elektronické publikování a vědecká komunikace
 
E-kniha a její čtečka
E-kniha a její čtečkaE-kniha a její čtečka
E-kniha a její čtečka
 
05 Standardy a nástroje.pptx
05 Standardy a nástroje.pptx05 Standardy a nástroje.pptx
05 Standardy a nástroje.pptx
 

More from David Pasek

Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2
David Pasek
 
E tourism v oblasti cestovního ruchu
E tourism v oblasti cestovního ruchuE tourism v oblasti cestovního ruchu
E tourism v oblasti cestovního ruchu
David Pasek
 
Spectre meltdown performance_tests - v0.3
Spectre meltdown performance_tests - v0.3Spectre meltdown performance_tests - v0.3
Spectre meltdown performance_tests - v0.3
David Pasek
 

More from David Pasek (20)

FlexBook Software - Conceptual Architecture
FlexBook Software - Conceptual ArchitectureFlexBook Software - Conceptual Architecture
FlexBook Software - Conceptual Architecture
 
Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2Flex Cloud - Conceptual Design - ver 0.2
Flex Cloud - Conceptual Design - ver 0.2
 
E tourism v oblasti cestovního ruchu
E tourism v oblasti cestovního ruchuE tourism v oblasti cestovního ruchu
E tourism v oblasti cestovního ruchu
 
Intel & QLogic NIC performance test results v0.2
Intel & QLogic NIC performance test results v0.2Intel & QLogic NIC performance test results v0.2
Intel & QLogic NIC performance test results v0.2
 
VMware ESXi - Intel and Qlogic NIC throughput difference v0.6
VMware ESXi - Intel and Qlogic NIC throughput difference v0.6VMware ESXi - Intel and Qlogic NIC throughput difference v0.6
VMware ESXi - Intel and Qlogic NIC throughput difference v0.6
 
Exchange office 3.0 - Stanovisko Státní banky československé
Exchange office 3.0 - Stanovisko Státní banky československéExchange office 3.0 - Stanovisko Státní banky československé
Exchange office 3.0 - Stanovisko Státní banky československé
 
Network performance test plan_v0.3
Network performance test plan_v0.3Network performance test plan_v0.3
Network performance test plan_v0.3
 
vSAN architecture components
vSAN architecture componentsvSAN architecture components
vSAN architecture components
 
FlexBook overview - v2.4
FlexBook overview - v2.4FlexBook overview - v2.4
FlexBook overview - v2.4
 
VMware HCI solutions - 2020-01-16
VMware HCI solutions - 2020-01-16VMware HCI solutions - 2020-01-16
VMware HCI solutions - 2020-01-16
 
Hybrid cloud overview and VCF on VxRAIL
Hybrid cloud overview and VCF on VxRAILHybrid cloud overview and VCF on VxRAIL
Hybrid cloud overview and VCF on VxRAIL
 
Private IaaS Cloud Provider
Private IaaS Cloud ProviderPrivate IaaS Cloud Provider
Private IaaS Cloud Provider
 
Spectre/Meltdown security vulnerabilities FAQ
Spectre/Meltdown security vulnerabilities FAQSpectre/Meltdown security vulnerabilities FAQ
Spectre/Meltdown security vulnerabilities FAQ
 
FlexBook Basic Overview - v2.0
FlexBook Basic Overview - v2.0FlexBook Basic Overview - v2.0
FlexBook Basic Overview - v2.0
 
Spectre meltdown performance_tests - v0.3
Spectre meltdown performance_tests - v0.3Spectre meltdown performance_tests - v0.3
Spectre meltdown performance_tests - v0.3
 
FlexBook basic overview v2.0
FlexBook basic overview v2.0FlexBook basic overview v2.0
FlexBook basic overview v2.0
 
FlexBook - reservation system basic overview v1.1
FlexBook - reservation system basic overview v1.1FlexBook - reservation system basic overview v1.1
FlexBook - reservation system basic overview v1.1
 
CLI for VMware Distributed Switch (Community project)
CLI for VMware Distributed Switch (Community project)CLI for VMware Distributed Switch (Community project)
CLI for VMware Distributed Switch (Community project)
 
Dell VLT reference architecture v2 0
Dell VLT reference architecture v2 0Dell VLT reference architecture v2 0
Dell VLT reference architecture v2 0
 
Metro Cluster High Availability or SRM Disaster Recovery?
Metro Cluster High Availability or SRM Disaster Recovery?Metro Cluster High Availability or SRM Disaster Recovery?
Metro Cluster High Availability or SRM Disaster Recovery?
 

Architektura a implementace digitálních knihoven v prostředí sítě Internet

  • 1. 1 Univerzita Karlova v Praze Filozofická fakulta Ústav informačních studií a knihovnictví Diplomová práce 2002 Bc. David Pašek
  • 2. 2 Univerzita Karlova v Praze Filozofická fakulta Ústav informačních studií a knihovnictví Bc. David Pašek Architektura a implementace digitálních knihoven v prostředí sítě Internet Diplomová práce Praha 2002
  • 3. 3 Vedoucí diplomové práce: PhDr. Eva Bratková Oponent diplomové práce: Datum obhajoby: Hodnocení:
  • 4. 4 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité informační zdroje. V Praze, 18. prosince 2001 ………………………….. podpis diplomanta
  • 5. 5 Identifikační záznam PAŠEK, David. Architektura a implementace digitálních knihoven v prostředí sítě Internet. Praha, 2002. 77 s., 38 s. příl. Diplomová práce. Univerzita Karlova v Praze, Filozofická fakulta, Ústav informačních studií a knihovnictví 2001. Vedoucí diplomové práce PhDr. Eva Bratková. Abstrakt Cílem práce je charakteristika stávající situace budování digitálních knihoven ve světovém měřítku se zaměřením na problematiku jejich architektury a implementace v podmínkách sítě Internet. Práce se věnuje především důležitým komponentám digitálních knihoven a jejich specifikaci. Mezi důležité komponenty patří digitální objekt, repozitář, katalog a uživatelské rozhraní. V práci jsou rovněž popsány signatury digitálních objektů, které jsou důležité zejména z hlediska bezpečnosti, neměnnosti obsahu a věrohodnosti autora digitálního objektu. Pozornost byla věnována i normám a specifikacím metadat, která jsou velmi důležitá pro budování katalogu a vyhledávání relevantních digitálních objektů. Přínosem práce je podání návrhu optimálního modelu digitální knihovny a ukázky praktických aplikací na navrhovaném modelu. Klíčová slova Digitální archív, digitální knihovna, digitální objekt, digitální podpis, DOI, Dublin Core, handle systém, katalog, metadata, PICS, RAP, RDF, repozitář, signatura, transakční log, unikátní identifikátor, uživatelské rozhraní, XML
  • 6. 6 OBSAH 1.ÚVOD.....................................................................................................................10 1.1 CO JE DIGITÁLNÍ KNIHOVNA ................................................................................. 10 1.2. PROČ BUDOVAT DIGITÁLNÍ KNIHOVNY...................................................................... 14 1.3. TERMÍNY A DEFINICE ........................................................................................ 15 2. ARCHITEKTURY DIGITÁLNÍCH KNIHOVEN ..........................................................17 2.1. PRINCIPY BUDOVÁNÍ DIGITÁLNÍCH KNIHOVEN ............................................................. 17 2.2. DIGITÁLNÍ OBJEKT ........................................................................................... 20 2.3. REPOZITÁŘ ................................................................................................... 23 2.4. KATALOG ..................................................................................................... 26 2.5. UNIVERZÁLNÍ IDENTIFIKAČNÍ SYSTÉMY .................................................................... 29 2.5.1 URI, URN a URL ...................................................................................... 29 2.5.2 DOI - identifikátor digitálního objektu ........................................................ 30 2.5.3 Handle system........................................................................................ 36 2.6. CENTRALIZOVANÝ VERSUS DISTRIBUOVANÝ MODEL ....................................................... 39 2.6.1 Z39.50.................................................................................................. 40 2.6.2. XML..................................................................................................... 43 2.6.3. Z39.50 versus XML................................................................................. 45 3. SIGNATURY DIGITÁLNÍCH OBJEKTŮ ...................................................................47 3.1. ÚVOD DO KRYPTOGRAFIE.................................................................................... 47 3.1.1. Symetrická kryptografie .......................................................................... 48 3.1.2. Asymetrická kryptografie a digitální podpis ................................................. 48 3.2. POTŘEBA SIGNATUR U DIGITÁLNÍCH OBJEKTŮ ............................................................. 49 4. DIGITÁLNÍ KNIHOVNY A METADATA ...................................................................51 4.1 ÚVOD DO METADAT ........................................................................................... 51 4.2. NORMY A SPECIFIKACE ...................................................................................... 52 4.2.1. PICS - Platform for Internet Content Selection ............................................ 52 4.2.2. RDF - Resource Description Framework...................................................... 53 4.2.3. Dublin Core........................................................................................... 58 4.3. REKAPITULACE SOUČASNÉ SITUACE METADAT NA INTERNETU............................................ 62 4.4. PŘÍNOS METADAT PRO DIGITÁLNÍ KNIHOVNY .............................................................. 63 5. NÁVRH MODELU DIGITÁLNÍ KNIHOVNY..............................................................65 5.1. ARCHITEKTURA SYSTÉMU.................................................................................... 66
  • 7. 7 5.2. IMPLEMENTACE UŽIVATELSKÉHO ROZHRANÍ ............................................................... 67 5.3. IMPLEMENTACE KATALOGU .................................................................................. 70 5.4. IMPLEMENTACE REPOZITÁŘE ................................................................................ 72 5.5. OPTIMALIZACE VÝKONU ..................................................................................... 73 6. ZÁVĚR...................................................................................................................75 SEZNAM OBRÁZKŮ ...................................................................................................77 REJSTŘÍK..................................................................................................................78 REFERENCE...............................................................................................................80 PŘÍLOHA...................................................................................................................84
  • 8. 8 PŘEDMLUVA Již řadu let se zabývám problematikou budování informačních systémů. V minulých šesti letech jsem se intenzívně věnoval webovým internetovým systémům a on-line databázím. Poslední dva roky usilovně pracuji na hledání, návrhu a realizaci „ideálního“ dokumentově orientovaného systému, který slouží jako centrální katalog a repozitář digitálních objektů. V rámci mé vlastní softwarové firmy jsem právě na základě skloubení poznatků ze studia informatiky na Matematicko-fyzikální fakultě a informačních studií na Ústavu informačních studií a knihovnictví otevřel projekt digitální knihovny jako univerzální dokumentové báze dat pod pracovním názvem DigLib. Proto jsem přivítal možnost výběru tohoto tématu diplomové práce, které mi umožnilo podívat se na problematiku architektury digitální knihovny v širších souvislostech. Často jsem se v praxi setkal s dvěma naprosto odlišnými postoji k filozofii digitálních knihoven. Většina uživatelů, ale hlavně informačních manažerů, si dnes již uvědomuje potřebu centrální evidence dokumentů, identifikaci dokumentů pomocí metadat a jejich zařazení do relevantních kategorií. Na druhou stranu je patrná nechuť a neochota uživatelů metadata k dokumentům pořizovat. S tímto paradoxem se moderní informační specialista musí vyrovnat, a tato práce by měla ukázat směr, kudy je potřeba se ubírat. Nové technologie a implementace moderních standardů mohou pomoci vyřešit tento paradox. V závěru práce je popsána konkrétní implementace digitální knihovny, tak jak jsme ji společně s kolegy v naší firmě vytvořili. Také se zmíním o nasazení tohoto produktu v institucích, firmách a webových portálech v České republice a Německu. Práce je založena na výběru a studiu hlavně on-line dostupných zdrojů, protože dané téma je natolik nové a progresivní, že je velmi těžké najít kvalitní informace v klasické monografické literatuře. Více informací existuje v tradičních periodikách a nejvíce jich je v elektronické podobě. Jako základní dokument je použit framework1 od Roberta Kahna (CNRI) a Roberta Wilensky (UC Berkeley) [KAH95]. Tato práce je často nazývána jako "Kahn/Wilensky architektura digitální knihovny". 1 Framework je koncept (rámcový systém), nad nímž je možno tvořit další výzkum nebo vývoj
  • 9. 9 Na tomto místě bych chtěl poděkovat vedoucí své diplomové práce PhDr. Evě Bratkové za její pomoc, doporučení, vstřícnost a nasměrování správným směrem. Citace v textu diplomové práce jsou přizpůsobeny standardům běžně používaným v domácí i zahraniční odborné literatuře. Seznam použité literatury je zpracován podle normy ČSN ISO 690. U některých, zejména internetových, pramenů se mi nepodařilo získat všechny potřebné údaje, proto jsou uvedeny ve zkrácené podobě.
  • 10. 10 1.ÚVOD 1.1 Co je digitální knihovna Digitální knihovna je specifickým případem informačního systému, jehož hlavním úkolem je podpora velkého a rozšiřitelného množství digitálních informačních služeb [KAH95]. V této práci definuji a popíši základní entity a principy, které v takových systémech můžeme najít. Zaměřím se na otázku, jaké informace jsou v podobě digitálních objektů ukládány, vyhledávány a zpracovávány a jaké konvence, pravidla a normy lze použít pro identifikaci a lokaci digitálních objektů. Dále věnuji pozornost architektuře digitálních knihoven a jejich implementaci v prostředí Internetu. Termín digitální objekt zde používám v technickém slova smyslu a později bude podrobně popsán. Na tomto místě jen uvedu, že soubory, databáze, elektronické texty nemůžeme označovat jako digitální objekt, alespoň do té doby, než jsou uloženy ve správné struktuře. Je-li digitální knihovna informační systém, pak můžeme najít jednotlivé aktéry informačního systému a jejich funkce. Prvním aktérem je katalogizátor, který zajišťuje katalogizaci digitálních objektů a jejich přidávání do systému. Je-li systém katalogizace a uložení digitálního objektu do repozitáře automatizován, pak katalogizátorem může být autor primárního dokumentu, automatický systém a nebo kombinace autora a poloautomatického katalogizačního systému. Druhým aktérem je rešeršér, který vyhledává požadované informace uložené v digitálních objektech a relevantní digitální objekty ukládá z repozitáře na svůj počítač. Rešeršérem myslím kohokoliv, kdo vyhledává v digitální knihovně. Nebudu rozlišovat informační specialisty a běžné uživatele, neboť si myslím, že z hlediska systému mezi nimi není rozdíl. Rozdíl je pouze v jejich znalostech a zkušenostech. Jeden z pohledů na funkcionalitu systému je znázorněna pomocí use case diagramu2 podle normy UML3 : 2 Use Case diagram v UML je jeden z úhlů pohledu na softwarový systém, kde se vyskytují aktéři (lidé nebo stroje) provádějící určíté akce (use cases = případy užití). Jeden use case může obsahovat ještě další upřesňující případy užití
  • 11. 11 Obr.1 Případ užití digitální knihovny Obr.1. nám schematicky znázorňuje, že katalogizátor v systému digitální knihovny vykonává tři základní operace: 1. katalogizaci digitálního objektu 2. uložení digitálního objektu do repozitáře 3. revizi a změnu digitálního objektu a rešeršér používá dvě základní operace: 1. vyhledávání digitálního objektu 2. uložení digitálního objektu z repozitáře k lokálnímu použití Digitální knihovna je systém softwarových, hardwarových a komunikačních komponent, které zajišťují funkce digitální knihovny jako informačního systému. Ideálním komunikačním prostředím pro systémy digitálních knihoven je síť Internet umožňující přístup k digitální knihovně opravdu každému potencionálnímu zájemci. Přístup k Internetu je dnes již běžnou a relativně levnou záležitostí. Kdybychom 3 UML – Uniform Modeling Language – jazyk pro modelování informačních a softwarových systémů
  • 12. 12 používali nějaké jiné telekomunikační prostředí, pak pro zájemce musíme zajistit patřičnou konektivitu, která určitě bude finančně i technicky mnohem náročnější než spojení internetové. Navíc internetové technologie zažívají takový rozmach, že je možné si vybrat z mnoha platforem, operačních systémů, databázových systémů a vývojových nástrojů pro implementaci digitální knihovny. Zjednodušené schéma komponent digitální knihovny a jejich datových toků: Obr.2 Znázornění základních softwarových komponent internetové digitální knihovny a datové toky Názory na to, co to je digitální knihovna, jsou velmi různé. Například Dr. Peter Noerr4 ve své práci [NOE00] na otázku, co je digitální knihovna, uvádí že v podstatě existují dva typy digitálních knihoven
  • 13. 13 • knihovny obsahující materiály v digitalizované podobě • knihovny obsahující digitální materiály Podle mého názoru, je rozdíl mezi nimi velmi malý a z hlediska tématu v podstatě bezvýznamný. Důležité je, že digitální knihovna má materiály uloženy v počítačovém systému ve formě, ve které je velmi jednoduché s nimi manipulovat a dodávat je způsobem, který u klasických materiálů prostě není možný. I když má klasická knihovna velmi automatizovaný systém, není digitální knihovnou v našem pojetí, jestliže obsahuje pouze klasické materiály (jako jsou tištěné knihy). Automatizace nedělá z knihovny digitální knihovnu v našem slova smyslu, ale je pravdou, že digitální knihovna musí být automatizována v co nejvíce jejích procesech [POK01]. Mustafa Jarrar z katedry počítačových věd Bruselské univerzity v e-mailové konferenci o digitálních knihovnách (DIGLIB@INFOSERV.NLC-BNC.CA) napsal: "Termín digitální knihovna má více možných významů. Budeme-li se držet klasické definice, že digitální knihovna je digitalizovaná kolekce materiálů, tak si pod tím někdo představí tradiční knihovnu s digitalizovanými materiály a službami, které tyto informace zpřístupňují, někdo jiný se může dívat na telefonní seznam v mobilním telefonu jako na digitální knihovnu a někdo další může považovat za digitální knihovnu internetový vyhledávač. Z toho tedy vyplývá, že jakákoliv kolekce digitálních informačních objektů a služby nad ní je digitální knihovnou." Jak je vidět, tak ani mezi odborníky zabývajícími se digitálními knihovnami není jednotný názor. Já se myslím, že ne všechny kolekce digitálních materiálů a služby nad nimi můžeme považovat za digitální knihovny. Je potřeba, aby kolekce splňovala alespoň základní koncepty popsané v dalších kapitolách této práce. Myslím, že si budeme muset ještě nějaký čas počkat, než se například z dnešních velmi populárních internetových vyhledávačů stanou digitální knihovny internetového obsahu, i když je potřeba říci, že některé se k tomu svými vlastnostmi již blíží. Pokusím-li se definovat, co je digitální knihovna, pak bude má definice vypadat takto: 4 Dr. Peter Noerr - britský informační specialista, zakladatel známého knihovnického systému Tinlib
  • 14. 14 Def.: Digitální knihovnou rozumíme kolekci digitálních objektů, nad nimiž existují služby digitálních knihoven. Digitální objekt je informační entita obsahující metadata o obsahu, vlastní obsah, transakční log a signaturu. Podobnou definici digitální knihovny uvedl Jaroslav Pokorný [POK01] na 8. ročníku konference AKP 2001 (Automatizace knihovnických procesů). Def.[POK01]: Digitální knihovna je řízená kolekce informací spolu s jistými službami, přičemž tyto informace jsou uloženy v digitální formě a jsou přístupné po síti. 1.2. Proč budovat digitální knihovny V dnešní době elektronických textů, obrazů a zvukových děl, které se distribuují po datových telekomunikačních sítích typu Internet, je budování digitálních knihoven logickým krokem po knihovnách klasických. V klasických knihovnách dokonce existují metody na katalogizaci elektronických publikací na datových nosičích. Identifikace elektronických dokumentů, uložených kdesi v datové síti, často měnících obsah i lokaci, ale vyžaduje jiný přístup. S digitálními objekty lze mnohem kvalitněji a operativněji pracovat a manipulovat než s dokumenty klasickými a k tomu jsou zapotřebí speciální metody, normy a technologie, které by digitální knihovny měly obsahovat. Zde uvádím několik důvodů, které vysvětlují důležitost a přínosy digitálních knihoven. I. EFEKTIVITA PRÁCE Digitální knihovna by měla mimo jiné fungovat jako velmi kvalitní katalog digitálních objektů, v němž rešeršér má možnost velmi komfortně provést rešerši a získat metainformace o relevantních datových objektech. Primární dokumenty relevantních objektů, o které má zájem, má možnost okamžitě získat, a to v datovém formátu5 , který si zvolí. Práce s takovým typem knihovny je mnohem efektivnější a časově méně náročná. Využití digitální formy materiálů v digitálních knihovnách dává nové možnosti, které nejsou s klasickými materiály možné. 5 Datovým formátem rozumíme např. formáty PDF, PostSkript, MS Word dokument, HTML dokument, XML dokument a pod.
  • 15. 15 II. KVALITA VYHLEDÁVÁNÍ Bez digitálních knihoven se rešeršér při vyhledávání na Internetu musí spolehnout na standardní vyhledávací stroje, které nejsou nijak zaměřeny na digitální objekty. Nepoužívají k identifikaci univerzální identifikační systémy, ale pouze URL dokumentů. Neukládají kvalitní metadata. Obsahují informace všeho druhu a i dokumenty bez jakékoliv informační hodnoty. Metadata by měla zvýšit kvalitu vyhledávání a zlepšit poměr relevantních a partinentních dokumentů. III. TVORBA KOLEKCÍ DIGITÁLNÍCH OBJEKTŮ Tak jako klasické knihovny fungují jako uspořádané sbírky klasických dokumentů, tak je potřeba vytvářet i kolekce uspořádaných digitálních objektů. To je jedna z hlavních úloh digitálních knihoven. I elektronické zdroje je potřeba uchovávat pro další generace a nesmíme riskovat, že o některé kvalitní informace přijdeme. Trvalá dostupnost (PRESERVATION) je jeden z důležitých úkolů mezinárodní knihovnické federace IFLA a digitální knihovny jsou v digitálním světě ekvivalentem klasických knihoven, které tento problém řeší. 1.3. Termíny a definice Terminologie je velkou bariérou při popisování digitálních knihoven. Některá slova mají různý význam v různých oborech, a proto je potřeba vymezit, jaký význam budou mít právě v kontextu digitálních knihoven. S tímto problémem se setkáváme jak v jazyce anglickém, tak českém, kde je situace ještě komplikovanější. Mnoho běžně používaných anglických termínů nemá ustálený český ekvivalent. Osobně preferuji používání anglických termínů, než vymýšlení nových a nikomu nic neříkajících českých termínů, a jelikož naprostá většina kvalitních dokumentů z oblasti výzkumu digitálních knihoven existuje právě v jazyce anglickém, bude tak i pro čtenáře jednodušší studium dalších zahraničních materiálů. Jedním z úkolů této práce je vysvětlit a popsat termíny používané v oblasti digitálních knihoven. Na tomto místě uvedu ty nejdůležitější: • Digitální objekt • DOI (Digital Object Identifier)
  • 16. 16 • DOI žánry • Dublin Core • Handle system • Katalog • PICS (Platform for Internet Content Selection) • RAP (Repozitory Access Protokol) • RDF (Resource Description Framework) • Repozitář • Signatura digitálního objektu • Transakční log digitálního objektu • XML (eXtensible Markup Language) • Z39.50 a eZ39.50
  • 17. 17 2. ARCHITEKTURY DIGITÁLNÍCH KNIHOVEN 2.1. Principy budování digitálních knihoven Systém digitální knihovny pracuje obecně na tomto principu. Katalogizátor je uživatel, který převede primární materiály do formy digitálního objektu. Digitální objekt je datová struktura, která se skládá z primárních digitálních materiálů nesoucích obsahové informace, metadat, signatury a unikátního univerzálního identifikátoru. K získání unikátních univerzálních identifikátorů se používají autorizované generátory (viz handle system, DOI). Katalogizátor pak může digitální objekt uložit do jednoho nebo více repozitářů, ze kterých jsou pak dostupné pro rešeršéry. Rešeršérem nazývejme jakéhokoliv uživatele, jenž vyhledává v digitální knihovně. Po uložení objektu do repozitáře je identifikátor objektu a identifikace repozitáře zaregistrována do globálního systému identifikátorů. Rešeršéři pak mohou podle identifikátoru digitálního objektu zjistit, v jakých repozitářích je daný objekt uložen. Interakce s repozitářem typu ukládání nebo přístupu k objektům jsou prováděny přes protokol RAP (Repozitory Access Protocol), který by každý repozitář měl podporovat. Digitální objekt, jehož identifikátor je uložen v globálním systému identifikátorů, nazýváme registrovaným digitálním objektem. Chceme-li udržovat obsah digitální knihovny perzistentní a nezávislý na počítači, zařízení, prohlížeči nebo formátu dat, pak bychom se měli při budování a správě systému držet níže uvedených principů [CRA01]: 1. Očekávat a předvídat změny Držet systém co nejvíce obecný a flexibilní vůči dalším požadavkům, které se zaručeně objeví v budoucnosti. Měli bychom být připraveni na změnu technologií, konverzi primárních dokumentů do nových digitálních formátů či přidávání dalších metadat. 2. Znát uchovávaný obsah Je potřeba si uvědomit, že pro uživatele je nejzajímavější a nejhodnotnější obsah digitální knihovny. Tvůrci digitálních knihoven musejí rozhodovat o jejím obsahu včetně výběru objektů, které je potřeba vložit, převést z klasické formy do formy digitální a opatřit kvalitními metadaty.
  • 18. 18 3. Zapojit správné lidi V ideálním případě je dobré mít k dispozici specialisty jak z počítačového oboru, tak i z informačních věd a knihovnictví. Příkladem důležitosti spolupráce počítačových specialistů a knihovníků je americká norma Dublin Core metadata standard [DC_Z3985]. Počítačoví specialisté se na problém dívají z hlediska sémantické interoperability metadat ve velké informační síti - Internetu. Informační vědci a knihovníci mají velké zkušenosti s katalogizací a indexací, vědí, jak jsou důležité pro vyhledávání informací (information retrieval). Dále je dobré zapojit odborníky z oborů, pro které je digitální knihovna určena. Ti by měli ve spolupráci s knihovníky budovat (indexovat a katalogizovat) obsah digitální knihovny. 4. Navrhnout použitelný systém Uživatelská rozhraní většiny digitálních knihoven jsou budována pomocí internetových technologií. Na tomto místě je potřeba podotknout, že digitální knihovna nemusí používat pouze webové technologie, ale je pravdou, že dnes je to nejjednodušší možnost, jak poskytnout přístup k datům co nejvíce uživatelům. Uživatelské rozhraní by tedy mělo být navrženo tak, aby ho bylo možno jednoduše a bez velkých finančních a časových nároků předělat na jinou technologii. Dnešní webové technologie jsou však velmi dobře použitelné a není důvodu, proč na nich digitální knihovny nezaložit. Vždy je potřeba se držet základního pravidla, že pro uživatele je důležitý obsah, a proto navrhujme uživatelské rozhraní a navigační systém co nejjednodušší. Musíme si uvědomit, že uživatel má možnost si ve svém internetovém prohlížeči nastavit mnoho parametrů, jako jsou například velikost písma, velikost zobrazované plochy, vypnutí obrázků apod. Navíc uživatel může používat různé operační systémy, jako jsou MS-Windows, Apple Macintosh, UNIX, PALM OS apod. Pak tedy naše uživatelské rozhraní vypadá trochu jinak pro každého uživatele. Důležité je používat opravdu jednoduché rozhraní, které se všude zobrazí dobře. Vhodné je mít připraveno více uživatelských rozhraní a poskytnout uživateli možnost výběru. 5. Zajistit přístup Na tento bod se můžeme dívat ze dvou úhlů pohledu. Prvním úhlem pohledu je potřeba udržovat přístupová práva k jednotlivým objektům v digitální knihovně. Ne všichni musí mít stejná práva ke všem objektům. Někdo může daný objekt pouze číst, jiný ho může i změnit a někdo ho nemusí vidět vůbec. Druhým úhlem
  • 19. 19 pohledu je zajistit uživatelům čitelnost dokumentů. Jestliže uživatel získá dokument z digitální knihovny ve formátu, který si neumí zobrazit, pak je to stejné, jako by dokument nezískal. Systém by tedy měl umožnit uživateli výběr požadovaného formátu (pokud možno otevřeného6 ) a poskytnout konverzi. Druhou možností je nabídnout uživatelům software, který je schopen dokumenty zobrazit. 6. Automatizovat, kde je to možné Pracujeme s elektronickými daty, a proto bychom měli využívat co nejvíce automatizovaných procesů ve všech činnostech digitální knihovny. Jedná se o nástroje, které zrychlují a zefektivňují práci při pořizování objektů do digitální knihovny. Systém by měl nabízet katalogizátorům výběrová menu, nacházet klíčová slova podle četnosti výskytu v primárním dokumentu a další utility k usnadnění ruční práce indexátorům a katalogizátorům. Zatím není možné hovořit o plně automatické katalogizaci a indexaci, protože tyto činnosti vyžadují buď primární dokumenty ve strukturované formě (např. XML s patřičným DTD) a nebo lidskou inteligenci. Nicméně počítače nám jsou schopny mnoho práce ušetřit, nabídnout několik možností a člověk si pouze vybere tu správnou, případně ji upřesní. Vyhledávání a zobrazování informací uživatelům musí být naopak plně automatizováno, protože to už vychází ze strukturovaných dat uložených v digitální knihovně. 7. Držet se standardů Použití standardů při budování systému má mnoho výhod. Aplikace jsou více škálovatelné, robustnější, interooperabilní a přenositelné [STR94]. To samozřejmě platí i pro budování, implementaci a správu digitálních knihoven. 8. Zajištění kvality Výběr kvalitních dokumentů, kompletní a korektní metadata, to jsou základní pravidla pro udržení kvality digitální knihovny. Digitalizujeme-li klasické materiály, je potřeba sledovat i kvalitu pořízených dat. 9. Klást důraz na trvalé uchování (perzistenci) 6 Otevřeným formátem rozumíme formát, jenž je veřejně zdokumentovaný a existují nástroje pro jeho zobrazení. Tyto nástroje musí být možno získat bezplatně.
  • 20. 20 Je potřeba si uvědomit, že i dokumenty v digitální podobě je potřeba uchovávat pro budoucnost. Máme-li nějaký dokument v určitém formátu, který se dnes již nepoužívá, pak jej nemůžeme ani zobrazit, a tím se nám obsah tohoto dokumentu ztrácí. Dalším problémem je například poruchovost magnetických záznamů, nebo i CD nosičů. Je potřeba se tímto jevem zabývat, abychom nepřišli o cenná data. Speciálně vytvořená skupina 21 expertů zjistila, že v dnešní době není garantováno trvalé uchování digitálních informací [ROT99]. Toto zjištění je opravdu paradoxní, když si uvědomíme, kolik dokumentů a informací se nám zachovalo až do dnešního dne na relativně "primitivních" nosičích informací, jako jsou papír či kámen. 2.2. Digitální objekt Na tomto místě podrobně vysvětlím pojem digitální objekt. V některých starších českých zdrojích se občas můžeme setkat i s ekvivalentním termínem informační jednotka, avšak většina odborníků se již dohodla na termínu digitální objekt. V architektuře Kahn/Wilensky jsou jednotky či entity v digitální knihovně nazývány "digitálním objektem". Kahn a Wilensky [KAH95] zdůrazňují, že termín digitální objekt musí být používán ve smyslu datové struktury, a ne v obecném smyslu jakéhokoliv dokumentu v digitální formě. Podle nich by možná byl lepší termín digitální strukturální objekt (objekt digitální infrastruktury), ovšem jeho používání nepovažují z praktického hlediska za optimální. Kahn se na digitální objekty dívá jako na architekturu, kterou lze použít v různých síťových informačních systémech. Digitální objekt musí obsahovat jak samotná data, tak i metadata [KAH95]. Informace uložené v digitálním objektu, tedy primární dokumenty, nazýváme obsah (content). Jména a identifikátory digitálních objektů (handle) jsou jedním z nejdůležitějších částí architektury digitální knihovny, ale tím se budu podrobně zabývat v kapitole 2.5. (Univerzální identifikační systém).
  • 21. 21 Jak již víme, informace jsou v digitální knihovně uloženy jako digitální objekty. Nejjednodušším zobecněním digitálního objektu je, že digitální objekt je sadou bitů7 . Toto zobecnění je jistě pravdivé, ale velmi zjednodušené. Obsahy většiny digitálních objektů mají určitou strukturu a obsahují další informace (intelektuální vlastnictví, identifikace autora či vydavatele apod.), které musí být propojeny s digitálním objektem. Obrázek č.3 ukazuje strukturu digitálního objektu v Kahn/Wilensky architektuře. Obr.3 Architektura digitálního objektu - zdroj [KAH95] K tomu, aby bylo možné prezentovat obsah (content) digitálního objektu, je potřeba znát typ obsahu. Digitální objekt může obsahovat více typů obsahů. Jedna část obsahu může být například textová a druhá audio záznam. Ukazuje se, že jakkoliv komplexní data mohou být poskládána z několika základních typů obsahů, identifikátorů (handlů), signatur a dalších digitálních objektů. Objekt vždy obsahuje unikátní identifikátor (handle). K podrobnějšímu popisu objektu se používají metadata (properties), která jsou na obrázku č.3 znázorněna jako "properties". Signatura je volitelná část objektu, ale může být užitečná například pro ověření platnosti objektu nebo získání informace, že nikdo kromě autora objekt nezměnil. Používají se k tomu pokročilé techniky kryptování, kontrolních součtů (check sums) či 7 Bit - ve smyslu jednotka informace, která nabývá pouze dvou hodnot, a to 0 nebo 1
  • 22. 22 technologie privátních a veřejných klíčů (public/private keys). V dnešní době je možné použít technologii hodně diskutovaného digitálního podpisu. Možnostem signatur se budu více věnovat v samostatné kapitole č.3. Transakční log8 se často používá k uchování informací o všech prováděných transakcích s daným objektem. Ty mohou být užitečné například pro statistiky četnosti zobrazení metadat, četnosti stažení obsahu objektu rešeršéry. Další transakční údaje je možné použít pro profilování (nabídnutí daného objektu určitým uživatelům), či rozhodování o managementu a optimalizaci repozitáře (např. ke kterým objektům se nejčastěji přistupuje). Mezi data, jež má smysl ukládat do transakčních logů, patří datum, čas a typ provedené operace s objektem v repozitáři a identita uživatele provádějícího tuto operaci. Jeden digitální objekt má více forem. Je potřeba odlišovat mezi formami digitálních objektů. Jinou formu má objekt vytvořený autorem, v jiné formě může být uložen v repozitáři, a v další je posílán rešeršérům. Rešeršér, požadující primární dokument určitého digitálního objektu z repozitáře digitální knihovny, si může zvolit mnoho parametrů, pomocí nichž se bude daný obsah přenášet přes síť do jeho systému9 . Jako příklad mohu uvést situaci, kdy rešeršér nalezl dokument v digitální knihovně, který si chce uložit do lokálního počítače. V repozitáři je tento dokument uložen jako digitální objekt, jenž má obsah uložen ve specifickém formátu postscript a samozřejmě obsahuje další metadata. Tvůrce dokumentu jej poslal do repozitáře jako dokument v MS Word a rešeršér jej požaduje ve formátu PDF. Celá transakce může být velmi složitým softwarovým procesem, nicméně velmi důležitým k tomu, aby byl systém použitelný. Na tomto příkladě vidíme, že forma digitálního objektu se mění, přičemž obsah zůstává zachován. Digitální objekty jsou základním stavebním kamenem digitální knihovny, avšak uživatelé nechtějí pracovat s digitálními objekty, ale s objekty na nejvyšší úrovni abstrakce. Digitální objekt je svým způsobem abstraktní třída všech typů dokumentů, která musí zůstat uživatelům utajena. Uživatelé pracují s textovými dokumenty, počítačovými programy, obrázky, hudebními záznamy, které jsou většinou 8 Log – žurnálový soubor, ve kterém se uchovávají všechny provedené akce 9 Úmyslně mluvíme o systému, neboť rešeršér nemusí pracovat jen s personálním počítačem, ale například s kapesním počítačem typu PDA, mobilním telefonem, či jiným zařízením, jež je schopno zobrazit požadovaná data.
  • 23. 23 reprezentovány formou více digitálních objektů seskupených dohromady. Jak by měly být digitální objekty seskupeny, nemůže být specifikováno nějakými pevně danými pravidly. Je to závislé na specifikaci objektu, typu obsahu a někdy i na obsahu samotném. Příkladem smysluplného seskupení je například počítačový program a jeho dokumentace v elektronické podobě. Architektura digitální knihovny musí podporovat seskupování digitálních objektů a jejich zpřístupnění. Architektura Kahn/Wilensky podporuje nejvyšší úroveň abstrakce (uživatelskou) dvěma možnými způsoby. Prvním způsobem je, že digitální objekt může sám v sobě obsahovat další digitální objekty (Obr.4). Druhým řešením je více digitálních objektů, každý s vlastním identifikátorem (handlem), které tvoří speciální digitální objekt, jenž v metadatech obsahuje identifikátory na tyto samostatné objekty. Toto řešení funguje na principu katalogizačního záznamu. Osobně se mi více líbí právě toto druhé řešení. Je logické, aby jednotlivé digitální objekty, i když obsahově patří k sobě, měly vlastní unikátní identifikátor a byly tak přístupné i samostatně. Obr.4 Digitální objekt použitý jako katalogizační záznam Kahn zavádí dva stavy digitálního objektu. Proměnlivý a neměnný digitální objekt (mutable a immutable). Proměnlivý digitální objekt může být změněn i po uložení v repozitáři. I přesto nemohou být změněna žádná klíčová metadata, ale většina ostatních změn je povolena. Naopak neměnný digitální objekt nesmí být změněn za žádných okolností. Jediné, co je možné s neměnným digitálním objektem provést, je vymazat ho z repozitáře nebo zakázat k němu přístup. 2.3. Repozitář Repozitář je jednou z hlavních komponent infrastruktury digitální knihovny [LAG95]. Úkolem repozitáře je ukládání a přístup k digitálním objektům v elektronické síti. Jak
  • 24. 24 jsem již jednou zmínil, digitální objekt je v repozitáři uložen často v úplně jiné formě, než se prezentuje uživateli. Různé repozitáře mají velmi různé interní organizace, ale každý digitální objekt musí mít všechny náležitosti popsané v kapitole 2.2. Obr.5 Struktura repozitáře [ARM97] Výše uvedené schéma na obr.5 ukazuje obecnou třívrstvou architekturu repozitáře. RAP interface je komunikační vrstvou, pomocí které okolní svět komunikuje RAP protokolem s repozitářem. V Kahn/Wilensky architektuře repozitáře je nadefinován repozitářový přístupový protokol (RAP - Repozitory Access Protocol). Každý repozitář musí tento protokol podporovat. Protokol definuje základní operace s repozitářem. Repozitáře samozřejmě mohou navíc poskytovat i další rozšířené funkce a užitečné dotazovací jazyky, pomocí nichž je možné vyhledávat digitální objekty uložené v repozitáři. To, aby protokolu RAP repozitář rozuměl, zajišťuje vrstva Repozitory Shell (repozitářová nadstavba). Perzistentní datový sklad (Persistent Store) je prostor, kam se fyzicky ukládají digitální objekty. Implementace je okolnímu světu skryta a záleží jen na implementaci repozitáře, jak a kam bude digitální objekty ukládat. Ke komunikaci s perzistentním skladem slouží příkazy Store API. Řídící vrstva (Object Management Layer) je střední vrstva, která zajišťuje mapování služeb mezi repozitářovou nadstavbou a datovým skladem, a to prostřednictvím příkazů Shell API. Popis základních funkcí protokolu RAP: 1. Přístup k digitálnímu objektu (ACCESS_DO) Příkaz ACCESS_DO obecně vyvolává program, jenž provádí přístupové operace nad digitálním objektem uloženým v repozitáři. Program je závislý na předaných parametrech.
  • 25. 25 Výstupem mohou být metadata objektu, klíčová metadata nebo celý digitální objekt. Mohou být implementovány i další doplňkové služby typu encrypt, compress apod. Služba encrypt vrací digitální objekt v zašifrované podobě. Služba compress vrací digitální objekt ve zkomprimované podobě nějakým komprimačním algoritmem. Doplňkové služby však nejsou nijak standardizovány a není dán ani jejich výčet. 2. Uložení digitálního objektu (DEPOSIT_DO) Příkaz DEPOSIT_DO může být implementován různě. Jednou z možností je předat operaci primární dokument a metadata, z čehož systém vytvoří nový digitální objekt a uloží jej do repozitáře. Při tvorbě digitálního objektu se musí rovněž zaregistrovat univerzální identifikátor (handle) objektu. Další možností příkazu DEPOSIT_DO je replikace již existujícího digitálního objektu. DEPOSIT_DO slouží i k modifikaci existujícího proměnlivého (mutable) digitálního objektu. 3. Přístup k dalším službám (ACCESS_REF) Tento příkaz umožňuje jednoznačně identifikovat další repozitáře a jejich protokoly, které poskytují další služby nad digitálními objekty. Jsou definovány dvě možné odpovědi: a) žádné další servery b) seznam dvojic (server, protokol) Základním cílem protokolu RAP je jednoduchý model práce s repozitářem. Všechny ostatní služby, akce a transakce mohou být prováděny přes jiné standardizované protokoly (např. Z39.50, SQL3, ZQL, Dienst) pomocí příkazu ACCESS_REF. Bylo by velmi praktické, kdyby všechny repozitáře podporovaly protokol RAP, protože pak by byla velmi jednoduchá komunikace mezi jednotlivými repozitáři. William Arms rozšířil ve svých implementacích RAP protokol o další funkce [ARM97]: Funkce Popis VerifyHandle Kontroluje, jestli byl handle zaregistrován v handle systemu AccessRepoMeta Načte metadata repozitáře
  • 26. 26 Funkce Popis Verify_DO Kontroluje, jestli repozitář obsahuje digitální objekt s uvedeným handlem AccessMeta Načte metadata specifikovaného digitálního objektu Access_DO Načte digitální objekt z repozitáře Deposit_DO Ukládá digitální objekt do repozitáře Delete_DO Smaže digitální objekt z repozitáře MutateMeta Změní metadata digitálního objektu Mutate_DO Změní digitální objekt V infrastruktuře digitální knihovny musí existovat alespoň jeden repozitář. Repozitářů však může být více a z hlediska výkonnosti velkých systémů se rozdělení repozitářů jeví jako nutnost. Systém repozitáře s milióny digitálních objektů a tisíci přístupy za vteřinu nelze provozovat na jediném serveru. Rozdělení repozitáře se dá řešit více způsoby. Jedním z nich je distribuovaný model pomocí technologií CORBA, COM apod. Další možností je například klastrování10 serverů, jež zajišťují funkci repozitářů. Carl Lagoze v práci [LAG95] popisuje implementaci repozitáře nad Kahn/Wilensky architekturou. Systém, který nazval ISOS (Inter-operable Secure Object Stores), definuje rozhraní do zabezpečených repozitářů, které komunikují s ostatními repozitáři, klienty a dalšími službami. Rozhraní je nadefinováno jako distribuovaný objektový systém v prostředí CORBA11 . Carl Lagoze používá ve svém systému více instancí repozitáře, který definuje jako sadu digitálních objektů. Každý repozitář je jednoznačně identifikován pomocí repozitářového handlu. Pošleme-li požadavek na získání digitálního objektu s daným handlem, systém nám vrátí handly repozitářů, ve kterých se daný digitální objekt nachází. Pak je velmi jednoduché si vybrat nejbližší, nejrychlejší, nebo jinak pro nás nejvýhodnější repozitář a objekt si vyžádat. 2.4. Katalog V Kahn/Wilensky architektuře se s pojmem katalog nesetkáme, neboť základní ideou je uchovávat katalogizační údaje zapouzdřené zároveň s primárním dokumentem v digitálním objektu a digitální objekty v repozitáři. Samozřejmě, že existují metody, jak využít metadat digitálních objektů v repozitáři jako katalogu, ale robustnějším 10 Klastrování (clustering) - seskupení více počítačů. Klastr navenek funguje jako jeden mnohem výkonnější počítač. 11 CORBA - standard pro vývoj distribuovaných aplikací, navržený organizací OMG (Object Managment Group)
  • 27. 27 řešením je vytvoření katalogu jako další komponenty architektury digitální knihovny. Z hlediska praktické implementace a rychlosti odezvy po zadání rešeršního dotazu do systému se podle mého názoru rozhodně vyplatí vytvořit katalog metadat digitálních objektů. Další výhodou je možnost šíření pouze katalogizačních záznamů jako zdroje sekundárních informací, a možnost umístit v digitální knihovně pouze katalogizační záznam digitálního objektu, aniž by existoval v repozitáři dané digitální knihovny. V neposlední řadě lze vybudovat katalog nad více repozitáři. Máme možnost držet se Kahn/Wilensky architektury a ponechat metadata jako součást digitálních objektů. Druhou možností je vytvoření pouze katalogu metadat s univerzálním identifikátorem12 digitálního materiálu13 , který bude uložen na lokacích daných identifikátorem (např. pomocí URL http://www.cuni.cz/dl/diglib.html, ftp://ftp.cuni.cz/dl/diglib.pdf nebo DOI či handle systemu) . Repozitářem se může stát i celý Internet nebo náš Inter/intranetový server a nemusíme vytvářet žádný speciální repozitář. Naimplementujeme-li vlastní repozitář, pak není problém, aby jedním z identifikátorů u katalogového záznamu byl identifikátor do repozitáře. Např. rap://repozitory.cuni.cz/?hdl:cnri.dlib/february97-arms. Výběr architektury repozitáře a metadat ovlivňuje typ aplikace a formát primárních dokumentů. Katalog je souborem katalogizačních záznamů. Záznam vytvoříme jako podmnožinu metadat uložených v digitálním objektu, která by měla být nějakým způsobem standardizována. Noerr v materiálu [NOE00] nabízí jako vhodná schémata pro katalogizační záznam tyto knihovnické standardy: MARC14 , Dublin Core15 , BIB-116 , EAD17 . Volba vhodného standardu je klíčová pro implementaci katalogu, nicméně záznamy implementované podle určitého standardu jde většinou jednoduše konvertovat do standardu jiného. 12 Například DOI - Digital Object Identifier 13 Zde není možno hovořit o digitálním objektu, ale pouze o digitálním primárním dokumentu, neboť digitální materiál nesplňuje definici digitálního objektu 14 MARC - http://lcweb.loc.gov/marc 15 Dublin Core - http://www.dublincore.org 16 BIB1 - http://lcweb.loc.gov/z3950/agency 17 EAD - http://lcweb.loc.gov/ead
  • 28. 28 Záznamy musí být uloženy tak, aby se v nich dalo velmi rychle vyhledávat. Ideálním řešením by bylo použít nějakou objektově orientovanou databázi, nejlépe založenou na XML. Jelikož však technologie objektových databází i přes velká očekávání v 90. letech 20. století nedoznala velkého rozmachu a technologie XML je relativně mladá, neexistují ještě použitelné a aplikovatelné nástroje. Nejlepším řešením je použít nějaký kvalitní RDBM18 systém, ve kterém implementujeme nám nejlépe vyhovující standard pro katalogizační záznam - metadata. RDBM systémy jsou optimalizovány pro práci s velkým množstvím dat. Je jen otázkou, který z databázových systému použít. Pro jednodušší implementaci katalogu bych doporučoval Open source19 databáze, které jsou většinou zdarma a bývají velmi kvalitní. Jako příklad uveďme MiniSQL nebo dnes na Internetu hodně používaný databázový server MySQL. Pro profesionálnější řešení můžeme použít kvalitních komerčních produktů typu Oracle, Sybase, DB2 či Informix20 . Katalog je určen pro uživatele, a proto je potřeba vytvořit uživatelské rozhraní pro procházení a prohledávání katalogu. Jelikož implementujeme digitální knihovnu v prostředí Internetu, pak je vhodné vytvořit internetovou aplikaci komunikující s uživatelem prostřednictvím webového rozhraní. Pro aplikační vrstvu digitální knihovny je možno zvolit jeden z mnoha programovacích jazyků podporujících tvorbu webových aplikací. Mezi nejkvalitnější patří PHP, PERL, JAVA a další. K velmi podobným závěrům dospěli i tvůrci prototypu digitální knihovny z virginské univerzity [STA00]. Ti zvolili jako RDBMS databázový server MySQL a pro aplikační vrstvu použili Java servlety. 18 RDBM systém - Relation Database Management System - relační databázový server 19 Open source - software včetně zdrojových kódů, který je volně šiřitelný pod různými licencemi (např. GNU) 20 Informix byl v květnu 2001 koupen IBM a začleněn do RDBMS IBM DB2
  • 29. 29 2.5. Univerzální identifikační systémy Na tomto místě je potřeba zdůraznit, že vzhledem k architektuře digitální knihovny, nemají architektury identifikačních systémů přímou souvislost, neboť k identifikaci digitálních objektů nám postačí brát univerzální identifikační systém jako "black box", kde k identifikaci používáme identifikátor daného systému a umístění objektu jsme také schopni z identifikačního systému získat. To nám pro potřeby digitální knihovny bohatě postačí. Avšak k lepšímu pochopení souvislostí je vhodné se zaměřit na podstatu identifikačních systémů. 2.5.1 URI, URN a URL URI, URN a URL se používají hlavně na internetu. Internet je informační prostor, který obsahuje milióny dokumentů. K tomu, abychom se mohli orientovat v tak obrovském informačním prostoru, potřebujeme univerzální identifikátory, které nám slouží jako orientační body v tomto kyberprostoru [W3CNA93]. URI (Uniform Resource Identifier) jsou krátké znakové řetězce identifikující abstraktní nebo fyzické zdroje jako jsou dokumenty, soubory ke stažení, služby, elektronické poštovní schránky, apod. URI zpřístupňuje zdroje a zároveň definuje jednoduché přístupové metody (HTTP, FTP, GOPHER, MAILTO, apod.) k těmto zdrojům, což umožňuje získání zdrojů pomocí jednoho prostého kliknutí myši (čí jiného podobného výběru). Obr.6 URL a URN jsou podmnožinou URI URI může fungovat jako lokátor zdroje, jméno zdroje a nebo obojí. URL (Uniform Resource Locator) je podmnožinou URI, což je schématicky zobrazeno na obrázku č.6. URL identifikuje zdroje podle jejich umístění v elektronické síti a přístupového
  • 30. 30 protokolu. Příkladem URL je tedy ftp://ftp.freebsd.cz/pub/FreeBSD/release-4.6.i386.iso, což identifikuje soubor ke stažení přes protokol FTP a to ze serveru zabývajícího se operačním systémem FreeBSD v České republice. URN (Uniform Resource Name) je také podmnožinou URI. URN je však na rozdíl od URL globálně jednoznačný a trvale dostupný identifikátor, a to i v případě, že zdroj přestane existovat a nebo se stane nedostupným. Klasickými příklady URN jsou tedy DOI a Handle system. Oba tyto systémy jsou popsány v dalších kapitolách. Příklady URN [ARM97]: urn:hdl:cnri.dlib/august95 urn:lifn:some.domain:anything-goes-here urn:path:/A/B/C/doc.html 2.5.2 DOI - identifikátor digitálního objektu Nejdříve vysvětlím zkratku DOI (Digital Object Identifier). Znamená trvalý identifikátor digitálního objektu v elektronické síti. Zde jsou všechny digitální objekty jednoduchou posloupností bitů. DOI může být použit na jakoukoliv formu digitálního objektu v libovolném prostředí. Obecněji řečeno, DOI je univerzální identifikační systém, který můžeme přirovnat například k ISBN či ISSN. DOI může být použit k identifikaci různých fyzických objektů (např. tištěné knihy, články v časopisech, CD nosiče, video záznamy apod.), ale i k identifikaci digitálních souborů v síťovém prostředí, což je důležité pro digitální knihovny. DOI poskytuje schéma pro jednoznačnou a perzistentní identifikaci digitálních objektů v síťovém prostředí. Trvalá (perzistentní) dostupnost DOI je zajišťována centrálním systémem. Jedním z problémů dnešního Internetu je fakt, že kdykoliv se nějaký objekt přesune někam jinam, pak uživatel hledající daný objekt nalezne pouze starou lokaci daného objektu, a jelikož tam již objekt není, obdrží pouze informaci, že daný objekt neexistuje. V lepším případě na daném místě v Internetu nalezne odkaz na hledaný objektu. To je zapříčiněno tím, že identifikace pomocí URL určuje umístění objektu a ne objekt samotný. DOI naopak identifikuje určitý objekt a podružně pak jeho lokaci. Každý DOI je registrován v handle systemu a lokace objektu v Internetu tudíž může být určena. Když se objekt přesune někam jinam, pak je potřeba změnit jeho lokaci
  • 31. 31 v handle systemu a vše funguje dále. Pro koncového uživatele změna lokace nepřináší žádný problém, neboť uživatel se na digitální objekt odkazuje pomoci DOI a až na základě odpovědi handle systemu se dozví aktuální lokaci objektu. Nestane se nám pak, že objekt nemůžeme nalézt, a nebo, že musíme procházet všechny lokace, na kterých byl daný objekt umístěn. DOI pracuje jako akční identifikátor. Nejjednodušší operací, jež lze s DOI provést, je lokace objektu, který DOI identifikuje. Díky tomu se může používat jako URL. Vlastnosti DOI jsou však mnohem komplexnější a lze s ním provádět mnohem více operací. DOI je interoperačním identifikátorem. DOI systém byl vyvíjen, aby spolupracoval s minulými, současnými i budoucími technologiemi. DOI umožňuje pracovat jak s dřívějším standardem ISBN, tak se současným standardem URL. DOI systém je a vždy bude otevřený standard a bude vždy kompatibilní s budoucími Internetovými standardy, které se vyvíjejí a budou vyvíjet. DOI systém je konstruován jako integrovaný systém složený z více spolupracujících komponent (obr.7). Norman Paskin [PAS01] rozdělil DOI systém do tří komponent. Jsou to enumerace, popis, rozpoznání. Nad těmito komponentami jsou definována pravidla.
  • 32. 32 Obr.7 Tři komponenty DOI systému (enumeration, description, resolution) a pravidla (policies) 1. Enumerace (Enumeration): Přiřazení identifikačního čísla (DOI), které digitální objekt identifikuje. Je mnohem lepší mluvit o alfanumerickém řetězci než o čísle, neboť identifikátor objektu může obsahovat jak číslice tak i písmena. Pro jednoduchost se však používá termín číslo digitálního objektu. DOI je vytvořen tak, aby bylo možno co nejjednodušším způsobem jednoznačně identifikovat objekt v jakémkoliv formátu (fyzickém i digitálním). Existující identifikátory, jako třeba ISBN, mohou být použity jako část DOI. Struktura DOI bude podrobně popsána později. V praxi se DOI používá jako identifikační číslo bez nároku na popis obsahu. Obecně z DOI nelze odvodit obsah nebo nějaké popisné atributy materiálu, avšak některé implementace identifikátorů umožňují uchovat obsahovou i popisnou identifikaci přímo v sobě, a tak dávají uživateli k dispozici metadata o identifikovaném objektu. V takovém případě jsou metadata uložená v systému DOI při registraci tou nejbezpečnější cestou k získání informací o objektu. Nemáme-li identifikační číslo závislé na metadatech, docílíme toho, že identifikátor zůstává perzistentní i při změně matadat (např. změna autorských práv), a proto se DOI často nazývá trvalý (perzistentní) identifikátor. 2. Popis (Description): Vytváří popisné atributy objektu, který je DOI identifikována. Jak již bylo řečeno, identifikátor sám o sobě většinou neobsahuje žádná metadata, a proto je zavedena v systému DOI množina metadat, která musí být povinně vyplněna u každého registrovaného objektu. Je to tedy určité metadatové jádro, které je stejné pro všechny registrované digitální objekty. Tato metadata jsou dostupná pro všechny uživatele systému DOI a slouží jako základní popisná metadata objektů identifikovaných v systému DOI. Je zřejmé, že struktura metadat je různá pro různé typy identifikovaných děl. Například popis monografie je odlišný od popisu hudebního záznamu nebo fotografie. Proto jsou zavedeny žánry DOI (DOI Genres). Každý objekt zaregistrovaný do systému DOI je zařazen minimálně do jednoho žánru. Každý DOI žánr může obsahovat ještě další žánrově specifická metadata. V následující tabulce zrekapituluji soubor metadat, který tvoří metadatové jádro systému DOI:
  • 33. 33 Prvek metadat Definice Status Počet Povolené hodnoty DOI DOI Povinné pouze 1 DOI Žánr DOI žánrová klasifikace definovaná IDF21 Povinné minimálně 1 z DOI žánrové klasifikace Identifikátor unikátní identifikátor Určeno žánrem minimálně 1 alfanumerický řetězec obsahující i typ identifikátoru např. ISBN Název jméno, pod kterým je objekt znám Určeno žánrem minimálně 1 alfanumerický řetězec Typ Primární strukturální typ objektu Povinné pouze 1 Dílo Vyjádření Zhmotnění Jednotka Původ Proces, kterým bylo dílo vytvořeno povinné minimálně 1 Originál Modifikace Excerpce Kompilace Kopie Primární agent Jméno nebo identifikátor primárního agenta (většinou autor) povinné minimálně 1 Role agenta Jakou roli má primární agent povinné minimálně 1 kód role Metadatové jádro je množina povinných metadat, ke kterým je možné zadat další administrativní informace při registraci objektu, jako je např. datum registrace, identita uživatele, který provádí registraci, nebo číslo verze záznamu. 3. Rozpoznání (Resolution): Systém DOI se odlišuje od ostatních identifikačních systémů tím, že je "akční". Objekt určený identifikátorem DOI, může být na Internetu rozpoznán a poté získán, je-li na Internetu přístupný. To neznamená, že by byl každý DOI identifikátor implicitně rozpoznatelný, neboť DOI nemusí identifikovat pouze digitální objekty, ale může identifikovat i materiály klasické (monografie, časopisecké články apod.). Rozpoznáním v tomto slova smyslu, rozumíme proces uložení DOI identifikátoru do síťové služby, ze které můžeme pomocí identifikátoru získat zpět informace relevantní 21 IDF - International DOI Foundation
  • 34. 34 danému identifikátoru. Nejjednodušší je takový případ, kdy k jednomu registrovanému DOI identifikátoru uložíme jednu URL lokaci digitálního objektu (Obr.8). Takový případ nazýváme jednoduché rozpoznání (simple resolution). Obr.8 Schéma jednoduchého rozpoznání Digitální objekt však může a často i existuje na Internetu ve více kopiích. Pro DOI systém to není vůbec žádný problém a takový případ pak nazýváme vícenásobné rozpoznání (multiple resolution). K jednomu DOI pak existuje více URL nebo jiných lokačních identifikátorů (Obr.9). Obr.9 Schéma vícenásobného rozpoznání Technologie používaná pro rozpoznávání DOI se nazývá handle system, který bude podrobněji popsán v kapitole č. 2.5.2.
  • 35. 35 4. Pravidla (Policies): V každém komplexním systému je potřeba dodržovat určitá pravidla, aby nenastal chaos a systém byl konzistentní. Nejinak je tomu i v systému DOI, který spravuje IDF (International DOI Foundation). Základní pravidla IDF: • DOI se používá k identifikaci intelektuálního vlastnictví digitálních objektů. Intelektuální vlastnictví je chápáno v celé šíři, tak jak ho definují definice organizace WIPO a další mezinárodní úmluvy. • DOI je primárně určeno k řízení intelektuálního vlastnictví, ale to neznamená, že by se DOI nemohlo používat i pro volně šiřitelné objekty. • Používání systému DOI pro identifikaci je zdarma. Náklady spojené s provozováním systému jsou přímo i nepřímo hrazeny registrovanými členy systému DOI. IDF bude dotovat celý systém až do té doby, než poplatky registrovaných členů systému DOI pokryjí všechny náklady spojené s provozem. • Všechny identifikátory DOI musí být registrovány v globálním registru DOI. • Zápis identifikátoru DOI je standardizován podle americké normy ANSI/NISO Z39.84-2000 • Budou zřízeny registrační autority, aby řídili přidělování identifikátorů DOI a pořizování metadat. • Každý objekt musí mít vyplněnu minimální sadu metadat (metadatové jádro). • Reverzní vyhledávání objektů podle metadat není poskytováno systémem DOI. Takovéto vyhledávání bude nabízeno jednotlivými registračními autoritami. Struktura DOI DOI je složen ze dvou komponent, prefixu a sufixu, které jsou odděleny lomítkem (Obr.10).
  • 36. 36 Obr.10 Struktura identifikátoru DOI Prefix je poskládán z částí oddělených tečkou. První část DOI prefixu je "10", což je vlastně identifikace DOI systému v různých implementacích handle systemu. Další částí prefixu je číslo organizace, které je organizaci přiděleno při registraci. Do budoucna se počítá s dalšími částmi, jež budou reprezentovat podčásti organizace. Například Karlova univerzita jako organizace by mohla mít DOI prefix "10.2504", ale každá fakulta UK by měla přidělený rozšířený prefix. Například Filozofická fakulta UK by mohla mít rozšířený prefix "10.2504.09". Sufix slouží jako jednoznačný identifikátor objektu. Kombinací prefixu a sufixu dostáváme jednoznačný identifikátor objektu v rámci organizace. Sufix může být alfanumerický řetězec, který si uživatel volí při registraci. Může to být pořadové číslo a nebo také již existující identifikátor (ISBN, ISSN, apod.). Syntaxe obou dvou následujících DOI identifikátorů je tedy korektní. Obr.11 Syntaxe DOI identifikátorů 2.5.3 Handle system Technologie handle system, vyvíjená CNRI, byla vybrána k rozpoznávání ve výše popsaném systému DOI, neboť nabízí mnoho reálných výhod jako: • vícenásobné rozpoznání (multiple resolution) • přizpůsobivost (flexibility) • rychlost zpracovávání rozpoznávacích dotazů • úspěšné nasazení v několika projektech digitálních knihoven • úspěšná implementace a podpora v různých dalších reálných projektech • vyvíjeno jako otevřený standard
  • 37. 37 • připravenost k dalšímu vývoji Obecně se handle system využívá k tomu, aby bylo možno rozpoznat univerzální identifikátory (handly) v distribuovaném prostředí Internetu. Jednotliví klienti, jako jsou například webovské prohlížeče, používající speciální rozšíření (většinou ve formě pluginů22 nebo proxy serverů23 ), se připojují k handle systemu a prostřednictví handle system protokolu získávají metadata o digitálních objektech identifikovaných příslušným identifikátorem. Systém rozpoznávání v handle systemu je názorně vidět na dalším obrázku (Obr.12). Celý proces je velmi podobný systému DNS24 , který se v Internetu používá pro rozpoznávání adres URL. 22 Plugin - je speciální softwarová komponenta rozšiřující schopnosti původního software 23 Proxy server - zprostředkovávající server, v klient/server technologiích komunikuje klient se serverem definovaným protokolem. Potřebujeme-li mezi klienta a server vložit nějakou další funkcionalitu, která není protokolem nativně podporována, pak musíme použít právě proxy server, který to zprostředkovaně zajistí. 24 DNS - domain name systém
  • 38. 38 Obr.12 Schéma architektury handle systemu Vysvětlení ke schématu handle systemu: 1. Klient je webový browser a handle požadovaného dokumentu je například 10.123/456. Klient posílá handle do handle systemu k požadovanému rozpoznání. To je provedeno buď přímo pomocí klienta, který má implementovánu nativní podporu handle system protokolu, a nebo prostřednictvím proxy serveru, jestliže klient protokol handle system nepodporuje. 2. Handle systém je soustavou celé řady serverů poskytující handle služby (handle services). Každá služba se skládá z jednoho primárního handle serveru a libovolného počtu sekundárních handle serverů. Sekundární slouží jako záložní servery v případě nefunkčnosti primárního serveru, proto se všechny informace z primárního serveru automaticky replikují na servery sekundární. Každá handle služba musí být zaregistrována v globálním registru handle služeb (Global Handle Registry), který je zodpovědný za to, že zná lokace a jmenné prostory všech
  • 39. 39 veřejných lokálních handle služeb. Naopak i každá lokální handle služba ví, jak přistupovat ke globálnímu registru handlů. To umožňuje handle systemu lokalizovat lokální handle službu, která zná odpověď na rozpoznávací dotaz a vrátí klientovi lokační data dokumentu s požadovaným handlem. 3. & 4. Každý handle může být asociován s jedním nebo více lokačními údaji. V našem příkladě je handle 10.123/456 sdružen, a tudíž i rozpoznán jako URL adresa i jako nový protokol DLS25 . To jsou informace, které jsou vráceny klientovi. Je potřeba si uvědomit, že k jednomu DOI může existovat i více lokačních identifikátorů jednoho typu, takže například můžeme k jednomu dokumentu obdržet více URL adres. Handle systém je čistě rozpoznávací systém a je až na klientovi, co s vrácenými údaji provede. 2.6. Centralizovaný versus distribuovaný model Digitální knihovna je katalog a repozitář digitálních objektů. Ideálním stavem by bylo, kdyby existovala jedna velká digitální knihovna, kde by člověk nalezl vše, co hledá. Taková představa je však velmi utopická, a to z mnoha hledisek. Ať již z technického (komunikační infrastruktura, technické vybavení), regionálního (každý region má svá specifika), oborového (i každý obor má svá specifika) a dalších. Realita je taková, že existuje mnoho digitálních knihoven regionálních, oborových, institucionálních a dalších, které žijí svým vlastním životem. Nicméně velmi často se stává, že si mezi sebou potřebují vyměnit určité digitální objekty (nebo alespoň jejich metadata) a nebo uživatel jedné knihovny chce využít fond jiné knihovny, při zachování stejného uživatelského rozhraní. Na otázku, jaký konkrétní systém či technologie je nejlepší, je velmi těžké odpovědět, protože právě dnes se utvářejí standardy pro distribuované webové služby a je otázkou blízké budoucnosti, co se prosadí. Obecně je důležité, aby systém podporoval automatickou výměnu a sdílení informací, a aby byl založen na otevřených standardech. V dalších podkapitolách nastíním jednotlivé standardy a technologie, které měly, mají a nebo mohou mít praktický význam pro digitální knihovny. 25 DLS - digital library system
  • 40. 40 2.6.1 Z39.50 Jde o standardizovaný protokol pro vyhledávání a přejímání dat. Z39.50 specifikuje abstraktní informační systém s velkou množinou funkcí pro vyhledávání a přejímání záznamů, procházení uspořádaných seznamů, atd. Na straně serveru je tento abstraktní systém mapován na konkrétní systém správy bází dat. Komunikace mezi serverem a klientem je přesně definována protokolem. Implementační detaily serveru jsou zakryté síťovým rozhraním, takže klient může přistupovat k libovolnému typu databáze prostřednictvím stále stejného protokolu. Na straně klienta je abstraktní informační systém zpětně namapován na uživatelské rozhraní, které může být šité na míru konkrétním požadavkům uživatele. Výhodou Z39.50 tedy je, že umožňuje odlišným informačním zdrojům vystupovat pod jednotným uživatelským rozhraním a současně dává každému informačnímu systému možnost vytvořit několik rozhraní pro odlišné skupiny uživatelů [RUB99]. Komunikace, služby Z39.50 je aplikačním protokolem, který specifikuje komunikaci mezi klientem a serverem při vyhledávání informací v bázích dat. Spojení navazuje klient zasláním tzv. inicializačního (init) požadavku, kterým se představí serveru a ve kterém navrhuje hodnoty parametrů nezbytných pro vytvoření Z39.50 relace (verze protokolu, ověření identity, podporované operace, maximální délka zprávy, apod.). Server zareaguje zasláním inicializační (init) odpovědi, ve které oznamuje klientovi hodnoty parametrů a informuje ho, zda souhlasí s vytvořením Z39.50 relace. Následně klient zformuluje dotaz (seznam bází plus termy k vyhledání s hodnotami atributů, pospojované boolskými operátory) a odešle jej jako tzv. Search požadavek. Server prohledá databáze, vytvoří si množinu výsledných záznamů a odpovídá zasláním počtu prvků této množiny v Search odpovědi. V závislosti na počtu nalezených záznamů může tato odpověď obsahovat také některé či všechny nalezené databázové záznamy. Ostatní nalezené záznamy jsou pro klienta k dispozici prostřednictvím dodatečných dotazů, tzv. Present požadavků, po kterých následují Present odpovědi serveru obsahující požadované záznamy. Proces ukončení Z39.50 relace může zahájit jak klient, tak server, a to zasláním Close požadavku a obdržením Close odpovědi. Kromě výše uvedených služeb Init, Search a Present nabízí protokol Z39.50 mnoho dalších operací, jako např. vyhledávání v uspořádaném seznamu (služba Scan), setřídění či zrušení množiny výsledků (služba Sort, resp.
  • 41. 41 Delete), ověřování totožnosti klienta (služba Access-control), zasílání služebních informací (služba Resource-control), atd. Existují novější verze Z39.50 (verze 2 a 3), které mají určitá vylepšení, ale pro účel výběru komunikačního protokolu pro decentralizovaný systém digitální knihovny bude tento popis Z39.50 postačovat. Formáty Protokol rozlišuje 2 druhy záznamů, které se mohou vyskytnout v odpovědi serveru: jsou to záznamy databázové a diagnostické. Databázové záznamy musí vyhovovat některému z registrovaných formátů, přičemž Z39.50-1995 podporuje 15 formátů záznamu: Unimarc, Intermarc, CCF, USmarc, UKmarc, Normarc, Librismarc, Danmarc, Finmarc, MAB, Canmarc, SBN, Picamarc, Ausmarc a Ibermarc. Diagnostické záznamy server posílá v případě, že z nějakých důvodů není schopen obsloužit dotaz. Jsou akceptovány 2 druhy registrovaných diagnostických formátů, a to Bib-1 a Diag-1. Jako přenosová syntaxe záznamu je podporována struktura záznamu pro výměnu dat podle ISO 2709. Obr.13 Systém komunikace mezi uživatelem a knihovnickou databází [AND01] Využití Z39.50 v knihovnictví
  • 42. 42 V knihovnickém prostředí lze protokol Z39.50 využít zejména k: 1. lokálnímu přístupu k externím datovým zdrojům. Pomocí základních funkcí protokolu lze uživateli rozšířit množinu lokálních zdrojů dat o vzdálené databáze, přičemž přístup k lokálním a externím bázím probíhá přes stejné uživatelské rozhraní. Lokální přístup ke vzdáleným zdrojům je nejběžnější implementací protokolu Z39.50 v knihovnách. 2. vytváření virtuálních či distribuovaných souborných katalogů. Skupina knihoven může využít protokolu k poskytnutí přístupu k jejich bázím přes lokálního klienta. Uživatel v jedné z těchto knihoven pak využívá její lokální uživatelské rozhraní k vyhledávání v databázích všech knihoven ve skupině. 3. přejímání záznamů. Z39.50 klient prohledává vzdálenou databázi, přičemž specifikuje požadovanou syntaxi záznamů. Obdržené záznamy pak zkopíruje do lokálního systému za účelem zařazení do lokálního katalogu. Přejímání záznamů se stává velmi rozšířeným využitím Z39.50. Z39.50 z praktického hlediska Ačkoli je představa o využití protokolu Z39.50 jako sjednocujícího prvku při sdílení informací mezi různými knihovnickými systémy velmi revoluční, v praxi je třeba zůstat na zemi. Aplikace, využívající protokol Z39.50, mohou poskytovat jednotné rozhraní jen tehdy, budou-li tento protokol beze zbytku podporovat. Z39.50 je však protokolem velice rozsáhlým, takže ve skutečnosti každý systém založený na protokolu Z39.50 využívá spíše jen větší či menší podmnožinu jeho vlastností. Rozhraní těchto systémů jsou tedy sice založena na standardu protokolu Z39.50, avšak není zaručena jejich vzájemná kompatibilita. Při vytváření distribuovaných či virtuálních souborných katalogů je proto třeba, aby se zúčastněné strany dohodly na konkrétní množině podporovaných vlastností Z39.50, čili na tzv. Profilu, jehož součástí jsou např. typy atributů a jejich hodnoty, syntaxe záznamů, velikosti zpráv, apod. Pokud se v současnosti rozhodneme využívat služeb Z39.50 serverů, zjistíme, že různé servery mají nejenom odlišné vlastnosti, ale jejich chování je dokonce nezřídka v rozporu s protokolem Z39.50, takže je téměř nemožné vytvořit univerzálního Z39.50 klienta, který by dokázal komunikovat s libovolným Z39.50 serverem bez předchozí studie jeho chování.
  • 43. 43 I přes tuto skutečnost přináší protokol Z39.50 mnohá zjednodušení. Usnadňuje například přejímání autorit, protože záznam s sebou nese informaci o použitém formátu. Velký přínos Z39.50 je však zejména v tom, že výrazně zjednodušuje implementaci souborných katalogů, protože rozdíly mezi chováním jednotlivých serverů nejsou zdaleka tak veliké, jaké jsou mezi systémy, které Z39.50 nepodporují. 2.6.2. XML Pokud bych měl jednou větou vyjádřit co je XML, pak bych řekl, že "XML je sada standardů pro výměnu a publikování informací strukturovaným způsobem. Zkratka XML znamená eXtensible Markup Language. Jde o relativně nový značkovací jazyk, vyvinutý konsorciem W3C26 (World Wide Web Consortium) především jako prostředek k překonání omezujících prvků v HTML. HTML27 je velmi populární značkovací jazyk. Některé studie udávají, že celkem existuje asi 800 miliónů webových stránek, které jsou napsány v jazyce HTML. Jazyk HTML je podporován obrovským množstvím aplikací, včetně prohlížečů, editorů, emailových programů, databází, organizátorů a dalších aplikací [BEN01]. Příčina vzniku XML je zdánlivě jednoduchá a je výsledkem úsilí o vyřešení konfliktních požadavků, ke kterým W3C dospělo při stanovení budoucnosti jazyka HTML. Všem je jasné, že lidé potřebují další HTML tagy28 . Tyto nové tagy přitom budou stále specializovanější. Například matematici chtějí tagy pro vzorce. Chemici také potřebují tagy pro vzorce, ovšem pro jiné typy vzorců. Tyto, ze strany uživatelů, zcela opodstatněné požadavky dělají starosti autorům a vývojářům, protože ti chtějí naopak méně tagů. HTML je totiž už dnes natolik komplikované, že aplikace pro práci s HTML jsou velmi složité a mají velké hardwarové nároky. Je možné v rámci jednoho jazyka mít více tagů a zároveň méně tagů? Tuto zdánlivě paradoxní otázku řeší XML dvěma základními změnami oproti HTML: • XML nemá žádné předdefinované tagy • XML má mnohem přísnější syntaxi 26 W3C je organizace zabezpečující vývoj a udržování většiny webových standardů. Další informace o konsorciu W3C získáte na webové adrese www.w3c.org 27 HTML hypertext markup language – předpokládám, že čtenář ví co je HTML a k čemu se používá 28 TAG je značka značkovacího jazyka - například <p> je tag, který v HTML znamená začátek nového odstavce
  • 44. 44 To, že XML nemá žádné předdefinované tagy, dělá z XML rozšiřitelný (eXtensible) jazyk, protože si autoři mohou vytvořit tagy podle jejich konkrétních potřeb. Pozorného čtenáře však okamžitě napadne řada otázek. 1. Jak systém zjistí, že například tag <autor> označuje právě informace o autorovi? 2. Dají se porovnávat různé (například číselné) údaje? 3. Jak se tímto způsobem zjednoduší správa dokumentů? Pokusím se na tyto otázky odpovědět, a tím bych zároveň chtěl objasnit základní význam XML. Ad 1. Klasický prohlížeč dokumentů nepotřebuje vědět, že text uvnitř tagu <autor></autor> jsou personální údaje o autorovi. Většinou mu stačí vědět, jak dané informace zobrazit a čtenář už si podle zobrazení konkrétní obsah uvědomí. Co naopak po prohlížeči požadujeme je, aby příslušné údaje zobrazil jinak pro různé druhy výstupů. Jinak je potřeba zobrazit údaje o autorovi pro tištěný dokument, jinak pro webovou prezentaci a jinak pro wapovou prezentaci. Tím se dostáváme ke hlavní myšlence XML. XML označkuje textový dokument tak, aby informace byli strukturované a automatizovaný systém s nimi mohl pracovat. V XML dokumentech máme možnost uchovávat pouze holé informace bez formátovacích informací. Informace o formátování se k danému XML přiřazují pomocí XSL, nebo kaskádových stylů (XSL a styly definují konečnou podobu jak se XML dokumenty zobrazí). Některé speciální aplikace potřebují vědět, na rozdíl od klasického prohlížeče, že daný údaj je například příjmení autora. To je samozřejmě možné a k tomu slouží XML analyzátory (XML analyzátory jsou programy, které přetransformují XML dokument do stromové hierarchie a umožní přístup k jednotlivým strukturám v dokumentu). Ad 2. Různé údaje v XML se dají porovnávat pomocí XML analyzátorů. Ad 3. Pomocí XML se může správa dokumentů velmi zjednodušit. Máme-li všechny dokumenty v dokumentovém repozitáři ve formátu XML, pak nám stačí uchovávat pouze jednu kopii holého dokumentu a formátovací šablony nám zajišťují automatické formátování do formátů požadovaných uživatelem. Není tedy vůbec žádný problém okamžitě změnit grafický design všech dokumentů. XML v digitálních knihovnách
  • 45. 45 XML se v digitálních knihovnách hodí pro tři základní druhy aplikací: publikování, ukládání a výměnu dat. Všechny druhy aplikací jsou pro implementaci digitálních knihoven zajímavé a přínosné. XML lze jednak využít jako základní formát dokumentů v repozitáři, a nebo z hlediska distribuovaného modelu digitální knihovny zajímavější využití XML jako nástroje pro definici standardizovaných metadat a jejich výměny mezi jednotlivými digitálními knihovnami. Tím se nabízí možnost existence uživatelských rozhraní do digitálních knihoven, přistupujících do více katalogů a repozitářů distribuovaných po celém Internetu. Samozřejmě to předpokládá standardizaci protokolu, založeného na XML, pro přístup do digitálních knihoven. Takovýto protokol by měl podle mého názoru nahradit zastaralý a neflexibilní protokol Z39.50, o kterém jsem psal v předchozí kapitole. 2.6.3. Z39.50 versus XML Je zřejmé, že chceme-li budovat distribuované digitální knihovny, které spolu komunikují, tak k tomu potřebujeme komunikační protokol. Otázkou je zda do moderních digitálních knihoven implementovat starý, méně flexibilní, pouze knihovnicky zaměřený protokol Z39.50 a nebo protokol založený na moderních, obecných a dnes už i standardizovaných protokolech XML, SOAP29 (respektive XP). Pavel Krbec i Naděžda Andrejčíková se ve článcích [KRB01] a [AND01] přiklánějí k používání protokolu Z39.50 a jeho případné doplnění o podporu XML. Stanislav Psohlavec to ve článku [PSO01] již vidí spíše ve prospěch moderních technologií, a to jak z pohledu technologického, tak i ekonomického. Já si myslím, že pro protokol Z39.50 nalezneme využití pouze v knihovnách, ale obecnější "průmyslové" protokoly založené na XML a SOAP se dají využít i v jiných oborech, což sebou přináší i obecné nástroje a technologie, které zlevňují a zefektivňují vývoj a správu knihovnických systému. Dnešní informační technologie se velmi intenzivně zabývají komunikací v heterogenním síťovém prostředí, a tak se nabízí jejich využití i v automatizovaných knihovnických systémech. Samozřejmě, že nakonec musí vzniknout protokol, který bude funkčně velmi podobný protokolu Z39.50, ale bude "zabalený" do moderního a obecného konceptu. Určité iniciativy 29 SOAP je protokol založený na XML, pro výměnu informací v decentralizovaném distribuovaném prostředí.
  • 46. 46 tímto směrem je možné pozorovat již dnes. Například ELAG (European Library Automation Group) vydal na 25. mezinárodním semináři rezoluci [HAL01], která vyzívá k adaptaci stávajících knihovnický protokolů a norem do obecných ITC technologií. Prvním náznakem přechodu k novým technologiím je protokol ZXML, známý též pod názvem eZ3950, jenž počítá s použitím webových služeb a obecného přenosového protokolu SOAP.
  • 47. 47 3. SIGNATURY DIGITÁLNÍCH OBJEKTŮ 3.1. Úvod do kryptografie Co je kryptografie? Vezmeme-li to doslova, pak jde o "studium tajného písma". Často se také používá pojem šifrování. V podstatě jde o vědní disciplínu, která se zabývá šifrováním dat za pomoci matematických metod. Praktické aplikace kryptografie jsou v dnešní době velmi široké a dále porostou. Jde například o posílání utajených informací nezabezpečeným informačním kanálem (například elektronickou poštou) nebo o mechanismus digitálních podpisů. Prostě všude tam, kde je nutné informace utajovat nebo ověřovat jejich pravost [ŠOB00]. Potřebu utajovat některé obsahy digitálních objektů nebo zaručit jejich autenticitu můžeme od digitální knihovny vyžadovat. S kryptografií se můžeme v historii setkat již u starých národů. Dá se říci, že je stará téměř stejně jako umění písma. Už v prvopočátcích písemnictví, někdy před 4000 lety, se objevovaly tajné znaky, které byly určeny pouze pro určitou skupinu zasvěcených. První známou šifrou v pravém slova smyslu byl Skytale, který se používal již v 5. století před naším letopočtem ve Spartě. Princip je velmi jednoduchý. Na hůlku o určitém průměru se namotal proužek kůže a na něj byla napsána zpráva. Poté se proužek odmotal a takto byl odesílán kurýrem. Kdo neznal princip, nedokázal zprávu přečíst. Dalším známým příkladem z historie je první z řady substitučních šifer, která byla údajně používána ke korespondenci mezi Juliem Césarem a královnou Kleopatrou. Její princip je opět prostota sama. Celá abeceda byla odsunuta o tři místa doprava. Pro dnešní kryptografy by rozluštění těchto šifer byla práce v nejhorším případě na několik minut. Ani systémy vyvinuté až do konce minulého století nedokáží kryptografům vzdorovat podle podmínek déle než několik hodin. Ovšem již na počátku tohoto století došlo k prudkému rozvoji kryptografie, který byl spjat s vynálezem telegrafu. Až do konce padesátých let bylo vynalezeno velké množství mechanických šifrovacích strojů. Namátkou mohu uvést jedno z nejpřísněji střežených tajemství 2. světové války - schopnost spojenců luštit německé depeše šifrované Enigmou. Pro tento účel také Alan Turing sestrojil jeden z prvních počítačů Colossus.
  • 48. 48 Kryptografii můžeme rozdělit na dvě hlavní části - symetrickou kryptografii a asymetrickou kryptografii. 3.1.1. Symetrická kryptografie Symetrická kryptografie bývá nazývána též konvenční nebo klasická. Založená je na principu jednoho tajného klíče, který vlastní jak odesilatel tak příjemce. Klíč si předávají nějakým bezpečným kanálem. Zprávy jsou šifrovány i dešifrovány pomocí tohoto klíče. Výhodou symetrické kryptografie je její relativně velká rychlost. Běžně používané algoritmy jsou také dostatečně jednoduché na to, aby mohly být implementovány do speciálních hardwarových komponent. V praktických aplikacích, například v bankovnictví, se dnes používá právě hardwarových karet. Nejznámějšími symetrickými algoritmy jsou DES (Data Encryption Standard), 3DES (TripleDES), IDEA (International Data Encryption Algorithm), CAST, BlowFish a TwoFish. 3.1.2. Asymetrická kryptografie a digitální podpis Asymetrická kryptografie, neboli kryptografie s veřejným klíčem, využívá jiné myšlenky. Každý uživatel má dva klíče. Jeden je tajný (soukromý) a jeden veřejný. Využití asymetrické kryptografie se dělí do dvou hlavních skupin - na přenos tajných zpráv a na digitální podpis. Při přenosu tajné zprávy je zpráva odesílatelem zašifrována pomocí veřejného klíče adresáta. Kryptografický algoritmus zaručuje, že zprávu bude schopen dešifrovat (a tedy i přečíst) pouze adresát, a to pomocí svého tajného klíče. Digitální podpis používá podobný princip, ale v opačném směru. Cílem digitálního podpisu je autentifikace zprávy - ověření její pravosti a úplnosti. Zpráva se tedy zašifruje pomocí tajného klíče odesílatele a takto získaný podpis se přidá k původní (nešifrované) zprávě. Adresát si ověří pravost odesílatele tak, že pomocí odesílatelova veřejného klíče dešifruje podpis. Pokud obsah zprávy je totožný s dešifrovaným podpisem, je odesilatel autentický, neboli napsal to opravdu ten, kdo se vydává za odesilatele.
  • 49. 49 Ve skutečnosti je to trochu složitější. Nešifruje se totiž celá zpráva, tak jak je, ale ze zprávy se vytvoří hašovací funkcí (obvykle MD5 nebo SHA-1) tzv. Otisk zprávy, který si můžeme představit jako otisk prstu člověka. Až tento otisk se šifruje. Proč se vytváří otisk zprávy? Prvním důvodem je velmi nízká rychlost asymetrických algoritmů. Uvádí se, že asymetrické šifry jsou řádově tisíckrát pomalejší, než šifry symetrické. Druhým důvodem je velikost zprávy. Kdybychom k původní zprávě přidali ještě zprávu zašifrovanou, tak by se velikost zprávy zdvojnásobila. Zašifrováním otisku můžeme podpis omezit na konstantní velikost. Většinou se používá 128 bitový nebo 160 bitový otisk. Nejznámějšími asymetrickými algoritmy jsou RSA, Diffie-Hellman, ElGamal (varianta Diffie-Hellmana), DSA a algoritmy založené na eliptických křivkách. 3.2. Potřeba signatur u digitálních objektů Po krátkém úvodu do základů kryptografie chci v této kapitole vysvětlit potřebu signatur u digitálních objektů. V kapitole "Digitální objekt" jsem uvedl, že se digitální objekt skládá ze čtyř komponent. Identifikátoru, metadat, obsahu a signatury. Signatura je komponenta volitelná a často se ani v praxi neimplementuje, nicméně v některých aplikacích má svůj smysl. Hlavní funkce signatur digitálních objektů jsou: 1. zajištění možnosti kontroly, zda obsah dokumentu nebyl změněn 2. zajištění věrohodnosti autora obsahu Jiří Peterka30 v jedné emailové konferenci přirovnává elektronickou signaturu k obálce s pečetí, která dává příjemci záruku, že se její obsah cestou od odesilatele nezměnil, a zároveň prokazuje, že obálku zalepil někdo, kdo vládne danou pečetí . Příklad: Představte si elektronický archív nějakého ministerstva, který zpřístupňuje oficiální dokumenty pro veřejnost. Jistě výborná služba. Ministerstvo by však mělo požadovat zajištění věrohodnosti dokumentů. Co kdyby někdo úmyslně či neúmyslně vyměnil 30 Jiří Peterka
  • 50. 50 nebo pouze pozměnil oficiální dokumenty v archívu? I malá změna v dokumentu může naprosto změnit smysl celého dokumentu. Archív je informační systém připojený ve veřejné síti, ve které existují potenciální bezpečnostní hrozby jak z vnějšku tak i ze vnitř31 . Řešení: Každý digitální objekt v digitální knihovně má signaturu, která obsahuje digitální podpis ministerstva. Tím je zajištěno, že čtenář dokumentu má možnost ověřit platnost digitálního podpisu a tím autenticitu dokumentu. Navíc má i jistotu, že dokument nebyl pozměněn. Výsledkem spolupráce konsorcia W3C a Internet Engineering Task Force je nový standard zvaný XML-Signature Syntax and Processing [BAR02]. Ten specifikuje XML podepisování dokumentů a při dodržení pravidel standardu, zajišťuje autenticitu autora, autenticitu dokumentu i jeho integritu. 31 Většina bezpečnostních průniků do informačních systémů je provedena ze vnitř organizací (pracovníky organizace) nicméně ani průniky z vnějšku nejsou zanedbatelné. Otázka bezpečnosti informačních systému přesahuje rámec této práce.
  • 51. 51 4. DIGITÁLNÍ KNIHOVNY A METADATA 4.1 Úvod do metadat Kapitolu o metadatech jsem do své práce zařadil, protože metadata mají významný vliv na elektronické dokumenty, a tím i na digitální knihovny. Právě proto bychom při budování digitální knihovny měli vědět, co nám metadata mohou nabídnout a jak by digitální knihovna měla s metadaty pracovat a využívat je. V současné době existuje v celosvětovém měřítku nepředstavitelně rozsáhlé bohatství informací uchovávaných v dokumentech. Většinou není problémem, aby určité informace byly publikovány, ale problém je relevantní publikované informace vyhledat. K tomu, aby byly informace dobře vyhledatelné, slouží kvalitní popis dokumentů, který se opírá o identifikační popis, pořádací systémy a metody obsahové analýzy. Výsledkem jsou informace o dokumentech, respektive informace o obsazích dokumentů. Nejčastěji se používá termín informace o informacích - metadata. Cílem této kapitoly je ukázat aktuální trendy v používání metadat, a to zejména v elektronických dokumentech, protože právě tam je jejich nejširší a nejzajímavější uplatnění. Zaměříme-li se na elektronické dokumenty, pak v současnosti nejpoužívanějším médiem pro jejich publikaci je síť Internet, kde můžeme nalézt opravdu velké množství dokumentů. A právě tato skutečnost může způsobit tak zvaný informační problém. Na Internetu je tolik dokumentů, že se nám může stát, a velmi často se nám to i stává, že nemůžeme rychle, kvalitně a uspokojivě nalézt relevantní dokumenty. Buď nenajdeme žádný relevantní dokument a nebo naopak, a to je obvyklejší případ, najdeme velmi mnoho relevantních dokumentů a neumíme rychle rozhodnout, které z nich jsou pro nás zajímavé a které mají nulovou informační hodnotu. K řešení tohoto problému by mohla sloužit metadata. Jaké jsou aktuální trendy v identifikačním popisu a pořádání elektronických dokumentů na Internetu a jak nám tyto metody slouží k vyhledávání, jsem se pokusil popsat v následujících kapitolách.
  • 52. 52 4.2. Normy a specifikace Velkou nutnost metadat elektronických dokumentů si uvědomuje i organizace W3C32 . Výsledkem jejich velkého zájmu o metadata je vytvoření RDF - Resource Description Framework33 a PICS - Platform for Internet Content Selection. Nutnost demonstruje i prohlášení organizace W3C. "Možnosti využití Internetu jsou nekonečné, co nám však internetové technologie nenabízejí, jsou informace o informacích. Identifikační popis, katalogizace a popisné informace v takové formě, aby je bylo možné správně vyhledávat a zpracovávat pomocí počítačů. Jinými slovy, dnešní web potřebuje metadata." [W3CMDS00] 4.2.1. PICS - Platform for Internet Content Selection PICS je množina specifikací, umožňující distribuovat metadata o obsahu elektronických dokumentů ve formě štítků (labels34 ). Štítky obsahují informace v jednoduché, počítačem čitelné formě a jsou primárně určeny k selekci, filtraci a profilování informací danému informačnímu konzumentovi. Vše se samozřejmě odehrává v pozadí a potenciální čtenář o filtraci nemusí vědět. Jistě si dovedeme představit velké množství situací, kdy se nám takovéto automatické filtrování informací hodí a vyplatí. Původně byla tato technologie vyvíjena k tomu, aby rodiče či učitelé měli možnost odfiltrovat nežádoucí materiály pro děti. Dnes tuto technologii s velkým ohlasem přijmou i IT manažeři firem, kterým umožní automatickou cenzuru dokumentů pro jejich zaměstnance. Prohlížení nevhodných dokumentů v pracovní době je pro firmy velkým problémem a tato technologie jim dává do rukou nástroj, kterým zamezí, aby si zaměstnanci prohlíželi webové stránky cestovních kanceláří, zábavné webové stránky, apod. Tuto skutečnost dnes řada firem řeší tak, že neposkytuje svým zaměstnancům plný přístup k Internetu, to jim však na druhou stranu snižuje přístup k mnoha důležitým informačním zdrojům. Normu PICS podporují i vládní instituce, jelikož volné šíření informací všem sociálním skupinám, nemusí být například z morálních či etických důvodů vhodné. Vydavatel či 32 W3C - organizace pro standardizaci webových technologií. 33 Framework - je ucelený znovupoužitelný systém, nad kterým je možno budovat další nadstavby 34 Label - obecně štítek, návěští, záložka (je velmi složité najít ekvivalentní český název pro již zaběhlé anglické výrazy)
  • 53. 53 autor dokumentu má v rámci standardu PICS možnost určit kategorii nebo cílovou skupinu pro publikovaný dokument. Komise pro komunikaci EU k tomu ve 34. bodě svého prohlášení říká: "Komise podporuje vývoj mezinárodních systémů pro hodnocení obsahu dokumentů kompatibilních s protokolem PICS a dostatečně flexibilních k regionálním a kulturním rozdílům, jenž budou přínosem jak pro uživatele, tak pro vydavatele." [EPCC97] Osobně si myslím, že tato technologie bude mít pro vývoj Internetu velký význam nejenom jako úmyslná cenzura, ale i jako inteligentní filtrace nerelevantních dokumentů. Tím nám také částečně pomáhá řešit informační problém. Z pohledu implementace digitálních knihoven je dobré o PICS vědět a případně primární dokumenty o tato metadata obohatit. 4.2.2. RDF - Resource Description Framework RDF (Resource Description Framework) je koncepce zápisu metadat, možňující univerzální a strojově srozumitelnou formu popisu informačních zdrojů (digitálních objektů) v distribuovaném prostředí elektronické sítě Internet. Nejdůležitějšími vlastnostmi celého konceptu je univerzálnost metadat, strojově srozumitelná forma, lepší přesnost než fulltextové vyhledávání a budoucí rozšiřitelnost pomocí RDF schémat. RDF bylo publikováno a doporučeno k používání organizací W3C dne 22.2.1999. RDF specifikace 1.0 vyšla 27.3.2000. Dá se říci, že PICS je podmnožinou RDF. Z předchozí kapitoly je zřejmé, že PICS je primárně určen k popisu obsahu dokumentu. RDF samozřejmě také, ale navíc poskytuje informace i o dalších, z knihovnického pohledu zajímavých prvcích. Jazyk RDF je deklarativní, standardně používající jazyk XML pro zápis metadat digitálního objektu. Tento digitální objekt, často zvaný zdroj, může být jakýkoliv elektronický objekt. Např. elektronický textový dokument, webová stránka, grafický soubor, zvukový soubor, video, apod. V praxi RDF nemusí popisovat pouze digitální objekty, ale dokonce jakékoliv reálné objekty jako jsou výrobky, budovy, instituce, apod.
  • 54. 54 Další vlastností RDF záznamů je možnost odkazu (reference) na jiný RDF záznam, poskytující podrobnější informace. Toto je velmi silný nástroj, který nám ve své podstatě umožňuje definovat hypermetadatovou síť. RDF poskytuje koncepci (framework), ve které nezávislé komunity mohou vytvářet slovníky35 hodící se k jejich specifickým potřebám a mají možnost sdílet tyto slovníky s dalšími komunitami36 . Při sdílení takto vytvořených slovníků musí být význam jednotlivých termínů, respektive jednotlivých vlastností, předem dán a alespoň rámcově normován. Právě k tomu nám slouží RDF schémata. Schéma definuje významy, vlastnosti a vazby mezi jednotlivými atributy metadat37 . Schéma také obsahuje určitá omezení hodnot metadatových atributů a přebírání atributů z jiných schémat. Jazyk RDF umožňuje každému dokumentu, aby obsahoval metadatové údaje (URL lokací) k objasnění, které slovníky jsou v dokumentu používány. Jedním z nejznámějších slovníků je Dublin Core, jenž byl vynalezen knihovnickou komunitou k identifikačnímu popisu a klasifikaci webových dokumentů. Další slovníky mohou zahrnovat úplně jiné obory a to i komerční. Jako příklad můžeme uvést fiktivní aplikaci slovníku pro komunitu pohostinství, který by sloužil k identifikaci a popisu restauračních zařízení. Tak například aplikace slovníku RESTAURACE by mohla obsahovat metadatové atributy typu "adresa", "cenová skupina", "kvalita jídla", "další služby", apod. Zde však může nastat problém, kdy dva různé slovníky použijí stejná jména některých metadatových atributů. V těchto případech nastává potřeba použití jmenných prostorů. Již jsem se několikrát zmínil o tom, že RDF je odvozeno z idejí XML. RDF používá XML jmenné prostory k povolení více stejně nazvaných metadatových prvků pro různá schémata. Mám na mysli situaci, kdy dvě různá schémata chtějí používat stejné jméno metadatového prvku. Např. schéma PUB chce používat atribut ADDRESS jako fyzickou adresu daného objektu (ulice, město, PSČ, ) a schéma PHOTO chce používat atribut ADDRESS jakou URL lokaci na elektronickou fotografii. 35 termínem slovník máme v tomto kontextu na mysli seznam atributů metadat 36 komunitou myslíme určitou, např. oborově zaměřenou, skupinu lidí 37 metadatový atribut je jedna popisná informace z metadatového schématu