Tam a znovu späť: Od integrovaných knižničných systémov k modulárnym
Zo zahraničia
Odkedy sa začiatkom 80. rokov objavili integrované knižničné systémy (IKS), prechádzali neustálym vývojom, až kým sa koncom 90. rokov nedosiahol istý stav nasýtenia. Viaceré IKS uspokojili požiadavky väčšiny knižníc a na trhu neexistoval nijaký dominantný dodávateľ. V roku 2003 sa táto rovnováha narušila. Viedli k tomu dve hlavné príčiny – potreba poskytovať účinný a jednotný prístup k obsahu na webe (napr. k elektronickým zdrojom, na ktoré majú knižnice licencie, k databázam a elektronickým časopisom), ako aj potreba pracovať s elektronickými zdrojmi, ktoré vlastnia samotné knižnice. Aby sme tieto požiadavky mohli uspokojiť, potrebujeme, aby naše systémy obsahovali viacero nových vlastností. Nazvime tieto nové oblasti funkcionality “systémy na správu digitálnych dokumentov” (DOMS) a “portálové služby vyhľadávania informácií”. Mnohí dodávatelia knižničných systémov začali pre tieto nové oblasti vyvíjať aplikácie. Spôsoby praktickej implementácie sú rôzne. Niektorí dodávatelia (napr. Innovative) poskytujú všetky funkcie v jednom systéme, iní dávajú k dispozícii dva systémy (napr. Voyager a ENCompass od Endeavoru), kým minimálne jeden dodávateľ má tri aplikácie. Rodina produktov Ex Libris sa skladá z Alephu, portálového systému MetaLib a Digitoolu (DOMS). V budúcnosti budeme svedkami toho, ako sa aj dnešné monolitické integrované knižničné systémy rozdrobia na menšie časti, popri tradičných IKS budú knižnice napríklad používať klienta Z39.50 od jedného dodávateľa, modul MVS od druhého a akvizičný systém od ďalšieho výrobcu softvéru. Bude si to vyžadovať bezchybnú technickú interoperabilitu, zabezpečenú súborom medzinárodných a národných priemyselných noriem. Integrované systémy nahradia modulárne, ktoré sa hodia pre prostredie sietí alebo konzorcií a umožňujú knižniciam kombinovať najlepšie vlastnosti rozličných produktov. Pri písaní týchto riadkov sme ešte ďaleko od vízie, ktorú tu predkladám, ale systémy, ktoré knižnice používajú, prechádzajú štádiom búrlivého rozvoja. Za posledných 15 rokov, čo sa venujem automatizácii knižníc, som nezažil takú obrovskú rýchlosť zmien. Ako to už býva, keď sa veci menia rýchle, objavuje sa rad zaujímavých problémov, ktoré treba vyriešiť. V tomto článku by som sa chcel venovať niektorým z nich. Čo by malo byť cieľom projektu pri výbere nového knižničného systému? Z pohľadu veľkej akademickej knižnice alebo konzorcia predstavujúceho skupinu knižníc sa veľkou výzvou stáva definovanie cieľa systémového projektu. V rokoch 1997 – 1998, po zhruba 15 rokoch neustáleho vývoja aplikácií, sme mali dosť jasnú predstavu o tom, čo by tieto systémy mali robiť. Najlepšou ukážkou spoločnej paradigmy (prosím o prepáčenie, ak termín “paradigma” používam dosť voľne, ani jej vynálezca Thomas S. Kuhn ju dosť jasne nešpecifikoval) je skutočnosť, že knižnice by mohli používať požiadavky na systém (Request for Proposal – RFP), ktoré získavajú od partnerských inštitúcií, ako vzory na vývoj vlastných požiadaviek na nové IKS. Vypracovanie nového RFP nebývalo revolučným procesom. Knižnice alebo konzorciá si pri špecifikácii vlastných potrieb zvyčajne ponechali väčšinu požiadaviek, ktoré obsahovali staré RFP, a pridali k nim celkom krátky zoznam vlastných, zväčša aby uspokojili špeciálne miestne požiadavky. V rámci tejto paradigmy sa krásne nazhromaždili poznatky o IKS. Tento trend viedol k veľkým a komplikovaným RFP, ktoré ani samotné knižnice celkom nechápali. Podľa vyjadrenia dodávateľov RFP dokonca občas obsahovali aj protirečivé požiadavky. Tento narastajúci proces vytvárania RFP, posilnený vznikom webu, ktorý sprístupnil texty komukoľvek a kdekoľvek, spôsobil ozajstnú paralýzu: nikto sa neodvážil urobiť zásadné štrukturálne zmeny týchto dokumentov, nanajvýš mierne modifikácie. Predchádzajúci prispievatelia k úprave textu sa predsa nemohli všetci mýliť. Alebo mohli? V skutočnosti mohli. Problém spočíval v tom, že technológie sa vyvíjali rýchlo, ale metódy rozširovania a kolektívneho poznania knižníc aplikované pri formulovaní požiadaviek sú ako ropné tankery – otáčajú sa pomaly. Došlo k tomu, že v posledných rokoch knižnice začali nanovo definovať svoje projekty IKS (zväčša na základe intervencií dodávateľov), aby pokrývali širší okruh funkcií, ako sa tradične považovalo za primerané. Vhodným príkladom tohto trendu je Britská knižnica (BL). Pôvodným zámerom bolo kúpiť integrovaný knižničný systém, ako sa definoval v tradičných RFP, ale na záver sa knižnica rozhodla pre všetky tri produkty od Ex Librisu. Aleph je dobrý produkt IKS a právom ho bolo možné vybrať, pričom výhodou spoločnosti v projekte BL bol najmä široký záber ponúkaných produktov. V budúcnosti by sa mal projekt systému začínať definovaním účelu: Získavame iba tradičný IKS, IR (Information Retrieval) portál, DOMS, všetky tieto v jednom, alebo iba nejakú aplikáciu tradične považovanú za modul IKS, ako napr. aplikáciu MVS? Na náš výber budú vo veľkej miere vplývať používané aplikácie, disponibilné zdroje (ľudské a iné) a vyspelosť trhu. Aj keď bude náš projekt veľmi úzko alebo tradične zameraný (napr. implementácia nového akvizičného systému alebo iba tradičný IKS), pri každom projekte treba vziať do úvahy celkové informačno-technologické prostredie, ako je v danom čase zadefinované. Každý systém, ktorý kupujeme, by mal vedieť spolupracovať s každou inou aplikáciou, ktorú používa sieť národných knižníc. Preto každý projekt informatizácie knižnice, ktorú využíva verejnosť, musí mať široký záber, aj keď jej vlastné zameranie je veľmi úzke. Problém spočíva v tom, že ešte dobre nevieme, ako budú systémy alebo ich moduly vzájomne spolupracovať. Keďže chýbajú mnohé zo základných noriem alebo sú iba v počiatočnom štádiu rozvoja, každé z existujúcich riešení má tendenciu byť proprietárne. Knižnice musia podporovať zavedenie noriem a investovať do tejto oblasti – či už jednotlivo, alebo kolektívne. Ako sa budú systémy, ktoré knižnice používajú, vyvíjať? Poskytovatelia knižničných služieb používajú rôzne stratégie pri poskytovaní nových služieb, ktoré naliehavo potrebujeme. Niektorí rozšíria svoj súčasný systém, aby zahŕňal všetky funkčné oblasti “trojuholníka”: portál IR, IKS a DOMS, kým ostatní vyvinú dve, tri a možno aj viac aplikácií. Niektorí dodávatelia možno nemajú dosť zdrojov, aby ponúkli novú funkcionalitu, alebo im súčasná technická infraštruktúra nedovoľuje vybudovať požadované služby bez toho, aby úplne neprepracovali celé systémy. Jedným z výsledkov súčasnej zmeny môže byť to, že počet dodávateľov bude stále klesať. Zostane iba zopár tých, ktorí budú schopní vyvinúť nový softvér vlastnej produkcie alebo získať licenciu. V porovnaní s IKS sú portály IR a najmä DOMS ešte len v počiatočnom štádiu rozvoja. Vôbec to neprekvapuje. IKS trvalo dosť dlho, kým sa stali zrelými produktmi, ale portály sú k dispozícii iba od r. 1998 a prvé DOMS od dodávateľov knižničných systémov sa objavili až v roku 2001. Keďže portály a DOMS zostávajú do istej miery neúplné, také sú aj naše očakávania. Keď Univerzitná knižnica v Helsinkách začala projekt výberu portálu pre fínske univerzitné knižnice, existovalo iba niekoľko portálových RFP, ktoré by sme boli mohli použiť ako vzor. Počas riešenia projektu (1999 – 2003) prešli portály vývojom od pomerne skromných nástrojov na združené vyhľadávanie až po pružné aplikácie ponúkajúce viaceré funkcie – napr. keď sme začali s naším projektom, kontextovo podmienené prepájanie (context-sensitive linking) vôbec nebolo k dispozícii. Takže náš pôvodný RFP neobsahoval všetku funkcionalitu, ktorú sme napokon získali od MetaLibu. Ťažko môžete požadovať služby, ktoré nepoznáte, a je celkom nemožné definovať ich tak, aby sa dali implementovať. Ako portálové aplikácie postupne dozrievali, vedeli sme čoraz lepšie a širšie definovať vlastné očakávania. Každá knižnica, ktorá dnes pripravuje portálový projekt, môže nájsť niekoľko RFP, urobí však najlepšie, ak použije iba tie najnovšie. Umenie napísať portálové RFP prechádza rýchlym vývojom. V porovnaní s IKS je situácia na trhu pri predaji portálov iná. Jedna z aplikácií, MetaLib od Ex Librisu, v istom období už mala veľký podiel na trhu a nepochybne zostane v obľube ešte niekoľko rokov. Je to vďaka skutočnosti, že MetaLib mal silný vplyv na to, čo knižnice požadujú od portálového softvéru, čo opäť posilňuje pozíciu MetaLibu na trhu. Bude zaujímavé pozorovať, ako sa bude portálový trh vyvíjať a akú stratégiu prijme konkurencia, aby Ex Libris porazila. V porovnaní s IKS a dokonca aj portálmi, systémy DOMS a najmä tie, ktoré boli vytvorené dodávateľmi, sú stále v počiatočnom štádiu rozvoja. Akosi prekvapuje, že tieto systémy sa objavujú až teraz. Clifford Lynch v závere minulého tisícročia tvrdil, že schopnosť účinne riadiť elektronické zdroje bude ďalším veľkým krokom k automatizácii knižníc. Dodávatelia IKS nezareagovali dosť rýchle, aby túto príležitosť, ktorá sa na trhu núka, využili, možno preto, že vytvorenie systému DOMS je úplne odlišnou výzvou, ako bolo vytvorenie IKS. Bude potrebné, aby sa objavili nové názory, pohľady a požiadavky, a zrejme aj noví programátori, ktorí by to vedeli urobiť. Treba pripustiť, že niektorí dodávatelia systémov IKS začleňujú funkciu DOMS do svojich tradičných knižničných systémov, ale ja osobne mám pochybnosti o tomto postupe, ktorý môže vážne obmedziť všestrannosť aplikácie. Som toho názoru, že návrhári DOMS by nemali používať súčasné IKS, najmä nie dátový model podľa AACR2 a MARC 21. Pri pohľade na systémy DOMS, ktoré ponúkajú dodávatelia knižničných systémov, mám pocit, že do istej miery sme ešte vždy spätí so spôsobom práce tradičného knižničného systému. Kým v IKS sa množstvo dát vkladá ešte manuálne, v DOMS spracovanie dát zväčša prebieha automaticky. Napríklad knižnica, ktorá si vytvára zbierku novinových článkov, nebude spracúvať texty ručne, ale vybuduje si nástroje, ktoré zautomatizujú proces vkladania nových článkov do systému. Na druhej strane DOMS používaný vo veľkom digitálnom archíve by mal vedieť využiť rad ďalších aplikácií na spracovanie a zobrazenie dát; napríklad existujú špeciálne nástroje na prehliadanie a strih pohyblivých obrázkov, takže niet dôvodu, aby sa táto funkcia zabudovala priamo do aplikácie DOMS. Knižnice sú náchylné kupovať portálové aplikácie od poskytovateľov knižničného systému, keďže sa potom interoperabilita s IKS berie viac-menej za zaručenú (hoci aj táto otázka zďaleka nie je taká jednoduchá, napr. nijaký portál vám neumožní rezervovať si dokument). S DOMS bola situácia iná, keďže dodávatelia knižničného systému nemali čo ponúknuť a knižnice kupovali svoje aplikácie inde, alebo si ich v prípade potreby vypracovali samy. Situácia sa mení, ale ešte vždy možno tvrdiť, do istej miery oprávnene, že systémy DOMS vypracované mimo našej domény vyzerajú zrelšie ako tie, ktoré vyprodukovali “naši” dodávatelia. Kľúčovým faktorom pri rozhodovaní by však mala byť interoperabilita. Dodávatelia knižničného systému možno zatiaľ nemajú tie najkrajšie rozhrania na vkladanie údajov, poznajú však MARC a Z39.50. Normy a interoperabilita Technická interoperabilita medzi knižničnými systémami sa dlho obmedzovala na možnosť výmeny bibliografických dát prostredníctvom medzinárodného výmenného formátu ISO 2709. Internet a následné vytvorenie knižničných sietí a konzorcií situáciu zmenili. Bolo nevyhnutné odovzdávať medzi systémami dotazy a súbory výsledkov, ako aj správy MVS. Normy Z39.50 (ISO 23950) a ISO MVS boli vypracované pred vyše 10 rokmi ako odpoveď na tieto potreby. Dnes je Z39.50 podporovaný každým väčším knižničným systémom, aj keď sa zvyčajne do praxe uviedla iba malá podmnožina normy. Dopyt po ISO MVS bol oveľa viac obmedzený, minimálne preto, že dôležité odkazové systémy poskytovali slabú podporu ISO MVS. Dnes, keď sa napr. v RLG (Research Libraries Group, USA) rozhodli neudržiavať svoj starý, neštandardný systém a podporovať iba prístup založený na ISO MVS, sa zdá, že tento protokol sa prijme a uvedie do praxe. Keď sa spolupráca medzi knižnicami rozšíri a získame IR portály a systémy DOMS, samotná podpora len ISO 2709 a dvoch už uvedených dobre zavedených protokolov už nebude stačiť. Nové požiadavky na interoperabilitu zahŕňajú: – Open URL. Tento protokol, ktorý umožňuje kontextovo podmienené prepájanie, si veľmi rýchlo získava obľubu. Krátko po tom, ako v máji 2003 prebehlo testovanie Open URL 1.0, na zozname záujemcov o implementáciu bolo 20 organizácií. Pri Z39.50 to trvalo dlhšie, kým sa dopracovali tak ďaleko a všetky spoločnosti pracujúce s protokolom boli z domény knižníc. Toto nie je prípad URL alebo niektorých iných protokolov, ktoré sa v súčasnosti vyvíjajú v NIO alebo ISO TC46, ktoré sa tradične považovali za doménu knižníc. – ZING alebo Z39.50 International Next Generation. Tento protokol, ktorý sa v súčasnosti vyvíja, spája najlepšie vlastnosti tradičného vyhľadávacieho protokolu Z39.50 a webu a očakáva sa, že rozšíri použitie protokolu Z39.50 za hranice knižničnej domény. Momentálne existuje iba zopár aplikácií, ani tie nedosahujú požadovanú funkcionalitu, je však isté, že sa ich počet v blízkej budúcnosti zvýši. Osobne si želám, aby sa zvýšila obľuba Explainu, keďže dáta sú tu v strojom čitateľnej forme, klienti ZING-u sa budú môcť dozvedieť o vzdialených databázach a ďalších službách prostredníctvom Explainu, čo je jedným z viacerých predpokladov pre sémantický web. – NCIP (NISO Circulation Interchange Protocol). Výpožičný protokol NISO umožní knižniciam vymieňať si dáta o používateľoch, jednotkách a výpožičných transakciách. V prostredí konzorcií je táto funkcia naliehavo potrebná. – LDAP a Shibboleth. Autentifikácia používateľov bude v budúcnosti veľmi dôležitá, keďže väčšina zakúpeného obsahu, aspoň pre vedecké knižnice, bude elektronická. Dotazy, či má používateľ právo na prístup k zdroju, možno efektívne realizovať pomocou Shibbolethu bez toho, aby sme narušili jeho súkromie. – OAI (Open Archive Initiative). Protokol na zbieranie metadát z otvorených archívov umožňuje národnú a/alebo medzinárodnú spoluprácu pri zbieraní metadát o dizertáciách, preprintoch alebo principiálne o ľubovoľnom prameni v digitálnej alebo tlačenej forme. – Dublin Core, ONIX, MODS a ďalšie formáty bibliografických metadát. Naše systémy musia vedieť narábať s rôznymi druhmi metadát, pretože budeme dostávať dáta od viacerých organizácií a posielať ich rôznym organizáciám, nie všetky z nich budú používať MARC. Aj keď sa knižnice ešte dlho budú spoliehať na AACR2 a môžu v ďalších rokoch zväčša stále používať MARC 21, musíme byť pripravení na iné možnosti. Ak budú informačné systémy paralelne používať viaceré odlišné formáty, musíme si uvedomiť možné dôsledky. Napr. dobrý DOMS musí dokázať zozbierať akýkoľvek druh včlenených zdrojov metadát vložených do systému a zmysluplne ich indexovať. – Budúce formáty pre ďalšie potreby, ako napr. dlhodobé uchovávanie elektronických zdrojov, správu digitálnych autorských práv, informácie o poskytnutých licenciách, opis vzdelávacích prameňov, oficiálne publikácie. NISO a ISOT C46 budú mať veľa práce pri vývoji nových noriem, pri revízii existujúcich, ako aj pri vypracovaní smerníc, ako ich používať. Treba dúfať, že knižnice sa v budúcnosti budú aktívne zúčastňovať na procese normalizácie. Na zabezpečenie účinnej technickej interoperability niet lepšieho základu, ako je dobrá norma a správna smernica na jej použitie. Prirodzene, že normy nemajú nijaký význam, ak sa neuvádzajú do praxe. Knižnice musia žiadať, aby sa ich dodávatela opierali o normy, a nie o krátkodobé proprietárne riešenia, inak naše budúce modulárne systémy nebudú vedieť navzájom náležite komunikovať a naši dodávatelia budú nútení robiť veľa duplicít pri vytváraní aplikačných rozhraní voči mnohým iným systémom. Ohrozilo by to prechod zo súčasného prostredia, v ktorom dominuje jeden dodávateľ, k flexibilnejšej budúcnosti. Poznámka: * Autor je riaditeľom databázových služieb v Univerzitnej knižnici v Helsinkách. Prameň: Hakala, Juha: There and back again: From integrated to modular library systems. In Helsinki University Library Bulletin 2003, s. 11-14. Preložila Antónia Jasemová. |