Petr Šaloun and Dušan Chlapek

Transkript

2014
Proceedings of the 34th Annual
Database Conference
Edited by
Petr Šaloun
and
Dušan Chlapek
Demänovská dolina, Jasná,
Hotel Junior
Slovak Republic
September 25-27, 2014
http://www.datakon.cz
Petr Šaloun and Dušan Chlapek (Editors)
DATAKON 2014, sborník z konference
1. vydání
Určeno pro účastníky konference DATAKON 2014
elektronické vydání
151 stran
Vydává Vysoká škola báňská-Technická univerzita Ostrava,
v řadě Fakulty elektrotechniky a informatiky, 2014
Elektronická verze sborníku konference
ISBN 978-80-248-3545-7
Petr Šaloun and Dušan Chlapek (Ed.) DATAKON 2014
DATAKON
2014
sborník konference
Editoři
Petr Šaloun
Dušan Chlapek
Demänovská dolina – Jasná
Slovensko
25. - 27. září 2014
www.datakon.cz
Vydané: Vysokou školou báňskou-Technickou univerzitou Ostrava
Datakon 2014
1. vydání
Editoři
Petr Šaloun
VŠB-Technická univerzita Ostrava
katedra informatiky FEI
17. listopadu 15
70833 Ostrava-Poruba
Dušan Chlapek
Katedra informačních technologií
Vysoká škola ekonomická
Nám. W. Churchilla 4
130 67 Praha 3
Partneři vydání
Česká společnost pro kybernetiku a informatiku
Vema, a.s.
Fakulta informačních technologií Vysokého učení technického v Brně
Profinit, new frontier group
 Autoři příspěvků uvedení v obsahu, 2014
Každý příspěvek byl recenzován, recenzenti jsou členy programových výborů konferencí.
Vydává
Vysoká škola báňská-Technická univerzita Ostrava,
v řadě Fakulty elektrotechniky a informatiky, 2014
Elektronická verze sborníku konference
ISBN 978-80-248-3545-7
Partneři vydání
Česká společnost pro kybernetiku
a informatiku
Vema, a.s.
Fakulta informačních technologií
Vysokého učení technického
v Brně
DATAKON® je prestižní česká a slovenská konference s mezinárodní účastí
zaměřená na teoretické a technické základy, nejlepší postupy a vývojové trendy
v oblasti využití informačních technologií při budování informačních systémů
včetně výsledků jejich aplikace v praxi.
DATAKON® představuje ideální platformu pro výměnu zkušeností mezi
českými i zahraničními odborníky z řad dodavatelů informačních technologií,
jejich zákazníků a akademického světa.
DATAKON® oslovuje zkušené odborníky i nejlepší studenty.
DATAKON® is a high-profile traditional conference focused on theoretical and
technical background, best practices and development trends in deployment of
information technology for information systems development including
application results of described approaches in industry practice.
DATAKON® serves as an ideal platform for experience exchange among experts
of information technology products and services suppliers, their customers and
the academic community both Czech, Slovak and also foreign.
DATAKON® brings together researchers, professionals, and students.
Předmluva
DATAKON ® je prestižní česká a slovenská konference s mezinárodní účastí zaměřená na
teoretické a technické základy, nejlepší postupy a vývojové trendy v oblasti využití
informačních technologií při budování informačních systémů včetně výsledků jejich
aplikace v praxi. Hlavní témata konference Datakon 2014 jsou
 Big data,
 Open data,
 Linked data.
Tematické okruhy Datakonu 2014 nejsou výlučné, preferovány jsou standardní příspěvky,
případové studie a postery s vazbou na praxi a praktické použití.
 Architektury informačních systémů
 Cloud Computing
 Datové registry
 Dobývání znalostí
 Informační bezpečnost
 Integrace datových zdrojů
 Kvalita dat a zpracování neúplné informace
 Management znalostí a znalostní technologie
 Modelování procesů a služeb
 Multimediální, časová, časově prostorová a geografická data
 Nové trendy a moderní databázové technologie
 Servisně orientované architektury
 Sociální sítě na internetu
 Vyhledávání na webu
 XML technologie
 Zpracování rozsáhlých souborů dat
 Proudy dat
 Řídicí systémy v reálném čase
Obsah sborníku odpovídá programu konference DATAKON 2014, konané 25. - 27. září
2014 v hotelu Junior, Demänovská dolina – Jasná, Slovensko. Výběr příspěvků zajišťoval
programový výbor pro rok 2014 Všechny příspěvky byly posuzovány třemi nezávislými
recenzenty. Na letošním ročníku DATAKONu byla zařazena panelová diskuse Otevřená data
v samosprávě SR a ČR, kterou organizovali Ján Gondoľ (Ministerstvo vnútra SR), Dušan
Chlapek (FIS VŠE Praha).
Sborník příspěvků obsahuje texty pěti zvaných přednášek, čtyř přijatých standardních
příspěvků a tří posterů.
Závěrem chceme poděkovat všem, kteří se zasloužili o 34. ročník konference DATAKON
a této publikace. V prvé řadě chceme poděkovat autorům zvaných přednášek, standardních
příspěvků a posterů, za úsilí, které vynaložili při jejich přípravě. Rovněž bychom chtěli
poděkovat členům programového výboru za posouzení příspěvků a jejich nápady a práci při
přípravě programu konference, zejména děkujeme předsedovi řídícího výboru Jaroslavu
Pokornému za neutuchající nadšení a podporu všemu a všem, co s konferencí souvisí. Dále
chceme poděkovat partnerům konference za podporu, bez nichž by uspořádání konference
bylo obtížně realizovatelné. Velký dík patří také kolegům z organizačního výboru
konference Yvetě Geletičové, a zejména kolegům Tomáši Horváthovi a Štefenu Perovi,
kteří v rámci kolokace konferencí s ITAT zajistili místo a organizaci v Jasnej pod
Chopkom.
Petr Šaloun a Dušan Chlapek
předsedové programového výboru
Preface
DATAKON® is a high-profile traditional conference focused on theoretical and technical
background, best practices and development trends in deployment of information
technology for information systems development including application results of described
approaches in industry practice. The main topics of conference DATAKON 2014 are
 Big data,
 Open data,
 Linked data.
The other topics of conference DATAKON are mainly (but not only):
 Information systems architecture
 Cloud Computing
 Data mining
 Information security
 Data sources integration
 Data quality and incomplete information processing
 Knowledge management and technologies
 Process and service modeling
 Multimedia, time, time space and geographic data
 New trends and modern database technologies
 Service oriented architecture
 Social networks on the Internet
 Searching on the Web
 XML technology
 Very large data sets processing
 Real-time systems
The conference DATAKON 2014 was held on September 25th - 27th 2013 at hotel Junior,
Demänovská dolina – Jasná, Slovakia. The Proceedings follows the program of the
conference. All entries were judged by three independent reviewers, members of program
committee. This year DATAKON was open panel discussion Open data in local government
Slovak Republic and Czech Republic, which was organized by Ján Gondoľ (Ministry of
Interior SR) and Dušan Chlapek (University of Economics, Prague).
Proceedings contains texts of five invited lectures, four standard contributions and tree
posters.
Finally we want to thank everyone who contributed to the 34th annual conference
DATAKON and to this publication. First of all we want to thank the authors of invited
lectures, tutorials, standard contributions and case study for the effort they put forth in their
preparation. We would also like to thank the members of the program committee for their
reviews of contributions and their ideas and work in preparing the conference program,
especially we wish thank to Jaroslav Pokorný, Steering Committee chair, for his enthusiasm
and support. We would also like thank to the partners of the conference for their support. A
big thank to colleagues from the organizing committee of the conference, namely Yveta
Geletičová, and colleagues Tomáš Horváth and Štefan Pero from the ITAT conference
Organizing Committee for the preparation, help and care during the conference
DATAKON 2014 in Jasná pod Chopkom.
Petr Šaloun and Dušan Chlapek
Program Committee Chairs
Organizace konference
(Conference Organization)
Řídící výbor (Steering Committee)
Předseda (Chair):
Jaroslav Pokorný, UK Praha
Členové (Members): Mária Bieliková, STU Bratislava
Ján Genči, TU Košice
Petr Hujňák, Per Partes Consulting Praha
Dušan Chlapek, VŠE Praha
Karel Richta, ČVUT Praha
Jan Staudek, MU Brno
Petr Šaloun, VŠB-TU Ostrava
Jaroslav Zendulka, VUT Brno
Programový výbor (Program Committee)
Předsedové (Chairs): Petr Šaloun, VŠB-TU Ostrava
Dušan Chlapek, VŠE Praha
Členové (Members): Maria Bieliková, STU Bratislava
Miroslav Benešovský, NESS Europe Brno
Marie Duží, VŠB-TU Ostrava
Ján Genči, FEI TU Košice
Ivan Halaška, ČVUT Praha
Zdeněk Havlice, TU Košice
Tomáš Hruška, VUT Brno
Petr Hujňák, Per Partes Consulting Praha
Štefan Kovalík, ŽU Žilina
Jaroslav Král, UK Praha
Pavel Král, ZČU Plzeň
Petr Kučera, Komix s.r.o.
Aleš Limpouch, TopoL Software, s.r.o.
Karol Matiaško, ŽU Žilina
Martin Molhanec, ČVUT Praha
Jaroslav Pokorný, UK Praha
Lubomír Popelínský, MU Brno
Karel Richta, ČVUT Praha
Vojtěch Svátek, VŠE Praha
Henrieta Telepovská, FEI TU Košice
Michal Valenta, ČVUT Praha
Tomáš Vlk, ČVUT Praha
Peter Vojtáš, UK Praha
Jaroslav Zendulka, VUT Brno
Organizační výbor (Organization Committee)
Petr Šaloun, předseda, VŠB-TU Ostrava
Yveta Geletičová, VŠB-TU Ostrava
Tomáš Horváth a Štefan Pero (ITAT), UPJŠ Košice
DATAKON 2014 organizují (DATAKON 2014 is organized by)
Matematicko-fyzikální fakulta, UK Praha
Česká společnost pro systémovou integraci
Slovenská informatická společnost
Fakulta elektrotechniky a informatiky, VŠB-TU Ostrava
Partneři konference DATAKON 2014 (DATAKON 2014 Partners)
Česká společnost pro kybernetiku
a informatiku
Vema, a.s.
Fakulta informačních technologií
Vysokého učení technického
v Brně
Obsah
Zvané prezentace
Big Data: jejich ukládání, zpracování a použití
Jaroslav Pokorný ........................................................................................ 3
Otevřená a propojitelná data – metodiky, postupy, nástroje a praxe
Dušan Chlapek, Jakub Klímek, Jan Kučera, Martin Nečaský .................. 17
Na strastiplnej ceste k otvoreným päťhviezdičkovým údajom v Slovenskej
republike
Miroslav Líška .......................................................................................... 39
Skúsenosti so správou prepojených dát
Marek Šurek .............................................................................................. 53
Digitalizace artefaktů paměťových institucí
Petr Vršek ................................................................................................. 63
Vybrané příspěvky
Spracovanie viacslovných pomenovaní
Ján Genči, Martin Ološtiak ...................................................................... 73
Reprezentácia časových radov pomocou opakujúcich sa vzorov
Jakub Ševcech, Mária Bieliková ............................................................... 79
Extended Column Level Temporal Indexed Management System
Michal Kvet, Karol Matiaško, Monika Vajsová ....................................... 87
Úvod do vizualizácie softvéru
Kristián Šesták, Zdeněk Havlice ............................................................... 99
Postery
Webové služby v procese vyhodnocovania študentských zadaní
Miroslav Biňas ........................................................................................ 111
BOINC@Fiit – distribuovaný výpočtový systém
Peter Lacko, Juraj Vincúr, Martin Tibenský, Pavol Pidanič,
Juraj Petrík, Ján Kalmár, Ondej Jurčák, Radoslav Zápach ................... 121
P. Šaloun, D. Chlapek (eds.), DATAKON 2014, Jasná, 25.-27.9.2014
Databázový mirror jako nutná komponenta informační podpory při řízení
kontinuální výroby
Roman Danel, Lukáš Otte, David Johanides .......................................... 129
Rejstřík autorů ............................................................................................ 137
Zvané prezentace
Jaroslav POKORNÝ
Katedra softwarového inženýrství, MFF UK Praha
Malostranské nám. 25, 118 00 Praha
[email protected]
Abstrakt. V posledních letech je patrný vývoj a nasazování vysoce distribuovaných a
škálovatelných systémů pro zpracování dat v oblasti zvané Big Data. Nové
architektury zahrnují např. distribuované souborové systémy a NoSQL databáze. Na
druhé straně je zřejmé, že problémy Big Data, jako jsou složitost dat, rychlost jejich
vzniku a analytické požadavky, řeší tyto prostředky pouze částečně. To je patrné
zejména v síťovém prostředí, kde součástí Big Data bývá i podniková databáze a jsou
vyžadovány ACID vlastnosti, které NoSQL databáze obecně negarantují. Vývoj tzv.
NewSQL databází je tedy aktuální, objevuje se dokonce nová kategorie databází – Big
Data Management Systems. V přednášce budeme diskutovat tyto trendy a
vyhodnotíme některé současné přístupy ke zpracování a řízení Big Data.
Klíčová slova: Big Data, Big Analytics, NoSQL, NewSQL, Hadoop
1 Úvod
Efektivní využívání systémů zahrnujících zpracování velkých objemů dat vyžaduje
v mnoha aplikačních scénářích odpovídající nástroje pro ukládání a zpracování těchto dat
na nízké úrovni a analytické nástroje ve vyšších úrovních. Zdá se, že z pohledu uživatele je
nejdůležitějším aspektem zpracování velkých objemů dat na počítači právě jejich analýza,
jak se dnes říká - Big Analytics. Bohužel, velké kolekce dat obsahují data v různých
formátech, např., relační tabulky, XML data, textová data, multimediální data nebo RDF
trojice, což může působit potíže při jejich zpracování algoritmy pro dolování dat. Rovněž
zvyšující se objem dat v úložišti nebo počet uživatelů tohoto úložiště vyžaduje spolehlivé
řešení škálování v těchto dynamických prostředích a pokročilejší, než nabízejí tradiční
databázové architektury.
Je zřejmé, že Big Analytics se provádí i nad velkým množstvím transakčních dat
rozšířením metod používaných obvykle v technologii datových skladů (DW). Technologie
DW byla vždy zaměřena na strukturovaná data ve srovnání s mnohem bohatší variabilitou
typů dat, tak jak je dnes třeba pro Big Data. Analytické zpracování velkých objemů dat
proto vyžaduje nejen nové databázové architektury, ale také nové metody pro analýzu dat.
Pro skladování a zpracování velkého množství dat a řešení uvedených problémů mají
dnes uživatelé řadu možností:
 tradiční paralelní databázové systémy,
 distribuované souborové systémy a technologii Hadoop,
 datová úložiště klíč-hodnota (tzv. NoSQL databáze),
 nové databázové architektury (např. NewSQL databáze).
Distribuované souborové systémy uvažované zde, např. Hadoop Distributed File System
(HDFS) [26], se liší od tradičních síťových souborových systémů (např. v systému UNIX).
P. Šaloun, D. Chlapek (eds.), DATAKON 2014, Jasná, 25.-27.9.2014, pp. 3-16.
4
Používají např. rozdělování souborů a replikace. NoSQL databáze jsou relativně novým
typem databází, které byly iniciovány webovými společnostmi počátkem 20. století.
NewSQL databáze usilují poskytnout efektivní škálování (jako NoSQL databáze) a
udržovat garanci konzistence transakcí jako v tradičních relačních systémech řízení bází dat
(SŘBD). Jsou rovněž kompatibilní s SQL.
Příspěvek se zaměřuje na výzvy přicházející s technologií Big Data. Jeho cílem je dát do
souvislosti principy tradičních nástrojů pro zpracování dat se zpracováním a řízením
velkých objemů dat a ukázat některé alternativy v této oblasti. V souladu s dnešními
konvencemi budeme někdy (nepřesně) místo SŘBD hovořit o databázi.
V sekci 2 stručně popíšeme koncept Big Data, tj. vlastnosti, zpracování a analýzu
velkých objemů dat. Sekce 3 zmiňuje v této souvislosti dva typy databázových architektur:
tradiční univerzální a architekturu založenou na software Hadoop s implementací
frameworku MapReduce. V sekci 4 předkládáme stručný přehled technologií NoSQL
databází, zejména jejich datové modely, architektury, a zmíníme některé její představitele.
V sekci 5 vyhodnotíme různé přístupy k ukládání a správě Big Data s ohledem na Big
Analytics. Sekce 6 uvádí některé otevřené problémy související s Big Data představující
výzvy pro databázovou komunitu.
2 Big Data
O velkých objemech dat obvykle mluvíme, pokud je velikost datového souboru mimo
schopnosti současného systému pro jeho ukládání, zpracovávání, vyhledávání a správu.
McKinsey popisuje v [17] Big Data jako velké zásobárny nestrukturovaných a
strukturovaných údajů, které mohou být získány, sdělovány, agregovány, uloženy a
analyzovány, a které se nyní stávají součástí každého sektoru či funkce světové ekonomiky.
Objem dat vytvořených jak uvnitř korporace tak za jejími hranicemi prostřednictvím Webu,
prostřednictvím mobilních zařízení, IT infrastruktury a dalších zdrojů, roste každým rok
exponenciálně [15].
Při vývoji paradigmatu Big Data hraje významnou roli Web. Textový obsah Webu je
zdrojem, který chtějí uživatelé snadno použít pro konzultace a vyhledávání. Výzvy v této
oblasti zahrnují zejména sumarizaci dokumentů, personalizované vyhledávání a
doporučující systémy. Sociální struktury tvořené přes Web, reprezentované hlavně on-line
aplikacemi sociálních sítí, jako jsou Facebook, LinkedIn nebo Twitter, intenzivně přispívají
k Big Data. Tyto sítě umožňují interakce uživatelů v rámci platformy sociální sítě a
vytvářejí rozsáhlé a dynamické grafy vyžadující speciální datové struktury a prostředky pro
dotazování.
Big data se objevují v těchto kontextech:
 velké kolekce dat v tradičních DW nebo databázích,
 podniková data z velkých newebových společností, které pracují s internetovými
transakcemi,
 data z velkých webových společností, které poskytují sociální sítě a média,
 data získaná a/nebo zasílaná prostřednictvím mobilních zařízení,
 proudy dat generované vzdálenými senzory a dalším IT hardwarem,
 datové archivy z e-science (výpočetní biologie, bioinformatika, genomika a
astronomie),
 současný rozvoj Internetu věcí vedoucí k velkému zatížení sítí následnému zvýšení
nároků na ukládání odpovídajících dat.
Zvaná přednáška
5
Typickým rysem velkých objemů dat je absence jejich charakterizace pomocí schématu dat,
což dělá problémy, když chceme heterogenní kolekce dat integrovat.
2.1 Charakteristiky Big Data
Big Big Data jsou nejčastěji charakterizovány několika V:
 Volume - data škálovaná v rozmezí TB až PB a více,
 Velocity - jak rychle se data se vytváří a jak rychle musí být pro splnění požadavku
zpracována,
 Variety - data jsou v mnoha formátech - strukturovaná, nestrukturovaná, semistrukturovaná, textová, média atd.,
 Veracity – věrohodnost (spolehlivosti, pravdivosti) a predikabilita dat, která jsou ze
své podstaty většinou nepřesná.
První tři V uvádí Gartner v [16], další V přidal D. Snow na svém blogu1 v roce 2012.
Různost typů dat a rychlost jejich vytváření vlastně pracují proti jejich věrohodnosti.
Snižují schopnost čistit data před jejich analýzou a následným rozhodováním. Páté V
zavedli autoři [11]:
 Value - užitečná a cenná data pro byznys.
Vize hodnoty dat zahrnuje vytváření sociální a ekonomické přidané hodnoty na základě
inteligentního využívání, řízení a znovuvyužití datových zdrojů s cílem zvýšit Business
Intelligence (BI).
V literatuře se objevují i další V:
 Vizualization - vizuální reprezentace dat a pohledy pro rozhodování,
 Variability - různé významy/kontexty spojené s danou množinou dat,
 Volatility - jak dlouho data jsou platná a jak dlouho by měla být uložena (od kdy již
konkrétní data nejsou pro současnou analýzu relevantní).
Skutečná otázka zní, zda některá V jsou opravdu definiční a nejen matoucí. Např.
spolehlivost vyjadřuje kvalitu veškerých dat a není tedy pro Big Data definiční vlastností.
Když používáme definici Gardner "Big data jsou velkoobjemová, rychle vznikající a
různorodá informační aktiva, která vyžadují nákladově efektivní, inovativní formy
zpracování informací pro lepší porozumění a rozhodování", vidíme, že zahrnutá 3 V tvoří
pouhou třetinu definice! Druhá část definice se zaměřuje k využití možností infrastruktury a
technologií, resp. toho nejlepší z nich. Společná definice velkých objemů dat je stále
nejasná [27].
2.2 Zpracování Big Data a Big Analytics
Velký objem je nejen problémem pro ukládání dat, ale ovlivňuje také Big Analytics.
S nárůstem složitosti dat je rovněž složitější i jejich analýza. Chcete-li využívat Big Data,
musíme škálovat jak infrastrukturu, tak i standardní techniky jejich zpracování. Zpracování
Big dat zahrnuje interaktivní zpracování, zpracování dat v klidu (at rest) pro podporu
rozhodování a zpracování dat v pohybu (in motion) v reálném čase, což se obvykle provádí
pomocí systémů řízení proudů dat (např. [19]). Nedílnou dimenzí dat v proudu je čas, což
ovlivňuje jejich zpracování. Analytik nemůže data poté, co proud proběhl, znovu
analyzovat. Rychlost může být také problémem, protože hodnota analýzy (a často i dat) se
snižuje s časem. Pokud je potřeba více průchodů proudu, údaje musí být vloženy do DW,
1
http://dsnowondb2.blogspot.cz/
6
kde lze provést další analýzy. Data tak mohou být uskladněna relativně tradičním způsobem
nebo jsou uložena a zpracována pomocí levných systémů, jako jsou např. NoSQL databáze.
Big Analytics slouží k proměňování informací ve znalosti pomocí kombinace stávajících
a nových přístupů. K souvisejícím technologiím patří:
 správa dat (uvažující nejistotu, zpracování dotazu v téměř reálném čase, extrakci
informací, explicitní správu časové dimenze),
 nové programovací modely,
 strojové učení a statistické metody,
 komponentové architektury systémů ukládání a zpracování dat,
 vizualizace informací.
Big Data jsou často zmiňována pouze v souvislosti s BI, nicméně nejen vývojáři BI, ale
také vědci v e-science analyzují velké kolekce dat. Výzvou pro počítačové odborníky nebo
datové vědce je poskytnout těmto lidem nástroje, které mohou efektivně provádět složitou
analytiku s přihlédnutím ke zvláštní povaze zpracování velkých objemů dat. Je důležité
zdůraznit, že Big Analytics nezahrnuje pouze fáze analýzy a modelování. V úvahu se často
bere zkreslený kontext, heterogenita dat a interpretace výsledků. Všechny tyto aspekty
ovlivňují škálovatelné strategie a algoritmy, proto jsou zapotřebí účinnější kroky
předzpracování (filtrování a integrace) a pokročilé paralelní výpočetní prostředí.
Kromě těchto spíše klasických témat dolování velkých objemů dat se v posledních letech
objevily další zajímavé problémy, např. rozpoznávání pojmenovaných entit. Aktuální je i
analýza názorů a mínění (např. pozitivní, negativní, neutrální) a jejich dolování (sentiment
analysis) jako témata využívající metody vyhledávání informací a analýzy webových dat.
Specifickým problémem je hledání a charakterizace rozporů na základě názorů a mínění.
Porovnávání vzorů grafů se běžně používá při analýze sociálních sítí, kde grafy např.
zahrnují miliardu uživatelů a stovky miliard odkazů. V každém případě pocházejí hlavní
problémy současných technik dolování dat používaných pro Big Data z jejich nedostatečné
škálovatelnosti a paralelizace.
3 Architektury ukládání dat
V této sekci ukážeme dvě základní architektury pro správu a ukládání dat: tradiční
univerzální architekturu, na které jsou založeny běžné komerční databázové produkty, a
architekturu softwarového zásobníku Hadooop, dnes nejznámějšího přístupu v souvislosti
s Big Data.
Tabulka 1. SŘBD s pětivrstvou hierarchií zobrazení
L5
L4
L3
L2
L1
Úroveň abstrakce
neprocedurální
nebo algebraický přístup
záznamově-orientovaný
navigační přístup
management záznamů a
přístupových cest
Objekty
tabulky, pohledy, řádky
Pomocná zobrazení dat
popis logického schématu
záznamy, množiny,
hierarchie, sítě
fyzické záznamy,
přístupové cesty
řízení propagace
management souborů
segmenty, stránky
soubory, bloky
popis logického a fyzického
schématu
tabulky volného prostoru,
tabulky překladů
databázových klíčů
buffery, tabulky stránek
direktoráře
Zvaná přednáška
7
3.1 Univerzální architektura SŘBD
Tabulka 1 ukazuje univerzální architekturu SŘBD založenou na modelu mapování pěti
vrstvách abstrakce [14]. V praxi relačních SŘBD je architektura zapouzdřena spolu
s použitím jazyka SQL v L1. Stejný model může být použit v případě distribuovaných
databází na každém uzlu sítě spolu s propojovací vrstvou odpovědnou za komunikaci,
adaptace nebo zprostředkovatelské služby. Typický paralelní relační SŘBD s architekturou
"sdílení ničeho" lze rovněž popsat pomocí této architektury. Vrstvy L1-L4 jsou přítomny
obvykle na každém počítači v klastru. Typickou vlastností univerzální architektury je, že
uživatelé mohou vidět pouze nejvyšší (SQL) vrstvu. Počet vrstev v univerzální architektuře
je často redukován a vede ke známému třívrstvému modelu.
Vývoj ve 3. tisíciletí ukázal, že běžné databázové technologie (jak centralizované tak
distribuované) nejsou pro správu datových zdrojů generujících Big Data v rozsahu Webu
vhodné. Snad nejdůležitějším problémem tradičních databází v prostředí Webu je obtížná
škálovatelnost. Vertikální škálování (nazývané angl. scale-up), tj. přidávání nových a
drahých velkých serverů, bylo nahrazeno rozdělením databáze na více levných strojů
přidávaných dynamicky k síti. Toto tzv. horizontální škálování (také angl.. scale-out) může
zřejmě zajistit škálovatelnost účinnějším a levnějším způsobem. Data jsou distribuována
horizontálně v síti, což v případě tabulkových dat znamená do skupin řádků. Vertikální
dělení nebo kombinace obou stylů jsou používány také. Horizontální distribuce dat
umožňuje rozdělit výpočet do souběžně zpracovávaných úkolů. Ukážeme, že umístit více
segmentů dat na různých strojích je snadnější implementovat pro NoSQL databáze, protože
integrita, kromě té programované v aplikaci, není vyžadována. Horizontální distribuce
používá architekturu "sdílení ničeho", tj. každý server má svá vlastní data a procesor. Více
databází je v tomto případě sjednoceno i na aplikační vrstvě. Může být použito i MPP, tedy
jeden SŘBD s distribuovanou pamětí.
3.2
Softwarový zásobník Hadoop
Typicky vrstvená architektura softwaru Hadoop často používaná v NoSQL prostředí má
také třívrstvý model, vypadá však trochu jinak než v tradičních databázích. Open source
software Hadoop je založen na frameworku MapReduce [10] a HDFS. Hadoop se používá
jako vysoce škálovatelná MapReduce platforma pro aplikace náročné na data. Složitost
úloh pro zpracování dat v těchto architekturách je díky MapReduce minimalizována. Je
zřejmé, že přístup není snadno realizovatelný pro libovolný algoritmus a libovolný
programovací jazyk. MapReduce inspirovaný funkcionálním programováním umožňuje
realizovat přirozeným způsobem např. násobení řídkých matic vektorem. Na druhé straně
efektivní provádění relační operace spojení v MapReduce vyžaduje zvláštní přístup jak
k distribuci dat, tak k indexování (viz [23]). Ve verzi Apache Software Foundation se nad
HDFS NoSQL nachází databáze HBase2 a další komponenty (viz tabulku 2 vytvořenou na
základě [3]). Existují i další podobné architektury stojící na HDFS, např. BDAS (Berkeley
Data Analytics Stack)3 vhodný zvláště pro Big Analytics.
Významný rozdíl softwarového zásobníku Hadoop od univerzální SŘBD architektury je,
že v jednotlivých vrstvách můžeme k datům přistupovat pomocí tří různých sad nástrojů.
Střední vrstva - Hadoop MapReduce systémový server slouží pro dávkovou analytiku
s úlohami MapReduce (M/R). K dispozici je datové úložiště HBase jako vrstva založená na
datovém modelu klíč-hodnota (viz Sekce 4) s operacemi Get/Put na vstupu. Z nevyšší
2
3
https://hbase.apache.org/
https://amplab.cs.berkeley.edu/software/
8
vrstvy jsou pro uživatele k dispozici jazyky vyšší úrovně HiveQL [29], PigLatin [12] a Jaql
[2]. Jazyk HiveQL je podobný SQL a umožňuje realizovat neprocedurální datovou
analytiku (s konstruktem SELECT-FROM-GROUP BY). Jaql je deklarativní skriptovací
jazyk pro analýzu velkých kolekcí semistrukturovaných dat. Využití deklarativních jazyků
snižuje velikost kódu řádově a umožňuje distribuované nebo paralelní provedení
požadavků. Pig Latin není deklarativní, programy v něm jsou sekvence přiřazení podobné
prováděcím plánům známým z relačních SŘBD.
Tabulka 2. Třívrstvý softwarový zásobník Hadoop ve verzi Apache Software Foundation
L5
L2-L4
L1
Úroveň abstrakce
neprocedurální přístup
záznamově-orientovaný
navigační přístup
management záznamů a
přístupových cest
řízení propagace
management souborů
Data processing
HiveQL/PigLatin/Jaql
M/R úlohy
Hadoop MapReduce
Dataflow Layer
Operace Get/Put
HBase uložiště typu
klíč-hodnota
HDFS
4 NoSQL databáze
Pro ukládání a zpracování velkých kolekcí dat jsou často používány NoSQL databáze.
NoSQL znamená "ne pouze SQL" nebo "žádné SQL vůbec", což dělá tuto kategorii
databází velmi různorodou a ne příliš jasně specifikovatelnou. NoSQL databáze, jejichž
vývoj začíná od konce 90. let, poskytují v porovnání s tradičními relačními databázemi
jednodušší škálovatelnost a vyšší výkon. Popíšeme stručně jejich datové modely,
identifikujeme schopnosti transakčního zpracování s následnou diskusí jejich použitelnosti
pro zpracování Big Data. Detailnější diskusi NoSQL je věnován v české literatuře např.
článek [20], ve slovenštině [28].
4.1 Datové modely používané v NoSQL databázích
To, co je hlavní klasických přístupů k databázím - (logický) datový model - je v NoSQL
databázích popsáno spíše intuitivně, bez jakýchkoliv formálních základů. Terminologie
NoSQL je také velmi rozmanitá a rozdíl mezi konceptuálním a databázovým pohledem na
data je většinou rozmazaný.
Nejjednodušší NoSQL databáze nazývané uložiště typu klíč-hodnota obsahují množinu
dvojic (klíč, hodnota). Klíč jednoznačně identifikuje hodnotu (typicky řetězec, ale také
ukazatel, kde je hodnota uložena). Hodnota může být dokonce seznamem dvojic (jméno,
hodnota) (např. v Redis4). Operace pro přístup k datům, typicky get a put, fungují pouze
prostřednictvím klíče. Ačkoliv jde o velmi efektivní a škálovatelný přístup v implementaci,
nevýhoda příliš jednoduchého modelu dat může být pro takové databáze podstatná. Nejsou
ovšem nutné NULL hodnoty, neboť ve všech případech tyto databáze nepoužívají schéma.
Ve složitějších přístupech ukládá NoSQL databáze množinu dvojic (jméno, hodnota) do
skupiny, tj. řádku adresovaného pomocí klíče. Pak mluvíme o sloupcově-orientované
NoSQL databáze. Do skupin mohou být přidávány nové sloupce, tj. dvojice (jméno,
4
https://hbase.apache.org/
Zvaná přednáška
9
hodnota). K dispozici je i další úroveň struktury nazývaná, např. v Cassandra5,
supersloupec. Supersloupec obsahuje vnořené (pod)sloupce. Přístup k datům pomocí
operací get a put je vylepšen použitím názvů sloupců.
Nejobecnější datové modely patří do dokumentově-orientovaných NoSQL databází. Jsou
stejné jako úložiště typu klíč-hodnota, párují však každý klíč s libovolně složitou datovou
strukturou připomínající semistrukturovaný dokument. Pro prezentaci těchto datových
struktur je obvykle používán formát JSON (JavaScript Object Notation). JSON je binární a
typovaný datový model, který podporuje základní datové typy a objekty – neuspořádané
množiny dvojic (jméno, hodnota), přičemž hodnota může být strukturovaná (pole). JSON je
podobný XML, je ale menší, rychlejší a jednodušší pro parsování než XML. CouchDB6 je
založen na JSON. MongoDB7 používá BSON (binární JSON). Jeho typy tvoří
podmnožinou typů JSON. Dotazování nad daty v dokumentu je možné i jinými způsoby
než pomocí klíče (nad výsledky je možné provádět operace selekce a projekce).
Zdá se, že všechny uvedené datové modely jsou v podstatě typu klíč-hodnota. Odlišují se
především v možnostech agregace dvojic (klíč, hodnota) a zpřístupňování těchto hodnot.
Nejznámější NoSQL databáze pak mohou být podle použitého datového modelu
klasifikovány jako:
 úložiště typu klíč-hodnota: SimpleDB8, Redis, Memcached9, Dynamo10,
Voldemort11,
 sloupcově-orientované: BigTable [7], HBase, HyperTable12, CASSANDRA,
PNUTS [8],
 dokumentově-orientované: MongoDB, CouchDB.
Rovněž grafové databáze (např. [24]) jsou často považovány za kategorii NoSQL. Jejich
datové modely se liší podle typu grafu (orientované, ohodnocené, s atributy uzlů a hran,
multigrafy, hypergrafy). Jejich nativní implementace umožňují k uzlu najít rychle jeho
sousedy, využívají speciální metody indexace. Využívají se i různé strategie rozdělování
grafu v distribuovaném prostředí vhodné pro velké grafy (Big Graphs), grafové dotazovací
jazyky určené pro jednotlivé typy grafů a efektivní metody vyhodnocování dotazů
(průchody grafem, dotazy na hledání podgrafů a nadgrafů, podobnost grafů apod.).
Z četných dostupných produktů grafových SŘBD jmenujme alespoň Neo4j13 a
InfiniteGraph14.
Některé NoSQL databáze jsou databáze typu in-memory, což znamená, že abychom
dosáhli rychlejší přístup, je většina dat uložena ve vnitřní paměti počítače. Nejrychlejší
NoSQL úložiště, jako Redis a Memcached, jsou omezeny celé na vnitřní paměť, na druhé
straně zachovávají perzistenci na disku.
Seznam NoSQL databází popsaný na webové stránce15 obsahuje 150 položek, včetně
objektově-orientovaných, XML, grafových a dalších.
5
http://cassandra.apache.org/
http://couchdb.apache.org/
7 https://www.mongodb.org/
8 http://aws.amazon.com/simpledb/
9 http://memcached.org/
10 http://aws.amazon.com/dynamodb/
11 http://www.project-voldemort.com/voldemort/
12 http://hypertable.org/
13 http://www.neo4j.org/
6
14
http://www.objectivity.com/infinitegraph
15
http://nosql-database.org/
10
4.2 Zpracování transakcí v NoSQL databázích
V komunitě NoSQL databází je zvláštní pozornost zaměřena na konzistenci dat. Transakční
zpracování v tradičních relačních SŘBD je založeno na vlastnostech ACID. Konzistenci
v těchto databázích říkáme silná konzistence. V NoSQL databázích nejsou vlastnosti ACID
realizovány v plném rozsahu, databáze může být jen případně nebo slabě konzistentní.
V distribuovaných architekturách pro ukládání a zpracování dat se uvažuje trojice
požadavků: konzistence (C), dostupnost (A) a tolerance k rozdělení sítě (P), krátce CAP.
 Konzistence znamená, že pokud jsou data zapsána, každý, kdo čte z databáze, bude
vždy vidět nejnovější verzi dat. To je vlastně ekvivalentní mít jedinou
aktualizovanou kopii dat. Pojem se liší od konzistence v ACID. C v CAP je ostře
menší než C v ACID.
 Dostupnost znamená, že můžeme vždy očekávat, že každá operace obdržená
nechybujícím uzlem musí vést k obdržení výsledku (nebo chyby). Vysoká
dostupnost se obvykle dociluje pomocí velkého počtu fyzických serverů, které se
prostřednictvím sdílení dat mezi databázovými uzly a replikacemi tváří jako jedna
databáze.
 Tolerance k rozdělení sítě znamená, že z databáze lze stále číst a zapisovat do ní, i
když některé její části jsou v případě chyby sítě nepřístupné.
Podle teorému CAP [4], [13] je pro jakýkoliv systém sdílení dat nemožné všechny tyto
tři požadavky současně zajistit. Zvláště v internetových aplikací založených na
horizontálním škálování a předpokladu P je třeba se rozhodnout mezi C a A. Tj. nastávají
tyto případy:
1. C je klíčová a A je maximalizována. Výhodou silné konzistence, což připomíná
ACID transakce, znamená vývoj aplikací a řízení správy datových služeb mnohem
jednodušším způsobem. Jinak musí být implementována složitá aplikační logika,
která detekuje a řeší nekonzistence.
2. Prioritu má A a maximalizováno je C. Dát přednost A má spíše ekonomické
opodstatnění. Nedostupnost služby totiž může znamenat finanční ztráty
(připomeňme např. současné požadavky na garanci dostupnosti 99,9 %!).
V nespolehlivém systému založeném na teorému CAP nelze A plně zaručit. Pro její
zvýšení je nutné rozvolnit C. Korporátní cloudové databáze preferují C nad A a P.
Tabulka 3 ukazuje, jak různé NoSQL databáze řeší tyto problémy.
Tabulka 3. Preference konzistence a dostupnosti
CP
AP
Redis, BigTable, HBase, HyperTable, MongoDB
Dynamo, Voldemort, CASSANDRA, Memcached, PNUTS, CouchDB
Současné transakční modely používané ve webových distribuovaných replikovaných
databázích využívají vlastností BASE (Basically Available, Soft state, Eventually
consistent) [22]. Dostupnost v BASE odpovídá dostupnosti v CAP teorému. Aplikace
pracuje v podstatě po celou dobu (B), nemusí být konzistentní po celou dobu (S), ale
paměťový systém zaručuje pro případ, že žádné nové aktualizace nejsou s objektu
prováděny, že všechny přístupy k objektu vrátí nakonec poslední aktualizované hodnoty
(E). Simple DB např. potvrdí klientovi zápis před tím, než je zápis rozšířen do všech replik.
Jinými slovy řečeno, pokud opustíme silnou konzistenci, můžeme dosáhnout lepší
dostupnost, což významně zlepší škálovatelnost databáze. To může být v souladu
s databázovou praxi, kde jsou ACID transakce také požadovány pouze v určitých
případech. Ve známém příkladu s bankomaty by jistě měla mít přednost silná konzistence,
Zvaná přednáška
11
v praxi je však dostupnost služby přednější. Podobně v on-line sociálních sítí je určité
množství chyb v datech přípustné.
Analyzujeme-li NoSQL databáze můžeme najít i sofistikovanější přístupy ke
konzistenci:
 laditelná konzistence (např. v Cassandra),
 nastavitelná konzistence (např. CP nebo AP v NoSQL databázi firmy Oracle).
Laditelná konzistence znamená, že její stupeň může být ovlivněn vývojářem aplikace.
Pro operaci čtení nebo zápisu pak klientská aplikace rozhodne, jak konzistentní by měla
požadovaná data být. To umožňuje použít SŘBD Cassandra v aplikacích se zpracováním
transakcí v reálném čase.
Přijetí CAP teorému znamená, že návrh distribuovaného systému vyžaduje hlubší přístup
závislý na aplikacích a technických podmínkách. CAP např. ignoruje latenci, která je
s rozdělením sítě nedílně spjata. Problematikou teorému CAP, jeho mnohdy chybnými
intepretacemi a použitím v různých prostředích se zabývá článek [5]. Např. pro zpracování
velkých objemů dat na počítači v sítí datových center, jsou poruchy v síti minimalizovány.
Pak můžeme s vysokou pravděpodobností dosáhnout jak vysoké C tak P.
NoSQL lze vhodně použít pro nerelační distribuované systémy, které se nepokoušejí
poskytovat ACID záruky.
5 Big Data s NoSQL, Hadoop a nové architektury
V této kapitole se pokusíme analyzovat klady a zápory diskutovaných nástrojů v kontextu
Big Data a ukážeme další možnosti některých současných přístupů.
5.1 Použitelnost NoSQL databází
Použitelnost NoSQL databází je úzce spjata s neobvyklými a často nevhodnými jevy těchto
nástrojů:
 mají malou nebo žádnou podporu pro modelování dat, vývojáři tedy nevytvářejí
logický datový model,
 návrh databáze je řízený spíše dotazem,
 data nejsou omezena integritními omezeními,
 v různých aplikacích mají rozdílné chování,
 neexistuje pro ně standardní dotazovací jazyk,
 některé z nich jsou vyspělejší než jiné, ale každý z nich se snaží řešit podobné
problémy,
 migrace z jednoho systému do druhého může být složitá.
I když patří do jedné kategorie, mohou být dva NoSQL nástroje velmi odlišné. Např.
CouchDB používá dotazovací jazyk nízké úrovně a škálovatelnost prostřednictvím
replikací. Mongo má bohatý deklarativní dotazovací jazyk a škálovatelnosti dosahuje
prostřednictvím horizontální distribuce dat.
NoSQL databáze může být užitečná v aplikacích, které nevyžadují transakční sémantiku,
např. adresáře, blogy, nebo systémy řízení obsahu (CMS). Jsou rovněž vhodné pro
 indexování velkého počet dokumentů,
 pro provoz stránek na webových místech s vysokým provozem,
 doručování médií proudovým způsobem,
 správu dat v aplikacích sociálních sítí.
12
NoSQL databáze může být také dobrou platformou pro Big Analytics, např. pro analýzu
velkých objemů dat v reálném čase. Např. analýza webových logů a analýza proudů
kliknutí patří k dobře paralelizovatelným problémům, které lze s NoSQL databázemi řešit.
Je to možné z řady důvodů:
 prosazování schémat a zamykání na úrovni řádků jak je běžné v relačních SŘBD
zbytečně komplikuje tyto aplikace,
 absence vlastností ACID umožňuje výrazné zrychlení a decentralizaci NoSQL
databází.
Naopak nevhodné jsou NoSQL databáze pro aplikace vyžadující funkce běžné na
podnikové úrovně (ACID, bezpečnost a další funkčnost technologie relačních SŘBD).
Např. sloupcově-orientované NoSQL databáze nejsou vhodné pro
 většinu aplikací DW/BI,
 a mnoho tradičních webových aplikací.
Mají málo funkcí pro ad-hoc dotazování a analýzu, dokonce i jednoduchý dotaz
vyžaduje značné zkušenosti s programováním. Např. HBase umožňuje rychlé analytické
dotazy, jde to ale pouze na úrovni sloupce.
Problémy jsou ale i na druhé straně. Běžně používané nástroje BI obvykle neposkytují
připojení k NoSQL.
5.2 Použitelnost Hadoopu
Mnoho databází NoSQL je postaveno na vrcholu jádra Hadoop a jejich výkon tak závisí na
M/R úlohách. MapReduce je technika stále velmi jednoduchá ve srovnání s těmi, které se
používají v oblasti distribuovaných databází. MapReduce se dobře hodí pro aplikace, které
analyzují prvky velkého datového souboru nezávisle; nicméně aplikace, jejichž přístupy
k datům jsou složitější, musí být postavena na několika voláních kroků metodami Map a
Reduce. Výkon takového návrhu je závislý na celkové strategii algoritmu, jakož i na povaze
a kvalitě bezprostřední reprezentace dat a jejich uložení v těchto krocích. Nové výzvy pro
systémy založené na MapReduce představují např. i složité výpočty v aplikacích e-science.
Protože vědecké údaje je často velmi nepravidelně rozložená a složitost runtime úlohy
reduktoru je obvykle vysoká, výsledné zpracování M/R úloh nemusí být příliš efektivní.
MapReduce není také vhodný pro ad hoc analýzy, ale spíše pro organizované zpracování
dat.
Proti MapReduce mluví více důvodů. Big Analytics vyžaduje často iteracé, které se jen
těžko dosahují v NoSQL databáze založeném na MapReduce. V důsledku toho se objevují
zajímavé úpravy, např. framework HaLoop [6], který se podporuje iterace. Samotný
Hadoop je vhodný spíše pro podporu rozhodování.
Problémy s NoSQL se týkají celé jejich architekturu. M. Stonebraker 16 poukazuje na to,
že softwarový zásobník Hadoop má špatný výkon s výjimkou případů, kdy je požadavek
"triviálně paralelní". Důvody pro to mají zázemí v neexistenci indexování, ve velmi
neefektivních operacích spojení v Hadoop vrstvě, "odesílání dat k dotazu" a nikoliv
"odeslání dotazu k datům". Jiným kritizovaným příkladem je Couchbase17, která kopíruje
celý dokument, pokud se změní pouze jeho malá část.
V světě Big Data dominují NoSQL databáze spíše pro operační schopnosti v reálném
čase, tedy pracovní zátěž při interaktivním zpracování, kdy data jsou primárně sbírána a
ukládána. Další třída technologií řeší zátěž objevující se při analytickém zpracování Big
16
17
http://istc-bigdata.org/index.php/no-hadoop-the-future-of-the-hadoophdfs-stack/
http://www.couchbase.com/
Zvaná přednáška
13
Data (Big Analytics), a to s řešeními pomocí MPP systémů a MapReduce. NoSQL se sice
stávají populární i pro Big Analytics, ale se spoustou nevýhod, např., těžkopádným
výpočetním modelem, nízkoúrovňovými informacemi o zpracovávaných datech apod.
Výjimky se však vyskytují, např. knihovna Mahout18 realizovaná nad Hadoop nabízí
algoritmy automatického strojového učení a dolování dat pro hledání skrytých trendů a
další často netušené či dosud neuvažované možnosti.
Big Data jsou často spojována s cloud computingem. Cloud computing obecně znamená
výpočetní zdroje, které jsou dodávány jako služba, typicky přes internet. NoSQL databáze
používané v tomto prostředí jsou proto většinou pro skladování a zpracování velkých
objemů dat dostačující. Jestliže však uvažujeme složitější cloudové architektury, NoSQL
databáze by neměla být v cloudu jedinou možností.
5.3 Směrem k novým architekturám pro zpracování Big Data
Pro řešení výzvy Big Analytics se v posledních letech objevila nová generace
škálovatelných technologií pro správu dat. Systém pro správu velkých dat (Big Data
Management Systems - BDMS) je vysoce škálovatelná platforma, která podporuje
požadavky na zpracování velkých objemů dat. Zástupcem BDMS je systém ASTERIX
[30]. Jde o plně paralelní systém s možností uložení, přístupu, indexace, dotazování,
analýzy a publikace velkého množství semistrukturovaných dat. Jeho architektura
znázorněna v tabulce 4 je podobná architektuře z tabulky 2, ale s vlastní spodní vrstvou
zvanou Hyracks, která řídí paralelní datové výpočty. Vrstva algebry Algebrics je uprostřed,
nad ní je paralelní systém pro řízení dat ASTERIX. ASTERIX QL [1] je jazyk umožňující
skládání operací (připomíná XQuery), který pro analytické účely používá speciální
techniky, např. operaci fuzzy spojení. Softwarový zásobník Asterix zahrnuje rovněž vrstvu
pro kompatibilitu s Hadoop, software Pregelix pro analýzu grafů a další funkce.
Tabulka 4. Třívrstvý softwarový zásobník Asterix
L5
Úroveň abstrakce
neprocedurální přístup
Asterix QL
L2-L4
algebraický přístup
ASTERIX
SŘBD
L1
management souborů
Zpracování dat
HiveQL, Piglet, …
kompilátory
vyšších PL
M/R úlohy Pregel úlohy
Algebricks
Hadoop M/R
Pregelix
algebraická
kompatibilita
vrstva
datová paralelní platforma Hyracks
Hyrack
úlohy
Vývoj NoSQL databází v mnoha případech dospěl do stavu, že potřeba SQL se stala
vážnější, než se na počátku jejich vývoje zdálo. Jedním z řešení je tedy poskytnout nad
NoSQL databází vrstvu s SQL. Jiná řešení navrhují zlepšení výkonu a škálovatelnosti
relačních databází. Kategorie paralelních databází nazvaná v r. 2011 NewSQL databáze19
zastřešuje oba tyto přístupy a vyznačuje se následujícími vlastnostmi:
 jsou škálovatelné horizontálně v architekturách „sdílení ničeho“,
18
19
http://mahout.apache.org/
http://451research.com/report-long?icid=1651
14
 rozdělení dat je transparentní,
 nadále poskytují záruku ACID,
 interakce aplikací s databází je primárně pomocí SQL (včetně operace spojení),
 pro řízení souběžného zpracování nepoužívají zámky,
 poskytují vyšší výkon než tradiční systémy.
NewSQL SŘBD lze kategorizovat jako
 obecné SŘBD: Spanner [9] a F1 [25], ClustrixDB20, NuoDB21, VoltDB22
 hybridy kombinující Hadoopa relační technologii: HadoopDB23 (paralelní systém
s konektory pro Hadoop), Vertica24,
 podporující více datových modelů: FoundationDB 25.
NewSQL SŘBD poskytují podstatně vyšší výkon a škálovatelnost ve srovnání
s tradičními SŘBD či Hadoop. Např. srovnání Hadoop a Vertica ukázalo, že vyhodnocení
dotazu pro Hadoop bylo pomalejší o 1-2 řády [18].
Hodně úspěchů některých řešení NewSQL spočívá v nových databázových
architekturách, zejména v přístupu in-memory. Např. MemSQL26 patří k nejrychlejším
NewSQL nástrojům jak při vytváření databáze tak pro vyhodnocování dotazů. V souvislosti
s Big Analytics je většina zástupců NewSQL vhodná pro analýzu ve (skore) reálném čase
prostřednictvím použití technologií, jako je MPP (např. ClustrixDB a Vertica) nebo
ukládání relačních tabulek po sloupcích (Vertica). Je možné namítnout, že relační databáze
používající MPP zde byly již dávno před tím, než započala era Big Data. Kvalitativní rozdíl
je zřejmě ve vícejádrových procesorech a nových řešeních (např. Durable Distributed
Cache (DDC) v NuoDB). Database v NuoDB je množinou in-memory objektů, které
mohou přetékat na disk, je-li to třeba, nebo být zálohovány v perzistentním úložišti.
6 Závěr
Efektivní ukládání a zpracování dat databázovým způsobem jsou pouze prvním
předpokladem pro Big Analytics. Viděli jsme, že NoSQL databáze částečně přispívají
k tomuto cíli. Jejich rozmanitost a rozdílné vlastnosti tvoří základ ke klíčovým problémům
s aplikací NoSQL v praxi:
 volba správného produktu, návrh vhodného architektury pro danou třídu aplikací,
 zajištění, že budou k dispozici zkušení vývojáři aplikace.
S. Edlich27 dokonce navrhuje výběr NoSQL databáze až po zodpovězení asi 70 otázek
v 6 kategoriích a zhotovení prototypu. Navzdory tomu, že některé firmy nabízejí referenční
modely pro zpracování velkých objemů dat (např. Oracle), jeden obyčejný je již k dispozici
nyní. Takový model by měl obsahovat vrstvy: (1) datovou, (2) integrační, (3) pro analýzu a
(4) vrcholovou vrstvu pro prediktivní a normativní analýzu. Zde jsme se zabývali vrstvami
(1) a (3) a jejich vzájemnou silnou korelaci.
Techniky dolování dat, již široce používané v (3) k extrakci častých korelací hodnot jak
ze strukturovaných a semistrukturovaných souborů dat v BI, jsou zajímavými řešeními pro
20
http://www.clustrix.com/
http://www.nuodb.com/
22 http://voltdb.com/
23 http://db.cs.yale.edu/hadoopdb/hadoopdb.html
24 http://www.vertica.com/
25 https://foundationdb.com/
26 http://www.memsql.com/
27 http://www.infoq.com/presentations/Choosing-NoSQL-NewSQL
21
Zvaná přednáška
15
Big Analytics také, musí ale být rozšířeny a přizpůsobeny. Hlavní dnešní výzvy pro
výzkum v oblasti zpracování velkých objemů dat zahrnují:
 zlepšení kvality a škálovatelnosti metod dolování dat. Procesy formulace dotazu zejména při absenci schématu - a prezentace a interpretace získaných odpovědí
může být netriviální.
 transformaci obsahu do strukturovaného formátu pro pozdější analýzu, protože
mnoho dat dnes není nativně ve strukturovaném formátu.
 zlepšení výkonu příslušných aplikací a posun směrem k „No Hadoop" databázím, ve
kterých je odstraněna vrstva MapReduce.
Druhá výzva znamená nejen krok k integraci, ale týká se i filtrování Big Dat. Např.
v projektech zpracování rozsáhlých dat digitálních přehlídek oblohy se můžeme posunout
pomocí vhodné transformace dat z rozsahu TB do desítek GB.
Závěrečná výzva se týká role člověka v Big Analytics. Zatím je proces dolování řízen
analytikem či datovým vědcem. V závislosti na aplikačním scénáři ten určuje část dat,
odkud mohou být užitečné vzory extrahovány. Lepším přístupem by byl automatický
proces dolování s cílem získat přibližné syntetické informace jak o struktuře, tak o obsahu
velkého množství dat. Toto je zatím největším problémem v Big Data.
Poděkování
Tato práce byla podpořena agenturou GACŘ (grant No. P103/13/08195S).
Literatura
1.
Behm, A., Borkar, V. R., Carey, R. M., Grover, J., et al.: ASTERIX: Towards a Scalable,
Semistructured Data Platform for Evolving-world Models. Distributed and Parallel Databases,
29(3) (2011) 185–216.
2. Beyer, K., Ercegovac, V., Gemulla, R., Balmin, A., Eltabakh, M., Kanne, C.-Ch., Ozcan, F.,
Shekita, E.J: Jaql: A scripting language for large scale semistructured data analysis. PVLDB
4(12) (2011) 1272–1283.
3. Borkar, V., Carey, M.-J., Chen Li, Ch.: Inside "Big Data management": ogres, onions, or
parfaits? Proceedings of EDBT Conference, Berlin, Germany (2012) pp. 3-14.
4. Brewer, E.A.: Towards robust distributed systems. Invited Talk on PODC 2000, Portland,
Oregon, 16-19 July, 2000.
5. Brewer, E.A.: CAP twelve years later: how the ‘rules’ have changed. Computer 45(2) (2012) 29.
6. Bu, Y., Howe, Y., Balazinska, M, Ernstm M.D.: The HaLoop approach to large-scale iterative
data analysis. The VLDB Journal 21(2) (2012) 169-190.
7. Chang, F., Dean, J., Ghemavat, S., et al: BigTabulka: A Distributed Storage System for
Structured Data. ACM Transactions on Computer Systems (TOCS), 26(2) (2008) Article No. 4.
8. Cooper, B.F., Ramakrishnan , R., Srivastava, U., et al: PNUTS: Yahoo!'s hosted data serving
platform. Journal Proceedings of the VLDB Endowment 1(2) (2008) 1277-1288.
9. Corbett, J.C., Dean, J.C., Epstein, M. et al: Spanner: Google’s Globally-Distributed Database. In:
Proc. of 10th USENIX Symposium on Operation Systems Design and Implementation (OSDI
2012), Hollywood (2012) 261-264.
10. Dean, D., Ghemawat, S.: MapReduce: Simplified Data Processing on Large Clusters.
Communications the ACM 51(1) (2008) 107-113.
11. Gamble, M. and Goble, C.: Quality, Trust and Utility of Scientific Data on the Web: Toward a
Joint model. In: Proc. of WebSci’11 Conference, Koblenz, Germany, 2011.
16
12. Gates, A., Natkovich, O., Chopra, S., et al: Building a high level dataflow system on top of
MapReduce: The pig experience. PVLDB 2(2) (2009) 1414–1425
13. Gilbert, S., Lynch, N.: Brewer’s conjecture and the feasibility consistent, available, partitiontolerant web services. ACM SIGACT News, 33(2) (2002) 51-59.
14. Härder, T., Reuter, A.: Concepts for Implementing and Centralized Database Management
System. In: Proc. Int. Computing Symposium on Application Systems Development, Nürnberg,
B.G. Teubner-Verlag (1983) 28-60.
15. Kelly, J.: Big Data: Hadoop, Business Analytics and Beyond, Wikibon, 2014
http://wikibon.org/wiki/v/Big_Data:_Hadoop,_Business_Analytics_and_Beyond (accessed 20
February 2014).
16. Laney, D.: 3d data management: Controlling data volume, velocity and variety. Gartner.
Retrieved, 6, 2001.
17. Manyika, J., Chui, M., Brown, B., et al: Big data: the next frontier for innovation, competition,
and productivity. McKinsey Global Inst., 2011.
18. Pavlo, A., Paulson, E., Rasin, A., et al: A Comparison of Approaches to Large-Scale Data
Analysis. In: Proc. of SIGMOD’09, June 29–July 2 (2009), 165-178.
19. Pokorný, J., Snášel, V.: Zpracování proudů dat. In: Proc. of the Annual Database Conf.
DATAKON'2006, P. Vojtáš ed., Brno, , Masaryk University Brno (2006) 61-76.
20. Pokorný, J.: NoSQL databáze. In: Proc. of the Annual Database Conf. DATAKON'2011, J.
Zendulka, M. Rychlý (eds.), Mikulov, VUT Brno (2011) 71-82.
21. Pokorny J.: NoSQL Databases: a step to databases scalability in Web environment. International
Journal of Web Information Systems, 9 (1) (2013) 69-82.
22. Pritchett, D.: BASE: an ACID alternative. ACM Queue, May/June (2008) 48-55.
23. Rajaman, A., Ullman, J.D.: Mining of Massive Datasets. Cambridge University Press, 2011.
24. Robinson, I., Webber J., Eifrem E.: Graph Databases - The Definitive Book on Graph
Databases. O'Reilly, 2013.
25. Shute, J., Vingralek, R., Samwel, B., et al: F1: A Distributed SQL Database That Scales. PVLDB
6(11) (2013) 1068-1079.
26. Shvachko, K., Kuang, H., Radia, S., Chansler, R.: The Hadoop Distributed File System, In:
Proceedings of MSST2010, May 2010.
27. Stuart, J., Barker, A.: Undefined By Data: A Survey of Big Data Definitions. CoRR,
abs/1309.5821 (2013).
28. Šeleng, M., Laclavík, M., Dlugolinský, Š.: Dostupné škálovateľné riešenia pre spracovanie
veľkého objemu dát a dátové sklady. In: Proc. of the Annual Database Conf. DATAKON'2011,
J. Zendulka, M. Rychlý (eds.), Mikulov, VUT Brno (2011) 1-22.
29. Thusoo, A., Sarma, J.S., Jain, N., et al: Hive - a warehousing solution over a map-reduce
framework. PVLDB 2(2) (2009) 1626–1629.
30. Vinayak, R., Borkar, V., Carey, M.-J., Chen Li, Ch.: Big data platforms: what's next? ACM
Cross Road 1 (2012) 44-49.
Annotation:
In recent years there has been the development and deployment of highly distributed and scalable data
processing systems in the area called Big Data. New architectures include, for example. Distributed
file systems and NoSQL databases. On the other hand, obvious that Big Data challenges, such as the
complexity of the data, the rate of their occurrence and analytical requirements, solves these funds
only partially. This is particularly noticeable in the network environment where Big Data is part of the
corporate database and are required ACID properties by NoSQL databases generally guaranteed. The
development of so-called. NewSQL databases is therefore up to date, it appears even a new category
of databases - Big Data Management Systems. In this lecture we will discuss these trends and
evaluate some of the current approaches to the treatment and management of Big Data.
Otevřená a propojitelná data – metodiky, postupy,
nástroje a praxe
Dušan CHLAPEK1, Jakub KLÍMEK2, Jan KUČERA1, Martin NEČASKÝ2
1
Katedra informačních technologií, FIS VŠE v Praze
nám. W. Churchilla 4, 130 67 Praha 3
{chlapek,jan.kucera}@vse.cz
2
Katedra softwarového inženýrství, MFF UK Praha
Malostranské nám. 25, 118 00 Praha
[email protected]
Abstrakt. V přednášce budou představeny přístupy k analýze, přípravě, zpracování a
publikaci otevřených a propojitelných dat. Současně bude poskytnut přehled
experimentálně vyvíjených metod, postupů a nástrojů pro přípravu a zpracování
otevřených a propojitelných dat. V přednášce budou prezentovány zobecněné
poznatky a zkušenosti z řady výzkumných i ryze praktických projektů v oblasti
otevřených a propojitelných dat realizovaných v posledních dvou letech.
Klíčová slova: otevřená data, Open Data, propojitelná data, Linked Data, Linked
Open Data, LOD, metodika, postup, nástroj.
1 Úvod
Dle viceprezidentky Evropské komise Neelie Kroesové představují data základní surovinu
digitální ekonomiky [23]. Zejména v souvislosti se zpřístupňováním dat veřejné správy
(VS) k dalšímu využití se dnes často hovoří o tzv. otevřených datech, tj. o datech, která jsou
publikována na internetu ve strojově čitelných formátech a za takových podmínek užití
(licence), která umožňují jejich volné užití (viz [28]). Otevřená data veřejné správy jsou
vnímána jako jeden z klíčových aspektů prosazování konceptu tzv. otevřeného vládnutí, tj.
snahy o transparentnější veřejnou správu a vládnutí založené na spolupráci politiků a
orgánů veřejné správy s podnikateli a občany [2]. Kromě podpory transparentnosti a
otevřeného vládnutí existují studie, které předpokládají značný ekonomický potenciál ve
využití otevřených dat pro tvorbu nových aplikací a služeb (viz např. [13], [40]).
Buchholtzová, Bukowski a Śniegocki pak na základě své analýzy očekávají přínos
současného využití otevřených dat a Big Data pro podporu rozhodování [7].
Otevřená data veřejné správy a jejich využití slibují značné přínosy pro občany, podniky
i samotné orgány veřejné správy. Při jejich publikaci se ale orgány veřejné správy potýkají
s problémy v řadě oblastí. Dle Ubaldiové např. na strategické úrovni není vždy definována
strategie pro otevřená data, postupy publikace a formáty dat se mezi jednotlivými orgány
VS liší, postupy pro hodnocení nákladů a přínosů otevřených dat v současné době ještě
nejsou dostatečně propracovány, pro publikaci otevřených dat nejsou vždy nastaveny
vhodné procesy a odpovědnosti a překážky publikace otevřených dat existují i v právní
oblasti [36]. Kromě toho naplnění očekávaných přínosů otevřených dat může také
vyžadovat změnu přístupu či kultury organizací směrem k větší spolupráci mezi
poskytovateli a uživateli dat.
18
Cílem tohoto příspěvku je diskutovat přístupy k publikaci otevřených a propojitelných
dat a představit existující metodiky pro jejich publikaci. Přístupy k publikaci otevřených dat
diskutované v tomto příspěvku jsou identifikovány na základě analýzy přístupů
k otevřeným datům dvou orgánů veřejné správy z České republiky. Konkrétně Českého
telekomunikačního úřadu (ČTÚ) a České obchodní inspekce (ČOI). Na základě zobecnění
zkušeností z praxe je dále v tomto příspěvku na obecné úrovni představen postup publikace
otevřených propojitelných dat, který byl formulován v rámci projektu COMSODE 1.
Příspěvek je členěn následujícím způsobem. Na úvod navazuje vymezení pojmů
otevřená data a propojitelná data. V další části je uvedena diskuse přístupů k publikaci
otevřených a propojitelných dat. Následuje část věnovaná existujícím metodikám publikace
otevřených a propojitelných dat. Dále je představen obecný postup publikace otevřených
propojitelných dat a následně jsou také diskutovány nástroje pro publikaci a využití
otevřených propojitelných dat. V závěru jsou shrnuty získané poznatky a jsou předestřeny
další výzkumné otázky.
2 Otevřená a propojitelná data
V této kapitole jsou vymezeny pojmy otevřená data (angl. Open Data, zkráceně OD),
propojitelná data (Linked Data, LD), resp. otevřená propojitelná data (Linked Open Data,
LOD).
2.1
Otevřená data
Otevřená data lze dle Open Knowledge Foundation vymezit jako data, která mohou jejich
uživatelé užívat pro libovolné účely a která mohou dále šířit za podmínky, že při užití a
šíření dat bude uveden jejich autor a pokud budou stejná oprávnění pro nakládání s daty
zachována i pro další uživatele [28]. Na základě principů formulovaných The Sunlight
Foundation (viz [33]) vymezuje Koncepce katalogizace otevřených dat VS ČR (dále jen
Koncepce) otevřená data jako data, která jsou [19]:”
1. úplná – data jsou zveřejněna v maximálním možném rozsahu. Rozsah může být
definován právním předpisem, usnesením vlády, příp. poskytovatelem dat.
Například seznam všech nemovitostí s číslem popisným nebo evidenčním v obci
XY, nebo seznam všech památkově chráněných objektů v obci XY.
2. primární (původní) – data, která jsou zveřejněna původcem dat v podobě, v jaké
byla původcem jako primární (původní) vytvořena. Za primární data se považují i
a. referenční údaje ze základních registrů,
b. data z registrů a rejstříků VS,
c. agregovaná data (např. výsledky voleb), pokud není možné zveřejnit data,
z nichž byla provedena agregace,
d. agregovaná data – (např. statistiky nad jinými otevřenými daty), pokud je
uveden způsob agregace a odkaz na zveřejněná primární data, z nichž byla
agregace provedena.
3. zveřejněná bez zbytečného odkladu – zveřejnění dat není zdrženo činnostmi, které
nesouvisí s jejich přípravou; činnosti nezbytné pro publikaci dat jsou provedeny
v čase, který umožní jejich zveřejnění bez nepřiměřeně dlouhé prodlevy od
okamžiku vzniku dat,
1
http://www.comsode.eu/
Zvaná přednáška
19
4.
snadno dostupná – data jsou dostupná a dohledatelná běžnými ICT nástroji a
prostředky,
5. strojově čitelná – data ve formátu, který je strukturovaný takovým způsobem, že
pomocí programové aplikace lze z dat získat žádané (vybrané) údaje,
6. neomezující přístup – data dostupná způsobem, který nediskriminuje jednotlivce
nebo skupinu osob,
7. používající standardy s volně dostupnou specifikací (otevřené standardy) – data
musí být ve formátu, který je volně (bezplatně) dostupný pro libovolné použití
nebo do takovéhoto formátu převoditelný volně (bezplatně) dostupnou aplikací,
8. zpřístupněna za jasně definovaných podmínek užití dat (licence) s minimem
omezení - podmínky musí být jasně a zřetelně definovány a zveřejněny,
9. stále dostupná – data jsou dostupná on-line po dobu uvedenou jejich
poskytovatelem,
10. dostupná uživatelům při vynaložení minima možných nákladů na jejich získání –
poskytovatelé jsou v souvislosti s poskytováním dat oprávněni žádat úhradu
maximálně ve výši, která nesmí přesáhnout náklady spojené s jejich
zpřístupněním uživateli; poskytovatel dat může jednorázově vyžádat i úhradu za
mimořádně náročné pořízení dat, pokud si uživatel zpřístupnění těchto dat
vyžádá.”
Protože ale nemusí být vždy snadné všechny výše uvedené podmínky splnit, rozděluje
Koncepce výše uvedené atributy otevřených dat VS na povinné a nepovinné. Dle [19] musí
data splňovat alespoň podmínky č. 1, 4, 5, 7, 8 a 10, aby byla považována za otevřená.
Zbylé podmínky č. 2, 3, 6 a 9 jsou nepovinné. Koncepce označuje data splňující všech 10
podmínek jako “dobře publikovaná otevřená data” [19].
2.2
Stupně otevřenosti dat
V předcházející části byly představeny vlastnosti, které musí otevřená data splňovat.
Nicméně otevřené datové sady mohou být publikovány v různých formátech. Berners-Lee
formuloval klasifikační schéma pro otevřená data, v rámci kterého je definováno 5 stupňů
otevřenosti v závislosti na tom, jaké formáty dat jsou použity [3]. Toto schéma dále
rozpracoval Hausenblas [17]. Jednotlivé stupně otevřenosti dat (označené počtem
hvězdiček) uvádí tabulka 1.
Tabulka 1: Stupně otevřenosti dat, zdroj: zpracováno dle [17]
Stupeň
otevřenosti
*
**
Vlastnosti dat
 Data poskytována pod otevřenou licencí či podmínkami
užití umožňujícími jejich další užití
 Data poskytována v libovolném formátu
 Data poskytována ve strojově čitelném formátu
Příklad
formátu
PDF
MS Excel
20
Stupeň
otevřenosti
Příklad
formátu
Vlastnosti dat
 Formát dat je otevřený
 Specifikace formátu je volně dostupná
 Lze využívat zdarma, další využití formátu není
omezeno
 Formát nezávislý na platformě, resp. lze vytvořit
nezávislé implementace pro různé platformy
 Jako identifikátory objektů jsou použity URI 2
 Jako identifikátory objektů jsou použity URI
 Data jsou pomocí odkazů propojena na jiná související
data
***
****
*****
CSV
RDF3 bez
propojení na
další zdroje
RDF s
propojeními
na další
zdroje
V následující tabulce 2 jsou pak uvedeny výhody a nevýhody jednotlivých stupňů
otevřenosti.
Tabulka 2: Hodnocení stupňů otevřenosti dat, zdroj: zpracováno dle [17]
Stupeň
otevřenosti
*
2
3
Výhody
Nevýhody
 Jednoduchost a relativně nízká
pracnost
 Data není třeba transformovat
 Zaměření pouze na právní
otevřenost
 Uživatelé vědí, že mohou data
dále zpracovávat
 Data může být obtížné využít –
např. potřeba vytěžování
tabulkových dat z PDF
dokumentů
 Příklad: tabulky s údaji
v ročenkách a výročních
zprávách
URI – Uniform Resource Identifier, viz [4]
RDF – Resource Description Framework, viz [22]
Zvaná přednáška
Stupeň
otevřenosti
**
***
****
*****
21
Výhody
Nevýhody
 Relativně jednoduché, pokud
jsou podkladová data již
dostupná ve formátu typu MS
Excel, nebo pokud je lze
takovéhoto formátu jednoduše
uložit
 Data jsou ve formátu, který je
snáze strojově zpracovatelný
 Uživatelé nejsou nuceni používat
aplikace určitého výrobce, aby s
daty mohli pracovat
 Objekty jsou jednoznačně
identifikovány způsobem, který
umožňuje se na ně odkazovat
obdobně jako na HTML stránky
 Lze kombinovat s jinými
datovými sadami na stupních 4 a
5 hvězdiček
 Data jsou propojena na další
související zdroje
 Datům lze přiřadit bohatý
kontext
 Místo opisování referenčních
údajů se lze přímo odkázat na
referenční datové zdroje
 Propojení umožňují uživateli
získat další data, která by
jinak poskytovatel musel
zahrnout do datové sady
 Jednotlivé orgány VS
zodpovídají a udržují své datové
sady, je možné se mezi nimi
odkazovat, není nutné je
duplicitně publikovat na více
místech
 Pokud neexistují volně dostupné
nástroje pro práci se zvolenými
formáty, je uživatel nucen
pořizovat odpovídající SW
nástroje
 Může být nutné data do
otevřeného strojově čitelného
formátu transformovat
 Příprava dat vyžaduje více času a
úsilí – definice schémat pro
tvorbu URI a přiřazení URI
identifikátorů objektům
 Ne všichni v současné době
disponují znalostmi pro publikaci
a zpracování dat v této podobě
 Příprava dat vyžaduje více času a
úsilí – definice schémat pro
tvorbu URI a přiřazení URI
identifikátorů objektům
 Ne všichni v současné době
disponují znalostmi pro publikaci
a zpracování dat v této podobě
 Související datové zdroje musí
být také k dispozici minimálně na
stupni 4 hvězdičky
S rostoucím stupněm otevřenosti dle “5-ti hvězdičkového schématu” [17] roste i
připravenost dat na jejich další strojové zpracování a je usnadněno jejich propojování na
další datové zdroje. Nicméně pokud zdrojová data, která mají být jako otevřená data
publikována, nejsou již dostupná v odpovídajícím formátu, je třeba zdrojová data do
formátu příslušného stupně otevřenosti převést. To může být zdrojem pracnosti spojené
s publikací dat na zvoleném stupni otevřenosti. Zároveň pro publikaci (a využití) dat na
úrovních 4* a 5* jsou také vyžadovány znalosti principů a technologií propojitelných dat
(viz dále).
22
2.3
Propojitelná a otevřená propojitelná data
Jak je patrné ze stupňů otevřenosti představených v předcházející části, otevřená data
mohou být publikována v různých formátech. Otevřená data na nejvyšším stupni
otevřenosti (5 hvězdiček) jsou otevřená po právní stránce a zároveň jsou u nich aplikovány
principy propojených dat (Linked Data). Tyto principy jsou následující [3]:
1. pojmenování objektů na webu pomocí URI,
2. použití HTTP URI, které umožňují je vyhledat v prostředí dnešního webu,
3. při vyhledání URI jsou uživateli poskytnuta data o objektu, data jsou poskytnuta
s využitím standardů RDF a SPARQL4,
4. objekty jsou provázány pomocí odkazů mezi HTTP URI, takže je možné
objevovat související objekty.
Hlavní myšlenkou propojených dat je propojit související data na webu pomocí odkazů
obdobně, jako je tomu v případě webových stránek [5]. Na rozdíl od odkazů mezi
webovými stránkami představují ale odkazy mezi propojenými daty tvrzení o vzájemném
vztahu těchto dat [5]. Díky tomu jsou tak data zasazena do kontextu.
Propojitelná data využívají dvou základních standardů. Prvním z nich je obecný formát
RDF (Resource Description Framework) [22]. Druhým z nich je dotazovací jazyk a
protokol SPARQL [42].
Pokud nebude třeba blíže rozlišit, zda se jedná o skutečně propojená data, nebo o data,
která jsou pouze technicky připravena pro propojování, bude pro zjednodušení v dalším
textu používán pouze pojem propojitelná data. Data, která jsou otevřená a zároveň
využívají principů propojených dat, budeme označovat jako otevřená propojitelná data
(ekvivalent anglického pojmu Linked Open Data, zkráceně LOD).
3 Přístupy k publikaci otevřených a otevřených propojitelných dat
Na základě analýzy přístupů k publikaci otevřených dat aplikovaných Českou obchodní
inspekcí (ČOI) a Českým telekomunikačním úřadem (ČTÚ) jsou v této kapitole
představeny dva možné přístupy k publikaci otevřených dat - přístup shora-dolů (top-down)
a zdola-nahoru (bottom-up).
3.1
Otevřená data ČOI
Česká obchodní inspekce (ČOI) publikovala v podobě otevřených dat databázi kontrol,
sankcí a zákazů v září roku 2013 [9]. Tato data byla zvolena pro publikaci v podobě
otevřených dat, jelikož data o kontrolách jsou častým předmětem dotazů novinářů a dotazů
dle zákona č. 106/1999 Sb., o svobodném přístupu k informacím [34]. Kromě snahy o
snížení počtu dotazů dle zák. č. 106/1999 Sb. představují otevřená data ČOI další z nástrojů
osvětové a preventivní činnosti [34].
Otevřená data poskytuje ČOI v několika datových sadách: kontroly, zaměření kontrol,
sankce, zákazy, zajištěné výrobky a předmět podnikání kontrolovaných subjektů. Data jsou
poskytována ve formátech CSV, XLSX, ODS (Open Document Spreadsheet) a RDF. Ve
formátu RDF jsou publikována i metadata [9]. Pro otevřená data ČOI dále formulovala
podmínky užití, které zajišťují jejich právní otevřenost [8]. Publikovaná data jsou
aktualizována čtvrtletně [34].
4
SPARQL – množina specifikací pro dotazování a manipulaci s daty v RDF, viz [42].
Zvaná přednáška
23
Publikací dat ve formátu RDF se ČOI snaží dosáhnout stupně otevřenosti svých dat na
úrovni 5* (viz [3], [17] a kapitola výše). Pro dosažení úrovně 5* je ale třeba, aby
u publikovaných dat byla zajištěna dereferencovatelnost použitých URI, tj. aby po
přistoupení na zvolené URI byla uživateli poskytnuta data o objektu, který je daným URI
identifikován (viz např. [18]). Tato podmínka nicméně u dat ČOI zatím splněna není.
Na základě stanoviska Úřadu pro ochranu osobních údajů byla ČOI nucena přistoupit
k částečné anonymizaci dat [9]. Úplné informace jsou poskytovány o kontrolovaných
právnických osobách. Konkrétní fyzické osoby, které byly kontrolovány, nejsou
v otevřených datech ČOI identifikovány.
3.2
Otevřená data ČTÚ
Český telekomunikační úřad se rozhodl zvýšit svoji otevřenost a publikovat otevřená data.
Vzhledem k velkému rozsahu dat, které ČTÚ zpracovává, přistoupil ČTÚ k provedení
analýzy, jejímž cílem bylo určit, jaká data by bylo vhodné publikovat v podobě otevřených
dat. Tato analýza zahrnovala [11]:
 vymezení požadavků na otevřená data ČTÚ a způsob jejich naplnění,
 identifikaci přínosů a rizik otevření dat ČTÚ,
 identifikaci potenciálních datových sad k otevření
 určení pracnosti publikace datových sad ve formátu otevřených dat,
 určení priorit otevírání datových sad ČTÚ,
 návrh podmínek užití otevřených dat ČTÚ,
 návrh vybraných částí nově navrženého interního řídícího aktu,
 návrh struktury katalogizačního záznamu a postupu katalogizace otevřených dat
ČTÚ,
 identifikace aplikací pro podporu otevřenosti ČTÚ,
 návrh projektů pro realizaci navržených doporučení.
Na základě zhodnocení pracnosti publikace a rizik bylo vybráno 50 datových sad
k publikaci [11]. Pro jednotlivé datové sady byla také určena priorita jejich publikace a dle
této priority publikace rozplánována do tří etap pro roky 2014-2015.
V březnu 2014 bylo v podobě otevřených dat publikováno prvních 10 datových sad a
v nové sekci webových stránek byl zpřístupněn katalog otevřených dat ČTÚ 5 [10]. Datové
sady jsou poskytovány ve formátu CSV a jejich stupeň otevřenosti tak odpovídá úrovni 3*.
Uživatelům je také umožněno zasílat podněty týkající se otevřených dat ČTÚ a tím i
pomáhat iniciativu dále rozvíjet.
3.3
Porovnání přístupů shora-dolů a zdola-nahoru
Přestože lze v postupu otevírání dat ČOI a ČTÚ nalézt určité shodné kroky, jako je např.
návrh podmínek užití otevřených dat, oba výše zmíněné orgány veřejné správy aplikovaly
při otevírání svých dat odlišný přístup. Zatímco v případě ČOI byla k publikaci dat vybrána
data z jedné oblasti (kontroly, sankce a zákazy) na základě zájmu novinářů a dalších
subjektů, v ČTÚ předcházelo publikaci dat provedení analýzy dat, která úřad zpracovává a
výběr datových sad, které by bylo vhodné zveřejnit v podobě otevřených dat.
Přístup ČTÚ byl strategicky zaměřen na poznání dostupných datových sad, provedení
analýzy přínosů a rizik, určení priorit publikace vybraných datových sad a sestavení
5
http://www.ctu.cz/otevrena-data/katalog-otevrenych-dat-ctu.html
24
harmonogramu jejich publikace. Díky postupu od celkové množiny datových sad
spravovaných úřadem ke konkrétním datovým sadám určeným k publikaci v podobě
otevřených dat lze přístup uplatněný ČTÚ označit jako přístup shora-dolů (top-down).
Oproti tomu ČOI zvolila přístup, který je možno označit jako přístup zdola-nahoru. Byla
vybrána data z jedné oblasti a postupně v rámci zvolené domény byly přidávány další
datové sady. Tento přístup také odpovídá jednomu z doporučení pro otevírání dat, které je
obsaženo v Open Data Handbook a sice “začít v malém, jednoduše a rychle” [28].
Tabulka 3 shrnuje aktivity v oblasti otevřených dat ČOI a ČTÚ.
Tabulka 3: Otevřená data ČOI a ČTÚ, zdroj: autoři
Charakteristika
Celkový přístup
Počet
publikovaných
datových sad
Výběr datových
sad
Očekávané
přínosy
Dopad
ČOI
Zdola-nahoru
6 (data za období od 1. 1. 2012
do 31. 3. 2013)
Zaměření na data vyžadovaná
novináři a v žádostech dle zák.
č. 106/1999 Sb.
Zvýšení prestiže, méně dotazů
na tiskové oddělení, přívětivé
aplikace zdarma, objevení
nových poznatků z propojení s
daty ostatních úřadů,
efektivnější prevence a osvěta
Data využívána univerzitami,
novináři a webovým portálem,
vyvinuta aplikace
VysledkyKontrol.cz6
ČTÚ
Shora-dolů
10 (březen 2014), do konce roku
2015 plánována publikace 50
datových sad
Identifikace dostupných datových
sad, analýza přínosů a rizik, určení
pracnosti a priorit publikace
Zvýšení transparentnosti, zlepšení
služeb, minimalizace chyb při
práci s daty, snazší překlady
dokumentů, lepší pochopení a
zlepšení řízení dat ČTÚ, lepší
informování veřejnosti o
výsledcích kontrol, zvýšení
hodnoty dat, zvýšení prestiže
Iniciativa otevřených dat
zaznamenána a komentována
médii, zlepšování kvality dat na
základě poskytnuté zpětné vazby
Lze shrnout, že pro přístup shora-dolů je typické především:
 provedení analýzy datových sad dostupných v rámci organizace;
 provedení výběru vhodných datových sad k otevření a
 prioritizace a sestavení plánu otevírání vybraných datových sad.
Pro přístup zdola-nahoru je pak především typické:
 volba jedné či několika málo datových sad a jejich publikace;
 zpravidla bez podrobné analýzy;
 výběr např. podle častých dotazů dle zák. č. 106/1999 Sb.;
 postupné rozšiřování publikovaných datových sad a zlepšování kvality
publikovaných dat;
 rozšiřování nabídky dat na základě zpětné vazby uživatelů;
 rozšiřování dostupných dat o historická data;
 postupné zlepšování metadat.
6
http://www.vysledkykontrol.cz
Zvaná přednáška
25
Každý z výše uvedených přístupů má přirozeně své výhody a nevýhody. Nejvýznamnější
z nich jsou shrnuty v následující tabulce 4.
Tabulka 4: Výhody a nevýhody přístupů shora-dolů a zdola-nahoru, zdroj: autoři
Přístup
Výhody
 Lepší poznání dostupných
datových sad
 Plánování a vyhodnocování
postupu
 Výsledky analýzy dat mohou
být využity pro zlepšení řízení
dat v organizaci
Shora-dolů
Zdola-nahoru
 Rychlá publikace prvních
datových sad
 Pokud jsou datové sady
využívány, může organizace
rychle získávat zkušenosti a
podněty od uživatelů
Nevýhody
 Od rozhodnutí publikovat
otevřená data do publikace
prvních datových množin
uplyne více času
 Výsledky analýzy dat nemusí
přinést výstupy přímo
využitelné potenciálními
uživateli dat
 Ne vždy musí být zřejmé,
kterými datovými sadami je
vhodné začít
4 Metodiky publikace otevřených dat
Za účelem usnadnění publikace otevřených dat a poskytnutí doporučení a návodů, jak při
publikaci otevřených dat postupovat, vznikají metodiky publikace otevřených dat. Dle
Buchalcevové metodika představuje “v obecném slova smyslu souhrn metod a postupů pro
realizaci určitého úkolu” [6]. Dle [24] pak lze metodiku publikace otevřených dat definovat
jako “soubor postupů, metod či praktik pro publikaci otevřených dat.”
V České republice v návaznosti na Koncepci katalogizace otevřených dat VS ČR [19]
byla vytvořena Metodika publikace otevřených dat veřejné správy ČR [20]. Nicméně
metodiky publikace otevřených dat vznikají i ve světě. V této části tak představíme některé
z těchto metodik. Cílem není poskytnout úplný výčet existujících metodik, ale představit
vybrané metodiky. U zahraničních metodik zejména ty, které jsou dostupné v anglickém
jazyce. Tabulka 5 uvádí přehled dále porovnaných metodik.
Tabulka 5: Přehled metodik publikace otevřených dat, zdroj: [24]7
ID
ODH
OGDTK
Název
Open Data Handbook
Guidelines on Open Government
Data for Citizen Engagement
(2nd edition)
Open Government Data Toolkit
POD
Project Open Data
OGDUN
7
Autor/Vydavatel
Open Knowledge Foundation
Zdroje
[28]
Organizace spojených národů
[37]
Světová banka
Office of Management and
Budget, Office of Science and
Technology Policy
[43]
[26]
Zdroje popisující metodiky a příslušné odkazy z původního zdroje [24] jsou upraveny, aby
odpovídaly zdrojům a číslování použitým v tomto příspěvku.
26
ID
SODFG
ODIG
ODVSCR
MELODA
MGPLD
BPPLD
Název
Open Data Field Guide
Open Data Institute Guides
Metodika publikace otevřených
dat veřejné správy ČR (v1.0)
MEtric for reLeasing Open Data
(v3.10)
Methodological Guidelines for
Publishing Linked Data
Best Practices for Publishing
Linked Data
Autor/Vydavatel
Socrata
The Open Data Institute
D. Chlapek, J. Kučera, M.
Nečaský
Zdroje
[32]
[27]
University Rey Juan Carlos
[38]
B. Villazón-Terrazas, O.
Corcho
B. Hyland, G. Atemezing, B.
Villazón-Terrazas
[20]
[41]
[18]
Open Data Handbook [28] obsahuje definici pojmu otevřená data a poskytuje úvod do
problematiky jejich publikace. Je definován základní postup publikace OD a metodika také
dává základní doporučení pro provádění jednotlivých kroků publikace OD.
Metodika Guidelines on Open Government Data for Citizen Engagement (2nd
edition) [37] vniká v rámci OSN a zaměřuje se zejména na využití otevřených dat pro
zapojení občanů do veřejných záležitostí. Metodika je určena především osobám
rozhodujícím o aplikaci principů otevřených dat a ICT pracovníkům. Metodika definuje
postup tvorby strategie pro otevřená data a dále obsahuje praktická doporučení pro
samotnou publikaci OD včetně interakce s uživateli dat.
Open Government Data Toolkit [43] je vytvářen Světovou bankou. Metodika
obsahuje úvod do problematiky a vymezení otevřených dat. Metodika se zabývá např.
budováním poptávky po datech, interakcí s uživateli, doporučenými technologiemi nebo
datovou kvalitou. Metodika často místo vlastních doporučení odkazuje na jiné zdroje a
metodiky. Součástí metodiky je i dotazník pro hodnocení připravenosti na otevřená data.
Project Open Data [26] představuje projekt vlády USA, který je však otevřený i širší
veřejnosti. Cílem tohoto projektu je vytvořit metodiku pro orgány VS v oblasti otevřených
dat, která by zejména umožnila orgánům VS naplnit požadavky dané Open Data Policy (viz
[15]). Kromě doporučených praktik a postupů mají poskytovatelé OD k dispozici seznam
doporučeného softwaru a případové studie.
Open Data Field Guide [32] společnosti Socrata se snaží poskytnout ucelenou sadu
doporučení pro naplánování a realizaci iniciativ otevřených dat. V metodice je tak možné
najít vysvětlení konceptu otevřených dat a praktická doporučení pro jejich publikaci, která
zahrnují jak plánování celé iniciativy, její organizační zajištění, tak i pokrývají fázi
realizace. Vedle publikace dat ve strojově čitelných formátech je kladen důraz na prezentaci
dat prostřednictvím aplikací.
Organizace The Open Data Institute vytváří metodiku, která je tvořena sadou
průvodců (Guides) [27] zaměřených na různé aspekty publikace (a využívání) otevřených
dat, např. licencování otevřených dat, katalogizaci, tvorbu business case, interakci
s uživateli nebo anonymizaci dat.
Jak již bylo uvedeno výše, Metodika publikace otevřených dat veřejné správy ČR
(v1.0) [20] byla vytvořena v návaznosti na Koncepci katalogizace otevřených dat VS ČR
[19]. Metodika definuje základní postup publikace OD VS a vymezuje základní pojmy a
dále role podílející se na publikaci OD VS. Pro jednotlivé kroky publikace OD VS jsou
uvedena doporučení pro jejich realizaci.
MEtric for reLeasing Open Data (v3.10) [38] představuje zejména metodu pro
hodnocení datových sad z hlediska toho, jak snadné je datovou sadu opětovně použít
(re-use). Hodnotí se podmínky užití datové sady, použité technické standardy, přístup
Zvaná přednáška
27
k datové sadě a datový model. Kritéria hodnocení lze nicméně využít i jako určitou sadu
doporučení, jaké vlastnosti by měly mít dobře opětovně použitelné datové sady.
Metodika Methodological Guidelines for Publishing Linked Data [41] je zaměřena
specificky na publikaci otevřených propojitelných dat. Doporučení jsou organizována na
základě životního cyklu s následujícími fázemi: specifikace, modelování, tvorba dat,
publikace a využití.
Jak je již z názvu patrné, Best Practices for Publishing Linked Data [18] je metodika
zaměřená na publikaci otevřených propojitelných dat. Metodika byla vytvořena v rámci
konsorcia W3C a má statut doporučení. Metodika popisuje nejlepší praktiky (best practices)
pro získávání podpory zainteresovaných stran, výběr datových sad, datové modelování,
volbu vhodné licence, tvorbu URI, využívání standardních slovníků a ontologií, převod dat
do formátu propojitelných dat, zpřístupnění strojově čitelných dat, informování
o dostupnosti dat a zajištění jejich dlouhodobé dostupnosti.
Tabulka 6 uvádí hodnocení výše představených metodik z hlediska naplnění požadavků
na metodiku publikace otevřených dat identifikovaných v [24]. Hodnoceny jsou metodiky
ve verzích dostupných v červenci 2014 a jsou hodnoceny následujícím způsobem [24]:
 Požadavek je hodnocen jako splněn (S), pokud metodika kromě obecného popisu
problémové oblasti obsahuje i konkrétní doporučení, návody či postupy, jak
požadavek řešit.
 Požadavek je hodnocen jako částečně splněn (Č), pokud je problémová oblast
v metodice popsána, ale metodika neobsahuje konkrétní návody či doporučení
pro řešení problémové oblasti.
 Požadavek je hodnocen jako nesplněn (N), pokud se problémovou oblastí
metodika nezabývá, nebo je zmíněna jen velmi povrchně.
8
Přeloženo do češtiny.
SODFG
ODIG
ODVSCR
MELODA
MGPLD
BPPLD
Vymezení rolí
Vyhodnocování poptávky po datech
Výběr a prioritizace datových sad
Přínosy otevřených dat
Odhadování pracnosti a nákladů
Vybírání poplatků
Zajištění souladu s legislativou
Analýza rizik
Podmínky užití
Minimalizace roztříštěnosti datových sad
Volba formátů dat
Propojení souvisejících datových sad
Posuzování dopadu na IS/ICT
POD
PO1
PO2
PO3
PO4
PO5
PO6
PO7
PO8
PO9
PO10
PO11
PO12
PO13
OGDTK
Požadavek
OGDUN
ID
ODH
Tabulka 6: Hodnocení metodik publikace otevřených dat, zdroj: [24]8
N
S
S
Č
N
Č
N
Č
S
N
S
N
N
N
S
S
Č
Č
S
Č
S
S
N
Č
Č
N
N
N
N
Č
N
N
N
N
Č
N
Č
N
N
S
S
S
Č
Č
N
S
S
S
N
Č
N
S
S
S
S
S
N
N
N
N
Č
Č
S
Č
N
N
Č
S
Č
Č
S
Č
Č
S
N
Č
N
N
S
N
Č
N
N
N
Č
N
S
N
S
Č
N
N
N
N
N
N
N
N
N
S
N
S
N
N
N
N
Č
N
N
N
N
N
S
S
Č
S
N
Č
N
Č
N
N
N
N
N
Č
Č
Č
S
N
ODIG
ODVSCR
MELODA
MGPLD
BPPLD
Postup publikace dat
Katalogizace dat
Zajištění kvality dat
Zajištění snadného přístupu
Aktualizace datových sad
Komunikační strategie
Nezávislost na centrálním portálu
Doporučený SW
Zohlednění různé velikosti orgánů VS
SODFG
PO14
PO15
PO16
PO17
PO18
PO19
PO20
PO21
PO22
POD
Požadavek
OGDTK
ID
OGDUN
ODH
28
S
Č
N
Č
N
S
S
Č
N
S
Č
N
Č
N
S
S
Č
N
N
Č
Č
N
N
S
S
Č
Č
Č
S
Č
N
Č
Č
S
S
N
N
N
N
Č
N
S
S
N
N
N
S
N
N
N
S
S
N
N
S
N
N
N
N
Č
S
N
N
N
N
Č
S
N
N
S
N
N
S
Č
Č
N
N
N
S
S
N
S
Č
N
N
Č
Č
S
N
N
Podrobnější komentář k hodnocení metodik lze najít v [24]. Je třeba ale uvést, že rozsah i
zaměření hodnocených metodik se liší. Např. MELODA poskytuje hlavně metodu, jak
hodnotit datové sady z hlediska snadnosti jejich dalšího využití. Metodika nedefinuje
proces publikace otevřených dat a ani to není jejím cílem. Hodnocení je tak třeba chápat
jako porovnání oblastí a problémů, kterým se jednotlivé metodiky věnují. Hodnocení
nevystihuje vhodnost či nevhodnost metodiky pro určité použití.
Open Government Data Toolkit (OGDTK) v řadě případů nepopisuje vlastní doporučení
pro dané oblasti, ale odkazuje na jiné metodiky a informační zdroje. Jako splněno jsou
hodnoceny pouze ty oblasti, které jsou v OGDTK pokryty vlastními doporučeními.
Odkazovanými metodikami jsou i Open Data Handbook, Guidelines on Open Government
Data for Citizen Engagement a Open Data Field Guide. Uživatelé tak mohou najít
doporučení pro oblasti nepokryté přímo v OGDTK např. v některé z těchto metodik.
Z provedeného hodnocení je zřejmé, že současné metodiky publikace otevřených dat se
zaměřují především na zajištění právní (PO9) a technické otevřenosti dat (PO11). Většina
metodik se také alespoň částečně zabývá otázkou komunikace s uživateli dat (PO19) a časté
je také uvedení alespoň nějakých doporučení pro výběr vhodných datových sad k publikaci
v podobě otevřených dat (PO3). Doporučení hodnocených metodik jsou také nezávislá na
centrálním datovém portálu (PO20).
5 Postup publikace otevřených propojitelných dat
Kromě softwarové platformy pro podporu publikace otevřených dat Open Data Node
(ODN) vznikají v rámci projektu COMSODE také metodická doporučení pro publikaci
otevřených dat. V této části jsou představeny jednotlivé kroky postupu publikace
otevřených dat, který je součástí metodiky Methodology for publishing datasets as open
data [29], jenž vznikla právě v rámci projektu COMSODE (dále jen Metodika
COMSODE).
Metodiku COMSODE tvoří 5 základních metodických prvků [29]:
 fáze – jednotlivé etapy procesu publikace otevřených dat, fáze se dále člení na
úlohy, tj. skupiny souvisejících činností;
Zvaná přednáška
29

průřezové aktivity – aktivity, které jsou prováděny ve všech fázích procesu
publikace otevřených dat, stejně jako fáze se dále člení na úlohy;
 artefakty – vstupy a výstupy úloh fází či průřezových aktivit;
 role – zodpovědnost, kterou zastává jedna nebo více osob či organizačních
jednotek;
 praktiky – doporučení či návod, jak postupovat při realizaci některé z úloh.
Samotný postup publikace otevřených dat pak probíhá v těchto čtyřech fázích [29]:
1. Tvorba plánu publikace otevřených dat
2. Příprava publikace
3. Realizace publikace dat
4. Archivace
Získávání a vyhodnocování zpětné vazby uživatelů otevřených dat je důležitým aspektem
úspěchu otevřených dat [21]. V Metodice COMSODE není získávání a vyhodnocování
zpětné chápáno jako samostatná fáze procesu publikace otevřených dat, ale prostřednictvím
průřezové aktivity Řízení komunikace je získávání a vyhodnocování zpětné vazby součástí
všech fází procesu publikace otevřených dat (viz obrázek 1).
Obrázek 1: Metodika COMSODE a zpětná vazba uživatelů dat, zdroj: [29]
V rámci Metodiky COMSODE je zpětná vazba využívána zejména k [29]:
 vyhodnocení poptávky po datových sadách,
 získání informací o nedostatcích a chybách v publikovaných datových sadách a
k následnému zvyšování kvality datových sad a zlepšování jejich publikace,
 vyhodnocení dopadu ukončení podpory či poskytování datových sad a zlepšování
postupů ve fázi Archivace.
V následujících sekcích jsou blíže popsány jednotlivé fáze procesu publikace otevřených
dat. Popisy jednotlivých úloh a souvisejících praktik lze pak najít v [29] a přílohách tohoto
výstupu [31], [30].
30
5.1
Tvorba plánu publikace otevřených dat
Přestože Metodika COMSODE předpokládá, že se publikace otevřených dat odehrává
v určitém politickém kontextu a v také v kontextu strategického řízení subjektu
poskytovatele dat, otázkami tvorby strategie a politik ve vazbě na otevřená data se nevěnuje
[29]. První fází procesu publikace otevřených dat tak je Tvorba plánu publikace otevřených
dat.
Cílem této fáze je analyzovat datové zdroje a vybrat datové sady, které mají být
publikovány jako otevřená data. Hlavním výstupem této fáze je plán publikace otevřených
dat. Tento plán by měl obsahovat [31]:
 vymezení cílů publikace otevřených dat;
 mapu datových zdrojů a datových sad;
 seznam datových sad s určením přínosů a rizik jejich publikace, odhadované
pracnosti publikace a cílovým stupněm otevřenosti;
 určení priorit publikace identifikovaných datových sad;
 harmonogram publikace datových sad;
 obsazení vymezených rolí.
5.2
Příprava publikace
Cílem fáze Přípravy publikace je připravit vybrané datové sady tak, aby mohly být
publikovány jako otevřená data v určeném formátu a za vhodných podmínek užití/licence.
V rámci této fáze by tak mělo dojít k určení struktury metadat, která budou popisovat
datové sady a budou zpřístupněna v datovém katalogu. Je doporučeno využívat standard
Data Catalog Vocabulary (DCAT)9. Dalším krokem je pak příprava samotných metadat pro
datové sady určené k publikaci.
Kromě přípravy metadata je třeba připravit samotné datové sady. Zejména navrhnout či
popsat datové schéma jednotlivých datových sad, a pokud jsou data publikována jako
otevřená propojitelná data, identifikovat vhodné existující ontologie a případně i navrhnout
vlastní, pokud dostupné ontologie nepokrývají zcela potřeby uvažovaných datových sad.
Dále je třeba vhodným způsobem zvolit identifikátory datových entit. V případě otevřených
propojitelných dat je součástí této úlohy návrh vzorů pro URI, které budou datové entity
identifikovat.
Součástí fáze je i výběr softwarových nástrojů a návrh, implementace a testování
automatizovaných ETL10 procedur, které budou zajišťovat transformaci dat z primárních
datových zdrojů do určeného cílového formátu a struktury. Tyto procedury také mohou
zajišťovat čištění a obohacování zdrojových dat.
Pro zajištění právní otevřenosti publikovaných datových sad je třeba určit, za jakých
podmínek užití nebo pod jakou licencí budou data zveřejněna. Je doporučováno využívat
standardní licence, jako jsou licence Creative Commons CC-BY 4.011, příp. právní nástroj
CC012 [30]. Není doporučováno vytvářet vlastní licence, nicméně pokud se již poskytovatel
dat rozhodne vlastní licenci formulovat, měl se snažit maximálně držet principů
uplatněných v licenci CC-BY 4.0 nebo CC0. Licence by neměla omezovat užití dat na
nekomerční účely a tvorbu odvozených datových sad (derivative works). Pro maximalizaci
9
http://www.w3.org/TR/vocab-dcat/
ETL – Extract, Transform and Load
11 http://creativecommons.org/licenses/by/4.0/legalcode
12 http://creativecommons.org/publicdomain/zero/1.0/legalcode
10
Zvaná přednáška
31
potenciálu dalšího využití datové sady by licence neměla vyžadovat, aby odvozené datové
sady byly publikovány pod stejnou licencí, jako původní datová sada (blíže viz [14]).
5.3
Realizace publikace dat
Cílem fáze Realizace publikace dat je realizovat samotnou publikaci připravených
datových sad na webu včetně publikace metadat. Dalším cílem je zajistit pravidelnou
údržbu a aktualizaci již publikovaných datových sad. Zajištění údržby datových sad se jeví
být jedním z aspektů úspěchu otevřených dat v delším časovém horizontu. Např. dle studie
Capgemini Consulting z roku 2013 96% zkoumaných zemí publikovala datové sady, které
nebyly pravidelně aktualizovány [35]. Zajištění dlouhodobé dostupnosti a údržby datových
sad je také jednou z dobrých praktik publikace otevřených propojitelných dat dle [18].
V této fázi je také významné získávání a vyhodnocování zpětné vazby od uživatelů
otevřených dat. Zpětná vazba může poskytovateli otevřených dat pomáhat odhalovat
nedostatky v publikovaných datech a díky tomu může být i cenným vstupem do činností
zajištění a zvyšování kvality dat [29] a může přispívat i ke zlepšení procesu publikace
otevřených dat jako takového [21].
Pro zajištění, že uživatelé budou moci zpětnou vazbu poskytnout, je doporučováno, aby
na webových stránkách poskytovatele dat byl zpřístupněn alespoň jeden elektronický kanál
pro tento účel [30]. Např. se může jednat o diskusní fórum, kontaktní email či formulář.
5.4
Archivace
Přestože by u publikovaných datových sad měla být zajištěna jejich dlouhodobá dostupnost
a pravidelná údržba, může nastat situace, v jejímž důsledku již nebude možné datovou sadu
dále udržovat, nebo dokonce ani dále poskytovat. Může se jednat např. o změnu legislativy,
v jejímž důsledku poskytovatel dat přestane nebo již nebude oprávněn pořizovat data, která
byla obsažena v určité datové sadě, např. z důvodu, že již nebude vykonávat určitou
činnost, jenž doposud vykonával. K ukončení poskytování datové sady by teoreticky mohlo
vést i rozhodnutí soudu či jiného příslušného orgánu, např. v situaci, kdyby bylo shledáno,
že určitá datová sada je publikována v rozporu se zákonem.
Cílem fáze Archivace tak je ukončit životní cyklus datové sady. Je rozlišováno
ukončení podpory a ukončení poskytování datové sady. V případě ukončení podpory
datové sady zůstává datová sada dostupná uživatelům, ale již nebude dále aktualizována, tj.
nebudou přibývat nová data a ani nebudou opravovány chyby v již publikovaných datech.
Při ukončení poskytování datové sady dochází ke znepřístupnění dříve publikovaných dat.
Katalogizační záznam datové sady by měl zůstat i nadále přístupný a měl by obsahovat
informaci, že datová sad již není déle dostupná [30]. Pokud je datová sada, jejíž údržba
nebo poskytování je ukončeno, nahrazena jinou datovou sadou, je vhodné uvést odkaz na
tuto datovou sadu.
Protože ukončení podpory či poskytování datové sady se patrně dotkne jejích uživatelů,
je v této fázi velmi důležitá komunikace. Kromě příslušné úpravy katalogizačních záznamů
je třeba informovat uživatele o změně stavu datové sady i jinými vhodnými kanály, např.
v rámci novinek na webu poskytovatele.
6 Nástroje
V předcházející kapitole byl představen obecný postup publikace otevřených dat. Realizaci
činností v jednotlivých fázích tohoto postupu pak může být vhodné podpořit softwarovými
nástroji. Z navrženého postupu je také zřejmé, že publikace otevřených dat není záležitostí
32
čistě technickou, ale vyžaduje i manažerské aktivity, jako je řízení přínosů, rizik,
komunikace nebo řízení samotné publikace otevřených dat prostřednictvím plánu publikace
otevřených dat. Zmínit lze i potřebu stanovení vhodných podmínek užití dat a zajištění
souladu publikace otevřených dat s legislativou. Paleta softwarových nástrojů
uplatnitelných při publikaci otevřených dat tak může být dosti široká a může v širším pojetí
zahrnovat jak např. kancelářské aplikace, nástroje pro podporu spolupráce či jiné obecně
použitelné nástroje, které své uplatnění naleznou např. při přípravě plánu publikace
otevřených dat nebo následně při řízení celé iniciativy, tak i specializované nástroje
zaměřené přímo na podporu přípravy, publikace, údržby a archivace datových sad.
Vzhledem k šíři možných nástrojů se zaměříme v této kapitole pouze na nástroje spadající
do druhé skupiny, specificky pak na nástroje pro publikaci a využití otevřených
propojitelných dat.
Pro podporu publikace a využití otevřených propojitelných dat je k dispozici celá řada
nástrojů vytvářených jak výzkumnými institucemi, tak i podnikatelskými subjekty. Na
tvorbu nástrojů pro tuto oblast se zaměřuje i několik výzkumných projektů financovaných
z prostředků Evropské unie (viz [25]). Jedním z těchto projektů je i projekt LOD2, jehož
hlavním výstupem je sada integrovaných nástrojů pro publikaci a využití otevřených
propojitelných dat označovaná jako LOD2 Stack 13 [1]. Nástroje v LOD2 Stacku podporují
jednotlivá stadia životního cyklu otevřených propojitelných dat, který je znázorněn na
obrázku 2.
Obrázek 2: Životní cyklus otevřených propojitelných dat, zdroj: [1]
13
Po skončení projektu LOD2 bude LOD2 Stack dále rozvíjen v rámci projektů GeoKnow a
DIACHRON pod označením Linked Data Stack [1].
Zvaná přednáška
33
LOD2 Stack tak obsahuje nástroje pro podporu [1], [39]:
 extrakce dat – získávání dat z datových zdrojů a jejich převod do podoby
otevřených propojitelných dat;
 ukládání dat – ukládání dat ve formátu RDF a dotazování nad uloženými daty;
 vytváření dat – vytváření dat ve strukturované podobě propojených na příslušné
slovníky a ontologie;
 propojování dat – vytváření a údržba propojení mezi datovými zdroji včetně
automatizace tvorby propojení;
 klasifikace dat – klasifikace a obohacování dat pomocí využívání sdílených
slovníků a ontologií;
 analýzy kvality dat – analýza dat a zjištění úrovně jejich kvality např. na základě
kontextu nebo metadat o jejich původu,
 údržby dat a jejich oprav – zajištění podpory pro transparentní úpravy slovníků a
ontologií;
 procházení dat a vyhledávání v datech – zajištění funkcí, které umožní otevřená
propojitelná data procházet, vyhledávat v nich a vizualizovat je.
Vzhledem k velkému počtu komponent zařazených do LOD2 Stacku je jejich popis nad
rámec tohoto příspěvku. Zájemci mohou najít jejich popis např. v [39]. Další informace
jsou k dispozici na webových stránkách projektu LOD2 14.
Dalším z výzkumných projektů, v rámci kterého jsou vytvářeny nástroje pro publikaci
otevřených (nejen) propojitelných dat, je projekt COMSODE. V tomto projektu je
vytvářena publikační platforma Open Data Node [16] a je jí věnována jiná přednáška
letošního ročníku konference DATAKON.
7 Závěr
Orgány veřejné správy mají v držení značné množství dat, která mohou být využita pro
tvorbu nových aplikací či služeb. Publikace dat veřejné správy ve formátu otevřených dat
tak slibuje značné přínosy jak pro posílení transparentnosti veřejné správy, tak i představuje
příležitost pro rozvoj inovací. Publikace a následné využívání otevřených dat pak také může
vést k ekonomickým přínosům.
Ačkoli zpřístupňování dat veřejné správy pro další využití není záležitost zcela nová,
v rámci iniciativ otevřených dat nabývá tato aktivita na dříve nebývalé intenzitě [12]. Mimo
to se poskytovatelé dat a osoby odpovědné za realizaci publikace otevřených dat potýkají
s celou řadou problémů, ať se již jedná např. o ne vždy nastavené odpovídající procesy a
odpovědnosti nebo o problémy právní povahy vyplývající např. z legislativy upravující
ochranu osobních údajů. Intenzita iniciativ otevřených dat a zároveň existence problémů
doprovázejících publikaci OD poukazují na skutečnost, že pro publikaci otevřených dat
jsou zapotřebí nejen softwarové nástroje, ale i metodická doporučení, která by umožnila
poskytovatelům otevřených dat získat potřebné znalosti a pomohla jim publikaci
otevřených dat lépe zvládat.
V tomto příspěvku jsme analyzovali dva z možných přístupů k publikaci otevřených
dat. Přístup shora-dolů charakteristický provedením analýzy dostupných datových sad,
výběrem vhodných datových sad k publikaci a sestavením plánu jejich publikace. Tento
přístup umožňuje lépe řídit publikaci otevřených dat, nicméně od rozhodnutí publikovat
14
http://lod2.eu
34
otevřená data do publikace prvních datových sad patrně uplyne více času, než v případě
přístupu zdola-nahoru. Tento přístup charakterizuje výběr jedné či několika málo datových
sad, které jsou relativně rychle publikovány, a postupné učení se ze zkušeností. Nicméně
nevýhodou tohoto přístupu může být, že ne vždy je zřejmé, kterými datovými sadami je
vhodné začít.
Pro usnadnění publikace otevřených dat vznikají metodiky pro jejich publikaci. Některé
z těchto metodik byly v tomto příspěvku stručně představeny a porovnány z hlediska jejich
obsahu či problémových oblastí, kterým se věnují.
V rámci projektu COMSODE byla vytvořena metodika Methodology for publishing
datasets as open data [29] a v tomto příspěvku byl představen postup publikace otevřených
dat navržený v této metodice. Postup publikace otevřených dat Metodiky COMSODE se
skládá ze čtyř fází: (1) Tvorba plánu publikace otevřených dat, (2) Příprava publikace,
(3) Realizace publikace dat a (4) Archivace. První fáze je zaměřena na analýzu dostupných
datových sad a výběr vhodných datových sad k publikaci ve formátu otevřených dat. Cílem
druhé fáze je připravit zvolené datové sady k publikaci, tj. zejména připravit transformaci
dat do cílových strojově čitelných formátů, opatřit datové sady metadaty a zvolit vhodnou
licenci pro zajištění jejich právní otevřenosti. Třetí fáze je pak zaměřena na realizaci
publikace datových sad společně s jejich metadaty a následné údržby a aktualizace
datových sad. Poslední fáze procesu publikace otevřených dat se pak věnuje ukončení
životního cyklu datové sady, tj. ukončení její aktualizace nebo ukončení jejího poskytování.
Publikace otevřených dat zahrnuje realizaci řady činností a je tak vhodné uvažovat
o podpoře publikace pomocí softwarových nástrojů. Na vývoj nástrojů pro podporu
publikace a využití otevřených propojitelných dat se zaměřují i výzkumné projekty, jako
např. LOD2 nebo COMSODE. V rámci prvního zmíněného projektu byla vytvořena
integrovaná sada nástrojů LOD2 Stack, ve druhém uvedeném projektu je vyvíjena
platforma pro publikaci otevřených dat Open Data Node.
Přestože metodiky publikace otevřených dat vznikají, stále existují oblasti, které
v těchto metodikách nejsou vždy pokryty. Další výzkum by se tak mohl věnovat např.
dopadu publikace otevřených dat na IS/ICT orgánů VS, které se otevřená data rozhodnou
publikovat, nebo hledání vhodných metod pro hodnocení nákladů a přínosů otevřených dat.
Poděkování: Tento příspěvek byl vypracován v rámci projektu COMSODE, který je
financován Sedmým rámcovým programem Evropské unie pod grantovým číslem 611358.
Literatura
1.
2.
3.
4.
5.
Auer, S.: Introduction to LOD2. In: Linked Open Data – Creating Knowledge Out of
Interlinked Data: Results of the LOD2 Project, LNCS 8661, S. Auer, V. Bryl and
S. Tramp (Eds.), Springer (2014), 1-17.
Bauer, F., Kaltenböck, M.: Linked Open Data: The Essentials. Edition
mono/monochrom, Vienna, 2011.
Berners-Lee,
T.:
Linked
Data
Design
Issues,
2006.
http://www.w3.org/DesignIssues/LinkedData.html
Berners-Lee, T., Fielding, R., Masinter, L.: RFC 3986 - Uniform Resource Identifier
(URI): Generic Syntax, 2005. http://tools.ietf.org/html/rfc3986
Bizer, C., Heath, T., Berners-Lee, T.: Linked Data - The Story So Far. Special Issue on
Linked Data, International Journal on Semantic Web and Information Systems, 2009.
Zvaná přednáška
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
35
Buchalcevová, A.: Metodiky budování informačních systémů. Nakladatelství
Oeconomica, Praha, 2009.
Buchholtz, S., Bukowski, M., Śniegocki, A.: Big and open data in Europe: A growth
engine or a missed opportunity? 2014. http://www.bigopendata.eu/wpcontent/uploads/2014/01/bod_europe_2020_full_report_singlepage.pdf
Česká obchodní inspekce: Licence pro používání zveřejněných dat, 2013.
http://www.coi.cz/cz/spotrebitel/open-data-databaze-kontrol-sankci-a-zakazu/opendata-licence/
Česká obchodní inspekce: Open Data – Databáze kontrol, sankcí a zákazů, 2013.
http://www.coi.cz/cz/spotrebitel/open-data-databaze-kontrol-sankci-a-zakazu/
Český telekomunikační úřad. ČTÚ zpřístupnil první otevřená data, 2014.
http://www.ctu.cz/aktuality/tiskove-zpravy.html?action=detail&ArticleId=11382
Český telekomunikační úřad: Otevřená data Českého telekomunikačního úřadu:
Použitý
postup
a
dosažené
výsledky,
2014.
http://www.isss.cz/archiv/2014/download/prezentace/ctu_drtina.pdf
Davies, T.: Supporting open data use through active engagement, 2012.
http://www.w3.org/2012/06/pmod/pmod2012_submission_5.pdf
Deloitte:
Market
Assessment
of
Public
Sector
Information,
2013.
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/198905/
bis-13-743-market-assessment-of-public-sector-information.pdf
Dulong De Rosnay, M., Tsiavos, P., Artusio, C., Elli, J., Ricolfi, M., Sappa, C.,
Vollmer, T., Tarkowski, A.: D5.2. Licensing Guidelines, 2014. http://www.lapsiproject.eu/sites/lapsi-project.eu/files/D5.2LicensingGuidelinesPO.pdf
Executive Office of the President: Open Data Policy – Managing Information as an
Asset, 2013. http://www.whitehouse.gov/sites/default/files/omb/memoranda/2013/m13-13.pdf
Hanečák, P.: Open Data Node – what it is, what it does, what is next.
http://www.comsode.eu/index.php/2014/06/open-data-node-what-it-is-what-it-doeswhat-is-next/
Hausenblas, M.: 5 star Open Data, 2012. http://5stardata.info/
Hyland, B., Atemezing, G., Villazón-Terrazas, B.: Best Practices for Publishing
Linked Data, 2014. http://www.w3.org/TR/ld-bp/
Chlapek, D., Kučera, J., Nečaský, M.: Koncepce katalogizace otevřených dat VS ČR
(zkrácená
verze),
2012.
http://www.mvcr.cz/soubor/koncepce-katalogizaceotevrenych-dat-vs-cr-pdf.aspx
Chlapek, D., Kučera, J., Nečaský, M.: Metodika publikace otevřených dat veřejné
správy ČR verze 1.0, 2012. http://www.mvcr.cz/soubor/metodika-publ-opendata-verze1-0-pdf.aspx
Janssen, M., Zuiderwijk, A.: Open data and transformational government.
In: Proceedings of the Transforming Government Workshop 2012 (tGov2012), Brunel
University, London (2012).
Klyne, G., Carroll, J. J., McBride, B.: RDF 1.1 Concepts and Abstract Syntax, 2014.
http://www.w3.org/TR/rdf11-concepts/
Kroes, N.: Digital Agenda and Open Data, 2012. http://europa.eu/rapid/pressrelease_SPEECH-12-149_en.htm
Kučera, J.: Methodologies for publication of Open Government Data, 2014.
http://nb.vse.cz/~xkucj30/dissertation/Kucera_OGD_methodologies_EN_v1.pdf
36
25. Linked Data Europe - Programme. http://www.linkeddataeurope.eu/?page_id=326
26. Office of Management and Budget, Office of Science and Technology Policy: Project
Open Data. http://project-open-data.github.io/
27. Open Data Institute, The: Guides. http://theodi.org/guides
28. Open
Knowledge
Foundation:
The
Open
Data
Handbook,
2012.
http://opendatahandbook.org/pdf/OpenDataHandbook.pdf
29. Nečaský, M. Chlapek, D., Klímek, J., Kučera, J., Maurino, A., Rula, A., Konecny, M.,
Vanova, L.: Deliverable D5.1: Methodology for publishing datasets as open data,
2014.
http://www.comsode.eu/wp-content/uploads/D5.1Methodology_for_publishing_datasets_as_open_data.pdf
Annex 1: Documentation of Practices, 2014. http://www.comsode.eu/wpcontent/uploads/Annex1_D5.1-Documentation_of_practices.pdf
Annex
2:
Master
spreadsheet,
2014.
http://www.comsode.eu/wpcontent/uploads/Annex2_D5.1-Methodology_Master_Spreadsheet.xlsx
32. Socrata: Open Data Field Guide, 2014. http://www.socrata.com/open-data-field-guide/
33. Sunlight Foundation: Ten Principles for Opening Up Government Information, 2010.
http://sunlightfoundation.com/policy/documents/ten-open-data-principles/
34. Tajtl,
M.:
Otevírání
dat
a
využití
nástroje
ODN,
2014.
http://www.cssi.cz/cssi/system/files/all/Seminar_CSSI_6-6-2014_Tajtl.pdf
35. Tinhold, D.: The Open Data Economy: Unlocking Economic Value by Opening
Government
and
Public
Data,
2013.
https://www.capgeminiconsulting.com/ebook/The-Open-DataEconomy/files/assets/downloads/publication.pdf
36. Ubaldi, B.: Open Government Data: Towards Empirical Analysis of Open Government
Data Initiatives. OECD Working Papers on Public Governance, No. 22, OECD
Publishing, 2013. http://dx.doi.org/10.1787/5k46bj4f03s7-en
37. United Nations: Guidelines on Open Government Data for Citizen Engagement, 2013.
http://workspace.unpan.org/sites/Internet/Documents/Guidenlines%20on%20OGDCE
%20May17%202013.pdf
38. University Rey Juan Carlos: MEtric for reLeasing Open DAta: Version 3.10, 2014
http://www.meloda.org/full-description-of-meloda/
39. Van Nuffelen, B., Janev, V., Martin, M., Mijovic, V., Tramp, S.: Supporting the
Linked Data Life Cycle Using an Integrated Tool Stack. In: Linked Open Data –
Creating Knowledge Out of Interlinked Data: Results of the LOD2 Project, LNCS
8661, S. Auer, V. Bryl and S. Tramp (Eds.), Springer (2014), 108-129.
40. Vickery, G.: Review of recent studies on PSI re-use and related market developments,
2011.
http://ec.europa.eu/information_society/policy/psi/docs/pdfs/report/psi_final_version_f
ormatted.docx
41. Villazón-Terrazas, B., Corcho, O.: Methodological Guidelines for Publishing Linked
Data, 2011. http://delicias.dia.fi.upm.es/wiki/images/7/7a/07_MGLD.pdf
42. W3C
SPARQL
Working
Group:
SPARQL
1.1
Overview,
2013.
http://www.w3.org/TR/sparql11-overview/
Zvaná přednáška
37
43. World Bank: Open Government Data Toolkit, 2014. http://data.worldbank.org/opengovernment-data-toolkit
Annotation:
Linked Open Data – methodologies, approaches, tools and the current practices
Open Data is data published on the Internet for free reuse and redistribution in open and machinereadable formats. Governments hold large amount of valuable datasets, therefore opening up
government data is seen as a way to increase transparency and foster economic growth. Open
Government Data (OGD) is expected to bring significant benefits to citizens, businesses and
governments as well. However approaches to publication of OGD differ among the public sector
bodies and the necessary processes and organizational structures are not always in place. In this paper
we analyse the top-down and the bottom-up approach to publication of OGD and we introduce some
of the existing OGD publication methodologies that might provide the required guidelines and best
practices for OGD publication. Finally, we propose a generic workflow for OGD publication
developed in the COMSODE project.
Na strastiplnej ceste k otvoreným päťhviezdičkovým
údajom v Slovenskej republike
Miroslav LÍŠKA
Datalan, a.s.
Galvaniho 17A, 821 04 Bratislava
[email protected]
Abstrakt. Strojové spracovanie informácií s ohľadom na ich význam je pomerne
prebádaná oblasť, no ukazuje sa, že až Sémantický web dokázal túto disciplínu
vytiahnuť zo znalostných laboratórií a presvedčiť, že pracovať s dátami bez ohľadu na
ich význam je málo efektívne a veľmi nákladné. Mimo komerčných aplikácií niet
azda lepšej oblasti ako oblasť verejnej správy a samosprávy, kde je žiadúce, aby dáta
mali význam, resp. aby boli v tvare tzv. prepojiteľných dát (LinkedData). I keď sú
dáta veľmi roztrúsené, sémanticky by sa dali ľahko pospájať a použiť na rozličný účel
a to nepomerne lacnejšie a rádovo efektívnejšie než sa to deje dnes prostredníctvom
nákladnej integrácie. Čo však krajina, to iný dosiahnutý stupeň kvality verejných dát.
Na Slovensku je to z pohľadu prepojiteľných otvorených dát zatiaľ veľká bieda,
konkrétne štandardizačný proces nad verejnými dátami v gescii Ministerstva Financií
SR je technologicky desaťročie dozadu. Čo je však ešte horšie, existuje tu dokonca
nevôľa pustiť sa týmto smerom aj od organizácií kde by ste to nečakali. Prečo je tomu
tak, pokúsim sa vysvetliť v tomto príspevku. Je síce subjektívny, nevyvážený, no
autor verí že vyprovokuje diskusiu ktorá na konci dňa prispeje k tomu aby verejné
dáta mali požadovanú kvalitu, aby Slovensko prestalo tak dramaticky zaostávať
v tejto oblasti.
Klúčové slova: sémantický web, štátna správa, umelá inteligencia, prepojené
otvorené dáta, ontológie
1 Úvod
Je krásny neskoroletný podvečer kedy som sa vybral na obhliadku mojej vysnenej záhrady.
Prichádzam na miesto, a už z diaľky vidím, že je to To miesto. Dívam sa naň, a už si
predstavujem, kde budú rásť jablone, hrušky či slivky. A potom začnú prichádzať otázky.
Aká je tu vlastne pôda, a aké sú tu ročné teploty? Je toto miesto už intravilán alebo
extravilán obce? Do ktorého katastra pozemok patrí? Kto presne je vlastníkom?Nie je tam
nejaké obmedzenie užívania pôdy? Nejaká ťarcha? Môžem si tam postaviť murovanú
chatku? Neplánuje sa tadeto vedenie nejakej cesty? A čo dosah inžinierskych sietí?
Prípadne aké sú dane a poplatky konkrétne v tejto lokalite?
Keď si toto všetko uvedomím, môžem sa pripravovať na niekoľko týždňovú analýzu
v upršaných jesenných dňoch, na obiehanie množstva úradov, navštívenie ich webových
stránok (au) na nájdenie požadovaných údajov. A tie budú vskutku rozmanite umiestnené.
Niektoré nájdem priamo v rámci textu na stránke, niektoré v excelovských, wordovských,
pdf alebo iných prílohách a mnohé nenájdem vôbec.
40 Na strastiplnej ceste k otvoreným päťhviezdičkovým údajom v Slovenskej republike
Bolo by ideálne, keby boli dáta na jednom mieste. Našťastie také miesto je [19], a hoc je
to zatiaľ najlepší počin, situácia so slovenskými verejnými dátami je vskutku tragická.
Na obrázku 1 je znázornený portál data.gov.sk, ktorý má ambíciu byť centrom
obsahujúcim alebo referejúcim rôzne datasety verejnej správy. V súčasnosti je tam 206
datasetov čo je akiste veľmi málo. Horšie ale je, že základný problém nie je len v kvantite
dát, ale aj kvalite. Problém s kvalitou je založený na tom, že dáta nemajú význam a nijako
spolu nesúvisia. Sú to len “hlúpe” písmenká a číselká. S takýmito dátami sa nedá robiť ako
so znalosťami a navyše, nemôžem ani len pomýšľať nad dopytmi ktoré kombinujú viaceré
datasety. Na obrázku 1 je napr. vidieť Dataset geodetov a Dataset centrálnych zmlúv a
podobne. Neviem položiť takúto otázku: Vrát mi všetkých geodetov ktorý uzatvorili nejakú
zmluvu so štátnou správou v októbri minulého roka. Takisto ďalšia zaujímavá vec je
nemožná. Vyberiem si daného geodeta a pozriem si kde pracuje. V záujme väčšej dôvery sa
chcem o tejto spoločnosti dozvedieť všetko, čo sa len dá. Či má so štátom uzatvorenú
nejakú zmluvu, či táto spoločnosť dostala nejakú finančnú pomoc, či nemá dlhy voči
poisťovniam, alebo daňové nedoplatky a podobne.
V mojom prípade, kedy sa chcem dozvedieť niečo o vysnenom pozemku pre založenie
ovocného sadu by bolo akiste prínosné, keby som len jednoducho označil daný pozemok na
mape a vypýtal si všetko, čo s ním súvisí. Všetky dotknuté materiály ako rôzne zmluvy
ktoré súvisia s obcou, územný plán, rôzne meteorologické dáta, či dáta zo životného
prostredia o blízkych skládkach a podobne.
Aj keď bolo položených množstvo otázok a problematika je veľmi komplexná, riešenie
je jednoduché, elegantné, 10 rokov staré. Volá sa Sémantický web.
Obr. 1 – Niektoré datasety portálu http://data.gov.sk
Zvaná přednáška
41
2 Sémantický web
Sémantický web [37] (Web 3.0) je nová generácia webu. Rozvíja a stojí za ním konzorcium
W3C [29], hlavný a najdôležitejší hráč v oblasti štandardov webu. Môžeme povedať že je
to nová generácia informatiky, aj keď sa jedná v zásade len o implementáciu klasických a
známych metód umelej inteligencie do prostredia webu. Lenže ten dominuje nielen na
internete, ale aj intranete, čiže sémantický web získava na obrovskom vplyve. Sémantika je
význam a teda sémantický web je významový web. Čiže dáta na webe už majú význam.
Nie sú to len “hlúpe” písmenká a číselká, sú to dáta s reálnym významom. Presnejšie
povedané, sú to znalosti [21]. A znalosti sú zapísané tvrdeniami, čiže sémantická databáza
je vlastne databáza tvrdení. Tvrdenie je reprezentované trojicou Subjekt – Predikát –
Objekt, pričom množina tripletov vytvára graf (sieť). Napr. tvrdenia
http://sk.linkedin.com/in/miroslavliska/ rdf:type foaf:Person .
http://sk.linkedin.com/in/miroslavliska/ foaf:givenName “Miroslav” .
http://sk.linkedin.com/in/miroslavliska/ foaf:familyName “Líška” .
hovoria, že to čo je moja domovská stránka na linkedin predstavuje osobu, mňa. Kým
zatiaľ napr. o FIIT [8] by to bolo povedané takto:
http://fiit.stuba.sk/ rdf:type foaf:Organization .
http://fiit.stuba.sk/ foaf:name “Fakulta informatiky a informačných technológií” .
Asi najzaujímavejšia časť sémantického webu sa venuje strojovému odvodzovaniu
nových znalostí. Odvodzovanie nových znalostí je vlastne odvodzovanie nových tripletov,
ktorý majú status odvodené, kým zatiaľ pôvodné triplety sú tzv. stanovené. Samotné
odvodzovanie je aplikácia rôznych znalostných pravidiel, ich zreťazenia a podobne. Ak
mám napr. jeden takýto triplet:
http://www.semamtickyweb.sk/stuff/lukasko foaf:givenName “Lukáš” .
tak z neho sa dá odvodiť že
http://www.semamtickyweb.sk/stuff/lukasko rdf:type foaf:Person .
Čiže ak nejaký zdroj má prvé meno, tak je Osoba. Pretože vlastnosť prvé meno sa
používa len v súvislosti s osobami. Presnejšie povedané, definícia vlastnosti prvé meno je
že jej doména je Osoba a odvodzovanie bolo typu rdfs:domain.
Sémantické databázy sú teda databázami tripletov, niekedy sú nazývané natívne
tripletové databázy, alebo grafové databázy. Rozlišovanie medzi dobrou alebo zlou
sémantickou databázou sa dá uskutočniť prostredníctvom zistenia, koľko tripletov dokáže
daná databáza efektívne spracovávať, aké rýchle sú vstavané reasonery ktoré práve robia
základný procesing ako načrtnuté rdfs:domain odvodzovanie, aká rýchla je odozva
SPARQL dotazov [38], ktorý sa ako jazyk natívne používa na dopytovanie grafu a
podobne. Aby sa výsledky pre dotazy sa vrátili čo najrýchlejšie, tak sa odvodzovanie
vykonáva už pri vstupe dát do DB, čo sa nazýva dopredné zreťazenie [21]. Dopredné
zreťazenie vyzerá, že je veľmi dôležitá vlasnosť v komerčných riešeniach. Situácie, kedy je
DB už príliš veľká a odvodzovanie trvá buď dlho, alebo záťaž je enormná dochádza ku
presmerovaniu dopytu na kópiu DB v klasteri. Čiže kým sa odvodzujú nové dáta na jednom
servery, druhý obsluhuje používateľské dotazy, čím nedochádza k výpadku výkonu.
2.1
URI – referencovateľný identifikátor
Úlohou URI identifikátora [39] je identifikovať niečo, nejakú vec, osobu, udalosť atď.
prostredníctvom webovej referencie. Pozor, URI nie je URL. URL [40] je čo sa mi má
zobraziť keď zadám nejakú adresu do prehliadača, kým URI len identifikuje niečo cez
internetový odkaz, a stránka nemusí ani existovať. Platí ale, že každé URL je zároveň aj
URI. Napr. http://www.datalan.sk je URL lokátor a zároveň i URI identifikátor spoločnosti
Datalan, a.s.. Nás ale zaujíma primárne URI identifikátor. Všetko čo má URI identifikátor
sa nazýva RDF zdroj [36]. RDF zdroj predstavuje niečo identifikovateľné cez URI.
Množina RDF zdrojov a ich vzájomných vzťahov tvorí tzv. ontológiu.
2.2
Ontológie
Ontológie sú kľúčovým stavebným kameňom sémantiky. Sú to znalosti o nejakej doméne.
Vždy sa jedna o ontológiu niečoho. Napr. Ontológia liekov, ontológia osôb, ontológia
realít, atď. Ontológia liekov hovorí, ako sa lieky delia, aké majú vlastnosti, vzťahy.
V horeuvedených tvrdenia som použil ontológiu RDF keď som o zdroji mojej domovskej
stránke povedal, že má nejaký typ pomocou vlastnosti rdf:type. To aký je to typ som opäť
povedal cez ontológiu FOAF [27], kde som definoval že som osoba, tj. foaf:Person, pričom
som navyše definoval aj ako sa volám cez vlastnosti foaf:givenName a foaf:familyName.
Čiže ontológia FOAF sa používa na opis osôb, organizácií, ich rôznych vzťahov. Pozn.:
jedným z najznámejších vzťahov je asi foaf:knows, ktorým sa dá vytvoriť sociálnu sieť.
2.3
FiveStar OpenData
Samotný šéf konzorcia W3C Tim Berners-Lee, ktorý ako prvý vytvoril web definovaním
protokolu HTTP [33] už vtedy vedel, že klasický web, kde dáta nemajú význam má svoje
dni spočítané. Denne pribúda na webe obrovské množstvo obsahu ktorý keď nemá
definovaný význam, tak sa vyhľadávanie stáva čoraz ťažšie a nepresnejšie. V spojitosti
s definovaním nových štandardov pre sémantický web ako RDF, či OWL [34] alebo
SPARQL, Tim Berners-Lee definoval tzv. 5 hviezdičkovú stupnicu kvality otvorených dát
[2], ktorá je zobrazená na obrázku 2.
Obr. 2 – klasifikácia FiveStar Open data
Zvaná přednáška
43
Čím viac hviezdičiek, tým sú dáta (či už otvorené alebo nie) kvalitnejšie z pohľadu ich
strojového spracovania. Je všeobecne známe, že napr. z dátami v exceloch sa pracuje lepšie
než s dátami v PDF formáte, no na druhej strane zase pokiaľ sú dáta v CSV, resp. XML
[41] tak to je ešte lepšie než excely. Čiže to sme sa dostali na 3 hviezdičky. Ak však
začnem dáta vnímať ako RDF zdroje, tak ich môžem prostredníctvom ontológií pridať im aj
význam, čiže sme na 4 hviezdičkách. Ak navyše použijem štandardizované ontológie ako
napr. FOAF pokiaľ mám dáta o ľuďoch, alebo GeoNames [11] ako definovať geografické
dáta a mnohé iné, dostávam sa na najvyššiu možnú úroveň 5 hviezdičiek, ktorá sa nazýva
LinkedData. A to je to podstatné, čo je dôležité pre verejné dáta. Keby boli napr. datasety
Register geodetov a Register pharmaceutov reprezentované cez prepojené dáta, tj. v tvare
tripletov, tak by sa s tými dátami pracovalo veľmi ľahko, logicky a efektívne. Už len keby
som tieto dva datasety vložil do jednej databázy, automaticky mi vzniknú prepojenia cez
foaf:Person triedu, pretože oba datasety sú o osobách, takisto mohli by sa prepojiť cez
niektoré časti adresy, ako napr. rovnaké mesto, ulica, či dokonca dáta by sa prepojili aj cez
prípadné rovnaké mená, priezviská, atď. Potom by som mohol veľmi jednoducho
vykonávať takéto dopyty: Vrát mi geodetov a pharmaceutov z Bratislavy Staré Mesto.
Alebo, vrát mi všetky osoby ktoré sa volajú Slávko Líška, a podobne.
3 Aktuálny žalostný stav sémantiky v otvorených dátach
V tejto kapitole sa pokúsim opísať aktuálny stav kvality verejných dát na Slovensku, hoc
subjektívne. V gescii Ministerstva Financií SR prebieha proces štandardizácie verejných
dát, ktorého produktom sú Štandardy pre informačné systémy verejnej správy [16]. Ako
zástupcovi ITAS [] sa nám dostalo pocty zúčastňovať sa týchto stretnutí. Tému
sémantického webu, resp. kvality otvorených sme ihneď vytiahli na stôl. Samozrejme že
predstavitelia verejnej správy nemali o téme žiadne informácie, čo nie je nič nové na
Slovensku, a ďalší dôležitý zástupca ako SOIT [25], či opedata.sk [22] niečo o
problematike len čítali. Bohužiaľ, tieto spomenuté organizácie, resp. ich niektorí konkrétni
zástupcovia sa postavili k téme úplne negatívne. “Teraz nie je na to čas, ani priestor, aby
sme sa tomu venovali”. Pochopiť sa to dá, ak si predstavíme že ich čas konzumuje úsilie
s desaťročie starým prístupom. Žiadne štandardizované ontológie na popis verejných dát,
žiadne adoptovanie odporučení na tvorbu efektívnych (perzistentných) URI identifikátorov.
Nič také. Ich zámer je všetko si urobiť na novo po svojom. “To nevadí že v tomto
zaostávame za svetom. My ideme správnou cestou.” Debata teda je, ako má vyzerať popis
údajov. Ako sa majú volať tie či oné atribúty, či to má byť ValidFrom alebo EffectiveFrom,
atď. Na obrázku 3 môžete vidieť aktuálne riešený problém ako reprezentovať číselník obcí.
<CodelistItem>
<ItemCode>100</ItemCode>
<ItemName language=”sk”>Bratislava</ItemName>
<ItemName language=”en”>Pressburgh</ItemName>
<AdditionalContent>Má dvojúrovňovú štruktúru, keďže ...</AdditionalContent>
<Note language=”sk”>Meno tejto obce je fiktívne.</note>
<Includes>Krajské mesto</Includes>
<ValidFrom>15.01.2002</ValidFrom>
<EffectiveFrom>02.02.2002</EffectiveFrom>
<EffectiveTo>03.03.2003</EffectiveTo>
<CodelistItem>
Obr. 3 – Príklad súčasne diskutovaných štandardov
Prvá vec je, že tie pojmy ktoré tam vidíte, tj. CodelistItem, ItemCode, ItemName
predstavujú desaťročie starý prístup k reprezentácii dát. Aby som to vysvetlil, tak tým
desaťročím myslím to, že sémantický web má už viac ako desať rokov, a hlavnou vecou je
použitie ontológií, ideálne štandardizovaných, aby mali údaje význam. Nič také v danom
príklade nenájdete. Druhá vec je, že z danej definície vôbec neviem, že sa jedná o obec.
A ako bude vyzerať reprezentácia povedzme krajov? Zase tam bude CodelistItem,
ItemCode … atď? A čo keď niečo iné má tiež kód 100? Napr. nejaká odroda hrušky.
Nebude sa to potom miešať? Samozrejme bude. Čo je ale najhoršie na tomto prístupe?
Keby som chcel opäť skombinovať Dataset geodetov a Dataset pharmaucetov v takomto
formáte, musel by som to urobiť integračne, tj. musel by som urobiť mapovanie a dáta
vložiť do nejakej novej databázy ktorej relačný model by pokrýval rozsah predmetných
datasetov. Až potom by som môhol dopytovať nad takýmito dátami. Na odvodzovanie by
som musel samozrejme zabudnúť. Toto sú najväčšie problémy s verejnými údajmi. Aj keď
ich bude mnoho, pracovať s nimi bude nákladne, obtiažne, neefektívne.
Aby som to zhrnul. Z celého štandardizačného procesu mám veľmi zlý dojem. Pracovná
skupina ktorá tam pôsobí podľa mňa nie je dostatočne dobre zložená. Chýbajú tu
predstavitelia, ktorí majú k problematike spracovania verejných dát veľmi blízko a sú na
dostatočnom stupni poznania. Chýbajú tu predstavitelia FIIT, SAV [24], dokonca aj AFP
[1]. V súčasnosti to teda prebieha tak, že štandardy určuje najmä SOIT, či opendata.sk,
pričom občas sa ozve aj nejaký pracovník štátnej správy. Ja mám z toho taký pocit, že oni si
spoločne robia štandardy, nikto poriadne o tom nevie, treba hlavne spĺňať nejaké termíny, a
podobne. Rozumiem tomu tak, že dôvod prečo sa neotvoriť sémantických štandardom pre
otvorené dáta je, aby si súčasná pracovná skupina udržala svoju moc, resp. pozíciu v tejto
oblasti. To je už nadradené nad samotnú myšlienkou otvorenia dát, čo je podľa mňa
alarmujúce.
4 Návrhy na zlepšenie aktuálneho stavu
Aká cesta teda vedie z tejto zapeklitej situácie? Jednoducho taká, akú použili vyspelé
krajiny ako USA či Spojené kráľovstvo. Napr. USA má portál data.gov [28], kde je viac
než 88 tisíc datasetov. Nie všetky sú samozrejme päťhviezdičkové, no táto úroveň je tam
vyslovene žiadaná. Prečo vlastne? Kto má z toho osoh? Všetky strany! Od občana cez
firmu až po štát. Až keď sú dáta prepojené, až vtedy je možné robiť kvalitné štatistiky a
teda občan vidí, ako sa tu žije a čo je napr. mýtus. Podstatná nie je otázka, ktoré datasety
majú byť publikované, pretože to vôbec nemusí daný orgán štátnej správy riešiť. Každý si
môže použiť jemu vyhovujúci dataset na svoj prospech. Nad prepojenými dátami je oveľa
Zvaná přednáška
45
ľahšie, lacnejšie a efektívnejšie robiť aplikácie pre konečného používateľa. Dáta sa
nespájajú integráciou, dáta sú už integrované ich sémantikou. Aplikácia sa tým pádom
môže viac zamerať na prezentáciu, či funkcionalitu pre používateľa než na integráciu.
Spraviť potom aplikáciu, napr. pomocníka pre nákup pozemku, kde na vstupe označím na
mape predmetnú lokalitu o ktorej dostanem všetky súvisiace veci (dokumenty, osoby,
spoločnosti) nie je vôbec náročné. Pospájané verejné dáta tak vlastne vytvárajú platformu,
nielen databázu.
4.1
Adopcia sémantických štandardov EÚ/USA na údaje
Základným krokom k dosiahnutiu požadovaných štandardov pre verejné dáta na Slovensku
je použiť známe a štandardizované ontológie na popis dát, namiesto vymýšľania si
vlastných XML schém. V Európskej únii pod Európskou komisiou pre tento účel existuje
program ISA [12], ktorej skupina SEMIC [23] sa priamo podieľa na definovaní štandardov
pre popis verejných dát. Môžeme tu nájsť ontológiu na popis občana [31], registrovanej
firmy [35], datesetu verejnej správy [32] a mnohé iné . Zaujímavou informáciou je, že ani
SEMIC sa nesnaží tvoriť vlastné ontológie, resp. ísť vlastnou cestou ako sa to deje na
Slovensku kde sa tvoria vlastné štandardy a to ešte zastaralé. Naopak, SEMIC odporúča
svetové štandardy v danej oblasti, kde napr. v základe sú to všetko ontológie vytvorené a
spravované konzorciom W3C.
Z pohľadu EÚ dôvod nie je len ten, aby sa verejné dáta dali efektívne používať v rámci
jedného štátu. Dôvodom je aj používanie dát v rámci všetkých, alebo len vybraných
členských štátov ÉU. Predstavme si situáciu, že je potrebné urobiť report o počte čiernych
skládok v celej únii za dané obdobie. Tie dáta, ktoré sú 5hviezdičkové a majú teda
sémantiku sa dajú použiť ihneď pre základ reportu. Ostatné (napr. slovenské), ktoré sú
definované len prostredníctvom XML, resp. CVS, tj. sú na treťom stupni treba pracne
transformovať do jednotného spoločného tvaru. Do sémantiky.
4.2
Návrh na sémantické dátové štandardy SR
Vedomí si tohoto stavu, v našej spoločnosti sme spracovali tieto štandardy pre potreby
Slovenska a publikovali ich na pripomienkovanie na to určenom portáli EÚ Joinup už
v máji v roku 2013 [4] . Materiál sme prezentovali aj na štandardizačnom procese v rámci
Ministerstva Financií SR, no zbytočne. Nikto si nič neprečítal, a v podstate sme jednotlivé
stretnutia len zdržiavali. A pritom sa nejedná o žiadnu veľkú zmenu. Len namiesto
navymýšľaných pomenovaní pri popise jednotlivých dát sa použijú štandardné ontológie,
ktoré sa na tú či onú doménu používajú. Materiál v prvom rade predstavuje výber ontológií
a ich popis, na čo sa používajú, tak ako je to zobrazené na nasledovnom obrázku.
Obr. 4 – Ontológie navrhované pre sémantické dátové štandardy
Následne sme navrhli spôsob, akým sa budú identifikovať jednotlivé entity, tj. osoby,
kraje, lieky, úrady a podobne. Využili sme na to dokument ktorý robí štúdiu, ako sa robia
identifikátory v rôznych krajinách, pričom návrh zohľadňuje aj odporúčania, aby jednotlivé
identifikátory boli dostatočne stabilné (perzistentné) [15]. Nasledovný obrázok predstavuje
pár príkladov, ktoré reprezentujú niektoré entity.
Obr. 5 – Príklady navrhovaných URI identifikátorov
Aby sme boli čo najviac presní, špecifikáciu dátových štandardov sme doplnili aj
sémantické mapovanie medzi štandardizovanými ontológiami a súčasným Katalógom
dátových prvkov [17]. Úplný záver dátových štandardov je doplnenie špecifikácie
Zvaná přednáška
47
príkladmi o definovanie osoby, organizácie, adresy, územno-správnej jednotky,
geopriestorovej entity a lieku.
4.3
Slovpedia
Samozrejme, neostali sme len pri dátových štandardoch, ale vytvorili sme projekt Slovpedia
[5] , ktorý plní rovnakú funkciu ako data.gov.sk s rozdielom, že všetky datasety obsahujú
len 5hviezdičkové, tj. LinkedData údaje. Datasetov zatiaľ nie je mnoho, všetky sú tam
z dôvodu našej samostatnej aplikácie pre lieky, ktoré sú publikované jednak na Štátnom
ústave kontroly liečiv [26], no i na Ministerstve zdravotníctva [18], pričom niektoré dáta sú
ťahané z Európskej databázy []. Výhodou slovpedie je, že je ju možné prehliadať
prostredníctvom aplikácie Datalan Tripleskop [6]. Tripleskop umožňuje dáta prehliadať,
skúmať, dopytovať, či exportovať pre potreby tvorby štatistík. Vyhľadávať je možno
textovo, ďalej prostredníctvo dopytovacieho jazyka SPARQL ale aj vizuálne, kedy je
možné dopyt takpovediac nakresliť. Napr. Pri zadaní textu Concor do vyhľadávania systém
vráti množinu liekov Concor (pozn. liekov je viac, jeden obsahuje 5mg účinnej látky, iný
10mg a podobne.) Keď chcem želaný výsledkov preskúmať, resp. pozrieť si jeho okolie,
môžem si to vizualizovať to textovej tabuľky tak ako je to znázornené na nasledovnom
obrázku.
Obr. 6 – Niektoré vlastnosti lieku Concor zobrazené tabuľkou
Alebo alternatívne, môžem si podrobnosti o tomto lieku znázorniť ako graf, čo je
ilustrované na obrázku č. 7. Výhoda zobrazenia údajov v grafe je, že sa môžem postupne
posúvať cez jednotlivé uzly ďalej, čím vlastne traverzujem a skúmam graf.
Obr. 7 – Niektoré vlastnosti lieku Concor zobrazené grafom
Na horeuvedenom obrázku je možné vidieť, že liek Concor má exspiračnú dobu 60
mesiacov, že jeho výdaj je viazaný na predpis, že v rámci klasifikácie patrí do ATC skupiny
C07AB07, čo je Bisoprol. Keby som skúmal okolie práve tohoto uzla, tak by som zistil, že
Bisoprol je Selektívny betablokátor, ktorý je Betablokátor (pozn. Existujú aj neselektívne
Betablokátory). A teraz príde ďalšia skvelá vec súvisiaca so sémantickým webom.
Keďže dotaz je vlastne definícia subgrafu, tak sa dotaz dá reprezentovať grafom, resp.
nakresliť. Z daného grafu lieku som odstránil všetky vlastnosti s výnimkou exspirácie a
ATC skupiny a rovnako som zmenil daný liek za premennú.
Obr. 8 – Graf reprezentujúci vizuálny dotaz
Zvaná přednáška
49
Týmto sa nakreslil vlastne dopyt „vrát mi všetky lieky ktoré majú ATC skupinu
C07AB07 a súčasne exspirácia je 60 mesiacov“. Systém po spustení daného dopytu vráti
zoznam liekov, ktoré vyhovujú týmto podmienkam.
Toto bol jednoduchý dotaz na prezentovanie možnosti technológie. Predstavme si ešte
pár iných. Napr. môj sen o ovocnom sade môže priblížiť dotaz: Chcem vidieť také
pozemky v extraviláne do 50km od Bratislavy, kde inžinierske siete sú v dosahu do 200m,
teploty v zime nie sú nižšie než -20 stupňov Celzia, sú vysporiadané a bez ťarchy. Keby
som sa zaujímal o ekonomickú zdravosť Slovenska, mohol by som sa chcieť spýtať: Chcem
vidieť zoznam firiem, kde je pracuje nejaký poslanec pričom predmet podnikania je blízky
k predmetu práce poslanca. Čiže robím dotaz nad datasetom firiem a datasetom verejných
činiteľov. Alebo spravím dotaz, kde chcem vidieť také spoločnosti, ktoré poberajú nejaký
finančný príspevok a zároveň sú neplatiči voči niektorým subjektom. Predstavte si, ako by
sa skvele dalo robiť s verejnými dátami, keby obsahovali sémantiku. Takýto prístup
odkrýva úplne netušené možnosti využitia verejných dát. Lenže, aj keď je už rok 2014, na
slovensku sa pristupuje k otvoreným údajom ako pred desiatimi rokmi. Smutné.
5 Na záver
Článok sa snažil priblížiť problematiku štandardizácie dátových štandardov informačných
systémov verejnej správy v Slovenskej republike a vysloviť znepokojenie nad nízkou
kvalitou ich výstupov. Z pohľadu 5starOpen data sa na Slovensku dlhodobo presadzuje len
tretí stupeň, čo je škoda, pretože čím väčší stupeň kvality dát, tým bude väčšia využiteľnosť
verejných dát. Náklady na dátovú integráciu výrazne klesnú a efektivita využiteľnosti
údajov bude neporovnateľne lepšia.
Ambíciou článku bolo v jednoduchosti priblížiť aj technológie, ktoré sémantický web
tvoria a načrtnúť výhody tejto technológie na prácu s verejnými dátami. Cieľom bolo na
jednej strane poukázať, že sa jedná o novú generáciu webu (Web 3.0) ktorý už mimo
Slovenska nastúpil pred desaťročím v zahraničí, a že za Sémantikou stojí základne webové
konzorcium W3C. Sémantický web poznajú na Slovensku s výnimkami len
v akademických oblastiach, no sú to už dlhé roky pričom často sme v tejto oblasti aj
zažiarili [9, 10]. Len bohužiaľ, proces štandardizácie dátových štandardov nie je tejto téme
momentálne naklonený. Pri tomto postupne predpokladám že až za 5 rokov sa začnú prvý
krát touto témou vážne zaoberať. Škoda tohto „odkladu“ a musím povedať, že aj doteraz
minutého času.
Na záver by som chcel len povedať, že ma na jednej strane mrzí, ako som zámerne
nevychválil SOIT či opendata.sk. Viem že urobili pre Slovensko mnoho dobrého. No za
súčasného stavu poznania procesu štandardizácie a ich postoja k sémantickým dátam to
jednoducho nejde.
Literatúra
1.
2.
3.
4.
Aliancia Fair Play. http://www.afp.sk [prístupné 31.8.2014].
Berners-Lee, T.: 5 Star Deployment Scheme for Open Data. http://http://5stardata.info/
[prístupné 31.8.2014].
Datalan: Pharmanet. http://www.pharmanet.sk [prístupné od 1.1.2015].
Datalan: Proposed Data Semantic Annotation Using Standardized Web Ontologies and
URI Identifiers to the Slovak Government.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
https://joinup.ec.europa.eu/elibrary/case/proposed-data-semantic-annotation-usingstandardized-web-ontologies-and-uri-identifier [prístupné od 1.1.2015].
Datalan: Slovpedia. http://www.slovpedia.sk [prístupné od 1.1.2015].
Datalan: Tripleskop. http://www.tripleskop.sk [prístupné od 1.1.2015].
European Drug Database. http://www.emcdda.europa.eu/eldd [prístupné 31.8.2014].
Fakulta informatiky a informačných technológií. http://www.fiit.stuba.sk [prístupné
31.8.2014].
Fakulta informatiky a informačných technológií. Personalized Web Group.
https://wiki.fiit.stuba.sk/research/seminars/pewe/ [prístupné 31.8.2014].
FOAF.SK. Sociálna sieť firiem. http://foaf.sk [prístupné 31.8.2014].
Geonames: GeoNames Ontology.
http://www.geonames.org/ontology/documentation.html [prístupné 31.8.2014].
ISA – Interoperability Solutions for European Public Administrations.
http://ec.europa.eu/isa/ [prístupné 31.8.2014].
IT Asociácia Slovenska. http://itas.sk [prístupné 31.8.2014].
Kvasnička, V., Pospíchal, J.: Algebra a diskrétna matematika. STU Bratislava, 2008.
Loutas, N.: 10 Rules for Persistent URIs.
https://joinup.ec.europa.eu/community/semic/document/10-rules-persistent-uris
Ministerstvo financií SR. http://www.informatizacia.sk [prístupné 31.8.2014].
Ministerstvo financií SR. Katalóg dátových prvkov.
http://www.informatizacia.sk/ext_dok-mpk_priloha_2/4464c [prístupné 31.8.2014].
Ministerstvo zdravotníctva. http://www.sukl.sk [prístupné 31.8.2014].
Národná agentúra pre sieťové a elektronické služby. http://data.gov.sk [prístupné
31.8.2014].
Národná agentúra pre sieťové a elektronické služby. Ústredný portál verejných služieb.
http://slovensko.sk [prístupné 31.8.2014].
Návrat, P.: Umelá inteligencia. STU Bratislava, 2002, 2006.
Opendata.sk. http://opendata.sk [prístupné 31.8.2014].
SEMIC - Semantic Interoperability Community.
https://joinup.ec.europa.eu/community/semic/description [prístupné 31.8.2014].
Slovenská akadémia vied. http://ikt.ui.sav.sk/ [prístupné 31.8.2014].
Spoločnosť pre otvorené informačné technológie. http://www.soit.sk [prístupné
31.8.2014].
Štátny ústav pre kontrolu liečiv. http://www.sukl.sk [prístupné 31.8.2014].
XMLNS.com: FOAF – Friend of a Friend Vocabulary. http://xmlns.com/foaf/spec/
US Government. http://data.gov [prístupné 31.8.2014].
W3C: http://www.w3.org/ [prístupné 31.8.2014].
W3C: Core Location Vocabulary.
https://joinup.ec.europa.eu/asset/core_location/description [prístupné 31.8.2014].
W3C: Core Person Vocabulary.
https://joinup.ec.europa.eu/asset/core_person/description [prístupné 31.8.2014].
W3C: Data Catalogue vocabulary. http://www.w3.org/TR/vocab-dcat/ [prístupné
31.8.2014].
Zvaná přednáška
33. W3C: HTTP - Hypertext Transfer Protocol. http://www.w3.org/Protocols/ [prístupné
31.8.2014].
34. W3C: OWL - Web Ontology Language. http://www.w3.org/OWL/ [prístupné
31.8.2014].
35. W3C: Registered Organization Vocabulary . http://www.w3.org/TR/vocab-regorg/
36. W3C: RDF - Resource Description Framework. http://www.w3.org/RDF/ [prístupné
31.8.2014].
37. W3C: Semantic Web Activity. http://www.w3.org/2001/sw/ [prístupné 31.8.2014].
38. W3C: SPARQL - Protocol and RDF Query Language.
http://www.w3.org/TR/sparql11-query/ [prístupné 31.8.2014].
39. W3C: URI – Uniform Resource Identifier. http://www.w3.org/wiki/URI [prístupné
31.8.2014].
40. W3C: URL – Uniform Resource Locator. http://www.w3.org/TR/url/ [prístupné
31.8.2014].
41. W3C: XML – Extensible Markup Language. http://www.w3.org/XML/ [prístupné
31.8.2014].
51
Marek ŠUREK
Datalan a.s.
Galvániho 17/A, 821 04, Bratislava
[email protected]
Abstrakt. Spoločnosť Datalan sa niekoľko rokov venuje vývoju sémantických aplikácií
a nástrojov sémantického obsahu. V tomto príspevku sa budeme snažiť predstaviť niektoré
z vytvorených nástrojov ako aj koncových aplikácií. Nakoľko je komplexnosť jednotlivých
nástrojov netriviálna, budeme sa snažiť popísať ich hlavnú pridanú hodnotu. Na základe
našich dlhoročných skúseností sa budeme snažiť celý príspevok koncipovať v čo
najpraktickejšej rovine. Pri jednotlivých nástrojoch budeme jasne popisovať problémy,
ktoré je nutné riešiť pri vývoji sémantických aplikácií ako aj naše riešenie pre daný
problém. Jednotlivé kapitoly zároveň poskytujú aj námety na výskumné projekty v oblasti
sémantických technológií ako aj námety na participovanie pri tvorbe open source projektov,
ktoré sú nevyhnutné pre rozvoj sémantických technológií a ich väčšie rozšírenie.
Kľúčové slova: sémantický web, správa znalostných báz, odvodzovanie
1 Úvod
Sémantické technológie sú v súčasnosti etablovanou technológiou na poli IT. Je
nepochybné, že svojou štruktúrou a popisom sveta prostredníctvom ontológií ďaleko
prevyšujú vlastnosti relačných databáz. Za posledných pár rokov spoločnosť Datalan
vyvinula množstvo produktov a nástrojov, ktoré boli zamerané na prácu so sémantickým
webom a sémantickými technológiami. V nasledujúcich kapitolách si postupne predstavíme
jednotlivé produkty, ich základné vlastnosti a problémy, s ktorými sme sa museli pri vývoji
popasovať.
V jednotlivých kapitolách budeme často spomínať problémy a ich následné riešenia.
Tým ale nechceme v čitateľovi nabudiť dojem o nepriaznivom stave v danom odvetví.
Celkovo mapujeme históriu práce s technológiami a ich progresívny vývoj. Za uplynulé
obdobie sa situácia výrazne zmenila k lepšiemu a sémantické technológie vyzreli do
rozmerov plne kompetitívnych s inými riešeniami.
Z našich skúseností vieme povedať, že množstvo ľudí sa pozeralo na technológiu veľmi
negatívnym spôsobom ako na perspektívnu ale nepoužiteľnú vetvu v IT sektore. Pri
následnom prezentovaní našich produktov sme im dokázali jasne preukázať, že technológia
nie je len dostatočne vyzretá, ale dokáže poraziť aj mnohé súčasné najväčšie podnikové
riešenia. Dôležitým prvkom je obrovská informačná hodnota dát v sémantických
databázach, ktoré spolu s možnosťou odvodzovania poskytujú nespornú konkurenčnú
výhodu pre dodávateľov sémantických riešení.
Musíme podotknúť, že vlastnosti použitých technológií ďaleko prevyšujú akékoľvek
existujúce technológie a ich potenciál ešte ani zďaleka nie je naplnený. Spôsob akým sú
dáta popisované je prielomový a bude hrať v najbližších rokoch obrovskú úlohu pri tvorbe
novej generácie webu. Príspevkom chceme motivovať množstvo vývojárov k používaniu
sémantických technológií. Táto mladá technológia je v súčasnosti dostatočne vyzretá pre
P. Šaloun, D. Chlapek (eds.), DATAKON 2014, Jasná, 25-27.9.2014, pp. 53-61.
54
použitie v komerčných aplikáciách, čoho jasným dôkazom sú aplikácie a nástroje vytvorené
v spoločnosti Datalan, ktoré sú nasadené v produkčných prostrediach.
2 OWLIM – GraphDB
2.1
Osobné skúsenosti
Jadrom každej sémantickej aplikácie je databáza, ktorá je schopná zachytiť a čo najlepšie
interpretovať znalosti v jednotlivých doménach. Spoločnosť Datalan v tomto ohľade
spolupracuje s firmou Ontotext, ktorá jej poskytuje v súčasnosti najkomplexnejšie riešenie
v oblasti sémantických triplestore databáz. Za dlhé roky, počas ktorých sme s týmto
dodávateľom spolupracovali, sme získali veľmi cenné skúsenosti, ktoré sme pretavili
v návrhoch a implementáciách našich produktov.
V počiatočných fázach našej spolupráce (2011), sa databáza OWLIM hrdila dodávkou
svojho riešenia anglickej televíznej spoločnosti BBC. Naše praktické skúsenosti ale
poukazovali na to, že v tomto období mala databáza značné problémy so stabilitou
i rýchlosťou, ktoré sú základom pre každú databázu. V tomto období sa stávalo, že vo
vývojárskom režime sme prišli o dáta, ktoré bolo nutné nanovo nahrať do databázy.
Celkovo môžeme povedať, že vlastnosti prvotných verzií (OWLIM 4.2 a skôr) neboli
vhodné pre komerčné využitie, hlavne kvôli svojej stabilite. Myslíme si, že aj to viedlo
mnohých potenciálnych vývojárov k tomu, že sa báli nasadzovať túto novú technológiu
v praxi. Následne takto nadobudnutú skúsenosť šírili okolo seba čo neprospelo k vývoju
technológie.
Od tejto chvíle sme sa aktívne začali podieľať na vývoji databázy OWLIM, kde sme
veľmi často komunikovali s dodávateľom a pripomienkovali jednotlivé funkcionality
a nahlasovali chyby, ktoré sme odhalili. V tomto smere musíme podotknúť, že za toto
obdobie, považujeme komunikáciu so spoločnosťou za nadštandardnú a mnohokrát máme
prístup k verziám, ktoré nie sú oficiálne prístupné širokej verejnosti. Takto sa dostávame
k novým funkcionalitám, ktoré vieme v predstihu pripomienkovať.
Výrazná zmena prišla s príchodom verzie 5.0, ktoré v dostatočne veľkom rozsahu
napravila negatívnu reputáciu. I v tomto prípade musíme poukázať na fakt, že v ranných
verziách tejto novej verzie dochádzalo pri určitých používateľských scenároch k výraznej
degradácií výkonu rôznych typov dopytov na databázu. V tomto období bola spolupráca so
spoločnosťou najintenzívnejšia nakoľko kvalita databázy výrazne ovplyvňovala nami
vyvíjané produkty. Celkovo môžeme povedať, že všetky problémy boli úspešne odstránené
a od verzie 5.2 sme nepocítili žiadne nepriaznivé a neočakávané správanie databázy.
Každá ďalšia nová verzia databázy zvyšovala vývojársky komfort a čo najdôležitejšie,
zvyšovala rýchlosť dopytovania. V súčasnosti sa spoločnosť rozhodla premenovať databázy
OWLIM na databázu GraphDB resp. OWLIM 6.0. Zároveň v nových verziách sa vo
výraznej miere zameriava na najväčších partnerov, ktorý využívajú ich Enterprise verziu.
Výhodou tejto verzie je klastrovanie databázy na niekoľko nezávislých strojov. Táto
funkcionalita bola poskytovaná už v predchádzajúcich verziách, ale až od tejto verzie
obsahuje robustný model.
2.2
Zaujímavé vlastnosti databázy
Databáza OWLIM obsahuje množstvom veľmi zaujímavých funkcionalít, ktoré
poskytujú vývojárom neobmedzené možnosti. Jednou z nich je Plugin API, pomocou
ktorého môže vývojár pristupovať k dátam na tej najnižšej úrovni. Takto je možné vytvárať
Zvaná prezentace
55
nové komponenty priamo na úrovni databázy, ktoré rozširujú vlastnosti databázy. Jednou
z nich je napríklad vstavaná integrácia s rámcom Lucene. Tento komponent poskytujú
samotný autori OWLIM databázy a využíva rovnaké API, aké je poskytnuté ostatným
vývojárom.
Pri našej práci sme takisto využili možnosti, ktoré nám poskytuje OWLIM Plugin API.
V našom prípade sme vytvorili prototyp komponentu, ktorý slúži na zachovanie
konzistencie v databáze. Nakoľko do tripletovej databázy je možné uložiť akékoľvek údaje
nezávislé na schéme, komponent slúžil ako prostriedok na zachovanie konzistenice,
nakoľko overoval jednotlivé trojice pri vkladaní do databázy proti ontológie. Zároveň daný
komponent zaobstráva zjednodušenie písaniu dopytov, ktoré pracujú s dátovými
vlastnosťami. Komponent jednoducho dopĺňa dátové vlasnosti do dopytu pred spustením
nad databázou.
3 Albert
3.1
Motivácia
Dôležitou vlastnosťou sémantických databáz je schopnosť odvodzovať nové poznatky
z existujúcej bázy znalostí. V súčasnosti je najrozšírenejší pravidlový spôsob
odvodzovania, kde si používateľ definuje pravidlá, ktorých dôsledkom je vytvorená
znalosť.
Pri tvorbe komplexných aplikácií je nutné počítať s mnohými stupňami odvodzovania
s rôznou výrazovou silou a v rôznom čase. Databáza OWLIM poskytuje odvodzovač, ktorý
je do určitej miery schopný pokryť potreby moderných aplikácií, no nie všetky.
V prvotných fázach našej práce so sémantikou sme venovali veľké úsilie hľadaniu možných
riešení, ktoré by zabezpečili požadovanú funkcionalitu pre vyvíjané koncové aplikácie
v oblasti odvodzovačov, ktoré limitovali funkcionalitu navrhnutých aplikácií.
Prvým problémom pri odvodzovaní pomocou nástroja OWLIM je jeho spôsob
materializácie. Pri každom vložení údajov do databázy sa spustí odvodzovač, ktorý sa snaží
všetky pravidlá aplikovať na existujúcu bázu dát. Tento princíp sa volá aj úplná
materializácia. Nespornou výhodou tohto prístupu je zvýšená rýchlosť dopytovania nad
takouto databázou. Nevýhodou je práve spomalenie UPDATE operácií a čo je ešte
dôležitejšie, nemožnosť definovania časových postupností a závislostí pri odvodzovaní.
Vývojár nemá plnú kontrolu, kedy sa ktoré pravidlo aplikuje, čo pri komerčných
aplikáciách môže byť kľúčové.
Ďalším problémom vstavaného odvodzovača v databáze OWLIM je nižšia vyjadrovacia
sila jazyka v ktorom je možné pravidlá zapísať. Komplikované pravidlá, ktoré sú závislé na
agregačných funkciách resp. porovnaniach, nie sú v súčasnej verzii databázy
OWLIM/GraphDB možné.
Počas nášho interného testovania sme zistili, že riešením je práve použitie SPARQL
dopytov na odvodzovanie nových znalostí. Dopyty/pravidlá v jazyku SPARQL 1.1
poskytujú dostatočnú výrazovú silu na zapísanie ľubovoľných pravidiel. V prvotných
fázach odvodzovania nových znalostí pomocou jazyka SPARQL sme sa museli vyrovnať
s obrovskou pamäťovou náročnosťou riešenia. Túto nevýhodu sme časom dokázali
odstrániť a to pri získaní niekoľko násobne vyššieho výkonu. Dôležitým architektonickým
rozhodnutím bola schopnosť odvodzovať jednotlivé pravidlá na menších zvolených
dátových sadách. Vďaka tomu sa pamäťová náročnosť výrazne zmenšila. Súčasne sme
mnohé veci komunikovali so spoločnosťou Ontotext, ktorá optimalizovala správu pamäte
56
a tým sa aj dodávateľ priamo podieľal na lepšení vlastností odvodzovania pomocou tejto
metódy.
Správne definovanie rozdeľovača dát na menšie časti nám dovolila vytvoriť spôsob
paralelného odvodzovania s využitím veľkej sily našich serverov. Tým je možné
paralelizovať veľké množstvo odvodzovania, čo je taktiež jeden z nedostatkov
odvodzovača OWLIM. Okrem samotného plnohodnotného využitia hardverových
komponentov pri zníženej záťaži na pamäť, bolo ďalším pozitívom výrazné zníženie času
odvodzovania.
I keď by sa z predchádzajúcich odsekov mohlo zdať, že odvodzovač, ktorý je
v databáze OWLIM je nepoužiteľný, nie je tomu úplne tak. Pravidlá, ktoré sú definované
napr. podľa OWL-RL, zvláda databáza s oveľa nižšou záťažou na výpočtové prostriedky.
Typickým predstaviteľom je odvodzovanie rdfs:subClassOf, ktoré nie je závislé na časovej
postupnosti alebo biznis pravidlách. Toto pravidlo je nutné aplikovať vždy v okamihu
vloženia dát do databázy. Preto je nutné vhodne poznať, kedy je vhodné odvodzovať nové
znalosti pomocou vstavaného odvodzovača v databáze OWLIM (obvykle pravidlá
definované v deskriptívnej logike) a kedy je vhodné použitie riešenia odvodzovania
pomocou SPARQL v kombinácii s rôznymi vylepšeniami (obvykle komplikované biznis
pravidlá)
Plánovanie odvodzovania, definovanie paralelizácie či samotných pravidiel nás viedli
k vytvoreniu komplexného agentového nástroja, ktorý spravuje jednotlivé úlohy. Tento
nástroj má kódové označenie Albert.
3.2
Vlastnosti nástroja
Albert sa stal veľmi dôležitý, nakoľko sa z neho stal nástroj pre komplexnú správu dát
sémantických aplikácií. Tým, že cieľom nástroja bolo jeho použitie v rôznych
sémantických projektoch spoločnosti, musel nástroj poskytovať čo najväčšiu škálu
vlastností, ktoré si postupne predstavíme.
Základom nástroja je jeho schopnosť vykonávať naplánované úlohy. Úlohy je možné
definovať na základe vytvoreného API, ale aj prostredníctvom XML konfiguračného
súboru. V ňom si vieme definovať následnosť úloh, ich závislosti vykonávania ako aj
množstvo vlákien, ktoré je možno použiť.
Rôzne aplikácie vyžadujú rozdielne nároky na úlohy, ktoré nástroj Albert poskytuje. To
nás viedlo k vytvoreniu sady definovaných úloh, ktoré sú použiteľné v mnohých
aplikáciách naprieč doménami. Vývojári tak nie sú nútení riešiť neustále tie isté problémy,
ale používajú predpripravené úlohy, ktoré si už len dokonfigurujú. Každá úloha má navyše
možnosť nastavenia počtu vlákien a tak paralelizáciu vieme dosiahnuť nie len v rámci
plánu úloh ale aj v rámci úlohy samotnej. Jednou z takýchto úloh je napríklad samotné
odvodzovanie pomocou SPARQL, no aplikácií je hneď niekoľko. Príklady ďalších úloh,
ktoré je možné v nástroji Albert definovať sú nasledovné :
1. Štatistické dopyty
2. Vytvorenie databázy
3. Načítanie dát do databázy
4. Volanie REST API iných aplikácií
5. Kopírovanie dát medzi databázami
Zároveň sú v nástroji definované ďalšie zásuvné moduly, ktoré sú svojou povahou
natoľko dôležité, že si ich popíšeme oddelene. Tieto moduly boli primárne vytvorené pre
jednu konkrétnu aplikáciu, no ich použitie nie je obmedzené danou doménou. Pre lepšie
pochopenie dôležitosti daných modulov spomenieme, že daná aplikácia pracovala
s neštruktúrovanými dátami, ktoré obsahovali veľkú dávku nekonzistentnosti a neúplnosti.
Zvaná prezentace
57
Modul na hľadanie podobnosti medzi objektami
Ako sme uviedli v predchádzajúcich odsekoch, naše aplikácie pracujú vo veľkej miere
s nepresnými dátami ako aj dátami, ktoré sú redundantné. Medzi prvými aplikáciami vo
vývoji bola preto aplikácia zaoberajúca sa identifikáciou redundantnosti dát a ich
následnému zlúčeniu. Výsledkom je skvalitnené vyhľadávanie nad očistenou bázou dát čím
šetríme zákazníkovi čas a aj peniaze. Skvalitnená báza dát môže slúžiť aj na kvalitnejší
prehľad nad samotnými dátami, kedy sú v štatistických dopytoch započítané naozaj iba
unikátne záznamy.
Komponent v nástroji Albert bol primárne určený na odhaľovanie podobnosti medzi
dátami. Výsledkom odhalenia podobnosti je vytvorenie interného predikátu sameAs
namiesto všeobecne známeho predikátu owl:sameAs. Dôvodom tohto použitia je veľmi
vysoká vyjadrovacia sila predikátu owl:sameAs. Nakoľko pracuje s dátami, ktoré nie sú
dokonalé, automatizovaným spôsobom nevieme povedať s úplnou istotou, či sú dané dve
inštancie objektu identické. Z tohto dôvodu sme vytvorili vlastné pravdepodobnostné
modely, ktoré sú založené na definovaní pravidiel naprieč jednotlivými vlastnosťami.
Zároveň je možné pre jednotlivé vlastnosti definovať aj váhy a mnohé ďalšie parametre,
ktoré skvalitňujú výsledky vyvodzovania totožnosti medzi objektami.
Nie všetky akcie je možné robiť automatizovane bez akýchkoľvek znalostí od človeka,
obzvlášť keď pracujeme v doménach, kde je kvalita vstupných dát nízka. Z tohto dôvodu
vie nástroj pracovať aj s používateľskou odozvou korektnosti vyvodenej identity medzi
inštanciami.
Pri určovaní totožnosti je nutné brať ohľad na všetky matematické vlastnosti totožnosti
ako reflexívnosť, tranzitívnosť a symetrickosť totožných indivíduí. Jedným z najväčších
problémov pri riešení totožnosti je šírenie matematických vlastností medzi skupinou
pravdepodobne totožných indivíduí. Majme dva rozdielne zhluky totožných nehnuteľností,
každý o 30 prvkoch. Na základe šumu v dátach a definovaných pravidlách je možné, že je
vyvodená totožnosť medzi jedným z prvkov prvého zhluku z jedným z prvkov druhého
zhluku. Takéto nesprávne určenie totožnosti ale vedie k prešíreniu sameAs naprieč
všetkými vlastnosťami. Tým dostávame jeden zhluk o 60 indivíduách, ktorý ale nie je
korektne spárovaný. Hľadanie dát, na základe ktorých vznikne spojenie a následné
prešírenie sameAs zabralo pri vývoji algoritmov na elimináciu tohto problému množstvo
úsilia. V súčasnosti sa vďaka množstvu podporných mechanizmov dokážeme aspoň
čiastočne tomuto problému vyhnúť a tak vytvárať skutočne skvalitnenú bázu dát.
Modul na čistenie dát
Ďalším komponentom, ktorý je súčasťou nástroja Albert, je nástroj na čistenie dát na
základe rôznych štatistických modelov. Základným predpokladom je korektné odhalenie
vzťahu sameAs medzi inštanciami. Následne komponent čistenia dát sa snaží odhaľovať
nekonzistentné údaje. Nakoľko pracujeme s rôznymi typmi údajov a pri určovaní totožnosti
si nemôžme byť úplne istý či sú údaje naozaj nesprávne, bolo nutné zvoliť menej agresívnu
metódu. Sémantické databázy sa javia ako ideálny spôsob na vysporiadanie sa s týmto
druhom problému. Riešením je definovanie kontextu(subgrafu), kde budú všetky
nekonzistentné a pravdepodobne nesprávne údaje presunuté. Týmto spôsobom neprídeme
o žiadne údaje a zároveň vieme v údajoch filtrovať na základe ich kontextu v ktorom sa
nachádzajú.
58
4 Rámce na prístup k databáze
Pri práci s databázou potrebuje vývojár kvalitné API, ktoré mu uľahčí prácu s ňou. Túto
oblasť považujeme za jednu z kameňov úrazu, ktorá zabraňuje k masívnejšiemu rozšíreniu
sémantických databáz do komerčných aplikácií. Rámec Openrdf Sesame poskytuje
základné štandardizované rozhranie pre prácu s databázou. Prístup k databáze ale nie je pre
dnešnú dobu intuitívny. Samotné API by sa dalo prirovnať k JDBC API, ktoré je základom
pre Javu a relačné databázy. Každý prístup do databázy sprevádza veľké množstvo
opakujúceho sa kódu, ktorý je možné eliminovať. Zároveň musí programátor ošetrovať
a zachytávať pri každom volaní veľké množstvo výnimiek, čím sa stáva výsledný kód
veľmi neprehľadný.
Nepohodlná práca s databázou nás viedla k vytvoreniu databázovej vrstvy, ktorá značne
zjednodušuje prácu s databázou. Samotná idea práce vychádza z rámca Spring a jeho triedy
JdbcTemplate. Na základe vytvoreného API, ktoré sa svojou povahou podobá práve
JdbcTemplate triede sa nám podarilo výrazne zjednodušiť prácu s databázou. Pridanou
hodnotou rámca je okrem správy pripojení aj možnosť jednotným spôsobom spravovať
mapovanie výsledkov dopytu na Java doménové objekty. Vývojár pracuje jednotným
spôsobom s API a prípadné optimalizácie na pozadí rámca sa ho nedotknú. Tento projekt
dostal názov Teatime a je súčasťou všetkých aplikácií využívajúcich pripojenie
k sémantickej databáze v spoločnosti.
Projektu Teatime sa podarilo odstrániť množstvo nepotrebného kódu bez poklesu
rýchlosti aplikácie. Cieľom pre plnohodnotné veľké aplikácie je ale vytvorenie databázovej
vrstvy(ORM), ktorá sa podobá na Hibernate vrstvu pre SQL databázy. V tejto oblasti sme
analyzovali hneď niekoľko projektov. Nakoniec sme sa podľa rôznych kritérií rozhodli pre
nástroj RDFBean. Tento rámec je open source a poskytuje funkcionalitu veľmi podobnú
rámcu Hibernate. Dôležitou vlastnosťou rámca je, jeho nezávislosť na jednom dodávateľovi
databázového riešenia. Používateľ môže používať databázu OWLIM ale aj Jena, Virtuoso
a iné bez akejkoľvek zmeny v kóde. Sami sme niekoľko mesiacov prispievali k vývoju
tohto rámca tak aby sme docielili funkcionalitu, ktorá bola pre naše aplikácie veľmi
dôležitá.
K projektu RDFBean sa viaže aj implementácia Spring Data rámca. Tento rámec sme
takisto implementovali a poskytli pre opensource využitie. Výhodou tohto rámca je jeho
priama prepojenosť s rámcom Spring, pri použití Spring Data princípov. Spring Data je
projekt rámca Spring, ktorý zabezpečuje jednotné API naprieč rôznymi NoSQL
databázami.
Prvotné implementácie zabezpečujú základnú funkcionalitu rámca. V rozvoji tohto
rámca vidíme veľký potenciál aj do budúcnosti. Bez prepracovaného rámca pre prístup
k databáze, bude záujem komerčných firiem o sémantické databázy menej výrazný.
V oblasti mapovania výsledkov dopytu na objekty je priestor na vedecký výskum, nakoľko
je tu možnosť optimalizovať dopyty na čo najlepšie a najefektívnejšiu prácu s databázou.
V rámci možností bude i naďalej spoločnosť Datalan participovať na vývoji daných
rámcov, nakoľko si uvedomujeme ich dôležitosť pre komerčnú sféru a teda aj pre nás.
5 Tripleskop
Odlišná reprezentácia dát inšpirovala spoločnosť k výskumu odlišných spôsobov
vizualizácie sémantického obsahu. Zároveň sme sa snažili vytvoriť nástroj, ktorý bude v čo
najjednoduchšej podobe dostupný aj ľuďom, ktorí nie sú profesionáli v oblasti IT.
Výsledkom tejto práce je nástroj Tripleskop, ktorý reprezentuje údaje prostredníctvom
Zvaná prezentace
59
interaktívneho grafu. Pri jeho návrhu sme chceli poskytnúť vývojárom nástroj, ktorý je
schopný rôznymi spôsobmi vizualizovať jednotlivé vzťahy čo prispieva k ich ľahšiemu
pochopeniu.
Počas úvodných fáz sme sa zameriavali na použitie existujúcich riešení napr. Gruff. Pri
používaní týchto riešení sme ale narážali na limity pri vizualizácii dát čo znemožňovalo ich
dôkladnú analýzu. Preto sa časť vývojového oddelenia zaoberala návrhom
a implementáciou nástroja, ktorý je schopný plne pokryť nároky na prehliadanie
a analyzovanie sémantického obsahu.
Veľkou výhodou nástroja je jeho nezávislosť na platforme. Vytvorená aplikácia je
nezávislá na operačnom systéme ale aj internetovom prehliadači v ktorom je používaná. Pri
tvorbe boli použité štandardy technológií HTML 5 ale aj javascriptu. Nástroj je takisto
schopný vytvoriť dopyty v jazyku SPARQL pomocou vizuálnych prvkov bez znalosti
jazyka SPARQL.
Sémantický obsah je veľmi rôznorodý. Práve z tohto dôvodu je nástroj Tripleskop
obohatený o viacero implementácií rôznych vizualizácií dát. Analytik ale aj používateľ je
schopný zvoliť si intuitívnym spôsobom rozdielne typy zobrazenia, ktoré mu dopomáhajú
k lepšiemu pochopeniu dát v databáze. Analytik si vie konštruovať aj agregačné funkcie,
ktoré mu pomôžu lepšie analyzovať existujúce dáta. Nástroj obsahuje veľké množstvo
variability pri používaní od vyhľadávania pomocou textového SPARQL dopytu, cez
vyhľadávania pomocou textu v prirodzenom jazyku ale aj pomocou vizuálnej konštrukcie
dopytu. Používateľ sa môže jednoduchým spôsobom pripojiť k ľubovoľnej sémantickej
databáze. Tieto ale aj mnohé ďalšie funkčné vlastnosti sú súčasťou komplexného
vizualizačného a analytického nástroja Tripleskop.
6 Medicínska aplikácia
V úvodných častiach tohto článku sme uvádzali prevažne nástroje a rámce, ktoré sú
všeobecného charakteru. Predstavené nástroje patria medzi nami identifikované základné
súčasti sémantických aplikácií pracujúcich s triplestore databázami. Spoločnosť Datalan
vyvinula aj viacero koncových aplikácií s určenou doménou.
Oblasť medicíny patrí k prelomovým doménam v oblasti sémantického webu v praxi.
Vďaka vhodnej štruktúre dát sme implementovali softvérovú aplikáciu, ktorá je taktiež
zasadená do domény medicíny. Aplikácia má viacero vlastností, ktoré sú na trhu jedinečné
práve kvôli sémantike a odvodzovaniu nových faktov. Zároveň sú v tejto aplikácii použité
aj prvky spracovania prirodzeného jazyka a extrakcie sémantiky z neštruktúrovaného textu.
Jednou z pridaných vlastností aplikácie je automatizované vyvodzovanie interakcií
medzi liekmi/účinnými látkami. Základom celého procesu bolo vytvorenie ontológie
vzťahov v oblasti medicíny. Následne sme na základe konzultácií s odborníkmi v danej
oblasti boli schopní extrahovať dôležité informácie z SPC letákov publikovaných na
stránkach ŠUKL. Pomocou pravidiel a odvodzovania sme boli schopní odhaliť také
interakcie medzi liekmi, ktoré poskytujú odbornej verejnosti dôležité informácie pre rýchle
rozhodovanie pri predpise liečiv.
Aplikácia má takisto pokročilé textové vyhľadávanie, ktoré taktiež obsahuje prvky
sémantiky. Používateľ je schopný na základe predspracovaných dát s extrahovanou
sémantikou hľadať indikácie či kontraindikácie v liekoch. Medzi ďalšie vlastnosti produktu
môžeme spomenúť vyhľadávanie generických substitúcií či preskripcií, ktoré sú pre
odbornú verejnosť taktiež veľmi dôležité.
Pri vývoji tejto aplikácie sme sa museli vysporiadať s odlišnou množinou problémov
ako sme popisovali v predchádzajúcich kapitolách. Jednou z najväčších výziev bola
60
anotácia SPC letákov, ktoré obsahujú veľké množstvo odborných termínov. Tie sa
nenachádzajú v štandardných slovníkoch od SAV a preto nie sme schopní korektne
lematizovať a správne anotovať takéto pojmy. Museli sme preto vyvinúť viacvrstvové
modely, ktoré iteratívnym spôsobom postupne anotujú viac a viac textu. Ďalšia z výziev pri
tvorbe tejto aplikácie bola zameraná na odvodzovanie interakcií medzi liekmi. Táto
operácia je výkonnostne veľmi náročná nakoľko veľmi veľké množstvo liekov navzájom
interaguje práve kvôli rozličným pravidlám vyhodnocovania interakcií.
7 Univerzálny sémantický vyhľadávač
Jedným zo spôsobov, ako zapracovať sémantiku do aplikácie je aj spôsob akým používateľ
komunikuje s aplikáciou. V tejto oblasti sme sa snažili vyvinúť nástroj, pomocou ktorého sa
používateľ môže pýtať pomocou prirodzeného jazyka. Výsledkom takejto aplikácie je
rámec Susan, ktorý dokáže konvertovať používateľské dopyty do sémantickej podoby – do
jazyka SPARQL. Údaje je možné vyhľadávať na základe ich sémantiky definovanej
v ontológií a nie na základe full textovej zhody textu dopytu.
Výsledky našej práce sú zaznamenané v diplomovej práci, ktorú autor tohto článku
vypracoval v spolupráci so spoločnosti Datalan. Jednotlivé algoritmy sú navrhnuté
doménovo nezávisle a zároveň sú schopné pracovať v tak náročnom jazyku akým je
slovenčina. Nakoľko je komerčné využitie dôležitým faktorom, prototyp sémantického
vyhľadávača bol vo zvolených testoch schopný odpovedať na používateľské dopyty do
60ms v 97% prípadov.
Okrem samotnej rýchlosti vyhľadávača sme v práci preukázali, že používatelia by radi
používali textové vyhľadávanie, no na základe ich skúseností z minulosti s existujúcimi
vyhľadávačmi, neveria výsledkom vyhľadávania. Aj to viedlo respondentov k prikloneniu
sa k formulárovému vyhľadávaniu, ktoré je schopné interpretovať priamo ich požiadavky.
V prvotných fázach vývoja vyhľadávača sme sa s touto požiadavkou nezaoberali, nakoľko
bol hlavným cieľom vysoká presnosť prepisu prirodzeného jazyka do jazyka SPARQL pri
čo najnižšej latencii odpovedí. V súčasnosti sú do vyhľadávača implementované aj
podporné časti, ktoré sú schopné transformovať dopyt v prirodzenom jazyku do podoby
formulárového vyhľadávania. Používateľ tak môže zadávať dopyt v plne prirodzenom
jazyku. Výsledkom je predvyplnený formulár so vstupnými dátami.
Tento stav považujeme za krátkodobí, nakoľko chceme používateľom navrátiť dôveru
v textové vyhľadávanie. Postupne plánujeme posúvať formulárové vyhľadávanie do úzadia.
Vývoj tohto modulu patrí v súčasnosti k jedným z výskumných aktivít spoločnosti.
8 Automatizovaný zber dát
Získavanie sémantiky z dobre štruktúrovaných dát je pomerne jednoduchá úloha. Problém
nastáva v okamihu, kedy sú údaje nepresné a neponúkajú dokonalú a jednotnú štruktúru.
Ideálnym prípadom je zber dát z rôznych zdrojov, kedy sú jednotlivé dátové modely
roztrieštené a je nutné ich zjednotiť jednotnou sémantikou.
Zber dát nie je triviálna úloha a vyžaduje si mnoho času na implementáciu a vývoj
metód, ktoré sú schopné spracovávať rôznorodé neštruktúrované dáta. Do tejto oblasti
spoločnosť investuje v poslednom odbobí nemalé prostriedky. Výsledkom je vytvorený
softvérový prototyp, ktorý poskytuje veľmi zaujímavé výsledky v oblasti zberu
neštruktúrovaných dát vo zvolenej doméne. Vytvorený zberač vie automatizovaným
Zvaná prezentace
61
spôsobom mapovať dáta do ontológie a tak zjednodušiť proces automatizácie anotácie
jednotlivých polí potrebných na zber dát.
Vyvinutý komponent sa skladá z množstva štatistických modelov no súčasne aj
komponentov, ktoré je možné použiť naprieč viacerými aplikáciami. Jedným z nich je aj
nástroj, ktorý je konvertuje prirodzený vstup adresy do normalizovanej formy. Na základe
použitých algoritmov a rámcov, sa nám podarilo postupom času zrýchliť pôvodné
algoritmy spracovania a normalizácie 20 000 nenormalizovaných adries za hodinu na
30 000 nenormalizovaných adries za sekundu. Zároveň je daný nástroj normalizuje dáta
s vysokou úspešnosťou prepisu do normalizovanej formy nad 98 percent.
Vytvorený konvertor adries navyše pracuje so štandardizovanou ontológiou, ktorá je
schválená naprieč teritoriálnymi entitami európskej únie. Nakoľko sme sa snažili
o všeobecnosť nástroja. V súčasnej podobe je nástroj konvertuje do jednotnej podoby
adresy dvoch rôznych krajín v dvoch rôznych jazykoch. Nástroj je okrem iného obohatený
aj o implementácie, ktoré zabezpečujú odhaľovanie teritoriálnych entít v neštruktúrovaných
textoch.
Nakoľko sme v súčasnej dobe na začiatku výskumu v tejto oblasti, plánujeme výsledky
práce spísať a prezentovať aj na vedeckých konkurenciách v budúcnosti. Prvotné výsledky
naznačujú, že smer nášho bádania by mohol priniesť očakávané ovocie.
9 Záver
I keď sú sémantické technológie oproti technológiám založených na SQL databázach
podstatne mladšie, v súčasnej dobe poskytujú dostatočné
vlastnosti na vývoj
kompetitívnych produktov na trhu. Práve vďaka špecifickým vlastnostiam databáz
poskytujú klientom pridanú hodnotu, ktorú je možné dosiahnuť s oveľa nižším úsilím ako
pri použití štandardných relačných databáz. V príspevku sme sa zamerali aj na
pomenovanie niekoľkých oblastí, ktoré nám počas vývoja aplikácie spôsobovali problémy.
Tie sú ale vo väčšine prípadov vyriešené úplne alebo aspoň na úrovni dostatočnej pre
bezproblémový beh aplikácií. Na základe dosiahnutých výsledkov plánuje spoločnosť aj
naďalej vývoj sémantických aplikácií, čím len podčiarkuje, že je spokojná s kvalitou
projektov postavených práve nad týmito technológiami.
Annotation:
Experience with management of semantic content
For many years, Datalan invests in developement of semantic applications and tools for
management of semantic data. In this paper, we introduce some of them, which were
directly developed within company’s research group. As complexity of particular tools is
not trivial, we try to summarize emerged problems during their developement and describe
their added value. Based on our practical experience over last few years, all problems are
analyzed in practical way, which gives reader inside look into semantic development team.
Our paper also contains multiple ideas for future research projects in area of semantic
technologies. At the same time, we present multiple open source projects which could speed
up growth of popularity of semantic technologies.
Petr VRŠEK
ICZ a.s.
Na hřebenech II 1718/10, 140 00 Praha 4
[email protected]
Abstrakt. Přednáška zahrnuje problémy typizace paměťových institucí (společné a
rozdílné rysy), obecnou architekturu procesu digitalizace (ukládání a zpřístupnění
objektů), principy dlouhodobé archivace, model OAIS. Popsány budou informační
balíčky, jejich smysl a struktura. Závěrem bude popsán konkrétní dlouhodobý
digitální repozitář a jeho implementace.
Klíčová slova: digitalizace, dlouhodobé uchovávání digitálních objektů, zpřístupnění
digitálních objektů, artefakt, digital born objekt, digitální data, digitalizovaná data,
digitální objekt, metadata, monografie, periodika, šedá literatura, Long Term
Preservation (LTP), Open Archival Information Systém (OAIS), Producer Submission
Package (PSP), Submission Information Package (SIP), Archival Information Package
(AIP), Dissemination Information Package (DIP), protokol OAI-PMH
1 Úvod
Pod pojmem "proces digitalizace" chápeme obecně jednak podproces skenování fyzických
2D či 3D objektů jakoukoliv technologií do formy množiny digitálních obrazů co možná
nejvyšší dostupné kvality a jednak podproces bezpodmínečně nutného vytváření či
přebírání popisných, technických a strukturáních metadat, která musí být s příslušnými
digitálními obrazy nedílně spojena do jednoho celku, digitálního balíčku.
Cílem tohoto příspěvku není zabývat se digitalizací jako takovou, ale pozornost upřít
především na dlouhodobé ukládání digitálních balíčků, což je prozatím oblast poněkud
zanedbávaná.
Stručně bude pojednáno i o oblasti zpřístupňování digitálních balíčků, bez níž by
digitalizace neměla žádný smysl.
Pojem "artefakt" je používán jako synonymum pojmu "objekt" pouze z toho důvodu, že
je pracovníkům některých typů paměťových institucí bližší. Některé "artefakty" jsou přímo
"digital born" (např. digitální soubory typu .avi dokumentující vystoupení lidového
tanečního souboru), takže u nich nebudeme pojednávat o jejich digitalizaci (digitální již
jsou), ale o jejich dlouhodobém uložení resp. způsobu zpřístupnění široké veřejnosti.
S příchodem éry digital born objektů a digitalizace materiálních objektů došlo zákonitě
k potřebě tato digitální a digitalizovaná data (obecně digitální objekty) jak především trvale
a důvěryhodně ukládat v co nejvyšší kvalitě pro budoucí generace, tak je navíc okamžitě a
v přípustné nižší kvalitě prezentovat širokému okruhu zájemců, např. badatelů. Sloučit
řešení obou těchto protichůdných požadavků do jednoho univerzálního softwarového balíku
není řešením nejvhodnějším a právě níže popisovaná architektura jedno takové vhodné a
vícekrát ověřené řešení nabízí.
Řada institucí nejrůznějšího typu má specifické úkoly a probíhají v nich procesy, které
jsou zdánlivě neslučitelné s procesy institucí jiných, což je dáno i tím, že nejrůznější
DATAKON 2014, Jasná, 25.-27. 9. 2014, pp. 63-70.
64
instituce spadají pod gesce nejrůznějších ministerstev. Přesto však většina institucí,
především tzv. "paměťových", má jeden superproces naprosto společný, který je tvořen
podprocesy: "tvorba digital born objektů" resp. "digitalizace 2D resp. 3D materiálních
objektů", "dlouhodobé až trvalé ukládání vzniklých digitálních objektů" a "co nejrychlejší
prezentace digitálních objektů co největšímu okruhu koncových uživatelů". Co to vlastně
jsou "paměťové instituce", jaké mají společné a jaké mají rozdílné rysy, bude popsáno dále.
Obecně lze konstatovat, že pod velmi medializovaným pojmem "digitalizace" se často
chápe pouhé "skenování" = "tvorba digitálních obrazových souborů", bez bezpodmínečně
souvisejících kroků, kterými například jsou: úprava obrazu, přímé pořízení popisných
metadat k jednotlivým obrazům resp. dotažení popisných metadat k těmto obrazům
z elektronických katalogů, logické uspořádání obrazů a jejich popisných metadat do
příslušných stromových struktur včetně popisů těchto uzlů vyšších úrovní stromové
struktury, konverze souborů .tif pořízených skenery do archivního bezeztrátového
reversibilního formátu .jp2 a prezentačního formátu .jpg, automatické (OCR) nebo
manuální vytěžování informací, vytváření ALTO (Analyzed Layout and Text Object) .xml
souborů a prostých textových souborů z automaticky vytěženého textu.
Závěrem procesu digitalizace jednoho fyzického objektu musí být vytvoření digitálního
objektu (zde pracovně tzv. PSP balíku = Producer Submission Package), většinou ve formě
zapakované adresářové struktury s různými typy souborů na různých úrovních, který
obsahuje jak archivní příp. i prezentační obrazy všech částí skenovaného objektu, tak i
všechna popisná, technická a strukturální metadata na všech relevantních úrovních této
struktury.
Termín "PSP" není žádným oficiálním pojmem či mezinárodním standardem, ale rozšířil
se v digitalizační komunitě prostřednictvím definice standardu Národní knihovny ČR, kde
je používán v rámci definice metadatových formátů pro digitalizaci periodik a monografií viz [1] a [2].
V tomto příspěvku bude pojem "PSP-balíček" používán obecně, jako výsledný produkt
digitalizace jakéhokoliv 2D či 3D fyzického objektu v souhlasu s výše uvedeným obecným
popisem, nikoliv jako konkrétní typ PSP definovaný standardem NK ČR.
Výsledný produkt digitalizace je nutno následně trvale a bezpečně uložit
v dlouhodobém, tzv. LTP (Long Term Preservation) systému, protože jinak obrovské
digitalizační náklady přicházejí nazmar.
Optimálním postupem je současně s exportem PSP-balíčků do LTP exportovat jejich
podmnožinu též do subsytému zpřístupnění, realizovaného většinou jako webový portál či
webová aplikace nad relační databází.
2 Typizace paměťových institucí a jejich sjednocující se potřeby
Paměťové instituce můžeme roztřídit podle různých hledisek, např.
 podle druhu institucí: knihovny, archivy, muzea, univerzity, galerie, výzkumné
ústavy
 nebo podle rozsahu jejich působnosti: privátní, obecní, regionální, celostátní,
evropské, světové
Mezi typy těchto institucí můžeme nalézt rozdíly v těchto oblastech:

v architektonických nárocích na budovy sloužící různým typům paměťových
institucí

v odlišných operacích s objekty

v užívané terminologii, standardech, postupech práce
Vybraný příspěvek


65
v organizačním začlenění institucí
v různých způsobech zpřístupnění objektů klientům:

čtenářům (knihoven) – artefakty: monografie, periodika, hudebniny, CD,
DVD, sochy, obrazy ….

badatelům (archivů) – artefakty: archiválie (prakticky cokoliv)

návštěvníkům (muzeí a galerií) – artefakty: muzejní a galerijní sbírky
(prakticky cokoliv)

studentům (univerzit) – artefakty: převážně šedá literatura, monografie,
periodika

pracovníkům (vědeckých ústavů) – artefakty: převážně šedá literatura,
monografie, periodika.
Mezi typy těchto institucí můžeme však nalézt i významné shody, které je možno popsat
v chronologické škále následovně:
 v době historické:
 existovaly pouze hmotné objekty (knihy, listiny, muzejní exponáty)
 existovaly pouze listinné katalogy (kartotéční lístky), archivní pomůcky a
listinné rejstříky
 se operace s objekty evidovaly pouze v listinné evidenci (např. akvizice,
výpůjčky, zápůjčky, opravy, ošetření, vyřazení,…)
 v době nástupu počítačů a především relačních databázových systémů:
 se evidence metadat objektů příp. i operací s objekty se převedla do
elektronického katalogu instituce, příp. množiny spolupracujících
programových modulů a databází
 v době nástupu velmi kvalitních a rychlých 2D a 3D skenerů nejrůznějších typů
(umožňujících zachránit před definitivním rozpadem velké množství historických
artefaktů nevyčíslitelné hodnoty, alespoň ve formě jejich digitálních obrazů a
popisů) a masovém nárůstu počtu digital born objektů, a to nejen úředních
dokumentů, ale i uměleckých artefaktů (videa, audiovizuální produkce) se podstatně
sjednotily potřeby všech paměťových institucí, protože:
 vůbec poprvé v historii vznikla paměťovým institucím potřeba nejen své
artefakty digitalizovat, ale ukládat je vlastně ještě jednou (nebo i vícekrát)
v digitální podobě a navíc je vzdáleně prezentovat
Současné klíčové potřeby všech typů paměťových institucí můžeme tedy shrnout do
následujících bodů:
 digitalizovat fyzické objekty
 bezpečně trvale uložit digitální i digitalizované objekty včetně jejich metadat a
zaručit jejich čitelnost a srozumitelnost v daleké budoucnosti
 vzdáleně zpřístupnit digitální i digitalizované objekty včetně jejich vybraných
metadat
Proč digitalizovat a trvale uchovávat image i metadata fyzických objektů?
 pro umožnění vzdáleného přístupu k fyzickým objektům
 pro případ zničení originálu z důvodu
 opotřebení fyzického objektu používáním
 degenerace materiálu fyzického objektu
 katastrofy v paměťové instituci
 kvůli pátrání po ukradených objektech
 kvůli tvorbě kvalitních replik fyzických objektů i ve vzdálené budoucnosti
66
Na základě těchto potřeb můžeme navrhnout principiální schema architektury
informačního systému paměťové instituce.
3 Architektura informačního systému paměťové instituce
Hlavními komponentami informačního systému splňujícího výše popsané požadavky jsou
čtyři zcela nezávislé subsystémy, vzájemně komunikující přes příslušná rozhraní API,
každý se zcela specifickými úkoly. Jsou to:
 Digitalizační jednotka
 Systém dlouhodobého uchovávání, Long Term Preservation (LTP), vybudován dle
modelu OAIS
 Katalog objektů paměťové instituce s množinou nadstavbových aplikací
 Subsystém zpřístupnění s možností sklízení svého obsahu jinými systémy
Následuje obrázek navrhované architektury a její podrobnější popis:
3.1
Digitalizační jednotka
Pro každý typ instituce je vhodné navrhnout jinou kombinaci skenerů s přihlédnutím
k funkcím a finančním možnostem. Skenery jsou základem, k nim je však vždy potřeba
dodat digitalizační SW na sdíleném serveru, dostatek pracovišť a pracovních stanic,
operativní datové úložiště pro skeny a metadata, dostatečné personální zajištění
digitalizační jednotky.
Skenery jsou řady typů dle různých způsobů třídění, např.: knižní, dokumentové, robotické,
ruční, kamerové, portálové, bubnové, 2D, 3D atd.
3.2
Systém dlouhodobého uchovávání, Long Term Preservation (LTP), vybudovaný
dle modelu OAIS
Zajišťuje digitálním objektům po neomezenou dobu: životaschopnost (viability), čitelnost
(renderability), pochopitelnost (understandability), autentičnost (autenticity), identifikaci
(identification).
67
Budován by měl být na základě mezinárodně nejuznávanějšího modelu OAIS (Open
Archival Information Systém) definovaném normou ISO - viz [3].
Funkční části modelu jsou znázorněny na následujícím obrázku. Model pracuje
s následujícími datovými entitami, jejichž význam je konkretizován v souladu
s navrhovanou architekturou paměťové instituce:
Submission Information Package (SIP)
 vstupní informační balíček vytvářený původcem (Producer), obsahuje obrazy a
metadata vzniklá v digitalizační jednotce či přímo digital born objekty. Balíčky SIP
jsou buď přímo totožné s výstupy digitalizační jednotky, čili s balíčky PSP
(Producer Submission Package), nebo se z technických a archivačních důvodů na
optimální SIPy z PSP ještě transformují.
Archival Information Package (AIP)

archivní informační balíček, který je dlouhodobě uložen v několika kopiích na více
archivních úložištích, optimálně v geograficky oddělených lokalitách
Dissemination Information Package (DIP)

výstupní informační balíček, který se operativně vytváří z balíčků AIP na základě
dotazu konzumenta archivu
Systém LTP dle OAIS se skládá ze základních funkčních modulů, zde popsány jejich
prakticky nejdůležitější činnosti a vlastnosti:
 Ingest (příjem) kontroluje syntaxi i sémantiku SIPů přijímaných od původce
(Producer). Vytváří z obrazů a metadat obsažených v SIPech AIPy a tyto v několika
identických kopiích ukládá do několika nezávislých, geograficky oddělených
archivních úložišť (Archival Storage). Samotná metadata vytěžená ze SIPů ukládá
do databáze (Data Management).
 Acces (přístup) umožňuje konzumentovi (Consumer) na základě dotazů získat jak
informace o uložených datech z modulu Data Management, tak přímo data samotná
ve formě balíčků DIP.
 Preservation Planning (plánování uchovávání) spouští v pozadí periodické kontroly
všech kopií uložených AIP a při zjištění chyby nějaké kopie ji nahražuje kopií
68
správnou. Dále umožňuje plánování a realizaci dávkových migrací zastaralých typů
souborů na typy moderní. Původní balíčky AIP se nikdy nemažou, nýbrž se
"přebalují", čili ke starým souborům se "přibalují" soubory nově vytvořené.
 Administration (administrace) je modul, jehož prostřednictvím se vykonává správa
celého systému
Z praktických zkušeností vyplývá, že není vhodné využívat LTP systém přímo jako
systém zpřístupnění pro velkou množinu uživatelů, či dokonce veřejnost, protože jeho
zdroje se musí využívat především na příjem a kontrolu balíčků a na periodické uchovávací
akce, přičemž vybavovací doba obrovských archivních úložišť je z principu dlouhá, už i
vzhledem k tomu, že se často kombinují různé typy digitálních úložišť (s přímým
přístupem, se sekvenčním přístupem) pro jednotlivé sady kopií AIP.
Modul Access je vhodný pro "insidery" LTP systému, tedy administrátory, archiváře,
knihovníky, muzejníky, galeristy, atd. převážně pro ten účel, že potřebují z nejrůznějších
důvodů získat z LTP originální, velmi kvalitní a objemné digitální obrazy artefaktů pro
publikační účely, či chtějí část obsahu LTP vyexportovat na jiné úložiště, přičemž na
vybavovací době DIP příliš nezáleží.
Pro přístup většiny uživatelů je optimální vybudovat speciální, nezávislý, velmi rychlý
subsystém zpřístupnění, obsahující pouze podmnožinu originálních metadat a pouze
degenerované (silně komprimované) kopie archivních obrazů.
3.3
Katalog objektů paměťové instituce
Je to architektonicky nejstarší komponenta, specifická dle typu instituce. V metadatech
objektu se evidují jak vlastnosti objektů, tak historie operací s objekty.
Katalog eviduje objekty většinou v hierarchické struktuře, popisná metadata eviduje ke
každé úrovni. Dříve existovaly spíše specifické metadatové modely, podle typu instituce.
Metadatové modely jsou v neustálém vývoji, existuje snaha o namapování atributů do
modelů univerzálních – pro všechny typy institucí.
Nad katalogem existuje velká množina nejrůznějších aplikací, jak postupně
v paměťových institucích chronologicky vznikaly, např. výpůjční systém, správa fondu,
restaurování fondu, systém zápůjček atd.
3.4
Subsystém zpřístupnění
Obsahuje vybraná popisná metadata z balíčků AIP (obsažená většinou též v katalogu) a
umožňuje na jejich základě zpřístupňovat uživatelské (degenerované) kopie archivních
obrazů velké komunitě zájemců přes webové rozhraní.
Hlavní vlastností subsystému zpřístupnění musí být rychlá odezva při masivním
paralelním přístupu.
Mimo specifického webového uživatelského rozhraní disponují některé subsystémy
zpřístupnění i strojovým rozhraním podporujícím protokol OAI-PMH (Open Archives
Initiative – Protocol for Metadata Harvesting) pro sklízení metadat externími poskytovateli
služeb.
Nejrozšířenějším a nejuniverzálnějším metadatovým standardem popisných metadat je
Dublin Core (dc:) – viz [5], který je i základem metadatového schematu systému
Europeanahttp: //www.europeana.eu/, který umožňuje zpřístupnit informace o artefaktech
paměťových institucí napříč státy a typy paměťových institucí.
Je proto velmi vhodné, aby popisná metadata digitalizovaných objektů uložená v rámci
balíčků AIP v xml-souborech dle standardu METS – viz [4], obsahovala i sekci Dublin
Core, protože propagací metadat a uživatelských kopií digitálních obrazů z LTP-systémů
69
do subsystémů zpřístupnění a následným sklízením subsystémů zpřístupnění resp. katalogů
paměťových institucí se tak informace o jednotlivých artefaktech i digitální obrazy těchto
artefaktů nejrůznějších typů paměťových institucí dostanou ke koncovému uživateli
prostřednictvím jeho jediného dotazu, necíleného na na konkrétní typ instituce.
4 Implementace LTP systému ICZ DESA edice DEA v Archivu města Brna
Stručně popíšeme jednu konkrétní implementaci repozitáře ICZ DESA edice DEA (LTP
systém vybudovaný dle standardu OAIS se základními vlastnostmi popsanými v kapitole
3.2). Tato implementace je součástí projektu "Digitalizace archivu města Brna", v jehož
rámci se digitalizují, dlouhodobě ukládají a veřejnosti zpřístupňují dokumenty sčítání lidu
od roku 1857 – 1900.
Stručné schema architektury celého projektu je znázorněno na obrázku níže.
Celý systém byl optimálně dekomponován na podsystémy různých dodavatelů, z nichž
LTP systém, na obrázku označený jako "Elektronická archivace – Systém digitálního
archivu" (v červeném čárkovaném obdélníku) vyvinula a dodala firma ICZ a.s.
Subsystému zpřístupnění tohoto projektu, na obrázku v modrém čárkovaném obdélníku,
je možno klást otázky na oficiální webové stránce Archivu města Brna – viz [6].
4.1
O digitalizovaných dokumentech
Operáty sčítání lidu jsou rozpadající se listiny velkých formátů převážně z 19. století, na
nichž jsou ručně, částečně kurentem, částečně latinkou, částečně česky, částečně německy,
částečně čitelně, částečně nečitelně zapsány sčítacími komisaři údaje o osobách bydlících
v roce sčítání v jednotlivých bytech brněnských domů.
Jmenné rejstříky jsou indexovými knihami obsahujícími jména osob z jednotlivých
ročníků sčítání a odkazující na příslušné domovní adresy. Tyto rejstříky, pečlivě vytvořené
archiváři v 19. století, umožnily vazbou osob na domy inteligentní vyhledávání operátů
podle osob a ročníků sčítání v subsystému zpřístupnění.
Díky projektu digitalizace nejsou již zdigitalizované rozpadající se operáty a jmenné
rejstříky vůbec přístupné a jsou uloženy v depozitáři archivu.
4.2
O systému ICZ DESA edice DEA
LTP systém lze dekomponovat na "Systém digitálního archivu" (což je veškerá OAIS
funkcionalita) a na "Systém archivního úložiště", což můžeme chápat jako nízkoúrovňový
systém pro pouhé ukládání dat. Tato dekompozice se dobře osvědčila již v řadě
implementací, protože v rámci "Systému archivního úložiště" je možno použít vějíř
nejrůznějších archivních technologií podle požadavků zákazníka (od prostých filesystémů
až po sofistikované archivační systémy) pouze pro jediný účel: umožnit uložit a číst
pojmenované AIP ve formě souborů .zip či jiných balíčkových souborů.
V dané implementaci exportuje modul Ingest systému DESA ve fázi tvorby AIP popisná
metadata a uživatelské náhledy do relační databáze Subsystému zpřístupnění, jejíž
konceptuální datový model je vytvořen tak, aby relativně rychle poskytl náhledy operátů a
jmenných rejstříků podle výběrových podmínek zadaných badatelem přes webové rozhraní
– viz [6].
Přímý přístup do archivu systému DESA mají pouze archiváři a správci systému, kteří
mohou získávat plnohodnotné balíčky DIP obsahující veškerá metadata a obrazy stran
operátů a rejstříků v archivní kvalitě. Na speciální, archivářem schválený dotaz mohou
získat balíčky DIP i badatelé.
70
Literatura
[1] Hutař, J., Švástová, P., Kvasnica, J.: Definice metadatových formátů pro digitalizaci periodik, verze
1.5, www.ndk.cz/digitalizace/nove-standardy-digitalizace-od-roku-2011
[2] Hutař, J., Švástová, P., Kvasnica, J.: Definice metadatových formátů pro digitalizaci monografických
dokumentů
(monografií,
kartografických
dokumentů,
hudebnin),
verze
1.1.1
www.ndk.cz/digitalizace/nove-standardy-digitalizace-od-roku-2011
[3] Open archival information system - reference model - ISO 14721:2003, this standard has been revised
by: ISO 14721:2012. Wikipedie: http://en.wikipedia.org/wiki/Open_Archival_Information_System
[4] METS, Metadata Encoding and Transmission Standard, http://www.loc.gov/standards/mets/
[5] DCMI, Dublin Core Metadata Initiative, http://dublincore.org/
[6] Digitální archiv města Brna, http://digiarchiv.brno.cz/home
Annotation:
The paper focused on the typing problems of memory institutions (common and different features),
the general architecture of the digitization process (storage and access objects), the principles of longterm archiving, OAIS model. Information packages will be described, their purpose and structure.
Finally, the specific long-term digital repository and its implementation will be described.
Vybrané příspěvky
Ján GENČI1, Martin OLOŠTIAK2
1
Katedra počítačov a informatiky, FEI, technická univerzita v Košiciach
Letná 9, 042 00 Košice
2
Inštitút slovakistických, mediálnych a knižničných štúdií, PU v Prešove
Ul. 17. novembra 15, 080 01 Prešov
[email protected]
[email protected]
Abstrakt. Cieľom príspevku je informovať o prebiehajúcich aktivitách v oblasti
identifikácie a spracovania viacslovných pomenovaní resp. výrazov pre slovenský
jazyk a niektorých dosiahnutých priebežných výsledkoch.
Kľúčové slová: viacslovné pomenovania, viacslovné výrazy
1 Úvod
Jednou z mnohých úloh pri sémantickom spracovaní textov je identifikácia objektov
resp. činností objektmi vykonávaných. Objekty sú primárne v textoch reprezentované
podstatnými menami, činnosti slovesami. Najjednoduchším prvoplánovým spôsobom
identifikácie týchto konštrukcií je budovať databázu slov, ktorá eviduje slová a mapuje ich
na objekty, resp. činnosti. Pri aplikácii takejto databázy však veľmi rýchlo dospejeme
k prvým problémom spojeným s nejednoznačnosťou takejto transformácie – napr. slová
mier (subst. nom. sg. aj verbum – imperatív od mieriť), diel (subst. nom. sg., ale aj gen. pl.
– subst. dielo), zviera (subst. nom. sg. aj verbum zvierať – 3. os.). Tento problém je
pomerne známy a rieši sa rôznymi metódami dezambiguácie textu.
Bohatosť jazyka vedie k tomu, že jednotlivé slová na označenie všetkých objektov
a činností vo všetkých situáciách nestačia, a preto musíme používať slovné konštrukcie
zložené z viacerých slov, tzv. viacslovné pomenovania, resp. viacslovné výrazy – napr.
starý otec, vysoká pec, dať pokoj a pod. Viacslovné pomenovania predstavujú ďalší
problém sémantického spracovania textov, pretože je ich potrebné v textoch najprv
identifikovať a prípadne následne rozhodnúť, či skutočne ide o viacslovné
pomenovanie/výraz, alebo sa jedná o iný typ konštrukcie (napr. starý otec – ide o deda,
alebo o otca, ktorý je starý?).
Cieľom prezentovaného príspevku je poukázať na niektoré aktivity a parciálne
výsledky, ktoré sa realizujú v oblasti spracovania viacslovných pomenovaní pre slovenský
jazyk.
2 Viacslovné pomenovania/výrazy a aktuálny stav v slovenčine
Viacslovné pomenovanie/výraz je definovaný ako „idiosynkratická interpretácia
prekračujúca hranice slova” [5]. Zrozumiteľnejšie, „je to lexéma (jednotka lexikálneho
významu) tvorená dvoma alebo viacerými lexémami, majúca vlastnosti neodvoditeľné od
74
vlastností individuálnych lexém, alebo ich zvyčajnej kombinácie“ [11]. Otázka
viacslovných pomenovaní v slovenčine ostávala pomerne dlho neriešenou problematikou.
Prvé lastovičky zrejme znamenali publikácie [6] a [7], širšou aktivitou je potom projekt
„Slovník viacslovných pomenovaní (lexikografický, lexikologický a komparatívny
výskum)” [2,4] riešený v rámci grantového program slovenskej Agentúry pre podporu vedy
a výskumu (APVV). Tento projekt sa pre nás nakoniec stal vstupnou bránou do projektu
ICT COST Action IC1207 - Parsing and multi-word expressions. Towards linguistic
precision and computational efficiency in natural language processing (PARSEME)
[10,12].
3 Identifikácia viacslovných pomenovaní
Pri identifikácii viacslovných výrazov/pomenovaní sa používajú dva základné prístupy:
a) manuálne spracovanie a b) automatické spracovanie. Automatické spracovanie môže byť
potom založené na i) lingvistických, ii) štatistických a iii) kombinovaných metódach.
Náš APVV projekt „Slovník viacslovných pomenovaní“, iniciovaný lingvistami, je
založený na klasickom manuálnom spracovaní, založenom na manuálnej excerpcii
termínov lingvistami a následným iteratívnym procesom revízie vybraných termínov.
V súčasnosti je excerpovaných okolo 60 tisíc viacslovných pomenovaní, ktoré v najbližšom
období doplníme frekvenciami excerpovaných termínov podľa štatistík 1 Slovenského
národného korpusu ([13]). Na základe [9], predpokladáme využiť charakteristiku bodová
vzájomná informácia (pointwise mutual information, PMI).
Automatizované spracovanie založené na lingvistických metódach sú založené na
metódach značkovania textu (POS (part-of-speech) tagger) a syntaktických a sémantických
metódach. Pre slovenčinu sú tieto metódy do značnej miery obmedzené, pretože neexistuje
dostatočná dátová základňa, ktorá by takéto spracovanie umožňovala. V tomto prípade je
možné spracovanie založiť iba na čiastočných zdrojoch dostupných v rámci projektov
Jazykovedného ústavu Ľudovíta Štúra – POS (part-of-speech) tagger, Slovenský
závislostný korpus (malá množina syntakticky anotovaných textov) [8].
Zaujímavou alternatívou pri lingvistických metódach je využitie dostupných zdrojov
v podobe rôznych typov slovníkov – synonymických, terminologických, či prekladových,
resp. ich kombináciou. Konštrukcie pozostávajúce z viacerých slov v synonymických
radoch môžu byť priamym zdrojom viacslovných pomenovaní, podobne ako heslá
v terminologických slovníkoch. Prekladové slovníky je možné využiť či už na extrakciu,
alebo overenie, či daná konštrukcia je viacslovným pomenovaním.
Okrem uvedených prístupov boli pokusy aj o uplatnenie štatistických metód na
identifikáciu viacslovných pomenovaní/výrazov. Podľa [1], miery ako bodová vzájomná
informácia, vzájomná informácia (mutual information), χ2 skóre, logaritmická vierohodnosť
(log-likelihood) sú často používanými, pričom práve miera bodová vzájomná informácia sa
zdá byť asi najlepšie schopná rozlíšiť viacslovné pomenovania/výrazy od iných jazykových
konštrukcií.
Zatiaľ sme experimentovali s bodovou vzájomnou informáciou, ktorá je definovaná
PMI(x,y)=log(p(x,y)/p(x)p(y)) [3], kde p(x,y) je pravdepodobnosť spoločného výskytu slov
x a y, a p(x) a p(y), sú pravdepodobnosti výskytu jednotlivých slov. Pravdepodobnosti
výskytu slov sme odvodili od frekvencie jednotlivých slov resp. ich bigramov v štatistikách
Slovenského národného korpusu [13], zároveň sme sa ten istý výpočet zopakovali na dátach
1
http://korpus.juls.savba.sk/files/prim-6.1/
75
získaných z vyhľadávača Google (reportovaný ako približný počet výsledkov), a taktiež
sme overovali výskyt daného viacslovného výrazu v prekladovom slovníku. Výsledky pre
viacslovné pomenovania spojené so slovom otec sú prezentované v Tab. 1. Tabuľka je
rozdelená na štyri časti. Stĺpce tabuľky označené SNK a Google obsahujú frekvencie
jednotlivých slov viacslovných pomenovaní v zodpovedajúcich zdrojoch, teda v štatistikách
Slovenského národného korpusu a vyhľadávači Goole, pričom f(ab) je frekvencia
viacslovného pomenovania, f(a) a f(b) sú frekvencie jednotlivých slov, PMI je hodnota
bodovej vzájomnej informácie určenej na základe vzťahu uvedeného vyššie; stĺpec MWE
označuje, či ide skutočne o viacslovné pomenovanie a stĺpec Slovník označuje, či sa daný
viacslovný termín nachádza v slovensko-anglickom (A v danom stĺpci) a/alebo slovenskoruskom (R v danom stĺpci) prekladovom slovníku2.
Tab. 1: Výpočet bodovej vzájomnej informácie (PMI) a určenie MWE
krstný otec
prastarý otec
nebohý otec
starostlivý otec
svätý otec
nebeský otec
vzorný otec
milujúci otec
duchovný otec
otec biskup
hrdý otec
otec arcibiskup
nešťastný otec
starý otec
šťastný otec
vlastný otec
dobrý otec
f(ab)
1727
792
206
226
10885
1047
96
215
706
1111
208
310
92
11162
138
404
318
SNK
f(a)
3364
1581
3241
1271
44369
3651
1191
1897
14789
188224
10757
188224
8674
77050
33018
58045
144632
f(b)
188224
188224
188224
188224
188224
188224
188224
188224
188224
31464
188224
16478
188224
188224
188224
188224
188224
PMI
3,44
3,43
2,53
2,98
3,12
3,18
2,63
2,78
2,4
2,27
2,01
2
1,75
2,89
1,35
1,57
1,07
f(ab)
42500
11700
10100
6540
338000
10100
2270
3770
10100
10600
7570
4580
2420
60500
5880
13300
8030
Google
f(a)
58400
39600
38300
39900
2890000
118000
31500
61100
283000
4430000
345000
4430000
170000
6010000
1690000
5840000
9500000
MWE Slovnik
f(b)
4430000
4430000
4430000
4430000
4430000
4430000
4430000
4430000
4430000
386000
4430000
219000
4430000
4430000
4430000
4430000
4430000
PMI
3,22
2,82
2,77
2,57
2,42
2,29
2,21
2,14
1,91
1,79
1,69
1,67
1,51
1,36
0,89
0,71
0,28
A
A
RA
R
A
A
A
R
A
A
A
A
A
RA
A
R
Pre viacslovné pomenovania založené na slove auto, sme spracovali podobnú tabuľku.
Na základe týchto dát Tab. 2 prezentuje zhluky viacslovných pomenovaní pri zotriedení
podľa rôznych kritérií (f-SNK a f-Google znamenajú zotriedenie podľa frekvencie
viacslovných pomenovaní podľa korpusu resp. vyhľadávača Google, PMI zase zotriedenie
podľa hodnoty bodovej vzájomnej informácie spočítané podľa dát z SNK, resp. Google).
Zaujímavosťou je, že kým v prípade viacslovných pomenovaní v spojení so slovom otec,
najlepšie výsledky sme dosiahli zotriedením podľa frekvencie výskytu, v prípade spojení so
slovom auto, to bola práve bodová vzájomná informácia.
2
http://www.slovnik.sk
76
Tab. 2: Zhluky, zoradené podľa rôznych kritérií pre otec (vľavo) a auto (vpravo)
f-PRIM
f-Google
PMIPRIM
PMIGoogle
f-PRIM
f-Google
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
N
N
N
N
A
N
A
A
N
A
N
A
A
N
N
N
A
A
A
N
N
A
A
N
N
N
N
N
A
A
A
A
N
N
A
A
N
A
A
A
N
A
N
A
N
N
N
N
N
N
N
A
A
N
N
A
N
N
N
N
N
N
N
N
N
N
N
N
N
N
A
A
A
PMIGoogle
N
A
A
N
N
A
N
N
A
N
A
N
A
N
A
A
A
A
A
A
N
N
A
N
A
A
A
A
PMIPRIM
A
A
A
4 Záver
Cieľom príspevku bolo informovať o aktuálnom stave problematiky a prebiehajúcich
aktivitách v oblasti spracovania viacslovných pomenovaní a výrazov pre slovenský jazyk.
Poďakovanie
Táto práca bola podporená Agentúrou na podporu výskumu a vývoja na základe zmluvy
č. APVV-0342-11.
Literatúra
1.
2.
3.
Caseli H., Villavicencio A., Machado A., Finatto M.: Statistically-Driven AlignmentBased Multiword Expression Identification for Technical Domains. Proceedings of the
2009 Workshop on Multiword Expressions, ACL-IJCNLP 2009, pages 1–8, Suntec,
Singapore, 6th August 2009
Ivanová, M.: Kolokácie v korpuse, viacslovné pomenovania v slovníku. (Úvodné
poznámky k príprave slovníka viacslovných pomenovaní) In: Jazyk je zázračný
organizmus... Metamorfózy jazyka a jazykovedy. Zborník príspevkov venovaných
prof. PhDr. Ivorovi Ripkovi, DrSc., emer. prof. PU, pri príležitosti jeho životného
jubilea. Eds. M. Imrichová – J. Kesselová. Prešov: Filozofická fakulta Prešovskej
univerzity v Prešove 2013, ss. 132 – 147.
Mihalcea R., Radev D.: Graph-Based Natural Language Processing and Information
Retrieval. Cambridge University Press, 201
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
77
Ološtiak M., Ivanová M., Genči J.: Slovník viacslovných pomenovaní (lexikografický,
lexikologický a komparatívny výskum). Koncepcia projektu. In: Slovenská reč :
časopis pre výskum slovenského jazyka. Roč. 77, č. 5-6 (2012), s. 259-274.
Sag I. A. et al.: Multiword Expressions: A Pain in the Neck for NLP (2002) in: Lecture
Notes in Computer Science, Vol. 2276, pp. 1-15.
Staš, J., Hládek, D., Juhár, J., and Trnka, M., Automatic Extraction of Multiword
Expressions using Linguistics Constraints for Slovak LVCSR. In: Proc. of the 6th
International Conference on Natural Language Processing and Multilinguality,
SLOVKO 2011, Modra, Slovakia, 2011, pp. 138-145.
Staš J. et. al: Automatic Extraction of Multiword Units from Slovak Text Corpora. In.:
Natural Language Processing, Corpus Linguistics, E-learning. In: Proc. of the 7th
International Conference SLOVKO 2013, Bratislava, Slovakia, 13–15 November 2013
Šimková M., Gajdošová K.: Slovenský závislostný korpus. Dostupné na:
http://korpus.juls.savba.sk/attachments/publications/2007-Simkova-GajdosovaSZK.pdf
Villavicencio A., Caseli H., Machado A.: Identification of Multiword Expressions in
Technical Domains: Investigating Statistical and Alignment-based Approaches. In:
Proceeding STIL '09 Proceedings of the 2009 Seventh Brazilian Symposium in
Information and Human Language Technology, Pages 27-35
ICT COST Action IC1207 Parsing and multi-word expressions. Towards linguistic
precision and computational efficiency in natural language processing (PARSEME).
http://www.cost.eu/domains_actions/ict/Actions/IC1207
Multiword expression. Wikipedia. http://en.wikipedia.org/wiki/Multiword_expression
PARSEME (PARSing and Multi-word Expressions). Towards linguistic precision and
computational efficiency in natural language processing http://typo.unikonstanz.de/parseme/
Slovenský národný korpus – prim-6.1-public-all. Bratislava: Jazykovedný ústav Ľ.
Štúra SAV 2013. Dostupný z WWW: http://korpus.juls.savba.sk.
Reprezentácia časových radov pomocou opakujúcich
sa vzorov
Jakub ŠEVCECH, Mária BIELIKOVÁ
Ústav informatiky a softvérového inžinierstva, Fakulta informatiky a informačných
technológií, Slovenská technická univerzita v Bratislave
Ilkovičova 2, 812 19 Bratislava
{jakub.sevcech, maria.bielikova}@stuba.sk
Abstrakt. Počas uplynulých rokov bolo navrhnutých veľa rôznych reprezentácií
časových radov, ktoré mali za úlohu redukciu dimenzionality a podporu rôznych
algoritmov na spracovanie časových radov. Pomerne zaujímavou skupinou sú
symbolické reprezentácie, ktoré umožňujú použitie rôznych algoritmov používaných
pri spracovávaní textu v úlohách spracovania časových radov. Tieto reprezentácie
však trpia nedostatkami pri porovnávaní časových radov za prítomnosti šumu a/alebo
natiahnutia na časovej osi alebo na osi hodnôt. V tomto príspevku navrhujeme
reprezentáciu časových radov založenú na transformácii opakujúcich sa vzorov na
symboly. Hlavným cieľom tejto reprezentácie je redukcia dimenzionality časového
radu pri zachovaní možnosti zohľadnenia šumu a posunutí pri porovnávania radov.
Základným komponentom navrhnutej reprezentácie časového radu sú opakujúce sa
sekvencie časového radu získané pomocou metriky na výpočet podobnosti časových
radov schopnej pracovať so šumom, posunutím a natiahnutím ako napríklad metóda
Spatial Assembling Distance (SpADe).
Kľúčové slova: prúd dát, reprezentácia časového radu, redukcia dimenzionality
podobnosť vzorov.
1 Úvod
So stále sa zväčšujúcim objemom dát produkovaných rôznymi senzormi alebo aplikáciami
sa musíme vysporiadať s problémami s ich uchovávaním a spracovaním. Doména
spracovania týchto veľkých objemov dát (nazývaná tiež veľké dáta, angl. Big Data) sa
počas ostatných rokov teší záujmu výskumníkov ako aj praktikov. Keď hovoríme
o veľkých dátach, tak máme väčšinou na mysli len veľké objemy dát. V roku 2001 však
Doug Laley definoval veľké dáta na troch dimenziách [9]: objem, rýchlosť a rôznorodosť.
Tieto dimenzie pomenovávajú vlastnosti dát, ktoré ich robia náročnými na spracovanie.
Neskôr, v roku 2011, Hopkins Brian doplnil túto definíciu o ďalšiu dimenziu [6]:
premenlivosť, ktorá sa odkazuje na veľkú premenlivosť hodnôt typickú pre spracovanie
veľkých objemov dát a spôsobuje problémy pri odlíšení zmysluplnej informácie od
náhodného šumu. V rôznych doménach (napr. rôzne analytické nástroje, finančné alebo
herné aplikácie) sú tieto dáta produkované a ďalej spracovávané v podobe prúdu dát.
Motiváciou pre takéto spracovanie sú rôzne problémy spojené s ich uchovávaním alebo
s potrebou poskytovať výsledky v čase vzniku týchto dát. Práve pri spracovávaní prúdu dát
sa do veľkej miery prejavujú problémy spôsobené rýchlosťou vzniku dát a ich
premenlivosťou. Tieto sú doplnené o obmedzenia prostriedkov na ich spracovanie (najmä
80
jediný prechod cez dáta a obmedzená pamäť), s ktorými sa musia algoritmy na ich
spracovanie vysporiadať.
Jedným z prostriedkov na podporu efektívneho spracovania prúdu dát je redukcia
dimenzionality pomocou transformácie na inú reprezentáciu. Počas uplynulých rokov bolo
navrhnutých množstvo reprezentácií časových radov, ktoré redukujú ich dimenzionalitu
a poskytujú podporu pre rôzne algoritmy, ktoré ich ďalej spracovávajú. Takéto časové rady
sú predmetom rôznych úloh analýzy dát ako je napríklad zhlukovanie, klasifikácia, detekcia
anomálií alebo hľadanie často sa opakujúcich vzorov [1].
V príspevku prezentujeme niekoľko najčastejšie používaných reprezentácií časových
radov spolu s ich obmedzeniami a navrhujeme reprezentáciu, ktorá využíva transformáciu
opakujúcich sa vzorov v tvare časového radu na symboly pri reprezentácii časového radu.
Zvyšok príspevku je organizovaný takto. V kapitole 2 prezentujeme viacero
reprezentácií časových radov a metrík na porovnávanie týchto radov spolu s ich
vlastnosťami. V kapitole 3 navrhujeme symbolickú reprezentáciu časových radov
zohľadňujúci opakujúce sa vzory a v kapitole 4 diskutujeme naše závery a ďalšiu prácu.
2 Reprezentácie časových radov a metriky podobnosti
Ako viaceré porovnávacie štúdie ukázali [4, 11], existuje množstvo reprezentácií časových
radov, ktoré sa výrazne odlišujú svojimi vlastnosťami pri použití pri rôznych úlohách a
rôznych dátových sadách. Neexistuje teda jedna reprezentácia, ktorá by konzistentne
prekonávala svojimi vlastnosťami ostatné na rôznych dátových sadách ale je potrebné
vybrať si takú ktorá spĺňa konkrétne potreby.
2.1
Reprezentácie časových radov
V práci [7] autori opisujú jednu z najčastejšie používaných reprezentácií časových radov
PAA (z angl. Piecewise Aggregate Approximation), ktorá transformuje bežiace okno
konštantnej dĺžky nad časovým radom na priemer (alebo inú metriku) hodnôt v okne.
V tejto práci autori porovnávajú túto metódu s ďalšími tromi najčastejšie používanými
reprezentáciami časových radov:
 Rozkladom singulárnych hodnôt (angl. Singular value decomposition)
 Diskrétnou Fourierovou transformáciou (angl. Discrete Fourier transform)
 Diskrétnou vlnkovou transformáciou (angl. Discrete wavelet transform)
Autori ukázali, že zložitejšie metódy ako je napríklad diskrétna Fourierova transformácia
poskytujú mierne lepšie výsledky v porovnaní s jednoduchšími metódami ako napríklad
PAA. Dosiahnuté výsledky sú však porovnateľné a jednoduchšie metódy poskytujú viacero
výhod ako je napríklad menšia výpočtová zložitosť, jednoduchosť na pochopenie a na
implementáciu a vo všeobecnosti sa lepšie hodia na spracovanie veľkého objemu dát.
V práci [10] autori prezentujú hierarchiu rôznych skupín reprezentácií časových radov,
pričom sa sústreďujú na symbolické reprezentácie a porovnávajú ich vlastnosti s inými
reprezentáciami. Symbolické reprezentácie transformujú rad reálnych hodnôt z časového
radu na rad symbolov, čo umožňuje používanie metód z oblasti spracovania textu.
Umožňujú použitie rôznych metód, ktoré nie sú aplikovateľné na sekvencie reálnych
hodnôt ako sú napríklad Markovovské modely, suffixové stromy, rozhodovacie stromy atď.
Jedna z najčastejšie používaných symbolických reprezentácií časových radov je SAX
(z angl. Symbolic Aggregate approximation) [10]. Táto reprezentácia najskôr transformuje
časový rad pomocou PAA a následne označuje jednotlivé PAA koeficienty pomocou
81
symbolov, kde každý symbol reprezentuje jedno okno fixnej dĺžky z pôvodného časového
radu. Táto reprezentácia časového radu našla množstvo aplikácií pri analýze dát nad
časovými radmi ako je napríklad detekcia anomálií pomocou metódy HOT SAX (z angl.
Heuristically Ordered Time series using Symbolic Aggregate ApproXimation) [8], ktorá
slúži na hľadanie najobvyklejších sekvencií v priebehu časového radu. Metóda SAX však
zdieľa obmedzenia spoločné pre všetky symbolické reprezentácie časových radov: kvôli
transformácii okna s fixnou dĺžkou na neprekrývajúce sa symboly je veľmi náročné
pracovať s časovými radmi za prítomnosti šumu, posunutia a natiahnutia na časovej osi
alebo na osi hodnôt. V tejto práci navrhujme symbolickú reprezentáciu, ktorá umožňuje
pracovať aj pri takýchto obmedzeniach.
2.2
Metriky podobnosti
Popri rôznych reprezentáciách časových radov, bolo vytvorených množstvo metrík
podobnosti, ktoré dokážu s takto reprezentovanými časovými radmi pracovať. V práci [4]
autori prezentujú rozdelenie rôznych metrík na výpočet podobnosti medzi časovými radmi
do niekoľkých skupín:
 Metriky s fixným krokom porovnávajú i-tu hodnotu v jednom časovom rade s itou hodnotou v inom časovom rade. Medzi takéto metriky patria napríklad
Menhattanská vzdialenosť alebo Euklidovská vzdialenosť.
 Metriky s pružným krokom porovnávajú bod z jedného časového radu
s viacerými bodmi z iného časového radu. Medzi takéto metriky patrí DTW
(z angl. Dynamic Time Warping) alebo rôzne metriky, ktoré na výpočet
podobnosti využívajú počet operácií potrebných na transformáciu jedného
časového radu na iný.
 Metriky založené na prahu ako napríklad TQuEST, predpokladajú, že dva body
sú ekvivalentné v prípade ak rozdiel medzi nimi nepresahuje stanovený prah.
 Metriky založené na vzoroch ako napríklad SpADe (Spatial Assembling
Distance) porovnávajú tvary priebehu časového radu.
V kontexte našej práce sa sústreďujeme na metriky, ktoré sa dokážu vysporiadať so
šumom, natiahnutím a posunutím. Z rozdelenia vyššie, len metriky s pružným krokom
a metriky založené na vzoroch sú schopné pracovať so šumom a natiahnutím. Z tab. 1 však
vidíme, že metódy ako je DTW majú problém s natiahnutím a posunutím na osi hodnôt.
V našej práci sa preto sústreďujeme na metriky založené na vzoroch, konkrétne na metódu
SpADe [2].
Tab. 1. Vlastnosti metrík na porovnávanie časových radov. Tabuľka prebratá z [2].
Posunutie
času
Natiahnutie
času
Posunutie
hodnôt
Natiahnutie
hodnôt
Šum
Euklidovská
vzdialenosť
nie
čiastočne
nie
nie
nie
DTW
áno
áno
nie
nie
nie
CommonSub
áno
áno
nie
nie
áno
SpADe
áno
áno
áno
áno
áno
82
Metóda SpADe porovnáva lokálne vzory v zdrojovom časovom rade s posúvajúcim sa
oknom porovnávanom časovom rade. Lokálny vzor je reprezentovaný trojicou l=(θt,θa,θs)
zloženou z pozície, strednej hodnoty a identifikátorom jedného zo základných tvarov.
Obr. 1 reprezentuje proces porovnávania lokálnych vzorov s posúvajúcim sa oknom
v časovom rade.
Obr. 1. Príklad porovnávania lokálneho vzoru s posúvajúcim sa oknom v časovom rade
pomocou metriky SpADe. Obrázok prebraný z [2].
Vďaka rozkladu hľadaného vzoru na lokálne vzory metrika SpADe umožňuje vyhľadávanie
vzorov a podvzorov, a zároveň dokáže pracovať s šumom, natiahnutím a posunutím na
časovej osi a osi hodnôt. Ďalšou výhodou tejto metódy je možnosť jej použitia nielen na
statických kolekciách časových radov ale aj na prúde dát.
3 Opakujúce sa vzory ako reprezentácia časového radu
Navrhli sme reprezentáciu časových radov, ktorá adresuje problémy spojené so
spracovaním časových radov, ako sú zašumenie, posunutie a natiahnutie opakujúcich sa
vzorov na časovej osi alebo na osi hodnôt. Základnou súčasťou navrhnutej metódy je
transformácia opakujúcich sa vzorov v priebehu časového radu na symboly a vyhľadávanie
opakujúcich sa vzorov metódou odolnou voči šumu, posunutiu a natiahnutiu. Symbolická
reprezentácia časového radu nám umožňuje používať rôzne algoritmy z domény
spracovania textu pri analýze časových radov.
Naša metóda reprezentácie prúdu dát je inšpirovaná metódou na vyhľadávanie
frekventovaných vzorov v prúde dát prezentovanej v [5]. Autori tu použili model založený
na sklopenom okne (angl. Tilted window model) [3] ako prostriedok na ukladanie
frekventovaných vzorov na rôznych úrovniach granularity a ako prostriedok na zachovanie
pamäťových ohraničení pri uspokojivej presnosti počas spracovania potencionálne
nekonečných prúdov dát (obr. 2).
83
Obr. 2. Model založený na sklopenom okne. S časom pohybujúcim sa do minulosti model
uchováva dáta na zvyšujúcej sa granularite. Obrázok prebraný z [3].
V práci [5] autori používajú model založený na sklopenom okne na ukladanie tabuliek
frekventovaných vzorov s do minulosti sa znižujúcou granularitou. Takto sú uložené
stabilne frekventované vzory, ktoré sa opakovane objavujú počas dlhých časových období
a rovnako sú uložené aj nové vzory, s vyššou granularitou – frekventované počas kratšieho
časového obdobia.
Túto metódu sme rozšírili o identifikáciu vzorov v tvare priebehu časového radu
pomocou metódy SpADe. SpADe používame na identifikáciu vzorov v priebehu časového
radu a na porovnávanie vzorov s prichádzajúcim prúdom dát. Nájdené vzory sa ukladajú na
viacerých úrovniach granularity, kde s rastúcim vekom vzoru sú uchovávané len vzory,
ktoré sa opakovane objavujú v prichádzajúcich dátach a teda sú stabilne frekventované za
dlhšie časové obdobie. Zároveň sa s vyššou granularitou uchovávajú aj novšie vzory a teda
sa navrhnutá metóda postupne rozširuje o stále nové vzory. Uchovávaním len dlhodobo
frekventovaných vzorov, s granularitou klesajúcou s vekom vzoru, je zabezpečené splnenie
pamäťových obmedzení, spojených so spracovaním potencionálne nekonečného prúdu dát.
V druhej fáze transformácie časového radu na nami navrhnutú reprezentáciu
vyhľadávame identifikované frekventované vzory v prichádzajúcom prúde dát
a transformujeme prichádzajúci prúd dát na prúd symbolov, kde každý nájdený vzor
reprezentujeme jedným symbolom. Obr. 3 znázorňuje príklad identifikovaných vzorov
v prichádzajúcom prúde dát a jeho transformáciu na prúd prekrývajúcich sa symbolov.
Obr. 3. Vzor identifikovaný v bežiacom okne pomocou metódy SpADe je transformovaný
na symbol reprezentujúci tento vzor. Časový rad sa transformuje na postupnosť
prekrývajúcich sa symbolov.
84
Každé prekrývajúce sa okno (s definovaným posunutím) je transformované na symbol,
ktorý reprezentuje vzor identifikovaný v tomto okne. Vďaka použitiu metódy SpADe na
porovnávanie vzorov s prichádzajúcim prúdom dát je možné zohľadniť šum, natiahnutie
a posunutie hodnôt na časovej osi ako aj na osi hodnôt. Vďaka transformácii časového radu
na prúd symbolov je zabezpečená redukcia dimenzionality ako aj možnosť použiť rôzne
algoritmy pre spracovanie textu na rôzne úlohy analýzy časového radu.
Pomocou navrhnutej reprezentácie vidíme priamočiare využitie v rôznych úlohách
analýzy prúdu dát, ako je napríklad klasifikácia na úrovni jedného časového radu, ale aj na
úrovni viacerých paralelne bežiacich časových radov, kde vstupom pre klasifikáciu môže
byť sada vzorov (symbolov) identifikovaných nad paralelnými časovými radmi v jednom
momente.
Ďalšou možnosťou využitia navrhnutej reprezentácie je predikcia vývoju časového radu
vďaka možnosti vyhľadávania podvzorov v prichádzajúcom prúde dát pomocou metódy
SpADe. Podobne je možné použiť túto metódu na priamočiaru identifikáciu anomálií
v časovom rade – ak sa prichádzajúce dáta nezhodujú so žiadnym existujúcim vzorom, ide
o anomálny stav.
4 Záver
Navrhli sme symbolickú reprezentáciu časového radu, ktorá transformuje opakujúce sa
vzory v časovom rade na symboly. Na identifikáciu opakujúcich sa vzorov používame
metódu SpADe, vďaka ktorej dokáže reprezentácia pracovať so šumom ako aj posunutím
a natiahnutím na časovej osi a na osi hodnôt. Na ukladanie opakujúcich sa vzorov
používame model založený na sklopenom okne, ktorý uchováva frekventované vzory
s granularitou znižujúcou sa s vekom nájdeného vzoru. Vďaka použitiu sklopeného okna je
možné použiť navrhovanú metódu nie len na reprezentáciu statických kolekcií dát, ale aj na
reprezentáciu potencionálne nekonečných prúdov dát.
Navrhnutá reprezentácia poskytuje priamočiare použitie v rôznych úlohách spracovania
časových radov ako napríklad klasifikácia, detekcia anomálií alebo predikcia. Aplikácie
navrhnutej metódy vidíme najmä v doménach, kde sú dáta produkované vysokou
rýchlosťou a s veľkou variabilitou, kde sa kladie dôraz na tvar priebehu sledovaných
časových radov ako je to napríklad pri monitorovaní finančných dát alebo analýze
prístupov k webovým aplikáciám.
V súčasnosti pracujeme na metrikách na porovnávanie transformovaných časových
radov na úrovni jednotlivých vzorov ako aj na úrovni postupnosti symbolov. Sústreďujeme
sa na aplikáciu navrhnutej reprezentácie v rôznych úlohách analýzy prúdov dát a na
porovnanie jej vlastností s bežne používanými reprezentáciami na rôznych typoch dát.
Poďakovanie: Táto publikácia vznikla vďaka čiastočnej podpore projektov VG1/0971/11 a
APVV-0208-10.
Literatúra
1.
2.
Aggarwal, C. C.: Data streams: models and algorithms. Springer, 31 (2007)
Chen, Y., Chen, K., Nascimento, M.: Effective and efficient shape-based pattern
detection over streaming time series. In: IEEE Transactions on Knowledge and Data
Engineering (TKDE) 24(2), IEEE (2012), 265-278.
85
3.
Chen, Y., Dong, G., Han, J., Wah, B. W., Wang, J.: Multi-dimensional regression
analysis of time-series data streams. In: Proc. of the 28th international conference on
Very Large Data Bases, VLDB Endowment (2002), 323-334.
4. Ding, H., Trajcevski, G., Scheuermann, P.: Querying and mining of time series data:
experimental comparison of representations and distance measures. In: Proc. of the
VLDB Endowment, VLDB Endowment 1(2), (2008), 1542-1552.
5. Giannella, C., Han, J., Pei, J., Yan, X., Yu, P.: Mining frequent patterns in data streams
at multiple time granularities. Next Generation Data Mining, AAAI/MIT (2003), 191212.
6. Hopkins B.: (2011) Blogging From the IBM Big Data Symposium - Big Is More Than
Just Big. url: http://blogs.forrester.com/brian_hopkins/11-05-13-blogging_from_the_
ibm_big_data_symposium_big_is_more_than_just_big.
7. Keogh, E., Chakrabarti, K.: Dimensionality reduction for fast similarity search in large
time series databases. Knowledge and information Systems 3(3), Springer (2001), 263286.
8. Keogh, E., Lin, J., Fu, A.: Hot SAX: Efficiently finding the most unusual time series
subsequence. In: Fifth IEEE International Conference on Data Mining, IEEE (2005),
226-233.
9. Laney, D.: 3D data management: Controlling data volume, velocity and variety. In:
META Group Research Note, 6, (2001).
10. Lin, J., Keogh, E., Wei, L., Lonardi, S.: Experiencing SAX: a novel symbolic
representation of time series. Data Mining and Knowledge Discovery 15(2), Springer
(2007), 107-144.
11. Wang, X., Mueen, A., Ding, H., Trajcevski, G., Scheuermann, P., Keogh, E.:
Experimental comparison of representation methods and distance measures for time
series data. Data Mining and Knowledge Discovery 26(2), Springer (2012), 275-309.
Annotation:
Time series representation using repeating patterns
Over the past years multiple representations for time series were proposed. The main purpose of these
representations is dimensionality reduction and support of various algorithms in the domain of time
series data processing. Rather interesting group of time series representations are symbolic
representations allowing the employment of various algorithms from the domain of text processing.
These methods however suffer from the disadvantages associated with comparison of time series in
the presence of noise and/or shifting and scaling on temporal and amplitude dimensions. In this work,
we propose a novel symbolic representation of time series based on transformation of reoccurring
patterns into symbols. The main purpose of this representation is the dimensionality reduction on
evolving data streams while preserving the ability to cope with noise, shifting, and scaling in both
temporal and amplitude dimensions. The essential component of the proposed time series
representation are repeating time series sequences extracted using time series similarity measure
capable of dealing with noise, shifting and scaling such as using Spatial Assembling Distance
(SpADe).
Extended Column Level Temporal Indexed
Management System
Michal KVET, Karol MATIAŠKO, Monika VAJSOVÁ
1,2,3
Katedra informatiky, Fakulta riadenia a informatiky, ŽU
Univerzitná 8215/1, 010 26 Žilina
{Michal.Kvet, Karol.Matiasko}@fri.uniza.sk
Abstract. Standard relational data model is based on paradigm managing current
valid data. Historical values can be obtained only using backups and log-files.
However, these data are raw and complicated to use for operational decision making.
Therefore, concept of temporal management has been developed. Data structure for
historical and future valid data is similar to the actual data in conventional system.
However, existing solutions are based on object level temporal data, which is
inadequate in terms of performance – effectiveness of the whole system which is
manifested using the size of the whole structure and processing time to get required
data. This paper deals with the principles of transaction management and indexing in
extended column level temporal approach, describes the structure and methods for
manipulation.
Keywords: column level temporal data, valid time, transactions, indexing, time point,
changes monitoring.
1 Introduction
Database systems are one of the most important parts of the information technology, it
occupies the central position. The development of data processing has brought the need for
modelling and accessing large structures based on the simplicity, reliability and speed [13].
Thus, the main factors are correctness and efficiency of these systems. However, most
databases process and represent the current state of the data valid in this moment. Properties
and states of the objects evolve over time, become invalid and are replaced by new ones.
Once the state is changed, the corresponding data are updated in the database and it still
contains only the current valid data. Temporal data processing is very important in
dynamically evolving systems, industry, communication systems and also in systems
processing sensitive data. Simply, in systems, where it is necessary to store not only the
current state, but also the previous states and progress. It can also help us to optimize
processes and make future decisions [2] [4].
This paper deals with the temporal system based on the column level, focuses
performance, size optimization and also easy manipulation. It describes the structure,
operations and principles of the proposed solution. Moreover, this system manages also
transactions using the standard identifier of the running transactions. Experiment section
compares the performance of structural indexes (size and time to get and process data) in
the auto-commiting system. Thus, this system is extended by the transaction management.
This paper consists of the 6 sections. The section 2 defines the temporal system
principles and existing solutions and approaches. The section 3 describes the developed
system, which is transactional, which is confirmed by the section 4. Auto-committing
system delimiting the end of the transaction significantly together with the defined indexes,
88
Data Commiting in Extended Column Level Temporal Indexed System
significantly influence the performance of the system (expressed in section 5). Section 6
concludes the developed solution.
2 Temporal approach
Temporal system has been developed soon after the development of databases.
Historical data were saved using log files and archives in the recent past. Although the
historical data could be obtained, it is a complicated process because of the raw form,
which requires too much time for processing. In addition, management requires quick and
reliable access to data defined by any time point, but also getting information about the
attributes changes in the future without significant time delays.





Later, the temporal systems on the object level have been developed. Temporal databases
define a new paradigm for selecting one or more rows based on the specified criteria, for
projecting one or more columns to the output sets and for joining the tables by specifying
relationship criteria. Rows with the different values of the primary key (PK) can represent one
object at different times [1] [5] [6].
The first model in figure 1 does not use time for definition at all, it cannot provide
management for non-current data in the main structure. This is a standard model used today,
called the conventional model. The primary key is defined by the attribute ID (can be
composite). In non-timed table, each row represents an instance identified by a primary key.
The uniqueness of the primary key values without defining additional conditions ensures that
the number of rows in the table is identical with the number of managed objects. Any change
is directly reflected to the database and the old value is deleted.
The second model in figure 1 is uni-temporal system, ID is a unique identifier; PK refers to a
primary key. BD1 and ED1 is a pair of columns defining the beginning and end value of the
period – validity. The uni-temporal system always uses the composite primary key – object
identifier and time interval defining the validity state characterizing the row [3].
Another approach for managing temporal data is bi-temporal system (third model in Fig. 1). It
uses two directions of the time. The first one is the validity (BD1, ED1), the second one
represents the transaction time (BD2, ED2). This system allows storing also incorrectly
updated data or data changed (corrected) during the time period (for example for audits).
More about bi-temporal structure can be found in [8] [9].
Figure 1. Temporal models
Special type of uni-temporal system is a solution that contains only one time attribute
defining the validity. This means that any change of the corresponding object determines
the validity of the prior state. However, there can be problem with the object definition, if
one or more data attributes are undefined. The whole object must be considered as nonactual and should be distinguished from the other (actually valid) objects. Thus, the system
Full paper
89
must be extended by the definition of the validity or the object must be in that case deleted.
However, if the object is deleted, the whole temporal system is degraded.
The principles of transformation uni-temporal system defined by begin date of the
validity to the standard approach and time intervals are described in [10] [11].


Current database systems provide methods for temporal management, however, they are
focused on historical data processing. The output of the Flashback operation is the image of
the whole database at defined timepoint. The main disadvantage of this method is the
impossibility of future valid data objects processing. Moreover, temporal system requires
image of the objects during the whole time frame definition, which cannot be provided using
this functionality, respectively the process is very complicated with significant time
consumption.
Changing model to temporal is not easy problem and requires sophisticated methods. Object
level temporal data extend the primary key with the validity definition. If there is a need to
update the attribute, the whole state is modified and inserted new, thus, some attribute values
are only copied to the new state, because the values have not been changed. One of the
solutions is based on a division of the original table. One contains non-temporal attributes, it
is classical conventional table, the second one is temporal, but consists only of temporal
columns – columns, which must be monitored and changes must be stored. However, the
problem is solved only partially, there is still problem with temporal columns, which do not
change their values in the time of update. Simply, the system is not effective and stores too
many duplicities.
Solution for temporal management should be universal, not only in terms of usability in
practice, but also in terms of independence from the used database system. Creating new
structures at the core level of the database system is therefore not appropriate. The basis of
the proposed solution is to use existing resources and their combinations to create temporal
solution. Moreover, it should be possible to be adapted into existing applications without
the need of changing application programs.
3 Extended column level temporal system

Extended column level temporal system can be considered as the improvement of the column
level temporal system (described in [9] [10]) in the term of the performance and the simplicity
of the model management for the users. It is extended by the definition of the type of the
operation. If the operation is update, there is also the reference to the data type tables with
historical values. The figure 2 shows the complete structural model with dataflow.
Application is directly connected to the main tables with current valid values. It means that
currently used applications can be used without any change. Historical values are stored in the
special part of the database scheme, each temporal data type has one table defined by the
primary key (see explanation of Data_Type attribute below in this section). The whole system
is based on triggers providing the global functionality. New numerical values (mostly
identifiers) are provided by the defined sequences. Principles and system is similar to the
column level temporal system, but historical values management and temporal table is
different.
90
Figure 2. Extended column level temporal structure













Management of the temporal table is completely different. It consists of these attributes (Fig.
3, Fig. 4):
ID_change – primary key of the table.
ID_previous_change – references the last change of an object identified by ID. This
attribute can also have NULL value that means, the data have not been updated yet, so the
data were inserted for the first time in past and are still actual.
ID_tab – references the table, record of which has been processed by DML statement
(INSERT, DELETE, UPDATE, RESTORE).
ID_orig - carries the information about the identifier of the row that has been changed.
ID_column – holds the information about the changed attribute (each temporal attribute has
defined value for the referencing).
Data_type – defines the data type of the changed attribute:
 C = char / varchar
 N = numeric values (real, integer, …)
 D = date
T = timestamp
T
Create table t_tab (
h
id Integer NOT NULL primary key,
i
val Timestamp(6) NOT NULL);
s
m
odel can be also extended by the definition of the other data types like binary objects.
--historical
for value
timestamp
values.
ID_row
– referencestable
to the old
of attribute
(if the DML statement was UPDATE).
Only update statement of temporal column sets not NULL value.
Operation – determines the provided operation:
 I = insert
 D = delete
 U = update
 R = restore
The principles and usage of proposed operations are defined the in the part of this paper.
BD – the begin date of the new state validity of an object.
Full paper
91
Figure 3. Temporal table
Transaction system is based on adding new attribute for the identifying transaction
provided by the manager. Thus, temporal_table consists of the attribute ID_trans, complete
data are stored in system data tables, which can be directly referenced. The principle of
transaction modelling and processing is described in the next sections.
3.1
Insert
Trigger before insert operation stores information about this operation into
temporal_table. New value of the primary key is set using the sequence.
It is new object, therefore attribute id_previous_change (based on this object) has NULL
value. Also attributes referencing temporal attributes changes have NULL values
(id_column, id_row, data_type). Each table must have numeric value characterizing the
table containing temporal attributes.
3.2
Update
Update operation is a bit more complicated, because the root of the system granularity attribute itself, not the whole object. Thus, each updated temporal attribute is stored
separately in temporal_table and historical values are inserted into particular table based on
the data type. However, it is important to mention the main table can also consists of the
non-temporal (conventional) columns – it means that the attribute does not change its value
over the time or the changes are not important to be monitored. These data updates do not
cause the insert operation into the temporal_table.
The next code shows the series of the steps, which must be done to store the history of
the temporal attributes complexly:
 Get the value of the last change of the appropriate object. This is very important
part of the optimization, because of the time consumption.
 Store the old value of the changed attribute in the historical tables based on the
data type:





C = char / varchar -- > c_tab
N = numeric values -- > n_tab
D = date
-- > d_tab
T = timestamp
-- > t_tab
Insert the information about the update operation and references into the
temporal_table.
This operation is also the limitation of the whole system. It is necessary to know the
ratio of the changed attributes at a given time to the total number of attributes (temporal and
conventional). If all of the attributes are temporal and have the same granularity for the
changes, the uni-temporal system managing the whole object is more convenient. However,
a lot of systems used today are characterized by the different granularity. In that case, this
solution rapidly decreases the need for the disc storage and processes the changes more
easily.
92
3.3
Delete
Operation for the deleting objects can be divided into two groups. The proposed scheme
handles only the beginning of the validity. If the new valid value for the attribute,
respectively for the whole object is not available (or it is incorrect), such object must be
removed from the table, which contains only current valid objects.
However, this state is often only temporary and short-term, therefore it is not convenient to
remove the entire object due to time management. Thus, the current time value is set into
the attribute validity, which determines the last time point of the correct validity. If the
values are corrected and known later, the object state is rebuilt and the value of the validity
has the NULL value then. Of course, all of these operations are stored into the
temporal_table. Thus, we can get the complete image of the object in the system over the
time.
Another situation occurs, if the user is sure, that the object should be removed. In that case,
the whole object is moved into historical table, which has the same structure as main table
(without the validity attribute).
Based on the performance, the system defines the time interval, which determines the
maximal time, during the invalid object can be placed in the main table. After the defined
time, the object is automatically moved into the historical tables (tables for deleted objects).
Referential information is stored in temporal_table to provide whole and complex
management of the objects in time evolution.
Another operation linked with the delete operation is Restore. The aim of this operation
is to reestablish the validity of the object. If the object is in main table, it deletes the value
of the validity. However, if the object is in the table with deleted, it must be transformed
into the main table. Naturally, each change is stored in temporal_table.
3.4
States of the objects
The most important part of the developed solution is the performance based on getting
states of the objects or the whole database. This can be also considered as the critical part of
the whole system. Therefore, the special structures like indexes are developed to improve
the performance and lower time management to get required data.
Select operation can be divided into two groups. The aim of the first one is to get all
actually valid data. It means, that the system returns the data from main table (objects
without ended validity definition). However, more complicated is the second group monitoring the progress of the changes of the object attributes over the time. Using
temporal_table, the object data are reconstructed and the complete states during the defined
time interval or timepoint can be obtained. This procedure has in principle two parameters –
identifier of the object and time point determines the validity – the system provides data
from the defined time till now. Using cursor, the data about operations from temporal_table
are processed. Then, the changes are
Listing changes:
processed and written step by step from
U - 20.05.14
now to the history.
id:2,
datum:
16.07.13,
cislo:
The code in the right part shows the output
1368784703,
cislo2:
-1433307823,
retazec: ABC
of the procedure, the insert operation was
performed in 14.5.2014, the first update
U - 15.05.14
was done during the 15.5.2014, the second
id:2,
datum:
16.07.13,
cislo:
one during the 20.5.2014. Certainly, the
1598829631,
cislo2:
-1433307823,
retazec: DEF
system works on timestamp level
(microseconds), but for presentation
I - 14.05.14
purposes, it is easier to use only dates. The
id:2,
datum:
18.01.13,
cislo:
1598829631,
cislo2:
retazec: AAA
-1128911893,
Full paper
93
attributes changed during the updates, are underlined.
4 Transactions
Conventional databases usually store information that describes actually valid data
objects. When the event happens in the real world, corresponding object must be updated.
These operations are processed and executed using the transactions. Each transaction must
be designed to declare the correctness of the results. Thus, the transaction must ensure the
transformation from the consistent state to the new, consistent. Moreover, there are more
requirements placed on the transaction [13] [14]:
 Consistency – transaction must preserve all database integrity constraints. For
example, the number of students in the subject cannot exceed the capacity. Thus,
after the registration for subjects, there cannot be amount discrepancy. All these
requirements are performed by the transaction management accepting the defined
constraints. There exists four consistency levels:
 Transaction does not overwrite the data managed by another transaction.
 Transaction does not confirm changes before reaching commit.
 Transaction does not read data managed by another transaction.
 Other transactions do not read data managed by the transaction before the
commit operation.
 Atomicity – processing system guarantees, that the transaction either runs to
completion or if it is not completed, there is no effect in the database at all as if the
transaction has not been defined. Commit statement successfully determines the
transaction processing, whereas abort forces the system to rollback all the changes
provided by the transaction.
 Durability ensures that the commited data cannot be rollbacked, the system cannot
loose processed information. Thus, the effects should remain in the database even
after the collision of the system and medium damage (for example, if the student
successfully takes the exam, the result may not be lost).
 Isolation – transactions must be isolated one from another. In general, system can
process and manage several transactions in parallel. Changes are not available
before the transaction confirmation (commit). This requirement is mostly
associated with the parallel processing to ensure getting actual values.
A database transaction consists of one or more statements. Specifically, a transaction
can consist of one of the following:
 one or more data manipulation language (DML) statements,
 one data definition language (DDL) statement.
Each transaction has the beginning and the end point defined by the transaction
manager. All of the DDL statements (create, alter, drop) automatically end transaction
successfully (commit). Transaction in the system has assigned unique identifier
called a transaction_ID provided by the transaction manager. These identifiers are stored in
temporal_table for easy management and grouping operations into transactions (Fig. 4).
Moreover, the user can set the transaction name for easier manipulation using a simple and
memorable text string (SET TRANSACTION ... NAME). These names with transaction IDs
are also stored in log files and data dictionary views. Naming transactions means assigning
user defined name with system managed identifier of the transaction. Transaction identifier
is unique, whereas the name does not need to be. Transactions, which are currently defined
94
and processed in the system (have not reach the commit or rollback statements) are called
active.
Another approach is the auto-commit system, which delimits the transactions after
executing each INSERT, UPDATE, or DELETE operation, or PL/SQL block [13] [14].
Figure 4. Transaction temporal system (extended column level approach)
5 Experiments
The aim of the developed structure is to provide fast, reliable approach to the actual and
historical data objects (and also deleted objects) – data, which were valid in the past. The
optimization is based on the performance level – size of the whole structure and time to get
required data (actual state of the whole database and the object changes monitoring over the
time).
This section deals with the index performance of the global structure based on the autocommitting data option. Six indexes have been tested, which were compared to declare the
quality and usability for this system. Notice that although these indexes improve
performance of the system, inappropriately designed index structure can even significantly
decrease the solution quality. The system uses none or one developed index for
temporal_table (Fig. 3):
 Ind1:
System without indexes.
 Ind2:
ID_orig
 Ind3:
ID_orig, ID_previous_change
 Ind4:
ID_orig, BD
 Ind5:
ID_orig, ID_previous_change, BD
 Ind6:
UNIQUE ID_orig, ID_previous_change
Experiment results were provided using Oracle 11g. The parameters of used computer
are:
 Processor: Intel Core i7-3612QM, CPU @ 2.10GHz
 Operation memory: 16GB
 HDD: 1TB, 5400rpm
Complete number of each operation was 10 000 (insert, delete, update, restore).
Minimal number of operations on the object was 3, maximal number was 24, the average
value was 5,4795.
Full paper
95
Another problem is based on the transaction management of the DML operations Insert,
Delete and Update. If the parameter of the auto-commit system is set to ON value, commit
is reached after each Insert, Update, Delete operation or after PL/SQL block. It means that
the index structure is reconstructed after each operation. Based on the defined type of
experiments, slowdown of the auto – commit ON solution without indexing (without
building index structure) compared to of the auto – commit OFF solution without indexing
(reference 100%) is (Fig. 5): Insert: 143, 75%, Update: 123,84%, Delete: 114, 70%,
Restore: 110, 83%. Values in the figure 5 are in seconds.
Figure 4 shows the experiments results using auto-commit ON for DML operations –
insert, delete, update and restore in comparison with auto-commit OFF solution in graph
representation. This parameter does not influence the Select operation, therefore it is not
referenced in the figure.
Auto Auto commit OFF commit ON
Figure 4. Performance of the operations in different environments (auto-commit ON / OFF)
Insert
Update
Delete
Restore
Insert
Update
Delete
Restore
Ind1
Ind2
Ind3
Ind4
Ind5
Ind6
Ind7
Ind8
21,4353
9,2800
9,8663
9,6253
9,3143
9,5117
9,5440
9,5833
92,6447 18,6110 19,0563 18,6680 17,6667 18,7003 42,9603 42,6630
65,8047 12,7467 13,1903 12,3677 12,6237 12,4213 31,0997 31,6860
78,1120 14,0220 13,9777 14,1163 13,7153 14,2193 37,0247 37,3020
8,7940
9,2800
9,8663
9,6253
9,3143
9,5117
9,5440
9,5833
41,3880 18,6110 19,0563 18,6680 17,6667 18,7003 42,9603 42,6630
30,4940 12,7467 13,1903 12,3677 12,6237 12,4213 31,0997 31,6860
37,0503 14,0220 13,9777 14,1163 13,7153 14,3393 37,0247 37,3020
Figure 5: Performance (time to get required data)
The performance results show the quality of the Ind2 – Ind6. Data objects are selected
based on their identifier referenced as ID_orig in temporal_table. The second criterion can
be divided based on the user requirements. If the aim of the most operations are based on
time (get image of the database at defined time point), Ind2 - ID_orig, ID_previous_change
96
– is more convenient. However, if there is requirement for one object monitoring over the
time, Ind3 performs better solution. Interesting result provides index Ind3 compared to the
Ind6. Unique index definition does not provide significant change of the performance. If the
first attribute is not identifier of the object, the performance is the same as solution without
indexes, or even worse. The reason is based on temporal system, which is object oriented.
Next figure shows the performance of the auto-commit OFF system with emphasis on
DML operations (Insert, Delete, Update) and operation Restore, which rebuilds the validity
in case of managing invalidated or deleted objects.
Figure 6. Experiment results (auto-commit OFF)
6 Conclusion
Standard temporal system deals with the whole objects as the granularity, which is used,
if all temporal columns are updated at the same time. Effective managing temporal data can
be very useful for decision making, analyses, process optimization and can be used in any
area – industry, communication systems, medicine, and transport systems and so on.
However, a lot of systems manage data with the different character of the granularity.
Temporal data management used today are based on object level (one row represents the
whole state at defined time point or time interval), which often does not cover the
complexity of the data management in time validity. A significant aspect is just
performance reflected to processing time and size of the structure. Extended column level
temporal system is based on the column attribute level developed by us in the past, the
whole state is created by the grouping the properties and states of the attributes. Model
described in this paper significantly improves the usability thanks to simplifying the
structure and manipulation system.
This paper deals with the principles, characteristics and describes implementation
methods to provide the complex temporal data management. The developed system is
compared based on the performance. In the future research, the system will be extended by
the distribution and parallelism management.
Acknowledgment
This publication is the result of the project implementation:
Centre of excellence for systems and services of intelligent transport II., ITMS 26220120050
supported by the Research & Development Operational Programme funded by the ERDF.
"PODPORUJEME VÝSKUMNÉ AKTIVITY NA SLOVENSKU
Full paper
97
Projekt je spolufinancovaný zo zdrojov EÚ"
The work is also supported by the project VEGA 1/1116/11 - Adaptive data distribution.
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Date J. C.: Date on Database. Apress, 2006.
Date J. C., Darwen H., and Lorentzos A. N.: Temporal data and the relational model,
Morgan Kaufmann, 2003.
Jensen S. Ch.: Introduction to Temporal Database Research,
Web: http://infolab.usc.edu/csci599/Fall2001/paper/chapter1.pdf
Jensen S. Ch. and Snodgrass T. R.: Temporally Enhanced Database Design, MIT Press,
2000.
Hubler N. P. and Edelweiss N.: Implementing a Temporal Database on Top of a
Conventional Database. In Proceedings of Conference SCCC ’00,(2000), pp. 58 – 67.
Johnson T. and Weis R.: Managing Time in Relational Databases, Morgan Kaufmann,
2010.
Kvet M., Lieskovský A., and Matiaško K.: Temporal data modelling, In: Proceedings of
IEEE conference ICCSE 2013, 26.4. – 28.4.2013, pp. 452 – 459.
Kvet M. and Lieskovský A.: Temporal Data Management – Uni-temporal table Modelling
Update, In: Proceedings of Conference ICCGI 2013, 21.7. – 26.7.2013, pp. 146 – 161.
Kvet M. and Matiaško K.: Column level uni-temporal, Journal Communications, Vol. 16,
no. 1 (2014), pp. 97 –104
Kvet M. and Matiaško K.: Uni-temporal modelling extension at the object vs. attribute
level, In: Proceeding of UKSim-AMSS 7th European modelling symposium, Manchester,
20.11. – 22.11.2013, pp. 6 – 11
Kvet M., Matiaško K., Kvet M.: Transaction Management in Fully Temporal System, In:
Proceedings of UKSim-AMSS 16th international conference on computer modelling and
simulation, Cambridge, 26.3.– 28.3.2014, pp. 147 – 152
Lewis P., Bernstein A., and Kifer M.: Databases and Transaction Processing (An
Application Oriented Approach), Addison-Wesley, 2002
Matiaško M., Vajsová M., Zábovský M., and Chochlík M.: Database systems, EDIS, 2008
Ozsu M. and Valduriez P.: Principles of Distributed Database Systems, Springer, 2011
Úvod do vizualizácie softvéru
Kristián ŠESTÁK, Zdeněk HAVLICE
Technická univerzita v Košiciach, Fakulta elektrotechniky a informatiky, Katedra počítačov
a informatiky, Letná 9, 042 00 Košice, Slovenská republika
[email protected]
[email protected]
Abstrakt. Príspevok sa zaoberá problematikou vizualizácie softvéru, modelovania
softvérového systému, popisuje základné princípy a funkcie z tejto oblasti. Analyzuje
niekoľko nástrojov pre vizualizáciu softvérového modelu, taktiež ponuka nové
riešenia.
Klíčová slova: vizualizácia, softvérový model, 2D, 3D, virtuálna realita
1 Úvod
Vývoj softvérových systémov je náročná úloha, ktorá zahŕňa množinu súvisiacich fáz, tieto
fázy vytvárajú životný cyklus softvéru. Počas všetkých týchto fáz, softvéroví inžinieri
potrebujú pomocou rôznych metód, nástrojov, metodík a metodológií pre pochopenie a
zvládnutie zložitosti, rozsahu a komplexnosti softvérových systémov a požiadaviek na tieto
systémy. V tejto súvislosti môže použitie interaktívnej grafickej reprezentácie dát
modelovaného systému významne pomôcť k analýze a pochopeniu týchto zložitých
informácii.
Správna definícia požiadaviek na softvérový systém má veľký vplyv na zvyšok
vývojového procesu. Splnenie používateľských požiadaviek na softvérový systém je
hlavnou výzvou pre softvérových inžinierov. Skúsenosti na mnohých veľkých projektoch
ukazujú, že veľmi veľké percento chýb bolo v dôsledku nepresnosti v skorších fázach
procesu vývoja softvéru [5].
Efektívne grafické znázornenie môže bližšie poskytnúť vhodnejší model pre
používateľa, ako je textová reprezentácia. Skúsenosti v softvérovom inžinierstve a v oblasti
vizualizácie, potvrdzujú, že vizuálna reprezentácia softvérového systému môže zvýšiť jeho
pochopiteľnosť a znížiť náklady na vývoj [28].
2 Vizualizácia
Vizualizáciu možno definovať nasledovne: vizualizácia je ...„počítačom podporovaná,
interaktívna, vizuálna reprezentácia dát k rozšíreniu poznania“, kde poznanie je
nadobudnutie, alebo využitie znalosti. Tieto grafické reprezentácie môžu sprostredkovať
jasné myšlienky, presnosť a efektívnosť [31, 16].
V skutočnosti, ľudský vizuálny systém (t.j. oko a vizuálny kortex) predstavuje efektívny
paralelný procesor, ktorý maximálne podporuje komunikačný kanál do ľudských
kognitívnych centier [6]. Navyše vizuálny systém uvoľní kognitívne kapacity a presúva tam
100
Základné princípy vizualizácie softvéru
časť spracovania [32]. Napríklad, v dôsledku vizualizácie vedci zmenili spôsob myslenia,
tvrdia, že nie je možné robiť vedecký výskum bez vizualizácie [26] (pozri Obr.1).
Vizualizácia dát je disciplína, ktorá študuje princípy a metódy pre vizualizáciu kolekcie
dát s cieľom získať prehľad o dátach. To sa odráža v jednej z najviac dnes akceptovaných
definícii vizualizácie „Vizualizácia je proces transformácie informácie do vizuálnej formy,
ktorá umožňuje používateľovi sledovať informáciu. Výsledné vizuálné zobrazenie umožňuje
pre vedca, alebo inžiniera vnímať vizuálne prvky, ktoré sú skryté v dátach, ale napriek tomu
sú potrebne pre prieskum a analýzu dát“ [17].
Obr. 1 Proces vizualizácie - interaktívny, počítačom podporovaný [1].
3 Vizualizácia softvéru
Vizualizácia softvéru (VS) je široká výskumná oblasť, ktorá zahŕňa veľké množstvo
pojmov a techník [22]. Oblasť VS (pozri Obr. 2) je zameraná na vizuálnu reprezentáciu
s cieľom vytvárať softvér viac pochopiteľný. Jedna sa o špecializovanú vetvu vizualizácie
informácie, ktorá zobrazuje artefakty súvisiace so softvérom a jeho vývojovým procesom
[33].
Porozumenie, pochopenie softvéru je proces prijatia zdrojového kódu a jeho pochopenie
[10]. Je to proces získavania a pochopenia softvéru, ako systému funkcií [30].
Obr. 2 Vennov diagram ukazuje vzťahy medzi rôznymi oblasťami softvérovej vizualizácie
[3].
101
Porozumenie softvéru sa odlišuje od porozumenia programu tým, že porozumenie
softvéru zahŕňa dokumentáciu, zatiaľ čo porozumenie programu sa vzťahuje iba na
zdrojový kód.
Vizuálné programovanie môžeme definovať, ako: „Akýkoľvek systém ktorý umožňuje
používateľovi zadať program v dvoch, alebo viacerých dimenziách“, ale výslovne vylúčime
textové jazyky (považujeme ich za jednorozmerné) a obrazovo definované jazyky [4].
Iná definícia vizuálneho programovania: „použitie techník vizualizácie pre špecifikáciu
programu.“ [6].
Programová vizualizácia sa od vizualizácie programu odlišuje a to tak, že programová
vizualizácia je: „program sa špecifikuje konvenčným, textovým spôsobom, a grafika je
použitá na ilustráciu niektorých aspektov programu“ [18].
Techniky pre porozumenie softvéru môžu byť klasifikovane buď ako:
 Statické
 Dynamické
Mnohé z existujúcich vizualizácií softvérových systémov sa sústreďujú na animáciu
programu, alebo algoritmu a vizualizáciu založenú na grafoch, statických a dynamických
vzťahoch medzi softvérovými komponentmi [25].
Všeobecne platí, že VS by mala determinovať úroveň abstrakcie informácie, ktorá
vypovedá o softvérovom systéme. Mal by sa používať vizuálny jazyk, alebo
pretransformovať zdrojový kód do vizuálnej reprezentácie [25].
Sémantika jazyka by mala byť jednoznačná, prirodzená a naučiteľná používateľom.
Výber mapovania závisí od typu informácií, ktoré reprezentujú a média použitom
v reprezentácii. Používateľské úlohy, ktoré systém podporuje, vrátané úloh programu
s porozumením, by mali byť špecifikované [25].
3.1
Vizualizácia softvéru v 3D priestore
Vizualizácia softvéru v 2D priestore bola rozsiahlo študovaná, boli navrhnute mnohé
techniky pre reprezentáciu softvérových systémov [21, 11]. 2D techniky VS zvyčajne
zahŕňajú reprezentáciu grafu, alebo stromu a skladajú sa z veľkého počtu uzlov a oblúkov
[19].
Komplexný softvérový systém môže zahŕňať tisíce takých uzlov a oblúkov. Aby
konceptualizácia a porozumenie boli jednoduché pre používateľa, vizualizácia takýchto
systémov reprezentuje časti grafov v rôznych pohľadoch, alebo v rôznych oknách tak, že
používateľ sa môže zamerať na tú úroveň detailov, ktorú chce. Softvérový systém sa preto
reprezentuje vo viacerých oknách, ktoré predstavujú pre pozorovateľa rôzne charakteristiky
posudzovaného systému. A tak 2D vizualizácie môžu viest k neprehľadným množstvám
informácií na zobrazenej ploche.
Zobrazenie dát v troch dimenziách miesto dvoch, môže uľahčiť používateľom
porozumieť dátam. A tiež, chybovosť pri určovaní trasy v 3D grafoch je oveľa menšia ako
v 2D [34, 35].
Niektorí autori uvádzajú, že dva rozmery sú dostatočné na zobrazenie informácie, a že
nie je žiaduce pridávať tretí rozmer. Tato extra dimenzia by mala byť použitá len pre
vizualizáciu dátovej množiny, ktorá je sémanticky bohatšia. Avšak, iní autori si myslia, že
3D prezentácie uľahčujú vnímanie ľudského vizuálneho systému [23]. Domnievajú sa, že
zavedenie esteticky príťažlivých prvkov 3D grafiky a animácie, môže výrazne zvýšiť
intuitívnosť a pamätanie informácie [29].
A čo robí vizualizáciu softvéru „dobrou“? Zoznam niektorých žiadúcich vlastnosti pre
vizualizáciu [36]:
102







Jednoduchá navigácia s minimálnou možnosťou dezorientácie: vizualizácia by mala
byť štruktúrovaná a mala by obsahovať funkcie na pomoc používateľovi pri
navigácii.
Vysoký informačný obsah: Vizualizácia by mala predložiť čo najviac možných
informácií, bez premáhania používateľa.
Dobre využitie interakcie: Interakcia poskytuje mechanizmy pre získavanie viac
informácií a udržanie pozornosti.
Nízka zložitosť vizualizácie, dobre štruktúrovaná: Dobre štruktúrované informácie
by mali viest k jednoduchšej navigácii. Nižšia zložitosť sa vymení s vysokým
informačným obsahom.
Rôzne úrovne detailov: Zrnitosť, abstrakcia, informačný obsah a druh informácie by
mali vyhovovať záujmom používateľov.
Dobre využitie vizuálnych metafor: Metafory poskytujú prostriedky k pochopeniu.
Boli vyčlenene dve kritéria pre hodnotenie mapovania dát na vizuálne metafory:
expresivita a účinnosť.
Odolnosť zmeny: Malé zmeny obsahu, alebo zmeny v pozornosti by nemali
spôsobovať veľké rozdiely vo vizualizácií.
4 Realizácia vizualizácie softvéru
Náš výskum bol zameraný na možnosti, ktoré ponúkajú viac rozmerné vizualizácie (dva
a viac rozmerov) pre statický a dynamický popis softvérového systému.
Najprv sme sa rozhodli použiť rozšírenie UML diagramov v troj-rozmernom (3D)
systéme. Tu existuje niekoľko hlavných dôvodov:
 Na UML sa môžeme pozerať, ako na štandard, UML má širokú akceptáciu
v softvérovom inžinierstve.
 UML nemá limity pre použitie 3D diagramov, stereotypy umožňujú vytvorenie
nových vizualizácií modelu, ktorý môže dať lepší význam než je to u štandardného
typu.
Pre implementáciu 3D UML diagramov sme použili gef3d – aplikačný rámec
(Graphical Editing Framework) (pozri Obr.3) [20]. Táto implementácia je 3D editovateľný
aplikačný rámec (framework), ktorý je založený na široko používanom dvoj-rozmernom
(2D) grafickom gef2d.
Obr. 3 Pohľad na systém gef3d.
Pre zistenie možných výhod použitia aplikačného rámca gef3d sme ho porovnali
s gef2d. Testovacia skupina pozostávala z piatich programátorov. Cieľom bolo porovnať
gef3d a gef2d aplikačné rámce na základe týchto kritérií:
103
 čas potrebný pre porozumenie softvérového modelu,
 čas potrebný pre implementáciu softvérového modelu,
 chybovosť výslednej implementácie softvérového modelu.
Celý proces pozostával z týchto krokov:
1. Bolo vytvorených 5 softvérových modelov v gef2d a 5 softvérových modelov
v gef3d.
2. Softvérové modely v gef2d a v gef3d boli podobné, nie však rovnaké.
3. Programátor náhodne vyberal softvérový model v gef2d alebo v gef3d.
4. Meral sa čas od doby, kedy programátor získal model, až do doby, kedy model začal
implementovať.
5. Meral sa čas od začiatku implementácie až do finálneho stavu.
6. Zistila sa miera chybovosti v implementácií v percentách.
Na základe analýzy dát z výskumu sme prišli k nasledujúcemu záveru:
 Nedá sa jednoznačne povedať, že gef3d poskytuje kratší, alebo dlhší čas pre
pochopenie a následnú implementáciu softvérového modelu.
 Výskyt chybovosti v pochopení a v implementácií modelov bola nulová, treba však
poznamenať, že každý z testovaných modelov bol na jednoduchej úrovni.
Ďalej, čo sa týka samotného aplikačného rámca, riešenie gef3d je pomerne jednoduché,
implementácia je relatívne rýchla. Vizuálné prostredie a manipulácia je dostatočná
vzhľadom na ponúkane možnosti. Slabou stránkou tohto riešenia je, že neposkytuje
plnohodnotný 3D systém, ale len jednotlivé na seba poukladané 2D vrstvy a z analýzy
vyplýva, že je to jedna z možných príčin nepreukázanej výhodnosti použitia gef3d oproti
gef2d.
Pre popis dynamických častí softvérového systému sme sa rozhodli použiť prostredie
Second Life (pozri Obr.4), vyvíjaný firmou Linden Lab. Ide o 3D prostredie virtuálnej
reality (VR), ktoré rozširuje softvérový model o niekoľko ďalších rozmerov. Takto by sa
pomocou vhodného návrhu a implementácie malo dosiahnuť rýchlejšie pochopenie
softvérového modelu a samotného softvérového systému.
Obr. 4 Virtuálny svet v SecondLife.
Prostredie systému Second Life je plnohodnotným systémom VR. Poskytuje nástroje
pre vytváranie virtuálnych svetov. Avšak, tieto nástroje patria medzi slabé stránky tohto
systému. Zmeny polohy, rozmerov a správania geometrických objektov sa vykonávajú
pomocou skriptovacieho jazyka LSL (Linden Scripting Language) to znamená, že pre
automatizovanú aplikáciu, ktorej výstupom by boli špecifické dáta popisujúce štruktúry a
správanie virtuálneho sveta je potrebný prekladač práve do tohto skriptovacieho jazyka.
104
4.1
Návrh riešenia
V 2D systéme s použitím geometrie pre popis vlastností objektov a ich vzájomných
vzťahov máme dva rozmery v
- ovej súradnicovej sústave. Ak chceme popísať ďalšie
z nášho hľadiska dôležite vlastnosti objektov, môžeme rozšíriť daný 2D model o ďalšie
rozmery (atribúty), ako sú napríklad farby objektov, texty rozširujúce vlastnosti objektov,
alebo použitie iných tvarov z ktorých sa skladajú objekty. Získanie ďalších rozmerov, ktoré
reprezentujú dôležite informácie sa dajú relatívne ľahko vytvárať. Avšak, môžu nastať tieto
problémy:
 Model môže byť neprehľadný, náročný na pochopenie.
 Model nemusí byť intuitívny, je potrebne sa učiť dodatočné informácie.
 Vzniká väčšia chybovosť pri pochopení modelu.
Z pohľadu geometrie rozšírením 2D modelu o tretí rozmer síce získame jeden rozmer
naviac. Ale, vhodným návrhom je možné získať viac použiteľných atribútov (pozri Obr. 5).
Majme geometrický objekt (kváder) a nech má tieto vlastnosti:
1. Geometrický objekt (kváder) je v systéme definovaný svojou polohou v
–
ovej súradnicovej sústave.
2. Výška geometrického objektu → dĺžka strany .
3. Šírka geometrického objektu → dĺžka strany .
4. Dĺžka geometrického objektu → dĺžka strany .
Obr. 5 Geometrický objekt – kváder.
Takto sme získali 4 atribúty, ktoré reprezentujú vlastnosti objektu. Tu je ale potrebné
zvážiť, koľko rozmerov je ešte prínosom a koľko už nie, inak povedané, kvantita
vizualizovaných informácií nemusí vždy znamenať kvalitu. Model sa môže stať
neprehliadaným a ťažko pochopiteľným.
Majme neprázdnu databázu ktorá má n tabuliek a m relácií, kde n >1, m >0. A
definujme systém G nasledovne: Nech systém G pozostáva z množiny geometrických
objektov a ich vzájomných relácií. Definujme geometrický objekt typu C – valec (pozri
Obr.6),
a nech poloha C je definovaná v súradnicovom systéme (x, y, z) a nech C má
nasledujúce vlastnosti:
 Výška objektu – reprezentuje počet riadkov v tabuľke.
 Priemer objektu – reprezentuje počet stĺpcov v tabuľke
105
Obr. 6 Geometrický objekt – význam.
Ďalej definujme geometrický objekt typu L - úsečka, L
a bude reprezentovať
vzájomné relácie medzi objektmi typu C (pozri Obr.7) a nech má tieto vlastnosti:
 Cudzí kľuč - reprezentuje kružnica na povrchu objektu typu C.
 Relácia – reprezentuje úsečka.
Každý objekt typu L a typu C má jednoznačne definovanú polohu v systéme G.
Obr. 7 Relácie medzi tabuľkami - cudzí kľúč.
Obr. 8 Pohľad na 3D model s vyznačenými súradnicami.
Definujme transformáciu T takto:
 Počet riadkov databázovej tabuľky → výška geometrického objektu C.
 Počet stĺpcov databázovej tabuľky → priemer geometrického objektu C.
 Početnosť dotazov na databázovú tabuľku → poloha geometrického objektu C.
 Relácia medzi databázovými tabuľkami → poloha geometrického objektu L.
Nami predstavený návrh riešenia vizualizácie vo viac, ako dvoch rozmeroch ponúka
nasledujúce možnosti: (pozri Obr. 8)
 Je viac intuitívny, ako klasický 2D model – pre ľudské oko sú informácie
prichádzajúce z 3D prirodzenejšie.
 Na základe vizualizácie objektov ich polôh, vzájomných relácií je možné odhaliť
nedostatky modelu za behu systému.
106
5 Záver
Cieľom vizualizácie softvéru je vytvoriť „obrazy“, ktoré evokujú pre používateľa lepšie
pochopenie softvéru [12]. Vizualizácia softvéru sa javí ako veľmi sľubné na riešenie
zložitosti a evolučných výziev v softvérovom priemysle [34]. 3D vizualizácia bola
preskúmaná vo všetkých oblastiach, kde sa používa 2D vizualizácia, vrátané vizualizácie
založenej na metrikách objektovo orientovaných programov a vizualizácie na sledovanie
chýb softvéru, izolovaných problémov, a monitorovanie priebehu vývoja [8, 9, 24]. 3D
UML boli tiež preskúmané [19, 13].
Mapovanie veľkého množstva dynamických informácií na 3D reprezentáciu je viac
výhodná a to bez ohľadu na typ použitých symbolov (reálnych alebo virtuálnych) [14].
Praktická softvérová vizualizácia musí poskytnúť nástroje pre vyber a zobrazenie len
takých informácií, ktoré sú pre vizualizáciu dôležité. Musí poskytovať kvalitne vizuálne
zobrazenie, ktoré je intuitívne a ma vysokú formu abstrakcie, a vyhýba sa preťaženiu
informácií [25].
Hoci otázka výhod ktoré ponúkajú 3D oproti 2D stále zostava otvorená, oblasť
výskumu ktorý vyšetruje použitie 3D grafiky na VS má optimistické výsledky [7, 2, 19].
Literatura
1.
Alfredo R. Teyseyre, Marcelo R. Campo, "An Overview of 3D Software
Visualization," IEEE Transactions on Visualization and Computer Graphics, pp. 87105, January/February, 2009, (Angl.)
2. A. Marcus, L. Feng, and J.I. Maletic, “3D Representations for Software Visualization,”
Proc. ACM Symp. Software Visualization (SoftVis ’03), p. 27-ff, 2003., (Angl.)
3. B.A. Price, R.M. Baecker, and I.S. Small. A principled taxonomy of software
visualization. Journal of Visual Languages and Computing, 4:211–266, 1993., (Angl.)
4. B.A. Myers. Taxonomies of visual programming and program visualization. Journal of
Visual Languages and Computing, 1:97–123, March 1990., (Angl.)
5. Ben Potter, Jane Sinclair, and David Till. An Introduction to Formal Speciﬁcation and
Z. Prentice Hall, New York, 1991. , (Angl.)
6. C. Ware, Information Visualization: Perception for Design. Morgan KaufmannElsevier, 2004. , (Angl.)
7. C. Knight, “System and Software Visualisation,” Handbook of Software Eng. and
Knowledge Eng. World Scientific, 2000. , (Angl.)
8. Chuah MC, Eick SG (1997) Glyphs for software visualization. In: Proceedings of the
5th iternational workshop on program comprehension (IWPC’97), pp 183–191, (Angl.)
9. Chuah MC, Eick SG (1998) Information rich glyphs for software management data.
IEEE Comput Graph Appl 18(4):24–29, (Angl.)
10. Deimel, L., Naveda, J., Reading Computer Programs: Instructor’s Guide and Exercises,
Technical Report CMU/SEI-90-EM-3, Software Engineering Institute, Carnegie
Mellon University, 1990, (Angl.)
11. Diehl, S., ed., Revised Lectures on Software Visualization, Int’l Seminar. Springer,
2002., (Angl.)
12. Diehl, S., Software Visualization: Visualizing the Structure, Behaviour, and Evolution
of Software. Springer, 2007., (Angl.)
107
13. D. Gracanin, K. Matkovic, and M. Eltoweissy, “Software visualization,” Innovations in
Systems and Software Engineering, A NASA Journal, vol. 1, no. 2, pp. 221–230, Sep.
2005. , (Angl.)
14. Dos Santos, C. R., Gros, P., Abel, P., Loisel, D., Trichaud, N., and Paris, J. P.,
"Mapping Information onto 3D Virtual Worlds", in Proceedings of IEEE International
Conference on Information Visualization, London, England, July 19-21 2000.
15. DwyerT (2001) Three dimensional UMLusing force directed layout. In: Proceedings of
the Australian symposium on information visualisation 2001, Sydney, Australia, pp
77–85, (Angl.)
16. E. R. Tufte, Visual Explanations: Images and Quantities, Evidence and Narrative.
Cheshire, CT, USA: Graphics Press, 1997., (Angl.)
17. GERSHON, N. Information visualization: The next frontier. In SIGGRAPH’94:
Proceedings of International Conference and Exibition on Computer Graphics and
Interactive Techniques (1994), pp. 485–486., (Angl.)
18. Grant, C., Software visualization in Prolog, University of Cambridge, Computer
Laboratory, dec 1999, (Angl.)
19. G. Parker, G. Franck, and C. Ware, “Visualization of Large Nested Graphs in 3D:
Navigation and Interaction,” J. Visual Languages and Computing, vol. 9, no. 3, pp.
299-317, 1998., (Angl.)
20. J. von Pilgrim, K. Duske, Gef3D: a framework for two-, two-and-a-half-, and threedimensional graphical editors, SoftVis '08 Proceedings of the 4th ACM symposium on
Software visualization, Pages 95-104, (Angl.)
21. J.T. Stasko, M.H. Brown, and B.A. Price, eds., Software Visualization: Programming
as a Multimedia Experience. MIT Press, 1997., (Angl.)
22. Qais Ali, Supervisor Prof. Dr, P. Klint, Static Program Visualization Within The
ASF+SDF Meta Environment Master Software Engineering, Centrum Voor Wiskunde
En Informatica, University of Amsterdam, Amsterdam, Holland, September, 2008,
(Angl.)
23. I. Spence, “Visual Psychophysics of Simple Graphical Elements,” J. Experimental
Psychology: Human Perception and Performance, vol. 4, no. 16, pp. 683-692, 1990.,
(Angl.)
24. Lewerentz C, Simon F (2002) Metrics-based 3D visualization of large object-oriented
programs. In: Proceedings of the 1st international workshop on visualizing software for
understanding and analysis (VISSOFT’02), Paris, pp 70–77, (Angl.)
25. Maletic, J. I., Leigh, J., Marcus, A., and Dunlap, G.: Visualizing Object-Oriented
Software in Virtual Reality, Division of Computer Science, The Department of
Mathematical Sciences, The University of Memphis and Electronic Visualization
Laboratory, University of Illinois at Chicago, 2001, (Angl.)
26. M.B. McGrath and J.R. Brown, “Visual Learning for Science and Eng.,” IEEE
Computer Graphics and Applications, vol. 25, no. 5, pp. 56-63, Sept./Oct. 2005.
27. Pacione, J., M.,: A Novel Software Visualisation Model to Support Object-Oriented
Program Comprehension, University of Strathclyde, Glasgow, 2005, (Angl.)
28. R. Mili and R. Steiner, “Software engineering - introduction,” in Revised Lectures on
Software Visualization, International Seminar. London, UK: Springer-Verlag, 2002,
pp. 129–137., (Angl.)
108
29. R. Brath, M. Peters, and R. Senior, “Visualization for Communication: The Importance
of Aesthetic Sizzle,” Proc. Ninth Int’l Conf. Information Visualisation (IV ’05), pp.
724-729, 2005., (Angl.)
30. Russell Wood, Assisted Software Comprehension, Final report, June 2003, (Angl.)
31. S. Card, J. MacKinlay, and B. Shneiderman, Eds., Readings in Information
Visualization: Using Vision to Think. Morgan Kaufmann Publishers, 1998., (Angl.)
32. Van Ham F (2003) Using multilevel call matrices in large software projects. In:
Proceedings of the 2003 IEEE symposium on information visualization (INFOVIS’03),
pp 227–232, (Angl.)
33. Voinea, S., L., Software Evolution Visualization, 2007, ISBN 978-90-386-1099-3,
(Angl.)
34. Ware, C. and Franck, G., "Representing Nodes and Arcs in 3D Networks", in
Proceedings of IEEE Conference on Visual Languages, St. Louis, October 1994, pp.
189- 190. (Angl.)
35. Ware, C., Hui, D., and Franck, G., "Visualizing Object Oriented Software in Three
Dimensions", in Proceedings of CASCON'93, Toronto, Ontario, Canada, October
1993, pp. 612-620. (Angl.)
36. Young, P., and Munro, M. (2003) Visualising software in virtual reality. IEEE First
International Workshop on Visualizing Software for Understanding and Analysis.
IEEE Computer Society Press. (Angl.)
An Introduction to Software Visualization.
Postery
Webové služby v procese vyhodnocovania
študentských zadaní
Miroslav BIŇAS
Katedra počítačov a informatiky, FEI TU v Košiciach
Letná 9, 042 01 Košice
[email protected]
Abstrakt. S výučbou programovania úzko súvisí aj hodnotenie študentmi napísaných
programov. Proces hodnotenia vie byť veľmi zdĺhavá a náročná činnosť, ale
s použitím vhodných nástrojov je možné v relatívne krátkom čase overiť riešenia
veľkého počtu študentov so zachovaním objektívnosti hodnotiaceho procesu. Tento
článok sa venuje práve automatizácii tohto procesu s využitím architektúry SOA.
Kľúčové slová: testovanie, automatizácia, SOA, webové služby, vzdelávanie
1
Úvod
Väčšinu predmetov a kurzov, ktoré je možné na univerzitách absolvovať, je potrebné
ukončiť vypracovaním aspoň jedného projektu, v ktorom študenti preukážu nadobudnuté
znalosti a schopnosti v predmetnej oblasti. V závislosti od požiadaviek sa môže jednať o
jeden záverečný alebo o sadu menších projektov odovzdávaných priebežne.
Proces hodnotenia týchto projektov predstavuje veľmi dôležitú súčasť celkového
hodnotenia. Pre učiteľov sa jedná o proces, ktorý môže byť v závislosti od typu projektu
značne časovo náročný. Očakáva sa od nich, že ich výsledné hodnotenie bude vzhľadom na
stanovené požiadavky objektívne. Pokiaľ však nie je jasne stanovené, koľkými bodmi je
možné ohodnotiť jednotlivé časti projektu, je ťažké vidieť rozdiel medzi projektom, ktorý
bol ohodnotený počtom bodov N a projektom, ktorý bol ohodnotený počtom bodov N+1.
Študenti by zasa chceli poznať hodnotenie svojho projektu čo najskôr a v prípade, že
nedosiahli plný počet bodov, by chceli jasne poznať dôvody, prečo je tomu tak, aby mohli
zistené nedostatky opraviť.
V súvislosti s procesom odovzdávania a hlavne hodnotenia záverečných projektov, je
možné vyzdvihnúť dôležitosť nasledovných kritérií: rýchlosť hodnotiaceho procesu,
objektívnosť hodnotenia a znovupoužiteľnosť nástrojov použitých pri hodnotení.
V tomto článku sa budem venovať práve automatizovanému hodnoteniu
programátorských predmetov a teda projektov, ktorých výstupom je program. Niektoré
opisované riešenia (služby) je však možné použiť aj na iné typy projektov. To však závisí
od čitateľa, ako vie uvedené závery aplikovať aj pre iné domény.
V článku sú opísané skúsenosti s reálnym nasadením webových služieb do procesu
odovzdávania a vyhodnocovania programátorských zadaní na Technickej univerzite
v Košiciach v predmete prvého ročníka s názvom Programovanie. Jednotlivé služby, ktoré
sa podieľajú v tomto procese, budú opísané podrobnejšie v ďalšom texte. Rovnako tak
budú predstavené prípady použitia, ktoré sme v rámci predmetu úspešne realizovali.
Tento článok môže byť inšpiráciou pre tých, ktorí by chceli ušetriť čas a zobjektívniť
proces vyhodnocovania študentských zadaní jeho automatizovaním.
112
2
Súčasný stav v predmetnej oblasti a existujúce riešenia
Potreba automatizovaných nástrojov súvisí hlavne s množstvom študentov, ktorí konkrétny
predmet absolvujú [9]. Toto množstvo je tým väčšie, čím je nižší ročník štúdia. Nastáva
teda situácia, kedy vzhľadom na množstvo študentov (rádovo stovky) a obmedzený počet
učiteľov (rádovo jednotky) sa stáva kontrola a hodnotenie zadaní ťažko zvládnuteľná.
Automatizované hodnotenie dokáže v takejto situácii priniesť výhody pre obe strany – ako
pre študentov tak aj pre učiteľov. To, že sa jedná o reálny problém, dokumentuje aj
niekoľko prieskumov existujúcich nástrojov v predmetnej oblasti, ako napr. [1] alebo [5].
Problém, ktorý v tejto oblasti pretrváva, bol opísaný v prieskume [11]. Aj keď sa jedná
o starší prieskum z roku 2004, analyzoval príspevky z tejto oblasti v období od 1983 do
2003. Spolu bolo analyzovaných 444 príspevkov. Výsledok prieskumu uvádza, že len malé
množstvo prezentovaných nástrojov bolo použitých a ďalej používaných mimo ich
domovskú inštitúciu. Tieto závery rovnako potvrdzuje aj novší prieskum [5].
Tento záver je zrejmý – dôvody pre vývoj nástrojov súvisia s potrebou riešenia
lokálneho problému danej inštitúcie alebo konkrétneho kurzu. Výsledkom projektu je
obyčajne prototyp, ktorému chýba podpora po ukončení projektu. A aj keď sú tieto nástroje
následne uvoľnené a voľne dostupné, ich úprava a adaptovanie pre potreby inej inštitúcie sú
obyčajne náročné.
Samozrejme existujú aj projekty, ktoré sa uchytili a medzi tie úspešné je možné zaradiť
napr. interaktívne prostredie BlueJ [7] pre výučbu objektového programovania, rodinu
mikrosvetov založenú na robotovi Karlovi [8], poloautomatický hodnotiaci systém BOSS
[6] alebo automatický hodnotiaci systém CourseMarker [3].
Podobne je tomu aj v našich nie len univerzitných, ale slovenských podmienkach, kde
prevládajú systémy „šité“ na mieru pre konkrétny kurz. Často sa dá tiež stretnúť
s CMS/LMS systémami, ktoré sa zúčastňujú procesu odovzdávania a zberu zadaní, ale nie
vyhodnocovania. V tomto prípade zrejme dominuje používanie otvoreného LMS Moodle,
ktorý síce umožňuje zber zadaní, ale nepodporuje napr. ich revízie. Rovnako tak
neumožňuje automatizáciu ich hodnotenia. Moodle síce obsahuje niekoľko modulov tretích
strán, ktoré integrujú podporu napr. pre kontrolu plagiátov a niekoľko modulov, ktoré
dokážu riešiť niektoré typy programátorských úloh, ale celkovo sa nejedná o vhodný
systém pre kurzy orientované na programovanie.
Istým príkladom, ako by mohlo vyhodnocovanie programátorských úloh vyzerať,
ponúkajú súčasné MOOC systémy, ako edx.org, Coursera, Udacity a ďalšie. V našich
podmienkach sa vývoju podobného nástroja pre oblasť programovania venujú na pôde FIIT
STU v Bratislave. Projekt má názov Peoplia [10], ale rovnako sa jedná o uzavretý systém a
v súčasnosti je zrejme ešte stále vo vývoji.
Do prostredia LMS Moodle by však bolo možné napríklad integrovať techniku
hodnotenia niektorých MOOC kurzov, kde riešenia študentov hodnotia iní študenti
(v podstate - spolužiaci). Takýto systém hodnotenia však nie je objektívny, pretože študenti
sa môžu na výslednom hodnotení vzájomne dohodnúť.
3
SOA v procese zberu a hodnotenia
Uvedené „úspešné“ systémy pre čiastočnú alebo plnú automatizáciu hodnotenia BOSS [6] a
CourseMarker [3] (a nie len tieto) sú založené na architektúre klient-server. V súčasnosti sa
dá stretnúť najmä v oblasti enterprise riešení so servisne orientovanou architektúrou (SOA).
Hlavným prvkom takejto architektúry sú služby, ktoré poskytujú potrebnú funkcionalitu.
The OpenGROUP na svojich stránkach (www.opengroup.org) charakterizuje službu ako:

samostatná a nezávislá,

môže byť zložená z ďalších služieb,
Poster
113

pre koncového klienta sa javí ako „čierna skrinka“,

poskytuje minimálne jednu funkcionalitu (činnosť).
Založiť proces zberu a hodnotenia zadaní na architektúre SOA by teda znamenalo
identifikovať jednotlivé samostatné a nezávislé služby, ktoré sa na tomto procese podieľajú,
implementovať ich a vzájomne prepojiť s cieľom dosiahnutia potrebného výsledku.
Príkladom existujúceho riešenia problému automatizovanej kontroly študentských
zadaní založeného na architektúre SOA, je možné považovať prácu M. Amelunga [2]. Na
svojej univerzite sa venoval práci na sade nástrojov s názvom eduComponents, ktoré
poskytujú e-learningové rozhranie pre CMS systém Plone. Jednotlivé komponenty sú však
vzájomne tesne previazané, čo bráni ich samostatnému použitiu ako samostatných služieb.
V nasledujúcom texte bude predstavených niekoľko prípadov použitia, ako je možné
využiť architektúru SOA v procese zberu a hodnotenia študentských programátorských
zadaní. Rovnako tak budú identifikované jednotlivé webové služby podieľajúce sa na tomto
procese tak, ako sme ich identifikovali na viacerých kurzoch ponúkaných na Technickej
univerzite v Košiciach.
Väčšina služieb bola vytvorená v jazyku Python pomocou mikro webového rámca
Flask1. Iná technológia bola použitá len v prípade systému použitého na skúške, ktorý bol
vytvorený v jazyku PHP pomocou webového rámca CodeIgniter2. Na komunikáciu medzi
jednotlivými službami bol použitý formát JSON.
1
Prípad použitia 1 – Hodnotenie na požiadanie
Schéma prvého prípadu nasadenia je znázornená na obrázku 1. V tomto prípade dochádzalo
k hodnoteniu zadania priamo po jeho odoslaní.
Študenti odovzdávali svoje zadania prostredníctvom systému na správu verzií Git,
pričom pre naše potreby používame rozhranie s názvom GitLab3. Aby bolo možné
hodnotenie spustiť priamo po operácii push, vytvorili sme obslužný skript a naviazali ho
na udalosť (hook) post-receive [4]. Ten následne projekt zabalil do zip archívu a ten
poslal na overenie službe Structure Checker. Pokiaľ kontrola prebehla v poriadku, archív
bol následne poslaný službe Arena, ktorá vykoná statickú a dynamickú analýzu kódu v
študentskom projekte. Výsledok spracovania bol vrátený študentovi ako odpoveď z VCS
systému (obr. 2), pričom pre každú chybu, ktorá bola pri testovaní zistená, bol do prostredia
GitLab-u pridaný Issue pomocou jeho REST API.
Toto testovanie trvalo dva týždne. Zúčastnilo sa ho spolu 475 študentov, ktorí vytvorili
cez 12000 kontrol, čo je priemerne 25 kontrol na jedného študenta.
1
http://flask.pocoo.org
https://ellislab.com/codeigniter
3
http://www.gitlab.com
2
114
Obr. 1. Schéma prípadu hodnotenia na požiadanie.
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
remote:
============================
=
Results
=
============================
Problemset: tiktak
Compilation: Passed
Globals: no
Testcase | State | Score
---------------------------1
| Pass | 0.2
2
| Pass | 0.2
3
| Pass | 0.2
4
| Pass | 0.2
5
| Pass | 0.2
---------------------------Sum:
5
|
5
| 1.0
---------------------------============================
Excelent! The problemset PS1 is solved.
Obr. 2. Odpoveď z VCS systému, ak kontrola prebehla v poriadku.
1.1 Webová služba Structure Checker
Úlohou služby Structure Checker je overiť štruktúru projektu. Kontrola zahŕňa overenie
existencie súborov a priečinkov vyžadovaných v danom projekte. Ak sa v ňom totiž
potrebné súbory nenachádzajú, nie je vlastne čo testovať.
Vstupom služby je zabalený archív projektu a šablóna vo formáte XML, ktorá opisuje,
ako má štruktúra projektu vyzerať. Podoba šablóny, ktorá má overiť štruktúru súborov a
priečinkov zobrazenú na obrázku 3 sa nachádza na obrázku 4.
Výstupom služby je JSON dokument so zoznamom chýb a zoznamom varovaní.
Poster
115
.
`-- ps1
|-- tesco.c
`-- tiktak.c
Obr. 3. Štruktúra súborov a priečinkov prvého zadania.
<?xml version="1.0" encoding="UTF-8"?>
<package name="prog-2014(-[a-z][a-z0-9])?\.zip">
<directory name="ps1">
<file name="tiktak.c"/>
<file name="tesco.c"/>
</directory>
</package>
Obr. 4. Šablóna opisujúca požadovanú štruktúru.
Okrem kontroly štruktúry priečinkov a súborov je však možné overiť aj správnosť
názvu súborov, priečinkov a samotného archívu (v prípade, ak sa v názve napr. nachádzajú
identifikačné údaje študenta) ale aj požadovaný obsah v niektorých súboroch (napr. ak je
potrebné prečítať doplnkové metaúdaje o študentovi, ako e-mail, číslo skupiny, meno a
priezvisko a pod.). Na kontrolu je možné s výhodou využiť regulárne výrazy.
Táto služba je príkladom univerzálnej služby, ktorá nemusí byť nutne použitá len pre
overovanie programátorských projektov.
1.2 Webová služba Arena
Najdôležitejšia služba celého procesu je služba s názvom Arena. Práve ona je
zodpovedná za samotné testovanie daného projektu.
Služba obsahuje lokálne úložisko testov pre jednotlivé úlohy. Pri posielaní úlohy na jej
overenie je potrebné špecifikovať, o ktorú úlohu sa jedná. Na správu úloh má služba
definované REST API, pomocou ktorého je možné úlohy vytvárať, aktualizovať a mazať.
Služba zabezpečuje len testovanie konkrétneho problému, resp. úlohy a preto
neobsahuje jej zadanie, ktoré by bolo možné zo služby tiež získať.
Samotné testovanie je definované pomocou JSON súboru, ktorý obsahuje zoznam
jednotlivých testov. Tie sa vykonávajú v poradí, v akom sú v tomto zozname umiestnené.
Vykonanie niektorých testov však môže byť podmienené úspešným vykonaním
predchádzajúceho (napr. unit testy sa nespustia, ak bol preklad programu neúspešný).
Pri návrhu špecifikácie testov bol kladený dôraz na to, aby boli testy do čo najväčšej
miery opisné (deklaratívne). Tým je možné testy vytvárať v pomerne krátkom čase.
Samotný test vždy len spustí niektorý spustiteľný program, ako napr. prekladač pre
preklad riešenia alebo pripravené unit testy. Týmto spôsobom testovania nedochádza ku
závislosti na žiadnom vybranom jazyku alebo špeciálnom softvérovom rámci.
Príklad jednoduchého testu, v ktorom sa testuje len správny výstup proti požadovanému
vstupu, sa nachádza na obrázku 5.
Ako je možné vidieť, autor testu má pod kontrolou aj proces rozbalenia archívu,
v ktorom je uložené riešenie projektu. Samotné testy môžu vykonávať statickú (napr.
identifikovanie globálnych premenných) aj dynamickú (napr. unit testy) analýzu kódu.
116
{
"title": "General Test for PS1",
"testcases": [ {
"title": "unzip package",
"type": "exec",
"cmd": "unzip -j prog-2014.zip ps1/tesco.c",
"strict": true
},
{
"title": "Globals - tesco",
"description": "Searching for globals",
"type": "exec",
"strict": true,
"cmd": "ctags -x --c-kinds=v --file-scope=no tesco.c"
},
{
"title": "Compile Student's Version - tesco",
"description": "Compiles code first",
"type": "exec",
"cmd": "gcc -std=c99 -Wall -Werror tesco.c -o tesco",
"strict": true
},
{
"title": "Input Over Range",
"description": "Input Over Range",
"stdin": "10000 23 17 0.12",
"expectedStdout": "Enter value of your bill: Wrong
input!",
"type": "exec",
"timeout": 2,
"cmd": "./tesco"
} ]
}
Obr. 5. Príklad testu pre službu Aréna.
Test môže mať nastavené aj ďalšie atribúty, napr. pomocou atribútu strict je možné
nastaviť striktnosť testu (ak test zlyhá, nebude vykonaný už žiadny ďalší test zo zoznamu
testov), alebo je možné nastaviť dĺžku trvania testu pomocou atribútu timeout (ochrana
napr. pred zacyklením programu).
Pri tvorbe služby sme sa inšpirovali aj hook-mi z VCS systémov a rovnako tak je možné
spustiť aj pre-test a post-test hook. pre-test zatiaľ našiel svoje využitie pri
príprave testov a generovaní náhodných vstupných hodnôt. post-test používame pre
bodové hodnotenie úloh a úpravu podoby výstupu.
Služba vráti klientovi výsledok v podobe rozšírenej verzie JSON súboru s testom, do
ktorého zahrnie aj výsledky. Klient následne rozhodne, ktoré údaje a akým spôsobom
poskytne študentovi.
Poster
2
117
Prípad použitia 2 – Hodnotenie v pravidelných časových intervaloch
Schéma nasadenia druhého prípadu použitia sa nachádza na obrázku 6. V tomto prípade
išlo o jednoduché simulovanie reálneho prostredia, kedy sa testy spúšťali v pravidelných
časových intervaloch (každé 3h).
Obr. 6. Schéma prípadu hodnotenia v pravidelných časových intervaloch.
Študent do VCS systému odošle svoje riešenie. V pravidelných časových intervaloch sa
spúšťa proces Gladiator, ktorý kontrolu týchto riešení spúšťa.
Gladiator najprv vyhľadá študentov projekt v systéme VCS, k čomu je možné využiť
REST API projektu GitLab. Po jeho nájdení najprv overí štruktúru projektu pomocou
služby Structure Checker. Po úspešnej kontrole je projekt poslaný službe Arena, kde sa nad
riešením spustia funkčné testy. Výsledky testov sú následne publikované študentovi
prostredníctvom služby Caesar.
Tento prípad použitia sme používali na dvoch projektoch a v databáze prezentačnej
služby Caesar sa nachádza spolu cez 22000 záznamov. Toto číslo žiaľ nezahŕňa všetky
testy, nakoľko počas experimentov došlo niekoľkokrát k zásahu aj do databázy.
2.1 Webová služba Caesar
Služba Caesar slúži len na publikovanie výsledkov pre študentov. Prezentácia
výsledkov je v podobe webovej stránky, kde študenti môžu v prehľadnej podobe zistiť stav
svojho projektu. Ukážka výstupu služby sa nachádza na obrázku 7.
Služba Caesar má definované REST API, pomocou ktorého vie Gladiator alebo
akákoľvek iná komunikujúca aplikácia výsledky testov prezentovať. Konkrétna podoba
výsledkov je závislá od typu výstupu testu, napr. porovnanie požadovaného výstupu
z programu so študentským je možné zobraziť pomocou nástroja diff, zatiaľ čo výsledok
hlásiaci chybu prekladu sa zobrazí ako text.
Adresu s výsledkami sme pre každého študenta posielali pomocou e-mailu. Tento
spôsob sa nám však pri takom počte študentov neosvedčil, nakoľko e-maily zvykli
v niektorých prípadoch značne meškať. Preto Caesar obsahuje aj sumárnu stránku pre
každého študenta so všetkými jeho výsledkami. Nie je preto potrebné čakať na doručenie
mailu, ale v príslušných časových intervaloch stačí sledovať len danú adresu.
118
Obr. 7. Celkový prehľad výsledkov študenta prezentovaný službou Caesar.
3
Prípad použitia 3 – Hodnotenie na požiadanie počas skúšky
Posledným prípadom použitia bolo nasadenie služieb do procesu záverečnej skúšky.
Študenti počas vymedzeného času riešili úlohy a svoje riešenia si mohli priebežne
kontrolovať, čím získali okamžitú spätnú väzbu. Schéma nasadenia tohto prípadu použitia
sa nachádza na obrázku 8.
Obr. 8. Schéma nasadenia služieb na záverečnej skúške z predmetu.
V tomto prípade s webovou službou Arena komunikuje priamo webové rozhranie,
v ktorom študent pracuje počas skúšky. Arena teda umožňuje vyhodnotiť aj samostatný
jednoduchý textový dokument (obsah odosielaného formuláru), ktorý nie je nutné baliť
samostatne do archívu.
Študenti nie sú počas trvania skúšky obmedzení v počte odoslaní riešení na kontrolu.
Aktuálne je teda v databáze po niekoľkých skúškach cez 7000 záznamov hodnotení, čo
v priemere predstavuje 15 hodnotení na študenta.
Poster
4
119
Záver
To, čo na začiatku vyzeralo ako silný experiment, sa počas semestra a postupného
nasadenia do praxe prejavilo ako riešenie s obrovským potenciálom do budúcna. Počas
testovania bolo vykonaných vyše 34000 testov, do ktorých bolo zapojených 475 študentov.
Podobný princíp hodnotenia bol čiastočne viditeľný len v prostredí systému edx. Tu sme
dokázali pri jednoduchom analyzovaní komunikácie pomocou nástrojov vo webovom
prehliadači identifikovať niekoľko služieb systému. Architektonicky podobným riešením sa
javí sada nástrojov eduComponents [2], ale podobne, ako ostatné spomínané systémy je
jeho vnútorná architektúra značne previazaná.
V článku boli prezentované tri prípady použitia troch webových služieb. V každom
jednom sa jednalo o použitie rovnakých služieb, avšak vždy v kontexte iného procesu.
Rovnako tak ich je možné podobným spôsobom prepojiť aj s existujúcimi populárnymi
CMS/LMS systémami, kedy napríklad vyhodnocovanie špecifických typov otázok v teste
môže mať práve na starosti konkrétna webová služba (podobne, ako je tomu v prípade
použitia č. 3). Môže byť však vytvorená aj špeciálna aktivita na odovzdávanie
programátorských zadaní v prostredí vybraného LMS, ale to sa bude na pozadí posielať na
hodnotenie do niektorej webovej služby a LMS bude použité len ako komunikačné
rozhranie medzi študentom a systémom (podobne, ako je tomu v prípade použitia č. 2).
Nespornou výhodou takéhoto prístupu je aj nezávislosť služieb - každá robí len to, na čo
je určená. Vďaka navrhnutému jednoduchému REST API nie je potrebné vytvárať
špeciálne používateľské rozhranie. V rámci komunikácie nedochádza k posielaniu
súkromných informácií, ako napr. prihlasovacie meno alebo heslo. Komunikáciu je ale
možné v špeciálnom prípade filtrovať pomocou súkromných tokenov, ktorým sa klient
nadväzujúci komunikáciu so službou autentifikuje v hlavičke dopytu.
Za jediný vážny zistený problém je možné považovať nasadenie systému počas skúšky,
kedy je v krátkom čase potrebné obslúžiť množstvo študentských dopytov. Ak sa totiž
hodnotenie jednej úlohy skladá z 10 testov a max. dĺžka hodnotenia jedného z nich sú 2s,
v najhoršom prípade tak trvanie celého testu zaberie 20s. Ako možné riešenie sa javí
použitie niektorého z dostupných frontov úloh. Uvedené existujúce riešenia [2], [3] a [6] sa
tomuto problému nevenujú, nakoľko každej úlohe môže učiteľ nastaviť max. počet
hodnotení, ktorý nemôže byť prekročený. V našom prípade však boli niektorí študenti
schopní počas skúšky urobiť aj viac ako 50 hodnotení.
Pomocou týchto služieb sa taktiež podarilo jednoducho naplniť kritériá uvedené
v úvode článku – dokázali sme rýchlo obslúžiť niekoľko stoviek študentov a zabezpečiť
objektívne hodnotenie ich výsledkov, pričom jednotlivé služby sme vedeli použiť znovu
v rozličných prípadoch. Vďaka tomu sa nám podarilo dosiahnuť náš hlavný cieľ omnoho
ľahšie a efektívnejšie – naučiť študentov programovať. A aj keď sa požiadavky kladené na
absolvovanie predmetu tento rok výrazne zvýšili, v porovnaní s minulým rokom je
percentuálny podiel úspešných študentov, ktorí predmet absolvovali, len o 7% nižší.
Literatúra
1.
2.
Ala-Mutka, K.: A survey of automated assessment approaches for programming
assignments. Computer Science Education, 15(2):83–102, 2005
Amelung, M., Krieger, K., & Ro, D. (2011). E-Assessment as a Service. IEEE
TRANSACTIONS ON LEARNING TECHNOLOGIES, 4(2), 162–174.
120
3.
Higgins, C. A., Gray, G., Symeonidis, P., & Tsintsifas, A. (2005). Automated
assessment and experiences of teaching programming. Journal on Educational
Resources in Computing. doi:10.1145/1163405.1163410
4. Chacon, S.: Pro Git. Apress, 2009
5. Ihantola, P., Ahoniemi, T., Karavirta, V., & Seppälä, O. (2010). Review of recent
systems for automatic assessment of programming assignments. Proceedings of the
10th Koli Calling International Conference on Computing Education Research - Koli
Calling ’10, 86–93. doi:10.1145/1930464.1930480
6. Joy, M., Griffiths, N., & Boyatt, R. (2005). The BOSS online submission and
assessment system. Journal on Educational Resources in Computing, 5(3), 2–es.
doi:10.1145/1163405.1163407
7. Kolling, M., Quig, B., Patterson A., and Rosenberg, J.: The BlueJ system and its
pedagogy. Computer Science Education, 13.dec.2003
8. Pattis, R. E.: Karel the Robot: A Gentle Introduction to the Art of Programming. John
Wiley & Sons, Inc., New York, NY, USA, 1981
9. Pears, A., Seidman, S., Malmi, L., Mannila, L., Adams, E., Bennedsen, J., … Paterson,
J. (2007). A survey of literature on the teaching of introductory programming. In
ITiCSE-WGR ’07: Working group reports on ITiCSE on Innovation and technology in
computer science education (pp. 204–223). doi:10.1145/1345443.1345441
10. Tvarožek, J., & Bieliková, M. (2010). Feasibility of a socially intelligent tutor. In
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial
Intelligence and Lecture Notes in Bioinformatics) (Vol. 6095 LNCS, pp. 423–425).
doi:10.1007/978-3-642-13437-1_91
11. Valentine, D. W. (2004). CS educational research: a meta-analysis of SIGCSE
technical symposium proceedings. ACM SIGCSE Bulletin, 36, 255–259.
doi:10.1145/1028174.971391
12.
Poďakovanie
This work was supported by project KEGA No. 019TUKE-4/2014 Integration of the Basic
Theories of Software Engineering Engineering into Courses for Informatics Master Study
Programmes at Technical Universities - Proposal and Implementation and by project
Information technology for knowledge transfer (ITMS project code: 26220220123)
supported by the Research & Development Operational Program funded by the ERDF.
Annotation:
Web Services in the Process of Evaluation of Student's Projects
Teaching of programming is closely related with the evaluation of created programs by students. This
process can be very tedious, but with the proper tools it is possible in a relatively short time evaluate
solutions of big number of students with the objectivity of the evaluation process. This article is
dedicated to the automatization of this process with the usage of SOA architecture.
Peter LACKO, Juraj VINCÚR, Martin TIBENSKÝ, Pavol PIDANIČ, Juraj PETRÍK,
Ján KALMÁR, Ondej JURČÁK, Radoslav ZÁPACH
Ústav informatiky a softvérového inžinierstva,FIIT STU v Bratislave
Ilkovičova 2, 812 19 Bratislava
[email protected]
Abstrakt. Tento článok sa zaoberá výhodou využitia distribuovaných počítacích sietí
založených na báze spoluúčasti dobrovoľníkov. Predstavuje architektúru a základné
znaky systému BOINC, ktorý umožňuje takúto sieť vytvoriť a prevádzkovať a tiež
pilotný projekt vytvorenia takejto siete na Fakulte informatiky a informačných
technológií Slovenskej technickej univerzity v Bratislave. Systém je testovaný
pomocou riešenia hry Reversi a štatistickej úlohy týkajúcej sa DNA.
Kľúčové slová: distribuované počítanie, dobrovoľnícke počítanie, BOINC, Reversi,
DNA.
1 Úvod
Veľké množstvo moderných výkonných počítačov je v prostredí domácností alebo
organizácií využívaných len na administratívnu prácu alebo prehliadanie internetu.
Výpočtový potenciál týchto zariadení je využitý len na zlomok jeho maximálnej hodnoty.
Tu vzniká priestor na využitie týchto počítačov na špeciálny spôsob distribuovaného
počítania založeného na vytvorení sieti dobrovoľníkov. Dobrovoľníci sa podieľajú na
riešení výpočtových úloh poskytnutím svojich nevyužitých zariadení a tak pomáhajú
urýchliť výskumníkom riešenie výpočtovo náročných úloh, ktoré sa dajú vhodným
spôsobom rozdeliť na menšie úlohy.
Tento spôsob zdieľania výpočtových prostriedkov je výhodný z ekonomického aj
ekologického hľadiska, pretože nie je potrebná výroba alebo zaobstarávanie špeciálnych
superpočítačov a využívajú sa len už dostupné zariadenia.
2 Dobrovoľnícke počítanie a systém BOINC
V našom prostredí môžeme distribuované počítanie definovať ako spoluprácu väčšieho
množstva uzlov na riešení výpočtovo náročného problému. Uzly v sieti komunikujú iba
s centrálnym uzlom určeným na administráciu celého procesu a samé seba ponúkajú len
ako samostatné entity. Z tohto dôvodu musí riešený problém spĺňať určité podmienky a síce
musí byť vhodným spôsobom rozdeliteľný na menšie problémy, ktoré sa ďalej distribuujú
medzi jednotlivé uzly.
V štandardných typoch distribuovaných počítacích sietí sú všetky uzly pod kontrolou
administrátora, sú známe ich špecifiká, môže byť na nich v prípade potreby vykonaný
priamy zásah do systému a sú spojené vysokorýchlostným pripojením. Pri takomto stupni
kontroly je možné vykonávať výpočtové úlohy skrytou formou, bez vedomia prípadného
122
ďalšieho používateľa uzla a výsledky vrátené od týchto uzlov možno bez špeciálnej
kontroly označiť za dôveryhodné.
V dobrovoľníckych distribuovaných počítacích sieťach je situácia trochu iná. Sieť je
vysoko heterogénna. Uzly majú rôzne operačné systémy, architektúry, systémové
prostriedky a rýchlosť pripojenia. Dobrovoľník je si plne vedomý účasti v takejto sieti. Pri
týchto podmienkach musia dobrovoľnícke siete riešiť radu ďalších problémov ako časté
pripájanie a odpájanie uzlov, efektívne prideľovanie v závislosti od systémových
prostriedkov uzla alebo potenciálne škodlivé správanie sa účastníkov vo forme sabotáže
výsledkov ich falšovaním alebo infiltráciou škodlivého kódu do systému.
Jedným zo systémov na vytváranie takýchto sietí je systém BOINC (Berkeley Open
Infrastructure for Network Computing) [1]. BOINC bol pôvodne zavedený v roku 2002 pre
podporu projektu SETI@home [2], ktorý sa zaoberá analýzou rádiových signálov za
účelom hľadania mimozemského inteligentného života. V roku 2013 bolo do projektu
zapojených už približne 145 tisíc aktívnych zariadení. Od svojho vzniku sa stal BOINC
populárnym nástrojom pre vytváranie a administráciu distribuovaných sietí aj pre mnoho
iných projektov.
2.1
Stručný popis systému
BOINC je postavený na štandardnej klient-server architektúre. Serverová časť má na
starosti celkovú administráciu projektu, vytváranie úloh, ich distribúciu dobrovoľníckym
zariadeniam, validáciu vrátených výsledkov a ich spracovanie. Štandardná inštalácia
obsahuje aj šablóny pre projektové stránky, ktoré slúžia jednak na popularizáciu projektu
a jednak na zobrazovanie priebežného stavu celkového riešenia problému alebo štatistické
údaje týkajúce sa počtu pripojených uzlov, prípadne rebríčky najlepších dobrovoľníkov.
Tieto rebríčky sa vytvárajú na základe kreditov pridelených za riešenie jednotlivých úloh.
Kreditový systém neposkytuje žiadne ďalšie výhody, ale podporuje prirodzenú súťaživosť
používateľov a tým môže projektu priniesť ďalšie výpočtové prostriedky.
V serverovej časti sa vytvárajú projekty. Každý projekt má svoj jedinečný identifikátor
a jeden BOINC server obsluhuje len jeden projekt. V rámci projektu môžeme vytvárať
ľubovoľné množstvo aplikácií, ktoré potom posielame dobrovoľníkom. Aplikácie môžu
mať niekoľko verzií, v závislosti od toho, pre koľko platforiem a architektúr ich chceme
vytvárať. Dobrovoľník má vždy možnosť pripojiť sa len k projektu, pričom o zaslanej
aplikácii rozhoduje server. Po pripojení k projektu sa dobrovoľníkovi pridelia na základe
jeho systému a systémových prostriedkov úlohy, ktoré sa odosielajú spolu s príslušnou
verziou aplikácie. Klientská časť má na starosti primárne spúšťanie, prípadne
pozastavovanie aplikácie a odosielanie výsledkov serverovej časti vo forme výstupného
súboru.
2.2
Serverová časť
Serverová časť sa skladá z niekoľkých navzájom spolupracujúcich častí. Časť má na
starosti fázu od vytvorenia úlohy až po jeho odoslanie klientovi a časť procesy spojené
s prijímaním a spracovávaním výsledkov.
Prvú časť tvorí generátor práce (work generator) slúžiaci na vytváranie úloh, ktoré
tvoria prakticky jednotlivé riešené problémy. Tieto úlohy pozostávajú zo súboru, alebo
množiny súborov, ktoré sa spolu s aplikáciou posielajú dobrovoľníkom. O tom, kto dostane
aký počet úloh rozhoduje plánovač (scheduler). V bode plánovania sa využíva aj jeden
z ochranných mechanizmov zameraných na identifikovanie nesprávne vypočítaných alebo
sfalšovaných výsledkov, ktoré sa môžu v dobrovoľníckych sieťach vyskytnúť. Ochrana
spočíva vo vygenerovaní viacerých identických úloh a ich rozposlanie rôznym klientom.
Poster
123
Pri ich prijímaní sa následne porovnávajú a výsledok nie je akceptovaný, pokiaľ sa
nedosiahne nejaké zvolené kvórum totožných odpovedí prijatých od klientov.
Druhá časť pozostáva hlavne z validátora a asimilátora. Validátor je bod prvého
kontaktu s vrátenými výsledkami a okrem vyššie spomenutého mechanizmu môže slúžiť aj
na overovanie vráteného súboru z formálnej stránky – jeho typ, veľkosť, formát obsahu atď.
Po validácii sa súbor premiestni do priečinku, kde čaká na spracovanie asimilátorom.
Jednoduchý asimilátor môže slúžiť len na spracovanie a následné uloženie výsledku do
databázy. Zložitejšie môžu vykonávať napríklad projektovo špecifické štatistické operácie
a spracovanie výsledkov.
Všetky vyššie spomenuté komponenty systému môžeme pomocou systému BOINC
spúšťať pri vzniknutí príslušných udalostí.
Obr.1. Architektúra systému BOINC
2.3
Klientská časť
Klientská časť, ktorú si na svojich zariadeniach musí nainštalovať dobrovoľník sa navonok
javí ako jeden celok, v pozadí sa skladá z viacerých častí, ktoré sú schopné fungovať
relatívne samostatne.
Jadro (core klient) komunikuje so serverom, odovzdáva mu informácie o klientovi,
stave riešenej úlohy, pýta si úlohy, spúšťa a manažuje aplikácie a v poslednom kroku
odosiela výsledky serverovej časti. Grafické rozhranie slúži dobrovoľníkovi na pripojenie
k projektu, prípadne nastavenie toho, za akých podmienok bude aplikácia spustená a aké jej
poskytne systémové prostriedky. Voliteľnou súčasťou klientskej časti je šetrič obrazovky,
ktorý môže na klientovi zobrazovať obrázky týkajúce sa projektu, prípadne zaujímavé
štatistiky a priebeh jednotlivých úloh.
124
3 Riešené projekty
Nasadenie BOINC siete prebiehalo na Fakulte informatiky a informačných technológií
STU (BOINC@Fiit – boinc.fiit.stuba.sk) v rámci študentského tímového projektu [5].
Úlohou projektu bolo otestovať sieť pomocou vybraných výpočtových úloh a vytvoriť
dokumentáciu, šablóny a návody pre ďalšie generácie študentov a výskumníkov. Keďže
výkon takýchto sietí závisí hlavne od počtu pripojených dobrovoľníkov, kriticky dôležitou
úlohou je aj verejné prezentovanie a popularizácia projektu.
3.1
Symetrická hra Reversi 8x8
Reversi je strategická dosková hra pre dvoch hráčov. Hráči postupne na plochu ukladajú
kamene a v prípade že sa hráčovi podarí ohraničiť súvislú čiaru súperových kameňov na
oboch koncoch, premení kamene na tejto čiare na svoju farbu. Cieľom hráča je mať na
konci hry na doske čo najväčší počet kameňov svojej farby.
Obr.2. Štartovná pozícia a prvý možný ťah v Reversi 8x8
Hlavným cieľom nášho projektu bolo zistiť ako hra dopadne v prípade, že sa v každom
ťahu hráč rozhodne ideálnym spôsobom, pričom prvý ťah uskutočňuje čierny hráč.
V prípade, že by sa nám podarilo uspieť, boli by sme celosvetovo prvým tímom, ktorý
našiel výsledok pre túto veľkosť šachovnice.
Hra Reversi je vďaka prirodzenému rozdeleniu možností do herného stromu ideálnym
kandidátom na riešenie pomocou distribuovanej siete. Každý uzol v strome predstavuje
šachovnicu po jednom z možných ťahov. Celkový počet legálnych ťahov pre tento rozmer
dosky je až 1028. Pri probléme takejto veľkosti je dôležité uvažovať vhodné heuristiky
jednak pri samotnom prehľadávaní stromu a jednak pri asimilácii výsledkov na strane
servera.
Úlohy vytvorené pre klienta pomocou generátora systému BOINC pozostávajú z pod
stromov, ktoré vznikli na určitej úrovni hlavného stromu hry. Samotný odosielaný súbor
obsahuje stav dosky (koreň pod stromu) a vhodne zvolený identifikátor, ktorý bol v tomto
prípade uložený v názve samotného súboru.
Klient vypočíta zadaný pod strom, rozhodne ktorý hráč a s akým náskokom vyhral
a výsledok pošle serveru. Server si výsledky ukladá do databázy a po ich skompletizovaní
určí výsledok pre celý strom.
Pri problémoch takejto veľkosti, je vhodné otestovať správnosť používaných
algoritmov, ale aj nástrojov slúžiacich na generovanie úloh a spracovávanie výsledkov. Na
takéto testovanie sme najskôr implementovali riešenie pre dosku s veľkosťou 6x6, ktorej
výsledok je známy [4] a v dnešnej dobe ho trvá bežnému počítaču nájsť rádovo minúty.
Poster
125
Obr.3. Spôsob distribúcie problému na menšie úlohy
Pomocou systému BOINC a našich algoritmov sme dostali správny výsledok (pre
zaujímavosť vyhrá biely o štyri kamene). V čase písania článku sa do tohto projektu
zapojilo 111 dobrovoľníkov, ktorí nám poskytli dokopy 1100 výpočtových jadier.
3.2
Štatistická analýza fragmentov DNA
V prostredí našej fakulty sa rozbieha aj výskum zameraný na rôzne metódy a algoritmy
spojené s DNA. Samotné skladanie DNA sme nevyhodnotili ako problém vhodný na
riešenie pomocou tohto typu siete, napríklad pre veľmi veľké nároky na pamäť už pri
menších genómoch. V rámci trvania tímového projektu však vznikla požiadavka na
vytvorenie distribuovaného systému skúmajúceho určité vlastnosti fragmentov, ktoré
produkujú zariadenia určené na skladanie DNA v procese čítania genetickej informácie.
Výstupom z tohto projektu budú nielen výsledky potenciálne užitočné pre výskumnú
prácu, ale aj šablóny pre aplikácie riešiace iné problémy týkajúce sa skúmania reťazcov
DNA.
Fragmenty, alebo laicky kúsky genetického kódu, ktoré sú vstupom pre samotné
skladanie DNA [6] môžu v rôznom počte obsahovať podreťazce, ktoré sú súčasťou
výslednej DNA. Zaujímavým problémom je zistiť, koľko krát sa štatisticky musí nachádzať
podreťazec vo fragmentoch, aby sme mohli prehlásiť, že sa v určitom počte bude nachádzať
aj vo výslednej DNA [4].
Na obrázku 4 je v hornej časti zobrazená výsledná DNA a pod ňou fragmenty,
z ktorých sa skladá. Pri fragmentoch môžeme uvažovať rôzne parametre ako dĺžka
jednotlivého fragmentu, počet fragmentov a pokrytie, ktoré vyjadruje s akou redundanciou
pokrývajú fragmenty referenčnú vzorku DNA. Spolu s množinou hľadaných podreťazcov
dostaneme množinu parametrov, ktorých hodnoty môžeme navzájom kombinovať. Tieto
kombinácie predstavujú úlohy, ktoré sa posielajú klientom. Výstupom od klienta bude
súbor s početnosťami pre hľadané podreťazce, pre dané hodnoty počtu fragmentov a dĺžky
fragmentov.
Pri tomto type úlohy nevzniká pri využití BOINCU takmer žiadna nadbytočná práca.
Generátor aj asimilátor by museli byť v nejakej forme, kvôli vytvoreniu experimentov
a spracovaniu výsledkov, vytvorené aj pri lokálnom riešení. Ak zohľadníme aj fakt, že
množstvo úloh v oblasti výskumu DNA sa týka práce s reťazcami, je reálnym a praktickým
cieľom vytvoriť nad systémom BOINC aplikačný rámec (framework). Tento rámec by
umožňoval výskumníkom nasadzovať riešenia do distribuovanej bez zbytočnej nadpráce
a agregovať viac výskumných problémov v rámci BOINC projektu.
126
Obr.4. DNA a fragmenty
4 Záver
Čísla predaných počítačov a smartfónov sa v roku 2013 pohybovali v stovkách miliónov.
Pomocou mizivého zlomku týchto zariadení sa dá vytvoriť dobrovoľnícka distribuovaná
počítacia sieť, ktorá pokryje potreby bežnej fakulty na dekádu dopredu. Systém BOINC
predstavuje technické riešenie s vysokým potenciálom pomáhať pri výučbe, teoretickom
výskume a hľadaní riešení reálnych problémov, ako napríklad existujúca dobrovoľnícka
sieť hľadajúca lieky na rakovinu. Zavádzanie a popularizovanie takýchto systémov v rámci
fakúlt im môže ušetriť finančné prostriedky, ktoré by boli potrebné na zakúpenie super
výkonných počítačov a špeciálnych priestorov, v ktorých musia byť umiestnené.
Poďakovanie. Tento článok vznikla vďaka podpore v rámci OP Výskum a vývoj pre
projekt: Podpora dobudovania Centra excelentnosti pre Smart technológie, systémy a
služby I a II, ITMS 26240120005, ITMS 26240120029, spolufinancovaný zo zdrojov
Európskeho fondu regionálneho rozvoja. Práca bola čiastočne podporená projektom APVV
0233-10.
Literatúra
1.
2.
3.
4.
5.
6.
Anderson, D. P.: BOINC: A System for Public-Resource Computing and Storage. In:
5th IEEE/ACM International Workshop on Grid Computing, November 8, 2004,
Pittsburgh, USA, pp 1-7.
Anderson, D. P. et al.: SETI@home: An Experiment in Public-Resource Computing.
Communications of the ACM, Vol. 45 No. 11, November 2002, pp. 56-61.
Feinstein, J.: Amenor Wins World 6x6 Championships! British Othello
FederationNewsletter, July, pp 6-9
Motahari, A. S. and Bresler, G.: Information Theory of DNA Shotgun Sequencing.
IEEE Transactions on Information Theory, Vol. 59, No. 10, October 2013
Vincúr, J. et al.: FIIT Grid – Distributed Computing Network. In: Proceedings in
Informatics and Information Technologies IIT.SRC 2014 Student Research Conference,
Mária Bieliková (Ed.), Nakladateľstvo STU, Bratislava (2014), 629-630
Warren, R. L. at al.: Assembling millions of short DNA sequences using SSAKE.
Bioinformatics Applications Note, Vol. 23 no. 4 2007
Poster
127
Annotation:
BOINC@FIIT – distributed computing network
This article addresses the advantage of using distributed computing networks based on participation
of volunteers. First part describes architecture and tasks of main modules of BOINC system, which is
designed to create and administer distributed computing networks. Article also covers the pilot project
of deployment distributed network on Faculty of Informatics and Information System in Bratislava.
System is tested with two different kind of tasks suitable for this way of computing. First project is
focused on finding ultra weak solution of Reversi 8x8 game. Reversi game tree can be naturally
distributed to subtrees which play role of subproblems. Second project consist of statistical task
related to searching for substrings in DNA fragments with various parameters.
Databázový mirror jako nutná komponenta
informační podpory při řízení kontinuální výroby
Roman DANEL, Lukáš OTTE, David JOHANIDES
Institut ekonomiky a systémů řízení, Hornicko-geologická fakulta,
VŠB – TU Ostrava
17. listopadu 15/2172, 708 33 Ostrava - Poruba
{roman.danel, lukas.otte, david.johanides.st}@vsb.cz
Abstrakt. Pro řízení kontinuálních technologických procesů v surovinovém průmyslu
je v dnešní době nutná existence informačního systému pro řízení výroby (MES),
který splňuje požadavky na spolehlivost a robustnost a je tedy v kategorii faulttolerant systémů. Na Institutu ekonomiky a systémů řízení se zabýváme návrhem
vhodné hardwarové i softwarové architektury takových systémů. V článku jsou
popsány důvody pro fault-tolerant řešení na příkladu informačního systému úpravny
uhlí a řízení jakostních parametrů uhlí. Pro řízení jakostních parametrů s cílem
zabránit překročení maximální hodnoty se používá informace o trendu, která je
vypočítávána z časových řad. Je tedy nutné zabezpečit data mající charakter časové
řady tak, aby byly bez přerušení, a pro tento účel je vhodná technologie databázového
mirroringu (zrcadlení). V červnu 2014 byl na Institutu zahájen projekt v rámci
Studentské grantové soutěže (SGS) s cílem porovnat technologie zrcadlení databází
čtyř producentů databázových systémů a doporučit nejvhodnější řešení z pohledu
funkcionality a ceny.
Klíčová slova: databázový mirror, informační systém úpravny, řízení kontinuálních
procesů, fault-tolerant systém, časová řada, výpočet trendu.
1 Úvod
Architektura a funkcionalita informačních systémů pro řízení výroby (označované jako
MES – Manufacturing Execution Systems) je závislá na druhu výroby. Principiálně existují
tři kategorie – výroba kusová, dávková a kontinuální. Na Institutu ekonomiky a systémů
řízení se dlouhodobě zabýváme automatizací a informačními systémy v oblasti
surovinového průmyslu, ve kterém převažují kontinuální technologické procesy (těžba uhlí,
zpracování energií, plynu, těžba a zpracování nerostů…). Typickou úlohou, řešenou
v informačních systémech pro kontinuální výrobu, je sběr dat o technologickém procesu,
což produkuje rozsáhlou množinu dat majících charakter časové řady. Tato data jsou
využívána pro bilanční výpočty a pro analýzu a výpočet trendu technologických nebo
jakostních parametrů.
Oproti nedávné minulosti je řízení výroby čím dál více závislé na existenci
informačního (řídicího) systému. Je to dáno neustálým důrazem na zvyšování produktivity
práce, stále přísnějšími požadavky odběratelů na jakost a tlakem ze strany konkurence. To
zase vytváří požadavky na informační systém, a to především na spolehlivost a robustnost
systému. Výpadek informačního systému může mít negativní důsledky jak pro samotné
řízení procesu, tak pro zajištění jakosti a kvality. Stále častěji jsou proto požadována řešení
v podobě tzv. fault-tolerant systémů (odolných vůči jakémukoli výpadku). Nejjednodušším
130 Databázový mirror…komponenta informační podpory při řízení kontinuální výroby
řešením pro zajištění požadavku na fault-tolerant je zdvojení systému (pokročilejší
enterprise řešení v podobě failover clusteringu a technologií „always-on“ poskytují větší
možnosti, avšak za vyšší cenu).
Hlavní myšlenkou fault-tolerant řešení informačního (řídicího) systému je existence
druhé – záložní – kopie systému, na kterou můžeme přejít v případě kritického výpadku
produkčního systému. Na systému záložním tedy musíme mít nejen identickou kopii
aplikačního vybavení, ale také aktuální data. Pokud má být přechod na záložní systém
dostatečně rychlý (v ideálním případě by uživatelé systému přechod neměli zaznamenat),
musíme mít k dispozici on-line kopii veškerých provozních dat. Přibližně před deseti lety
začali tvůrci databázových systémů nabízet technologie, které výše uvedený problém umí
zajistit – replikace a později mirroring (zrcadlení).
2 Příklad informačního systému pro řízení kontinuálních procesů
Jako příklad výrobního procesu, kde pořizovaná data mají charakter časových řad, je
například výroba černého uhlí. Výroba a prodej uhlí není jen o vytěžení uhlí z dolu, ale
podstatné je také dodržení jakostních parametrů požadovaných odběrateli. Důležitým
mezičlánkem mezi těžbou uhlí a jeho prodejem zákazníkům je zpracování uhlí v úpravně s
cílem dosáhnout odběrateli požadované jakostní parametry uhlí. Úprava uhlí v úpravně je
kontinuální proces, probíhající v režimu 7x24. Mezi základní jakostní parametry uhlí patří
obsah popele a obsah vody; další parametry jsou: výhřevnost, spalné teplo, obsah síry,
dilatace či index puchnutí. Obsah vody a popele je ovlivnitelný v procesu úpravy uhlí,
ostatní parametry jsou dány chemickým složením těžené suroviny.
Obr. 1 Kontinuální gamapopeloměr firmy Enelex Chvaletice
[Zdroj: http://www.enelex.cz/gamapopelomery.htm]
Aby bylo možné zmíněné jakostní parametry při výrobě uhlí dodržet, jsou úpravny uhlí
vybaveny informačními systémy, které v reálném čase zpracovávají informace ze snímačů.
Vzorkováním dat ze snímačů vznikají časové řady. Pro řízení jakosti jsou podstatné údaje o
jakosti na výstupu z úpravárenských technologií, měřené kontinuálními popeloměry
(nejčastěji se používají gamapopeloměry firmy Enelex, obrázek 1) a vlhkoměry (např.
Berthold), které jsou sice méně přesné než měření vzorků uhlí v laboratořích, ale jsou
schopné poskytovat údaje v reálném čase ještě v průběhu výroby [4]. Pro pracovníky
dispečinku nebo velínu nakládky uhlí není podstatná okamžitá hodnota ani její přesnost, ale
fakt, že na základě vzorkování jakostních parametrů s určitou časovou periodou informační
systém vypočítává z měřených hodnot trend (informace, zda hodnota sledovaného
Poster
131
jakostního parametru v průběhu technologického procesu stoupá či klesá). To umožňuje
dispečerovi provádět zásahy do výrobního procesu tak, aby zabránil nežádoucímu
překročení požadovaných hodnot obsahu popele či vody.
Požadovaná
hodnota
popele v %
Vypočítaná hodnota % popele a vody – vlečený
průměr
Obr. 2 Aplikace pro řízení nakládky, dispečink úpravny Dolu Darkov.
Příklad aplikace pro řízení nakládky uhlí na velínu vidíme na obrázku 2. Dispečer vidí
v informačním systému informace o odběrateli a jím požadovaného množství uhlí a obsahu
popele (tyto údaje jsou získány z podnikového informačního systému SAP R/3, kde jsou
evidovány uzavřené smlouvy na odběr uhlí, které obsahují dohodnuté požadované jakostní
parametry). Informační systém úpravny zároveň dispečerům ukazuje vlečený průměr a
trend z měření obsahu popele uhlí na pásových dopravnících. Jestliže hodnota jakostního
parametru v trendu stoupá, může dojít k překročení požadované hodnoty, což může
znamenat potenciálně problém - nesplnění požadované kvality, riziko jakostních odpočtů či
dokonce v nejhorším případě nutnost uhlí z vagonů vysypat a vrátit zpět do procesu úpravy.
Informace o trendu obsahu popele (zda stoupá či klesá) umožňuje dispečerům a
technologům provést řídící zásahy ještě v průběhu výroby tak, aby jakostní parametry byly
dodrženy. Aby byl informačním systémem trend vypočítán korektně, nesmí časová řada,
z níž je trend počítán, obsahovat mezery vzniklé odstávkou systému. Proto je důležité
zajistit, aby systém pracoval kontinuálně, bez výpadků.
V dřívějších dobách, kdy výroba probíhala bez této informační podpory, docházelo
k nedodržení kvality poměrně často. Při dnešním tlaku na efektivitu výroby už řízení
úpravny bez informační podpory není možné. V minulosti, kdy úpravny nebyly vybaveny
informačním systémem, byly informace o kvalitě zjišťovány kontrolním vzorkováním a
následnou analýzou v podnikové laboratoři. Jedná se o přesný ale časově velmi náročný
proces a výsledky laboratorních rozborů jsou známy až ve chvíli, kdy už je technologický
proces ukončen. Pokud zjistíme zásadní nedodržení kvality v situaci, kdy uhlí už je
nasypáno na vagónech k expedici, jedná se o značné ekonomické ztráty.
Současné informační systémy úpraven uhlí prošly dlouhodobým vývojem a dnes se
používá třetí generace těchto systémů [1]. Jedním z charakteristických rysů třetí generace je
fault-tolerant řešení spočívající ve zdvojení kritických komponent – serverů, koncentrátorů
dat a síťové infrastruktury. Pro řešení spadající do kategorie fault-tolerant systémů je nutné
zajistit také kontinuitu dat v relačních databázích. Pokud z důvodu nefunkčnosti systému
vznikne v datech „díra“, naruší se výpočty vlečených průměrů, trendů či bilancí.
Dnešní databázové systémy nabízejí jako vhodný prostředek pro zajištění kontinuity dat
technologii databázového mirroru (zrcadlení dat mezi dvěma nezávislými instancemi
databáze).
Zde je vhodné uvést, že technologie zrcadlení nenahrazuje zálohování. Zrcadlení i
zálohování mají poněkud jiný účel. Zálohování je pro fault-tolerant řešení nevhodné,
protože v případě výpadku produkčního systému by se na záložním musela obnovit
databáze z poslední zálohy. Nedostatky takového řešení jsou zjevné – pravděpodobně by od
poslední zálohy byla v systému nějaká prodleva a i samotný proces obnovy databáze ze
zálohy zabírá určitý čas, nemluvě o tom, že automatizace takového řešení je velice
problematická. Na druhé straně, ani zrcadlení nenahrazuje zálohování. Zrcadlení přenáší
veškeré změny v produkční databázi – pokud se v databázi nějakým způsobem poruší
integrita dat, promítne se toto narušení i do zrcadlené databáze.
V informačních systémech úpraven v těžební společnosti OKD je technologie zrcadlení
v provozu od roku 2006. Jedno z pilotních řešení na Dole Darkov bylo publikováno na
konferenci Datakon 2007 [2]. Z důvodu požadavku zákazníka na začlenění do
infrastruktury budované na platformě Microsoft, byl použit Microsoft SQL Server 2005.
Zrcadlení databází tam úspěšně funguje nepřetržitě od počátku roku 2007 a lze konstatovat,
že plní svůj účel. Přesto bylo během provozu zjištěno několik problémů, například enormní
nárůst databázových logů [3], způsobený kombinací několika faktorů - použitých
technických prostředků (velikost RAM paměti) a charakteru aplikace (kontinuální
vzorkování z přibližně 300 analogových, 60 čítačových a 1200 binárních snímačů).
3 Projekt testování technologie zrcadlení
Na jaře 2014 byl na Institutu ekonomiky a systémů řízení zahájen interní projekt v rámci
Studentské grantové soutěže (SGS), jehož cílem je ověřit a porovnat aktuální stav
technologií zrcadlení vybraných databázových systémů.
Cílem projektu je prozkoumat možnosti technologií zrcadlení jednotlivých
databázových systémů v kategorii low-end informačních systémů a doporučit nejvhodnější
řešení co se týče poměru funkcionalita a cena.
Alternativní řešení, které je rovněž často nasazováno, je řešení s využitím clusteringu
nebo tzv. „always-on“. Tyto řešení však spadají do kategorie enterprise a jejich pořizovací
cena je poměrně vysoká. V našem případě se zabýváme řešením pro informační a řídicí
systémy, jejichž pořizovací cena se pohybuje v řádu jednotek milionů korun.
Do testování byly zvoleny následující databázové systémy: Oracle, Microsoft SQL
Server, objektová databáze Caché (InterSystems) a MySQL. Poslední jmenovaný systém
disponuje pouze technologií replikace, byl však do testů zařazen jakožto zástupce „open
source“ databází. Výběr SŘBD byl omezen na databázové systémy používané v ČR
v surovinovém průmyslu z důvodu krátkých termínů řešení grantového projektu.
Poster
133
Snímaèe
Snímaèe
Snímaèe
UPS
UPS
Koncentrátory
dat
Router
Produkèní
server
UPS
Záložní
server
databázový
mirror
UPS
Server
Watchdog
UPS
Server
UPS
Router
alarm
Administrátor
Klienti
Obr. 3 Konceptuální schéma informačního systému pro řízení kontinuálních procesů
v surovinovém průmyslu
Pro účely testování byl na začátku projektu navržen model, který co nejvíce odpovídá
skutečné architektuře informačních systémů v surovinovém průmyslu. Konceptuální model
takové architektury informačních systémů vidíme na obr. 3. Základní myšlenkou zmíněné
architektury je koncepce koncentrátorů dat, které fungují jako mezistupeň při přenosu
informací ze snímačů, vážních systémů, analyzátorů apod. do samotného informačního
systému. Informační systém obsahuje dva servery, jeden je v roli produkčního serveru a
druhý v roli záložního (jedná se o konceptuální schéma, zde není rozlišováno další možné
fyzické rozdělení na aplikační a databázový server). Komponenta nazývaná watchdog
slouží pro automatizovanou kontrolu stavu produkčního systému, vyhodnocení závažnosti
výpadků a v případě potřeby zajišťuje přechod aktivního informačního systému na záložní
systém (včetně řešení přesměrování klientů systému). Klienti systému jsou v tomto případě
dispečeři, pracovníci velínů technologických celků a vedení úpravny, kteří v reálném čase
monitorují technologický proces a na základě informací poskytovaných informačním
systémem provádějí řídicí zásahy.
Sestavu technických prostředků (obr. 4) v projektu SGS pro testování zrcadlení databází
tedy tvoří také dva servery s operačním systémem Microsoft Windows Server 2012,
standardní PC v roli koncentrátoru dat a PLC (Programmable Logic Controller, zařízení pro
logické řízení; zde je používáno pro připojení snímačů jako zdroj dat pro databázový
systém) komunikující s koncentrátorem dat. Na PLC je připojeno několik snímačů.
Obr. 4 Sestava technických prostředků pro testování (servery, PC v roli koncentrátoru
dat, PLC s připojenými snímači)
Testovací sestava tedy umožňuje zprovoznit servery v roli produkčního a záložního
serveru, nastartovat zrcadlení databáze a simulovat periodické vzorkování údajů ze snímačů
s ukládáním dat ve formě časových řad do databáze. Jako snímač lze pro účely testování
použít jakýkoli analogový snímač.
Pro vyhodnocení testů byly stanoveny následující kritéria:
1. Posouzení složitosti zprovoznění zrcadlení (přehlednost a dostupnost dokumentace,
podmínky pro zprovoznění, možnosti automatizace procesu nastartování zrcadlení
pomocí skriptů).
2. Cena řešení.
3. Chování systému po rozpojení zrcadlení (složitost postupu obnovy do původního
stavu).
4. Odolnost mirroru při výpadku (vypnutí produkčního serveru při spuštěném mirroru).
U bodu 3 je záměrem ověřit také možnost využití třetího počítače v roli arbitru zrcadlení,
který umožňuje prohodit role (produkční – záložní systém). Cílem je tedy ověřit řešení
s maximální možnou míru automatizace přechodů a změn rolí bez nutnosti manuálního
zásahu operátora.
Zásadní pro vyhodnocení je čtvrté kritérium – chování zrcadlení při fyzickém vypnutí
produkčního serveru, výsledky tohoto testování jsou rozhodující pro závěrečné
vyhodnocení.
V době psaní příspěvku – červen 2014 – byla dokončena příprava testovací sestavy a
byly připraveny aplikace pro vzorkování dat ze snímačů, komunikaci s PLC a zápis dat do
databáze.
Poster
135
V průběhu srpna až září 2014 bude probíhat samotné testování a následné vyhodnocení.
Projekt SGS bude ukončen koncem roku 2014.
Již při zahájení testování můžeme konstatovat, že v dané oblasti chybí literatura, která
by komplexně popisovala způsoby práce s technologií zrcadlení v závislosti na použité
edici databázového systému. Samozřejmě, ke každému databázovému systému existují
rozsáhlá kompendia, která obsahují kapitoly věnované zrcadlení a také je celá řada článků
věnovaných zrcadlení dostupných na Internetu online. U každého systému jsme ale narazili
na několik skutečností, které nebyly úplně jasně popsány nebo jejichž popis chyběl a
k úspěšnému nastartování zrcadlení bylo nutné využít informace z několika zdrojů. Popisy
zprovoznění zrcadlení v literatuře jsou většinou zaměřeny na nejdražší enterprise verze
produktů. V případě použití standardních verzí je nutné některé postupy modifikovat.
Například u Microsoft SQL Serveru je nutné i v situaci, kdy servery nejsou zařazeny
v doméně, generovat a na druhém systému registrovat certifikáty pro přístupová práva
uživatelského účtu, který v rámci zrcadlení přistupuje do vzdáleného systému přes endpoint
protokolu TCP/IP (endpoint je objekt databáze SQL Server, který umožňuje komunikaci
v síti). Na druhé straně, při srovnání se stavem před deseti lety, je množství a přehlednost
informací dostupných k technologiím zrcadlení na Internetu podstatně vyšší.
4 Závěr
Pro řízení kontinuálních technologických procesů v surovinovém průmyslu je v současnosti
nutná existence výrobního informačního systému (MES), bez něhož by zajištění požadavků
na kvalitativní parametry a efektivnost výroby nebyla možná. V případě kontinuálních
procesů, kdy pořizovaná data mají charakter časových řad, musí být systém navržen
v kategorii fault-tolerant a splňovat požadavky na spolehlivost a robustnost.
V našem přípěvku jsme uvedli příklad takového systému ze surovinového průmyslu –
informačního systému pro úpravnu uhlí. Řízení jakostních parametrů uhlí v tomto systému
vyžaduje, z důvodu kontinuálního charakteru řízeného procesu, návrh a nasazení faulttolerant řešení, jehož nedílnou součástí je technologie zrcadlení databází. Zrcadlení
zajišťuje, že v případě výpadku systému a přechodu na záložní systém máme stále
k dispozici všechny produkční data a časové řady, sloužící k výpočtu trendů a bilancí,
nejsou významně narušeny. Výpočet trendu jakostních parametrů tak není zkreslený a
řízení výrobního procesu může pokračovat i v případě výpadku systému.
Na Institutu ekonomiky a systémů řízení se zabýváme návrhem architektury faulttolerant systémů pro kontinuální výrobní procesy – např. návrh watchdog komponenty pro
failover řešení (komponenta pro hlídání stavu produkčního serveru s algoritmem
zajišťujícím přechod na záložní systém v případě výpadku).
Ve vývoji je také varianta informačního systému se serverovým systémem na bázi
distribuce Linuxu.
Jedním z dalších oblastí řešení je zabezpečení dat v databázích, které mají charakter
časových řad a to byl důvod pro podání studentského grantového projektu zmíněného
v předchozí kapitole.
Literatura
1.
2.
3.
4.
5.
6.
7.
8.
Danel, R.: Analýza etap ve vývoji a implementaci informačních systémů a software
v úpravnách uhlí. In: Tvorba softwaru 2010, Česká společnost pro systémovou
integraci, Ostrava (2010) 33-39.
Danel, R.: Využití databázového mirroru SQL Serveru 2005 pro řešení odolnosti
informačního systému úpravny uhlí proti výpadkům. In: Datakon 2007, Brno (2007),
206-210.
Danel, R., Neustupa, Z.: Data Continuity Solution in Fault-tolerant Information
Systems. In: 12th International Carpathian Control Conference - ICCC 2011, Velké
Karlovice, Czech Republic (2011), 70 - 73.
Danel, R., Kohut, V., Kodym, O., Řepka, M., Kebo, V., Kijonka, M.: Information
Systems in Coal Preparation Plants and the Use of New Technologies. In: 13th SGEM
GeoConference on Informatics, Geoinformatics And Remote Sensing SGEM 2013.
Conference Proceedings, ISBN 978-954-91818-9-0 / ISSN 1314-2704, June 16-22,
Vol. 1 (2013), 151 – 158.
Database Mirroring Best Practices and Performance Considerations – Microsoft
MSDN
2006.
[online].
Available
at
<http://technet.microsoft.com/enus/library/cc917681.aspx>
Hemantgiri, G.: Microsoft SQL Server 2008 High Availability – Installing Database
Mirroring [online]. Available at <https://www.packtpub.com/books/content/microsoftsql-server-2008-high-availability-installing-database-mirroring>
Hirt, A.: SQL Server 2005 High Availability. Apress 2007. ISBN:13: 978-1-59059780-4
Oracle: 4 High Availability Architectures and Solutions. [online]. Available at
<http://docs.oracle.com/cd/B28359_01/server.111/b28281/architectures.htm>
Annotation:
For control of continuous technological processes in raw-material industry is nowadays necessary
existence of an information system (MES), which is in the category of fault-tolerant, and thus fulfills
the requirements for reliability and robustness. The Institute of Economics and Control Systems, we
design a suitable architecture of these systems - both hardware and software. The article describes the
reasons for the fault-tolerant solutions shown in example of coal preparation plant information system
and data safety having the character of time series using database mirroring technology. In 2014, the
Institute launched the project under the Student Grant Competition to compare the technology of
database mirroring four producers of database systems.
Rejstřík autorů
Bieliková, Mária .......................... 79
Biňas, Miroslav .......................... 111
Chlapek, Dušan ............................ 17
Danel, Roman ............................ 129
Genči, Ján ..................................... 73
Havlice, Zdeněk ........................... 99
Johanides, David ........................ 129
Jurčák, Ondej ............................. 121
Kalmár, Ján ................................ 121
Klímek, Jakub .............................. 17
Kučera, Jan ................................... 17
Kvet, Michal ................................ 87
Lacko, Peter ............................... 121
Líška, Miroslav ............................ 39
Matiaško, Karol ............................ 87
Nečaský, Martin ........................... 17
Ološtiak, Martin ........................... 73
Otte, Lukáš ................................. 129
Petrík, Juraj ................................ 121
Pidanič, Pavol ............................ 121
Pokorný, Jaroslav ........................... 3
Šesták, Kristián ............................ 99
Ševcech, Jakub ............................. 79
Šurek, Marek ................................ 53
Tibenský, Martin ........................ 121
Vajsová, Monika .......................... 87
Vincúr, Juraj .............................. 121
Vršek, Petr ................................... 63
Zápach, Radoslav ....................... 121

Petr Šaloun and Dušan Chlapek

Transkript

Podobné dokumenty

Vedení 400 kV V410/419, TR Výškov - TR Čechy Střed

1 Nadácia otvorenej spoločnosti

Diplomová práce

Teoretické základy kondenzační techniky

Druhé číslo - Psalterium - zpravodaj duchovní hudby

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Efektivní datové

20 stran / pages

text práce - Katedra geoinformatiky

Prezentace aplikace PowerPoint

NoSQL databáze – současný stav vývoje

CsIndex v.2.11 czech/slovak implementation of — — ceská

Dostupné škálovateľné riešenia pre spracovanie veľkého objemu

ZDE

Česká Java User Group (CZJUG) a Platforma informačních