Zpráva pro kontrolní den projektu VaV Národní geovědní bibliografie (SP II 4h3/22/07)
konaný dne 9.12.2009
Autoři: Hana Breiterová, Richard Binko, Petr Čoupek, Jan Klůfa, Martin Kybal, Jan Sedláček, Helena Skarková
Předkládá ředitel České geologické služby Zdeněk Venera
Česká geologická služba | Czech Geological Survey K l á rov 1 3 1 / 3 , 1 1 8 2 1 Praha 1, Tel.: (+420) 257 089 500, Fax (+420) 257 531 376 w w w. g e o l o g y c z Pro s i n e c 2 0 0 9 Pra h a
1. Úvod Cílem projektu SP II 4h3/22/07 je vytvoření nové informační infrastruktury v oblasti věd o zemi. Tato infrastruktura vznikne využitím dat pro Registr informací o výsledcích (dále RIV) a další publikační činnosti pracovníků organizací zabývajících se vědami o Zemi a jejich spojením s geologicko-mineralogickou bibliografií ČR zpracovávanou v knihovně ČGS. Propojení dosud samostatných databází umožní uživateli získat informace v jednotném informačním rozhraní.
2. Postup prací Na konci roku 2008 bylo vytvořeno centrální úložiště bibliografických záznamů (bylo prezentováno na kontrolním dni 10.12.2008). Do tohoto úložiště bylo pro účely prezentace importováno cca 30 záznamů z článkové databáze ČGS. Po konzultaci o harmonogramu dalších prací v roce 2009 jsme se rozhodli, že bude následovat řešení 2 závažných kroků současně. A to vývoj konverzních tabulek a vývoj duplicitního klíče. Oba problémy jsou zásadní pro hladký chod celé aplikace.
2.1 Data externí Na počátku února 2009 jsme oslovili naše partnery a požádali je o první dodávku dat z jejich systémů s co největší různorodostí typů dokumentů a v co největší retrospektivě. Záznamy jsme obdrželi od Moravského zemského muzea, Akademie věd ČR (za vybrané ústavy), Přírodovědecké fakulty UK, Národního muzea. V říjnu 2009 jsme po dlouhém jednání obdrželi základní soubor dat z Přírodovědecké fakulty MU v Brně. Formáty externích dat ukazuje tab.1. tab. 1: Formáty externích dat ORGANIZACE
FORMÁT DAT
Moravské zemské muzeum
XML
Národní muzeum
XML
Přírodovědecká fakulta MU
XML
Přírodovědecká fakulta UK
XML
Ústavy Akademie věd
UNIMARC, ISO 2709
2.2 Data interní Datový sklad ČGS je zaměřen na sběr geovědních informací, jehož součástí jsou i knihovnická data. Pro export dat do NGB byly vybrány dvě databáze: Geologická článková bibliografie a Publikační činnost zaměstnanců. Databáze geologické článkové bibliografie vznikla v roce 1990 a obsahuje záznamy od r. 1989. V současné době má více než 23000 záznamů článků z časopisů a sborníků a kapitol z knih tištěných nebo elektronických. Jsou zpracovávány podle standardů AACR2/UNIMARC. Data z bibliografie byla exportována jako soubor ve formátu UNIMARC ISO2709. Databáze publikační činnosti zaměstnanců ČGS (GeoPub) vznikla v roce 2006 jako systematická evidence informací o výsledcích projektů výzkumu a vývoje této organizace. Přepracována do nové podoby byla v roce 2008. Databáze je průběžně doplňována zaměstnanci ČGS a obsahově spravována pracovnicí knihovny. Základem této databáze se stala data od roku 2000, která jsou každoročně předávána do RIV. Pro účely evidence veškeré publikační činnosti zaměstnanců byla databáze rozšířena o výsledky (např. disertační a diplomové práce, články v nerecenzovaných odborných periodikách apod.), které se do RIV nepředávají. Struktura a obsah dat, která se předávají do RIV, odpovídají Popisu údajů dodávaných do IS a VaV – RIV v roce 2009 [pop09]. U dat, která se do RIV nepředávají, evidujeme po obsahové stránce pouze údaje, které jsou nezbytné pro vytvoření jejich citace. Pro převod dat byly dále vybrány jen ty druhy výsledků, které vyšly tiskem nebo elektronicky (tab. 2).
tab. 2: Seznam druhů výsledků v databázi publikační činnosti zaměstnanců ČGS NÁZEV DRUHU VÝSLEDKU Článek v odborném periodiku Odborná kniha Kapitola resp. kapitoly v odborné knize Článek ve sborníku Patent Výsledky s právní ochranou (užitný vzor, průmyslový vzor) Ostatní výsledky, které nelze zařadit do žádného z výše uvedených druhů výsledku Specializované mapy s odborným obsahem Certifikované metodiky Software Poskytovatelem realizované výsledky (promítnuté do právních předpisů, norem, směrnic a předpisů nelegislativní povahy) Technicky realizované výsledky (prototyp, funkční vzorek) Poloprovoz, ověřená technologie, odrůda Audiovizuální tvorba, elektronické dokumenty Uspořádání (zorganizování) konference Uspořádání (zorganizování) workshopu Uspořádání (zorganizování) výstavy Článek v odborném periodiku nerecenzovaný Článek v nerecenzovaném sborníku nebo abstrakt ve sborníku Článek v periodikách Pedagogická činnost Sborník Skripta Exkurzní průvodce Disertační práce Diplomová práce Zpráva (závěrečná) Zpráva ze zahraničních expedic Populární literatura Přednáška – mimokonferenční Rozhlasový, televizní pořad Propagační materiál
PŘEDÁNO DO RIV ano ano ano ano ano
EXPORT DO NGB ano ano ano ano ano
ano
ano
ano ano ano ano
ano ano ano ne
ano
ne
ano ano ano ano ano ano ne
ne ne ne ano ano ano ano
ne ne ne ne ne ne ne ne ne ne ne ne ne ne
ano ano ne ano ano ano ano ano ano ano ano ne ne ne
Z datového skladu GeoPub byl připraven nejprve soubor všech tištěných výstupů ve formátu xls. V červenci 2009 byl na žádost kolegů z Multidat připraven export z databáze GeoPub ve formátu xml. Jejich struktura vychází ze strukturálního xml schématu pro předávání dat do RIV09 [sche09]. Pro potřeby dodávky však bylo nutné udělat některé úpravy (např. z důvodu ochrany osobních dat neuvádíme rodná čísla). U dat, která se do RIV nepřevádějí, máme k dispozici jen citační údaje. Některé položky schází (např. jazyk výsledku a anotace) a naopak se zde vyskytují položky nové (např. místo uložení u diplomových a dizertačních prací a u zpráv). Pro potřeby exportu bylo proto nutné doplnit a rozšířit strukturu v xml o nové prvky. Také z těchto důvodů byl export dat rozdělen na dvě části.V prvním souboru (CGS_RIV.xml) jsou data, která jsou předávána do RIV a v druhém souboru (CGS_neRIV.xml), jsou data, které se do RIV nepředávají. Data budou v dalších letech exportována do NGB vždy po určitém přírůstku záznamů. Proto se jevilo jako nejoptimálnější pro převod dat naprogramovat aplikaci. Po ověření a vyzkoušení veškerých možných reakcí aplikace při exportu dat byly vygenerovány dva xml soubory (obr. 1) se všemi záznamy z databáze publikační činnosti. Celkem bylo vyexportováno 2986 záznamů. Soubory pak byly předány firmě Multidata, spol. s. r. o. pro vytvoření duplicitního klíče. Dokumentace Předávání údajů pro NGB ve formátu XML za ČGS je v příloze 2.
obr. 1: Aplikace pro převod dat do formátu xml Literatura: [pop09] Popis údajů dodávaných do RIV a VaV - RIV v roce 2009[cit. 2009-06-19], dostupné z URL http://www.vyzkum.cz/FrontClanek.aspx?idsekce=513951 [sche09] Vlastní schéma xml 2009 [cit. 2009-06-19], dostupné z URL http://www.vyzkum.cz/FrontClanek.aspx?idsekce=515697
2.3 Technické řešení NGB Aplikace pro sběr dat z oblasti geologie vzniká v prostředí databázového stroje TINMAN. Přitom plně využíváme zkušenosti, které s tímto strojem máme z jiných aplikací, a dále pak zkušenosti s konverzemi dat z různých formátů (ISIS, UNIMARC atd.). Aplikace bude po dohodě s pracovníky ČGS umístěna na serveru s operačním systémem na bázi UNIX. Sběr dat bude probíhat různými způsoby (e-mail, ftp atd.) a zatím se nepočítá s jeho automatizací. Soubory s daty od jednotlivých přispěvatelů se ručně (pomocí ftp) přemístí do dohodnutých adresářů v rámci instalace aplikace na serveru. Vlastní import záznamů pak bude zcela automatizovaný a bude řízený periodicky automaticky spuštěným skriptem. Tento skript vždy nejprve zkontroluje, zda se v příslušných adresářích vyskytují nové soubory, a následně pak v případě potřeby zajistí spuštění aplikace a import záznamů. Předpokládají se dva formáty vstupních dat - UNIMARC, RIV. Data ve formátu UNIMARC se do aplikace importují přímo. Data ve formátu RIV se nejprve přetransformují do podoby vhodné pro import a následně se spustí import. Každý záznam kromě údajů jmenného a věcného popisu obsahuje též údaje o svém vlastníkovi, tj. siglu knihovny, příp. další údaje v závislosti na zdrojových datech. Součástí importních mechanismů jsou i nástroje na deduplikaci záznamů. Jako klíč se používají standardní čísla (ISBN, ISSN) v kombinaci s dalším klíčem - prvních několik písmen autora + prvních několik písmen názvu + rok vydání (u článků navíc ještě ročník a číslo). Nyní probíhá testování těchto klíčů na velkém objemu dat, které má ukázat, zda jsou takto definované klíče dostačující. V případech, kdy nebude možné jednoznačně určit, zda se jedná o skutečnou duplicitu, budou mít zaměstnanci ČGS přístup do aplikace pomocí klienta. Zde se budou moci v konkrétních případech rozhodnout, zda příslušné záznamy sloučí (v databázi pak bude jeden záznam s více údaji o vlastnících) nebo zda ponechají více záznamů. Koncoví uživatelé budou mít přístup do aplikace pomocí www rozhraní. Toto rozhraní nabízí jak možnost vyhledávání podle různých kritérií, tak i možnost listování v rejstřících. Případné výstupy z aplikace budou realizovány pomocí xml.
2.3.1 Popis importních a deduplikačních skriptů Data od jednotlivých přispěvatelů se umístí do samostatných adresářů. Každý adresář se zpracovává individuálně (pomocí vlastních skriptů). V případě potřeby jsou na jednotlivé soubory aplikovány před importem různé konverze (např. konverze znakové sady nebo transformace RIV souborů do podoby vhodné pro import). Jednotlivé soubory se importují pomocí samostatných importních skriptů. Při importu se zachovává identifikační číslo záznamu (pole 001) a informace o tom, od jakého přispěvatele záznam pochází. To umožňuje případné budoucí aktualizace záznamů (opravy chyb, doplnění údajů apod.) Přehledně je tento proces znázorněn ve schématu 1.
Přispěvatel 1
Importní skript 1 Konverze znakové sady
Přispěvatel 2 Přispěvatel 2
Importní skript 2 Importní skript 3
Transformace RIV souborů
GeoLib (datový sklad NGB)
Importní skript n
Přispěvatel n
Schéma 1: Import záznamů Po importu záznamů probíhá jejich indexace pro potřeby vyhledávání. Poté se ke každému nově zapsanému záznamu vygeneruje deduplikační klíč. Pokud se tento klíč shoduje s některým již dříve vygenerovaným klíčem, porovná se název u obou záznamů a v případě přesné shody proběhne automatické sloučení záznamů. V opačném případě aplikace záznamy označí pro následnou manuální deduplikaci. Ta probíhá prostřednictvím klienta, v kterém mají oprávnění uživatelé možnost rozhodnout se, zda příslušné záznamy sloučí. V případě, že dojde ke sloučení záznamů, zachovají se údaje jmenného i věcného popisu a zároveň lokální údaje (sigla, signatura atd.) všech vlastníků záznamu. Dále se zachovají všechna původní čísla záznamů (pole 001). Pokud se uživatel rozhodne, že záznamy nesloučí, informace o tom se zapíše do systému, aby nedocházelo k opakované deduplikaci dříve vložených záznamů. Celý proces je znázorněn ve schématu 2.
GeoLib
Importované záznamy
GeoLib Indexace záznamů Vytvoření klíčů k deduplikaci
GeoLib
GeoLib
GeoLib
Automatická deduplikace
Manuální deduplikace
Záznamy po deduplikaci
Schéma 2: indexace a deduplikace záznamů
2.3.1 Deduplikační klíč Při tvorbě deduplikačního klíče jsme vycházeli ze zkušeností jiných knihoven, které podobný problém již dříve řešili. V rámci testování jsme na vzorek cca 22 tisíc záznamů od různých přispěvatelů postupně aplikovali 5 různých variant deduplikačního klíče. Tyto varianty jsou popsány v tab. 3:
tab. 3: Varianty deduplikačního klíče Klíč Duplicity Popis klíče FULL 46 TITULX # AUTOR[6] # ISN # DATUM # SVAZEK A 109 TITULX[15] # AUTOR[6] # ISN # DATUM # SVAZEK Přibyla řada falešných duplicit, neboť některé velmi dlouhé názvy článků se mohou lišit až na samém konci (číslem mapového listu apod.). B 114 TITULX[15] # AUTOR[6] # DATUM # SVAZEK 0 257 TITUL Přibyly duplicity stejnojmenných článků uveřejněných v různých periodikách. 1 282 TITULX TITUL TITULX AUTOR ISN DATUM SVAZEK [n]
název dokumentu název dokumentu zbavený mezer a interpunkce první autor ISBN nebo ISSN datum vydání ročník (číslo) seriálu počet znaků, které se z uvedeného údaje použijí
Z této tabulky vyplývá, že se nejvíce duplicit vyskytuje v případě použití jednoduchého klíče TITULX. Velká část z nich však ve skutečnosti duplicity nejsou. Naopak v případě použití klíče FULL je duplicit nejméně, avšak je velmi pravděpodobné, že se některé skutečné duplicity nenašly (díky odchylkám v zápisu údajů a v použité interpunkci). V současnosti probíhá vyhodnocování jednotlivých variant, po dohodě s pracovníky ČGS bude zvolen optimální klíč.
2.4 Harmonizace interních dat Vzhledem k tomu, že bibliografické záznamy z datového skladu ČGS tvoří významnou část budoucí Národní geovědní bibliografie, je nezbytně nutné pracovat na jejich harmonizaci. Průběžně proces harmonizace dat probíhá jak v databázích knihovny (zejména separáty a články), tak v datovém skladu GeoPub, a v databázích zpráv a map archivu ČGS. Harmonizace dat v databázích, které nejsou zdrojem pro NGB (separáty, archivní materiály) je nutná k tomu, aby data v NGB a data v ostatních bibliografických databázích ČGS byla kompatibilní pro budoucí jednotné vyhledávání v obou systémech současně. Cílem je funkční poskytování služeb a jednoduché vyhledávání v jednom prostředí.
2.4.1 Databáze knihovny Práce s článkovou databází knihovny a s datovým skladem GeoPub běží v udržovacím režimu, intenzívně pracujeme na databázi separátů. V roce 2009 probíhaly práce hlavně na opravách špatně převedených záznamů, přidělování čárových kódů jednotlivým jednotkám, doplňování chybějících záznamů separátů.
2.4.2 Databáze archivu Pokračuje harmonizace dat archivu ČGS. Jde o databázi zpráv, posudků, rukopisů a databázi map tištěných a rukopisných. Vzhledem k integraci služeb knihovny a archivu do jedné studovny je používán jeden výpůjční protokol. Databáze archivu jsou v jiných systémech než databáze knihovny a aby mohl být používán jeden výpůjční protokol, je proto třeba opakovaně konvertovat data z těchto databází do knihovního systému Clavius. Uvažovali jsme o dvou modelech: konverze úplná nebo částečná. Každý model má své výhody a nevýhody. Úplná konverze je výhodnější tím, že by zpracování pokračovalo v knihovním systému Clavius. Po dlouhých diskusích jsme se rozhodli pro konverzi pouze vybraných polí a to proto, že mapová databáze je navázaná na mnoho jiných aplikací (mapový server, digitální studovna, on line obchod atd.) a některé typy archivních materiálů jsou příliš specifické na to, aby se daly převést do knihovního systému. Před převodem proběhla podrobná analýza, popis struktury obou databází (rukopisných textů a zpráv, posudků a mapových dokumentů). Na základě analýzy byla vybrána pole potřebná k jednoznačné identifikaci dokumentu (názvové a autorské údaje, svazkové informace, vydavatelské údaje, signatura). Tato pole byla porovnána se strukturou polí v knihovním systému Clavius a poté bylo vytvořeno předběžné konverzní schéma. Před importem dat obou archivních databází (zprávy a posudky a mapová prozkoumanost) do cílového systému muselo dojít k jejich konsolidaci. Pro tento účel byla vytvořena transportní databázová struktura (schéma 3), do které jsou importována data archivních databází a kde jsou data upravena pro účely jejich exportu do knihovního systému CLAVIUS. Transportní databáze (AR2C) byla navržena jako relační databáze provozovaná v systému řízení báze dat (SŘBD) ORACLE. Její struktura umožňuje soustředit data ze zdrojových databází archivu při zachování referenční integrity a konzistence dat.
Schéma 3: E-R diagram struktury transportní databáze AR2C
Při práci s databázemi byly odhaleny výskyty duplicit a multiplicit (signatury, čárové kódy), které by mohly negativně ovlivnit identifikaci dokumentu. Některé případy byly řešeny průběžně, další duplicity budou odstraněny do první opakované konverze příští rok. Tím bude zároveň vyzkoušena funkčnost celého systému. Rovněž bylo nutno sjednotit slovníky jmenných a věcných autorit tak, aby byly kompatibilní se slovníky v knihovním systému Clavius. Převod dat z databází zpráv a map bude probíhat vždy po naplnění databází určitým novým počtem záznamů. Proto byla pro převod dat naprogramována aplikace. Vlastní chod aplikace je rozdělen do tří částí. V první fázi aplikace ověřuje některá vkládaná data (např. zda jsou první čtyři znaky u roku v databázi opravdu číslice.). Pokud proběhnou kontroly správně, následují další kroky a to: vymazání stávajícího obsahu tabulek a poté jejich naplnění (obr. 2). V případě, že jsou během kontrol nalezeny chyby v datech, je chod aplikace ukončen chybovým hlášením s identifikací záznamů, které je nutné opravit (obr. 3). Chování aplikace a její možné reakce na různé typy dat byly vyzkoušeny ve zkušebním provozu. Databáze pak byla naplněna daty, která byla zpřístupněna firmě Lanius pro vytvoření konverzní aplikace pro převod těchto dat do knihovního systému Clavius.
obr. 2: Aplikace pro přenos dat
obr. 3: Aplikace pro přenos dat do konverzní tabulky. Ukázka chybového hlášení při nekonzistenci dat Vlastním řešením opakované aktualizace je vybudování speciální SW nadstavby (datového můstku mezi databázemi archivu a knihovním systémem) pro opakovaný import a aktualizaci údajů v systému Clavius na serveru Oracle,, který umožní pravidelnou (opakovanou) aktualizaci dat z databází archivu. Pro tuto práci byla uzavřena dohoda s ing. Klůfou z firmy Lanius. Práce byla rozdělena do následujících kroků: 1) analýza dat 2) rozmístění položek do ekvivalentů v knihovním systému CLAVIUS 3) vytvoření vlastního algoritmu pro přesun a opakované aktualizace 4) ladění, testování a případné úpravy
Postup při importu (synchronizaci) Pro import archivních dat je zapotřebí Oracle klient (ODBC) ver. 10.02.00.01.
Prvotní import včetně svazků 1) 2)
Pustí se program IMPARCH, který vytvoří TAG soubor ARCH_TAG.TAG. Poté se přes katalogizaci soubor importuje s parametry kódová stránka 1250, netitulovat, nic nevytvářet, možná SLOVA a vymazat vyloučená pole.
Opakovaný import 1) Pustí se program ZALARCH, který vytvoří zálohu současného ARCHIVu, a promaže pomocná data. 2) Pustí se program IMPARCH, opět se vytvoří soubor, ale současně se identifikace dat v tabulce TITULy a LINEAR změní na minusové (nebudou vidět). Přitom bude probíhat aktualizace SVAZKů, pomocí ID_TITULU, které se nesmí měnit !!! 3) Importuje se soubor ARCH_TAG.TAG klasickým importem. Nyní máme nové záznamy, aktuální SVAZKy, ale nejsou provázané v CLAVIu přes tzv. TCISLO. 4) Pustíme program IMPARCH, kde zvolíme synchronizaci SVAZků, to provede změnu TCISLA u nově importovaných svazků na číslo minulé (SVAZKY budou opět vidět u nově importovaných záznamů). 5) Nyní je potřebná zběžná kontrola správnosti celé operace. 6) Je možné tzv. záporné záznamy (TITULY, LINEAR) smazat prográmkem DELTEMP.
Dokumentace k IMPORTU archivu zprav a map do systému CLAVIUS je v příloze 3.
3. Studijní a propagační cesty Jednání technické skupiny CGI IWG, Quebec 2009 (Commission for the Management and Application of Geoscience Information - Interoperability working group) Díky novým technologickým možnostem a rozvoje internetu obecně v posledních letech se ukazuje, že užší spolupráce mezi geologickými službami se do budoucna neobejde bez automatizované výměny a sdílení digitálních geologických informací. Jednání technické skupiny IWG komise CGI se zabývalo podrobnými možnostmi interoperability, to jest automatizované výměny digitálních geologických dat mezi geologickými službami různých zemí. Implementace a podíl na rozvoji konceptuálního modelu GeoSciML zapadá do rozvoje koncepce rozvoje poskytování geologických a aplikovaných dat a informací prostřednictvím internetových služeb založených na OGC/ISO standardech . Interoperabilita je založena na používání webových služeb standardu OGC konsorcia a konceptuálního modelu GeoSciML jazyka včetně společných ontologií. Jednání připravilo novou verzi konceptuálního schematu GeoSciML 3.0. ČGS jakožto partner ostatních geologických služeb a účastník mezinárodních projektů musí interoperabilitu implementovat (např. direktiva INSPIRE). Tohoto jednání se zúčastnil Mgr. Petr Čoupek, člen řešitelského týmu projektu NGB. Z projektu byla hrazena část nákladů spojených s touto studijní cestou. Společný sjezd České geologické společnosti a Slovenské geologické společnosti se konal na přelomu září a října 2009 v Bratislavě. V přednášce H. Breiterové „Geologické knihovny včera a dnes“ byla geologické veřejnosti představena Národní geovědní bibliografie jako nová informační infrastruktura v oblasti věd o Zemi.
4. Výsledky a závěr Po konverzi katalogů do prostředí Oracle bylo nutno vyvinout zcela nové internetové vyhledávání v databázích knihovny (obr. 4). Toto vyhledávání bylo připraveno se spolupráci s programátory ČGS a spuštěno v červnu 2009.
obr. 4: Úvodní stránka vyhledávání v elektronických katalozích knihovny ČGS
V dřívějším systému probíhaly exporty z databází knihovního systému do databáze Oracle, do které nahlížela vyhledávací webová aplikace. Tato procedura nyní odpadá, výhodou nového prostředí je on line zobrazování zpracovaných záznamů. Vyhledávání je postaveno tak, že lze vyhledávat buď v jednotlivých katalozích, nebo ve všech současně. Dotaz je možné upřesnit několika parametry. Zobrazují se všechny vyhledané záznamy ve stručné sestavě, ve které lze listovat. Ze sestavy je možné zobrazit podrobný náhled na jednotlivý záznam, včetně plného tagovaného záznamu ve formátu UNIMARC. I mezi těmito jednotlivými záznamy je možno listovat, popřípadě se vrátit na sestavu všech vyhledaných záznamů. Celý postup vyhledávání znázorňují obr. 5 - 8.
obr. 5: Vyhledávání v databázích knihovny ČGS: zadání dotazu
obr. 6: Vyhledávání v databázích knihovny ČGS: seznam vyhledaných záznamů
obr. 7: Vyhledávání v databázích knihovny ČGS: podrobný záznam
obr. 8: Vyhledávání v databázích knihovny ČGS: plný tagovaný bibliografický záznam ve formátu UNIMARC K tomuto vyhledávání bude možno napojit i konvertované stručné záznamy z archivních databází, s tím, že podrobné vyhledávání včetně náhledů map zůstane v původní podobě. Napojení stručných záznamů archivních materiálů konvertovaných do knihovního systému Clavius do jednotného vyhledávacího prostředí je plánováno na 1. pololetí 2010. Důležité je, že harmonizace dat v katalozích knihovny a archivu dávají dobrý základ pro případné budoucí jednotné vyhledávání v Národní geovědní bibliografii i katalozích současně.
5. Výstupy Čoupek, P. , Breiterová, H. (2009): Vyhledávací aplikace v katalozích knihovny ČGS. Praha. http://www.geology.cz/app/knihovna/hl.pl. Breiterová, H. (2009): Geologické knihovny včera a dnes. In M. Kohút a L. Šimon: Spoločný geologický kongres Českej a Slovenskej geologickej spoločnosti. Zborník abstraktov a exkurzný sprievodca, s. 29. Štátny geologický ústav Dionýza Štúra. Bratislava. ISBN 978-8089343-24-9.
Příloha 1: Stav čerpání k 9.12.2009
Čerpání 2009 – ROZPOČET PŘÍJEMCE
(v tis. Kč)
Celkové uznané náklady na řešení projektu
Hrazeno z prostředků poskytnutých ministerstvem
Hrazeno z prostředků příjemce
Vyčerpáno k 9.12.2009
2009
1325
1262
63
1325
Z toho neinvestiční prostředky
1325
1262
63
1325
602
602
0
602
- ostatní osobní náklady
50
50
0
50
- režijní náklady
93
30
63
30
Z toho investiční prostředky
0
0
0
0
Roky řešení projektu
Z toho: - mzdy
Příloha 2 Předávání údajů pro NGB ve formátu XML za ČGS: struktura dat (Helena Skarková) Obsah datového souboru dodávky je zkonstruován podle následující šablony: Deklarace XML <dodavka xmlns="urn:CZ-MULTIDATA" struktura="RIV09A-pro-MULTIDATA"> Kořenový element s deklarací jmenného prostoru a deklarace struktury dat pro NGB.
Záhlaví dodávky, obsahuje informace o dodávce a dodavateli dat. Vymezení rozsahu oblasti. Specifikace roku sběru dat. <predkladatel> Údaje o předkladateli dodávky dat. <subjekt> Údaje o subjektu – předkladateli sběru dat. >{IČO organizace} Česká geologická služba Czech Geological Survey Názvy organizace v anglickém a českém jazyce <dodavatel> Specifikace dodavatele. <pracovnik-povereny-pripravou-dodavky> Údaje o pracovníkovi, který je pověřen její přípravou dodávky dat. {celé jméno pracovníka} <emailova-adresa>{emailové spojení}
Obsah dodávky dat Jednotlivé výsledky, které tvoří obsah dodávky dat. Podrobná specifikace viz. dále.
Výsledky
{kód původního jazyka výsledku} Kód jazyku podle číselníku jazyků zveřejněného na www.vyzkum.cz. {název výsledku česky} {název výsledku anglicky} {popis výsledku česky} {popis výsledku anglicky} {jméno tvůrce výsledku} <prijmeni>{příjmení tvůrce výsledku} Skupina údajů klasifikujících výsledek.
{klíčové slovo nebo výraz}
Specifická část pro výsledek druhu clanek-v-periodiku, clanekperiodikum-nerecenzovane Skupina údajů o periodiku. {ISSN periodika} {oficiální název periodika} Skupina údajů o vydavateli periodika. <stat>{kód státu vydavatele periodika} Kód státu podle číselníku států zveřejněného na www.vyzkum.cz. {svazek periodika, v němž se nachází výsledek} {číslo periodika, v němž se nachází výsledek} <strany pocet="{počet stran výsledku}" >
Specifická část pro výsledek druhu kniha, popularni-literatura, skripta {ISBN knihy} <edice-cislo-svazku>{název edice a číslo svazku} <misto-vydani>{místo vydání knihy} Skupina údajů o nakladateli knihy. {název nakladatele} <strany pocet="{počet stran knihy}" />
Specifická část pro výsledek druhu kapitola-v-knize Skupina údajů o knize, v níž se kapitola nachází. {název knihy} {ISBN knihy} <edice-cislo-svazku>{název edice a číslo svazku} <misto-vydani>{místo vydání knihy} {název nakladatele} <strany pocet="{počet stran knihy}" /> <strany pocet="{počet stran kapitoly}" >
Specifická část pro výsledek druhu clanek-ve-sborniku, clanek-abstraktnerecenzovany-sbornik, sbornik-editorska-cinnost <sbornik>
{název sborníku} {ISBN sborníku} {ISSN sborníku} <misto-vydani>{místo vydání sborníku} {název nakladatele} <strany pocet="{počet stran článku ve sborníku}" >
Specifická část pro výsledek druhu vyzkumna-zprava {ISBN výzkumné zprávy} {verze výzkumné zprávy} <misto-vydani>{místo vydání výzkumné zprávy} Skupina údajů o objednateli výzkumné zprávy. {název objednatele} <strany pocet="{počet stran výzkumné zprávy}" />
Specifická část pro výsledek druhu specializovana-mapa {interní kód produktu} {lokalizace výsledku} {technické parametry výsledku}
Specifická část pro výsledek druhu certifikovana-metodika {IČO organizace} {interní kód produktu} {lokalizace výsledku} {technické parametry výsledku} <ekonomicke-parametry>{ekonomické parametry výsledku} {označení certifikačního orgánu} {datum certifikace výsledku}
Specifická část pro výsledek druhu patent {číslo patentu} Skupina údajů o vydání patentu. {datum registrace patentu} {datum přijetí patentu} <misto>{místo vydání patentu}
Specifická část pro výsledky druhu doplimova-prace, disertacni-práce, zahranicni-expedice-zprava, zaverecna-zprava <misto-ulozeni>{místo uložení} P,32
<strany pocet="{počet stran}" >
Příloha 3 Dokumentace k IMPORTU archivu zprav a map do systému CLAVIUS (Jan Klůfa) Pro import archivních dat je zapotřebí Oracle klient (Odbc) ver. 10.02.00.01. Byla provedena analýza schématu ARCHIV_PRENOS a jednotlivým položkám byl přiřazen ekvivalent v systému CLAVIUS stručně asi takto (jedná se o pole UNIMARCu) : AR2C_TITUL ID_TITUL NAZEV PDONAZEV ZDROJDAT ROK_VYD KODZEME SAMOPRILOH VYDAVATEL MISTO_VYDANI POZNAMKA
- přírůstkové číslo - 200a hlavní název - 200e podnázev - druh dokumentu - 210d rok vydání - 102a kód země (kódové pole) - poznámky k obsahu - 210c nakladatelské údaje, nakladatel - 210a místo vydání - 300a všeobecné poznámky
KOD_TYPMAP VYZNAM
- 608a předmětová hesla, forma žánr
AR2C_TITUL_AUTORI PRIJMENI, JMENO - 700,701, hlavní autor, další autoři AR2C_TITUL_MERITKA MERITKO - 206a oblast spec.údajů, kartograf.dok., měřítko KOD_TYPDOK VYZNAM
- NOSa převáděno do TITULů v CLAVIUSu jako nosič
AR2C_TITUL_VZTAHKML CISLO_LISTU - 423h číslo části JMENO_LISTU - 423t název části (tyto pole jsou provázaná přes tzv.porpole) AR2C_TITUL_SVAZKY + AR2C_TITUL_SIGNATURY tyto tabulky se zpracovávají pohromadě, předpokládá se vazba 1:1 mezi tabulkami AR2C_TITUL a AR2C_TITUL_SVAZKY, pokud mají mapy více řádek v tabulce AR2C_TITUL_SIGNATURY, použije se do tabulky SVAZKU políčka SIGNATURA v CLAVIU první řádek, ty další (včetně toho prvního) se ukládají do políček LOKl (signatura a další údaje) a do políčka NOSa (nosič). Svazky, vztah mezi originálem a CLAVIem CK SIGNATURA
- SVAZKY.CKOD, čárový kód - SVAZKY.SIGN, signatura (první výskyt, jinak vše v políčku LOKl)
ID_TITUL
- SVAZKY.PCISLO přírustkové číslo, jednoznačné
Následují zdrojové kódy všech tří programů ZALARCH.PRG IMPARCH.PRG DELTEMP.PRG 1) ZALARCH ***************** PROVEDE ZALOHU SOUČASNÝCH DAT (JEN ARCHIV) lcPathS=[archiv\zaloha\] lnCas=second() ?"Zálohuji data z tabulky LINEAR..." pohled("select l.* from linear l, tituly t where l.tcislo=t.tcislo and (druhdoku='AZ' or druhdoku='AM') order by l.tcislo") ?"Zaznamů - "+allt(str(recc())) lcFS=lcPathS+[linear] copy to &lcFS ?"Zálohuji data z tabulky SVAZKY..." pohled("select s.* from svazky s, tituly t where s.tcislo=t.tcislo and (druhdoku='AZ' or druhdoku='AM') order by s.tcislo") ?"Zaznamů - "+allt(str(recc())) lcFS=lcPathS+[svazky] copy to &lcFS ?"Zálohuji data z tabulky TITULY..." pohled("select * from tituly where (druhdoku='AZ' or druhdoku='AM') order by tcislo") ?"Zaznamů - "+allt(str(recc())) lcFS=lcPathS+[tituly] copy to &lcFS lnMinut=(second()-lnCas)/60 MessageBox("Záloha dokončena za "+allt(str(lnMinut,4,2))+" minut") 2) IMPARCH *** PROVEDE PRVNÍ I NÁSLEDNÉ (OPAKOVANÉ) IMPORTY do chyby lcPathS=[archiv\] *** Tady se zeptame, zda pustit vytvareni souboru, nebo synchronizaci SVAZKU lnAnswer=MessageBox("Přejete vytvořit soubor pro IMPORT (arch_tag.tag)...stiskněte Ano"+crlf+; ", nebo nabídku spustit synchronizaci SVAZKů...stiskněte Ne",3+32+512,"Vyberte si činnost") if lnAnswer=6 &&vytvorit soubor lnCas=second() Pohled("_majitel") Pohled("select * from tituly where 1=3","OKTitul") ******* LinearTitulu je potrebny pouze fiktivne **********8 IF !used('LinearTitulu') USE LinearTitulu IN 0 NODATA
ENDIF =AFields(laNic,'LinearTitulu') SELECT 0 CREATE CURSOR OKLinear FROM ARRAY laNic ** xnNeGenenerovat00x=.t. lcRecord=[] =strtofile([],lcPathS+"arch_tag.tag",0) *pohled("select * from ARCHIV_PRENOS.ar2c_titul where rownum<10","AR2C") pohled("select * from ARCHIV_PRENOS.ar2c_titul where rownum<10","AR2C") scan lcId_titul=allt(AR2C.id_titul) *InsLin (tcPole,tnPorpole,tcIndik1,tcHodnota) --- KN3171000000054538 lcIdentifier=[A]+allt(AR2C.zdrojdat)+allt(str(_majitel.prefix))+padl(allt(AR2C.id_titul),11,[0 ]) lcIdentSvaz=padl(allt(AR2C.id_titul),12,[ ]) InsLin([001],[0],[],lcIdentifier) InsLin([200a],[0],[1],AR2C.nazev) InsLin([200e],[0],[1],AR2C.pdonazev) InsLin([210d],[0],[],AR2C.rok_vyd) InsLin([102a],[0],[],AR2C.kodzeme) InsLin([327a],[0],[],AR2C.samopriloh) InsLin([210c],[0],[],AR2C.vydavatel) InsLin([210a],[0],[],AR2C.misto_vydani) InsLin([300a],[0],[],AR2C.poznamka) Pohled("select * from ARCHIV_PRENOS.ar2c_titul_autori where id_titul=?lcId_titul order by por_aut","AR2C_AUT") scan lcCeleJmeno=allt(AR2C_AUT.prijmeni)+iif(!empty(AR2C_AUT.jmeno),[, ]+allt(AR2C_AUT.jmeno),[]) if !empty(AR2C_AUT.por_aut) and AR2C_AUT.por_aut=1 InsLin([750)],[0],[0],lcCeleJmeno) else InsLin([751)],chr(recno()+47),[0],lcCeleJmeno) endif endscan Pohled("select vyznam from ARCHIV_PRENOS.ar2c_titul_typ_map , ARCHIV_PRENOS.kod_typmap where id_titul=?lcId_titul and typ_mapy=kod","AR2C_TYPMAP") InsLin([6508],[0],[],AR2C_TYPMAP.vyznam) Pohled("select * from ARCHIV_PRENOS.ar2c_titul_meritka where id_titul=?lcId_titul","AR2C_MERITKA") scan InsLin([206a],[0],[],AR2C_MERITKA.meritko) endscan Pohled("select * from ARCHIV_PRENOS.ar2c_titul_vztahkml where id_titul=?lcId_titul","AR2C_VZTAHKML") scan for recno()+47<255 InsLin([423h],chr(recno()+47),[],AR2C_VZTAHKML.cislo_listu)
InsLin([423t],chr(recno()+47),[],AR2C_VZTAHKML.jmeno_listu) endscan && zjistime jeli TITUL Pohled("select tcislo from tituly where special1=?lcIdentifier","CURTIT") lnReccTitul=recc() lnClavTcislo=iif(lnReccTitul>0,abs(CURTIT.tcislo),0) && udelame zaporny linear if lnReccTitul>0 Pohled("update linear set tcislo=0-tcislo where tcislo=?lnClavTcislo") Pohled("update tituly set tcislo=0-tcislo where tcislo=?lnClavTcislo") endif pohled("select * from ARCHIV_PRENOS.ar2c_titul_svazky s, ARCHIV_PRENOS.ar2c_titul_signatury q left join ARCHIV_PRENOS.kod_typdok t on q.typ_doku=t.kod "+; "where s.id_titul=q.id_titul and s.id_titul=?lcId_titul","AR2C_SVAZKY") lcCKOD=[tuturutu] lnPorPol=47 scan if lcCKOD<>AR2C_SVAZKY.ck lcCKOD=AR2C_SVAZKY.ck && existuje svazek if lnReccTitul>0 Pohled("select #* from svazky where tcislo=?lnClavTcislo","CURCLAVSVAZ") if recc()>1 if CURCLAVSVAZ.pcislo<>lcIdentSvaz && zmenilo se PCISLO replace pcislo with lcIdentSvaz endif if allt(CURCLAVSVAZ.ckod)<>allt(AR2C_SVAZKY.ck) && zmenil se CKOD replace ckod with allt(AR2C_SVAZKY.ck) endif if allt(CURCLAVSVAZ.sign)<>allt(AR2C_SVAZKY.signatura) && zmenila se SIGNATURA replace signatura with allt(AR2C_SVAZKY.signatura) endif if allt(CURCLAVSVAZ.lokace)<>[AR] replace lokace with [AR] endif endif else InsLin([980c],chr(lnPorPol+1),[],AR2C_SVAZKY.id_titul) InsLin([9801],chr(lnPorPol+1),[],AR2C_SVAZKY.ck) InsLin([980g],chr(lnPorPol+1),[],AR2C_SVAZKY.signatura) InsLin([980l],chr(lnPorPol+1),[],[AR]) endif endif InsLin([LOKl],chr(recno()+47),[],AR2C_SVAZKY.signatura) InsLin([NOSa],chr(recno()+47),[],nvl(left(AR2C_SVAZKY.vyznam,10),[])) endscan do OKMARC with 'OKLinear'
lcRecord=lcRecord+SaveUniTag()+crlf sele OKLinear Zap sele AR2C if mod(recno(),1000)=0 =strtofile(lcRecord,lcPathS+"arch_tag.tag",1) lcRecord=[] endif wait wind nowa str(recno()) endscan =strtofile(lcRecord,lcPathS+"arch_tag.tag",1) lnMinut=(second()-lnCas)/60 ?("Opearace dokončena za "+allt(str(lnMinut,4,2))+" minut") MessageBox("Pokud během chodu nevyskočila žádná chyba, byl úspešsně vytvoren soubor arch_tag.tag, a nyní proveďte IMPORT"+; " pomocí katalogizace CLAVIUS! Po jehos skončení proveďte synchronizaci SVAZKů opětovný spuštěním tohoto programu a zvolte volbu "+; " nevytvářet soubor!") endif && konec vytvoreni SOUBORU ***** tady probehne IMPORT, ale uzivatelsky if lnAnswer=7 &&synchronizace SVAZKů lnAnswer=MessageBox("Opravdu si přejete SYNCHRONIZOVAT SVAZKY ??!! Byl dokončen IMPORT souboru ??!!",1+32+256,"Chcete SYNCHRINIZOVAT") if lnAnswer=1 &&OK lnCas=second() ***** nasledu SYNCH SVAZKU s novymy TCISLy Pohled("update TITULY n set n.tcislo="+; "(select ABS(tcislo) from TITULY s where s.tcislo<0 and s.special1=n.special1 and (s.druhdoku='AZ' or s.druhdoku='AM') and rownum=1) "+; " where tcislo>0 and exists (select tcislo from TITULY s where s.tcislo<0 and s.special1=n.special1 and (s.druhdoku='AZ' or s.druhdoku='AM') and rownum=1)") Pohled("update LINEAR n set n.tcislo="+; "(select ABS(tcislo) from LINEAR s where s.tcislo<0 and s.pole='001' and s.hodnota=n.hodnota and rownum=1) "+; " where tcislo>0 and exists "+; "(select ABS(tcislo) from LINEAR s where s.tcislo<0 and s.pole='001' and s.hodnota=n.hodnota and rownum=1)") lnMinut=(second()-lnCas)/60 ?("Opearace dokončena za "+allt(str(lnMinut,4,2))+" minut") MessageBox("Pokud během chodu nevyskočila žádná chyba, byly SVAZKY úspešsně SYNCHRONIZOVÁNY, uvidíte je v záznamech!") else MessageBox("Operace SYNCHRONIZACE zrušena uživatelem !!!") endif && konec SYNCH svazku
else if lnAnswer<>6 MessageBox("Celá operace zrušena uživatelem !!!") endif endif && cela operace zrusena Procedure inslin (tcPole,tcPorpole,tcIndik1,tcHodnota) if !empty(tcHodnota) and !isnull(tcHodnota) tcHodnota=iif(type([tcHodnota])=[N],allt(Str(tcHodnota)),allt(tcHodnota)) insert into OKLinear (tcislo,pole,porpole,indik1,indik2,nejiste,nrzn,hodnota,bigtext,unitext); values(val(AR2C.id_titul),tcPole,tcPorPole,tcIndik1,[],0,[],left(tcHodnota,40),subst(tcHodnot a,41),[]) endif endproc 3) SMAZÁNÍ DOČASNÝCH (POMOCNÝCH) DAT ARCHIVU ***********ODSTRANÍ ZAPORNÉ ŘÁDKY POTŘEBNÉ PRO SYNCH. lnAnswer=MessageBox("PŘEJETE PROVÉST PROMAZÁNÍ POMOCNÝCH DAT.",1+48+256,"CLAVIUS - IMPORT ARCHIV") if lnAnswer=1 && promazeme lnCas=second() *** smazeme zaporne hodnoty ?"Mažeme pomocná data z LINEARu - delete from linear where tcislo<0" Pohled ("delete from linear where tcislo<0") ?"Mažeme pomocná data z TITULů - delete from tituly where tcislo<0 " Pohled ("delete from tituly where tcislo<0") lnMinut=(second()-lnCas)/60 MessageBox("Opearace dokončena za "+allt(str(lnMinut,4,2))+" minut") endif
